hit policy committee information exchange workgroup provider directory task force micky tripathi, ma...

HIT Policy CommitteeHIT Policy CommitteeInformation Exchange WorkgroupInformation Exchange WorkgroupProvider Directory Task ForceProvider 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

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

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

IE Workgroup Membership

Name Affiliation

Hunt Blair Vermont Medicaid

Jim Buehler CDC

Connie W. DelaneyUniversity of Minnesota, Nursing

Paul Egerman

Judy Faulkner Epic

Seth Foldy CDC

Donna Frescatore NY Medicaid

Jonah Frohlich Manatt Health Solutions

Dave GoetzDept. of Finance and Administration, TN

James GoldenMinnesota Department of Health

Gayle Harrell

4

Name Affiliation

Dianne HasselmanCenter for Health Care Strategies

George Hripcsak Columbia University

Jessica Kahn CMS

Charles Kennedy WellPoint, Inc.

Michael KlagJohns Hopkins School of Public Health

Deven McGrawCenter for Democracy & Technology

George Oestreich Missouri Medicaid

David A. RossPublic Health Informatics Institute

Steven Stack American Medical Association

Walter Suarez Kaiser Permanente

Latanya Sweeney Carnegie Mellon University

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

5

Provider Directory Task ForcePolicy 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

6

Name Affiliation

Hunt BlairSorin DavisPaul EgermanJudy FaulknerSeth FoldyDave GoetzJames Golden.Keith HeppJessica KahnJP Little George OestreichLisa RobinSteven StackSid Thornton

Vermont MedicaidCAQH

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

Co-Chair: Jonah Frohlich, Manatt Health SolutionsCo-Chair: Walter Suarez, Kaiser Permanente

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)

Provider Directories - Where are we in the process?

Users and Uses

Functions ContentOperating

rqmtsBusiness 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

Entity-Level Provider Directories (ELPDs)

9

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

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)


Content

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)


Operating Rqrmts. /

Business Model

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)

Policy Options

Business Model recommendation to HITPC 11/19

Potential Government Roles/Policy Levers

Infrastructure Maintaining 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

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


• 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


• 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

Users and Uses

Functions ContentOperating

rqmtsBusiness 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 Options Recommendations

Environmental scan and business analysis

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

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

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

Appendix 2: High Level Principles for Provider Directory Discussions

25

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

Appendix 3 – ELPD Use Cases

27

Scenarios and uses/value of ELPDs

28

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.

Uses/Functionality

29


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



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)





Uses/Functionality

30


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




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.


Uses/Functionality

31


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


Uses/Functionality