Healthcare APIs Aren’t the Hard Part: Workflow, Semantics and Change Are

Healthcare interoperability is often discussed as if it were principally a technical problem. One system holds information, another system needs it, and an API provides the route between them. Define the endpoints, authenticate the applications, agree the payload, map the fields and move the data. From a distance, the problem can look almost mechanical.

That view is understandable. Modern APIs have made healthcare integration considerably more structured than it once was. Standards such as FHIR provide common patterns for representing and exchanging clinical information. National services increasingly expose defined interfaces. Electronic patient record suppliers are opening more functionality through APIs. Cloud platforms, integration engines and mature software tooling have made it easier to build, test and monitor interfaces.

Yet anyone who has delivered interoperability in a real healthcare environment knows that establishing a connection is rarely the point at which the hardest problems end. In many cases, it is where they begin.

An API can tell one system how to request an appointment, retrieve an observation or submit information about a patient. It cannot, by itself, establish what that information means in the receiving organisation. It cannot decide at which point in a clinical pathway the information should appear, who should act on it, what should happen when the data is incomplete, how an exception should be escalated, or whether the new process has introduced a clinical risk somewhere that did not previously exist.

These are not peripheral implementation details. They are the substance of interoperability.

The most important distinction is therefore between moving healthcare data and making healthcare work across boundaries. The first is a technical capability. The second requires technical interoperability to be combined with semantic consistency, workflow design, clinical safety, operational ownership and organisational change.

That distinction matters more as healthcare becomes more connected. A digital product may no longer operate inside one organisation, one department or even one care setting. A single patient journey might involve primary care, an acute trust, community services, diagnostics, pharmacy, social care, a patient-facing application and several national NHS services. Information can travel across all of those environments and still fail to support the person delivering care at the moment it matters.

The next generation of healthcare interoperability will therefore not be won by organisations that simply build more APIs. It will be won by those that understand what needs to happen on either side of them.

The API illusion: connectivity is not the same as interoperability

APIs are essential infrastructure. They provide controlled, repeatable ways for systems to exchange information and invoke functionality. In healthcare, the move towards open interfaces and standards-based integration is particularly important because proprietary, tightly coupled integrations create cost, technical debt and dependence on individual suppliers.

But there is a dangerous conceptual shortcut hidden inside the phrase “the systems are integrated”.

Imagine that a digital health platform successfully retrieves a patient’s medication information from an electronic patient record. Authentication works. Patient matching works. The API responds successfully. Every required field passes schema validation. From the perspective of a technical integration test, the interface may be working perfectly.

Now ask some different questions.

Does the application understand whether a medicine is current, historic, discontinued or temporarily paused? Does it distinguish a medication that was prescribed from one the patient is actually taking? Does the receiving clinician understand where the information originated? Are dosage instructions represented consistently? What happens if duplicate medicines appear from different sources? What happens when the source system contains free text alongside coded information? Which system is authoritative if the records disagree?

Those are interoperability questions too.

The same problem occurs with apparently simple concepts across healthcare. An appointment is not merely a start time and an end time. Depending on the setting, it might represent a booked consultation, a provisional slot, a multidisciplinary review, a diagnostic procedure, a telephone call, a home visit, a theatre event or an administrative placeholder. A referral is not simply a document sent from one organisation to another; it has states, ownership, acceptance criteria, clinical urgency, dependencies and escalation routes. A test result is not useful merely because it has been transmitted; its interpretation may depend on units, reference ranges, specimen information, timing, methodology, previous results and the clinical context in which it was requested.

The problem becomes even clearer when integration crosses organisational boundaries. Inside a single organisation, years of local practice can create shared assumptions that are never formally documented. Staff know that a particular status means a particular thing. They know who monitors a worklist. They know that information appearing in one field is more reliable than information appearing in another. They know that an apparent duplicate is not really a duplicate. They know who to telephone when a process fails.

