HIT Policy Committee

Information Exchange WorkgroupProvider Directory Task Force

Micky Tripathi, MA eHealth Collaborative, Chair IE Workgroup Jonah Frohlich, Manatt Health Solutions, Co-Chair, Provider Directory Task ForceWalter Suarez, Kaiser Permanente, Co-Chair, Provider Directory Task Force

January 12, 2011

Todays objectivesReview WG and TF charge and problem statement

Review background information on Provider DirectoriesEntity-Level Provider Directories (ELPDs)Individual-Level Provider Directories (ILPDs)

Present policy recommendations on ELPDs endorsed by the HIT Policy Committee

Review and discuss preliminary policy directions being considered by Provider Directory Task Force on ILPDs*

*Charge to the IE WorkgroupBreakthrough areas where policy barriers prevent providers and/or states from being effective enablers of broader and deeper health exchangeSpecific clinical transactions already identified as important to meaningful useCritical issues that get unearthed by the over $1.5 billion programs in state-level HIE, RECs, Beacons, and NHIN Direct

IE WG will also act as conduit for state-level policy issues that need HITPC attentionFor issues in IE WG charter, Identify and recommend solutions to such issues to HITPCFor issues outside of IE WG charter, navigate to most appropriate HITPC WG(s) and facilitate/coordinate as necessary

IE Workgroup Membership*Chair: Micky Tripathi, Massachusetts eHealth CollaborativeCo-Chair: David Lansky, Pacific Business Group on Health

NameAffiliationHunt BlairVermont MedicaidJim BuehlerCDCConnie W. DelaneyUniversity of Minnesota, NursingPaul EgermanJudy FaulknerEpicSeth FoldyCDCDonna FrescatoreNY MedicaidJonah FrohlichManatt Health SolutionsDave GoetzDept. of Finance and Administration, TNJames GoldenMinnesota Department of HealthGayle Harrell

NameAffiliationDianne HasselmanCenter for Health Care StrategiesGeorge HripcsakColumbia UniversityJessica KahnCMSCharles KennedyWellPoint, Inc.Michael KlagJohns Hopkins School of Public HealthDeven McGrawCenter for Democracy & TechnologyGeorge OestreichMissouri MedicaidDavid A. RossPublic Health Informatics InstituteSteven StackAmerican Medical AssociationWalter SuarezKaiser PermanenteLatanya SweeneyCarnegie Mellon University

*Provider Directory Task ForcePolicy Objective and Problem StatementPolicy objectiveFacilitate rapid increase in secure electronic health information exchange (HIE) throughout our health system

Problem StatementThe lack of a consistent approach to cross-organizational provider directories is a known barrier to progress both in directed exchange and in health information exchange more broadlyWill also represent a missed opportunity to align multiple activities and combine multiple streams of funding that could yield a lower cost, higher quality service for all (e.g., State-level HIE grants, Beacon grants, Medicaid, Public Health)Key questions that the IE WG Provider Directory Task Force will address:How can provider directories accelerate information exchange?What can federal and state governments do to guide directory development to support meaningful use and drive system-wide improvements in care?What policy actions can be taken to promote creation of provider directories that accelerate secure information exchange?How can information exchange across state borders and nationwide be accelerated by consistent application and use of provider directories?*

Provider Directory Task Force Membership*Co-Chair: Jonah Frohlich, Manatt Health SolutionsCo-Chair: Walter Suarez, Kaiser Permanente

NameAffiliationHunt BlairSorin DavisPaul EgermanJudy FaulknerSeth FoldyDave GoetzJames Golden.Keith HeppJessica KahnJP Little George OestreichLisa RobinSteven StackSid ThorntonVermont MedicaidCAQH

EpicDHS, WisconsinDept. of Finance and Administration, TNMinnesota Department of HealthHealthBridgeCMSSurescriptsMissouri MedicaidFederation of State Medical BoardsAMAIntermountain Healthcare

*What are Provider Directories?An electronic searchable resource that lists all information exchange participants, their names, addresses and other characteristics and that is used to support secure and reliable exchanges of health information. Two types being considered:Entity-Level Provider Directory (ELPD): A directory listing provider organizationsIndividual-Level Provider Directory (ILPD): a directory listing individual providers

(See Appendix 1 - Terminology)

Provider Directories - Where are we in the process?Users and UsesFunctionsContentOperating rqmtsBusiness modelsPolicy issuesPolicy actionsWho wants an entity directory?

