Delivered, but not usable
A patient is discharged on a Friday afternoon. The discharge summary leaves the hospital, travels through the integration, and is logged as delivered. The interface dashboard is green.
On Monday a practice pharmacist opens it. It is a six page PDF in a documents queue. The medication changes are in a paragraph halfway down page three. One allergy is written as free text. Nobody has been assigned to review it, so it waited the whole weekend. She retypes the changes by hand and phones the ward to check the allergy.
Every system in that chain did its job. The data moved. It just didn't move far enough to be used. That gap, between data arriving and data being safely acted on, is what the levels of healthcare interoperability describe.
What are the levels of healthcare interoperability?
The levels of healthcare interoperability describe how far two systems actually understand each other. The model most people use comes from HIMSS, which defines four levels: foundational, structural, semantic and organisational. Each level builds on the one below. Data has to move before it can be read, be read before it can be understood, and be understood before anyone can safely act on it.
One discharge summary, four levels
Take the same summary and watch what each level adds.
- Foundational: the data can move. The hospital and the practice are securely connected, and a document can travel between them. The Friday PDF proves this level works. It proves nothing else.
- Structural: the data arrives in a shape the receiver can read. Now the summary travels as a structured message, using a standard such as HL7 v2 or HL7 FHIR. Medications, diagnoses and follow up actions sit in defined fields, so the receiving system can file them without retyping. This is also called syntactic interoperability: both systems agree on the grammar. The FHIR resources explainer covers what those structures look like in practice.
- Semantic: both ends agree what the data means. An allergy field containing "pen allergy?" is structurally valid and clinically useless. Semantic interoperability means the content is coded against a shared terminology: in the NHS, SNOMED CT for clinical terms and dm+d for medicines. Now the GP system knows it is a penicillin allergy and can warn the prescriber. National services such as the NHS England Terminology Server, and products such as WeHub Term, exist to support this level.
- Organisational: people and rules let it be used. The coded summary lands in the right system. Who reviews it, and by when? Does a data sharing agreement cover the flow? Who is accountable if a follow up action is missed over a weekend? HIMSS describes this level as governance, policy, social and legal considerations. In the UK it covers data sharing agreements and IG sign off. In the US, national frameworks such as TEFCA sit here. None of it is technical, and all of it decides whether the first three levels deliver anything.
Semantic vs syntactic interoperability
This is the distinction that causes the most confusion, and the most real problems.
Syntactic interoperability is about form. Both systems agree that a message has a medications section, and that each entry has a name, a dose and a route. Semantic interoperability is about meaning. Both systems agree that a given code refers to the same drug, at the same strength, with the same clinical intent.
You can have perfect syntax and broken semantics. Two organisations can exchange valid FHIR resources all day and still disagree on what a local clinic code or a free text diagnosis means. The interface passes every validation check. The data is still wrong for the person reading it. That is why mapping local codes to national terminology often takes more effort than the connection itself, and why Terminology 101 is a useful next read.
It isn't a ladder you finish
An interoperability maturity model can suggest you climb once and arrive. In practice, one organisation sits at different levels on different flows at the same time. A Trust can run well coded, governed FHIR flows for pathology results and still rely on emailed spreadsheets for a community service.
The higher levels also fail more quietly. A broken connection is obvious the same day. A semantic mismatch or an unclear owner can run for months, and only surfaces when a figure is disputed. Leave entitlement drift between ESR and rostering is a good example: the systems are connected, the files are well formed, and nobody agreed which system owns which figure.
Where to start
Don't assess interoperability across your whole organisation. Pick one flow that matters, and ask four questions in order:
- Does the data reliably arrive? (foundational)
- Does it arrive in a standard structure the receiver can read without manual work? (structural)
- Is the content coded so both ends mean the same thing? (semantic)
- Does someone own what happens when it arrives, under an agreed policy? (organisational)
The first "no" is your real interoperability level for that flow. It tells you what to fix next, and it is rarely the connection.
