Transcript Document

Health IT Standards Committee
Architecture, Services, and
API Workgroup
David McCallie, co-chair
Arien Malec, co-chair
March 18, 2015
ASA Workgroup - Active Members
Name
Organization
David McCallie, chair
Cerner
Arien Malec, co-chair
RelayHealth Clinical Solutions
Janet Campbell
Epic
George Cole
Allscripts
Josh Mandel
Children's Hospital Boston
Gajen Sunthara, ex officio
Department of Health and Human Services (HHS)
Debbie Bucci, staff lead
HHS, Office of the National Coordinator
2
ASA WG Workplan
Meetings
Task

February 10, 2015 – Joint Committee Meeting
•
Charged by HITSC with responding to the Interoperability Roadmap V.1

February 12, 2015 2:30 – 4:00pm ET
•
Comment on Interoperability Roadmap V.1

February 26, 2015 2015 2:00 – 3:30pm ET
•
Comment on Interoperability Roadmap V.1

March 12, 2015 2:30-4:00pm ET
•
Comment on Interoperability Roadmap V.1

March 18, 2015 – HITSC Meeting
•
Review current progress on Interoperability Roadmap V.1
March 26, 2015 2:00-3:30pm ET
•
•
Finalize comments on Interoperability Roadmap V.1
Overview of Certification NPRM and prepare to comment (anticipated date for
planning purposes)
April 9, 2014 12:00 – 1:30pm ET
•
Comment on Certification NPRM (anticipated date for planning purposes)
April 22, 2015 – HITSC meeting
•
Interoperability Roadmap V.1 comments to the HITSC
April 23, 2014 12:00 – 1:30pm ET
•
Comment on Certification NPRM (anticipated date for planning purposes)
May 7, 2014 12:00 – 1:30pm ET
•
Finalize comments on Certification NPRM (anticipated date for planning
purposes)
May 20, 2015 – HITSC Meeting
•
Anticipated date to present Certification NPRM Comments to the HITSC
7/18/2015
3
Architecture, Services and Application
Program Interfaces (APIs) Charge
• Define architectural patterns sufficient for an ecosystem of
nationwide scale information sharing and modular applications
serving patients, providers, provider-organizations, and researchers
• In close coordination with sister groups from HIT Policy Committee,
explore technology policy to promote the adoption and use of
enabling technology consistent with the architectural patterns
• Define and make recommendations on standards, implementation
guidance and certification criteria consistent with architectural
patterns
• Define and make recommendations on incremental progress
towards proposed architectural patterns consistent with ONC
roadmap and strategy
4
Mapping Healthcare APIs to the “Internet Hourglass”
Heterogeneity, competition, innovation, duplication
Parsimony, lack of duplication
Homogeneity
Parsimony, lack of duplication
Heterogeneity, competition, innovation, duplication
Parsimony --> the simplest and most economical way to construct something
5
Why an Hourglass: Modern example of evolutionary
pressure
HTTP
SOAP (over HTTP)
XMP-RPC (over HTTP)
CORBA (over HTTP)
REST/AJAX (over HTTP)
REST over HTTP
Supported on
enterprise platforms
(JavaEE and .Net)
Supported on all
platforms, languages,
OS, mobile/desktop, etc
Similar trends at play for data formats (XML  JSON)
7/18/2015
6
Composable API Era – Mapping to the hourglass
Data sharing Arrangements
Interoperability Use-cases
Orchestration Patterns
Core Composables
Internet Standards
Vendor
implementations
7/18/2015
7
Composable API Era – Mapping to the hourglass - Examples
ACOs eHealthExchange CommonWell
SureScripts Vendor-App-Stores
Referral-Networks
SDC
RFD Closed-Loop-Referrals
InfoButton-2 Pop-Health Remote-CDS
Rx-as-App PDMP Prior-Authorization
Appropriateness-Screening
Apps (SMART, mHealth)
Peer-to-Peer Brokered-Trust
Pub-Sub
CORE-Profiled-FHIR
OAuth2 OIDC
HTML5
HTTP + TLS
7/18/2015
Data Sharing
Arrangements
Interoperability
Use-cases
Orchestration
Patterns
Core
Composables
The Internet
8
An Orchestration Example – Pluggable Apps
• Pluggable Apps - Conversational UX inside Provider
workflow
–
–
–
–
Uses HTML5 via an embedded web app for the UX
Uses FHIR as the data service (read or read/write)
Uses OAuth2 and OIDC for auth/auth to the FHIR service
Defines an extensible context-passing model
• Many potential Use-cases fit this pattern
–
–
–
–
–
Disease-specific Visualizations
Diagnostic CDS (Differential Dx, Visual Dx, etc.)
Replacement for RFD and/or SDC (more powerful, easier)
Embed access to external HIE and pop health services
Closed-loop referral management services
9
Orchestration Example: Pluggable Apps (e.g., SMART)
SMART
Container
EHR
App
Authorization Service
FHIR Service
(EHR Data)
Menu or Trigger
App URL + EHR context
Request authorization
+ URL of Auth/FHIR
Validate user and patient context against EHR
Returns auth token
Token + FHIR request for patient data
Exchange patient data
HTML + JS (UX)
POST user input
Token + FHIR request for more patient data
HTML + JS (UX)
DONE
Exchange patient data
Orchestration Proposal – Remote CDS, with optional Conversation
(CORE-based version of Health eDecisions)
• Goal –EHRs invoke remote CDS, with option for conversational
mode
• Orchestration Sequence:
–
–
–
–
–
–
–
–
7/18/2015
[EHR uses internal tools to detect action requiring remote CDS]
EHR authenticates to the remote CDS service (peer to peer)
EHR and CDS service use Core-FHIR to exchange any data needed for decision
If additional provider interaction is needed, CDS asks EHR to invoke a SMART
App
SMART App captures any missing data
CDS then generates suggested orders, suggested problems, etc.
CDS may also generate documentation of decision-making
CDS returns the above data to EHR using Core-FHIR
11
Remote CDS, with Optional Conversation
• Benefits:
– CDS does not need to expose internal rule logic
– EHR does not need to implement complex decision logic
– If no conversation is needed, provider’s workflow is not interrupted
– EHR vendor and CDS vendor are de-coupled, speeding
implementations
• Many use-cases can use this Orchestration
– ACR Radiology appropriateness screen (CMS 2017)
– Prior approval capture (payer, CMS, etc.)
– PDMP workflows
– Smarter CDS (Choose Wisely, PGX reviews, etc.)
– Public Health interventions (Ebola screens, urgent reportables)
7/18/2015
12
DRAFT Roadmap Recommendations
• The workgroup deliberated on the proposed
Interoperability Roadmap
• We felt that the hourglass model provided a
strong framework for an interoperability
roadmap
• The following represents DRAFT directional
recommendations
7/18/2015
13
DRAFT General recommendations
• To create greatest modularity, move towards
parsimony of
– Transport and Security (HTTPS + OAuth2/OIDC)
– Content (Profiled FHIR)
– Common Orchestrations
• Adopt a deliberate policy of “rebalancing” the
standards portfolio towards parsimony
• Allow sufficient time to develop, adopt and use to
allow for success during the rebalancing period
• (Avoid use of “SOA” and “REST”– too generic and
confusing)
7/18/2015
14
DRAFT: Roadmap Recommendations: 2015-2017 (1)
• Create a glide-path to Core Composables and
Orchestration Patterns by:
– Supporting SDO and public-private (e.g., Argonaut,
DAF) work to define core composable API services and
profiles (“Core”)
– Support SDO and public-private work to define
orchestrations and related security components for
SMART/mHealth Apps
– Support future work to define other key high value
orchestrations and security components (e.g., Peer to
Peer record access, Remote CDS, Pub Sub)
– Support priority use-cases work (e.g., CDS, PDMP,
SDC, etc.) to be implemented in terms of Core +
Orchestration Patterns
15
DRAFT Roadmap Recommendations: 2015-2017 (2)
• Reduce “friction” and distraction to adopters and
implementers by
– Minimizing certification requirements overall to allow ample
time to pilot, adopt and refine Core and Orchestrations
– Ensuring that government incentives can be met using the
newer approaches, even if not formally adopted into Certified
HIT.
– Continuing to support production adopted standards not based
on Core (e.g. C-CDA, XCA/XCPD, etc.) while minimizing changes
and new uses
– Avoiding endorsing new standards that are not based on Core,
and seek alternatives that are based on Core (e.g., HPD+, CSD,
HIEM)
7/18/2015
16
DRAFT: Roadmap Recommendations: 2018-2024
• 2018-2020
– Refine and extend core composable services, profiles, and
orchestration patterns
– Expand the number of piloted use-cases based on Core
– Address needs for national-scale services such as MPI, RLS,
Directories, etc.
– As Data Sharing Networks emerge, address needs for network-bridging
services
– Consider mature APIs, orchestrations, and use-cases as candidates for
addition to Certified HIT
– Begin transition from non-Core/Orchestration standards and APIs
• 2021-2024
– As above +
– Address complex data profiles that require more robust data models
(CIMI) as may be needed for the Learning Healthcare System
– Contemplate transition to new Core/Orchestrations
7/18/2015
17
DRAFT Transition Paths (For Discussion Only)
Examples paths from production adopted standards to
approaches based on Core Composables and Common
Orchestrations
2015-2017
2018-2021
Direct and
Directed
Exchange
• Continue interoperable trust and
EHR workflow
• Pilot FHIR-based content
packaging and edge APIs
• Adopt FHIR-based content
packaging and edge APIs
• Pilot and adopt native FHIRbased Directed Exchange
XCA/XDS
• Continue interoperable trust and • Prefer MHDv2 for new goEHR workflow
lives
• Use MHDv2 in parallel with
• Adopt discrete data
XDS/XCA document exchange
exchange
• Pilot use of FHIR for discrete data • Start phase over from
exchange along with MHDv2
XCA/XDS to Core
7/18/2015
18