Argonaut Project is a Sprint Toward EHR Interoperability

The Argonaut Project that launched last week offers a real chance at much-needed workable EHR standards. But by itself, Argonaut won't lead to interoperability nirvana.

In Greek mythology, the Argonauts, accompanied by heroic Jason, had to snatch a golden fleece from a dragon who never slept. In 2015, the Argonaut Project aims to snatch a true interoperability demonstration between EHR competitors and help healthcare providers who've spent many a sleepless night trying to figure out how they can survive in this new age of sharing EHR data.

Announced at last week's HL7 Policy Conference in Washington, the Argonaut Project has the backing of heavyweight EHR competitors Epic, Cerner, McKesson, Meditech, and athenahealth, as well as heavy-hitting providers Partners HealthCare in Boston, Intermountain Healthcare in Salt Lake City, Beth Israel Deaconess Medical Center in Boston, and Mayo Clinic in Rochester, MN.

So how bowled over should we be by this announcement?

First, consider that every EHR provider listed above is a member of HL7, a nonprofit standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information. (With one exception: athenahealth let its membership in HL7 lapse in 2013, but a spokesperson tells me its renewal should be finalized by the end of this month.)

In short, these fierce competitors already meet around the HL7 table. So this wasn't exactly a Camp David moment for healthcare IT. More like a lively meeting of the United Nations.

But Argonaut is important. It represents a "code sprint" aimed at delivering something in April or May that could prove or disprove the utility of the new HL7 Fast Healthcare Interoperability Resources (FHIR) technology that aims to make sharing healthcare data more like sharing data on the Internet.

If the effort succeeds, it means peeling away a layer of the wall preventing interoperability between systems. Its goal is nothing less than providing a way for developers to create applications that could, given proper provider authorization and user authentication, allow data to flow much more freely than it does today.

In Search of Better Standards

Of course, to get there, the Argonauts still have to demonstrate FHIR in action, reading from and writing to Epic, Cerner, and other EHRs. The driving force behind that is longtime standards proponent Micky Tripathi, head of the Massachusetts eHealth Collaborative, who has committed his organization to serve as the project manager for this initiative.

Tripathi also co-chaired the JASON Task Force. JASON itself is a series of reports from a secretive group of scientists commissioned by the White House to make recommendations on a variety of subjects, including healthcare IT. This ONC task force wrestled with some recent JASON findings and concluded that a set of Web-friendly, standardized programming instructions (APIs) could make it easy for any developer to add health data interoperability to their applications on any device.

Although some longtime developers disagree, Tripathi asserts that APIs from the EHR developers and other consortia like Healtheway are too complex, require too much study, and of course are too numerous to promote widespread sharing of health data.

Standards groups who based their interoperability strategies on older, heavyweight tech specifications—groups such as the eHealth Exchange and the CommonWell Health Alliance—are finding the going slow and tough, Tripathi notes. Some of them assume "a lot of very specific workflows in terms of the way a physician or a hospital would have to do something, in order to even send that information or receive it," he says.

If the FHIR code sprint is successful, it will start to dissolve a model of interoperability that relies upon vendor acquiescence, larded with a layer of government-run software certification—an approach that has already been losing momentum.

Instead, the new model looks more like the way the Internet stood up: rough consensus and running code as requirements for standards, rather than attempts at standardization-by-committee.

The Road to Interoperability Nirvana

If I've learned anything covering IT for 33 years, it's that each way interoperability comes about is its own peculiar story. There is no one right way. So why do I think Tripathi's effort, which after all is just one of many efforts of late, including one announced recently by the eHealth Initiative, is particularly noteworthy?

For one thing, HL7's old-style program interfaces seem to have stumbled. HL7 version 2 has been the unseen workhorse that quietly moves a lot of healthcare data around between heterogeneous systems today. But version 3 has been a fumble, so HL7 itself is casting about looking for a new way to do things. That gives FHIR, itself a product of HL7, the inside track.

The other good thing FHIR does is retrieve information in chunks smaller than entire documents more efficiently than occurs in other healthcare interoperability schemes. Too many older-style mechanisms bring back an entire document, says Tripathi, which makes no sense when a patient is trying to use a mobile phone to retrieve a list of medications.

Now that I've raved about FHIR and Argonaut, I will note why having running code in April still leaves us a long way from interoperability nirvana.

Many EHR vendors, including Epic, have had ways to get data into and out of their EHRs for years. The issue isn't just programmatic. It is about the legal and business agreements that third parties have to reach with vendors to get the data out. In Epic's case, a transaction fee is paid for Epic's trouble in extracting or inserting the data in question. Epic isn't alone in charging for this service. Just because Epic supports Argonaut, it is not committing to waiving those fees in the future. The hope is that the new FHIR interface is easy enough to use and manage that Epic won't have the overhead it currently does and will be able to waive the fees. (In other ways, Epic is actually more liberal in allowing access to certain non-EHR apps and services than its supposedly "open" competitors are. But that's a topic for another column.)

Note that last week's announcement doesn't even say that Epic or any participant is committing to using the fruit of Argonaut's efforts. All participants are providing resources, including undisclosed sums of money, primarily to HL7 to get the code sprint to April, but after that, Argonaut’s story, and FHIR’s, are as yet unwritten… 

Tripathi hopes that his effort is so successful, it won't even matter if FHIR gets baked into meaningful use stage 3. Since we still don't know just how badly stage 2 has stumbled (those attestation results have been pushed back to the end of this month), it is still unclear if the old notions of stage 3, and of certified software, will soon be irrelevant to healthcare IT. Or if FHIR will work so well, no one will care.

The truly radical notion of this public API is that the existing certification of healthcare information technology in order to achieve certain standards compliance just kind of goes away. Implementations either work or they don't. That's the beauty of the way the Internet was built: one interop event at a time, with the standards worked out in parallel or at the end of the process.

Websites for the longest time didn't need to have anyone's permission to exist. (App stores for mobile devices do have such permissions, but they are still relatively loose compared to the old IT way of doing things.) We are talking about a future where the app that connects you to your electronic medical record is one that you choose, not one that is strictly approved for your use. Where the patient portal you choose succeeds on its merits, not on the fact that the EHR vendor built it.

And where yes, some bad things can happen; some bad apps can try to abuse or fudge with health data, but rather than them being regulated out of business, buyers must beware, and the court of public opinion will simply swarm over bad apps and put them out of business through general condemnation and the power of social networks.

A lot of people believe that is a future worth striving for in healthcare IT. We are about to start finding out if we as an industry can take some major steps in that direction.