Healthcare interoperability is usually described as a technical problem. One system holds information, another needs it, and an API is the route between them. Define the endpoints, authenticate the application, agree the payload, map the fields, move the data. From a distance it looks almost mechanical.

That view is understandable. FHIR gives common patterns for representing clinical information. National services expose defined interfaces. Electronic patient record suppliers open more functionality each year, and cloud platforms and integration engines make interfaces easier to build and monitor.

Anyone who has delivered this in a real NHS environment knows that a working connection is rarely where the hard problems end. It is where they start.

A passing integration test proves less than it seems

An API can tell one system how to request an appointment, retrieve an observation, or submit information about a patient. It cannot say what that information means in the receiving organisation. It cannot decide where in a clinical pathway the information should appear, who should act on it, what happens when it is incomplete, how an exception is escalated, or whether the new process has created a clinical risk that did not exist before.

Those are not implementation details. They are the substance of interoperability.

The important distinction is between moving healthcare data and making healthcare work across boundaries. The first is a technical capability. The second needs technical interoperability combined with consistent meaning, workflow design, clinical safety, operational ownership, and organisational change.

Take a platform that retrieves a patient's medication list from an EPR. Authentication works. Patient matching works. Every field passes schema validation. As a technical test, it is perfect.

Now ask different questions. Does the application know whether a medicine is current, historic, discontinued, or paused? Does it tell a medicine that was prescribed from one the patient is taking? Does the clinician see where the information came from? What happens when the same medicine arrives from two sources, or when coded data sits beside free text? Which system wins when the records disagree?

Those are interoperability questions too, and no test of the interface will answer them.

The same applies to simple-looking concepts. An appointment may be a booked consultation, a provisional slot, a multidisciplinary review, a home visit, or an administrative placeholder. A referral has states, ownership, acceptance criteria, urgency, and escalation routes. A test result depends on units, reference ranges, specimen details, timing, and the reason it was requested.

Inside one organisation, years of practice create shared assumptions that nobody wrote down. Staff know what a status means, who watches a worklist, which field to trust, and who to ring when a process breaks. Software arriving from outside has none of that knowledge. An integration can pass every acceptance test and still perform badly in production, because the project met the explicit contract and missed the implicit one.

FHIR does not remove this. A FHIR resource is not a full description of clinical reality. Teams still decide on profiles, extensions, terminology bindings, optional data, identifiers, and local constraints, and two systems can both use FHIR legitimately and still disagree on what a concept means.

So the question to ask a supplier is not whether it has an API. It is whether the capability supports the clinical and operational task, safely and consistently, in the places where it will be used.

Workflow is where interoperability becomes useful

Healthcare is made of workflows, not data transfers. A patient is assessed, a decision is made, something is requested, someone accepts responsibility, a result arrives, someone reviews it, and an action follows. An integration has value when it improves that chain. If it only puts more information somewhere in a system, data availability goes up and care barely changes.

Workflow is also harder to specify than an API, which is why it gets underestimated. An API document is precise about parameters, payloads, and response codes. A box labelled "clinician reviews result" hides dozens of questions. Which clinician? When in their day? How do they know the result exists? Who covers when they are absent? How are urgent results separated from routine ones? What happens if the patient has been discharged, or responsibility has moved to another service? What evidence shows the result was reviewed?

Those answers decide whether an integration removes work or creates it. Three ways a successful write into an EPR can still fail.

• The information lands in a section that clinicians rarely open during the relevant workflow, so it is invisible.
• It lands in the right place but adds another item to an overloaded queue, so the burden rises.
• It is visible and useful, but its arrival does not say who owns the next action, so each party assumes the other has it.

The hardest question is rarely where the data should go. It is what should happen because the data has arrived.

So workflow discovery has to come before technical design is fixed. Good discovery covers:

• Who creates, receives, reviews, and acts on information at each stage
• Which system is in use when each decision is made
• What triggers the next step and how users know it has happened
• Which steps are automated, manual, or dependent on a phone call
• Where delay, duplication, and re-keying occur today
• What happens when information is missing, late, duplicated, or contradictory
• Where clinical responsibility changes hands
• How teams spot, escalate, and recover from failures