Software crossing into that environment does not possess this tacit knowledge.

This is one reason an integration can pass every technical acceptance test and still perform poorly in production. The technology has successfully implemented the explicit contract while the project has failed to understand the implicit one.

FHIR does not remove this challenge. It gives healthcare a sophisticated common framework for exchanging information, but a FHIR resource is not a complete description of clinical reality. Implementers still have to make decisions about profiles, extensions, terminology bindings, cardinality, optional data, search behaviour, identifiers and local constraints. Two systems can both legitimately use FHIR and still require careful agreement before their interpretation of the same clinical concept is sufficiently aligned.

The right question is consequently not, “Does the supplier have an API?”

It is, “Can this capability support the clinical and operational task we need to complete, safely and consistently, in the environments where it will actually be used?”

That shift in language sounds subtle. In practice, it changes how an integration programme is designed.

Instead of beginning with available endpoints, teams begin with outcomes. Instead of treating the source and destination systems as abstract applications, they examine the people and processes surrounding them. Instead of assuming a successful response code represents success, they define what successful completion means to the patient, clinician and service.

This is the difference between interface engineering and healthcare interoperability engineering.

Workflow is where interoperability becomes clinically useful

Healthcare is composed of workflows, not data transfers.

A patient is assessed. A decision is made. Something is requested. Somebody accepts responsibility. Information is collected. A result becomes available. Someone reviews it. A subsequent action is taken. The patient may move between teams or settings throughout that sequence.

An integration has value when it improves that chain of activity. If it merely places additional information somewhere in a system, it may technically increase data availability while making very little difference to care.

This distinction is frequently underestimated during digital health projects because workflow is more difficult to specify than an API. API documentation can describe parameters, payloads, authentication requirements and response codes with precision. Real clinical workflows are messier. They differ between organisations, departments, professions, specialties and sometimes individual teams.

What appears on a process diagram as “clinician reviews result” may conceal dozens of important questions. Which clinician? At what point in their working day? How do they know the result exists? Who covers the work when that person is absent? What distinguishes routine results from urgent ones? What happens when the patient has already been discharged? What happens if the result arrives after responsibility has moved to another service? What evidence is created to show that the information has been reviewed?

Those questions determine whether integration reduces work or creates new work.

Consider a digital tool that produces clinically relevant information and writes it successfully into an EPR. That sounds like an ideal integration. Staff no longer need to transfer information manually, and the clinical record is automatically updated.

But suppose the information appears in a section of the EPR that clinicians rarely use during the relevant workflow. The integration is successful, yet the information is effectively invisible.

Alternatively, suppose the information appears in the right place but creates another item in an already overloaded work queue. The integration is successful, but it increases cognitive and administrative burden.

Or suppose the information is visible and clinically useful, but the arrival of the data does not establish who owns the next action. The integration may actually introduce risk because each party assumes the other has taken responsibility.

The hardest interoperability question is often not “Where should this data go?” but “What should happen because this data has arrived?”

That is why workflow discovery needs to happen before technical design is finalised. Teams need to understand the current state, including its imperfections, workarounds and exceptions, before deciding what the future state should look like.

Good workflow discovery typically explores:

• who creates, receives, reviews and acts on information at each stage of the pathway;
• which system is being used when each decision is made;
• what triggers the next activity and how users know that trigger has occurred;
• which steps are automated, manual or dependent on communication outside the core systems;
• where delays, duplication, re-keying and uncertainty currently occur;
• what happens when information is missing, late, duplicated or contradictory;
• where clinical responsibility changes hands; and
• how teams recognise, escalate and recover from failures.

This work often reveals that the existing process is not a single workflow at all. It is a collection of variants.

A referral may follow one route during normal hours and another out of hours. A result may be managed differently for an inpatient and an outpatient. A community team may operate differently from the acute service. Different sites within the same trust may have inherited different operating practices. Staff may compensate for poor system design through spreadsheets, inboxes, telephone calls, sticky notes or local knowledge.

