Skip to main content

Current Chapter

Current chapter – Integration and APIs


Overview

To support an integrated healthcare system, we need integrated IT systems. When patients are transferred between care providers, their details should be made available between IT systems too, to ensure continuity of care.

IT systems talk to one another through 'Application Programming Interfaces' (APIs).

There is nothing magical about APIs - they are simply a way for IT systems to exchange information. 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 be formatted as:

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

The response might be formatted as:


{

   “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:




There are different types of API for different uses.


Synchronous APIs

Synchronous APIs are used when the calling system needs an immediate response. For example:



Messaging or asynchronous APIs

Messaging APIs, sometimes called asynchronous or ‘fire and forget’ APIs, are used when the sending system does not need an immediate response. For example:




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



API services

We refer to 'API services' where we have a callable API in place for healthcare systems to talk to. 

These are one of two types:

  • central APIs that provide access to centralised, national services, such as the Personal Demographics Service or the Summary Care Record
  • intermediary APIs that help broker the communications between two healthcare organisations, typically senders and receivers of information, for example, GP systems providers and GP Connect API consumers

We separate API services from 'API standards' which do not provide an API but instead define a 'paper' specification for how applications can talk to each other directly. 


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 API services'. You can find them listed in our API catalogue, filtered to show central API services.


Intermediary APIs - proxies and message brokers

Sometimes, one local system needs to talk to another local system - for example to transfer GP records from one practice to another.

Often, local systems communicate via an intermediary. The intermediary makes sure the communication goes to the right place.

If the communication is synchronous, the intermediary is a ‘proxy’. For example:




If the communication is asynchronous, the intermediary is a ‘message broker’.

Some message brokers forward the message on to the recipient, like a postal service:




Other message brokers require the recipient to check for messages, like a post office box:




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 conform to.

A good example of an intermediary API service is the GP2GP HL7 V3 API which transfers patient records between GP practices when a patient changes their GP:



 

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


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:



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:



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.


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: 26 January 2022 4:48 pm