1. JASON Report Task Force August 19, 2014 David McCallie, co-chair Micky Tripathi, co-chair

2. Agenda Taskforce membership update Listening Session Debrief Recommendation framework Discussion 1

3. 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 2

4. 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 3

5. 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 Finalize draft recommendations Wednesday, September 3 rd - HITPC Draft recommendations to HITPC Tuesday, September 9 th 1:00-3:00pm ET Refine recommendations Tuesday, September 16 th 11:00am-12:30pm ET Refine recommendations Wednesday, September 17 th -HITSC Draft recommendations to HITSC Friday, September 19 th 1:00-3:00pm ET Refine recommendations Wednesday, October 1 st 11:00am-1:00pm ET Refine recommendations Monday, October 8 th 9:00-11:00am ET Finalize recommendations Wednesday, October 15 th – Joint HITPC/HITSC meeting Final recommendations 4

6. Listening Session Summary 5

7. Overview Many reactions point out that the JASON report underestimates progress being made in sharing discrete patient data. (Beyond “digital fax machine.”) Many felt that while the vision of discrete data APIs was a reasonable path the necessary standards are not ready, and the time frame proposed by the JASONS was too fast. Several panelists recommended incrementally improving upon current CDA document-centric standards Many panelists felt the implementation timelines in the JASON Report were not realistic and felt 6-10 years was a more reasonable timeline for a complete shift to discrete data API (e.g. FHIR). Many panelists thought focus on discrete APIs would advance interoperability. Numerous panelists considered FHIR to be the likely emerging candidate, though other options exist. A majority of opinions felt that FHIR itself, and implementation by vendors, would not be possible under current 2017 Edition timetable. Technical architecture alone will not enable seamless exchange of health information the policy, business and legal aspects of exchange need to be addressed in tandem. Building a “network” will be as challenging as implementing standard APIs over “stovepipe” legacy EHRs. – Business incentives for exchange need to be aligned. No elegant architecture will overcome an economic disincentive to share patient data. – Governance is key, need to take the time to get it right. 6

8. Detailed Summary APIs Many stakeholders thought additional focus on standards-based, discrete data APIs could be helpful to advance interoperability. But other stakeholders had varying opinions of the role of APIs in solving interoperability issues: – JASON like platforms and their robust APIs misdirect us down a maze of tightly coupled integrations that are costly, fragile and brittle, not at all based on the loosely coupled data exchanges [Who said this?] – Specific API requirements as part of ONC certification are neither realistic nor necessary; the growing industry adoption of standards-based API work such as FHIR, if focused on high- value use cases, is the more appropriate and sustainable path to accelerated use of APIs across the industry. There were differing opinions among app developers on the need to standardize EHR APIs. Some app developers felt with it was important to have standard APIs across EHR vendors. Other app developers felt it wasn’t necessary to standardize vendor APIs if EHR vendors were required to create APIs that were well documented and could read and write information. Examples of industries where multiple APIs exist were cited. Several EHR Vendors pointed out that they already expose (proprietary) discrete data APIs, and have many third-party users of their APIs. Current API approaches are either document-centric (XDS, XCA) or discrete-data centric (FHIR, OpenEHR.) Numerous groups are working on developing FHIR and FHIR Profiles, including S&I’s DAF, SMART Platform, HSPC, and IHE.) Document-centric APIs were de-valued by the JASONS, but several panelists pointed out that CCDA documents typically include embedded discrete data elements. The existence of a “public” API does not automatically imply that any entity has a right to use the API. Additional licensing, certification, and business arrangements (among other steps) are usually required before access to the API is granted to third parties. 7

9. Detailed Summary APIs (continued) Suggested artifacts necessary for a public API: – Complete documentation (Developer Resources) for each level of the API – Ideally, a “test bed” will accompany the API where the API can be tested, in a non---destructive manner, without exposing any patient identifying information. – Many public APIs will also include sample applications that provide a framework for proper use of the API. – Support mechanisms to assist developers in resolving issues – Licensing mechanisms to promote adoption and deployment to a client base. – Ability to communicate when a change to the API will be made There was sparse discussion of the JASON’s recommendations about cryptography, metadata translation, and indexing services. Some panelists pointed to the need for a National Patient Identifier or equivalent national scale MPI service (including linked patient consent tracking) in order to realize the full JASON vision. There was relatively little discussion of the JASON’s “privacy bundle” concept. Timeline Panelists had differing opinions on if the timing of including an API requirement in Meaningful Use Stage 3 was achievable. Many panelists felt that the timelines outlined in the JASON Report were not achievable. The transformation discussed would take more on the order of 6-10 years for the ecosystem to fully implement and operationalize the entire JASON architecture. 8

