About BaRS

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. It replaces the NHS Booking Standard which has been successfully deployed in many hospital trusts and healthcare IT systems and will provide enhanced capability using FHIR.

We're developing the necessary national infrastructure and components that underpin delivery of BaRS. Initially, it will be implemented within three care journeys:

between NHS 111/clinical assessment services (CAS) and emergency departments (or A&E)
between 999 and CAS for referral
between 999 and CAS for ambulance validation

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.

BaRS Core and BaRS Applications

BaRS consists of BaRS Core that provides a core set of functionality and BaRS Applications that provide distinct functionality for each use case.

BaRS Core is a set of documentation, specifications and services that describe and support all the fundamental components of the standard that are always the same for all use cases or care journeys. Examples include the underlying capabilities and patterns and transport layer elements such as security, authorisation and access control.

BaRS Applications are an application of the standard into a particular workflow or care journey. The application describes how particular operations and business flows map to the underlying technical capabilities and patterns of BaRS Core along with the specific payloads.

Using this guide

These pages provide guidance on how to implement BaRS and gain accreditation. The BaRS Core guide provides implementation guidance for the fundamental components of BaRS. This must be used in conjunction with the BaRS Application guide specific to your use case or care journey for example 111-ED

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

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

It also includes resources for product owners and business analysts and those involved at every stage of going live with a solution.

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.

Documentation

BaRS documentation is as follows:

Item	Description
BaRS homepage	An overview of the BaRS programme, the benefits of the standard and status of supplier development
Implementation guide (this site)	You will need to use both the BaRS Core page and the BaRS Applications page specific to your use case.
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

Infrastructure

The infrastructure components defined as parts of BaRS are offered for use as a set of centralised services that can support workflows and simplify integration between systems.

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 need only communicate with the BaRS API and a receiver only needs to accept request from it.

Components of BaRS centralised infrastructure are as follows:

Component	Description
BaRS API	Senders direct all requests to this API for both booking and referral requests.
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. Providers will be able to manage their endpoints via an API.
BaRS proxy	The proxy makes the request to the receiver

The following components are in development:

Component	Description
Registry	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. Access to the registry will be controlled by authentication at the API layer and authorisation to access the data will be delegated to the data owner.
Events	Closely tied with the registry, this will notify parties (directly related or interested 3rd parties) of events occurring on pointers in the registry.

Component

Description

Registry

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. Access to the registry will be controlled by authentication at the API layer and authorisation to access the data will be delegated to the data owner.

Events

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

Definitions 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

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 service the sender wishes to make the booking with

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

Referral

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.

Principles for Integration systems

A note about integration systems

We recognise that some solutions may be delivered using integration systems. To ensure the operational value of deploying a BaRS compliant solution and the spirit of the standard HIMSS interoperability level 4 is adhered to, we have developed a set of principles that integration systems should abide by.

In the principles the following terms are referenced:

End User - This is the person performing the necessary actions to initiate, accept or manage a referral or booking.

End user system - this is the healthcare IT system that is being used by the end user to initiate, accept or manage a referral or booking.

Integration system - is any intermediary system that is not part of the end user system that has been built to expose a BaRS compliant API to receive and/or transmit bookings and referrals with a bespoke or proprietary integration with the end user system.

Principle	Example
The end users are unaware that there is an integration system being used (No screen scraping, No double keying/swivel chair).	The information transmitted to an end user's system via an integration system is available natively in that system with sufficient resolution and integrity to be able to complete their tasks.
The information transferred through BaRS MUST be able to be used to drive workflow for the end user.	A worklist on the end user system can be ordered according to priority information received by their system.
Information must not be modified or lost between the sender and the end user system, in particular clinical meaning and intent must not be lost or modified in any way between the sender and the end user.	A key piece of diagnostic information (such as a clinical modifier) is not lost through truncation of a particular field.
The end user system should be able to consume BaRS referral information in a way that will support the onward transfer of care.	If an end user system needs to make an onward referral, the BaRS journey ID (episodeofcare.id) is available to include in that referral (as it has not been lost through "flattening" of the structure FHIR message).
Business acknowledgements work as per the design.	When an integration system accepts a referral, this completes the process for the sender and is not reliant on further interop to a downstream system (therefore our synchronous activity is not obstructed with caching in the integration system).
Providers can easily join up their reporting data across the multiple systems involved.	N/A
End-to-end service must be maintained - any issues downstream of the BaRS connected system are managed by the BaRS compliant supplier.	N/A
End user systems that send or receive BaRS referrals by an integration system are not considered BaRS compliant.	N/A
All information accessed by the end user must be delivered in real-time and be kept up to date (including not overwriting locally updated information).	N/A

NHS Booking and Referral Standard