Building healthcare software - referrals and bookings

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. 

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.

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.

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.

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.

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.

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.

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

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.

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.

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. 

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
• APIs and API standards that allow senders' IT systems to talk directly to receivers' IT systems

An API 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.

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.

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. 

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