JASON Report Task Force

August 19, 2014

David McCallie, co-chairMicky Tripathi, co-chair

2

Agenda

• Taskforce membership update• Listening Session Debrief• Recommendation framework• Discussion

3

Task Force Members

Member Name Organization Role

David McCallie Cerner Chair

Micky Tripathi Massachusetts eHealth Collaborative ChairDeven McGraw Manatt MemberGayle Harrell Florida State Legislator MemberLarry Wolf Kindred Healthcare MemberTroy Seagondollar Kaiser MemberAndy Wiesenthal Deloitte MemberArien Malec RelayHealth MemberKeith Figlioli Premier, Inc. MemberWes Rishel MemberLarry Garber Reliant Medical Group MemberJosh Mandel Children's Hospital Boston MemberLanden Bain CDISC MemberNancy J. Orvis FHA/DoD Ex OfficioTracy Meyer FHA/ONC Ex OfficioJon White HHS Ex Officio

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

Updated Meeting Schedule

Meetings Task

Wednesday, June 18th 9:00-10:30am ET • Review charges• Identify action steps

Tuesday, July 1st 3:30-5:00pm ET • Review discussion questions• Listening session planning

Thursday, July 31st 2:00-5:00pm ET • Listening session

Tuesday, August 5th 11:00am-12:30pm ET • Listening session

Tuesday, August 19th 11:00am-12:30pm ET • Listening session debrief• Develop recommendations

Tuesday, September 2nd 11:00am-12:30pm ET • Finalize draft recommendations

Wednesday, September 3rd- HITPC • Draft recommendations to HITPC

Tuesday, September 9th 1:00-3:00pm ET • Refine recommendations

Tuesday, September 16th 11:00am-12:30pm ET • Refine recommendations

Wednesday, September 17th-HITSC • Draft recommendations to HITSC

Friday, September 19th 1:00-3:00pm ET • Refine recommendations

Wednesday, October 1st 11:00am-1:00pm ET • Refine recommendations

Monday, October 8th 9:00-11:00am ET • Finalize recommendations

Wednesday, October 15th – Joint HITPC/HITSC meeting • Final recommendations 5

6

Listening Session Summary

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.

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.

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.

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.

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.

12

Recommendation Framework

• JASON charge• JASON scope• JASON findings• JASON architecture core principles• JASON recommendations

13

JASON charge

• 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?

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

14

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

15

JASON Findings (1)

# JASON Key Finding JTF notes

1 The 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)

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

3 The 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

16

17

JASON Findings (2)

# JASON Key Finding JTF notes

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

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

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

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

18

JASON Findings (3)

# JASON Key Finding JTF notes

8 The 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.

9 The 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.

10 Electronic 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)

JASON Recommendations (1)

# JASON Recommendation JTF notes

1 CMS 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

2 An 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.1 The 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.2 The 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.3 The 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

19

20

JASON Recommendations (2)

# JASON recommendation JTF notes

3 To 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.1 EHR 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.2 The 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.3 Commercial 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

21

JASON Recommendations (3)

# JASON recommendations JTF notes

4 The 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

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

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

7 Large-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

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)

Stov

epip

eLe

gacy

Sys

tem

s

Iden

tity,

Auth

entic

ation

, Au

thor

izatio

n

Patie

nt P

rivac

y Bu

ndle

M

anag

emen

t

Key

and

Certi

ficat

e M

anag

emen

t

Published API

22

JASON Example Architecture(With proposed mapping to standards)

User Interface AppsSMART Platform, et al.

Middleware AppsSemantics and Language Translation

FHIR ProfilesSearch and Index FunctionalityFHIR 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)

Stov

epip

eLe

gacy

Sys

tem

s

Iden

tity,

Auth

entic

ation

, Au

thor

izatio

n

Patie

nt P

rivac

y Bu

ndle

M

anag

emen

t

Key

and

Certi

ficat

e M

anag

emen

t

Published API

Key Network & Governance Issues

23

24

Discussion

Blank