Stage 3 Recommendations

Information Exchange Workgroup

May 9, 2014

Agenda

Background

Query exchange recommendations

Provider directory recommendations

Provider data migration and patient portability

Background

• IE WG had three issues in the HITPC Stage 3 Request for Comment– Query for Patient Record (102 comments)– Provider directory (EHR certification only) (62 comments)– Data portability (EHR certification only) (56 comments)

• The market is VERY dynamic and the landscape looks different than it did even when the RFC was released– The demand for cross-vendor query exchange appears to have grown with the rapid growth of ACOs

• Though some channels of query exchange are emerging in the market, such capabilities have generally not kept pace with demand

– Directed exchange as required for Stage 2 is starting to take shape• The role and function of HISPs is still murky, and lack of standards for provider directories and

security certificates appear to be an obstacle to more rapid progress– Industry projections suggest that 25-30% of physicians may change EHR systems in the near future,

making data portability an important issue– Demand for patient engagement is growing, as is entrepreneurial activity in this area

Agenda

Background

Query exchange recommendations

Provider directory recommendations

Provider data migration and patient portability

Query for Patient RecordBackground

• HITSC and public comments suggested that Query for Patient Record approach in RFC be simplified and generalized

– Complex set of back-and-forth transactions– Implied very specific user workflows

• Query exchange is occurring in parts of the market where there is 3rd party governance to address policy, legal, and technical complexities

– Examples include Healtheway and selected state-, regional-, and private-HIE activities– Single-vendor query exchange solutions are growing rapidly due to ability to eliminate technical

barriers and facilitate trust frameworks among separate legal entities

New recommendations focus on enabling query exchanges through existing HITECH authority and without separate authority to regulate HISPs, HIE organizations, or other third party actors

• Current recommendation focuses solely on enabling provider directory functions within context of HITECH EHR certification authority and building on market developments in directed and query exchange

Recommendation on Query for a Patient Record

• HITPC recommends:– Search for patient information: EHR systems have the ability to

electronically query external EHR systems for patient medical records– Respond to searches for patient information: EHR systems have the

ability to electronically respond to electronic queries for patient medical records from external EHR systems

Principles for Query Exchange

HITPC recommends that the following principles be used for establishing requirements and standards for query-based exchange:

1. Continuity: Build on Stage 1 and 2 approaches and infrastructure for directed exchange where possible, and allow use of organized HIE infrastructures where applicable and available

2. Simplification: Set goal of having query and response happen in a single (or minimal) set of transactions

3. Generalization: Accommodate flexibility in use cases, workflows, installed base capabilities, and legal/policy considerations

• e.g., allow clinical sources to have flexibility in how they respond to requests• e.g., remain flexible to legal and policy variation across legal entities and states

Principles for Query Exchange (continued)

4. Transactions

A. Querying systems must have the ability to:

1. Discover address and security credentials of clinical source*

2. Present authenticating credentials of requesting entity*

3. Present patient-identifying information*

4. Assert authorization for specific patient-level request*

5. Indicate type of information being requested (optional)

6. Securely transmit query message

7. Log requesting transaction

8. [Post-Query] Receive responding information

9. [Post-Query] Log transaction and disclosure*

B. Responding systems must have the ability to:

1. Validate authenticating credentials of requesting entity*

2. Match patient*

3. Assess robustness of authorization for specific patient-level request

4. Automate responses to requests based on robustness of authorization information presented by requestor (i.e., enable parameters to allow automation in certain circumstances determined by data-holder, such as requestor clinical setting (e.g., ED) or geography (e.g., within state))*

5. Check for and respond with patient record information or with indication that no patient record information will be sent in response to query*

6. Log transaction and disclosure

* Aligned with Privacy and Security Tiger Team recommendations already supported by HITPC

Principles for Query Exchange (continued)

5. Transaction details

A. Addressing, Access to Security Credentials, and Authentication

1. Standards should leverage (but not be restricted to) the considerable HISP policies and infrastructure being deployed to enable discoverability of addresses and security credentials for directed exchange

B. Authorization:

1. Variation in state- and organization-level policies suggests need to leave standard open to wide range of locally-determined authorization policies

2. EHR systems should capture a structured consent indicator, and include such indicator in query message when querying, and consume such indicator when being queried*

3. EHR systems should have ability to send and receive consent documents in query and responding messages

C. Patient-matching

1. Patient-identifying information and corresponding matching functions should be based on standardized demographic fields*

2. Data-holding entity should determine threshold of assurance needed to establish a match (could be facilitated by record locator function of organized HIE, if available and desired)*