Expect to find that the existing process is not one workflow but several. A referral may follow one route in hours and another out of hours. A result may be handled differently for an inpatient and an outpatient. Staff cover for poor system design with spreadsheets, shared inboxes, phone calls, and local knowledge. Digitise only the visible process and you can remove the very behaviours that kept it safe.

The opposite mistake is preserving the current workflow exactly. If a process contains repeated reconciliation and unnecessary hand-offs, automating every step only makes a poor process faster. The better aim is redesign. Which hand-offs can disappear once data moves reliably? Can information appear at the point of decision instead of in a separate application? Can a queue go altogether?

The best integrations feel unremarkable. Information arrives in context, the action can be completed where the user already is, status is visible, and responsibility is clear. A poor one announces itself constantly. Log in somewhere else. Re-enter the NHS number. Copy the result. Check another worklist. Ring someone when it misbehaves. Each of those is integration debt, paid by a person.

At NHS scale the arithmetic matters. Thirty seconds added to a task done occasionally is nothing. Thirty seconds added to something done hundreds of thousands of times is a large cost, and it falls on staff whose attention is already scarce. So measure integration in workflow terms, not API uptime. Count time saved, manual steps removed, duplication eliminated, information available at the point of need, and tasks completed safely.

Semantics decide whether the data still means the same thing

Workflow decides where information goes and what should happen next. Semantics decides whether the receiver understands what was sent. Healthcare data is extraordinarily dependent on context, so this is one of the most persistent problems.

Standard terminologies such as SNOMED CT matter because they reduce ambiguity. They do not solve it. The difficult work is in how local data is mapped to the terminology, how detailed the coding is, what context travels with it, and how the receiving system uses it.

An allergy shows why. The requirement sounds simple, exchange allergy information. The concept can include the substance, the reaction, severity, certainty, verification status, onset, notes, whether the patient reported it or a clinician established it, and whether it is a true allergy, an intolerance, or another adverse reaction. One system may hold all of that in structure. Another may use codes and free text together. A third may use local conventions older than the current standards. Flatten those differences during integration and the receiver gets valid data that has lost clinical meaning.

Diagnoses behave the same way. A problem on a long-term list is not the same as a diagnosis entered for one encounter. Suspected is not confirmed. Historic is not active. A code can be accurate but too broad for the receiving use, or very specific and mapped inconsistently across organisations.

Provenance matters as much as content. Suppose three systems give a patient's smoking status. One says smoker, one says former smoker, and a third holds a more recent record that says never smoked. A naive integration shows all three. A slightly better one picks the latest timestamp, which assumes the timestamps describe comparable events and that every source is equally authoritative. The system has a data integration problem. The clinician has a truth problem.

So semantic design needs explicit decisions about authority, provenance, time, and reconciliation. Which source is trusted for which concept? Should conflicting values be shown or resolved? Does a missing value mean not known, not applicable, not recorded, or confirmed absent? When should free text travel with a coded value? What meaning is lost in the transformation?

This gets more serious as healthcare automates. A clinician can use judgement on an ambiguous display. Software cannot. If interoperable data feeds decision support, triage, messaging, or AI, a semantic assumption becomes an executable decision. A weak mapping in a viewer confuses a user. The same mapping in an automated process can send a patient down the wrong pathway.

That is why semantics cannot be left to developers at the end. It needs clinicians, terminology expertise, data architects, and people from the systems on both sides. A payload can be syntactically perfect and semantically wrong. Standards give everyone a common language, and implementation decides whether they are all saying the same thing.

Change and clinical safety belong inside the integration

A sound integration, with correct meaning and the right workflow, can still fail if people do not adopt the new way of working. Programmes often split delivery into building the technology and then running change management around it. In healthcare that understates the problem, because changing the technology usually changes the service.

A new integration can change who sees information first, remove a manual check, create an automated task, change which organisation holds the latest version of a record, or let a patient start something that once needed staff. Those are operating-model changes delivered as software.

Many processes contain controls that look like inefficiency. Someone checks something because that check has caught errors before. A receptionist confirms details because downstream data has not been reliable. A clinician reviews a queue because nothing else identifies the exceptions. Automation can make a control unnecessary. Removing it without knowing why it existed can also remove a safety barrier.

So clinical safety has to run through the design, not arrive as a compliance exercise before go-live. A supplier can design a product safely and document the risks of its intended use. The deploying organisation then has to consider how those risks change locally, through configuration, pathway, staffing, and interaction with other systems.

