1. HIT Policy Committee Information Exchange Workgroup Provider Directory Task Force Micky Tripathi, MA eHealth Collaborative, Chair IE Workgroup Jonah Frohlich, Manatt Health Solutions, Co-Chair, Provider Directory Task Force Walter Suarez, Kaiser Permanente, Co-Chair, Provider Directory Task Force January 12, 2011

2. Today’s objectives Review WG and TF charge and problem statement Review background information on Provider Directories –Entity-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 2

3. 3 Charge to the IE Workgroup Breakthrough areas where policy barriers prevent providers and/or states from being effective enablers of broader and deeper health exchange –Specific clinical transactions already identified as important to meaningful use –Critical 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 attention –For issues in IE WG charter, Identify and recommend solutions to such issues to HITPC –For issues outside of IE WG charter, navigate to most appropriate HITPC WG(s) and facilitate/coordinate as necessary

4. IE Workgroup Membership NameAffiliation Hunt BlairVermont Medicaid Jim BuehlerCDC Connie W. DelaneyUniversity of Minnesota, Nursing Paul Egerman Judy FaulknerEpic Seth FoldyCDC Donna FrescatoreNY Medicaid Jonah FrohlichManatt Health Solutions Dave Goetz Dept. of Finance and Administration, TN James GoldenMinnesota Department of Health Gayle Harrell 4 NameAffiliation Dianne Hasselman Center for Health Care Strategies George HripcsakColumbia University Jessica KahnCMS Charles KennedyWellPoint, Inc. Michael Klag Johns Hopkins School of Public Health Deven McGraw Center for Democracy & Technology George OestreichMissouri Medicaid David A. Ross Public Health Informatics Institute Steven StackAmerican Medical Association Walter SuarezKaiser Permanente Latanya SweeneyCarnegie Mellon University Chair: Micky Tripathi, Massachusetts eHealth Collaborative Co-Chair: David Lansky, Pacific Business Group on Health

5. 5 Provider Directory Task Force Policy Objective and Problem Statement Policy objective Facilitate rapid increase in secure electronic health information exchange (HIE) throughout our health system Problem Statement The 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 broadly Will 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: 1.How can provider directories accelerate information exchange? 2.What can federal and state governments do to guide directory development to support meaningful use and drive system-wide improvements in care? 3.What policy actions can be taken to promote creation of provider directories that accelerate secure information exchange? 4.How can information exchange across state borders and nationwide be accelerated by consistent application and use of provider directories? 5

6. Provider Directory Task Force Membership 6 NameAffiliation Hunt Blair Sorin Davis Paul Egerman Judy Faulkner Seth Foldy Dave Goetz James Golden. Keith Hepp Jessica Kahn JP Little George Oestreich Lisa Robin Steven Stack Sid Thornton Vermont Medicaid CAQH Epic DHS, Wisconsin Dept. of Finance and Administration, TN Minnesota Department of Health HealthBridge CMS Surescripts Missouri Medicaid Federation of State Medical Boards AMA Intermountain Healthcare Co-Chair: Jonah Frohlich, Manatt Health Solutions Co-Chair: Walter Suarez, Kaiser Permanente

7. 7 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 organizations –Individual-Level Provider Directory (ILPD): a directory listing individual providers (See Appendix 1 - Terminology)

8. Provider Directories - Where are we in the process? Users and Uses FunctionsContent Operating rqmts Business models Policy issues Policy actions Who 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 Options Policy 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 8

9. Entity-Level Provider Directories (ELPDs) 9

10. Approved Recommendations - ELPDs (1) Recommendation: The following entities should be listed in the ELPD Health 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 functionality Support directed exchanges (send/receive as well as query/retrieve) Provide basic “discoverability” of entity Provide basic “discoverability” information exchange capabilities (i.e. CCD, HL7 2.XX) Provide basic “discoverability” of entity’s security credentials 10 Users and Uses Functions

