1. Draft Provider Directory Recommendations Begin Deliberations re Query for Patient Record NwHIN Power Team July 10, 2014

2. DRAFT Recommendations for Provider Directories 1.Based on our assessment of the functional requirements for querying provider directories, we know of no standards that are sufficiently mature and implementable to become a national standard. IHE's HPD+ profile is a good start, but needs to be proven within the marketplace. 2.We recommend that ONC encourage the exploration of other simple approaches for implementing the required functionality, such as working with CMS to harmonize its RESTful directory approach with FHIR. 3.We note that the federal government has already implemented a database of national provider identifiers (NPIs) and suggest exploring the possibility of providing the capability to capture Direct addresses within this database and making the information publically accessible through a service interface. 2

3. Tasks Assigned to NwHIN Power Team 3 StatusTaskBrief Description DRAFTProvider Directories Search for provider Respond to search Begin Today Query for a Patient Record Search for patient information Respond to searches for patient information AheadProvider Data Migration and Patient Portability 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)

4. Query for Patient Record Background In response to HITSC and public comment, original (RFC) recommendations regarding Query for Patient Record were simplified and generalized 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 Enabling provider directory functions within context of HITECH EHR certification authority and building on market developments in directed and query exchange 4

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

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

7. Clarifications from NwHIN Power Team Discussion with Micky Tripathi (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 7

8. Clarifications from NwHIN Power Team Discussion with Micky Tripathi (5/9/14) – 2 of 2 Search/respond for patient information Leverage Direct and Connect 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 CCDA (e.g., want to allow for FHIR response), but also recognize need to certify capability to return some minimal standardized content 8

9. Possible Options and Considerations 9 Connect – Current best for transactional query – Cumbersome and limited to documents – Network dependent – variations among implementations Direct – Asynchronous, variable response FHIR – Too immature for certification standard – Need to develop FHIR profiles Other considerations – Trust issues across networks – Impact of JASON and 10-year reports