What do they want to use it for?What functions do users need for their desired uses?What data will be required in order to enable desired functions?What operating business requirements will be needed in order for this to be used?What are possible business models for meeting needs?

Which business models should the government promote?

What are the policy issues related to each of the suggested business models?What policy actions should be taken to address the policy issues?Recommendations on Directory Requirements and OptionsPolicy Recommendations-- Entity-Level Provider Directory (ELPD) Recommendations Endorsed by HITPC December, 2010 -- Individual-Level Provider Directory (ILPD) Recommendations to HITPC February, 2011

-- Recommendations on Policy levers for ELPD Endorsed by HITPC*

Entity-Level Provider Directories (ELPDs)*

Approved Recommendations - ELPDs (1) Recommendation: The following entities should be listed in the ELPDHealth care provider organizations (i.e., hospitals, clinics, nursing homes, pharmacies, labs, etc)Other health care organizations (i.e., health plans, public health agencies)Health Information Organizations (i.e., regional HIE operators, health information service providers)Other organizations involved in the exchange of health information (business associates, clearinghouses)

Recommendation: ELPDs should support the following functionalitySupport directed exchanges (send/receive as well as query/retrieve)Provide basic discoverability of entityProvide basic discoverability information exchange capabilities (i.e. CCD, HL7 2.XX)Provide basic discoverability of entitys security credentials*Users and UsesFunctions

*Recommendation: ELPD content should be limited to the following categories of information Entity demographics and identification informationName, address(es); Other familiar names; Human level contactInformation Exchange ServicesRelevant domains (as defined by each entity); relevant website locationsProtocols and standards supported for Information Exchange (SMTP, REST, CCD/CDA, CCR, HL7 2.x.x, etc)Two Options:Include a pointer in the directory to the entitys information (recommended)Include the entity-level information in the directoryGeneral Inbox location, if applicable (for message pick-up/drop-off)SecurityBasic information about security credentials (i.e., type, location for authentication)

Approved Recommendations - ELPDs (2)Content

*Recommendation: Business model and operating approachInternet-like model (nationally coordinated, federated approach)Certified registrars: registrars are registered and certified to receive/process/accept entities in the ELPDsNational guidelines: Registrars follow national guidelines for who to accept, validation of application, addressingRegistrar reciprocity and Publication to National Registry System:Entities registered by one registrar are recognized across system (no need to register again at different registrars)Each registrar publishes directory information into a national provider directory registry system that, like DNS, will support identification of entities across registrar domainsELPDs: maintained by registrars; cross-referenced through system (similar to DNS)Possible roles of federal government:National standardization and harmonizationSome agencies could be registrars themselves (i.e., Medicare, VA)Build on existing national/federal tools (i.e., PECOS, NPPES, NLR, others)

Approved Recommendations - ELPDs (3)Operating Rqrmts. / Business Model

Recommendations on Policy Levers to Establish Nation-wide Entity-Level Provider Directory

*Policy Questions Which business models should the government promote?

What are the potential government roles and levers?

What is the appropriate level of depth in policy recommendations (and avoid stepping into role of Standards Committee)

What is critical and necessary to meet our goals (minimal necessary principal)

Policy Options*

Business Model recommendation to HITPC 11/19Potential Government Roles/Policy LeversInfrastructureMaintaining data quality and accuracyStandards and InteroperabilityGovernance and ParticipationInternet/like model - nationally coordinated, federated approach.

Operates similar to DNSStandards, services and policies to link existing and new ELPD assets managed by registrars

Certified registrars and/or accreditation process

Some federal agencies could be registrars (Medicare/VA)

States can also be registrars (HIE program)Meaningful use (EPs and hospitals required to participate and maintain own data)

Licensing/payment policy, especially for entities that do not receive MU incentives Requirements for participants in Nationwide Health Information Network

Registration for Direct address

Onboarding for Exchange gatewayStandards developed through S&I framework, recommended by HITSCData elementsInteroperability with EHROpen interfaces

Could be adopted through/by:EHR certification/MU standards rulesRequirements for any directories/registrars receiving HITECH funds (state HIE program)Requirements for participants in Nationwide Health Information NetworkFederal agencies serving as registrarsELPD governance could be requirement of Nationwide Health Information Network governance

Levers to entice entities to participate in the provider directories

Levers to entice potential registrars to become registrars

