Skip to main content

Building healthcare software - referrals and bookings

A non-technical guide to building software that deals with referrals and bookings within the NHS in England.

This guide is a work in progress

This guide is a work in progress

To tell us what you think, please use the feedback widget or contact us.


Overview

This guide explains how to build software that deals with referrals and bookings within the NHS in England. 

It is a non-technical guide, aimed at people building healthcare software, including: 

  • product owners
  • architects
  • business analysts
  • delivery managers
  • software engineers

It covers the following topics: 

  • what referrals and bookings are
  • the end-to-end business process
  • national services, APIs and standards
  • the software delivery process
  • getting started

This guide is part of our series of domain-specific guides on building healthcare software

For more context, also see our introduction to healthcare technology


Referrals and bookings

make a referral
make a r...
Patient
Patient
Care Provider A
(sender)
Care Provider A...
Care Provider B
(receiver)
Care Provider B...
make a booking
make a b...
receive care
receive...
Viewer does not support full SVG 1.1 Referrals and bookings context diagram

 

The NHS in England is an ecosystem of care providers, each with a specific purpose or specialism. Care providers do not operate in isolation – they are intended to act as a single integrated care system, with patients being passed from one provider to another as appropriate. 

A referral is where one care provider (the sender or referrer) asks another care provider (the receiver or provider) to participate in the care of a patient, generally because their specialism is needed. 

For example: 

  • a GP referring a patient to a hospital or clinic for specialist treatment 
  • an optometrist referring a patient to a hospital eyecare clinic 
  • an NHS 111 operator referring a patient to an NHS 999 operator for an emergency 

A booking is where the sender makes an appointment for the patient to visit the receiver at a specific time, or within a defined timeframe. This is an optional step – it is possible to make a referral without a booking.

We provide a number of national services and standards to make referrals and bookings quicker and easier. This includes:

  • end user applications for healthcare workers and patients
  • API services and standards that allow senders' IT systems to talk directly to receivers' IT systems

There are different services and standards for different use cases.

Self-referrals

In some cases, the patient self-refers to a care provider, such as:

  • their GP
  • NHS 111
  • an emergency department
  • an urgent treatment centre

In such cases, the referral details - the problem to be solved - come from the patient themselves.

Transfer of care

By default, the sender retains overall responsibility for the patient's episode of care, and expects the receiver to report back and / or transfer the patient back to them after they have dealt with them.

For example, when a GP refers a patient to a hospital.

In some cases, the sender is asking the receiver to take over responsibility for the patient's episode of care. We call this type of referral a transfer of care.

For example, when a hospital is finished with a patient and transfers care back to their GP.

Discharge

When a care provider releases a patient from their care we call this a discharge.

Usually, a discharge is accompanied by a transfer of care, for example from a hospital back to the patient's GP.

Signposting

Sometimes, one care provider directs a patient to another care provider without actually formally referring them. It is then up to the patient to self-refer to the recommended provider.

We call this signposting.

For example, the 111 online service often advises a patient to contact their GP or to go to an emergency department.


End-to-end business process

1. Service discovery
1. Service discov...
2. Referral
2. Referral
3. Booking
(optional)
3. Booking...
4. Feedback
(optional)
4. Feedback...
Text is not SVG - cannot display End-to-end business process

 

Whatever the use case, whether it be a GP referral to a hospital or clinic, or an NHS 111 referral to an emergency department, the end-to-end process is generally a variant of the following process:

  1. Service discovery
  2. Referral
  3. Booking (optional)
  4. Feedback (optional)

The following sections summarise each of these process steps.

1. Service discovery

find an appropriate
care provider
find an...
Care Provider A
(sender)
Care Provider A...
Directory of
Services
Directory of...
Viewer does not support full SVG 1.1 Service discovery

 

The first step in making a referral is for the sender to identify an appropriate care provider to be the receiver. We call this service discovery.

This is generally done using an appropriate service discovery tool - sometimes known as a directory of services. The discovery tool is usually searchable, making it possible to find services that:

  • have a particular specialism
  • are within a specific geographical region, or within a certain distance of the referrer

2. Referral

make a
referral request
make a...
check capabilities
(optional)
check capabilities...
Care Provider A
(sender)
Care Provider A...
Care Provider B
(receiver)
Care Provider B...
Viewer does not support full SVG 1.1 Referral

 

Having identified a receiver, the sender makes a referral request to that receiver.

There are different types of referral, including:

  • advice and guidance - where the receiver gives advice to the sender without needing to speak directly to the patient
  • referral with triage - where the receiver assesses the case prior to (or instead of) booking an appointment
  • referral with immediate booking

In some cases, the referral results in a transfer of care from the sender to the receiver. In other cases, the sender 'sub-contracts' the receiver but retains overall responsibility for the case.

Before making the referral, optionally, the sender double-checks the receiver's capabilities to make sure they can provide the required service at the present time. 

Then, the sender makes the referral request, including all the information that the receiver is likely to need. The information sent with the request depends on the specific use case. 

Ideally, the receiver accepts the referral, but it might reject it for one reason or another.

In some cases the acceptance is implicit, for example when a patient self-refers to their GP, or a GP refers to a GP hub. In these cases, the whole journey tends to pivot more around the appointment booking - with the referral details being sent along with (or after) the booking.

3. Booking

Care Provider A
(sender)
Care Provider A...
Care Provider B
(receiver)
Care Provider B...
make a booking
(optional)
make a b...
Patient
Patient
Text is not SVG - cannot display Booking

 

Optionally, the sender makes a booking for the patient to visit the receiver.

Firstly, the sender checks what appointment slots are available.

Then, the sender works with the patient to choose a slot and book it.

In some cases, the patient might be able to make the booking themselves.

In some cases, the receiver's service is not directly bookable by the sender or the patient. Rather, the receiver determines the appropriate course of action and arranges the right type of care, whether that be a booking or advice back to the sender.

4. Feedback

Care Provider A
(sender)
Care Provider A...
Care Provider B
(receiver)
Care Provider B...
send feedback
(optional)
send fee...
Viewer does not support full SVG 1.1 Feedback

 

Optionally, after the patient has visited the receiver, the receiver provides feedback to the sender. 

The receiver sends the sender details of the outcome of the visit, so that the sender can continue the patient’s episode of care. 


National services, APIs and standards

For some use cases, we provide national services, APIs or standards to make referrals and bookings quicker and easier. This includes:

  • end user applications for healthcare workers and patients
  • API services and standards that allow senders' IT systems to talk directly to receivers' IT systems

An API service is where we provide a physical, callable API for the participating systems to use. An API standard is where we provide an API specification for participating systems to use when integrating directly with one another.

Our services and standards have evolved over time. This means there are different services and standards for different use cases. We are currently working on a single Booking and Referral Standard that will eventually be used for all use cases.


Guidance for specific use cases

For guidance on how to implement referrals and bookings for a specific use case, including which national services and standards to use, see guidance for specific use cases.


The software delivery process

How you deliver your software is up to you. But there are some important things you need to plan in when building software for the NHS in England, such as clinical safety, security and information governance. 

For more details, read our introduction to healthcare technology


Getting started

To get started with building your software and using our API services and standards, see getting started.

Last edited: 18 May 2022 12:02 pm