HL7, FHIR and the Interoperability Gap

Two systems, one patient

A patient is admitted through a hospital's emergency department. Her blood tests are run in the laboratory. Her scans sit in a radiology system. The pharmacy has its own record of what she has been prescribed. Billing has a fourth. Each of these systems works. None of them agrees with the others on what to call her, and getting a complete picture requires a person to look in four places.

This is the interoperability gap. It is not caused by a lack of standards. Healthcare has more standards than almost any industry. It is caused by the distance between a standard on paper and two real systems that have both claimed to follow it.

Where HL7 started

HL7, Health Level Seven, is a standards organisation, and its name refers to the seventh layer of the old network model, the application layer. Its best known early product is HL7 version 2, which began in the late 1980s and remains in daily use in hospitals around the world.

A version 2 message is a compact piece of text, split into segments, fields and components using separators such as the pipe character. A simplified admission message looks like this:

MSH|^~\&|REG|HOSPITAL|LAB|HOSPITAL|20260101120000||ADT^A01|MSG001|P|2.5
PID|1||12345^^^HOSP||ADEYEMI^TUNDE||19800101|M
PV1|1|I|WARD3^101^A

It is terse and efficient, and it did the job when systems needed to tell each other that a patient had been admitted, discharged or transferred. It was also designed to be flexible. Optional fields, local extensions and tolerated variations meant that two systems could both be "version 2 compliant" and still fail to understand one another. In practice, every connection needed a mapping exercise by someone who knew both sides. Integration engines grew up to do this translation, and a whole profession grew up around the engines.

There was also a version 3 and a document format called CDA, which aimed for rigour through a detailed reference model. It was powerful and, for many teams, heavy. Adoption was uneven, and version 2 stayed where it was.

What FHIR changes

FHIR, Fast Healthcare Interoperability Resources, is the newer HL7 standard, and it takes a different approach. Rather than messages passed between systems, it models health data as resources, small units with a defined structure such as Patient, Observation, MedicationRequest or Encounter. These are exchanged over ordinary web APIs, using JSON or XML.

If you have built a REST service, you already know the shape. A patient is fetched with a request like this:

GET /Patient/12345
Accept: application/fhir+json

And you search with parameters, much as on any API. Resources reference each other, so an Observation points to the Patient it concerns. Developers who have never read a line of version 2 can be productive in a day.

This matters beyond tidiness. Web developers are plentiful and the tooling is familiar. Mobile applications, patient portals and analytics services can talk to the record without a translation layer built by specialists. FHIR also adds the idea of profiles, which let a country, a hospital network or a programme say precisely which fields are required and which codes must be used. That is where much of the real agreement now happens.

FHIR is also pragmatic about coverage. Its core resources aim to handle the commonly needed cases and let implementers add extensions for the rest. That flexibility is useful, and it carries the old risk in a new form: if every vendor extends differently, the standard bends until two compliant systems stop understanding one another. Profiles and rigorous testing are the discipline that prevents this.

Why the gap persists

If FHIR is better, why is the gap not closed? Because the format was never the whole problem.

Meaning differs even when syntax matches. Two systems can exchange a perfectly valid lab result where one uses a local code for "haemoglobin" and the other expects an international one. Terminologies such as LOINC for observations and SNOMED CT for clinical concepts exist to fix this, but they need to be adopted and mapped, and that mapping is slow human work.

Identity is hard. Matching a patient across systems needs a reliable identifier. Where no national identifier is used consistently, systems fall back on names, dates of birth and phone numbers, which produces duplicates and mismatches. A beautiful data exchange between two records that do not refer to the same person is worse than useless.

Legacy systems do not retire. A hospital will run a ten year old laboratory system for as long as it works. Version 2 will be with us for a long time, and FHIR deployments usually sit beside it, not in place of it.

Incentives are weak. Interoperability helps patients and the system as a whole, but a vendor does not always benefit from making it easy to move data out. Standards cannot fix a commercial reluctance.

Governance and consent are not technical. Who may see what, under which law, with whose permission, needs decisions that no specification can make. In Nigeria, the Data Protection Act 2023 treats health data as sensitive personal data, and hospitals need to design access with that in mind.

A pragmatic approach

We think the right posture for a hospital or a health technology team is modest and incremental.

• Pick a narrow, valuable exchange first. Lab results returning to the clinician, or a shared patient summary, rather than everything at once.
• Agree the codes before the code. Decide which terminologies you will use and who maintains the mapping. Treat it as ongoing work, not a launch task.
• Put a FHIR facade in front of what you have. An API layer that exposes existing data as FHIR resources, while version 2 continues behind it, gives you modern access without a rip and replace.
• Fix identity early. Whatever the national picture, a consistent internal patient identifier and a process for resolving duplicates will repay the effort.
• Test with real messages. Specifications look tidy. Production data does not. Try the awkward cases: missing fields, odd characters, corrections to earlier results.

This is operational advice about systems and data, not clinical guidance. The clinical decisions remain with clinicians. The job of the technology is to make sure they are looking at the right record.

Closing the gap, slowly

Interoperability is a long programme, not a project. FHIR gives developers a far better starting point than earlier standards did, and it has real momentum. But a standard only helps where the people running both systems have agreed on what the data means and who it belongs to.

Start with one exchange that saves someone a phone call. Make it reliable. Then do the next one.