Skip to main content

Overview

An integrated healthcare system needs integrated IT systems. When patients are passed between care providers, their records should be passed too. 

This page explains the different types of integration that IT systems use to share information.


APIs

APIs (Application Programming Interfaces) allow IT systems to request and receive information immediately – in ‘real time’.

Here’s an example:

In the above diagram:

  • System A requests patient data (for a specific patient) from System B (the 'request')
  • System B finds the data for that patient and returns it to System A (the 'response')

We say that System B 'presents' or 'exposes' an API, and that System A 'calls' or 'makes a request to' that API.

The systems use an agreed, machine-readable format to communicate. For example, the request “send me the name and address of the patient with NHS number 9000000009” might look like this:

GET https://api.service.nhs.uk/name-and-address/9000000009

And the response might be:

{

   “name” : {

       “given” : [ “Jane”, “Angela” ],

       “family” : “Smith”,

       “title” : “Mrs”,

   },

   address: {

       "line" : [

           "1 Trevelyan Square",

           "Boar Lane",

           "City Centre",

           "Leeds",

           "West Yorkshire"

       ],

       "postalCode" : "LS1 6AE"

}

When drawing API diagrams, because the response is usually implicit, we sometimes draw the diagram with a single arrow, like this:

Central APIs for national services

Some of our APIs give access to national services such as the Personal Demographics Service or the Summary Care Record. For example:

We refer to these APIs as 'central APIs'. You can find them listed in our API catalogue, filtered to show central APIs.

Intermediary APIs

Sometimes, one local system needs to talk to another local system - for example to get a patient's records from their GP.

Often, local systems communicate via an intermediary, also known as a 'proxy'. The intermediary makes sure the communication goes to the right place.

For example:

Intermediaries are usually national systems that can route traffic to any local system in the country. For this to work, all the local systems must talk the same language, so the intermediary includes an API specification that all sending and receiving systems must follow.

A good example of an intermediary API service is GP Connect Access Document - FHIR API which retrieves unstructured documents from a patient’s GP practice record.

You can find intermediary APIs listed in our API catalogue, filtered to show intermediary APIs.


Message integration

Message integration, also known as asynchronous integration or ‘fire and forget’, is where one system sends a message to another system but does not expect an immediate response. For example: 

In some cases, the receiving system might send a message back later. For example: 

Usually, message integrations use a dedicated messaging system to send and receive messages. For example, many of our message integrations use MESH (Message Exchange for Social care and Health):

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

A good example of a message integration is the Transfer of Care Emergency Care Discharge - FHIR which sends discharge information from an emergency care provider to a GP practice:

You can find message integrations listed in our API catalogue, filtered to show message integrations.


Publish-subscribe events

Sometimes a system wants to broadcast the fact that something has happened to all interested parties, for example a patient's death.

We call this a publish-subscribe events model, and it works very much like Twitter:

  • receiving systems subscribe to event types, for example patient deaths
  • publishing systems publish events of that type to the event management API
  • the event management API forwards the event on to all interested parties

Our national service for managing events is NEMS (National Events Management Service). It uses another of our services to deliver events to interested parties - MESH (Message Exchange for Social care and Health), as follows:

Sending System
Sending System
NEMS
NEMS
publish
event
publish...
MESH
MESH
send event
to all
subscribing
systems

send event...
Subscribed
System B
Subscribed...
Subscribed
System A
Subscribed...
Subscribed
System C
Subscribed...
manage subscriptions
manage subscriptions
Text is not SVG - cannot display How to publish and subscribe to patient-centric healthcare event messages using NEMS and MESH APIs.

You can find publish-subscribe events in our API catalogue, filtered to show publish-subscribe events.


Peer-to-peer APIs

Sometimes, local systems talk directly to one another - there is no national intermediary.

If the relationship is one-to-one - a single system talking to another system, this is fairly simple.

However, if the relationship is many-to-many, local systems must manage routing locally, so they know which system to send messages to.

Also, just as with an intermediary, all local systems must talk the same language. To support this, NHS Digital publishes an 'API standard' that all sending and receiving systems must conform to.

A good example of an API standard is the Clinical Decision Support API standard which supports the triage and onward referral of patients interacting with NHS 111:


API standards

As mentioned above, if all systems talk the same language, it makes it easier for software developers to get them to talk to one another.

Over the years, various international and national bodies have published standards for APIs.

Some of them apply to:

Some of these API standards are defined by us at NHS Digital - generally to support peer-to-peer APIs. You can find them listed in our API catalogue, filtered to show API standards.

For more information on NHS standards, see the NHS Data Standards Directory.


API technologies

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, including:

  • REST
  • SOAP
  • FHIR
  • HL7 Version 3
  • and more

For more details, see API technologies at NHS Digital.


Our API platform

Many of our newer APIs are hosted on our API platform, which we have built as part of our mission to make integration easier.


Last edited: 21 November 2022 12:24 pm