A Business Case for Interoperability

There are lots of challenges with #interoperability, but we can overcome those with some creativity and focus on business value.  I'd like to challenge a couple of the statements that HL7 CEO Charles Jaffe made in a recent interview with Healthcare IT News: that adoption is slow because the financial rewards aren't in place and that effective data sharing can't be achieved until we all have the same terminology.  If we look at the underlying assumptions differently, we can pivot toward solutions rather than excuses.

Assumption #1 - "You can't expect the for-profit vendors to connect everyone on their own dime..."

Jaffe contrasts healthcare to banking in the interview, suggesting that interoperability is like ATMs.  That comparison boxes in our thinking about interoperability and sets up an artificially constrained business model.  We’re not talking about giving away access to the healthcare asset free of charge to consumers.  If this was a real parallel to banking, we’d be talking about a situation where the bank charges you whenever you want to see you balance or your transaction history; or the bank charges you to connect your account with Mint.com. Interoperability in the banking sector isn’t about letting consumers withdraw their assets, it’s about allowing consumers to let their various financial service vendors share balance and transaction data.  Consumers don’t see a line-item, per usage charge for that capability.

Innovative healthcare vendors and providers need to shift their business strategy to think about interoperability as a strategic advantage rather than a threat or yet another cost of doing business.  “Choose us as your primary care relationship and we’ll make sure that everyone involved in supporting your care has ready access to the information you want to share with them, and you won’t have to pay us or them for it.  It’s just included in our service to you.”  Perhaps with the caveat: “…as long as you maintain a minimum level of service with us throughout the year.”

Some providers may not have the capital available to make this level of investment, but there are ways around that, too.  The largest healthcare systems certainly do have the capital and should be looking at interoperability as another value-add service that can provide to improve the experience and outcome for their patients.  Their contributions to the industry can be a rising tide that helps everyone in a way that aligns to their core mission.  The largest interoperability success story of all time, the Internet itself, is a major success not because of central funding and control.  Interoperability winners will show their success through market share gain, service diversification, revenue growth, and profitability.

Assumption #2 - "If I use a term with which you’re not immediately familiar, you’ll ask what do you mean? The computer can’t do that."

A computer can’t ask another computer questions?  Since the 1980s, when I call in to a support line or help desk, a computer walks me through a series of questions to understand what services I need and what my problem seems to be.  Computers negotiate conversations back-and-forth all the time to clarify intent and understand the meaning of their communications.  When a client computer tries to communicate with a server, there are often several layers of negotiation and progressive clarification.  Application Layer Protocol Negotiation (ALPN) is commonly used to help clients and servers negotiate in real-time how they are going to communicate.  There doesn’t have to be one single standard that covers every kind of application communication.

Imagine this scenario in healthcare interoperability with two computers negotiating back and forth at a few milliseconds per transaction:

Sender:        I need to transfer a patient to you.  What transfer protocol do you use?

Receiver:     First, tell me what kind of service the patient requires.  I prefer that you use SNOMED CT Clinical Findings?

Sender:        I can’t use SNOMED CT Clinical Findings, but I can use FHIR ServiceType.

Receiver:     OK, I can receive FHIR ServiceType.

Sender:        This patient needs FHIR ServiceType 1 – Aged Care Assessment.

Receiver:     Thank you. I understand.  Please use transfer protocol version 2.

Sender:        OK, the patient transfer information is: John Smith, Medicare ID 1EG4-TE5-MK72, Aged Care Assessment, Requested Appointment Date: 2017-11-30 09:00-09:30.

Receiver:     OK. To confirm patient identify, do you have the patient’s birth date and sex?

Sender:        Yes.  1948-04-03.  Male.

Receiver:     OK.  I have been able to confirm the identify of this patient and that Medicare ID number.  Do you have a medical history from the last 180 days?

Sender:        I do not.

Receiver:     OK.  In that case, the appointment will need to be 45 minutes.  The closest appointment available is on 2017-11-30 from 10:00-10:45. Will that work?

Sender:        That will work.  Please confirm…

Receiver:     Appointment confirmed.

What this model of interoperability gives us is the ability to build incrementally and prioritize the connections where the most value is created.

You can see where HL7’s CEO is coming from, though.  The technical work of interoperability is about the data formats, taxonomies, and message types.  This conversational model feels much more complex, but what it does is restructure the work of interoperability to be more like an interactive and dynamic language than a static messaging protocol.  Computer science is adept at designing, building, and continuously evolving very rich languages that can be interpreted by machines.

The HL7 and industry terminology standards are all a strong technical foundation.  The next step is to implement a layer of interoperable communication processes (not applications).  At first, these will be specific to the healthcare provider or enabled by third-parties that are able to gain sufficient traction in a narrow industry niche.  Only over time will those evolve into broader standards that get rolled into big vendor platforms.

The Building Blocks

We have the building blocks in both of these areas to accelerate the adoption of healthcare interoperability, and we can motivate that progress with a few changes in how we approach the work:

1. Align the development of interoperability with existing business objectives and enhance existing business strategies with interoperability capabilities.
2. Do the work of building interoperability capabilities not as an infrastructure cost, but with a narrow scope, targeted at a specific business outcome.
3. Use a scalable, flexible, and modular system architecture in creating an interoperable process.
4. Build using lean startup techniques, like the minimum viable product, with a backup manual process; then grow from there until interoperability handles 99% of scenarios.
5. Contribute and share the solutions that you deliver with the industry at large. You might be able to monetize those yourself, but it will at least raise the tide for the industry as a whole and support your mission of patient care.

Again, to step forward toward an interoperability solution we will need to ask ourselves questions that shift our underlying assumptions. We will not get there if we assume our excuses are valid.

One of the first questions to ask is whether or not you want to be part of the solution. Do you?