Digitising the visible process without understanding these compensating behaviours can inadvertently remove the mechanisms that were keeping the process safe.

There is also a temptation to treat integration as a means of preserving the existing workflow exactly as it is. That can be equally problematic. If a process contains repeated manual reconciliation, duplicated data entry or unnecessary hand-offs, automating every step may simply make a poor process run faster.

The better objective is workflow redesign.

This requires technical and clinical teams to work together to ask which activities remain necessary once information can move reliably between systems. Could the integration eliminate an administrative hand-off? Could information be presented directly at the point of decision rather than retrieved through a separate application? Could an existing queue disappear altogether? Could a clinician avoid opening another system? Could a process change from “search for information” to “information presented when required”?

The best integrations tend to feel unremarkable to the user because the technology disappears into the workflow. Information arrives in context. Actions can be completed where the user is already working. Status is visible. Responsibility is clear. Exceptions have somewhere to go.

By contrast, poor integration often announces itself constantly. Log into another application. Re-enter the NHS number. Copy the result. Check another worklist. Refresh the page. Reconcile two versions of the same information. Telephone someone when the automated process behaves unexpectedly.

Every one of those actions is integration debt being paid by a person.

At NHS scale, small amounts of friction become significant. A workflow that adds 30 seconds to a task performed occasionally may be insignificant. Add 30 seconds to an activity performed hundreds of thousands of times, and the cumulative cost becomes substantial. More importantly, the cost is often borne by clinicians and operational staff whose attention is already scarce.

That is why healthcare integration should ultimately be measured in workflow terms. Not simply API uptime or transaction volume, but time saved, manual steps removed, duplicated activity eliminated, information available at the point of need, exceptions resolved and clinical tasks completed safely.

Semantics: moving the data is useless if its meaning changes

Workflow determines where information needs to go and what should happen when it gets there. Semantics determines whether the receiving system and its users understand what has actually been sent.

This is one of the most persistent challenges in healthcare interoperability because healthcare data is extraordinarily context-dependent.

At the simplest level, semantic interoperability means preserving meaning between systems. If one application records a clinical concept, another application should be able to interpret that concept in the intended way rather than merely displaying the same characters.

Structured terminologies such as SNOMED CT are therefore fundamental to interoperable healthcare. Standard identifiers and vocabularies reduce ambiguity and provide a common representation of clinical concepts across systems. Similar standardisation is important for medicines, observations, pathology, procedures and many other domains.

But using a standard terminology does not magically solve semantics.

The difficult work often lies in how local data is mapped to that terminology, how detailed the coding is, what context accompanies it and how the receiving system uses it.

Consider an allergy record. On the surface, the integration requirement sounds straightforward: exchange allergy information.

In reality, the concept can include the substance or medication involved, the type of reaction, severity, certainty, verification status, onset, clinical notes, whether the information was reported by the patient or established clinically, and whether the record represents a true allergy, an intolerance or another adverse reaction. A source system may represent those dimensions structurally. Another may use a mixture of codes and free text. A third may have local conventions that predate current standards.

If those differences are flattened during integration, the destination may receive technically valid data that has lost clinically important meaning.

The same issue appears with diagnoses. A problem recorded on a long-term problem list may not mean the same thing as a diagnosis entered for an encounter. A suspected diagnosis is different from a confirmed diagnosis. A historic condition is different from an active condition. A code may be semantically accurate but too broad for the receiving use case. Another may be highly specific but not mapped consistently across organisations.

Healthcare information also has provenance. Knowing what a piece of data says can be less important than knowing where it came from, when it was recorded, by whom and in what context.

Suppose several systems provide a patient’s smoking status and the values differ. One says the patient is a smoker, another says former smoker, and a third contains a more recent record stating that the patient has never smoked. A naïve integration might simply display all three. Another might select the latest timestamp. But even that decision assumes the timestamps represent comparable events and the sources are equally authoritative.

