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 Amazon.com 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 Amazon.com 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.