NHS Integration

NHS Integration Overview

An integration connects two different platforms so they can share data and work together. An electronic patient record (EPR) integration therefore connects an EPR platform with other digital systems to enable the proper flow of clinical data between the two systems.

Unlike EPRs, which records the care provided by one institution or practice, electronic health records (EHRs) focus on the total health of the patient, from cradle to grave, and are designed to share information between healthcare professionals – so an EHR integration would allow access to information from all the clinicians involved in the patient’s care. It means that when a patient attends an outpatient clinic, the clinician can view all their medical history and medications, regardless of which prior service provided the care – as well as all communications between services.

To enhance this interoperability, modern systems increasingly use Artificial Intelligence (AI) for predictive diagnostics and to automatically structure vast amounts of clinical data, making it more insightful. This level of digitalisation underpins the NHS's ongoing ambition to be paper-free.

For pharmacists, the technology used in delivering pharmaceutical care is the Patient Medication Record (PMR) system, which is now widely used to manage patient care.

NHS Integration Options

The UK NHS offers multiple integration options for software system designers – targeting a range of different use-cases, from repeat-prescription apps to remote medical systems. While the NHS has traditionally used systems like MESH, it is increasingly transitioning towards modern, cloud-based APIs and interoperability frameworks like FHIR (Fast Healthcare Interoperability Resources).

Blueberry has worked on many NHS integration software projects, including the UK’s first repeat prescription app for start-up company, Dimec, which was subsequently sold to the Co-op. The market has since evolved significantly, with today's leading solutions often integrating with the NHS App or using AI-powered chatbots to manage prescriptions, a landscape we are well-equipped to navigate.

We have unrivalled experience in this area and are ready to help you deliver complex integrations that deliver significant improvements in patient care.

Note, however, that NHS integration presents significant challenges due to the high standards of data protection and information security that need to be met by anyone working with patient data.

There’s also a minefield of new terminology to navigate – from MESH to DSPT and beyond. Luckily, we’ve provided a terminology guide at the bottom of this page.

NHS API Use Cases

The NHS provides a wide range of different APIs (Application Programming Interfaces), covering multiple different application scenarios. The main scenarios they support are as follows:

Patient Services	You’re creating an app or web application that allows individual patients to access their health data and request services. In this case, you’ll integrate with NHS Login to confirm patient identity - for example, using the PDS API to obtain an NHS number - and then use GP Connect FHIR APIs to securely retrieve structured, real-time data from GP systems on behalf of the patient.
Digital Pharmacy	You’re creating an online pharmacy system that needs to interact with medicines and prescriptions. Typically, you’ll use the NHS Electronic Prescription Service (EPS) API v2 (or newer FHIR-based prescription APIs) to manage prescription workflows, while continuing to use the dm+d database for accurate and up-to-date medicine information.
Clinical Services	You’re creating an application to support clinicians in their work. Secure authentication is essential - while the NHS Smart Card is still used in some legacy systems, newer methods are now the standard. These include NHS Identity with Single Sign-On (SSO) using OAuth 2.0/OpenID Connect, and biometric authentication (such as facial recognition via the NHS App). Once logged in, clinicians can access structured, real-time patient information using GP Connect FHIR APIs.
Submitting Data	You’re creating a telemedicine app that allows patients to record medical information - such as vital signs or home measurements - that needs to be written back into the GP record. The standard approach today is through FHIR-based APIs, such as GP Connect or the National Record Locator Service (NRLS), which have replaced older transactional API methods for submitting patient-generated health data (PGHD).

NHS API Guide

NHS API Access

Most NHS APIs containing sensitive data were traditionally accessed through the private Health and Social Care Network (HSCN). However, NHS England is now transitioning to the NHS Secure Boundary model, which integrates cloud-based security and Zero Trust principles, reducing dependency on costly leased lines.

The monthly fees once associated with HSCN connections may no longer apply under this modern model.

Access to key services - such as PDS-FHIR - is increasingly available over the public internet, with strict security controls in place. NHS England continues to expand the accessibility of FHIR APIs, offering more functionality without the limitations of legacy HSCN access.

Meanwhile, the older IM1 interface has been superseded by modern FHIR-based APIs such as GP Connect, making historic HSCN and IM1 requirements largely irrelevant for new integrations.

Medical Software Compliance

NHS APIs require organisations to follow a strict compliance process, which includes providing details such as your ODS code and data security officer information, and completing managed testing - typically against sandbox or test environments - before going live. These processes remain time-consuming and often take several months, largely due to NHS review cycles.

As of September 2024, the Data Security and Protection Toolkit (DSPT) has been updated to adopt the National Cyber Security Centre’s Cyber Assessment Framework (CAF) as its foundation for cyber security and information governance assurance. NHS England has also created a tailored version for health and care, known as the CAF-aligned DSPT. This framework incorporates all core CAF principles while adding health-specific outcomes, such as ensuring the proper use and sharing of patient information.