The system has a data integration problem, but the clinician has a truth problem.

Semantic design therefore requires decisions about authority, provenance, temporality and reconciliation. Which source should be trusted for a particular concept? Can data from different settings be combined? Should conflicting values be displayed or resolved? Does absence of data mean “not known”, “not applicable”, “not recorded” or “confirmed absent”? When should free text accompany a coded value? What meaning is lost during transformation?

These questions become particularly important when information is used for automation rather than simply displayed to a human.

A clinician viewing a record can interpret ambiguity using professional judgement and surrounding context. Software cannot necessarily do so. If interoperable data feeds decision support, triage, population health management, automated messaging or AI, semantic assumptions can become executable decisions.

The consequences of a bad mapping therefore change as healthcare becomes more automated. A weak mapping in a passive viewer might confuse a user. The same mapping feeding an automated process might cause a patient to enter the wrong pathway.

This is why semantic interoperability cannot be delegated entirely to developers at the end of a project. It requires subject-matter experts, clinicians, terminology expertise, data architects and representatives of the systems on both sides of the interface.

The key semantic questions should be answered deliberately:

• What precisely does each data element mean in the clinical context of this integration?
• Which coding systems and value sets are required, and how are local concepts mapped to them?
• Which system is authoritative for each category of information?
• How are provenance, status, uncertainty and time represented?
• What information cannot be safely transformed without losing meaning?
• How should conflicting, duplicated or incomplete data be handled?
• What assumptions will downstream systems make about the information?
• Could any transformation alter the clinical interpretation of the record?

These discussions can feel disproportionately detailed compared with the apparently simple objective of connecting two applications. They are not.

A payload can be syntactically perfect and semantically wrong.

That is one of the most important lessons in healthcare interoperability. Standards make it possible to create a common language, but implementation determines whether everyone is actually saying the same thing.

Change and clinical safety are part of the integration, not activities around it

Even a technically sound, semantically accurate integration designed around the right workflow can fail if people do not adopt the resulting way of working.

Digital health programmes sometimes divide delivery into two streams: the technology is built, and then “change management” helps users adapt to it. That framing understates the role of change. In healthcare, changing the technology frequently changes the service itself.

A new integration may alter who sees information first. It may remove a previously manual check. It may create an automated task. It may change which organisation holds the most current version of a record. It may allow a patient to initiate an activity that previously required staff intervention. It may redistribute work between clinical and administrative teams.

Those are operating-model changes expressed through software.

This is particularly important because many healthcare processes contain controls that are easy to mistake for inefficiency. A person checks something because, historically, that check has caught errors. A receptionist confirms information because downstream data has not always been reliable. A clinician reviews a queue because there has been no other dependable way to identify an exception.

Automation may make some of those controls unnecessary. But removing them without understanding why they existed can also remove a safety barrier.

Clinical safety therefore needs to be considered throughout integration design rather than treated as a compliance exercise shortly before deployment.

The relationship between system-level and deployment-level risk is crucial. A supplier can design a product safely and document the risks associated with its intended use, but the organisation deploying it has to consider how those risks change in the local environment. An interface may behave exactly as designed while becoming unsafe because of the surrounding configuration, local pathway, staffing model or interaction with another system.

Imagine, for example, that a platform reliably transmits an urgent result into an EPR. Technically, the integration is robust. But if local users believe the sending platform is responsible for escalation while the supplier assumes the receiving organisation monitors the EPR, there is a potentially dangerous gap in responsibility. No API specification can resolve that ambiguity.

Safe interoperability needs explicit ownership.

Teams should know who is responsible for information while it is in transit, what happens if delivery fails, who monitors integration errors, how quickly different failures need to be resolved, how users recognise degraded service and what the fallback process is.

The design needs to account for failure because failure is inevitable.

