The ONC’s JASON Task Force (JTF) delivered its final report on October 15th to a joint meeting of the Health IT Standards Committee and Health IT Policy Committee. The task force recommendations are published in presentation slides and in a detailed report. The original JASON report completed in November 2013, titled “A Robust Health Data Infrastructure”, has been criticized as being neither robust nor realistic. The ONC task force was convened to analyze and respond to the JASON report.

The task force report addresses limitations and includes broad ranging policy recommendations for improving health data interoperability in the U.S. It also includes updated system architecture recommendations on how to achieve interoperability. Not surprisingly, HL7’s FHIR draft standard plays a central role in these recommendations. For other viewpoints the ONC meeting and these recommendations, see two articles published by Healthcare IT News:

Keith Boone also blogged about the JTF report, where he concludes:

Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE’s Mobile Access to Health Documents effort). Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed. This kind of thing is nearly unprecedented in health care. To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don’t you think?

A JTF recommendation that is most relevant to my current work is to create a “Public API” for EHR system interoperability. The JTF presentation outlines the general rationale for a Public API, but the report gets more specific on recommending FHIR as the best candidate standard for defining this API:

FHIR as the Public API Technical Standard:

  1. Current exchange APIs (such as XDS/XCA) allow access to structured and unstructured documents, but do not allow direct access to individual data elements. There is currently no widely accepted healthcare industry API that provides discrete data-level access to EHR data.
  2. A healthcare Public API needs to enable access to both clinical documents (e.g., referral summary, discharge summary, etc) and discrete data elements (e.g., medications, labs, problems, etc)
  3. The JTF believes that HL7 FHIR (accompanied by FHIR profiles) is currently the best candidate API approach to data-level and document-level access to healthcare data. (See the Technical Appendix for details.)

The JTF report includes this diagram in its Technical Appendix. It is based on the original proposed JASON architecture diagram, with updates and additions. The blue boxes are additions, and the red text/boxes represent recommended updates based on current standards and practice. FHIR, not even mentioned in the original report, plays a significant role in the updated recommendations.
JTF Public API

I am (finally) ramping up blogging activity to describe my current R&D on:

  • Designing FHIR profiles in UML
  • Binding terminology to information models
  • A UML profile for ISO 11179-3 Metadata Registry (used for binding terminology)
  • Healthcare Services Platform Consortium (HSPC)
  • Clinical Information Modeling Initiative (CIMI)
  • Model Driven Health Tools (MDHT) as a platform for design and deployment
  • Other topics related to implementing these tools in the Eclipse platform