Healthcare integration is treated as a single challenge but in practice it splits into fundamentally different ones. The approach that works for real-time clinical data exchange is a poor fit for population analytics, and the one that suits administrative workflows is different again. Choosing the wrong pattern is where most integration programmes quietly go wrong.
API-Based Integration
API-based integration is the dominant pattern for real-time, event-driven data exchange between healthcare systems. Rather than moving data in bulk on a schedule, APIs allow systems to request or push specific records at the moment they are needed. When a clinician triggers a lookup, when a patient is admitted, when a referral is submitted.
In an NHS context, this means stable API contracts that consuming applications can rely on without being tightly coupled to the system behind them. An API gateway sits in front of the integration layer handling authentication (OAuth2/OpenID Connect), throttling, schema validation, and request transformation.
The operational requirements for production API integrations are consistently underestimated. Retry logic, dead-letter handling for failed requests, correlation IDs for tracing, and immutable audit records at each transaction boundary. These are what makes the difference between an integration that works in testing and one that holds up in live clinical use.
HL7 and FHIR
HL7 v2, the pipe-delimited format most EPR administrators will recognise, still carries a very large share of healthcare data integration in NHS trusts and GP systems. It is well understood, widely supported, and not going away. FHIR is HL7’s modern successor. The difference in design philosophy matters significantly.
Where HL7 v2 is a messaging format, FHIR is a resource model with RESTful APIs built around it. Clinical concepts such as patients, observations, conditions, medications, and appointments are represented as discrete, addressable resources. It is making them queryable, composable, and far easier to integrate with modern web and mobile applications. FHIR R4 is now the standard NHS integration programmes are expected to implement.
What FHIR does not solve on its own is semantic alignment. Two systems can both be FHIR R4 compliant and still exchange data that neither can interpret correctly. That is because one uses SNOMED CT coding and the other uses ICD-10. Closing that gap requires a canonical clinical data model, concept mapping services, and field-level validation at the exchange boundary. The semantic work is usually more effort than the FHIR implementation itself.
FHIR Bulk Data Access has become the preferred extraction mechanism for population health use cases. It replaced bespoke database exports that are fragile, difficult to version, and carry real clinical risk when source schemas change.
ETL (Extract, Transform, Load) in Healthcare Data Integration
ETL is the established pattern for healthcare data integration where real-time exchange is not required. So scheduled loads, analytical pipelines, data warehouse ingestion, and bulk historical migration. In healthcare, ETL pipelines typically pull from GP systems, hospital EPRs, community platforms, and social care systems. Then they normalise everything into a consistent model and land it in a data platform.
The architecture is increasingly built on a lakehouse pattern. Raw data lands in a storage layer, a curated layer applies normalisation and deduplication, and a governed query layer sits above that for analytics consumption. The persistent challenge is semantic consistency. A diabetic patient coded in SNOMED CT in the GP system, ICD-10 in the hospital EPR, and free text in the community record will appear as three different patients to any naive aggregation.
ETL is not appropriate where clinical decisions depend on current data. A discharge summary that arrives at the GP practice via an overnight batch job twelve hours after discharge is a patient safety issue, not a data quality one. Where timeliness matters, ETL should be replaced or supplemented with event-driven integration.
Cloud vs On-Premise
The cloud vs on-premise question in healthcare is less binary than it used to be. Cloud-hosted integration on platforms like Microsoft Azure offers managed infrastructure, elastic scaling, built-in resilience patterns, and integrated security tooling including Entra ID, Key Vault, and Azure Monitor. For integration workloads that process pseudonymised or aggregated data, cloud deployment often makes sense and aligns with NHS Digital’s cloud-first direction.
On-premise or hybrid deployment remains appropriate where data residency requirements, network topology, or clinical safety governance constrains where processing can occur. HSCN connectivity requirements, Spine integration, and some NHSmail integrations have specific network path dependencies that affect architecture decisions regardless of cloud preference.
The more relevant question for most NHS programmes is not cloud vs on-premise but how the integration layer is designed: whether it has proper identity and access controls, whether audit trails are immutable and complete, whether it meets DSPT and DTAC requirements, and whether clinical safety has been considered from the start rather than added on before go-live.
Our Expertise
We connect healthcare systems using FHIR-based integrations and the data-sharing patterns underneath them. Our work covers EHR connectivity across Epic, Cerner, and NHS-specific platforms; full FHIR R4 implementation; real-time synchronisation; mobile and analytics integration; and the security and compliance posture including DSPT, DTAC, and DCB.
See It in Practice
A UK healthcare services provider had a long-established Microsoft-based ERP as its system of record for operational and patient-linked workflows. The platform was stable and heavily customised, but its integration options were limited and any change carried high operational and clinical risk. The organisation needed a path to modern digital services and national-level data exchange without a disruptive replacement programme.
We delivered a decoupled, event-driven integration layer on the Microsoft stack. Containerised .NET microservices exposed stable integration contracts, orchestrated multi-step workflows including demographic verification and write-back, and applied controlled updates to the ERP via an idempotent update service. Azure API Management provided the governed front door with OAuth2/OpenID Connect and schema validation. Azure Service Bus handled messaging with retries and dead-letter queuing. Entra ID, Key Vault, and Azure Monitor enforced access controls, protected secrets, and provided full audit trails, all without disrupting live clinical operations.
Read the full case study → Legacy Healthcare ERP Integration on Microsoft Azure – Microservices Modernisation
