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

2. Task Force Members Member NameOrganizationRole David McCallieCernerChair Micky TripathiMassachusetts eHealth CollaborativeChair Deven McGrawManattMember Gayle HarrellFlorida State LegislatorMember Larry WolfKindred HealthcareMember Troy SeagondollarKaiserMember Andy WiesenthalDeloitteMember Arien MalecRelayHealthMember Keith FiglioliPremier, Inc.Member Wes RishelMember Larry GarberReliant Medical GroupMember Josh MandelChildren's Hospital BostonMember Landen BainCDISCMember Nancy J. OrvisFHA/DoDEx Officio Tracy MeyerFHA/ONCEx Officio Jon WhiteHHSEx Officio 1

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) 2

4. 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 Refine recommendations Friday, September 19 th 1:00-3:00pm 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 3

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 4

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?) 9/16/20145 *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 9/16/20146 *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 9/16/20147 *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? 8 *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/16/2014

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 99/16/2014

11. What is a Public API? JASON repeatedly refers to a “public API” “Public” implies a mix of standards + governance 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 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) 109/16/2014

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) 119/16/2014

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

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? 139/16/2014

15. Appendix Materials presented to HITPC and HITSC 149/16/2014

16. Blank