Healthcare Interoperability
Healthcare Interoperability Challenges in the NHS: Six Real Problems and How to Solve Them
Interoperability fails in NHS Trusts at predictable points: identity, legacy systems, governance, latency, and ownership. Six healthcare interoperability challenges, six practical responses, written for the IT Leads and Digital teams who actually run the integration estate.WeHub
Reading time: ~7 minWritten for the senior NHS IT Lead, Digital Lead, or CTO. TOFU positioning: assumes the reader is researching the landscape, not yet evaluating a specific product. The piece is technical enough to earn credibility (real systems, real protocols, real governance artefacts named) but stays at the architectural level rather than going into protocol detail, which would be MOFU territory. The closing deliberately reduces the next action to "map what you have", which is something the reader can do without involving any vendor, including WeHub. That's the right move at TOFU: build trust by pointing somewhere useful, not somewhere commercial.
What we mean by interoperability (in NHS terms)
Before listing challenges, it helps to be specific. Interoperability in an NHS context covers at least four distinct things, and conflating them is itself part of the problem.There's syntactic interoperability (can the systems exchange messages at all). Semantic interoperability (do the messages mean the same thing on both sides). Process interoperability (does the workflow continue cleanly across systems). And organisational interoperability (do the governance, identity, and ownership models line up).Most public conversations focus on the first two. The Trusts that struggle most are usually stuck on the last two, and they don't realise it because the architecture conversation never gets there.1. The standards problem isn't really a standards problem
The textbook framing is that NHS interoperability is hard because too many standards exist: HL7v2, FHIR R4, CDA, OpenEHR, plus a long tail of proprietary APIs and CSV file drops. Pick one, the argument goes, and the problem solves itself.In practice, no Trust gets to pick one. A Trust integration architect will be working with HL7v2 ADT feeds from a PAS that was deployed in 2009, FHIR endpoints from a newer EPR module, batch CSV exports from a workforce system, and a SOAP service for some piece of pathology that nobody has touched in years. Modernising one of those costs six figures and breaks two clinical workflows. Modernising all of them is a multi year programme.
2. Identity is the silent killer
The most common assumption new architects make is that the NHS number solves identity. It doesn't, for several reasons.NHS numbers are missing or wrong on a non trivial proportion of records, particularly for unscheduled care, neonates, and overseas visitors. Local systems often hold a mix of MRN, NHS number, and a cached PDS demographic that drifted six months ago. Cross Trust referrals introduce yet another identifier. The moment two records on either side of an integration disagree about which person they describe, the entire feed becomes suspect, and so does every downstream report.How to approach it: treat identity as a first class concern in every integration, not a field on a payload. PDS reconciliation should run as a scheduled workflow against the master records you rely on. Mismatches should be surfaced for a human to resolve, not silently overwritten. Every integration should log which identifier it matched on, and what it did when matching failed. That log is the difference between a one hour investigation and a two week one.3. Legacy systems and the integration engine that grew teeth
Nearly every Trust has an integration engine somewhere. Mirth, Rhapsody, Ensemble, Cloverleaf, occasionally something bespoke that an architect built in 2014 and then left. These engines are doing useful work, but they are also where institutional knowledge goes to die.The challenge is rarely the engine itself. It's that the channels running on it have grown over a decade with no consistent design, limited documentation, and clinical workflows that depend on subtle behaviours nobody dares change. A new requirement comes in, and the safest path is to add another channel rather than refactor an existing one. Eventually the engine becomes a museum of past decisions and the smallest change carries clinical risk.How to approach it: catalogue what's actually running before you propose anything new. Each channel should have an owner, a purpose, a data flow diagram, and a test plan. Channels without owners get an end of life date. New integrations should be built outside the legacy engine where possible, with an explicit migration path planned for the legacy ones. The point is not to replace the engine. It's to stop treating it as a free dumping ground.4. Governance is part of the integration, not a gate in front of it
The DSPT, DCB 0129/0160, DPIAs, and the local Caldicott process are often treated as paperwork that happens before or after the technical work. That framing is what makes them painful.Governance fails late when it's treated as a gate. The clinical safety case gets written in the final week. The DPIA discovers an unflagged personal data flow. The DSPT evidence is reconstructed from memory. The go live slips. None of this is the governance team's fault. It's a design problem.How to approach it: build the governance artefacts as part of the integration design from day one. Data flow maps, identity handling, retention rules, and audit logging should be design inputs, not afterthoughts. The DCB 0129/0160 hazard log is far easier to maintain when it's written alongside the integration spec. DSPT evidence is far easier to produce when audit logging is in place by design rather than retro fitted under deadline pressure.5. Real time expectations against batch reality
Clinicians and operational managers increasingly expect data to be available now. The reality is that a large proportion of NHS data flows are still nightly batch, with some weekly and a small number running closer to real time. The gap between expectation and reality is where dashboard credibility dies.The integration layer is often blamed, but the real cause is usually a mix: source systems that only emit in batch, governance approvals that only cover batch, and downstream consumers that were originally designed assuming overnight refresh.How to approach it: be explicit about the latency contract for every feed. A feed that runs nightly should be labelled as such in the dashboard, in the data dictionary, and in any clinical safety documentation that depends on it. Where real time is genuinely needed, treat it as a separate integration with its own design (event driven, narrower scope, tighter monitoring) rather than as an upgrade of the batch one. Mixing the two inside a single channel is how you lose both.6. The ownership question nobody wants to answer
The final challenge is the one that breaks most integration estates over time: who owns the integration when it fails at 3am.The answer in most Trusts is "it depends". Sometimes the EPR vendor. Sometimes the integration team. Sometimes a third party supplier whose contract has lapsed. Sometimes nobody at all, which is how silent failures stretch from hours into weeks before anyone notices.How to approach it: every integration in production should have a named owner, an SLA, a runbook, and a monitoring view. If any of those four are missing, the integration isn't really in production, it's just running. The Trusts with the most stable interoperability estates are not the ones with the cleverest architecture. They're the ones where every feed has someone who is explicitly accountable for it on a Tuesday afternoon and at 3am on a Saturday.The pattern behind these healthcare interoperability challenges
The six challenges look different on the surface, but the underlying pattern is consistent. Interoperability fails when it's treated as a one off project rather than an operational capability. Standards, identity, legacy systems, governance, latency, and ownership all degrade quietly between projects, and the cost surfaces somewhere downstream: a clinical incident, a reporting variance, a DSPT finding, a stalled programme.The Trusts that handle this well aren't the ones with the largest integration teams. They're the ones who have stopped treating each integration as an isolated piece of plumbing and started running interoperability as a managed capability, with a normalised internal model, named owners, designed in governance, and explicit latency contracts.Where to start this week
If this list of healthcare interoperability challenges looks familiar and the question is what to do first, pick the one that's costing you most right now. For most Trusts, that's either identity reconciliation (because it corrupts every downstream feed) or ownership (because it's the reason failures last for weeks rather than hours).Map the integrations you have in production today. Note the owner, the SLA, the protocol, and when each was last reviewed. The blanks in that table are next quarter's roadmap. You don't need a transformation programme to start. You need an honest map.Keywords
healthcare interoperability challengesNHS interoperabilityFHIR R4HL7v2NHS integration architecturePDS reconciliationDSPTDCB 0129/0160NHS integration enginehealthcare data integrationNHS digital architecture
Ready to fix this in your workflow stack?
Related Blogs
Turn healthcare workflow ideas into production-ready delivery
Whether you're exploring interoperability, workflow automation, HL7, FHIR, ESR, or internal operational delivery, WeHub helps teams design, govern, and run workflows without unnecessary complexity.
- Built for healthcare integration and operations
- Faster delivery with reusable workflow components
- Better governance, visibility, and scale