Healthcare Interoperability
Healthcare API Integration: A Technical Guide for Digital Health Platforms Connecting NHS Systems
Healthcare API integration is where most digital health platforms quietly accumulate technical debt. This guide covers the architecture decisions, standards layers, and operational patterns NHS IT teams and platform builders need to connect clinical systems without building a maintenance nightmare.WeHub
Reading time: ~7-9 minHealthcare API integration is where most digital health platforms quietly accumulate technical debt. This guide covers the architecture decisions, standards layers, and operational patterns NHS IT teams and platform builders need to connect clinical systems without building a maintenance nightmare.
The Integration Meeting That Never Ends
Every NHS Trust has a version of this meeting. The digital programme team sits down with a new supplier, a clinical system vendor, or an internal development squad. Someone says: "We just need to connect System A to System B." The conversation starts simple. Then someone mentions PDS lookups. Someone else asks about HL7 ADT feeds from the PAS. The IG lead raises data minimisation. An hour later, the whiteboard is full and no one has written a line of code.That meeting is the real starting point for healthcare API integration. Not a Swagger file. Not a FHIR endpoint. The meeting where the team realises that connecting clinical systems is an architecture problem disguised as a connectivity task.This guide is for the people in that room: NHS IT leads, integration architects, digital health platform builders, and the technical leads who have to make these connections work at Trust scale without building something that collapses under its own weight.What Healthcare API Integration Actually Means in an NHS Context
Strip away the vendor language and healthcare API integration is the practice of moving structured clinical and operational data between systems that were never designed to talk to each other. In the NHS, that means connecting patient administration systems, electronic staff records, e-referral services, prescribing platforms, demographic services, and dozens of departmental tools that each speak a slightly different dialect.The technical challenge isn't exposing a REST endpoint. Most modern systems can do that. The real challenge is threefold.First, there's the standards mismatch. Your PAS might emit HL7v2 ADT messages over MLLP. Your analytics platform expects FHIR R4 bundles over HTTPS. Your workforce tool ingests flat ESR files via SFTP. These aren't just different formats. They encode fundamentally different assumptions about data structure, patient identity, and event semantics.Second, there's the trust boundary problem. NHS organisations operate under strict information governance. Every API connection crosses a trust boundary, whether it's between two internal systems or between a Trust and an external supplier. That boundary carries DSPT compliance expectations, GDPR obligations, and often a sign-off process that takes longer than the integration build itself.Third, there's the operational reality. Healthcare API integrations don't run in a clean test environment. They run against live patient data, real staffing rosters, and clinical workflows where downtime has direct care consequences. The gap between "it works in dev" and "it works at 08:00 on a Monday when the PAS is processing 400 ADT messages per minute" is where most integration projects quietly fail.Why REST Alone Doesn't Solve NHS Integration
It's tempting to treat healthcare API integration as a modern web development problem. Stand up a RESTful API, document it in OpenAPI, hand over the keys. For some use cases, that works. For NHS integration at scale, it falls apart quickly.The core issue is that REST assumes a request/response pattern between two systems that share a common understanding of the data model. In healthcare, that assumption rarely holds.Consider a common scenario: a digital health platform needs to receive real time admission, discharge, and transfer updates from a Trust's PAS. The PAS doesn't offer a webhook or a RESTful subscription. It emits HL7v2 ADT messages over MLLP, a TCP based protocol designed in the 1990s. Your platform speaks JSON over HTTPS. Between those two systems sits a translation layer, a transport bridge, error handling logic, message acknowledgement, and probably a queue for resilience.That's not an API call. That's a workflow.NHS Spine connectivity adds another dimension. PDS (Personal Demographics Service) lookups, ERS (e Referral Service) submissions, and EPS (Electronic Prescription Service) messages each have their own authentication models, message formats, and operational constraints. A platform that treats Spine as "just another API" will struggle with ASID registration, mutual TLS, and the specific message sequencing that Spine expects.The lesson here isn't that REST is wrong. It's that healthcare API integration requires a transport layer strategy, not just an API design.The Standards Layer: HL7, FHIR, and the Translation Problem
Every healthcare API integration project eventually confronts the standards question: which version of HL7, which FHIR release, and how do you bridge between them?HL7v2 remains the dominant messaging standard across NHS acute Trusts. ADT messages, ORM/ORU lab orders and results, and SIU scheduling messages flow in HL7v2 format between PAS, LIMS, radiology, and dozens of other departmental systems. If your platform integrates with Trust infrastructure, you will encounter HL7v2. It's not optional.FHIR R4 is the strategic direction. NHS England's interoperability standards increasingly mandate FHIR, and newer systems, particularly those built for the NHS App ecosystem and GP Connect, expose FHIR APIs natively. But FHIR adoption across acute Trusts is uneven. Many Trusts run HL7v2 interfaces that have been stable for years, and replacing them with FHIR equivalents is a multi year programme, not a quick migration.The translation problem is where integration platforms earn their keep or reveal their limits. Converting an HL7v2 ADT^A01 admission message into a FHIR R4 Encounter resource isn't a mechanical format swap. Field mappings are ambiguous. HL7v2 segments like PID (patient identification) and PV1 (patient visit) carry data that maps to multiple FHIR resources. Terminology codes need translating: ICD-10 to SNOMED CT, local codes to national standards. Every Trust has local extensions and custom Z segments that no standard converter handles out of the box.This is why healthcare API integration demands configurable transformation logic, not just a static converter. The platform needs to handle HL7 to FHIR conversion, FHIR version bridging where STU3 to R4 remains common, C-CDA to FHIR for cross-border or legacy document exchange, and ESR file parsing for workforce data flows. Each of these carries Trust specific configuration that changes between deployments.Authentication, Consent, and the Compliance Surface Area
Healthcare API integration doesn't just move data. It moves data that is governed by some of the most demanding compliance frameworks in the UK.DSPT (Data Security and Protection Toolkit) sets the baseline. Any organisation connecting to NHS systems must demonstrate compliance, and integration platforms that handle patient data are in scope. This isn't theoretical. IG teams at Trusts will ask for your DSPT status before granting API access.GDPR and the UK Data Protection Act 2018 impose data minimisation requirements that directly affect API design. If your integration pulls a full FHIR Patient resource when you only need the NHS number and GP practice code, you're collecting more data than you need. Every field in every API response should be justifiable under the lawful basis you've documented.Authentication varies by system. NHS Spine uses certificate based mutual TLS with registered ASIDs. Internal Trust systems might use OAuth 2.0, API keys, or in some cases, IP whitelisting. ESR file transfers typically run over SFTP with SSH key authentication. A healthcare API integration platform needs to manage all of these credential types centrally and rotate them without disrupting live workflows.Consent is the layer that most integration architectures underestimate. For patient facing data flows, the platform must respect consent preferences stored in Spine or local consent services. For workforce data, the governance model is different but equally strict. Getting authentication right is table stakes. Getting consent and data minimisation right is what separates a compliant integration from a reportable breach.Architecture Patterns That Hold Up at Trust Scale
After working through the standards, compliance, and transport layers, the architecture question becomes concrete: how do you structure a healthcare API integration that handles multiple data formats, multiple authentication models, and the operational demands of a live NHS environment?Pattern 1: Event driven pipelines with message queuing. Instead of synchronous API calls between systems, route messages through a queue or broker. This decouples the sending system from the receiving system, absorbs traffic spikes, including Monday morning ADT floods, and gives you a natural point for retry logic and dead letter handling. For HL7v2 feeds, this means receiving messages via MLLP, acknowledging them immediately, and processing them asynchronously through a transformation pipeline.
Where Integration Platforms Fit (and Where They Don't)
A healthcare specific integration platform solves the middle layer problem. It sits between the systems that produce data and the systems that consume it, handling transport bridging, format translation, credential management, and workflow orchestration.Where platforms add clear value: replacing custom point to point integrations that are expensive to maintain, providing a visual layer that lets integration engineers build and test data flows without writing bespoke code for every connection, and standardising how a Trust or digital health organisation handles HL7, FHIR, ESR, and Spine connectivity across multiple projects.Where platforms don't fit: if you're connecting two modern FHIR native systems with a clean, well documented API and no transformation requirements, a direct connection is simpler and cheaper. Don't add middleware where it doesn't earn its place.The honest test is this: if your integration involves more than one data format, more than one authentication model, or more than one downstream consumer, you're building a workflow, not making an API call. That's where a platform approach starts to justify itself.The Decision You're Actually Making
Healthcare API integration isn't a technology choice. It's an architecture decision about how your organisation handles the growing volume of data that needs to move between clinical, operational, and administrative systems.The teams that do this well share a few traits. They treat integration as infrastructure, not as a project. They invest in configurable middleware rather than custom code for every connection. They build compliance into the data flow, not around it. And they plan for the next ten integrations, not just the current one.The practical next step is straightforward: map the data flows you're running today. Identify which ones are point to point, which involve manual file transfers, and which rely on a single person who knows how the HL7 feed works. That map is where your integration architecture starts, and it will tell you more about what you actually need than any vendor demo.If you're working through that mapping exercise and want to see how a healthcare specific integration platform handles the HL7, FHIR, and ESR layers in practice, WeHub's team can walk you through a working example.Keywords
healthcare API integrationhealthcare integration APIsdigital health platform integrationFHIR R4HL7v2NHS SpinePDSESRDSPTAPI authenticationintegration architectureNHS interoperabilityworkflow automation
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