Is HIT interoperability in the nature of healthcare?

Anyone who understands the importance of continuity of care knows that health information exchange is essential. How are we supposed to cut waste and duplication from the healthcare system and truly focus on patient welfare if doctor B has no idea what tests doctor A conducted, or what the results were?

The predominant proprietary HIT vendors know this, yet have engaged in prolonged foot-dragging on interoperability and even basic data interfacing. Yes healthcare IT is their business, but interoperability is not in their nature.

As we’ve seen before, the problem is with the business model.

The proprietary business model makes the vendor the single source of HIT for hospital clients. Complexity and dependence are baked into both solutions and client relationships, creating a “vendor lock” scenario in which changing systems seems almost inconceivable.

In the proprietary world, interfacing with third-party products is a revenue generation strategy and technical challenge; the latter, though unnecessary, justifies the former. When we go looking for the reasons that healthcare is a laggard compared with other industries, this single-source model—the obstacle to much-needed competition and innovation—is a primary culprit.

To be fair, provider organizations, with little if any incentive to exchange patient data before the advent of Meaningful Use, haven’t shown much collaborative spirit either. In the fee-for-service model, why would a healthcare organization let patients slip from their grasp? Health reform is finally mandating needed change, but when will proprietary vendors actually enable the interoperability hospitals and practices soon have to demonstrate?

Recent rumblings from Washington, DC, suggest the feds are losing patience.

"If we do not see sufficient progress or … our policy goals for standards-based exchange are not being met, we will revisit these more specific measurement limitations and consider other policies to strengthen the interoperability requirements...," Farzad Mostashari, National Coordinator for Health IT, said last week at the 2013 Academy Health National Health Policy Conference. "I want there to be no question about the seriousness of our intent on this issue. [The] bottom line is it's what's right for the patient and it's what we have to do as a country to get to better healthcare and lower costs."

Even before Mostashari’s comments made the news, rumors were flying of Cerner and McKesson working on an agreement to make their EHRs “interoperable”. Framed as a technical development in the world of health IT, the potential Cerner/McKesson agreement is nothing more than a business decision—an attempted differentiator—driven by the success of Epic.

In fact, the technical interfaces and open standards are well established. There is no great technical interoperability challenge that requires the coordinated efforts of two industry heavyweights. We should recognize Cerner and McKesson for making tentative steps toward openness, but casting this as some kind of technical breakthrough does nothing to advance the cause.

Indeed, when Cerner CEO Neil Patterson recently told a joint public hearing organized by the Office of the National Coordinator that "no single vendor" can meet all the needs of a provider, he was talking about Epic.

"Cerner is … committed to an open healthcare ecosystem… to enabling data liquidity for every product … to enabling our solutions to send and receive data in a universal manner … to putting these principals to work for every system in every venue of care."

In other words, Cerner is willing to do everything Epic is not.

Again, while the commitment to data exchange is progress, we are still just talking about exchanging data, not true interoperability. Let’s look at a couple of definitions.

From the Institute of Electrical and Electronics Engineers (IEEE) Glossary definition on Wikipedia:

The ability of two or more systems or components to exchange information and to use the information that has been exchanged.

So narrowly tailored, this concept might be better defined as “interface-ability” or simply data exchange. And it completely lacks context, which matters a lot to those of us in health IT. There is no mention of the technical challenge and costs. There is no concept of separate systems operating together, which is requisite. And there is no mention of the alternatives.

Compare that with another interoperability definition found on Wikipedia:

Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation.

This definition, much closer to genuine interoperability, is arguably what Kenneth Mandl and Isaac Kohane of Harvard Medical School had in mind in 2011 when they published "Escaping the EHR Trap – The Future of Health IT" in the New England Journal of Medicine:

"We believe that EHR vendors propagate the myth that health IT is qualitatively different from industrial and consumer products in order to protect their prices and market share and block new entrants…"