Networks become unavailable. Tokens expire. upstream systems return unexpected data. terminology changes. duplicate messages are created. patients are not matched. queues back up. third-party services are degraded. a supplier releases a new version. configuration changes. staff use a workflow in an unanticipated way.

The relevant question is not whether the integration can fail. It is whether the organisation can detect, understand and safely recover when it does.

This is where operational design becomes inseparable from technical architecture. Monitoring must distinguish an infrastructure problem from a clinical process problem. A dashboard showing 99.99% availability may be reassuring while a small subset of clinically significant transactions is repeatedly failing. Conversely, hundreds of harmless retry events may create operational noise that obscures the few failures requiring immediate attention.

Good integration observability therefore needs clinical context as well as technical telemetry.

Teams should know which transactions matter most, what failure means for the patient pathway, how long information can safely remain delayed and which errors require human intervention. Support teams need enough contextual information to investigate without unnecessarily exposing sensitive patient information. Escalation processes need to connect technical teams with operational and clinical owners when a defect affects care.

Then there is adoption.

Healthcare professionals rarely resist technology simply because it is new. More commonly, they resist systems that make their work harder, create uncertainty, duplicate activity or fail to reflect the realities of the environment in which they work.

Training matters, but training cannot compensate indefinitely for poor workflow design. If users repeatedly need to remember a complicated sequence of steps, switch applications or manually reconcile information, the problem may be the product rather than the user’s knowledge.

The same applies to communication. Telling staff that a new integration will “save time” is not persuasive if their experience is that it has added another queue to check. Benefits need to be visible in the workflow and measurable after implementation.

Change therefore needs feedback loops. What happened after go-live? Are users completing the process as intended? Have manual workarounds emerged? Has workload shifted somewhere unexpected? Are exceptions accumulating? Are some teams seeing benefits while others have experienced new friction? Has the integration changed the volume or character of support requests?

A successful deployment is not the end state. It is the beginning of operational learning.

Healthcare environments change continually. Clinical pathways evolve, national requirements change, vendors update their platforms, organisations merge services, staff roles change and new digital capabilities are introduced. Integration therefore requires ongoing stewardship.

The most mature organisations do not treat interoperability as a series of projects that finish when an interface enters production. They treat it as a capability that needs ownership, governance, monitoring and continuous optimisation.

Start with the care outcome, then design the integration backwards

If APIs are not the hardest part, the solution is not to pay less attention to APIs. It is to put them in the correct place within the problem.

Technical quality remains essential. Healthcare interfaces need appropriate security, performance, resilience, authentication, error handling, version management, testing and observability. Standards-based APIs are enormously valuable because they reduce unnecessary variation and create a more sustainable foundation for connected care.

But technical excellence should serve a larger design.

The strongest interoperability programmes begin by describing what should become possible once the integration exists.

A clinician should be able to see the relevant information without searching another system. A referral should arrive with enough structured information to be safely triaged. A patient should not have to repeat information that another authorised service already holds. A result should reach the person responsible for acting on it. An application should be able to interpret a clinical concept consistently rather than guessing from local codes. A failed transaction should be visible before it becomes a missed clinical action.

Once the outcome is clear, teams can work backwards.

What is the workflow? Where does the decision occur? Who owns it? What information is required at that moment? Which system currently holds it? What does each data item mean? Which standards represent it? What is the authoritative source? What happens when information conflicts? Which action should the receiving system enable? What can fail? How is the failure detected? What does the user do when the integration is unavailable?

Only then does the API specification sit within its full context.

This approach also changes how integration is tested.

Traditional interface testing tends to concentrate on technical behaviour: valid requests, invalid requests, expected responses, authentication, mappings, error conditions, performance and resilience. All of that is necessary, but healthcare interoperability needs additional layers of validation.

Semantic testing asks whether the meaning survives the exchange.

Workflow testing asks whether users can complete the intended task.

Clinical safety testing asks whether foreseeable failures or misunderstandings 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 genuinely better than the one it replaces.

