Annual Evaluation of Health IT: Are We Stuck in a Holding Pattern? (Part 2 of 3)

Posted on April 14, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site ( and other publications on policy issues related to the Internet and on 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. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

The previous installment of this article was devoted to the various controversies whirling around Meaningful Use. But there are lots of other areas of technology and regulation affecting the progress (or stasis) of health IT.

FHIR: Great Promise, But So Far Just a Promise

After a decade or so of trying to make incompatible formats based on obsolete technology serve modern needs such as seamless data exchange, the health IT industry made a sudden turn to a standard invented by a few entrepreneurial developers. With FHIR they pulled on a thread that will unravel the whole garment of current practices and standards, while forming the basis for a beautiful new tapestry. FHIR will support modern data exchange (through a RESTful API), modern security, modern health practices such as using patient-generated data, and common standards that can be extended in a structured manner by different disciplines and communities.

When it’s done, that is. FHIR is still at version 0.82. Any version number less than 1, in the computer field, signals that all sorts of unanticipated changes may still be made and that anyone coding around the standard risks having to rip out their work and starting over. Furthermore, FHIR is a garment deliberately designed with big holes to be filled by others:

  • Many fields are defined precisely, but elements of the contents are left open, such as the units in which medicine is measured. This is obviously a pretty important detail to tie down.

  • Security relies on standards in the OpenID/OAuth area, which are dependable and well known by developers through their popularity on the Web. Still, somebody has to build this security in to health IT products.

  • Because countries and medical disciplines vary so greatly, the final word on FHIR data is left to “profiles” to be worked out by those communities.

One health data expert I talked to expressed the hope that market forces would compel the vendors to cooperate and make sure these various patches are interoperable as they are pieced into the garment. I would rather design a standard with firm support for these things.

Some of the missing pieces can be supplied relatively painlessly through SMART, an open API that predates FHIR but has been ported to it. An impressive set of major vendors and provider organizations have formed the Argonaut project to carry out some tasks with quick pay-offs, like making security work and implementing some high-value profiles. Let’s hope that FHIR and its accompanying projects start to have an impact soon.

The ONC has repeatedly expressed enthusiasm for FHIR, and CMS has alerted vendors that they need to start working on implementations. Interestingly, the Meaningful Use Stage 3 recommendation from CMS announces the opinion that health care providers shouldn’t charge their patients for access to their data through an API. An end to this scandalous exploitation of patients by both vendors and health care providers might have an impact on providers’ income.

Accountable Care Organizations: Walls Still Up

CMS created ACOs as a regulatory package delivering the gifts of coordinated care and pay-for-value. This was risky. ACOs require data exchange to effect smooth transfers of care, but data exchange was a rare occurrence as late as 2013, and the technical conditions have not changed since then so I can’t imagine it’s much better.

Pay-for-value also calls for analytics so providers can stratify populations and make rational choices. Finally, the degree of risk that CMS has asked ACOs to take on is pretty low, so they are not being pushed too hard to make the necessary culture changes to benefit from pay-for-value.

All that said, ACOs aren’t doing too badly. New ones are coming on board, albeit slowly, and cost savings have been demonstrated. An article titled “Poor interoperability, exchange hinders ACOs” actually reports much more positive results than the title suggests. There may be good grounds for ONC’s pronouncement that they will push more providers to form ACOs.

Still, ACOs are making a slow tack toward interoperability and coordinated care. The walls between health care settings are gradually lowering, but providers still huddle behind the larger walls of incompatible software that has trouble handling analytics.

I’ll wrap up this look at progress and its adversaries in the next installment of this article.