10. Detailed Summary Standards: Current and Future: A number of panelists felt that while the vision in the JASON Report was a reasonable path it would be difficult to implement and that more would be gained through following an approach of incrementally improving upon the standards/infrastructure in existence today. Many sources have described the problems with currently deployed C-CDA and its implementations – However, several of our panelists believed that C-CDA usage was getting better over time and has significant value for a variety of use cases. There was agreement that improvements to C-CDA should be made as quickly as possible (MU2 issues) Patient identify management came up repeatedly as a central problem that will have to be better addressed to achieve the vision outlined in JASON or any other approach to improving interoperability. FHIR was viewed by panelists as the most likely path towards the JASON vision though many felt FHIR would not be ready in time for inclusion in Stage 3 of Meaningful Use. One specific example of necessary work to be completed was the development the ability to query for a “complete” patient record. Some panelists raised concerns that the JASON Report didn’t focus sufficient attention to the challenges around semantic translation though the FHIR testimony described how FHIR Profiles could alleviate most of the need for semantic translation services. 9

11. Detailed Summary Patient controlled data use Patient at the center may make it easier to manage some aspects of exchange of health information– including some types of secondary use. – Methods for patients to directly control who has access to their data – Methods for patients to contribute to, view, and when necessary correct their data – Mechanisms for patients to authorize the use of their data for research – Of note, the JASONs have updated their original notion that patients “own” their data, and have acknowledged that patients “participate in the management” of their data. – There is confusion about rights associated with primary clinical data versus the copy that patients have a right to obtain. The research community has a different set of data and standards needs versus providing clinical care. The research community has its own set of standards development organizations and while at times leverage standards utilized for clinical care (such as the C- CDA) they also have other unique needs not covered by standards/infrastructure development for clinical care purposes. 10

12. Recommendation Framework JASON charge JASON scope JASON findings JASON architecture core principles JASON recommendations 11

13. JASON charge 12 How can complex data handling techniques and Internet-based technologies be applied to health care to promote the development of real-time integrated datasets at a scale seen in other industries? How can the various users of health data in the clinical research and public health communities be presented with tailored and highly specific data views in near real time based on routinely collected health data? As health data grows from megabits to gigabits per individual, what fine-grained analytics should be made available to patients and health care providers to guide health care decisions? What fundamental data management capabilities are needed to support potential future requirements in an open-ended manner? What are the national security consequences of not addressing comprehensive health data opportunities in clinical research and public health?

14. Key Challenges identified by JASONs Federation Jurisdiction Scalability User interface Interdisciplinary Front loaded cost Payer Business Model Exchange concept Data security Data integrity Access and curation Consent Intellectual property Legal liability 13

15. JASON Architecture: core principles (Main Focus of the Task Force in red) The patient owns his or her data The patient participates in the management of his or her data Be agnostic as to the type, scale, platform, and storage location of the data Use published APIs and open standards, interfaces and protocols Encrypt data at rest and in transit Separate key management from data management Include metadata, context, and provenance of the data Represent the data as atomic data with associated metadata Follow the robustness principle: “Be liberal in what you accept, and conservative in what you send.” Provides a migration path from legacy EHR systems 14

