Fundamental problems of interoperability: Why is it hard?

Once again, interoperability is near the top of everyone’s healthcare IT “to do” list this year. This evergreen health IT trend remains unresolved, which executives, clinicians, and patients find exceedingly frustrating. Other industries, from credit card companies to airlines, integrate systems with what appears as minimal hassle. Why does the healthcare industry have such a hard time?

There are some technical, nuts-and-bolts difficulties with getting systems to interoperate, but there are also fundamental, conceptual roadblocks that make healthcare different and harder than other industries.

Follow the money

Financial motivations are a main driver of interoperability in any industry, either reducing the cost required to complete a transaction or increasing the volume or value of transactions. Credit card companies, banks, airlines and other industries interoperate smoothly when doing so facilitates sales.

This is why billing data flows with reasonable efficiency from healthcare providers to insurance companies. It’s a place where interoperability improves cashflow, and it’s an often-overlooked example of effective interoperability in healthcare.

One reason that other types of data don’t move around very smoothly is that one party or the other (or both) are not incentivized to make it easy to share data. In fact, if a hospital holds patients’ medical records as a way of keeping them from seeking care elsewhere, there is actually a financial disincentive to sharing.

The Meaningful Use program’s incentives for sharing healthcare records have somewhat changed the equation, but an artificial, external, one-time-only financial incentive is seldom an effective long-term solution.

Who’s in charge here?

USB is sometimes used as an example of ideal, plug-and-play interoperability. The strict USB standard is one reason this level of interoperability can be achieved, but part of the standard includes clear distinctions between the master and the servant. Your computer commands the hard drive to write a file. There’s no negotiation.

Similarly, financial transactions like credit card charges include one party initiating an authorized transaction and the other party being contractually obligated to fulfill it. Again, no negotiation.

In healthcare, the roles are less clearly defined, and that causes an obstacle to easy integration. One EHR can push a patient’s record to another, but nothing requires the receiver to accept the data. Or, an EHR can try to pull a patient’s record from elsewhere, but there’s no guarantee that the far end of the interface will comply with the pull request.

The absence of an exchange agreement that defines commitments is one problem, but there’s also medicolegal issues at stake. An EHR doesn’t automatically accept every record that might be pushed to it because institutions don’t want external parties contributing data into their official, legal medical records.

Mismatched Models

Consider this use case: a patient presents in the emergency department with symptoms of pertussis. The doctor orders a lab test and confirms a diagnosis of pertussis and notifies the local public health department.

In this scenario, there’s a single subject: a patient with pertussis. But each of the three interested parties has a different conceptual model of the event. The doctor has a patient-centric approach that focuses on diagnosis and treatment. The laboratory’s unit of work is a sample that needs testing. The patient’s information is recorded for administrative and billing purposes but is irrelevant to the test or the results they send back to the doctor. The public health department’s view of the situation is in terms of a case of pertussis that may indicate an outbreak or the need for an intervention.

Doctors think about patients. Labs think about samples. Public health thinks about cases. These different points of view carry over into the workflows and – more importantly for this discussion – the software they use. Different kinds of software have different data models of the healthcare domain. In fact, the same kind of software (for example, two different EHR products) may have different data models because different vendors have solved the problem differently.

In order to interoperate between systems with different data models, two translations are required. The sending system has to convert its proprietary model into a standard format. Then, the receiver has to convert the standard format into its own native format. Each translation is an opportunity to lose fidelity. Even if the participants are willing to exchange data, the results may be far from perfect.

One solution to the problem of different data models would be to make everyone use the same model. This is how HL7 v3 approached interoperability. Unfortunately, a model of healthcare that’s rich enough to satisfy all stakeholders is intractably complex and turns simple integration projects into impractical ones. When everyone shares a model of healthcare, no one shares it.

So now what?

Interoperability fails in healthcare because there are rarely business cases for sharing data, poorly-defined technical contracts built into the standards, and different domain models. So, what’s the answer? Blaming vendors and providers is unproductive. While there is plenty of fault to go around, they can’t solve the problem just by changing their attitude. There is, however, some hope on the horizon.

Value-based reimbursement systems, such as ACOs, may motivate stakeholders to work together to optimize each patient’s care and minimize costs, providing the needed financial incentives to share data. Integration profiles like the ones from IHE prescribe roles, not just data formats, for the participants and provide at least a modicum of compliance testing. Emerging standards like FHIR are creating a healthcare data model that is standardized but lightweight enough to be practical.

We’re still pretty far from solving the interoperability problem, but with persistence maybe it will someday fade from the top of everyone’s list of major health IT initiatives.