JASON Report Task Force

September 16, 2014

Micky Tripathi, co-chairDavid McCallie, co-chair

2

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

3

Charge

• Analyze and synthesize feedback on the JASON report – Discuss the implications of the report and its impact on HHS,

other Federal agencies and their strategies– Assess the feasibility and impact of the JASON report on HHS

and the broader HIT ecosystem– Identify use cases and lessons learned from current

experience– Establish specific recommendations that can be integrated

into the Federal Health IT Strategic Plan and the ONC interoperability roadmap

– Provide a high-level mapping of the PCAST 2010 report with the JASON report (added subsequent to initial charge)

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

4

5

JTF – Work plan for remaining meetings

• Meeting 1 (16 Sep 2014)– Review comments/direction from HITPC & HITSC– Discussion definitions of “public API” and “orchestrated architecture”– Discussion on “fast track” approach to API standards

• Meeting 2 (19 Sep 2014)– Discuss “Privacy Bundles”– Discuss annotations for the JASON “architecture diagram”

• Meeting 3 (1 Oct 2014)– Refine JASON-to-PCAST mapping– First review of final report

• Meeting 4 (8 Oct 2014)– Final review of final report

HITPC Discussion*

In general, the preliminary report was very well received by both HITPC and HITSC.

• Probst: – Skeptical of industry’s ability to adopt JASON without government “push”– Need better definition of “loosely coupled”

• Egerman: – Compare and contrast to PCAST report. Adopt the good stuff.– What is the governance? What is the enforcement? (from Governance presentation)

• Kotes– Do we need new regulatory protections for the consumer’s copy of PHI? (FTC vs OCR vs ??)– Critical need to establish “trustworthy” apps for consumers (and providers) – prevent rogue use of APIs

• Cullen– Questioned whether vendors could be trusted to do this on their own. – Clarify “open” vs. “public” API – does public imply automatic access rights?– Not likely to see this in time for MU3 – too busy with other work

• Lansky: – Please address the other levers beyond MU3– Why were quality measures not mentioned? We need to make CQM more nimble and flexible, versus

hard-coded approach today (JASON as CQM Query tool?)

9/16/2014 6*Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

7

HITPC Discussion*, continued

• Bechtel– consumers vs. researchers – how to enable “meaningful choice” on data use. This technology enables more than our

policies can accommodate• Patterson:

– Don’t ignore the national patient identifier issues!– Remember the core use-case: Eliminate the “bags of records” that we have to carry from MD to MD– Please ensure that “inter-operability” is the target, not just “intra-operability”– MU3 is the “last train” that leaves with funding attached. Get as much on board as possible

• Kennedy– What’s different this time (from PCAST?)– The new economic drivers are still very immature– Don’t forget about documents and the patient’s narrative. Physicians must be able to capture the story.

• Harriman– Need more discussion about the privacy implications– privacy bundles imply lots more metadata – where will that come from?– What is the governance around API usage? Who controls? Access rights? Authorization?

• DeSalvo– Increasing consumer expectation for data access and rights– Powerful new business drivers for interoperability– Digitization of the raw data is nearing completion – now is time for better flow– The notion of an “open” API will pose new governance and policy challenges

9/16/2014 *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

8

HITSC Discussion*

(Combining discussion - Power Team “query” recommendation & JASON report)

• Reider:– Do these proposals leave “too much optionality” for interop to emerge?– What is the right “regulatory cadence” to accommodate these emerging technologies?– What is the right role for government in this?– Need to define a set of principles and a “timeline” that moves to FHIR

• Huff:– Don’t forget that coordination of FHIR Profiles is required in addition to standard API. What

mechanisms can ensure that we have consensus there as well?• Ross:

– What about support for “population” based services?• Halamka:

– We need a mechanism to fast-track a simple subset of FHIR in time for 2017 Edition• Ferguson:

– Don’t underestimate the success of current XCA+CCDA approaches.– Must support XCA during transition to FHIR– Please stay aligned with the S&I DAF– Should support DAF-like population-style query as well

9/16/2014 *Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

9

HITSC Discussion*, continued

(Combining discussion around Power Team “query” recommendation and JASON report)

• Lemaitre– Our role is to push FHIR forward (??)

• L Harris:– How can these tools be used to capture patient-generated data?– Capture “patient push” and device data– Don’t worry about “rip and replace” – you have to plan for it

• Rose– Concerned about vendor-proprietary (query) solutions – suggest requiring publishing of internal API or requiring

that networks be open• ????

– What do they mean by “uber architecture”– What do they mean by “migration to new platforms?– Were they addressing data persistence or data flows?