16. JASON Findings (1) #JASON Key FindingJTF notes 1The current lack of interoperability among data resources for EHRs is a major impediment to the unencumbered exchange of health information and the development of a robust health data infrastructure. Interoperability issues can be resolved only by establishing a comprehensive, transparent, and overarching software architecture for health information. (Section 2.4) 2The twin goals of improved health care and lowered health care costs will be realized only if health-related data can be explored and exploited in the public interest, for both clinical practice and biomedical research. That will require implementing technical solutions that both protect patient privacy and enable data integration across patients. (Section 2.4) Numerous JASON recommendations would require statutory changes to existing privacy laws. Changes to HIPAA de-identification laws Changes to Common Rule (Research) 3The criteria for Stage 1 and Stage 2 Meaningful Use, while surpassing the 2013 goals set forth by HHS for EHR adoption, fall short of achieving meaningful use in any practical sense. At present, large-scale interoperability amounts to little more than replacing fax machines with the electronic delivery of page-formatted medical records. Most patients still cannot gain electronic access to their health information. Rational access to EHRs for clinical care and biomedical research does not exist outside the boundaries of individual organizations. (Section 3.2) We believe this seriously underestimates the progress made recently via MU1 and MU2, though we agree that there is a long way to go 15

17. JASON Findings (2) #JASON Key FindingJTF notes 4Although current efforts to define standards for EHRs and to certify HIT systems are useful, they lack a unifying software architecture to support broad interoperability. Interoperability is best achieved through the development of a comprehensive, open architecture. (Section 5.1) Agree, though there is some uncertainty as to what “open” means. 5Current approaches for structuring EHRs and achieving interoperability have largely failed to open up new opportunities for entrepreneurship and innovation that can lead to products and services that enhance health care provider workflow and strengthen the connection between the patient and the health care system, thus impeding progress toward improved health outcomes. (Section 5.1) Agree that the industry should do better, but there are many third-party companies that have managed to create functioning discrete data interfaces to existing EHR products 6HHS has the opportunity to drive adoption and interoperability of electronic health records by defining successive stages of Meaningful Use criteria that move progressively from the current closed box systems to an open software architecture. (Section 5.2) We agree that existing products should adopt and expose standards-based APIs. However EHR implementations themselves do not need to be “open source” software. 7The biomedical research community will be a major consumer of data from an interoperable health data infrastructure. At present, access to health data is mostly limited to proprietary datasets of selected patients. Broad access to health data for research purposes is essential to realizing the long-term benefits of a robust health data infrastructure. (Section 6.2) 16

18. JASON Findings (3) #JASON Key FindingJTF notes 8The data contained in EHRs will increase tremendously, both in volume and in the diversity of input sources. It will include genomic and other “omic” data, self-reported data from embedded and wireless sensors, and data gleaned from open sources. Some types of personal health data, especially when combined, will make it possible to decipher the identity of the individual, even when the data are stripped of explicit identifying information, thus raising challenges for maintaining patient privacy. (Section 6.3) Agree that new data types will emerge the require new technical approaches. Agree that privacy challenges of “big data” may require modifications to current privacy laws (e.g., de- identification, penalties for attempted re-identification, etc.) See the recent PCAST report for more details. 9The US population is highly diverse, reflecting much of the diversity of the global population. Therefore, important research findings applicable to Americans are likely to come from shared access to international health data. Currently there is no coherent mechanism for accessing such data for research. (Section 6.4) Agree, though reaching international agreement should not be an excuse to slow progress towards JASON vision. 10Electronic access to health data will make it easier to identify fraudulent activity, but at present there is little effort to do so using EHRs. (Section 6.5) 17

19. JASON Recommendations (1) #JASON RecommendationJTF notes 1CMS should embrace Stage 3 Meaningful Use as an opportunity to break free from the status quo and embark upon the creation of a truly interoperable health data infrastructure. (Section 3.2) MU Stage 3 is one lever, but due to the declining incentive structure is unlikely to be influential enough to effect such a large-scale change 2An immediate goal, to be sought within 12 months (including time for consultation with stakeholders), should be for ONC to define an overarching software architecture for the health data infrastructure. (Section 5.1) Timeframe is quite challenging given the scale of the task and the complexity of gaining consensus “Single architecture” versus heterogeneous architecture – need to clarify definitions 2.1The architecture should provide a logical organization of functions that allow interoperability, protect patient privacy, and facilitate access for clinical care and biomedical research. JASON has provided an example of what such an architecture might look like. Comments on diagram 2.2The architecture should identify the small set of necessary interfaces between functions, recognizing that the purpose of a software architecture is to provide structure, while avoiding having “everything talking to everything.” Agree that thoughtful API design, using proven, standards-based APIs can be used to maintain a loosely- coupled architecture 2.3The architecture should be defined, but not necessarily implemented, within the 12 month period. During that time, ONC should create (or redirect) appropriate committees to carry out, continuing beyond the 12 month horizon, the detailed development of requirements for the functions and interfaces that comprise the architecture. See comment to #2 above Options to consider: Fast-track a subset of the architecture Delay MU3 Certification Encourage private industry to drive, outside of initial regulation 18

