Blog · Interoperability

Interoperability Is Not an Export Button

Why “we export FHIR” and “we send a PDF” are two very different promises — and why one of them gets expensive in operations.

There is a moment in nearly every hospital project when the word “interoperable” comes up and everyone nods. Usually someone points at a button: “The system can export FHIR.” Or: “We hand over the report as a PDF.” The question is treated as answered.

It is not.

A PDF is transport. Not interoperability.

A FHIR export is transport. Not interoperability. Both move data from A to B. Whether B then understands the same thing A meant is an entirely different question — and that question is what decides operations, patient safety and scalability.

Transport is not meaning

Interoperability does not mean that data arrives. It means that the meaning of the data arrives intact.

HL7 v2 and FHIR carry structure reliably. The meaning, however, lives elsewhere: in the terminologies (SNOMED CT, LOINC, ICD, OPS), in the units (UCUM), in the IHE profiles that fix which element sits in which context — and not least in the shared process understanding between sender and receiver. Remove any one of these layers and the transfer runs through cleanly on a technical level while still delivering something wrong.

A concrete example from practice: a lab value is transmitted with a correct LOINC code. Structurally conformant, the FHIR validator is satisfied. But the unit (UCUM) was silently lost along the way, or the reference-range context was not carried over. The receiving system displays a number — one that means something different from the number the sending system meant. No error log reports it. The transport was a success. The information was not.

Where meaning quietly gets lost

These silent losses follow patterns. In our work on SILD — a formal method for detecting semantic information loss at clinical system boundaries — they reduce to a small set of canonical types:

  • Type Narrowing — a precise concept is mapped onto a coarser one (the specific SNOMED code ends up as an unspecific ICD entry).
  • Temporal Collapse — a time interval or course of events is reduced to a single point in time.
  • Attribute Dropping — an attribute that qualifies the statement (unit, status, negation) is missing after the transfer.
  • Reference Severing — a link between resources breaks, and the context that carries the statement is lost.

The key point: each of these losses happens inside a technically successful transfer. Anyone measuring interoperability by the export button sees none of them.

What this means for hospitals

The conclusion is uncomfortable, but it saves money. Interoperability is not a feature you buy. It is an organisational and semantic discipline: who owns which profile? How are codes and units bound? Who checks whether a receiver can reconstruct the meaning — and not just the structure? What happens at the boundary between two systems when no one owns it?

Every decision of the form “we’ll handle that later through an interface” assumes that transport equals interoperability. The cost of that assumption never shows up in the project plan. It shows up in the receiving system — often invisibly, until a clinical process builds on a number that means something other than everyone believes.

About ISCaD

We support hospitals and their IT in exactly this discipline — profile governance, terminology binding, and the systematic inspection of system boundaries for semantic loss. If you want to know where meaning quietly leaks out of your data flows: get in touch.

The formal foundation of the method outlined here is documented at aion-clinical.eu.

← Back to the blog