jason report task force sept 2, 2014 david mccallie, co-chair micky tripathi, co-chair

53
JASON Report Task Force Sept 2, 2014 David McCallie, co- chair Micky Tripathi, co- chair

Upload: melissa-collins

Post on 26-Dec-2015

221 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

JASON Report Task Force

Sept 2, 2014

David McCallie, co-chairMicky Tripathi, co-chair

Page 2: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

2

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 3: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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

Page 4: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

4

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 5: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

5

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

Page 6: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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 • draft recommendations

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

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

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

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

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

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

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

6

Page 7: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

7

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 8: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

8

Listen Session Summary

• The Task Force held two listening sessions to gather input from a variety of stakeholders.

• Panels focused on:– Exchange service providers– Research– Standards– Consumer facing ecosystem– Vendor APIs– App Providers

• Detailed findings from the listening sessions are contained in the appendix. These findings have informed our deliberations and recommendations.

Page 9: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

Listening Session Panels

Consumer-facing ecosystems• Ali Emami, HealthVault• John Mattison, Kaiser• Kevin Riddleberger and Patrick Leonard, iTriage • Gordon Raup , Datuit• Anil Sethi, Gliimpse

Vendor APIs• Charles Parisot, EHRA• George Cole, Allscripts• Carl Dvorak, EPIC• Ryan Hamilton, Cerner

App Providers• Dave Vockell, Lyfechannel• Tim Michalski, Point of Care Decision Support • Nate Weiner, Avhanahealth • Chris Burrow and Steve Mickelsen, Humetrix • Denis Coleman, AppMedicine • Jonathan Baran, healthfinch

9

Exchange Service Providers• David Horrocks, Chesapeake Regional Information

System for our Patients (CRISP)• Ted Kremer, Rochester RHIO• Jitin Asnaani, CommonWell Health Alliance• Eric Heflin, Healtheway

Research• William Tierney, Regenstrief Institute• Sarah Greene, Patient-Centered Outcomes Research

Institute (PCORI)• Landen Bain, CDISC• Gwen Darien, Cancer Support Community

Standards• Grahame Grieve, Fast Healthcare Interoperability

Resources (FHIR)• Thomas Beal, openEHR• Steve Emrick, National Library of Medicine (NLM)• Stan Huff, Healthcare Services Platform Consortium

Day One (Jul 31, 2014) Day Two (Aug 5, 2014)

Page 10: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

10

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 11: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

11

Assumptions and Caveats

1. Though the JASON report is well-written and concise, there are many issues that can be interpreted in different ways. The JASON process does not allow engagement with JASON authors. We have tried to reasonably infer what is not clear, though we may have misinterpreted in some cases.

2. JASON report covers more ground than listed in its specific recommendations. Our review thus covers some areas that are not necessarily listed in the formal recommendations.

3. There has been a long time lag since the JASON report was conducted. Investigation was conducted in early 2013, but much has changed in the industry in the last 18 months, such as market deployment of Direct-enabled functions, and beginning of MU2 attestations using C-CDA.

4. JASON explicitly focused on high-level technical architecture considerations. They noted that several other challenges to interoperability – such as legal/policy, federation/jurisdiction, and business model – were not in the scope of their report.

5. JASON recommended encryption of data and transactions as a critical security feature, but did not propose any new technologies or measures than are already in use today. We thus have not focused on that aspect of the report.

6. JASON refers to the need for resolving patient identities across implementations as a key barrier to data aggregation. However, they do not propose any new technologies or approaches. We thus have not focused on that aspect of the report.

7. Due to the tight timetables, our preliminary recommendations are fairly high level and will need further exploration and broader discussion

Page 12: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

12

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 13: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

13

JTF One-Slide Summary on the JASON Report

