Skip to main content

API technologies at NHS Digital

Learn about the different types of API we have at NHS Digital.

NHS Digital has been developing APIs for quite some time. We always aim to adopt the latest standards for new APIs. But it’s costly to rebuild APIs when technology changes. As a result, our APIs use a variety of technologies, some more modern than others.

Basic REST

Some of our APIs are basic RESTful APIs.

RESTful APIs:

  • are synchronous - they give an immediate response
  • are accessed using HTTP - the same way a web browser accesses web pages
  • give access to data as 'resources' - like web pages, for example https://api.service.nhs.uk/personal-demographics/Patient/9000000009 accesses the demographic data for the patient whose NHS Number is 9000000009
  • use HTTP verbs such as GET and POST to get and update those resources
  • use HTTP status codes for errors, for example HTTP status 404 means 'resource not found'
  • in some cases, use HAL links to link to other resources
  • in most cases, use the JSON format for requests and responses (although some use XML)

FHIR

Where appropriate, our RESTful APIs follow the HL7 FHIR standard (pronounced 'fire').

FHIR (Fast Healthcare Interoperability Resources) is a global standard for health care data exchange. It is the successor to the HL7 V3 standard.

FHIR:

  • includes specific resources for the health care domain, such as Patient and Observation, and also defines common data items for those resources
  • can be adapted for local requirements using profiles, extensions, terminologies and more
  • defines rules for how to access resources via RESTful APIs

FHIR has been adapted for use in England as follows:

  • CareConnect is a set of England-centric FHIR profiles built on FHIR Release 3
  • FHIR UK Core (currently in prototype) is a set of UK-centric FHIR profiles built on FHIR Release 4

You don’t need to know much about FHIR to use our APIs - FHIR APIs are just RESTful APIs that follow specific rules. In particular:

  • resource names are capitalised and singular, for example /Patient not /patients
  • array names are singular, for example line not lines for address lines
  • data items that are country-specific and thus not included in the FHIR global base resources are usually wrapped in an extension object

Basic SOAP

Some of our APIs are basic SOAP (Simple Object Access Protocol) APIs.

This includes, for example, the Spine Mini Services Provider PDS API.

HL7 V3

Some of our older APIs conform to the HL7 Version 3 standard.

HL7 V3 is a global standard for health care data exchange. It is the predecessor to the FHIR standard.

It includes:

  • synchronous APIs, using SOAP and XML
  • asynchronous APIs, using ebXML

Be aware that using our HL7 V3 APIs can be hard work because:

  • the documentation is quite hard to navigate
  • the message structure is complex
  • for asynchronous APIs you need to build a Message Handling System to receive inbound messages

If there is a suitable RESTful API available, we recommend you use that instead.

Learn how to integrate with our HL7 V3 APIs by reading:

Message Handling Service Adaptor

To remove the complexity of building your own Message Handling System, NHS Digital offers a pre-assured, client side Message Handling Service Adaptor that you can integrate into your own infrastructure.  

Spine Security Proxy (SSP)

Some of our synchronous APIs are available via the Spine Security Proxy (SSP). We use SSP where the responding system is another local system. Requests and responses go via SSP instead because this makes it easier for responding systems - they only have to deal with requests from a single place.

To make sure all systems can talk to one another, we (NHS Digital) write the API specifications for SSP APIs, even though we don’t own the responding systems.

SSP APIs are generally FHIR APIs, the only difference being that SSP sits in the middle, routing traffic and making security easier.

MESH

Some of our asynchronous APIs use MESH (Message Exchange for Social care and Health). MESH is an NHS Digital messaging hub that allows systems to send and receive asynchronous messages. MESH replaced an older system called DTS.

With MESH, sending systems send messages to a messaging hub and the messages are placed on the recipient’s “queue”. Receiving systems must constantly check the messaging hub for incoming messages on their queue. This is known as a “push” or “polling” mechanism.

MESH is built as a RESTful API with endpoints for sending messages and for polling for received messages.

The message payload format depends on the specific API. For example, pathology messages use HL7 v2 EDIFACT, whereas transfer of care messages use FHIR.

LDAP

The Spine Directory Service API uses Lightweight Directory Access Protocol (LDAP).

LDAP is a simple way to access information held in a hierarchical directory structure over an Internet Protocol (IP) network such as HSCN or the internet. It is an open standard with multiple versions. See individual API documentation for details of which version is used.

Last edited: 6 July 2020 8:19 am