Could the DoD be SMART to Choose Cerner?

Even before the health IT world could react (with surprise) to the choice of a Cerner EHR (through its lead partner, Leidos Health Solutions Group) by the Department of Defense, rumors have it that Cerner beat out Epic through the perception that it is more open and committed to interoperability. The first roll-out they’ll do at the DoD is certain to be based on HL7 version 2 and more recent version 3 standards (such as the C-CDA) that are in common use today. But the bright shining gems of health exchange–SMART and FHIR–are anticipated for the DoD’s future.

HL7, to which all standards go if they have any hope of widespread adoption, offers a number of useful documents and message types for discharging patients, ordering medication and labs, etc. These standards are widely known to fall short in two areas, though. Being document-centric, they are cumbersome for exchanging small amounts of information quickly. And different vendors have trouble exchanging data, partly because the specifications are vague and partly because the developers creating the vendor products don’t follow them precisely enough.

The DoD claims that interoperability was never a big problem and played no role in their choice, but this claim falls flat. Interoperability has been cited as the top goal from the start of the bids, and for good reason–the difficulty in transferring soldiers from the DoD health system to the Veterans Affairs system is legendary. Perhaps the DoD is taking the blame for bureaucratic and cavalier actions instead of blaming technology (a welcome change from most organizations’ excuses), but given the state of data exchange in health care, we must conclude that technical problems exist.

Perhaps, as one author suggests, the DoD based its chose on the main contractor Leidos rather than the subcontractor Cerner, but that begs the question of why Leidos chose Cerner. The question of interoperability still looms large.

All my contacts emphasize that Cerner will start with the familiar HL7 version 2 standards. The other bidders on the DoD project could easily handle these as well. But the current state of data exchange will introduce an impedance.

Remember that data exchange is a two-sided endeavor. I can speak the most eloquent Shakespeare trippingly on the tongue, but if my correspondent can’t understand English, we will have no information exchange. Furthermore, the DoD communicates with many health care institutions besides the VA; it routinely sends soldiers and their families to other health care providers. It’s no surprise that nay-sayers have come out of the woodwork to predict gloom and doom.

But I am optimistic. First we have SMART, an open-source, stable platform that can fix interoperability problems. I have covered it in several articles ranging from 2011 through December of last year.

As an API, SMART allows quick access to data of any size, ranging from a single medication to an entire patient record. It enables the develpment of apps that automate the annoying tasks health care providers currently have to do by hand–apps that will run on any EHR that supports SMART. At the HIMSS trade show this past spring, the SMART team demonstrated SMART-on-FHIR apps running unmodified inside three commercial EHR systems: Cerner, athenahealth, and Epic. Support for incorporating genomic data was recently announced.

Cerner was the first commmercial EHR to create a SMART implementation. Dr. Kenneth Mandl, leader of the SMART project at Harvard Medical, updated me about the VistA side of the equation: the open source WorldVista project and a Hewlett Packard implementation of VistA both support SMART. These versions of VistA, however, are not in use at the VA itself.

The VA version of VistA, however, does support a new standard known as FHIR. I covered FHIR at an early stage and tracked some of its progress.

FHIR could, in theory, be used just as format replacing HL7 version 2. Sites could then create documents in ways they are used to and transfer them through familiar messaging protocols. The advantage of FHIR in this case would be–hopefully–less fuzzily defined formats that reduce the differences that now exist between vendors and currently hinder interoperability. But no such implementations of FHIR are in progress know, so far as I know.

Instead, the field is developing a more ground-breaking implementation of FHIR. This provides not only the format but a set of APIs. The main remaining problem with FHIR, whether used with messaging as an API, is that the current standard is only a starting point. Real use depends on the development of “profiles” that contain all the details.

Luckily, a consortium of EHR vendors–including Cerner and Epic–are working on a project called Argonaut to create a basic set of profiles that should cover the most common use cases in the US. SMART also runs on top of FHIR, solving some of the same problems and making them a good pair.

I would prefer a less closed process. We don’t know why the DoD rejected the open source bid (based on yet another version of VistA), although the conversations I’ve had suggest it just wasn’t up to the job. I don’t accuse the DoD of bias against open source solutions, because they are one of the biggest government users of open source anywhere in the world.

But we also don’t know why they chose the Cerner/Leidos bid and how they plan to direct Cerner’s work, in interoperability and elsewhere. Why the need for closed lips? Let’s see how the process goes, so other institutions can learn from it.

But I understand the DoD penchant for security. After all, there are enemies out there who could take advantage of any weakness acknowledged by th DoD. Their relations with the VA have been sour for a long time.

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.


  • I am doubtful if a move to FHIR as an afterthought would really pan out. It is important that the DoD be clear in its statements on what would be expected out of these contractors. Mixed messages around interoperability do not give me the warm fuzzies and I’m not that optimistic.

  • Anshuman, cynicism is an easy position to take. You have good reasons for expecting failure (and so do the “nay-sayers” whom I already pointed to in the article), but where doest this stance take you? Does it lead you to do nothing? This means current systems cannot achieve interoperability. Because most systems must move current patients to a new system such as FHIR, you’re saying that basically all systems will fail. I think we need to assume that creativity can find a way forward. I suspect that disruptive innovation will come from outside the established EHRs (such as from patient repositories) but the established EHRs need to evolve too.

Click here to post a comment