Is Interoperability Possible in HIT? And if it Is, Do We Even Want it?

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.

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

7 replies »

  1. I don’t know about other systems but epic is horrible for the end user and patient safety. And this is ” best of breed”? I think this is a case of the emperor has no clothes. Large hospital systems have poured billions into this, thinking it would be a market advantage and comply with regs. Now no-one can admit the system isn’t fulfilling the dream. Interfaces are cobbled together that provide no real integration or interoperability. Physicians and caregivers are rendered inefficient and doing major work arounds just to get through the day. Patients have no idea what is going on. These systems are built for revenue and data capture that does not enhance care.

  2. The systems within the Mayo Clinic can not communicate with each other.

    Cerner ought to get its act together in the UK before trying to determine policy in the US. Docs there are none too happy with the care from its devices.

    But here in the states, doctors are beaten into submission. Use the devices or you are out.

  3. All of this talk about interoperability is just talk. Within a Trust, the systems do not talk w eachother. The interconnected devices wiring up the ancillary services with the EHR and CPOE devices have interfaces that oft fail. The clinician can not trust these systems of devices to provide accurate communication.

  4. Your priorities are backwards and delayed by nearly a decade. Brailer was mouthing interoperability in 2004.

    You have the cart before the horse. You guys are talking about interoperability when the basic devices to be hooked up are flawed and dysfunctional.

    Simply put, most EHRs and their associated ordering devices are exemplars of bad healthcare in formation technology. They have not been approved as being safe as required by the F D and C Act.

    Neal’s company Cerner was featured in the UK news as the cause of finacial calamity at at least one trust: http://www.ehi.co.uk/news/EHI/8382/royal-berks-finances-hit-by-millennium And he is a spokesman?

  5. The most surprising thing is that fact that everyone is so surprised. As the author appropriately points out, it is not in their business model for the WMR vendors to integrate. Plane and simple. Government intervention? Not likely. Do some poking around and you’ll find that Judy Faulkner (EPIC’s CEO) is a primary donor to the DNC and the sole industry representative on the Meaningful Use standards committee.

    Democracy in Action 🙂

  6. 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?

    This is the nub of the problem, to be sure. The point is valid and well-made. It seems resistance to the end game is built in.

    I’m no expert, but my instinct is that what we are facing is how best to deflate one of the biggest economic bubbles of our lifetime. Unlike others wherein people lost houses or investments or part ownership in REITs or commodities — the health care bubble is both bigger and with more at stake. Large swaths of jobs, involving not only the professionals but ancillary and support industries (property management, housekeeping, nutrition, accounting, etc.) will eventually be eliminated as one of the world’s biggest multi-sourced revenue streams (er, schemes) gets smaller. It won’t dry up, as in the case of other bubbles, since the need for health care will never go away. In fact, an aging baby boom may have a cushioning effect over the next decade or so.

    But in the end, as health care costs are be brought under control, tons of money will be leaving the table. Hopefully advertising expenses will be among them. But where I am going is this — there is and will be for some time a transitional HIT phase as well. Proprietary, i.e. “billable” information will eventually face consolidation instead of being strung out among a swollen field of medical and insurance companies, all scrambling to add a few more ounces to the pounds of billing flesh already crippling the system.

    I see the shrinking of what we now have to where we need to be (in a distant future, not likely in my lifetime) as a process best not rushed. I favor allowing the market to shrink as the forces of reform, whatever that means, make inevitable and irrevocable changes. Sooner or later as that billable part shrinks the interoperability part will finally take its place.

  7. From our experience with HIT integration, the major roadblock we had was dealing with the godawful HL7 ‘standards’. No modern interface would be designed as HL7 is now, and the standard isn’t even an open standard! It’s behind a massive paywall!

    Not to mention, when you can change the meaning of a message by putting one “|” in a different place or using unix line endings instead of just carriage returns, that makes for a very fragile system requiring lots of [expensive] customization.

    As a small Oncology EMR company I was not surprised when the local hospital using Cerner turned us down for integration cooperation. Maybe that would be less likely if there was a sane, reliable transport standard (That was open-source).