API integration for healthcare: enabling safe, compliant data flow

Why healthcare integration is different

Most API integration projects carry the usual risks: data loss, downtime, incorrect mappings. In healthcare, those same risks carry clinical consequences. An incorrect medication record surfaced to a prescribing system, a missing allergy flag, a referral that never reached the receiving team – the stakes are measurably higher than in almost any other sector.

This changes how integrations are scoped, tested and governed. You can't treat a patient data pipeline the same way you'd treat a CRM-to-marketing-platform sync. Error handling needs to be exhaustive. Audit trails are mandatory. Every system that touches patient data carries obligations under UK GDPR, and every third party in the chain must be assessed.

There's also the standards layer. Healthcare has its own interoperability protocols, messaging formats and national infrastructure that sits entirely outside the standard API landscape. Understanding those isn't optional – it's what makes the integration work.

Clinical system interoperability: HL7 and FHIR

Two standards dominate clinical data exchange in the UK and internationally.

HL7 – Health Level 7 – is the older messaging standard. It defines how clinical data is structured and transmitted between systems, using a pipe-delimited message format (HL7 v2) that has been the backbone of hospital system communication for decades. It's not pretty, but it's widely implemented and still active across NHS trusts, private hospitals and diagnostic labs.

FHIR – Fast Healthcare Interoperability Resources – is the modern standard, developed by HL7 International to bring healthcare data exchange into the REST API era. FHIR defines resources (Patient, Observation, Appointment, Medication, etc.) that can be queried and updated over standard HTTP. NHS England has standardised on FHIR R4 for new national programme integrations, and it's the direction of travel for EPR vendors and GP system suppliers.

In practice, most NHS integrations today involve both. Legacy systems still emit HL7 v2 messages; new integrations and national programme connections use FHIR. A clinical system integration will often require mapping between the two, handling the translation layer between what a legacy EPR produces and what a modern API expects to receive.

EPR and patient record system connections

An EPR – Electronic Patient Record – is the core clinical system for a hospital or healthcare provider. It holds the longitudinal patient record: admissions, diagnoses, medications, procedures, test results, clinical notes. In secondary care, the dominant EPR vendors in the UK include Epic (increasingly common in NHS trusts after large-scale deployments), Oracle Health (formerly Cerner) and a range of legacy systems that vary by trust.

In primary care – GP practices – the market is dominated by EMIS Health and TPP SystmOne, both of which have their own API access programmes and data sharing frameworks. Connecting to either requires working within their approved access routes and, for NHS-connected use cases, going through the relevant national assurance process.

EPR integrations are rarely simple. Vendors control API access tightly, implementation guides run to hundreds of pages, and the data model is clinical rather than commercial – meaning the fields, codes and terminologies (SNOMED CT, ICD-10, OPCS) need clinical understanding to map correctly. Getting the clinical terminology right matters: a code mapping error isn't a data quality issue, it's a patient safety risk.

Referral and appointment booking integrations

Referral management and appointment booking are among the most common integration use cases in NHS and private healthcare settings, and both have specific national infrastructure to navigate.

NHS e-Referral Service (e-RS) is the national platform for consultant outpatient referrals from primary to secondary care. It has a published API that allows GP systems and referral management tools to create, manage and route referrals. Integrating with e-RS requires NHS Digital API access approval and appropriate IG controls.

Appointment booking – particularly the NHS Appointment Booking Standard – increasingly uses FHIR-based APIs. Direct booking into hospital slots from GP systems, or from patient-facing applications into primary care, operates through this framework. The technical implementation is well-defined; the access and assurance process is the longer path.

In private sector settings, referral and booking integrations are typically proprietary – connecting a consultant's practice management system to a hospital PAS (Patient Administration System), or linking a patient-facing booking portal to a clinician's diary. The governance requirements are still strict, but the national assurance layer doesn't apply in the same way.

Data governance and information governance (IG) compliance

Information governance – known as IG in NHS contexts – is the framework that covers how patient data is handled, shared and protected. It sits above and alongside UK GDPR, incorporating NHS-specific policies, the common law duty of confidentiality and Caldicott principles for patient data use.

For any integration that touches patient data, data controller and data processor relationships need to be established clearly. Under UK GDPR, the organisation that determines the purpose of processing is the data controller; a third-party supplier building or operating the integration is typically a data processor. That relationship must be documented in a Data Processing Agreement, and the processor must provide sufficient guarantees about their technical and organisational security measures.