And end-to-end testing asks the most important question of all: does the complete pathway work across every system and organisation involved?

This is particularly important for digital health suppliers trying to scale across the NHS.

The first integration with an NHS organisation can create a false sense of confidence. A supplier learns one EPR, one configuration, one set of workflows and one local interpretation of the data. The technical components become reusable, so the second implementation is expected to be easier.

Some of it will be.

But the difficult variation is often not in HTTP, JSON or FHIR. It is in the surrounding environment.

Another organisation may use the same EPR differently. Fields may be configured differently. The pathway may allocate responsibility to a different team. Local terminology may vary. One trust may need information written back immediately while another requires additional review. The same message may trigger a different operational response. A process that was acceptable in one organisation may introduce risk in another.

Scalable interoperability therefore depends on knowing what should be standardised and what genuinely needs to remain configurable.

The technical foundation should be reusable wherever possible. Authentication patterns, API clients, observability, mappings, test harnesses and core data models should not be reinvented unnecessarily.

At the same time, organisations need a deliberate implementation layer in which workflow, semantics, clinical safety and operational responsibilities are validated locally.

That balance matters. If everything is bespoke, integration becomes slow and expensive. If everything is assumed to be identical, the product becomes brittle and unsafe.

This leads to a broader point about the future of connected healthcare.

As APIs become more widely available, basic connectivity will become less differentiating. The strategic advantage will shift towards organisations capable of using connectivity to redesign care.

That requires a wider definition of interoperability. It means understanding interoperability not as the ability of two machines to exchange information, but as the ability of patients, professionals and organisations to complete meaningful activities across digital and organisational boundaries.

That is a substantially harder problem.

It is also a much more valuable one.

Healthcare does not ultimately need an API between System A and System B. It needs the patient discharged from hospital to have the right information available to the community team. It needs the GP to know what happened elsewhere in the pathway. It needs a clinician to see the important result at the point a decision is being made. It needs the patient to avoid explaining the same history for the fifth time. It needs responsibility for the next action to be unmistakable.

The API is one mechanism through which those outcomes can be achieved.

It is not the outcome itself.

This is why interoperability programmes should resist declaring victory when data begins to flow. Data moving successfully is only the first test. The real test is whether meaning has survived, whether the information appears at the right moment, whether somebody can act on it, whether the process remains safe when things go wrong and whether the new way of working has genuinely improved care.

In other industries, integration can sometimes be understood primarily as systems engineering. In healthcare, it is systems engineering embedded inside a clinical, organisational and human system.

Healthcare interoperability FAQs

What NHS interoperability standards should digital health suppliers follow?
Digital health suppliers should check the NHS Standards Directory and NHS England API and integration catalogue for standards relevant to their use case. Depending on the service, this may include NHS API standards, FHIR-based specifications, patient identification requirements and national information standards.

How does information governance affect healthcare interoperability?
Healthcare interoperability does not automatically create permission to share patient data. Organisations still need an appropriate legal basis, access controls, data protection measures and clear purposes for processing information, particularly when data moves between separate health and care organisations.

What is the role of shared care records in NHS interoperability?
Shared care records bring together information held by different health and care organisations so authorised professionals can access a broader view of a person’s care. They are an important part of NHS interoperability, but they are not the same as making every underlying clinical system directly interoperable.

Can open APIs reduce vendor lock-in in healthcare IT?
Yes. Open, standards-based healthcare APIs can make it easier for NHS organisations to connect different products without relying on bespoke interfaces controlled by a single supplier. This can improve portability, increase technology choice and make future system replacement or integration easier.

How can an NHS organisation measure its interoperability maturity?
Interoperability maturity can be assessed by looking beyond the number of connected systems. Useful indicators include adoption of open standards, ease of connecting new suppliers, availability of reusable APIs, consistency of data-sharing arrangements, portability of information and the cost and effort required to introduce or replace digital services.