Skip to main content

Booking and Referral Standard implementation guide

A standard for healthcare IT systems that enables booking and referral information to be sent between NHS service providers.

Content in progress

Content in progress

This is draft documentation for a developing standard and the content is subject to change. If you are interested in developing a solution using this standard, contact us.  


This Booking and Referral Standard (BaRS) is an interoperability standard that enables booking and referral information to be shared efficiently and securely between healthcare IT systems and across care settings. 

We're building the necessary national infrastructure and components that underpins delivery of BaRS. Initially, it will be implemented in two care journeys:

  • between 999 and NHS 111 Clinical Assessment Services (CAS)
  • between NHS 111 and emergency departments (also known as accident and emergency or A&E)

We'll use the experience gained from these two initial implementations to improve BaRS ahead of making it available to other care settings over the next few years. 

Using this implementation guide

These pages provide guidance on how to implement BaRS and gain accreditation where required. They cover everything from use cases for booking and referrals through to authentication. 

You can use it to support your analysis and define the scope of your solution. 

As a developer, you need to use this documentation to understand:

  • workflow
  • error handling
  • non-functional requirements

It also includes resources for stakeholders such as project managers, business analysts, commissioners and NHS service providers who are involved at every stage of going live with a solution.

We recommend you use the quick start guide  which outlines the key resources and guidance available for developing to the Booking and Referral Standard (BaRS) at each stage of a typical project lifecycle. 

BaRS products

BaRS consists of BaRS Core that provides a core set of functionality and BaRS Applications that provide distinct functionality for each use case. Click on the links below to access the specific implementation guides. These guides should be used in conjunction with the BaRS documentation listed below.

Components of BaRS

BaRS is made up of documentation and infrastructure components that define a standardised way for bookings and/or referrals to be made between any NHS Service.  


BaRS documentation is as follows:



BaRS homepage 

An overview of the BaRS programme, the benefits of the standard and status of supplier development

Implementation guide (this site)

Provides everything implementers need to create a BaRS compliant solution 

API specification

The specification for integrating with BaRS central infrastructure 

BaRS payload definition library

Holds a set of documentation and FHIR artefacts defining nationally assured payloads for each use case



The BaRS API is the main infrastructure component of BaRS and is hosted and maintained on our centralised platform. It's comprised of several components but, from a developer perspective, it can be thought of as a proxy. All requests are routed through it, it brokers the endpoint for a given service (on behalf of a sender) and delivers the request to the receiver. It can support both national and regional scale service implementations, including any type of service discovery tool. This centralised infrastructure speeds up your development and rollout by handling the burden of establishing endpoints and connectivity; a sender always communicates with the BaRS API and a receiver only accepts request from it.

Components of BaRS centralised infrastructure are as follows:

Component Description


The API senders direct all requests to, for both booking and referral works, when implementing the standard. 

Endpoint catalogue 

A component which holds service identifiers and their corresponding physical addresses. It is capable of supporting national and local directory of services or even standalone endpoints configured within a single system. 

BaRS proxy 

The proxy makes the request to the receiver

The following components are in development:

Component Description


A store of pointers to bookings and referrals made through BaRS. Receivers will create and maintain the status of any pointers for the lifecycle of the events they refer to. It is a store of current active events and cannot be interrogated for historical ones. 


Closely tied with the registry, this will notify parties (directly related or interested 3rd parties) of events occurring on pointers in the registry.


Definition of key terms

The Booking and Referral Standard (BaRS) deals with 'bookings' and 'referrals' as they relate to a patient's journey. In the context of BaRS, we use these terms to mean the following: 


Booking is the administrative function of reserving time-based capacity at a service provider. It can take one of two forms:

  • the traditional appointment at a specified time 
  • a timeframe within which the patient can expect to be seen, based on their assessed clinical severity (acuity) and capacity at the service

Booking consists of the sender and receiver roles

  • the sender is the service assessing the patient and wishing to send them to another service
  • the receiver is the the service the sender wishes to send the booking to

