Most conversations about healthcare technology focus on what’s new: AI diagnostics, virtual wards, the next wave of patient apps. Data integration gets less airtime, but it determines whether any of that works. When clinicians make decisions on partial records, when administrators re-key the same information across three systems, when population health teams try to analyse data that doesn’t reconcile, the cause is usually the same. The data exists. It just can’t move between systems cleanly.
Where Fragmentation Comes From
A typical NHS trust runs an EPR for acute care, a different platform for community services, a GP system older than most of its users, and a growing list of newer digital services bolted on as needs emerge. Each was built with its own data model, its own patient identifier logic, and its own conventions for representing essentially the same information. A surprising amount of internal messaging still runs on HL7 v2, a standard that pre-dates modern API design by several decades.
The result is familiar to anyone working in healthcare. A clinician treating a patient across two settings often works from two separate records that don’t share state. Referrals between organisations rely on document exchange, manual re-entry, and email. Discharge summaries land in primary care as PDFs. Verifying a medication history can mean picking up the phone. None of this is unusual. It’s just been around long enough that people have stopped noticing it as a problem.
The root cause is consistent. Systems were never designed to talk to each other. And now they’re too embedded in clinical workflows to rip out.
The Legacy System Problem
A platform built fifteen years ago, on a proprietary data model, with no REST API and database schemas that were never meant to be read externally, is genuinely hard to connect to anything modern. Integration options are limited. Documentation is partial at best. Every change carries risk that’s disproportionate to its scope.
Replacement is the obvious-sounding answer. And it’s almost always wrong. A mature EPR or ERP holds years of operational logic, customisations, and workflow configuration that don’t migrate cleanly. The data inside is frequently the most complete clinical record the organisation has. Replace the system and you either migrate that data successfully (usually a multi-year programme in itself) or you accept losing historical continuity.
The more workable approach is to treat the legacy system as a stable core and build a controlled integration layer around it. Data gets surfaced through well-defined API contracts rather than direct database reads. Event-driven messaging lets downstream systems receive updates asynchronously instead of polling. A canonical data model at the boundary normalises the legacy system’s quirks before they reach anything modern. The integration layer takes on the complexity, and everything built around it gets a stable, versioned interface to work against.
What Healthcare Interoperability Requires
HL7 FHIR R4 has become the dominant interoperability standard in modern healthcare. It now sits at the foundation of NHS software strategy, underpinning the NHS API catalogue and the digital commitments in the 10-Year Plan. Its RESTful model and structured resources are far more composable than the HL7 v2 messages and proprietary web services that came before. But FHIR compliance is where interoperability starts, not where it ends.
Genuine interoperability means implementing national FHIR profiles so resource structures and terminology bindings line up with what national services expect. It means OAuth 2.0 and SMART on FHIR for explicit, auditable access control. It means connecting to national services through the published NHS APIs rather than improvised point-to-point interfaces. And it means integrating with the NHS App. The 10-Year Plan positions it as the patient’s single digital front door for appointments, records, and care.
Semantic interoperability is the harder problem underneath all of this. Two FHIR-compliant systems can still exchange data that means nothing to the receiver if coding systems differ or value sets don’t align. A medication coded in SNOMED CT in one system and a local formulary code in another won’t reconcile on its own. Fixing that takes canonical modelling, terminology mapping, and normalisation at the point of exchange, none of which the FHIR specification does for you.
Our Expertise
We work at the intersection of legacy estate management, modern integration architecture, and clinical safety. Engagements typically start with a full audit of existing systems, data flows, and integration touch points, and produce a modernisation roadmap grounded in what the organisation can realistically deliver. Not a textbook architecture that ignores the actual constraints.
Where legacy systems need to stay in place (which is most of the time), we build a decoupled integration layer around them using API-first architecture, event-driven messaging, and FHIR-compliant contracts. The legacy platform keeps running. Everything around it gets a clean, stable interface, along with the surface area needed to connect into NHS national APIs as requirements evolve.
See It in Practice
A UK healthcare services provider came to us with a long-established Microsoft NAV-based ERP sitting at the centre of its operational and patient-linked workflows. The system was stable and heavily customised, but its integration surface was narrow, and any change to it carried real clinical risk.
We built a decoupled, event-driven integration architecture on Microsoft Azure around it. Containerised .NET microservices expose stable, versioned integration contracts and orchestrate multi-step workflows using the saga pattern, covering demographic verification, approval routing, and controlled write-back into the legacy ERP without disrupting live operations.
Read the full case study → Legacy Healthcare ERP Integration on Microsoft Azure – Microservices Modernisation
