HIT Policy Committee Information Exchange Workgroup Provider Directory

HIT Policy Committee Information Exchange Workgroup Provider Directory Task Force Micky Tripathi, MA e. Health 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

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

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 3

IE Workgroup Membership Chair: Micky Tripathi, Massachusetts e. Health Collaborative Co-Chair: David Lansky, Pacific Business Group on Health Name Affiliation Hunt Blair Vermont Medicaid Dianne Hasselman Center for Health Care Strategies Jim Buehler CDC George Hripcsak Columbia University Connie W. Delaney University of Minnesota, Nursing Jessica Kahn CMS Paul Egerman Charles Kennedy Well. Point, Inc. Johns Hopkins School of Public Health Center for Democracy & Technology Judy Faulkner Epic Michael Klag Seth Foldy CDC Deven Mc. Graw Donna Frescatore NY Medicaid George Oestreich Missouri Medicaid Jonah Frohlich Manatt Health Solutions David A. Ross Public Health Informatics Institute Dave Goetz Dept. of Finance and Administration, TN Steven Stack American Medical Association James Golden Minnesota Department of Health Walter Suarez Kaiser Permanente Latanya Sweeney Carnegie Mellon University Gayle Harrell 4

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

Provider Directory Task Force Membership Co-Chair: Jonah Frohlich, Manatt Health Solutions Co-Chair: Walter Suarez, Kaiser Permanente Name Affiliation 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. Bridge CMS Surescripts Missouri Medicaid Federation of State Medical Boards AMA Intermountain Healthcare 6

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) 7

Provider Directories - Where are we in the process? Recommendations on Directory Requirements and Options Users and Uses Functions Who wants an What functions entity directory? do users need for their desired What do they uses? want to use it for? Content What data will be required in order to enable desired functions? Operating rqmts What operating business requirements will be needed in order for this to be used? Policy Recommendations Business models What are possible business models for meeting needs? -- Entity-Level Provider Directory (ELPD) Recommendations Endorsed by HITPC December, 2010 -- Individual-Level Provider Directory (ILPD) Recommendations to HITPC February, 2011 Policy issues Which business models should the government promote? Policy actions What policy actions should be taken to address the policy issues? What are the policy issues related to each of the suggested business models? -- Recommendations on Policy levers for ELPD Endorsed by HITPC 8

Entity-Level Provider Directories (ELPDs) 9

Approved Recommendations - ELPDs (1) Users and Uses Functions 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, HL 7 2. XX) • Provide basic “discoverability” of entity’s security credentials 10

Approved Recommendations - ELPDs (2) Content 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, HL 7 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) 11

Approved Recommendations - ELPDs (3) Operating Rqrmts. / Business Model 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) 12

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) 13

Policy Options Business Model recommendation to HITPC 11/19 Potential Government Roles/Policy Levers Infrastructure Internet/like model nationally coordinated, federated approach. Operates similar to DNS Maintaining data quality and accuracy Standards and Interoperability Governance and Participation Standards, services and policies to link existing and new ELPD assets managed by registrars Meaningful use (EPs and hospitals required to participate and maintain own data) Standards developed through S&I framework, recommended by HITSC • Data elements • Interoperability with EHR • Open interfaces ELPD governance could be requirement of Nationwide Health Information Network governance Certified registrars and/or accreditation process Licensing/payment policy, especially for entities that do not receive MU incentives Some federal agencies could be registrars (Medicare/VA) Requirements for participants in Nationwide Health Information Network States can also be registrars (HIE program) Registration for Direct address Onboarding for Exchange gateway 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 Levers to entice entities to participate in the provider directories Levers to entice potential registrars to become registrars 14

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

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

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

Individual-Level Provider Directories (ILPDs) 18

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

ILPDs - Proposed framework Directory Requirements and Options Users and Uses Who wants an ILPD? What do they want to use it for? Functions What functions do users of ILPDs need for their desired uses? Content What data will be required in ILPDs in order to enable desired functions? Operating rqmts What operating business requirements will be needed for ILPDs in order for them to be used? Environmental scan and business analysis Recommendations Business models What are possible ILPD business models for meeting needs? Policy issues Which business models should the government promote? Policy actions What policy actions should be taken to address the policy issues? What are the policy issues related to each of the suggested business models? Consensus conclusions and recommendations 20

Proposed work plan Date Meeting Topic Jan 4 PD TF • Approve Framework and Schedule • Define Users & Uses; Begin discussion of Functions Jan 13 IE WG • Define Functions • Discuss Content and Operating Requirements • Discuss PCAST Report Jan 18 PD TF • Present Framework and Definitions of Users & Uses, Functions, Content, and Operating Requirements • Discuss Possible Business Models Jan 24 PD TF • Approve Business Model focus areas • Discuss Policy Issues and Actions Jan 28 IE WG • Approve Recommendation Feb 2 HITPC • Recommendations to HITPC on Individual level Provider Directories 21

Appendix 1 – Terminology 22

Terminology ELPD Recommendation: Basic Common Terminology • Provider Directory: • • Entity: • • • Authorized final end point organizational entities or their employees or proxy technical entities that generate and send directed exchanges. Receiver: • • 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: • • 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 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 23 table to determine the appropriate path and destination

Terminology ELPD Recommendation: Basic Common Terminology • Query/Retrieval: • • 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 process of requesting and obtaining access to health information. It also refers to the process of request and obtaining provider directory information 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 24 Sources: IHE Provider Directory Profile; HITSP Glossary; NIST Technical Documents

Appendix 2: High Level Principles for Provider Directory Discussions 25

Principles 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 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 26

Appendix 3 – ELPD Use Cases 27

Uses/Functional ity Scenarios and uses/value of ELPDs Scenarios Value 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. 28

Uses/Functional ity Scenarios and uses/value of ELPDs Scenarios Value 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. 29

Uses/Functional ity Scenarios and uses/value of ELPDs Scenarios Value 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. 30

Uses/Functional ity Scenarios and uses/value of ELPDs 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 Scenario: HIO to HIO routing • A regional HIO X needs to send clinical information to regional HIO Y Value of Entity-Level Directory • 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 • HIO X uses entity level directory to search for the organization’s ‘address’ of HIO Y 31