Healthcare Data Interoperability: Making Systems Speak One Language

Interoperability is the sub-topic of healthcare data that decides whether your systems can actually work together. In my healthcare data pillar I call it one of the four core problems, and it is the one people most often mistake for solved. They see a file move from one system to another and think the job is done. It is not. Moving the data is the easy half. Making both sides agree on what the data means is the hard half, and it is where most of the value and most of the pain live.

So here is my definition, the one I actually use. Interoperability is getting information to move, and mean the same thing, across every system that touches it. Two parts, both required. If the data moves but the meaning drifts, you have exchanged noise. If the meaning is shared but the data cannot move, you have a museum. You need both, and you need them at the same time.

Moving data is not the same as understanding it

The most expensive mistake in interoperability is treating transport and meaning as one problem. They are two, and they fail differently. Transport is plumbing: an API, a message, a file drop. It is largely solved, and standards like HL7's FHIR make it routine. FHIR, the Fast Healthcare Interoperability Resources standard, gives systems a consistent, well-specified way to exchange healthcare information. That is real progress, and I lean on it. But FHIR moving a lab result cleanly does not guarantee that the code inside that result means the same thing to the system receiving it. Transport gets the envelope there. It does not read the letter.

The four levels of interoperability

Interoperability is not a switch you flip, it is a ladder you climb, and each rung is harder than the last. The industry's common model has four levels, and I find it genuinely useful for locating where a team actually is. Foundational is the bottom: two systems can connect and send something. Structural is next: the data arrives in a predictable format, fields in the right places. Semantic is the hard one: both sides share the meaning, so a code means the same condition everywhere. Organizational sits on top: the governance, consent, and workflow that let the exchange happen in practice, safely and legally. Most teams are proud of foundational and structural, and quietly stuck below semantic. Semantic is where the real work is.

The standards I actually reach for

You do not need every standard, you need the right one for the job, and the jobs are different. Here is the short version of what I reach for and when. FHIR for exchange, when I need systems to send and receive data cleanly. OMOP, the common data model from OHDSI, for analysis, when I need many sources to line up into one shape I can query and model on. Terminologies like SNOMED, LOINC, and ICD for meaning, because they are the shared dictionaries that make a code mean one thing. And HL7 version 2 is still everywhere in the plumbing, so I plan for it even when I wish I did not. The mistake is picking one and expecting it to do every job. Exchange standards and analysis models are not substitutes. They are partners.

Where interoperability really breaks: the semantic gap

When interoperability fails in practice, the wire is usually fine. The meaning is what broke. Picture the same patient, the same condition, in two systems. One encodes it one way, the other another way, and a third might spell it out in free text. Transport moves all three faithfully. But unless something maps them to one shared concept, the receiving system sees three different things, or worse, treats them as one and averages them. That mapping layer, the unglamorous translation from local codes to a shared vocabulary, is where interoperability is actually won or lost. It is also the first thing cut when a timeline slips, which is why so many integrations technically work and practically do not.

How I would sequence an interoperability effort

If I were standing up interoperability from scratch, I would not start with the exciting API. I would start with meaning. The order I trust runs opposite to how most projects go. First, pick your shared vocabulary and your target model, so you know what everything has to mean before you move it. Second, map your highest-value sources to it, the few that carry the most weight. Third, stand up the exchange with FHIR once there is agreed meaning to exchange. Fourth, add governance and monitoring so the mappings do not rot the moment a source changes. Teams that start at step three, the API, end up rebuilding once they hit the semantic wall. Start with meaning and the plumbing lasts.

Interoperability is not the flashiest part of healthcare data, but it is the part that makes everything else possible. If systems cannot agree on what a record means, your analytics argue with each other and your AI learns from contradictions. Get this right and the whole foundation holds. That is why it earns its own place in the healthcare data pillar.