Download - JASON Report Task Force September 16, 2014 Micky Tripathi, co-chair David McCallie, co-chair
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