Information Exchange Workgroup

1. Information Exchange Workgroup Stage 3 Recommendations May 9, 2014

2. Agenda Background Query exchange recommendations Provider directory recommendations Provider data migration and patient portability

3. 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

4. Agenda Background Query exchange recommendations Provider directory recommendations Provider data migration and patient portability

5. 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

6. 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

7. Principles for Query Exchange HITPC recommends that the following principles be used for establishing requirements and standards for query-based exchange: • 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 • Simplification: Set goal of having query and response happen in a single (or minimal) set of transactions • 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

8. Principles for Query Exchange (continued) • Transactions • Querying systems must have the ability to: • Discover address and security credentials of clinical source* • Present authenticating credentials of requesting entity* • Present patient-identifying information* • Assert authorization for specific patient-level request* • Indicate type of information being requested (optional) • Securely transmit query message • Log requesting transaction • [Post-Query] Receive responding information • [Post-Query] Log transaction and disclosure* • Responding systems must have the ability to: • Validate authenticating credentials of requesting entity* • Match patient* • Assess robustness of authorization for specific patient-level request • 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))* • Check for and respond with patient record information or with indication that no patient record information will be sent in response to query* • Log transaction and disclosure * Aligned with Privacy and Security Tiger Team recommendations already supported by HITPC

9. Principles for Query Exchange (continued) • Transaction details • Addressing, Access to Security Credentials, and Authentication • 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 • Authorization: • Variation in state- and organization-level policies suggests need to leave standard open to wide range of locally-determined authorization policies • EHR systems should capture a structured consent indicator, and include such indicator in query message when querying, and consume such indicator when being queried* • EHR systems should have ability to send and receive consent documents in query and responding messages • Patient-matching • Patient-identifying information and corresponding matching functions should be based on standardized demographic fields* • 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

10. Principles for Query Exchange (continued) • Transaction details (continued) • Response to request • Data-holders decide content and format of response according to their processes, policies, and technology capabilities • Data-holders assure that information in response is covered by authorization presented by requesting entity • 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

11. Agenda Background Query exchange recommendations Provider directory recommendations Provider data migration and patient portability

12. 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

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

14. 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

15. Principles for Provider Directories HITPC recommends that the following guidelines be used for establishing standards for provider directories: • Scope: Standards must address PD transactions (query and response) as well as minimum acceptable PD content to enable directed and query exchange • 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) • Simplification: Set goal of having PD query and response happen in a single (or minimal) set of transactions • External EHR system: An EHR system of another distinct legal entity, regardless of vendor

16. Principles for Provider Directories (continued) • Transactions: • Querying systems must have ability to: • Present authenticating credentials of requesting entity • Validate authenticating credentials of provider directory holding entity • Present provider-identifying information • Securely transmit query message • Provider directory must have ability to: • Validate authenticating credentials of requesting entity • Present authenticating credentials to requesting entity • Match provider • Respond with unambiguous information necessary for message addressing and encryption or acknowledgement of non-fulfillment of request • Provider directories must have administrative capabilities to: • Submit updated provider directory information (additions, changes, deletions) to external provider directories • Receive and process provider directory updates from external provider directories • Transaction details: • 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 • 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)

17. Agenda Background Query exchange recommendations Provider directory recommendations Provider data migration and patient portability

18. 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.

19. 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

20. 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

21. 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

22. Recommendations • 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). • 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. • 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.

23. Recommendations • 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: • Investigate the current state of the field and create a needs assessment to lay the path for future standards work to reach this vision. • 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).

24. Backup

25. Anatomy of aQuery for a Patient Record Data Requestor Data holder • Discover provider address and security credentials • Send: • 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 query • Receive: • Medical record information or acknowledgment of non-fulfillment of request • Log transaction • Send: • Medical record information or acknowledgment of non-fulfillment of request • Log transaction response

26. Anatomy of aProvider Directory Transaction Data Requestor Provider Directory Holder • Discover relevant provider directory • Send: • Authenticating credentials • Provider-identifying information • Receive: • Validate authentication credentials • Match provider query • 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 response

27. Blank