The JASON report concludes that MU Stages 1 and 2 have not achieved meaningful interoperability “in any practical sense” for clinical care, research, or patient access due to the lack of a comprehensive nationwide architecture for health information exchange. They point to document-centric exchange as well as EHR vendor technology and business practices as structural impediments to achieving interoperability, and propose a “unifying software architecture” to “migrate” data from these legacy systems to a new centrally orchestrated architecture to better serve clinical care, research, and patient uses. This architecture would be based on the use of “public” APIs for access to discrete data, and on increasing consumer control of how data is used.

Page 14: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

14

Recommendation Categories

1. Current State of HIE

2. Architecture

3. Core clinical and financial systems

4. APIs

5. Consumer access and control of data

6. Research and HIE

7. Accelerating interoperability

Page 15: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

15

1. Current State of HIE: Background

Background• JASON report finds that “meaningful interoperability” is virtually non-existent

­ Conclude that interoperability, where it exists, is limited to “marked-up” document exchange

­ Little patient access­ No “rational access” between organizations for clinical care or research­ “[I]f this is the highest level of adoption of health information exchange the vendors will

agree to, then adoption of more meaningful information exchange appears to be very challenging.”

JTF Recommendation• ONC should take into account the current state of interoperability as well as current trends

before incorporating JASON findings in any decisions on HIE plans, policies, and programs.– We believe that JASON seriously underestimates the progress made in interoperability,

though we agree that there is considerable room for improvement.

Page 16: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

16

1. Current State of HIE: Recommendations and Discussion

Discussion• As noted earlier, the JASON findings were reached 18 months ago, some 6 months before the beginning of

MU Stage 2. While there has been some change in the capabilities available in the market, there has been an even larger positive change in the trajectory of interoperability progress.– Meanwhile, demand for interoperability has grown dramatically in the last 18 months, driven by MU

Stage 2 and the growth of value-based purchasing, Population Health services, and ACOs. The supply-side is responding to meet this demand.

• JASON expresses concern that Direct and CCDAs are inadequate end-states, however, this concern seems somewhat misplaced. – MU was structured intentionally to stage interoperability over time to allow for market adjustment to

new technologies and workflows. – We agree (see later recommendations) that immediate attention should be focused on improving the

interoperability of CCDAs to meet near-term structured data needs, while also accelerating development of usable standards for discrete data-level APIs

– We note that the JASON focus on APIs over CCDAs in order to support data exchange is somewhat of a false dichotomy – CCDAs embed structured data in document representations, and many systems are already consuming and extracting atomic data elements from CCDAs for a variety of clinical and business purposes

Page 17: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

17

2. Architecture: Background

Background• JASON report appears to be recommending a centrally orchestrated, nationwide architecture to resolve incompatibility of

individual implementations that exists today.– “Interoperability issues can be resolved only by establishing a comprehensive, transparent, and overarching software

architecture for health information.– “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.”

– 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.”

• They do note that their proposed software architecture could have heterogeneous implementation modes, including a mix of centralized and federated approaches.– “The architecture that JASON proposes allows for various specific implementations, including as possibilities integrated

software suites that run on a single box, a cloud implementation, or a widely federated system of systems with shared responsibilities across different organizations.”

• JASON explicitly focuses only on high-level technical architecture and does not address legal, business, policy, federation issues

Page 18: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

18

2. Architecture: Recommendation

JTF Recommendation• The industry should accelerate the current path of loosely coupled architecture based on

thoughtful API design connecting market-based implementations using proven, standards-based APIs

• ONC should not try to impose detailed architectures on the market but rather should focus on loosely coupled market-driven architectures based on standards-based APIs

• ONC should accelerate this process by helping to convene industry stakeholders to define the minimal components necessary to loosely couple market-based implementations, and to align and leverage federal infrastructure and programs to support development and adoption of such minimal components

Page 19: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

19

2. Architecture: Discussion

Discussion• JASON acknowledges the importance of governance agreements and appropriate business drivers.

Evolving a “robust health architecture” is not simply a technological problem.­ However, the concept of an “overarching” architecture would require some type of strong centralized

