Why interoperating in healthcare is hard

By Cyrus Bahrassa  LinkedIn

Labyrinth game board with red ball

"It should be easy." If you've dealt with interoperability in healthcare at any point within the past decade, that thought has probably crossed your mind at least once. Innovation and ingenuity have led to software that can chat with you like a human, transmit money to a bank account across the globe, and track a package from the warehouse to the front door. But in healthcare, it can be a struggle simply to pass a consolidated clinical summary from a referring provider to a specialist. In my mind, there are three key reasons why healthcare interoperability remains challenging.


Healthcare technology didn't begin with a culture of interoperability. That's understandable, given that we can trace health information management systems back to the 1960s when the industry was truly entering uncharted waters and our technological capabilities were far more limited than today's. Integrations have been added as business needs arose and standards were defined, but I would argue this bias towards interoperability as an add-on rather than an intrinsic feature slowed its progress.

Even now, the culture of interoperability is nascent and the availability of integrations is incomplete. HL7v2 interfaces are widely supported by EHRs and ancillary systems, but their publisher-subscriber model and lack of inherent security make them ill-suited for modern web applications. API coverage is growing, but among the major EHRs such as Epic and Cerner, the majority of APIs only support pulling data out, not pushing data in, and only for a single patient at a time. Most EHRs, payers, and clearinghouses don't advertise direct database access for advanced data extraction and analytics. And high costs to integrate—which I assert is common throughout the tech industry—can make available integration methods de facto inaccessible.


Healthcare is difficult to distill down to ones and zeros. For one, it is ubiquitous across the globe, which means that healthcare integrations must accommodate the enormous variety of cultural differences. Take something as basic as a patient's name; in the Western world, we are accustomed to a pattern of first names and family names, with most people also having a middle name. How then to interoperate with software designed for a totally different region, such as Ethiopia where patronymics dominate instead? Street addresses provide comparable challenges across borders, yet true interoperability can't function only for Western standards.

Secondly, meaningful healthcare data encompasses an array of data points, types, and formats. There are discrete values like vital signs that boil down to a number with a unit of measure. There are free-text strings ranging from a brief reason for a visit to lengthy rich-text notes. There are images, PDF documents, code sets, and more, some of which could be intensely private or critical for patient care. It isn't like integrating with Google Maps, where a few details about your origin and destination results in a mundane set of driving directions. Healthcare is a reflection of the realities of life, and life is complex.


This factor is the most difficult one to overcome, in my opinion. If healthcare IT is a jigsaw puzzle, modern interoperability is trying to put it together only to realize several pieces don't fit. You might perfect one or two corners, but the full picture can't be seamless.

In healthcare we rely upon a vast number of systems and data repositories, from EHRs to ancillary lab and radiology systems to public health registries and others. No two software applications or databases have the exact same data points and in the exact same format. Not one is an authoritative data source for a majority of patients (at least, not unless Oracle can truly pull off a national health records database—but I digress).

Compare this to, say, developing smartphone apps, where Apple's iOS and Google's Android have cornered the market. To make my app work, I only need to code to the standards of two platforms, and as those standards evolve, I can make updates that work for all users at once. Admittedly I'm oversimplifying—there are aspects such as OS versions to consider—but the permutations are still more limited, and the points of integration will remain the same whether my user is in Jakarta or Jackson Hole.

We simply don't have this luxury today in healthcare technology and we may never enjoy it. No doubt industry standards such as HL7v2, ANSI X12, and FHIR help reduce the complexity of integrations, but they don't eliminate the need for understanding and adapting to the nuances of each source and destination system, which is a time-consuming chore. This will always be a source of friction in the race to build an interoperable healthcare network.

Speed limits remain

The struggle is real. Healthcare could very well be the only industry in the U.S. where the federal government has had to mandate a minimum data set that must be exchangeable through APIs and to specify rules to prevent information blocking. To me, this speaks volumes to how challenging healthcare interoperability remains and how far we have to go. I can't say with certainty where the finish line lies, but I can say the journey isn't easy.


Photo by Alexas_Fotos on Pixabay

Share this post

Subscribe to the blog

Get new post notifications in your inbox