11. 11 Recommendation: ELPD content should be limited to the following categories of information Entity ‘demographics’ and identification information ­Name, address(es); Other familiar names; Human level contact Information Exchange Services ­Relevant domains (as defined by each entity); relevant website locations ­Protocols 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 entity’s information (recommended) ­Include the entity-level information in the directory ­General Inbox location, if applicable (for message pick-up/drop-off) Security Basic information about security credentials (i.e., type, location for authentication) Approved Recommendations - ELPDs (2) Content

12. 12 Recommendation: Business model and operating approach Internet-like model (nationally coordinated, federated approach) –Certified registrars: registrars are ‘registered’ and certified to receive/process/accept entities in the ELPDs –National guidelines: Registrars follow national guidelines for who to accept, validation of application, addressing –Registrar 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 domains –ELPDs: maintained by registrars; cross-referenced through system (similar to DNS) –Possible roles of federal government: National standardization and harmonization Some 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

13. Recommendations on Policy Levers to Establish Nation-wide Entity-Level Provider Directory 13 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)

14. Policy Options Business Model recommendation to HITPC 11/19 Potential Government Roles/Policy Levers InfrastructureMaintaining data quality and accuracy Standards and Interoperability Governance and Participation Internet/like model - nationally coordinated, federated approach. Operates similar to DNS Standards, 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 gateway Standards developed through S&I framework, recommended by HITSC Data elements Interoperability with EHR Open interfaces Could be adopted through/by: EHR certification/MU standards rules Requirements for any directories/registrars receiving HITECH funds (state HIE program) Requirements for participants in Nationwide Health Information Network Federal agencies serving as registrars ELPD 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 14

15. ELPDs – Policy Recommendation 1 The HITSC should be directed to identify technology, vocabulary, and content standards that will create an ELPD with multiple registrars and a single, nationwide, registry –The 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 registrars –Acquisition of a security credential (certificate) and discoverability of this credential using the ELPD must be included in the technical approach –The technical approach must also include a process for certification of ELPD functionality in EHRs and accreditation of registrars –Recognizing 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 Discussion –The 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 15

16. ELPDs – Policy Recommendation 2 The federal government should use the strongest available levers to require registration in, and encourage use of, the nationwide ELPD –ELPD registration and use should be incorporated in MU Stage 2/3 and in NHIN participation requirements –The 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/3 –ELPD governance and participation should be included as part of NHIN “Conditions of Trust and Interoperability” and used as a lever to establish NHIN Governance Require ELPD registration for participation in NHIN Exchange and Direct Create an accreditation process for registrars within the context of other similar processes (e.g., certificate issuance) Discussion –MU 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 incentives –The 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 requirement –We 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 process –CMS processes (NRL, PECOS, etc) should be leveraged to the greatest extent possible 16

17. ELPDs – Policy Recommendation 3 State-level HIE and Beacon programs should be required to enable the use of a national registry in addressing their constituents provider directory needs –ONC should require conformance with ELPD standards and technical guidelines –ONC 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 Discussion –ELPDs can provide a foundation to on which to build ILPDs and/or other sub-national public and private registries –While 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 requirement –States 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. 17

18. Individual-Level Provider Directories (ILPDs) 18

19. ILPD Assumptions and framing Scope of ILPDs should be sub-national level Rigid conformance not required States 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 ILPDs Will use the framework from ELPD for the development of recommendations on ILPDs 19

20. ILPDs - Proposed framework Users and Uses FunctionsContent Operating rqmts Business models Policy issues Policy actions Who wants an ILPD? What do they want to use it for? What functions do users of ILPDs need for their desired uses? What data will be required in ILPDs in order to enable desired functions? What operating business requirements will be needed for ILPDs in order for them to be used? What are possible ILPD 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? Directory Requirements and OptionsRecommendations Environmental scan and business analysis Consensus conclusions and recommendations 20

21. Proposed work plan DateMeetingTopic Jan 4PD TFApprove Framework and Schedule Define Users & Uses; Begin discussion of Functions Jan 13IE WGDefine Functions Discuss Content and Operating Requirements Discuss PCAST Report Jan 18PD TFPresent Framework and Definitions of Users & Uses, Functions, Content, and Operating Requirements Discuss Possible Business Models Jan 24PD TFApprove Business Model focus areas Discuss Policy Issues and Actions Jan 28IE WGApprove Recommendation Feb 2HITPCRecommendations to HITPC on Individual-level Provider Directories 21