coordination for legal clarity and alignment, policy development, business/organizational model development, and technical design, deployment, and operations to create a truly operational “virtual repository in the cloud”

• The JASON “architecture” is really more of an “architecture pattern” which will require a rich ecosystem of specific implementations to become useful– The proposed JASON architecture allows for loose coupling of multiple compatible-but-distinct

implementations– These distinct implementations should be market-based (i.e., not determined or sanctioned through

regulatory processes)• A monolithic software architecture is unlikely to be feasible in the US market

– Would require “top-down” direction and implementation from HHS that would require considerably more resources and legal authority than currently exists, even with MU Stage 3 and 2017 Edition certification

• The current direction of interoperability is aligned with many if not all of the components of the JASON architecture (see diagram) and follows very closely on the JASON-proposed migration path (see JASON figures 3-5)– JASON says it is acceptable to start with atomic data, intrinsic encryption, semantic translation, and

middleware applications and building these over time

Page 20: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

20

3. Core clinical and financial systems

Background• JASON concludes that current EHR and financial systems need to be replaced in order to meet the goals of

the proposed software architecture

– “Today’s EHR systems are already legacy systems, many of which are built on the MUMPS database technology first developed in the 1960s. Unfortunately, these systems are likely to dominate the HIT landscape for years to come.”

– “The architecture incorporates a migration pathway from the current legacy software used to store and process EHRs to the future system of broad interoperability.”

• JASON focused on only documentation and storage of clinical notes and data, and ignored other currently available EHR functions such as CPOE, CDS, and workflow orchestration.– Current generation EHRs and financial systems are denoted as “stovepipe legacy systems”

• JASON also assumes that the current structure of the market suffocates innovation– “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”

– Suggests that the current market is not open to entrepreneurs and new entrants, AND that current EHR and financial system vendors are not innovating themselves

Page 21: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

21

3. Core clinical and financial systems

JTF Recommendation• The industry should accelerate the parallel paths of CCDA refinement and data-level APIs as part of the evolutionary

development of EHR and financial systems • ONC certification should leverage standards-based APIs where possible to expand opportunities for modular certification • ONC should immediately seek guidance from the HIT Standards Committee on the maturity of development of data-level

API standards, and what foundational API requirements can reasonably be included in 2017 Edition Certification to help to launch an ecosystem for more robust API development and implementation

Discussion• Current EHR systems are more functionally sophisticated and technologically dynamic than JASON gives them credit for

– Many of the functions highlighted in the JASON software architecture are performed by EHR systems today (e.g., UI applications, Semantics and Language Translation, Search and Index Functionality, open APIs)

– Many vendors already support APIs, and have numerous third-party “apps” integrated into workflows– However, current APIs tend to be vendor-proprietary and thus reduce the market opportunity for entrepreneurial

developers, and could lead to “vendor lock in”• Market demand for interoperability is growing rapidly and the supply-side is beginning to respond through rapid innovation

by existing vendors and the influx of new entrants– However, technical barriers, though challenging, are eclipsed by the policy, legal, business, and socio-technical

barriers to greater interoperability– As in any rapidly evolving industry, more formalized structures and processes for market coordination of technical,

policy, legal, business, and socio-technical need to evolve to catalyze more rapid progress• Innovation and entrepreneurialism are best promoted by focusing on functional interoperability goals and open architecture

through standardized APIs, rather than on the internal software design of core clinical and financial systems

Page 22: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

22

4. APIs Background

Background• JASON urges moving beyond CCDAs to data-level “public” APIs to support the goals of exposing discrete

data for improved clinical and research uses.– “[S]imply moving to a common mark-up language will not suffice. It is equally necessary that there be

published application program interfaces (APIs) that allow third-party programmers (and hence, users) to bridge from existing systems to a future software ecosystem that will be built on top of the stored data.”

– “At present, large-scale interoperability amounts to little more than replacing fax machines with the electronic delivery of page-formatted medical records”