Here is the case that no API specification can settle. A platform reliably sends an urgent result into an EPR. Local users believe the sending platform escalates. The supplier assumes the receiving organisation monitors the EPR. The interface works exactly as designed, and nobody owns the result.

Safe interoperability needs explicit ownership. Who is responsible while information is in transit? What happens if delivery fails? Who watches integration errors, and how fast must each type be fixed? How do users tell the service is degraded, and what is the fallback?

Design for failure, because it will happen. Networks drop, tokens expire, upstream systems return unexpected data, terminology changes, duplicates appear, patients fail to match, queues back up, and suppliers release new versions. The question is not whether the integration can fail. It is whether the organisation can detect it, understand it, and recover safely.

Monitoring needs clinical context. A dashboard showing 99.99 percent availability can be reassuring while a small set of clinically significant transactions fails repeatedly. Hundreds of harmless retries can bury the few failures that need a human. Teams need to know which transactions matter most, what a failure means for the pathway, how long information can safely be delayed, and which errors need intervention.

Then there is adoption. Clinicians rarely resist technology for being new. They resist systems that make work harder, add uncertainty, duplicate effort, or ignore the environment they work in. Training cannot make up for a poor workflow indefinitely. If users must remember a complicated sequence or reconcile information by hand, the problem is the product.

Go-live is the start of learning. Ask what happened afterwards. Are users completing the process as intended? Have workarounds appeared? Has work moved somewhere unexpected? Are exceptions piling up? Have support requests changed? The most mature organisations treat interoperability as a capability with owners, governance, and monitoring, not a project that ends when an interface reaches production.

Start with the care outcome and design backwards

None of this means paying less attention to APIs. Security, performance, resilience, error handling, version management, testing, and observability all matter, and standards-based APIs are valuable because they cut unnecessary variation. They belong inside a larger design.

The strongest programmes start by saying what should become possible. A clinician sees the relevant information without searching another system. A referral arrives with enough structure to be triaged safely. A patient does not repeat what another authorised service already holds. A result reaches the person who must act on it. A failed transaction is visible before it becomes a missed clinical action.

Then work backwards. What is the workflow? Where is the decision made, and who owns it? What information is needed at that moment, and which system holds it? What does each item mean, which standard represents it, and which source is authoritative? What happens when sources conflict? What can fail, and how is it detected? What does the user do when the integration is down? Only after that does the API specification sit in its proper context.

It also changes the testing. Interface testing covers valid and invalid requests, mappings, authentication, error conditions, and performance. Healthcare needs more layers. Semantic testing asks whether meaning survives the exchange. Workflow testing asks whether users can complete the task. Clinical safety testing asks whether foreseeable failures or misreadings can cause harm. Operational testing asks whether the organisation can support the integration when something goes wrong. User testing asks whether the new process is better than the old one. End-to-end testing asks whether the whole pathway works across every system and organisation involved.

This matters for suppliers scaling across the NHS. The first integration with an NHS organisation gives false confidence. You learn one EPR, one configuration, one set of workflows, and one local reading of the data, and the technical parts look reusable, so the second should be easier. Some of it will be. The difficult variation is usually not in HTTP, JSON, or FHIR. It is around them. Another organisation may use the same EPR differently, configure fields differently, give responsibility to a different team, use different local terminology, or need write-back immediately where another needs review first. A process acceptable in one trust may introduce risk in another.

Scalable interoperability depends on knowing what to standardise and what must stay configurable. Authentication patterns, API clients, observability, mappings, test harnesses, and core data models should be reused. Workflow, semantics, safety, and operational responsibility need a deliberate local implementation layer where they are validated with each organisation. If everything is bespoke, delivery is slow and expensive. If everything is assumed identical, the product is brittle and unsafe.

As APIs spread, basic connectivity will differentiate less. The advantage will go to organisations that use connectivity to redesign care. Healthcare does not need an API between System A and System B. It needs the discharged patient's information in front of the community team, the GP to know what happened elsewhere, the clinician to see the result when the decision is being made, and nobody explaining their history for the fifth time. The API is one mechanism for getting there. It is not the outcome.

So do not declare victory when data starts to flow. That is the first test. The real tests are whether meaning survived, whether the information appeared at the right moment, whether someone could act on it, whether the process stays safe when it fails, and whether the new way of working improved care.