Speaking to InformationWeek later on, Kohane went further and named names: "Leading companies like Epic will claim that it's unsafe for health IT to be done outside their monolithic system and that their monolithic system is actually enabling patient safety and the correct conduct of healthcare process."

Mandle and Kohane describe an interoperability that goes beyond mere interfaces and data exchange. Indeed, the fulcrum of this advanced interoperability is open application programming interfaces (APIs), which enable applications to quickly, easily and affordably integrate with the core EHR. Think of all those iPhone apps in the iTunes store and then recall that Apple doesn’t even make open systems.

Right now open APIs are most frequently associated with the Web and work being done by companies like Facebook, Google, Salesforce and LinkedIn, which might seem irrelevant but is anything but. True interoperability in healthcare will result from tightly secured Web-based applications that enable a circle of accountable clinicians to work together with optimal patient health—not a billable test or procedure—as the ultimate goal. Does that sound like something simple data exchange can accomplish?

Policy and industry dynamics are moving toward data exchange, which is merely a precursor to a new healthcare business model and a safer health system with lower costs and better quality. As the paradigm shifts, we will follow other industries and move from interfaces to interoperability and real collaborative care. And we’ll recognize that open APIs eliminate the obstacles to interoperability that stifle competition and innovation.

Up next: Exploring how the open source industry has proven that interoperability is both possible and actually inevitable.

Edmund Billings, MD, is chief medical officer of Medsphere Systems Corporation, the developer of the OpenVista electronic health record.


How does Medsphere and Vista handle interoperability. Sure, the code is open source, so anyone can go in and extend it as they please, but are there some initiatives in the Vista software to make an open API possible without having to dig into the software code?

Thanks for engaging in the dialogue, John. There are some VistA initiatives focused on extending the platform, but they are pretty VistA specific. To extend the clinical support capabilities of OpenVista, our VistA-derived solution, Medsphere developed a Java-based API layer with a tool set for building Web Services. We call this layer the OpenVista Interface Domain (OVID), and it does enable APIs built by Medsphere and others. We know that other non-Medsphere developers have used OVID for its Java-enabled flexibility to extend the capabilities of VistA and OpenVista.

In terms of open development and data access more broadly, we’ve also developed a tool for the MUMPS database called FM Projection that enables structured SQL views of OpenVista data for various uses. OpenVista is also bundled with the open source MIRTH Connect interface engine, enabling easier and more affordable interfacing than proprietary options.

There are no industry-wide API standards, so Medsphere has not developed specific APIs that are applicable to other platforms and systems. But we’re trying to enable that level of collaboration and promote the idea that broad standards are necessary or health IT will remain badly fractured and we won’t even be able to see true interoperability from where we’re standing.

Unfortunately it takes 2 to tango (or should I say ineroperate), but it seems like healthcare IT is allergic to it. We’ll see if the Cerner-McKesson announcement at HIMSS breaks ground in this regard. Can VistA get in on that announcement?

Hi, John. For true industry-wide interoperability, we’ll probably be doing some kind of coordinated flash mob samba instead of the tango. As many have said already, the expected Cerner/McKesson deal is an attempt to create an Epic-killer. In reality, it simply combines the proprietary energies of two companies pursuing the same monopolistic goals as Epic, which won’t benefit healthcare and will lead to more HIT-related bankruptcies. Medsphere is trying to do something different with OpenVista–something that’s truly open.

I guess that is why I asked. If I get a chance, I’ll be sure to ask the same question at the Cerner/McKesson press event, “Will you open this up to other EHR vendors as well?” If they spout a spirit of openness and collaboration, and then say no they won’t, that will be very telling.

I agree there are some real problems, but I wonder also how this is going to affect what this article is talking about in remote patient monitoring (RPM) –

Something is going to get kicked to the curb if HIT does not improve interoperability soon. I suspect that HHS and CMS will start penalizing HIT systems.

Thank you for your insightful blogs.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.