• They propose accelerating this development through regulatory requirements, primarily MU Stage 3– “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.”

– The APIs should be certified through vetting by multiple third-party developers in regularly scheduled “code-a-thons.”

• They are highly concerned that the industry will not move beyond Direct and CCDAs– “[I]f this is the highest level of adoption of health information exchange the vendors will agree to,

then adoption of more meaningful information exchange appears to be very challenging.”

Page 23: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

23

4. APIs Recommendations

JTF Recommendation• We agree on the need for data-level APIs to complement document-level CCDAs currently in production

and refinement today– As noted elsewhere, immediate efforts should be addressed to improving current CCDA

interoperability in time for 2017 Edition certification– We also note the value of narrative text in preserving the patient’s clinical story – this narrative must

not be lost during addition of discrete data APIs.• The growing industry adoption of standards-based API work such as HL7 FHIR, focused on high-value use

cases, is the most appropriate and sustainable path to accelerated use of APIs across the industry– FHIR Profiles offer a promising approach to meeting the demand for “semantic interoperability” and

thus minimizing the need for “metadata translation services” denoted by JASON– However, there is much work to be done before FHIR can become a standard mature enough for

large-scale deployment• FHIR (and FHIR profiling) should be accelerated and targeted through ONC contracting with existing

initiatives and SDOs for development of tight specifications and implementation guides focused on high-value use cases and licensed for public use– ONC should encourage rapid public/private experimentation with these emerging APIs, to ensure

that they work as intended. – These experiments should include uses targeting clinical care, research, population data, as well as

exposure to consumers via EHR Portals.• Standards development and certification should leverage existing industry and HITECH structures

Page 24: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

24

4. APIs Discussion

Discussion• Need to strike balance between incremental perfecting of the current state and more radical changes

towards a future state– Data-level APIs are not a replacement for structured document-level CCDAs, which capture

encounter-level context that is critical for clinical care, as well as the narrative details than cannot be captured in structure.

– Thus, there is an ongoing need to aggressively improve existing CCDA standards while working in parallel towards complementary data-level APIs.

• We agree that existing products should adopt and expose standards-based APIs– Open APIs are typically based on accepted standards, and are published and documented at a

sufficient level of detail that they can be implemented without intervention by the source system hosting the API

– The JASON notion of “public API” may need additional clarification. • For example, does “public” imply an obligation by the EHR to provide access to the API?• We note that without external mechanisms for validating trust and appropriate use specific

to health care, there will still be a need for coordination between connecting parties, as well as normal business coordination regarding licensing, responsibilities, etc that exists in all industries

Page 25: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

25

4. APIs Discussion

Discussion (continued)• A published open API framework can partially offset the need for strict standardization of APIs

– Some discussion considered that if well-documented APIs and API support structures are made available by EHR vendors, there may be less need for the APIs to be identical, as long as they meet core elements of high-value use cases

– This could protect against an unintended consequence that JASON-like robust APIs among highly circumscribed functional components could lead to overly constrained APIs that are not flexible to emerging data access needs

• Standards development and certification should leverage existing industry and HITECH structures, at least through the first couple of years of MU Stage 3 attestation (and 2017 Edition Certification)– Creation of new standards-deeming or certification bodies at this point in time will likely greatly

hinder progress toward a public API approach to expose more data for clinical and research uses • Need to avoid market confusion that would come from introducing new certification structures

and processes in the middle of the MU program– Streamlining current ONC certification for end-to-end testing through public-private iterative, agile

processes, as discussed at the HIT Policy Committee, is the best approach for testing and validation through 2017 Edition Certification, after which an assessment can be made as to how to best catalyze and complement market-based approaches to standards coordination and validation

– Existing SDOs are already curating API development – need to catalyze and focus these efforts, not introduce intermediary structures or processes that will take time to mature and gain market acceptance

Page 26: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

26

5. Consumer access and control of data : Background

Background• The JASON report initially asserted that patients “own” their healthcare data. Subsequent

