Healthcare interoperability is often treated as a technology problem. Technology is certainly part of it, but I’d argue that today’s hardest interoperability problems are much more about workflow and collaboration.
We have standards, APIs, networks, and platforms capable of moving healthcare data. We have mature testing tools capable of validating whether individual systems conform to those standards. And yet, the ability to make two or more systems work together in a test environment doesn’t always translate cleanly into production.
That’s because moving data is only one part of interoperability.
For many years, technology really was a major part of the problem. Healthcare information lived primarily on paper, and the earliest electronic medical record systems were isolated and proprietary (MUMPS, anyone?).
Over the following decades, healthcare developed increasingly sophisticated standards for representing and exchanging clinical, administrative, and imaging data. HL7, DICOM, X12, SNOMED CT, and others all helped to establish common ways to represent and communicate healthcare information. Those standards have continued to evolve, culminating in modern approaches such as HL7 FHIR that use technologies familiar to today's software developers.
So, the technology is there. The standardization of the technology is, at least at the data element level, mostly there. And yet, we still struggle with interoperability between systems in the healthcare world. So what's going on?
It turns out that getting technology systems aligned to exchange data in a semantically meaningful way is really hard. Like, really, really hard. Collaborative testing events such as IHE and HL7 Connectathons and Plugathons certainly help. Tooling such as Aegis Touchstone and Drummond's FHIRPlace are part of the solution. Governance and national frameworks for data exchange like TEFCA are a great step forward. And yet, we still struggle.
Conformance is necessary for interoperability, but conformance is not interoperability in and of itself. Optionality, interpretation, versioning, extensions, terminology, data quality, and implementation choices all feed into the need for even richer interoperability test suites than what we have today. Interoperability is really a workflow and collaboration problem, and our thinking needs to change in order to see meaningful progress.
Even when the technology works exactly as designed, interoperability can still fail at the workflow level. Information can arrive successfully but at the wrong point in the workflow. It can reach a system without reaching the person who needs it. Organizations can have different expectations about when information should be exchanged, which system is authoritative, or who is responsible when something goes wrong. These aren’t problems that another API or implementation guide can solve on its own.
Interoperability also has a unique ownership problem. Within an organization, technology teams generally have control over the systems they operate. Interoperability crosses those boundaries. A successful exchange may depend on multiple healthcare organizations, technology vendors, networks, and intermediaries, none of which owns the entire workflow. Solving problems in that environment requires more than technical conformance. It requires organizations to collaborate around shared expectations, testing, governance, and accountability.
None of this means technology isn't important. It's foundational to all of this. Without standards such as IHE and FHIR, modern interoperability would not be possible. The harder problems are aligning workflows, agreeing on expectations, establishing governance, testing across organizational boundaries, handling exceptions, and creating accountability when things don't work.
We do not achieve interoperability when two systems connect and exchange data. We achieve it when that exchange reliably enables the people and organizations on either side to accomplish what they were trying to do.