Recently I was asked to provide testimony to the ONC hearings on the JASON report, from an openEHR point of view. I did so on 31 July 2014. The JASON report is entitled “A Robust Health Data Infrastructure”. It surveys the problems of health data interoperability, and proposes the adoption of a unifying ‘software architecture’ as the solution. It also seems to imply a federated health record database. It’s primary assumption appears to be that APIs are the key element of the solution, and that their standardisation will fix the problem.

I made some comments on the report, as well as to specific ONC questions. These are attached below, and is summarised as follows:

• the problem needs further articulation before a wide-ranging ‘solution’ can be defined.
• the nature of the problem (as known by many of us working for many years on it) is such that a ‘software architecture’ can only be a small part of any overall approach, and that the solution concept needs to be reframed as an open platform definition.
• most of the semantics that needs to be standardised are outside software and APIs, and found in artefacts like terminology, DCMs/archetypes, guidelines and ontologies.
• defining APIs without detailed content and workflow definitions won’t solve the problem.
• a content-based querying methodology needs to be part of any solution.

Here are some related resources:

• ONC JASON testimony page
• My response document: ONC-JASON-openEHR
• My testimony slides

One of the specific questions, which is of some interest in the general API discussion, along with my answer is reproduced below.

A key recommendation of the JASON Report is that EHR vendors should be required to develop and publish APIs for medical records data, searching and indexing, semantic harmonization and vocabulary translation, and user interface applications.  What existing  efforts are underway in health care that could inform the implementation of this recommendation?

We don’t agree with this recommendation as it is stated. Given that directive, EHR vendors will most likely develop and publish their own APIs, and particularly their own content and terminology models, and the situation will be as bad as it is now. Not only would they build their own, but the program they follow would be individual to each vendor.

Instead, the platform specification (including APIs) needs to be primarily outside the vendors, and managed by organisation(s) on which vendors (and other experts) can be members. See the comments above about platform-related roles & stakeholders.

Open source implementation of interoperability components should be built – these have two effects:

• Establishes a computable form of each ‘standard’
• Removes the need for each vendor to ‘implement’ the standard(s) from scratch, thus reducing industry resistance.

It is crucial to establish an architectural board for any JASON-like architecture, as would be found in efforts like FHIR, openEHR, and emerging in HSPC for example.