Where patient data is being used for analytics or reporting rather than direct care, pseudonymisation and anonymisation become important. Pseudonymised data – where direct identifiers are replaced with a reference key – is still personal data under UK GDPR but carries lower risk. Anonymised data, where re-identification is genuinely not possible, falls outside GDPR entirely. The line between the two is more technical and legal than most organisations appreciate.

Data Sharing Agreements are required wherever patient data moves between organisations. In NHS settings, these are often routed through Data Access Request Service (DARS) for national datasets, or directly between organisations for local sharing arrangements. Getting the legal basis right before an integration goes live is not optional.

NHS Digital standards and DSP Toolkit

NHS Digital – now operating as NHS England's digital function following the 2023 merger – sets the standards that NHS-connected systems must meet. The primary compliance mechanism for suppliers and NHS organisations is the DSP Toolkit – Data Security and Protection Toolkit – an online self-assessment tool that maps to the National Data Guardian's ten data security standards.

Any organisation that connects to NHS systems, handles NHS patient data or provides services to NHS organisations is expected to complete the DSP Toolkit annually. For suppliers, this means demonstrating that your data security practices, staff training, system controls and incident management processes meet the standard. It's not a light-touch exercise – the assessment covers dozens of assertions across data security, staff responsibility and IT infrastructure.

For clinical system access specifically, the NHS Smart Card and its successor CIS2 (Care Identity Service 2) authentication are the identity and access control mechanism. Systems that need to act on behalf of authenticated clinical users – rather than just receive data via a batch feed – must integrate with CIS2. This is a different authentication flow from standard OAuth and requires its own technical implementation and assurance.

NHS Spine is the national infrastructure that underpins most cross-organisation patient data sharing in England. It includes the Personal Demographics Service (PDS) for patient identity, the Summary Care Record (SCR), the Electronic Prescription Service and other national services. Connecting to Spine requires going through NHS England's onboarding process, which includes technical conformance testing and IG assurance.

MESH – Message Exchange for Social Care and Health – is the NHS's managed messaging gateway. It's used for secure file-based data exchange between NHS organisations and approved suppliers: pathology results, discharge summaries, referrals, screening data. If your integration needs to send or receive batch clinical data with NHS organisations, MESH is likely the channel.

Patient-facing applications and portals

Patient portals, online consultation tools and digital health applications that connect to clinical systems sit in a distinct category. They involve patient-initiated authentication, consumer-grade user experience expectations and the additional sensitivity of patients directly accessing their own health data.

The NHS Login service provides a national patient identity and authentication layer for NHS-connected patient-facing apps. Integrating with NHS Login allows patients to authenticate once and access multiple services without separate credentials. It uses standard OpenID Connect flows, but the connection itself requires assurance from NHS England.

Patient access to GP records via FHIR APIs – the GP Connect programme – allows approved applications to retrieve appointment information, access care records and send structured data to GP systems. The technical standard is published, but access is gated on supplier assurance and, in some cases, individual practice opt-in.

Private sector patient portals – those operated by independent hospitals, clinics or digital health companies outside the NHS – don't use NHS Login, but still carry the same data protection obligations. The underlying requirement to handle patient data lawfully, securely and transparently applies regardless of whether the system connects to the NHS.

Security requirements for healthcare integrations

Healthcare integrations carry security requirements that go beyond standard web application practice. Clinical systems are high-value targets; patient data is valuable on secondary markets; and the consequences of a breach – regulatory, reputational and patient safety – are severe.

Network segmentation is standard practice for clinical system environments. Systems that process patient data should sit on separate network segments from general IT infrastructure, with strict controls on what can communicate with what. This applies both to on-premise deployments and cloud architectures where clinical workloads should be isolated from other tenants and services.

IG penetration testing – penetration testing specifically scoped to information governance requirements – is expected for NHS-connected systems and recommended for private sector healthcare applications. The scope covers both the application layer and the supporting infrastructure, with reporting that maps findings to the DSP Toolkit standards.

ISO 27001 alignment is increasingly expected by NHS commissioning bodies and private healthcare groups when onboarding new suppliers. It's not always a hard requirement, but it's the framework that maps most directly to what the DSP Toolkit is assessing – and having it in place materially simplifies the supplier assurance process.

Encryption in transit and at rest is a baseline, not a differentiator. All patient data must be encrypted using current standards (TLS 1.2 minimum, TLS 1.3 preferred) in transit. Storage encryption is mandatory. Key management – who controls the encryption keys and under what conditions – needs to be documented and defensible.

Audit logging is non-negotiable. Every access to patient data – read or write – must be logged with sufficient detail to reconstruct who did what and when. Logs must be retained for the appropriate period (typically a minimum of two years for clinical data access logs) and protected from tampering.