* Aligned with Privacy and Security Tiger Team recommendations already supported by HITPC

Principles for Query Exchange (continued)

5. Transaction details (continued)

D. Response to request

1. Data-holders decide content and format of response according to their processes, policies, and technology capabilities

2. Data-holders assure that information in response is covered by authorization presented by requesting entity

3. Data-holders will respond to all queries, including an acknowledgement of non-fulfillment of request (e.g., “No information will be sent in response to this query”). Such acknowledgement of non-fulfillment should not divulge any information about the patient (such as whether the data-holding entity has any information about the patient)*

* Aligned with Privacy and Security Tiger Team recommendations already supported by HITPC

Agenda

Background

Query exchange recommendations

Provider directory recommendations

Provider data migration and patient portability

Provider DirectoriesBackground

Provider directories are a critical component of both directed and query exchange

Current lack of standards appears to be an obstacle to faster progress in Stage 2 directed exchange, and unless remedied, may impede Stage 3 query exchange as well

New recommendations reflect feedback from previous HITPC recommendations on PDs as well as IEWG observations on current and expected market trends

• Previous recommendation was not focused specifically on HITECH statutory and programmatic authority, and also was prior to Applicability Statement for Secure Health Transport (ie, Direct)

• Current recommendation focuses solely on enabling provider directory functions within context of HITECH EHR certification authority and building on market developments in directed and query exchange

• Does not assume separate authority to regulate HISPs, HIE organizations, or other third party market actors

• We note that our comments on CMS/ONC RFI on HIE highlighted opportunity to use existing CMS databases (NPPES, Meaningful Use) to catalyze market provide directory capabilities

Provider DirectoriesBackground

• At July HITPC, the provider directory recommendation was approved but the HITPC asked the Workgroup to revisit its principle on authentication

• In follow up WG conversation including S&I Framework staff, the Workgroup reaffirmed its recommendation to include the capability for authentication and further amended the recommendation to also require authentication of the provider directory-holding entity (ie, not just the requesting entity)

– Aligns with S&I approach which already included authentication of data source

– Important to include this protection to guard against spoofing of provider directories

• The recommendation is solely about the capabilities that certified EHR technology should have. The recommendation is not a policy requirement that authentication should be utilized.

• Including the capability in certification gives maximum flexibility implementers and policy makers.

– The provider directory market and use cases are still evolving

– We are seeing provider directory implementations utilize authentication in the market today, so making the ability to conduct mutual authentication assures that these capabilities will be available for those who choose to use them

Recommendation on Provider Directories

• HITPC recommends that:– Search for provider: EHR systems have the ability to query external

provider directories to discover and consume addressing and security credential information to support directed and query exchange

– Respond to search: EHR systems have the ability to expose a provider directory containing EPs and EH addressing and security credential information to queries from external systems to support directed and query exchange

Principles for Provider Directories

HITPC recommends that the following guidelines be used for establishing standards for provider directories:

1. Scope: Standards must address PD transactions (query and response) as well as minimum acceptable PD content to enable directed and query exchange

2. Continuity: Build on Stage 1 and 2 approaches and infrastructure for directed exchange where possible and allow use of organized HIE or cross-entity PD infrastructures where applicable and available (ie, remain agnostic to architecture and implementation approaches)

3. Simplification: Set goal of having PD query and response happen in a single (or minimal) set of transactions

4. External EHR system: An EHR system of another distinct legal entity, regardless of vendor

Principles for Provider Directories (continued)

5. Transactions:A. Querying systems must have ability to:

1. Present authenticating credentials of requesting entity

2. Validate authenticating credentials of provider directory holding entity

3. Present provider-identifying information

4. Securely transmit query message

B. Provider directory must have ability to:

1. Validate authenticating credentials of requesting entity

2. Present authenticating credentials to requesting entity

3. Match provider

4. Respond with unambiguous information necessary for message addressing and encryption or acknowledgement of non-fulfillment of request

C. Provider directories must have administrative capabilities to:

1. Submit updated provider directory information (additions, changes, deletions) to external provider directories

2. Receive and process provider directory updates from external provider directories

6. Transaction details:a. Provider directories should contain minimum amount of information necessary on EPs and EHs to

address and encrypt directed exchange and/or query for a patient record messages

b. Provider directories should contain minimum amount of information necessary on EPs and EHs to disambiguate multiple matches (i.e. same provider at different entities, providers with the same name, etc)

Agenda

Background

Query exchange recommendations

Provider directory recommendations

Provider data migration and patient portability

Background