clarification modified this proposition to “patients participate in the management of his or her data”

• JASON calls for granting “fine grained” consumer (patient) control over uses of health data, via the notion of “privacy bundles” which capture common access patterns that fit most patient needs, and assuming a fine-grained level of data tagging and segmentation to allow such “privacy bundles” to apply to a wide variety of use cases and legal/policy constraints

• JASON calls for providing consumer access to healthcare data via the same discrete data APIs that would address clinician and research data access needs.

Page 27: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

27

5. Consumer access and control of data: Recommendations and Discussion

JTF Recommendations• EHR Portals should expose similar discrete-data APIs as discussed for clinical care and research needs

– The Blue Button Plus (Pull) project offers a logical starting point – by expanding the current use of FHIR and OAuth2 to include a richer set of APIs

– Consider models that leverage the SMART Platform as an open specification for “app” developers to explore.

• HHS (OCR) should help clarify the degree to which patients and consumers can control access and usage of their personal health data. Much confusion exists, even among HIT experts.

Discussion• Standards-based, data-level patient portal APIs could become a major source of innovation for the

industry.– There is strong interest from the “mHealth” app industry in gaining direct data access to patient data,

probably via consumer-granted access to their provider’s portal. • The technical availability of APIs would need to be accompanied by business processes to support health-

care specific concerns (privacy, appropriate use of data) as well as general business concerns (data rights, liability, etc)

• Confusion exists about the degree to which data access rights are “carved out” under existing regulations versus the consumer’s right to a copy of their data and subsequent control of access to their copy.

• The Task Force did not spend significant time discussing the JASON “privacy bundle” proposal. More discussion is warranted, accompanied by clarification on the data access rights of the source versus copy of the data.

Page 28: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

28

6. Research and HIE: Background

Background• JASON believes that existing clinical data could be used for large-scale research purposes.

­ “A new software architecture will make aggregated health care data available to all biomedical researchers… The federated database will provide large effective sample sizes … in what amounts to an ongoing clinical trial with over 300 million potential enrollees.”

• JASON believes that the lack of EHR support for a consistent data-level API creates a fragmented research environment that grossly underutilizes existing clinical data– “At present, access to health data is limited to proprietary datasets of selected patients.”

• JASON an assumption that clinical, research, and consumer access use cases can all be supported by the same architecture

Page 29: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

29

6. Research and HIE: Recommendations

JTF Recommendations• Standards-based, discrete data APIs to improve researchers’ access to routine clinical data

should be strongly supported through technical and policy development– Agree with JASON recommendation to convene the research community to identify use

cases, technical requirements, alignment with existing data collection/analysis structures and processes, and legal/policy barriers and opportunities

– Research community should participate in decisions about where structured APIs XXX– This should include current representative from initiatives where research leveraging

routine clinical data is already undertaken, such as Kaiser Permanente and i2b2 • Many regulatory, governance, and business barriers remain to be addressed in order to see

the JASON vision mature. Additional research and regulatory refinement will be necessary to balance the needs of the research community with the need to protect patient privacy. The policy work in particular should be launched immediately in parallel with the development and adoption of new discrete data APIs

Page 30: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

30

6. Research and HIE: Discussion

Discussion• Standards-based, discrete data APIs would improve researchers’ access to routine clinical data, with

powerful consequences for observational research, but perhaps more limited benefit for other types of biomedical research– JASON vision for research access to clinical data is most appropriate for large scale clinical and health

services “observational” (exploratory, hypothesis-generation) studies– Benefits for biomedical research would be somewhat limited since most routine clinical data is not

captured under the rigorous control needed by clinical trials.• Additional work will be necessary to reconcile the JASON vision of a common data-level API with existing

approaches to clinical research.– Different types of research (controlled trials, outcome studies, etc) have their own approaches and

infrastructures, and in many cases have existing standards in common use (CDISC, RFD, etc.)• Potential inconsistencies in the JASON report about balancing the need for consumer control of non-