ELPDs Policy Recommendation 1The HITSC should be directed to identify technology, vocabulary, and content standards that will create an ELPD with multiple registrars and a single, nationwide, registryThe single, nationwide registry must be accessible by EHR systems and must accept registrations from accredited state/regional registrars and publish updates that are consumable to those registrarsAcquisition of a security credential (certificate) and discoverability of this credential using the ELPD must be included in the technical approachThe technical approach must also include a process for certification of ELPD functionality in EHRs and accreditation of registrarsRecognizing that some policy questions may still be unanswered, the HITSC should consult the HITPC as necessary during standards development to assure alignment of standards with policy

DiscussionThe infrastructure for an effective nationwide ELPD includes the registry itself, a robust process for managing registry entries, and means for users to access registry information*

ELPDs Policy Recommendation 2The federal government should use the strongest available levers to require registration in, and encourage use of, the nationwide ELPDELPD registration and use should be incorporated in MU Stage 2/3 and in NHIN participation requirementsThe MU Working Group should work jointly with the IE WG to determine the best approach for incorporating ELPD registration and use in MU Stage 2/3ELPD governance and participation should be included as part of NHIN Conditions of Trust and Interoperability and used as a lever to establish NHIN GovernanceRequire ELPD registration for participation in NHIN Exchange and DirectCreate an accreditation process for registrars within the context of other similar processes (e.g., certificate issuance)

DiscussionMU and NHIN governance are complementary levers MU has greater reach and more immediate relevance in the market, whereas NHIN governance will have persistence beyond HITECH incentivesThe IE Working Group strongly supports incorporating ELPD registration and use in MU Stage 2/3 requirements; we recognize, however, that the details of how to incorporate this in MU needs to be integrated with other HIE infrastructure requirements and addressed to the greatest extent possible as part of a clinical process rather than as a technology process requirementWe also believe that ELPD registration and use should be a NHIN participation requirement; the national registry can be used either to validate potential NHIN participants or to list NHIN participants who have been validated through a separate processCMS processes (NRL, PECOS, etc) should be leveraged to the greatest extent possible*

ELPDs Policy Recommendation 3State-level HIE and Beacon programs should be required to enable the use of a national registry in addressing their constituents provider directory needsONC should require conformance with ELPD standards and technical guidelinesONC should encourage state-level HIE program grantees to become accredited registrars and to work in partnership with other grantees to create multi-state/regional registrars where feasible and to promote the establishment of accredited registrars in their states and regions

DiscussionELPDs can provide a foundation to on which to build ILPDs and/or other sub-national public and private registriesWhile it might be desirable to require that state-level HIE grantees become registrars, variations in state laws as well as the potential for many other organizations to become registrars obviates the need to have this as a requirementStates and State Designated Entities (SDEs) may want to consider entering into partnerships with other states/SDEs to group purchase registry services, or for leader states/SDEs to procure and make services available to providers in other states.

*

Individual-Level Provider Directories (ILPDs)*

ILPD Assumptions and framingScope of ILPDs should be sub-national levelRigid conformance not requiredStates are currently implementing ILPDs as we speak - need to produce recommendations rapidly Focus on best practices for establishing and maintaining ILPDs (particularly data accuracy)Best practices for local policy levers for incenting participation in ILPDsWill use the framework from ELPD for the development of recommendations on ILPDs

*

ILPDs - Proposed framework*

Proposed work plan*

DateMeetingTopicJan 4PD TFApprove Framework and ScheduleDefine Users & Uses; Begin discussion of FunctionsJan 13IE WGDefine FunctionsDiscuss Content and Operating RequirementsDiscuss PCAST ReportJan 18PD TFPresent Framework and Definitions of Users & Uses, Functions, Content, and Operating RequirementsDiscuss Possible Business ModelsJan 24PD TFApprove Business Model focus areasDiscuss Policy Issues and ActionsJan 28IE WGApprove RecommendationFeb 2HITPCRecommendations to HITPC on Individual-level Provider Directories

Appendix 1 Terminology*

Terminology*ELPD Recommendation: Basic Common TerminologyProvider Directory: An electronic searchable resource that lists all information exchange participants, their names, addresses and other characteristics and that is used to support secure and reliable exchanges of health information. Entity-Level Provider Directory (ELPD): A directory listing provider organizationsIndividual-Level Provider Directory (ILPD): a directory listing individual providersEntity: Any organization involved in the exchange of patient health information, including submitters, receivers, requesters and providers of such information. Organizational entities: The legal organization involved in the exchangeTechnical entities: The systems/services that can interact with people through displays, etc., send and receive messages in standardized ways, etc.Individual Provider/Clinician:Individual health care provider (per HIPAA/HITECH definition)Sender: Authorized final end-point organizational entities or their employees or proxy technical entities that generate and send directed exchanges. Receiver:Authorized organizational entities or their employees or proxy technical entities that receive directed exchanges.Routing:Process of moving a packet of data from source to destination. Routing enables a message to pass from one computer system to another. It involves the use of a routing table to determine the appropriate path and destination