• The Information Exchange Workgroup sees two use cases that need to be addressed to promote an efficient HIT marketplace and to support safe and effective care delivery

– Provider Data Migration: Provider switching from one or more EHR systems to another (or multiple systems)

– Patient Portability: Patient requesting the movement of their complete record (e.g. to a new PCP)

• Goal: To enable patients who switch providers to have their care continue seamlessly (no repeat tests, missing key clinical information etc). To enable providers switching EHR systems to continue providing seamless care to patients (coded data in old system is consumable by the new system so clinical decision support still works).

• The Information Exchange Workgroup recognizes significant work will need to occur to reach these goals and is recommending a multiple step path to get the community there. Patient portability and provider data migration are critical components of interoperability and creating an efficient and effective marketplace and today, we lack a clear plan and pathway for achieving these important goals.

Background (continued)

• We expect to see rising demand for data portability across vendor systems– This will happen purely as a function of a growing installed base– In addition, market surveys suggest that 20-30% of providers could switch

vendors in the next 2 years, suggesting that there is some urgency to the issue

• Currently the difficulty of data migration is a barrier to exit for providers who are switching vendors, and a barrier to continuity of care for patients who are switching providers– Ad hoc process that is highly variable and fraught with potential for errors and

lack of continuity in medical record completeness– Difficult to include in EHR contracts in a way that is operationally executable

when needed– Can be difficult or impossible to execute if vendor is not cooperative, system

has been highly customized, or if mismatch exists between source and receiving system capabilities

Background (continued)

• Data or information can be lost, rendered operationally inaccessible, stripped of context/meaning, or misplaced leading to erroneous context/meaning

– Safety – records attached to wrong patient, data placed in wrong fields, etc

– CQMs and CDS – loss of data important to measurement and decision support, such as look-back periods, exclusions, etc can cause disruption in performance improvement efforts

– Administrative – loss of data important to revenue cycle can cause disruption in revenues

Background (continued)

• A standard for data portability would set a common baseline for medical record continuity that will be vital as the EHR user base grows and matures, and the industry comes to increasingly rely on electronic medical records and MU-related EHR functions.

– A challenge will be that it is difficult to completely specify data migration requirements because needs may vary locally for a variety of reasons including record retention laws, provider/patient preferences, and provider documentation patterns

– The provider EHR migration use cases covers data and workflow needs beyond the core clinical record that may be required for continuity of business and clinical care. These additional items may require more analysis and potentially separate solutions.

– However, setting a floor will inspire greater market dynamism by lowering barriers to exit for providers and patients, and promote safety and continuity of care by reducing opportunities for errors

Recommendations

1. The HITPC recommends that the HIT Standards Committee, by Stage 3 of Meaningful Use, develop standards and technical specifications to address both the provider data migration and patient portability use cases (to include such cases as patient care, clinical quality metrics and clinical decision support).

a) The HITSC should determine the necessary elements of a core clinical record that will establish a first step on the path towards improved data portability for patients and providers.

b) The HITPC suggests the HIT Standards Committee explore the adoption of a core clinical record that is easily extractable and consumable by EHRs to support the provider data migration and patient portability use cases.

Recommendations

2. ONC should establish a long term path to move the industry towards a practical patient portability and provider data migration solution that addresses the key policy concerns identified by the HITPC. ONC should:

a) Investigate the current state of the field and create a needs assessment to lay the path for future standards work to reach this vision.

b) Explore policy levers in addition to certification that could help facilitate patient portability and provider data migration portability (i.e. ACO continuity of record requirements, legal medical record requirements, etc).

Backup

Anatomy of aQuery for a Patient Record

Data Requestor Data holderDiscover provider address and security credentialsSend:• Authenticating

credentials• Patient-identifying

information• Authorization for

request• Type of information

being requested (optional)

Receive:• Validate authentication

credentials• Match patient• Verify authorization for

request• Check for requested

information

Send:• Medical record information

or acknowledgment of non-fulfillment of request

• Log transaction

Receive:• Medical record

information or acknowledgment of non-fulfillment of request

• Log transaction

query

response

Anatomy of aProvider Directory Transaction

Data Requestor Provider DirectoryHolder

Receive:• Validate authentication

credentials• Match provider

Expose:• Provider addressing and

security credential information, or ability to further specify request as determined by PD, or acknowledgment of non-fulfillment of request

• Log transaction

Receive:• Requested information

or non-fulfillment message

• Log transaction

query

response

Send:• Authenticating

credentials• Provider-identifying

information

Discover relevant provider directory

Blank