Download
1 / 9
90 likes | 181 Vues
JASON Report Task Force. Micky Tripathi, co-chair David McCallie, co-chair. September 18, 2014. Updated Meeting Schedule. JTF – Work plan for remaining meetings. Meeting 1 (16 Sep 2014) Review comments/direction from HITPC & HITSC
E N D
JASON Report Task Force Micky Tripathi, co-chair David McCallie, co-chair September 18, 2014
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) • Complete discussion of Public APIs and Key Architecture Principles • Discuss annotations for the JASON “architecture diagram” • Discuss Policy Questions • Meeting 3 (1 Oct 2014) • Discuss “Privacy Bundles” • Review JASON-to-PCAST mapping • First review of final report • Meeting 4 (8 Oct 2014) • Final review of final report
What is a Public API? (Updated) • JASON repeatedly refers to a “public API” • “Public” implies a mix of standards + governance • These comments apply to a “Public API” to address interoperability in health care • Proposed definition for implementationof 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 • If extended, the implementation shall follow the standard’s regular method for extensions • Should support public documentation for custom API and/or custom Profile extensions • Shallenable 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)
Key Architectural Principles (Updated) • Centralized coordination rather than top-down control • Architectural patterns: • Loosely coupled, ReSTfulInternet-style 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 • Support asynchronous upgrades (backward compatibility to allow for rolling upgrades) • Respect Postel’s principle (send conservatively; receive liberally) • Support use-case appropriate, standards-based authentication and authorization standards • Implemented with best practice encryption and key management • Expose API for patient care, consumer access, and population/research • Reuse core data definitions as much as possible, but allow for necessary variations by domain of usage, since profiles and access patterns may vary • 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, and other endpoints) • Authentication, authorization, key management • Consent and privacy preferences • Directories and data indexing services (supporting search) • Complex orchestration and transactions services (SOA)
Possible implementation building blocks(for discussion) • We may decide that we don’t want to go this far with our Task Force recommendations, but we could at a minimum identify the key areas and propose that the HITSC make specific recommendations • Key areas: • Base API – FHIR • Document access – Initially continue static XCA/CCDA, with phase over to FHIR • Data element access – FHIR • Base Profiles • FHIR Profiles from Health Service Platform Consortium? • Refocus Data Access Framework? • New, deliverable- and timeline-focused, ONC-initiated collaboration or contracting? • Auth/Auth – use case specific • Consumer access via tethered portal – OAuth2/OIDC (i.e., updated Blue Button Pull) • Remote access into EHR – Network-specific choices (OAuth?) • Semantics • Use FHIR Profiles for initial phases • National Value Set repository (NLM) for core profiles • Modularity • SMART on FHIR for EHR modules • TBD for SOA modules • Population health data • Consider FHIR Bundles, FHIR pub-sub? • Other areas?
JASON Example Architecture(With proposed mapping to standards) Key Network & Governance Issues Public API User Interface and Middleware Apps OAuth2/OIDC (e.g. SMART) Search and Index Functionality XCA FHIR “Push” Services FHIR Core Clinical and Financial Systems Patient & Provider Identity, Authentication, Authorization, Demographics Decision support FHIR Key and Certificate Management ValueSet & Metadata Standards & Services Patient Preference Management Patient - Provider Relationships Semantics and Language Translation FHIR Profiles “Atomic” & metadata FHIR “Population” level data FHIR “Clinical docs” XCAFHIR Crypto Layer (leverage existing approaches) Data Storage (logical) Data Transport (logical) Data Storage (physical) Data Transport (physical)
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 • What should be the first “Public API” use-cases? • EHR to EHR/HIE interchange? (e.g. eHealthExchange, CommonWell, etc.) • Consumer access via Portal (e.g., Blue Button Pull) • Pluggable apps? (e.g., SMART, etc.) • EHR to Population Health and Researchers? • Role of markets vs. government in reducing “barriers to legitimate data flow?” • Should (vendor) certification (CEHRT) of public API be required, voluntary, or neither? • Should HCO grants of external access to their implementation of the public API be mandated? • If so, under what conditions? (Trust, certification, license, cost…) • If so, how? Incentives? Governance? Other levers? • What constitutes a “network” around use of these APIs? • Assuming there is more than one network, should network-to-network bridging be required or voluntary? • How to coordinate cross-organization (network) services? • What should be required within networks? • How to motivate the creation of a market ecosystem to support loosely coupled approach? • How can we leverage “lessons learned” from Direct/HISP, eHealthExchange, CommonWell, Carequality, etc?
