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.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.