22. Appendix 1 – Terminology 22

23. Terminology 23 ELPD Recommendation: Basic Common Terminology Provider 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 organizations Individual-Level Provider Directory (ILPD): a directory listing individual providers Entity: 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 exchange Technical 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

24. Terminology 24 ELPD Recommendation: Basic Common Terminology Query/Retrieval: The process of requesting and obtaining access to health information. It also refers to the process of request and obtaining provider directory information Security 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. Discoverability The 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 functions Register/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

25. Appendix 2: High Level Principles for Provider Directory Discussions 25

26. 26 High Level Principles to Consider To Guide Development of Provider Directory Policy Recommendations What 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 what’s 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 beyond Agility - Don’t 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 stages Collaboration - Encourage regional/multi-state/national initiatives that leverage purchasing, policy and regulatory opportunities Completeness - Clearly delineate sources and uses and users Security – 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

27. Appendix 3 – ELPD Use Cases 27

28. Scenarios and uses/value of ELPDs 28 ScenariosValue of Entity-Level Directory Scenario: Clinician Orders Test from Lab & Lab Sends Results Clinician from Clinic X sends Lab Order to Laboratory Clinic X’s EHR generates lab order message and sends it to Laboratory Laboratory Information System (LIS) received lab order After lab sample is processed and results are entered, LIS generates a lab results message and sends back to ordering clinician Generally, exchanges with laboratories might be well-known to the clinic and pre-established Clinic 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 lab The entity level directory provides two benefits: Establishing a first-time connection with the lab and have the path be defined Afterwards, to ensure that changes to the address of the lab from changes the lab might experience (moved, purchased, etc) will be resolved Lab sends back results to Clinic X to the declared ‘address’ included in the electronic lab order Lab may also use entity-level directory to support ‘copy-to’ function to send results to a non-ordering provider Using 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. Uses/Functionality

29. 29 ScenariosValue of Entity-Level Directory Scenario: Patient Summary from PCP to Specialist PCP from Clinic X is sending a Patient Summary to Specialist in Clinic Y Clinic X’s EHR sends patient summary (i.e. CCD) to Clinic Y’s EHR Clinic Y EHR system receives the patient summary and incorporates data into the patient’s record in the EHR Clinic Y EHR sends an alert to specialist that new information about Patient is available Clinic 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 available Using 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 patient’s primary care provider practices and the patient’s record resides Clinic’s EHR system receives the discharge summary and incorporates data into the patient’s record in the EHR Clinic’s EHR sends an alert to primary care provider that new information about Patient X is available Hospital 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 available Using 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

30. 30 ScenariosValue of Entity-Level Directory Scenario: Hospital X Request for Information from Hospital Y Patient outside of their home geography appears in hospital for emergency or acute care Hospital X needs additional clinical information prior to treatment Patient knows familiar name of home Hospital Y; Hospital X needs to look up complete address for Hospital Y Hospital X sends request for patient information to Hospital Y Hospital Y sends CCD summary to Hospital X Hospital 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 information Hospital Y will use the entity-level directory to discover location of security credentials (as applicable) of Hospital X Hospital Y will send CCD the know address of Hospital X, based on the query 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 available Using 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 Referral PCP wants to refer patient for specialist consult or diagnostic testing PCP (or patient?) searches Directory for specialists or diagnostic test centers Patient chooses from among available choices PCP sends CCD referral summary or diagnostic test order The 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

31. 31 ScenariosValue of Entity-Level Directory Scenario: Public Health request for data from provider Public health agency needs to obtain information about a patient from a provider (clinic, hospital), in support of public health functions Public health seeks provider, sends query with request for information Provider received query, process it and submits data to public health agency Public health agency uses entity-level provider directory to identify the ‘address’ of the clinic/hospital to send the query Entity-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/hospital In 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 routing A regional HIO X needs to send clinical information to regional HIO Y HIO X uses entity-level directory to search for the organization’s ‘address’ of HIO Y Scenarios and uses/value of ELPDs Uses/Functionality