1. JASON Report Task Force September 18, 2014 Micky Tripathi, co-chair David McCallie, co-chair

2. Updated Meeting Schedule MeetingsTask Wednesday, June 18 th 9:00-10:30am ET Review charges Identify action steps Tuesday, July 1 st 3:30-5:00pm ET Review discussion questions Listening session planning Thursday, July 31 st 2:00-5:00pm ET Listening session Tuesday, August 5 th 11:00am-12:30pm ET Listening session Tuesday, August 19 th 11:00am-12:30pm ET Listening session debrief Develop recommendations Tuesday, September 2 nd 11:00am-12:30pm ET draft recommendations Tuesday, September 3 rd -HITPC Draft recommendations to HITPC Wednesday, September 10 th -HITSC Draft recommendations to HITSC Tuesday, September 16 th 11:00am-12:30pm ET Refine recommendations Wednesday, October 1 st 11:00am-1:00pm ET Refine recommendations Wednesday, October 8 th 9:00-11:00am ET Finalize recommendations Wednesday, October 15 th – Joint HITPC/HITSC meeting Final recommendations 1

3. JTF – Work plan for remaining meetings Meeting 1 (16 Sep 2014) – Review comments/direction from HITPC & HITSC – Discussion definitions of “public API” and “orchestrated architecture” – Discussion on “fast track” approach to API standards Meeting 2 (19 Sep 2014) – Complete discussion of Public APIs and Key Architecture Principles – Discuss annotations for the JASON “architecture diagram” – Discuss Policy Questions Meeting 3 (1 Oct 2014) – Discuss “Privacy Bundles” – Review JASON-to-PCAST mapping – First review of final report Meeting 4 (8 Oct 2014) – Final review of final report 2

4. What is a Public API? (Updated) JASON repeatedly refers to a “public API” “Public” implies a mix of standards + governance These comments apply to a “Public API” to address interoperability in health care Proposed definition for implementation of a Public API – Shall support all required standard Core API & standard Core Profiles – Shall support public documentation for Core API and standard Core Profiles – May support custom API and/or custom Profile extensions If extended, the implementation shall follow the standard’s regular method for extensions Should support public documentation for custom API and/or custom Profile extensions – Shall enable access to and use of the API in a way consistent with API governance Rules of the Road / best practices – Should be validated against rigorous certification tests API certification tests should be managed by the standards entity that governs the Core standard – Should be accompanied by a vendor-supported “sandbox” that enables testing by external entities (with proper access) 3

5. Key Architectural Principles (Updated) Centralized coordination rather than top-down control Architectural patterns: – Loosely coupled, ReSTful Internet-style API (the Public API,) connecting heterogeneous systems – Tightly specified “on the wire” profiles for data elements, fitted to defined use-cases, – API will support discrete data + documents + adequate metadata – Support asynchronous upgrades (backward compatibility to allow for rolling upgrades) – Respect Postel’s principle (send conservatively; receive liberally) – Support use-case appropriate, standards-based authentication and authorization standards – Implemented with best practice encryption and key management Expose API for patient care, consumer access, and population/research – Reuse core data definitions as much as possible, but allow for necessary variations by domain of usage, since profiles and access patterns may vary – Data profiles and authorization strategies may vary by class of usage Expose API in support of “apps,” “modules,” and other mechanisms that encourage “pluggable” innovations Start simple, but anticipate emerging higher functions (follow the “Internet Hourglass” pattern.) Future cross-organization (“network”) orchestrated services could include: – Identity management (providers and patients, and other endpoints) – Authentication, authorization, key management – Consent and privacy preferences – Directories and data indexing services (supporting search) – Complex orchestration and transactions services (SOA) 4

6. Possible implementation building blocks (for discussion) We may decide that we don’t want to go this far with our Task Force recommendations, but we could at a minimum identify the key areas and propose that the HITSC make specific recommendations Key areas: – Base API – FHIR Document access – Initially continue static XCA/CCDA, with phase over to FHIR Data element access – FHIR – Base Profiles FHIR Profiles from Health Service Platform Consortium? Refocus Data Access Framework? New, deliverable- and timeline-focused, ONC-initiated collaboration or contracting? – Auth/Auth – use case specific Consumer access via tethered portal – OAuth2/OIDC (i.e., updated Blue Button Pull) Remote access into EHR – Network-specific choices (OAuth?) – Semantics Use FHIR Profiles for initial phases National Value Set repository (NLM) for core profiles – Modularity SMART on FHIR for EHR modules TBD for SOA modules – Population health data Consider FHIR Bundles, FHIR pub-sub? – Other areas? 5

7. “Population” level data FHIR Decision support FHIR Key and Certificate Management Patient - Provider Relationships Patient Preference Management Patient & Provider Identity, Authentication, Authorization, Demographics JASON Example Architecture (With proposed mapping to standards) User Interface and Middleware Apps OAuth2/OIDC (e.g. SMART) “Push” Services FHIR Semantics and Language Translation FHIR Profiles “Clinical docs” XCA  FHIR “Atomic” & metadata FHIR Crypto Layer (leverage existing approaches) Data Storage (logical) Data Storage (physical) Data Transport (logical) Data Transport (physical) Core Clinical and Financial Systems Public API Key Network & Governance Issues ValueSet & Metadata Standards & Services Search and Index Functionality XCA  FHIR 6

8. Key Policy Questions Who governs the establishment and maintenance of specifications of the Public API? – Scope and specs of “core” API and profiles – Staging of expansion of core – Monitoring and compliance What should be the first “Public API” use-cases? – EHR to EHR/HIE interchange? (e.g. eHealthExchange, CommonWell, etc.) – Consumer access via Portal (e.g., Blue Button Pull) – Pluggable apps? (e.g., SMART, etc.) – EHR to Population Health and Researchers? Role of markets vs. government in reducing “barriers to legitimate data flow?” – Should (vendor) certification (CEHRT) of public API be required, voluntary, or neither? – Should HCO grants of external access to their implementation of the public API be mandated? If so, under what conditions? (Trust, certification, license, cost…) If so, how? Incentives? Governance? Other levers? What constitutes a “network” around use of these APIs? – Assuming there is more than one network, should network-to-network bridging be required or voluntary? – How to coordinate cross-organization (network) services? – What should be required within networks? How to motivate the creation of a market ecosystem to support loosely coupled approach? – How can we leverage “lessons learned” from Direct/HISP, eHealthExchange, CommonWell, Carequality, etc? 7

9. Blank