Most NHS API integrations must also comply with GDPR, often requiring a Data Protection Impact Assessment (DPIA), and suppliers must complete separate Supplier Conformance Assessment Lists (SCAL) for each integration. These cover detailed organisational and technical requirements aligned with current NHS standards.

Other Software Integration Resources

When working on NHS projects, you’ll probably encounter the following:

DM+D – this is a database of medicines. It converts a drug name, formulation, and dose into a unique ID. However, there are some complexities: first, it works at two levels – generic and actual, with generic covering the medical properties, and actual covering the brand names. Second, it’s large, and you usually must filter it to exclude items that don’t relate to your specific needs.

ODS Codes – every organisation within the NHS, and organisations who work with the NHS have an ODS code. You’ll need to apply for one if you’re working with the NHS.

Pharmacy Systems

Blueberry has delivered a wide range of digital projects in the pharmacy sector, with extensive experience integrating major PMR (Patient Medication Record) systems such as EMIS ProScript Connect, Cegedim, Titan, RxWeb, V-Rx, and Analyst.

The IM1 (Interoperability Message 1) standard, once central to pharmacy messaging, is now considered legacy. By 2025, the NHS has been transitioning toward FHIR (Fast Healthcare Interoperability Resources) and GP Connect APIs, which support more modern, scalable, and real-time data sharing.

In parallel, EMIS Health has been moving its systems to the cloud-based EMIS-X platform, designed to improve interoperability and provide more flexible integration opportunities.

Older HL7 v2 or PDF-based prescription workflows are also being replaced by NHS Digital’s FHIR APIs, EPS Phase 4 for fully electronic prescriptions, and GP Connect for secure, real-time patient record access - reflecting the sector’s broader shift to modern interoperability frameworks.

Planning an NHS Integration Project

We recommend the following steps:

First, make sure you know the types of integration you’d like to do. Who will be using the patient data – patients themselves or clinicians – or just your staff?
Second – apply for an ODS code – you will probably find it necessary. It’s free.
Third – read the pages in this section, and then consider calling us – we can give you impartial and confidential free advice on the right route to take.

NHS API Terminology:

IM1

IM1 is an integration standard defining how existing GP clinical systems providers should allow third parties to connect with their systems. IM1 allows suppliers to integrate their system with any principal clinical GP system through an interface mechanism.

ODS

The Organisation Data Service (ODS) issues and manages unique identification codes and accompanying reference data for organisations that interact with any area of the NHS. ODS codes are used in almost every IT system across the NHS. If your company is interacting with data, you’ll need to apply for an ODS code.

PDS

The Personal Demographics Service (PDS) is the national electronic database of NHS patient details such as name, address, date of birth and NHS number (known as demographic information) and medical information. The PDS API provides access to the demographic data held by the NHS Spine.

REST

Representational State Transfer is a set of architectural/design principles for APIs that when followed, assist in the implemenation of simple, reliable, and scalable APIs. The key principles for REST include, client-server architecture, providing a uniform interface between decoupled components, and ensuring requests are stateless. While REST is not a protocol, REST APIs often make use of common web protocols including HTTP, JSON and XML for exchanging data.

RESTful

Interfaces are often referred to as being “RESTful” when they follow principles of “REST” – in other words, a RESTful interface is one that doesn’t store state.

SCR

The Summary Care Record (SCR) supports patient care in urgent and emergency care settings. The SCR stores a defined set of key patient data for every patient in England except those who elect not to allow it to be disclosed. The data provides a summary record created from information held on GP clinical systems. The SCR FHIR API is used for primary care.

SNOMED CT

SNOMED CT is a clinical vocabulary readable by computers. Used in electronic health records. It gives clinical IT systems a single shared language, which makes exchanging information between systems easier, safer, and more accurate. It contains all the clinical terms needed for the whole NHS, from procedures and symptoms through to clinical measurements, diagnoses, and medications.

SOAP

Simple Object Access Protocol (SOAP) is a technical standard used when sending information to APIs. SOAP allows processes running on disparate operating systems (such as Windows and Linux) to communicate using Extensible Markup Language (XML).

SSP

Spine Secure Proxy is a system within the Spine used to securely broker API calls between external systems.

Spine

The NHS central ‘Spine’ is a collection of national applications, services and directories which support the health and social care sector in the exchange of information in national and local IT systems. Clinical information is held in the Personal Spine Information Service (PSIS) and demographic information is held in the Personal Demographics Service (PDS). The Spine also supports other systems and services such as the e-Referral Service and the Electronic Prescription Service.

Integrating with NHS Systems