Do We Really Like the JASON Recommendations for Interoperable Health Data?

The health IT community has been abuzz over the past few months about a report released by the Agency for Healthcare Research and Quality. Although the report mostly confirmed thoughts that reformers in the health IT space have been discussing for some time, seeing it aired in an official government capacity was galvanizing. The Office of the National Coordinator has held several forums about the report, known by the acronym JASON, and seems favorably inclined toward its recommendations.

Even though only four months have passed since its publication, we can already get some inkling of how it will fare at the ONC, which is going through major realignment of its own. And to tell the truth, I don’t see much happening with the JASON recommendations. In this article I’ll look at what I see to be its specific goals, and what I’ve heard regarding their implementation:

  • Enabling third-party apps to access EHRs

  • Requiring application programming interfaces (APIs) on EHRs

  • Holding a meeting of biomedical researchers within 12 months

  • Data segmentation, particularly patient privacy bundles

  • Adding provenance/metadata to EHRs

  • Sponsoring code-athons (p. 7)

Carrying these out would be a tall order. I believe years will pass before we see any movement on most of them, largely because several goals depend on major upheavals in the EMR and health IT space, and because some goals depend on the implementation of others.

I haven’t even listed some of the softer, less concrete recommendations in the long and detailed report, which include a revamping of Meaningful Use to enable “an entrepreneurial space” (p. 7), promoting patient control over data, defining an “architecture” that would engender the creation of third-party apps for both end-use activities and back-end data crunching (p. 37), better interoperability among EHRs, access to patient data by biomedical researchers, international interoperability (pp. 54-55), using data analysis to pursue fraud, and solid software security practices to address privacy concerns.

Let’s start with what is probably the central recommendation in the JASON report, a requirement that EHR vendors provide API access. This is a technical way of calling for 21st-century interoperability, because an API means that a programmer can invoke the functions of the underlying platform (the EHR, in this case) and thus automate all sorts of important activities.

Data exchange is hardly going on among doctors at all, as I recently reported, but when it does go on, its digital form utilizes a document format called the C-CDA. This is like if you had to order a book from by downloading a form, filling it out, and uploading it again. Not quite one click.

The JASON report is very insistent on the need for APIs. But in a recent teleconference, when ONC staff and colleagues considered the issue, they came to a consensus that it’s too soon to demand that of EHR vendors. Struggling to provide a poor communication system seems to be an excuse for not switching to a good system. One commenter even said he didn’t think APIs would have any effect on interoperability.

I’m sure ONC will return to the topic of APIs eventually. They actually funded one such project, SMART, and have uttered sounds of approval for another one, FHIR. I covered both in another article.

But the point of the APIs, besides turning data exchange into an order, is to allow new innovators to add new features and functions to EHRs. It could break open this hide-bound area of computing, turning it into a thriving market. Furthermore, the JASON recommendation to hold code-athons presupposes the existence of these platforms would that allow third parties to add features.

You see, everything fits together. You can’t achieve 21st-century results with 1980s technology.

Other JASON recommendations run into intractable paradoxes. For instance, data segmentation is a key plank in their goal of promoting patient control and privacy. However, data segmentation is problematic for several reasons. Hiding information is hard–I know that if I listed the medications I’m on, any nurse or physician could guess what I’m being treated for. And with the spread of dazzling data crunching algorithms, hiding becomes even harder.

The same problems make it difficult to accommodate the needs of researchers. It’s clear that data analysis on massive streams of patient data–including genomes–is becoming the leading area for medical research. But we need new forms of patient consent, which are a research focus of several interested parties but which have not emerged yet. The efficacy of deidentification has been repeatedly criticized, and when genomes are involved, as the JASON report itself says, “there can be no guarantees against re-ID” (p. 53).

Still, a meeting of biomedical researchers would be valuable so that the issues could be laid out and prioritized.

I haven’t heard a peep out of anyone about the JASON recommendation for adding provenance and other metadata to EHRs. This is important to allow patient-generated information to enter the health care stream, which in turn would further everyone’s announced top goal of patient engagement. Both doctors and researchers could do a lot with data from fitness devices and other patient sources, but they don’t have a way to store it or tools to derive insights from it.

I’m not saying that the ONC can snap their fingers and bring modern health IT into being. But we should all be aware of what the technologies promise, what we missing by waiting, and what alternatives are in place.

For instance, hospital CIOs should look very closely at the Cerner EHR if it completes its current SMART project, and any EHRs that achieve SMART or FHIR compliance should be snapped up like water bottles at beach volleyball tournament. By looking at possibilities creatively, we can beat the forces arrayed against change.

About the author

Andy Oram

Andy Oram

Andy Oram writes and edits documents about many aspects of computing, ranging in size from blog postings to full-length books. Topics cover a wide range of computer technologies: data science and machine learning, programming languages, Web performance, Internet of Things, databases, free and open source software, and more. My editorial output at O'Reilly Media included the first books ever published commercially in the United States on Linux, the 2001 title Peer-to-Peer (frequently cited in connection with those technologies), and the 2007 title Beautiful Code. He is a regular correspondent on health IT and health policy for He also contributes to other publications about policy issues related to the Internet and about trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business.


  • An excellent summary of the report. One thing they also said caught my eye:

    “The absence of a unique identifier for an individual can lead to record misidentification, and thereby to the accidental release of information to the wrong individual (a HIPAA violation) or the conflating of two persons’ medical records in the context of either medical treatment or research. Especially with the redaction of records for privacy protection and the sharing of partial datasets, the potential for misidentification is large.”

    This is an issue ONC could use NIST’s guidance on by asking for it the best way to uniquely ID patient records.

  • Thanks, Carl. Patient identification is a controversy fraught with philosophical and political overtones, as I’m sure you know. Congress has ruled out a unique personal identifier, which most countries have. In the same way, the US doesn’t have a national ID (although the Feds are making it hard on my state, Massachusetts, because we didn’t insert REAL ID into our driver’s licenses). The ONC doesn’t even like to talk about patient identification–they talk about patient matching, and have a big initiative around it. I think that’s the best we’ll get.

  • Every Health Portal that I have attempted to sign up for as a consumer in US has terms and conditions that a) say they can be changed unilaterally and b) that the service is not guaranteed. I generally decline the Ts and Cs at that point.
    Does JASON address these issues? In particular, whether the EHR data will always be available.

  • You raise some important points, David that need to be addressed by the PHR market, and if it doesn’t do so, by policy-makers. The JASON report does not look at PHRs closely. It does not really talk about PHRs, although the text makes it pretty clear they support having a patient keep all his or her information together (p. 30). The details are probably outside the scope of the report. But as your comment suggests, we haven’t advanced far if provider control over patient data is replaced by PHR vendor control.

  • Hi team,

    You ‘re right. In the same direction,i’m working in EMR and ELIS(Electronic Laboratory information system) interoperable data


Click here to post a comment