• S Terry– Please stay coordinated with PCORNet, especially around governance for research use, and the implementation of

privacy bundles.– Consumers are more sophisticated around privacy now

• Reider– Is it possible to produce a reduced-subset of FHIR in time for 2017 Edition, and if so, does the market have the “will”

to get it done?*Attributed comments are taken from notes captured during the meeting, and represent our attempts to summarize each member’s comments. They are not exact quotes.

9/16/2014

10

HITPC + HITSC – Major Themes

• Agreement to move forward to more powerful, data+ documents API– The debate is about the speed and timing of the cross over to newer standards– Debate also about what can be done in context of MU3/2017E– Consider a focused, fast-track implementation around FHIR, constrained CCDA, and core use-cases

• Agreement that “orchestration” of architectures is more feasible than “top down” control– Focus on loosely-coupled APIs + robust data element profiles to ensure semantic interchange– Assume heterogeneity among implementations– Some services may require higher degrees of centralization (identity, authorization, consent)

• Mostly agreed that market forces should be leveraged as much as possible– New business drivers are forcing new levels of interoperability faster than MU stages– Regulatory approaches must be light, nimble– Incentives should target inter-operability, not just intra-operability– Monitor for undesired barriers that inhibit interoperability??

• Agreement that “public APIs” introduce new governance/ecosystem questions– Access, trust, authorization, data use, certification, etc– Need to consider consumer and population health/research use cases as well

• Agreement that privacy policies must keep pace with technology advances

9/16/2014

11

What is a Public API?

• JASON repeatedly refers to a “public API”• “Public” implies a mix of standards + governance

• Proposed definition for implementation of a Public API– Shall support all required standard Core API & standard Core Profiles– Shall support public documentation for Core API and standard Core Profiles– May support custom API and/or custom Profile extensions

• Should support public documentation for custom API and/or custom Profile extensions

– Should enable access to and use of the API in a way consistent with API governance Rules of the Road / best practices

– Should be validated against rigorous certification tests• API certification tests should be managed by the standards entity that governs the Core

standard

– Should be accompanied by a vendor-supported “sandbox” that enables testing by external entities (with proper access)

9/16/2014

12

Key Architectural Principles

• Centralized coordination rather than top-down control• Architectural patterns:

– Loosely coupled, ReSTful API (the Public API,) connecting heterogeneous systems– Tightly specified “on the wire” profiles for data elements, fitted to defined use-cases,– API will support discrete data + documents + adequate metadata– Implemented with best practice encryption and key management– Respect Postel’s principle (send conservatively; receive liberally)

• Expose API for patient care, consumer access, and population/research– Data profiles and authorization strategies may vary by class of usage

• Expose API in support of “apps,” “modules,” and other mechanisms that encourage “pluggable” innovations

• Start simple, but anticipate emerging higher functions (follow the “Internet Hourglass” pattern.)• Future cross-organization (“network”) orchestrated services could include:

– Identity management (providers and patients)– Authentication, authorization, key management– Consent and privacy preferences– Directories and data indexing services (supporting search)– Complex orchestration and transactions services (SOA)

9/16/2014

“Population” level data

FHIR

Decision support FHIR

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

Patie

nt &

Pro

vide

r Ide

ntity

, Au

then

ticati

on,

Auth

oriza

tion,

Dem

ogra

phic

s

JASON Example Architecture(With proposed mapping to standards)

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

“Push” Services FHIR

Semantics and Language TranslationFHIR Profiles

“Clinical docs” XCAFHIR

“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

Public APIKey Network & Governance Issues

Valu

eSet

& M

etad

ata

Stan

dard

s &

Ser

vice

s

Search and Index FunctionalityXCA FHIR

14

Key Policy Questions

• Who governs the establishment and maintenance of specifications of the Public API?– Scope and specs of “core” API and profiles– Staging of expansion of core– Monitoring and compliance

• Role of markets vs government in reducing barriers to legitimate data flow?– Should implementation of public API be “required” via CEHRT certification, or voluntary?– Should external access to the public API be mandated?

• If so, under what conditions? (Trust, certification, license, cost…)

• What constitutes a “network” around use of these API?– Assuming there is more than one network, should network-to-network bridging be

required or voluntary?– How to coordinate cross-organization (network) services?

• How to motivate the creation of a market ecosystem to support loosely coupled approach?– How can we leverage lessons learned from Direct/HISP experience, and other early

network-building efforts?

9/16/2014

15

Appendix

• Materials presented to HITPC and HITSC

9/16/2014

Blank