clinical data usage versus the research community’s need for unfiltered, un-edited raw data• JASON also calls for additional work on standards for de-identification of research data, and on potential

changes in regulatory approach to dealing with attempts at re-identifying research data• The challenges of protecting patient privacy will grow as more and more and more data is captured

digitally.

Page 31: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

31

7. Accelerating Interoperability: Background

Background

• JASON advocates using MU Stage 3 as the primary lever for provoking the industry changes that it would like to see­ “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.”

­ “This pathway could be provided by published APIs mandated through the CMS Stage 3 Meaningful Use program”

­ “JASON believes that now is time to define such an architecture, leveraging the opportunity to specify CMS Stage 3 Meaningful Use requirements to drive implementation”

• JASON began its work in late 2012­ Did not have benefit of lessons learned from implementation of the C-CDA for MU Stage

2­ Assumed much more time to define, gain consensus, and prepare for MU Stage 3

Page 32: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

32

7. Accelerating Interoperability: Recommendation

JTF Recommendation

• ONC and CMS should consider MU Stage 3 as one of many levers to promote advancement toward JASON goals. - Especially because the 2017 Edition Certification timetable does not appear to allow

sufficient time for widespread adoption of the standards-based discrete data APIs at the core of the JASON architecture

• The federal government should align and leverage the many other means at its disposal to promote advancement of JASON goals.

• The emerging ONC Interoperability Road Map should include­ Specific and concrete operational goals that the federal government will target through

the orchestration of its own programs and activities­ Plans for leveraging existing market and HITECH structures to meet near-term (3- and 6-

year) goals while outlining the approaches necessary to shift to support of discrete data APIs as envisioned by JASON

­ Glide paths and decision points for assessing the need for other structures and processes in the future

Page 33: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

33

7. Accelerating Interoperability: Discussion

Discussion

• MU Stage 3 is not as powerful a lever as suggested by JASON­ Timelines are too short to require revolutionary changes in software and API design­ Declining incremental incentives and competing industry priorities have partially diminished the

market influence of the MU program­ Vendors will still have to meet certification requirements, so there is still power in MU’s market

orchestration influence

• Nevertheless, market demand for interoperability is growing rapidly­ Growth of value-based purchasing (ACOs, hospital readmission penalties, etc), rising consumer

expectations, rising standards of care

• As the MU program ramps down, the importance of effectively orchestrating other federal levers will be critical success factors in providing some channels for standardization– Purchasing of health IT systems (DoD, VA, IHS, other), interoperability with Federal health care

providers, creating publicly accessible HIE infrastructure components (e.g., nationwide provider directory), Medicare and Medicaid value-based purchasing initiatives, NIH intramural and extramural research, FDA and pharmaceutical and medical device regulation, public health infrastructure, LTPAC regulation, CLIA lab accreditation, advanced imaging facilities accreditation

Page 34: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

34

Agenda

• Review of JTF Charge• Members, process, and timeline• Listening session description• Assumptions and caveats• Recommendation framework and preliminary

recommendations• Next steps

Page 35: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

35

Next steps

• Gather directional inputs from the HITPC and HITSC• Further specify recommendations in four remaining

Task Force meetings (add more if necessary)• Cross-reference to PCAST report• Cross-map to ONC Interoperability Road Map

Page 36: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

36

Appendix

Page 37: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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

Page 38: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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

38

Page 39: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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)

• There is a tension between perfecting the current state and making incremental progress towards a future state and difference of opinion as to which of those paths is the most appropriate. We believe there is value in continuing to incrementally improve existing standards while working in parallel towards the desired future state.

• We believe the proposed JASON architecture is intended to exist in many compatible-but-distinct implementations but not as a single monolithic implementation.

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)

• Decide what standard will be used to solidify Patient Identity – even in discussions re: Unique Identifier(s) that Patient Matching/identity dependent on the strength of the underlying attributes used to validate in the first place.

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 considerable room for improvement.

