1 / 9

JASON Report Task Force

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

september-vasquez
Download Presentation

JASON Report Task Force

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. JASON Report Task Force Micky Tripathi, co-chair David McCallie, co-chair September 18, 2014

  2. Updated Meeting Schedule

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

  4. 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)

  5. 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)

  6. 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?

  7. 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” XCAFHIR Crypto Layer (leverage existing approaches) Data Storage (logical) Data Transport (logical) Data Storage (physical) Data Transport (physical)

  8. 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?

  9. Blank

More Related