Interoperability in IVD: FHIR is a tool, not an architecture

In IVD software, interoperability now has a default answer, and it is FHIR. Adopt the standard, the reasoning goes, and systems will finally talk to each other. 

That framing confuses the tool with the problem. FHIR standardizes the language two systems use to exchange data. It does not design the system that decides what is exchanged, who owns it, and what happens when one side changes.

That design - the integration layer - is where lab projects succeed or stall. FHIR is one component inside it, not a replacement for it.

FHIR standardizes the language, not the architecture

The momentum is real. In the 2025 State of FHIR Survey run by HL7 International and Firely, 71% of respondents reported FHIR in active use for at least a few cases in their country, up from 66% a year earlier. Among countries that already regulate health data exchange, 73% now mandate or advise it.

For European IVD vendors selling into hospital networks, that settles the first question. FHIR is increasingly a requirement, not a design choice, and the survey is clear that regulators are the ones driving it.

But the same study is candid about the gap underneath. National implementation guides exist in most countries, yet only around a fifth are reported as widely used. Legacy exchange - HL7 v2, CDA - remains in use almost everywhere, side by side with FHIR.

That gap is the tell. A shared language is necessary, not sufficient. Two systems can both speak FHIR and still fail to integrate, because the decisions that matter sit above the wire format.

Integration breaks in three predictable places

In lab software the breakage is not random. The same three failure points recur across instrument → LIS/LIMS → hospital integrations. This is a practitioner’s checklist, not a formal taxonomy, but the pattern keeps surfacing.

Semantic mapping

FHIR carries a lab result in a DiagnosticReport or Observation; it does not reconcile the codes inside it. LOINC, SNOMED CT and local in-house dictionaries do not collapse into one another automatically. A value coded one way upstream and read another way downstream is a silent error, not a transport failure, and in diagnostics, silent errors are the dangerous kind.

Data ownership along the chain

The hardest question on an IVD integration is not technical: it is who owns the data as it moves from the instrument to the LIS/LIMS and on to the hospital’s systems. We typically work in the case where a hospital runs software supplied by a vendor and holds its data on that vendor’s infrastructure. Responsibilities along that chain are rarely declared explicitly, and they surface - as liability, as access disputes - precisely when something has already gone wrong.

Post-deployment change governance

An integration that works at go-live is not finished. Endpoints get upgraded, profiles get revised, a hospital migrates its EHR. The question this raises is who manages those changes without breaking the integrations already in use. FHIR’s versioning model helps; it does not assign the responsibility.

The integration layer becomes the real deliverable

Treating interoperability as architecture means building the layer FHIR plugs into deliberately, instead of assuming the standard supplies it.

In practice that is three things:

• An explicit terminology service, so code mapping is a managed component with an owner, not an assumption buried inside adapters
• Declared contracts between systems, so each side knows what it sends, what it expects, and what counts as a breaking change
• A stated change-governance process, so updates move along the chain without silent regressions.

None of this is exotic. It is ordinary architectural discipline applied to a domain where the cost of a quiet failure is a misread result. FHIR sits inside this layer as the exchange format; the layer is what keeps the exchange safe over time.

It is also where the regulatory weight lands. Data ownership, traceability of a result across systems, controlled change: these are what an auditor and a hospital procurement team ask about, and none of them are answered by conformance to a resource profile alone.

Build the layer, not just the connector

The market treats FHIR as the finish line. For teams shipping regulated diagnostic software into European hospitals, it is closer to a starting condition.

The differentiator is no longer whether you can emit a valid FHIR resource: increasingly, everyone can. It is whether you have designed the architecture around it: the mapping, the ownership, the governance that decide whether an integration holds up in use and survives change.

That, in our view, is the real job. Architects of adoption, not just code vendors, because in lab integration the standard is the easy part, and the architecture is the product.