Terminology*ELPD Recommendation: Basic Common TerminologyQuery/Retrieval:The process of requesting and obtaining access to health information. It also refers to the process of request and obtaining provider directory informationSecurity Credentials:A physical/tangible object, a piece of knowledge, or a facet of an entity's or person's physical being, that enables the entity/person access to a given physical facility or computer-based information system. Typically, credentials can be something you know (such as number or PIN), something you have (such as an access badge), something you are (such as a biometric feature) or some combination of these items.DiscoverabilityThe ability of an individual/entity to access and obtain specific information about another entity, including demographic information, information exchange information and security credentials information. Administrative-related functionsRegister/edit/delete: Processes executed by authorized individuals or entities to add or modify entries (entities and individuals) in a provider directory based on national and local policies. They may involve attestation, verification and/or validation of the information provided about the entities and individuals.Access control: Prevention of unauthorized use of information assets (ISO 7498-2). It is the policy rules and deployment mechanisms, which control access to information systems, and physical access to premises (OASIS XACML) Audit: Review and examination of records (including logs), and/or activities to ensure compliance with established policies and operational procedures. This review can be manual or automated

Sources: IHE Provider Directory Profile; HITSP Glossary; NIST Technical Documents

Appendix 2: High Level Principles for Provider Directory Discussions*

*High Level Principles to Consider To Guide Development of Provider Directory Policy RecommendationsWhat initial principles should apply generally to Provider Directories? (From Nationwide Framework)Openness and Transparency Provider directories policies, procedures and technologies should be open and transparent.Collection, Use, and Disclosure Limitation Provider directories will support the exchange (collection and disclosure) of health information in a consistent and reliable manner.Data Quality and Integrity By supporting reliable information exchanges in real time, provider directories will help ensure that complete and accurate data is available to support delivery of care.Safeguards Provider directories will support the secure exchange of health information.Accountability Provider directories will help ensure accountability of those involved in information exchanges.

What initial principles should apply to our Provider Directory recommendations?Business Processes - Start simple and with whats needed to support concrete priority business process, not with data Meaningful Use - Focus on requirements for stage 1 MU, but with an eye to supporting Stages 2 and 3 and beyondAgility - Dont over-design too early, remain flexible to changes in technology and business (e.g., ACOs)Incremental Start by identifying and clearly articulating the minimum set of directory capabilities and the most straightforward technical model needed to accelerate and enhance secure exchange as identified in current and anticipated Meaningful Use stagesCollaboration - Encourage regional/multi-state/national initiatives that leverage purchasing, policy and regulatory opportunitiesCompleteness - Clearly delineate sources and uses and usersSecurity Protected health information must be transmitted securely, with assurances that actors participating in exchange adhere to a minimum set of standards to protect that information Principles

Appendix 3 ELPD Use Cases

*

Scenarios and uses/value of ELPDs* Uses/Functionality

ScenariosValue of Entity-Level DirectoryScenario: Clinician Orders Test from Lab & Lab Sends ResultsClinician from Clinic X sends Lab Order to LaboratoryClinic Xs EHR generates lab order message and sends it to LaboratoryLaboratory Information System (LIS) received lab orderAfter lab sample is processed and results are entered, LIS generates a lab results message and sends back to ordering clinicianGenerally, exchanges with laboratories might be well-known to the clinic and pre-establishedClinic X will use the entity-level directory to obtain the organization-level address of the laboratory, and other information exchange features supported by the lab (port information, formats supported, security credential locations) which allows Clinic X to establish a connection, open a defined port, and drop a message to the labThe entity level directory provides two benefits:Establishing a first-time connection with the lab and have the path be definedAfterwards, to ensure that changes to the address of the lab from changes the lab might experience (moved, purchased, etc) will be resolvedLab sends back results to Clinic X to the declared address included in the electronic lab orderLab may also use entity-level directory to support copy-to function to send results to a non-ordering providerUsing the directory, the digital credentials of both the sending and receiving computers are used to validate identities.Prior to sending the transaction, the sending computer checks the I.E. services that the receiving computer uses and determines whether the transaction can be sent.

