JASON Report Task Force

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

2. Task Force Members

3. Charge • Analyze and synthesize feedback on the JASON report • Discuss the implications of the report and its impact on HHS, other Federal agencies and their strategies • Assess the feasibility and impact of the JASON report on HHS and the broader HIT ecosystem • Identify use cases and lessons learned from current experience • Establish specific recommendations that can be integrated into the Federal Health IT Strategic Plan and the ONC interoperability roadmap • Provide a high-level mapping of the PCAST 2010 report with the JASON report (added subsequent to initial charge)

4. Updated Meeting Schedule

5. 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) • Discuss “Privacy Bundles” • Discuss annotations for the JASON “architecture diagram” • Meeting 3 (1 Oct 2014) • Refine JASON-to-PCAST mapping • First review of final report • Meeting 4 (8 Oct 2014) • Final review of final report

6. HITPC Discussion* In general, the preliminary report was very well received by both HITPC and HITSC. • Probst: • Skeptical of industry’s ability to adopt JASON without government “push” • Need better definition of “loosely coupled” • Egerman: • Compare and contrast to PCAST report. Adopt the good stuff. • What is the governance? What is the enforcement? (from Governance presentation) • Kotes • Do we need new regulatory protections for the consumer’s copy of PHI? (FTC vs OCR vs ??) • Critical need to establish “trustworthy” apps for consumers (and providers) – prevent rogue use of APIs • Cullen • Questioned whether vendors could be trusted to do this on their own. • Clarify “open” vs. “public” API – does public imply automatic access rights? • Not likely to see this in time for MU3 – too busy with other work • Lansky: • Please address the other levers beyond MU3 • Why were quality measures not mentioned? We need to make CQM more nimble and flexible, versus hard-coded approach today (JASON as CQM Query tool?) *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

7. HITPC Discussion*, continued • Bechtel • consumers vs. researchers – how to enable “meaningful choice” on data use. This technology enables more than our policies can accommodate • Patterson: • Don’t ignore the national patient identifier issues! • Remember the core use-case: Eliminate the “bags of records” that we have to carry from MD to MD • Please ensure that “inter-operability” is the target, not just “intra-operability” • MU3 is the “last train” that leaves with funding attached. Get as much on board as possible • Kennedy • What’s different this time (from PCAST?) • The new economic drivers are still very immature • Don’t forget about documents and the patient’s narrative. Physicians must be able to capture the story. • Harriman • Need more discussion about the privacy implications • privacy bundles imply lots more metadata – where will that come from? • What is the governance around API usage? Who controls? Access rights? Authorization? • DeSalvo • Increasing consumer expectation for data access and rights • Powerful new business drivers for interoperability • Digitization of the raw data is nearing completion – now is time for better flow • The notion of an “open” API will pose new governance and policy challenges *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

8. HITSC Discussion* (Combining discussion - Power Team “query” recommendation & JASON report) • Reider: • Do these proposals leave “too much optionality” for interop to emerge? • What is the right “regulatory cadence” to accommodate these emerging technologies? • What is the right role for government in this? • Need to define a set of principles and a “timeline” that moves to FHIR • Huff: • Don’t forget that coordination of FHIR Profiles is required in addition to standard API. What mechanisms can ensure that we have consensus there as well? • Ross: • What about support for “population” based services? • Halamka: • We need a mechanism to fast-track a simple subset of FHIR in time for 2017 Edition • Ferguson: • Don’t underestimate the success of current XCA+CCDA approaches. • Must support XCA during transition to FHIR • Please stay aligned with the S&I DAF • Should support DAF-like population-style query as well *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

9. HITSC Discussion*, continued (Combining discussion around Power Team “query” recommendation and JASON report) • Lemaitre • Our role is to push FHIR forward (??) • L Harris: • How can these tools be used to capture patient-generated data? • Capture “patient push” and device data • Don’t worry about “rip and replace” – you have to plan for it • Rose • Concerned about vendor-proprietary (query) solutions – suggest requiring publishing of internal API or requiring that networks be open • ???? • What do they mean by “uber architecture” • What do they mean by “migration to new platforms? • Were they addressing data persistence or data flows? • S Terry • Please stay coordinated with PCORNet, especially around governance for research use, and the implementation of privacy bundles. • Consumers are more sophisticated around privacy now • Reider • Is it possible to produce a reduced-subset of FHIR in time for 2017 Edition, and if so, does the market have the “will” to get it done? *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

10. HITPC + HITSC – Major Themes • Agreement to move forward to more powerful, data+ documents API • The debate is about the speed and timing of the cross over to newer standards • Debate also about what can be done in context of MU3/2017E • Consider a focused, fast-track implementation around FHIR, constrained CCDA, and core use-cases • Agreement that “orchestration” of architectures is more feasible than “top down” control • Focus on loosely-coupled APIs + robust data element profiles to ensure semantic interchange • Assume heterogeneity among implementations • Some services may require higher degrees of centralization (identity, authorization, consent) • Mostly agreed that market forces should be leveraged as much as possible • New business drivers are forcing new levels of interoperability faster than MU stages • Regulatory approaches must be light, nimble • Incentives should target inter-operability, not just intra-operability • Monitor for undesired barriers that inhibit interoperability?? • Agreement that “public APIs” introduce new governance/ecosystem questions • Access, trust, authorization, data use, certification, etc • Need to consider consumer and population health/research use cases as well • Agreement that privacy policies must keep pace with technology advances

11. What is a Public API? • JASON repeatedly refers to a “public API” • “Public” implies a mix of standards + governance • Proposed definition for implementationof 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 • Should support public documentation for custom API and/or custom Profile extensions • Should 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)

12. Key Architectural Principles • Centralized coordination rather than top-down control • Architectural patterns: • Loosely coupled, ReSTful 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 • Implemented with best practice encryption and key management • Respect Postel’s principle (send conservatively; receive liberally) • Expose API for patient care, consumer access, and population/research • 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) • Authentication, authorization, key management • Consent and privacy preferences • Directories and data indexing services (supporting search) • Complex orchestration and transactions services (SOA)

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

14. 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 • Role of markets vs government in reducing barriers to legitimate data flow? • Should implementation of public API be “required” via CEHRT certification, or voluntary? • Should external access to the public API be mandated? • If so, under what conditions? (Trust, certification, license, cost…) • What constitutes a “network” around use of these API? • Assuming there is more than one network, should network-to-network bridging be required or voluntary? • How to coordinate cross-organization (network) services? • How to motivate the creation of a market ecosystem to support loosely coupled approach? • How can we leverage lessons learned from Direct/HISP experience, and other early network-building efforts?

15. Appendix • Materials presented to HITPC and HITSC

16. Blank