• For example, immediate efforts should be made to improve compliance around the CCDA document standard during the transition to use of improved data APIs.

39

Page 40: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

40

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, [Do we want to suggest what an“open” architecture 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 useful applications that leverage 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.

• We note that an “open software architecture” is not the same as “open source” software. We do not believe that JASON is advocating for an architecture restricted to open source software implementations.

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)

• Agree, but the legal complexities involving access to patient data (not controlled by the patient) are as much a barrier as any software architecture issues.

Page 41: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

41

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 “big data” report for more discussion.

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 for the US.

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)

Page 42: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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)

• 2017 Edition timeframe is quite challenging given the scale of the task and the complexity of gaining consensus

• Start soon, but expect incremental changes that will continue to improve over a 6-10 year timeframe.

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

• See our annotations on the architecture diagram• Different architecture requirements for networks that

support clinical care, that support patient access and that support research

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 2017 Edition certification• Encourage private industry to drive, outside of

initial regulation• Initial focus on portal APIs for consumer “smart

app” access (Blue Button extensions)

42

Page 43: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

43

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, but note above comments about 2017 Edition timing• Entrepreneurial space may develop more rapidly in the consumer • App developers are ready and waiting…

• SMART on FHIR offers one option - an open specification (and an open source reference implementation) for “app” development

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• HL7 FHIR is a promising emerging standard that is gaining multi-

stakeholder adoption • Useful “search and indexing” may require some form degree of

centralization (as per PCAST report)• FHIR Profiles show promise in addressing “semantic

harmonization” and “vocabulary translation” but need to be proven via pilot activities

• APIs and profiles may need to vary for the major use-cases (clinical care, research and providing data to patients.)

3.2 The APIs should be certified through vetting by multiple third-party developers in regularly scheduled “code-a-thons.”

• Agree that robust validation should be made available, either through certification or other voluntary and collaborative approaches

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

Page 44: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

44

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 API and metadata 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 augment

local 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

Page 45: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

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,

Aut

henti

catio

n,

Auth

oriza

tion

Patie

nt P

rivac

y Bu

ndle

M

anag

emen

t

Key

and

Certi

ficat

e M

anag

emen

t

Published API

45

Page 46: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

“Population” level data

FHIR

Decision support

Key

and

Certi

ficat

e M

anag

emen

t

Patie

nt -

Prov

ider

Re

latio

nshi

ps

Patie

nt P

refe

renc

e M

anag

emen

t

Use

r/Pa

tient

/Pro

vide

r Id

entit

y, A

uthe

ntica

tion,

Au

thor

izatio

n, D

emog

raph

ics

JASON Example Architecture(With proposed mapping to standards)

User Interface and Middleware AppsOAuth2/OIDC (e.g. SMART)

“Push” Services

Semantics and Language TranslationFHIR Profiles

“Clinical docs” CCDAFHIR

“Atomic” & metadata

FHIR

Crypto Layer (leverage existing approaches)

Data Storage (logical)

Data Storage (physical)

Data Transport (logical)

Data Transport (physical)

Core

Clin

ical

and

Fi

nanc

ial S

yste

ms

Published APIKey Network & Governance Issues

Dat

a &

Met

adat

aSt

anda

rds

& S

ervi

ces

Search and Index FunctionalityXDS FHIR

Page 47: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

47

Listen Session Summary

• The Task Force held two listening to gather input from a variety of stakeholders. Panels focused on:– Exchange service providers– Research– Standards– Consumer facing ecosystem– Vendor APIs– App Providers

Page 48: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

48

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 expressed a tension between improving the current state vs moving towards a new state and urged an incremental path be taken in any approach.

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

Page 49: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

49

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.

Page 50: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

50

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.

Page 51: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

51

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.

Page 52: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

52

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.

Page 53: JASON Report Task Force Sept 2, 2014 David McCallie, co-chair Micky Tripathi, co-chair

Blank