The Uncomfortable Truth
The health technology industry has a consensus problem. Everyone agrees that interoperability is the answer. Everyone agrees that FHIR is the standard. Everyone agrees that APIs are the mechanism. And everyone is wrong. Not about the destination, but about the depth of the problem.
We are investing enormous sums in yesterday's technology. APIs aren't bad. But we've confused the ability to move data with the ability to move care. These are fundamentally different problems, and only one of them matters to patients.
The current approach to health interoperability treats healthcare like an engineering problem: connect System A to System B, map the data, validate the schema, confirm receipt. Job done. Except it isn't. Because healthcare isn't a data problem. It's a responsibility problem. And responsibility doesn't travel through an API.
What APIs Actually Solve
Let's be precise about what point-to-point API integration gives us.
Even a well-implemented FHIR API solves only data exchange. It answers the question: can I get a piece of clinical information from one system to another? That's a necessary capability. It's also a solved problem. HL7v2 solved it in 1987. FHIR solves it more elegantly. But solving it again, with better syntax and RESTful semantics, doesn't address the failures that actually harm patients.
When a GP refers a patient to a specialist, what needs to happen isn't a data transfer. It's a transfer of clinical responsibility. That transfer must be bounded, auditable, consent-governed, and reversible. The referring clinician needs to know the specialist has accepted responsibility. The specialist needs to know the clinical intent behind the referral, not just the diagnosis code. The patient needs to know who is responsible for their care at every moment. And the system as a whole needs to know that the chain of accountability is unbroken.
None of this is an API problem. All of it is an architecture problem.
The Seven Failures of API-First Thinking
When we look at the real-world failures in health data exchange, the ones that lead to patient harm, duplicated care, dropped referrals, and regulatory breaches cluster around seven distinct domains. Not one of them is solved by better APIs.
1. Identity Without Context
APIs can pass an NHS number. They cannot propagate the certainty of an identity match, the provenance of the demographic data, or the governance conditions under which identity was verified. Cross-organisational identity isn't a lookup. It's a chain of trust. When a patient moves between organisations, the receiving system needs to know not just who the patient is, but how confident the sending system was in that identification, and under what authority it was established.
2. Consent That Doesn't Travel
Patient consent is not a boolean. It's a dynamic, contextual, revocable grant with scope, duration, and conditions. Current interoperability approaches treat consent as a gate. You have it or you don't. They don't treat it as a flow that must propagate across organisational boundaries in real time. When a patient consents to share data with their insurer for a specific claim, that consent has boundaries. Those boundaries must travel with the data, be enforceable at every node, and be auditable after the fact. APIs don't carry consent semantics. They carry data with a flag.
3. Provenance That Stops at the Boundary
Where did this data come from? Who created it? Under what clinical context? Was it manually entered, device-generated, algorithmically derived, or copied from another record? Provenance isn't metadata. It's clinical safety information. A blood pressure reading entered by a consultant during a face-to-face examination carries different clinical weight than one uploaded from a consumer wearable. Both are valid FHIR Observations. Both look identical in an API response. Only one should trigger a prescribing decision.
Current interoperability standards can encode provenance. The infrastructure doesn't enforce it. The difference is everything.
4. Clinical Intent Lost in Translation
A referral carries intent. A diagnostic request carries intent. A prescription carries intent. But API-mediated exchanges strip intent down to structured codes. SNOMED terms, ICD classifications, OPCS procedure codes. These capture what but not why. The clinical narrative, the reasoning chain, the differential diagnosis that informed the request: all of this is either lost in translation or buried in unstructured free text that the receiving system cannot act on.
This is not a vocabulary problem. It's an architectural failure. We've built systems that can transmit a request without transmitting its purpose.
5. Responsibility Without a Chain
Here is the central failure of API-first health interoperability: at no point in a standard FHIR exchange is there an explicit, auditable, timestamped transfer of clinical responsibility from one organisation to another.
Think about what that means. A hospital can send a discharge summary to a GP practice. The API confirms receipt. But receipt is not acceptance. The GP hasn't acknowledged they've read it, agreed with the care plan, or accepted ongoing responsibility for the patient's medications. The patient exists in a governance vacuum. Technically discharged. Technically notified to primary care. Actually under nobody's active responsibility.
This gap kills people. Not in dramatic, visible ways. In slow, administrative ways. Missed follow-ups. Duplicated tests. Medication errors during handover. Referrals that sit in queues until they're clinically meaningless.
6. Routing That Doesn't Understand Services
Current interoperability treats routing as an addressing problem: send this message to this endpoint. But healthcare service routing is a clinical decision. It depends on capacity, capability, geography, commissioning arrangements, patient preference, urgency, and the clinical pathway being followed. An API endpoint tells you where data can go. It tells you nothing about where data should go, or whether the receiving service can actually act on it.
The NHS's own experience with e-Referral demonstrates this: technically interoperable, practically dysfunctional, because routing a referral to an endpoint is not the same as routing a patient to the right care.
7. Outcomes That Never Close the Loop
The final failure is that APIs are overwhelmingly unidirectional in practice. Data flows from A to B. What happens at B, the outcome, rarely flows back to A in a structured, actionable form. The referring clinician doesn't know what the specialist found. The commissioning body doesn't know whether the intervention worked. The system as a whole cannot learn because the feedback loop is broken.
We have built a healthcare data infrastructure optimised for sending and indifferent to knowing.
The Real Architecture Problem
These seven failures aren't implementation bugs. They're design constraints of an API-centric architecture. When you start from the premise that interoperability means connecting systems, you inevitably build infrastructure that connects systems. The problem is that healthcare doesn't need connected systems. It needs governed flows.
The distinction is fundamental. A connected system moves data between endpoints. A governed flow moves responsibility between organisations, with identity, consent, provenance, intent, accountability, routing logic, and outcome tracking built into the flow itself. Not bolted on afterwards.
This is the difference between plumbing and architecture. The health technology industry has spent two decades perfecting the plumbing. It hasn't started on the architecture.
