N wHIN Power Team

1. NwHIN Power Team Recommendations re Query for Patient Record August 28, 2014

2. Query for Patient RecordBackground • Enable query functions within context of HITECH EHR certification authority* and building on market developments in directed and query exchange *i.e., without requiring separate authority to regulate HISPs, HIE organizations, or other third-party actors

3. HIT Policy Committee Recommendation on Query for Patient Record • Search for patient information: Certified EHR systems have the ability to electronically query external EHR systems for patient medical records • Respond to searches for patient information: Certified EHR systems have the ability to electronically respond to electronic queries for patient medical records from external EHR systems

4. Clarifications from NwHIN Power Team Discussion with MickyTripathi (5/9/14) – 1 of 2 • To have any impact in the market, must have query capability in Stage 3 – objective is to enable query exchange, not to dictate “how” • EHR system should be able to delegate query capability to third party (e.g., HIE service provider) • “Query” need not be synchronous – synchronous query should be treated as desirada (“wish list”) – Stage 3 requirement should be set of functional requirements, not specific set of transactions in a specific order • No presumptions regarding orchestration

5. Clarifications from NwHIN Power Team Discussion with MickyTripathi (5/9/14) – 2 of 2 • Search/respond for patient information • Leverage existing standards such as Direct and IHE XCA where possible • Responsibilities for providing identifying information (patient matching) vs. clinical information (record) could be assigned to different organizations • Standards for content is open question • Don’t want to restrict to Consolidated CDA (e.g., want to allow for FHIR response), but also recognize need to certify capability to return some minimal standardized content

6. Query Options Considered for 2017 Edition(1 of 2) • Data Access Framework (DAF) S&I Framework project • Currently in development • Defined focus is too broad for 2017 timeframe – our focus needs to consider only the “remote system query for data” use case • Inadequate vendor support for emerging recommendations • Complex – requires support for both SOAP-based and REST-based query responses • IHE Cross Community Access (XCA) Profile • Document-oriented profile that uses document metadata • Cumbersome and limited to documents (which have not been well received by providers, due to cumbersome process of extracting structured data) • Network dependent – incompatible variations among implementations

7. Query Options Considered for 2017 Edition(2 of 2) • Direct • Asynchronous, no guarantee of a response • Responses limited to document attachments and text • HL7 Fast Healthcare Interoperability Resources (FHIR) • High promise, but not yet a finalized standard • Need to develop FHIR profiles

8. Query Options for 2017 Edition – Challenges • Use of Consolidated Clinical Document Architecture (C-CDA) for query • C-CDA specification needs further content coding and constraint standardization for interoperability • Transitions-of-care documents are large and cumbersome – need for template for concise, 1-2 page snapshot summary of patient state • Need more widespread support for other, simpler kinds of human-readable documents besides C-CDA (e.g., discharge summary) • Issues relating to consistent wrapping of C-CDA documents as Direct attachments • Other considerations • Trust issues across networks; certificate discovery • No standard for patient identity discovery and validation • No standard for record-locator services • Impact of JASON and ONC Roadmap initiative

9. Recommended Guiding Principles • Limit scope of use cases to: • Query a named external health care organization (HCO) for document containing a specific patient’s data • Return requested document in response to query • Address both synchronous (XCA) and asynchronous (Direct) queries • By 2017 Edition, address high-priority challenges relating to query for structured documents • Keep in mind longer term objectives of enabling query for discrete data elements, and eliminating need for EHRs to support multiple transport stacks for query/response

10. Recommended Functional Capabilities for 2017 Edition • Certified EHR technology will have the capability to: • Generateand address to a trusted and known, external end point: • A query requesting a document containing current summary clinical data for a named patient • The identifier for a document selected from a list provided by an external provider • In response to a query from an external provider: • Return a list of available documents that contain the requested information • Return a structured, encoded document containing the requested clinical information • Return a response indicating that the requested data are unavailable

11. Recommendations for EHR Technology Certification (1 of 3) • In the near term, support fast-tracking of improvements to Consolidated CDA Implementation Guide, as recommended by the Implementation Working Group and approved by the HITSC on August 20, 2014

12. Recommendations for EHR Technology Certification (2 of 3) • Improvements needed to facilitate query for and selective retrieval of C-CDA documents, recommend developing implementation guidance for: • Standardizing LOINC codes and Document Metadata for ambiguous attributes such as type-code, mime type, format code, and class code • Defining and associating standard LOINC codes for various types of C-CDA documents for “on demand” retrieval, such as full history (problems, allergies/intolerances, medications, labs, etc.); latest encounter summary; summary of active and pertinent information • Creating, identifying, and retrieving a C-CDA document containing a standard header plus “wrapped” content (e.g., PDF document, text) as a least-preferred alternative for exchanging health information

13. Recommendations for EHR Technology Certification (3 of 3) • Seek multi-vendor inputs to clarify high-priority improvements (e.g., profiling, implementation guidance) needed to standardize XCA query (e.g., defining and associating metadata parameters for typical queries, such as radiology reports, discharge summaries) • Support efforts to accelerate development of FHIR-based services and FHIR profiles • Query/response for named patient’s data as available documents or core discrete data elements • Define simplified subset of FHIR profiles for core elements such as problems, meds, etc. • Define FHIR profiles that align with the IHE Mobile Access to Health Documents (MHD) and core CDA elements (DAF work as a starting point)

14. Significant Barriers Remaining • Standardization of transport and data elements for query is not sufficient – potential public-private collaboration will likely be needed to resolve such key challenges as trust, patient identity, and record locator services • Adding certifiable functional capability is necessary but not sufficient for widespread interoperability – need implementation guidance and worked examples along with emerging market-facing networks