When a booking is made in conjunction with a referral, the receiving service must link the booking and referral together. 


A referral is a request for a care service, other than a specific diagnostic investigation or diagnostic procedure, to be provided for a patient.

The information included in the referral is primarily clinical and must allow the receiver to understand the reason for referral and detail of assessment by the sending service. This is key for patient care and experience as the patient transitions between services. 

The complete information transmitted in the referral depends on the use case, as detailed in the BaRS Applications catalogue. This is informed by user research and endorsed by specialist bodies in those fields. 

Quick start guide

This section outlines the recommended key resources and guidance for developing to the Booking and Referral Standard (BaRS) at each stage of a typical project lifecycle. 

Discovery and planning

We recommend you read the following documentation as part of your discovery stage and to inform planning: 

Connect to our platform

Connecting to our platform is a self-service process.

You  will need to:

  • request an account
  • register your application with the BaRS API and note the available environments
  • provide a public key through the platform

You are then ready to perform full end to end tests with other supplier solutions. 

Further details of how to connect to our platform can be found in the security section.

Design and build

The following sections provide the information you need to design and build to BaRS. You will need to use both the BaRS Core and BaRS Applications pages for your use case.

End to end workflow

When developing against the standard, understanding the end-to-end workflow is key. It describes how a solution interacts with BaRS system architecture, along with the assumptions and expectations of all parties concerned. 

BaRS currently supports the following use cases and there are data and workflow variations in each: 

BaRS payload definition library 

The BaRS payload definition library contains examples of the message body requests and responses transmitted in the workflows to assist with understanding what messages look like.

BaRS FHIR API specification

The BaRS API specification provides detail of the structure of endpoints. The specification allows you to try out calls to endpoints to view anticipated responses. This is a purely technical document and must be read in conjunction with other documentation that make up the standard as a whole. 


All security is provided through our platform. There are two methods for securing interactions via BaRS API:

  • senders will generate an access token from the platform and then use this to interact with the BaRS API. Additionally, they will provide header values identifying the organisation, service and user, which are passed through the BarS API to receivers for them to apply access control to the request.
  • for receivers accepting requests, the BaRS API Proxy secures the connection with the receiver using TLS MA, using a NHS Root CA issued certificate, in addition to the header value elements mentioned. This provides the receiver with sufficient information to accept or reject the request without having to inspect the payload body. 

Error handling 

Error handling is an important part of the standard for two key reasons.

  • to ensure the booking and referring experience is as smooth and seamless as possible, the error responses returned must be clear enough to allow the appropriate next action to take place, for example, to include a missing element of information (highlighted in the error message) and retry
  • there are several levels of interactions occurring from the sender, through BaRS API to the receiver and clearly identifying where the fault lies is central to resolution. All implementations must adhere to the error handling guidance within the standard

BaRS FHIR usage 

BaRS uses (FHIR) to achieve interoperability between multiple healthcare IT systems. This section describes how BaRS uses FHIR concepts which is essential information for developers implementing the standard. 

Environments and testing


There are two path-to-live environments to develop and test against prior to deploying to production. Full details are available in the BaRS API specification.

Toolkit Workbench (TKW)

A TKW tool will be available through the BaRS API (sandbox and integration environments) to assist you with development. The tool replicates scenarios for the various use cases and provide detailed validation reports allowing you to identify issues during development and also provide evidence for assurance.


Assurance for BaRS is achieved by completing and providing evidence through a SCAL document.

Supplier Conformance Assessment List (SCAL) Process

You need to:

  • complete a SCAL document and state the required capabilities are supported
  • provide evidence and supporting diagrams which will enable the Solution Assurance Team to understand the solution and ensure it meets the required standard
  • demonstrate an end-to-end test of solution functionality within the integration environment (INT), following given test scripts 

Contact us to request a copy of the latest SCAL.


Deployment documentation including go-live checklists and test plans are in development and will be available on this site. Contact us if you need further information or support in this area.

Last edited: 11 January 2022 12:31 pm