20. JASON Recommendations (2) #JASON recommendationJTF notes 3To achieve the goal of improving health outcomes, Stage 3 Meaningful Use requirements should be defined such that they enable the creation of an entrepreneurial space across the entire health data enterprise. (Section 5.2) Agree App developers are ready and waiting… SMART on FHIR offers one open source approach 3.1EHR software vendors should be required to develop and publish APIs for medical records data, search and indexing, semantic harmonization and vocabulary translation, and user interface applications. In addition, they should be required to demonstrate that data from their EHRs can be exchanged through the use of these APIs and used in a meaningful way by third-party software developers. Agree on goal of data-level APIs Technical and other challenges need to be tackled – HL7 FHIR is currently most promising technical vehicle (at least in the US) FHIR Profiles can address “semantic mapping” “Indexing” requires some form of centralization? Agree that some type of robust validation should be made available, either through certification or other voluntary approaches 3.2The APIs should be certified through vetting by multiple third-party developers in regularly scheduled “code-a- thons.” Agree on collaborative process to standards and implementation guide development 3.3Commercial system acquisition by the VA and DOD should adhere to the requirements for creating public APIs, publishing and vetting them, and demonstrating meaningful data exchange by third-party software developers. Agree, but would avoid tight coupling of time-tables to the rest of the industry 19

21. JASON Recommendations (3) #JASON recommendationsJTF notes 4The ONC should solicit input from the biomedical research community to ensure that the health data infrastructure meets the needs of researchers. This would be best accomplished by convening a meeting of representative researchers within the immediate (12 month) time frame for architecture definition. (Section 6.2) Timeline will be challenging Clinical and research architectures should clearly be aligned, however, unclear that a single architecture or approach is appropriate or feasible for both 5The adopted software architecture must have the flexibility to accommodate new data types that will be generated by emerging technologies, the capacity to expand greatly in size, and the ability to balance the privacy implications of new data types with the societal benefits of biomedical research. (Section 6.3) Agree It is likely that cloud-based approaches may supplant EHR storage for some large-scale new domains 6The ONC should exert leadership in facilitating international interoperability for health data sharing for research purposes. The genomics community is already engaged in such efforts for the sharing of sequence data, and the ONC should consider adopting a similar process. (Section 6.4) Agree, but should not slow US progress while waiting for international agreements to emerge 7Large-scale data mining techniques and predictive analytics should be employed to uncover signatures of fraud. A data enclave should be established to support the ongoing development and validation of fraud detection tools to maintain their effectiveness as fraud strategies evolve. (Section 6.5) Unclear at what level this activity would take place 20

22. JASON Example Architecture User Interface Apps Middleware Apps Semantics and Language Translation Search and Index Functionality “chart/record” data “atomic” data w/ metadata Crypto Layer Data Storage (logical) Data Storage (physical) Data Transport (logical) Data Transport (physical) Stovepipe Legacy Systems Identity, Authentication, Authorization Patient Privacy Bundle Management Key and Certificate Management Published API 21

23. JASON Example Architecture (With proposed mapping to standards) User Interface Apps SMART Platform, et al. Middleware Apps Semantics and Language Translation FHIR Profiles Search and Index Functionality FHIR for local search/index “chart/record” data CCDA/XDS “atomic” data & metadata FHIR Crypto Layer (leverage existing approaches) Data Storage (logical) Data Storage (physical) Data Transport (logical) Data Transport (physical) Stovepipe Legacy Systems Identity, Authentication, Authorization Patient Privacy Bundle Management Key and Certificate Management Published API Key Network & Governance Issues 22

24. Discussion 23

25. Blank