*Scenarios and uses/value of ELPDs Uses/Functionality

ScenariosValue of Entity-Level DirectoryScenario: Patient Summary from PCP to SpecialistPCP from Clinic X is sending a Patient Summary to Specialist in Clinic YClinic Xs EHR sends patient summary (i.e. CCD) to Clinic Ys EHRClinic Y EHR system receives the patient summary and incorporates data into the patients record in the EHRClinic Y EHR sends an alert to specialist that new information about Patient is availableClinic X will use the entity-level directory to identify the organization-level address of Clinic Y and other information exchange features supported by Clinic Y (port information, formats supported, security credential locations)In the message header or inside the message is where the information about the patient, the provider (specialist) resides, which will be used by the EHR of the recipient to incorporate data, issue alerts to providers about new data availableUsing the directory, the digital credentials of both the sending and receiving computers are used to validate identities.Prior to sending the transaction, the sending computer checks the I.E. services that the receiving computer uses and determines whether the transaction can be sent.Scenario: Hospital Discharge Summary (or ED Visit Summary or Surgical Report Summary)Hospital discharge summary (i.e. CDA) of a patient is sent from hospital information system (EHR) to the clinic EHR where patients primary care provider practices and the patients record residesClinics EHR system receives the discharge summary and incorporates data into the patients record in the EHRClinics EHR sends an alert to primary care provider that new information about Patient X is availableHospital will use the entity-level directory to identify the organization-level address of the clinic the data is intended to, and other information exchange features supported by the clinic (port information, formats supported, security credential locations)In the message header or inside the message is where the information about the patient, the provider (specialist) resides, which will be used by the EHR of the recipient to incorporate data, issue alerts to providers about new data availableUsing the directory, the digital credentials of both the sending and receiving computers are used to validate identities.Prior to sending the transaction, the sending computer checks the I.E. services that the receiving computer uses and determines whether the transaction can be sent.

*Scenarios and uses/value of ELPDs Uses/Functionality

ScenariosValue of Entity-Level DirectoryScenario: Hospital X Request for Information from Hospital YPatient outside of their home geography appears in hospital for emergency or acute careHospital X needs additional clinical information prior to treatmentPatient knows familiar name of home Hospital Y; Hospital X needs to look up complete address for Hospital YHospital X sends request for patient information to Hospital YHospital Y sends CCD summary to Hospital XHospital X will use the entity-level directory to search for the organization-level address of the Hospital Y to be able to send query for patient informationHospital Y will use the entity-level directory to discover location of security credentials (as applicable) of Hospital XHospital Y will send CCD the know address of Hospital X, based on the queryIn the message header or inside the message is where the information about the patient, the provider (specialist) resides, which will be used by the EHR of the recipient to incorporate data, issue alerts to providers about new data availableUsing the directory, the digital credentials of both the sending and receiving computers are used to validate identities.Prior to sending the transaction, the sending computer checks the I.E. services that the receiving computer uses and determines whether the transaction can be sent.Scenario: Patient Request for Site of ReferralPCP wants to refer patient for specialist consult or diagnostic testingPCP (or patient?) searches Directory for specialists or diagnostic test centersPatient chooses from among available choicesPCP sends CCD referral summary or diagnostic test orderThe entity level directory is used to make sure that the CCD is sent to the correct organization.The header or message content contains information about the patient identity and, also, the specialist, if appropriate.*** It is not necessary for this directory to describe services that are provided, because that information should be available from other sources. The primary purpose of the entity-level directory is routing.

*Scenarios and uses/value of ELPDs Uses/Functionality

ScenariosValue of Entity-Level DirectoryScenario: Public Health request for data from providerPublic health agency needs to obtain information about a patient from a provider (clinic, hospital), in support of public health functionsPublic health seeks provider, sends query with request for informationProvider received query, process it and submits data to public health agencyPublic health agency uses entity-level provider directory to identify the address of the clinic/hospital to send the queryEntity-level directory provides other information exchange features supported by the clinic/hospital (port information, formats supported, security credential locations)Public health agency sends query to clinic/hospitalIn the message header or inside the message is where the information about the patient resides, which will be used by the clinic/hospital to search/extract data needed

Scenario: HIO to HIO routingA regional HIO X needs to send clinical information to regional HIO YHIO X uses entity-level directory to search for the organizations address of HIO Y

**

*