NHS Booking and Referral Standard

Guide v1.5.0 | Core v1.2.1 | Package v1.30.0

About BaRS

The NHS Booking and Referral standard (known as BaRS) is a framework standard for interoperability.

  • BaRS offers a universal standard way to digitise workflows that support all cross service patient journeys in the NHS
  • It is based on FHIR R4 and fully supports UK Core
  • It is a set of instructions, rules and guidance on how to use the building blocks of FHIR to digitise workflows
  • This provides a framework for vendors to build solutions in a way that guarantees compatibility

The majority of cross service flows in the NHS can be loosely defined as referrals however, there are many more formal definitions of referrals and BaRS is intended to support all of them and more. The primary goal is to create a framework that vendors can operate within to share information about a patient, with some sort of directive or request for further care or tasks. This can optionally be supported by an appointment (e.g. the reservation of resource for an event at a specific time/place).

Summary of the key features

In order to achieve this, BaRS has adopted the approach of standardising everything that can and should be standardised whilst creating a safe space for solutions to have the necessary flexibility to support all flows whilst maintaining compatibility.

There are three main "layers" that make up the framework within BaRS.

The first is the transport layer (referred to as BaRS Core). This is all the things that define the way two systems "talk" to each other and this layer is absolutely standardised. All systems will implement these things exactly the same way.

Second there is the "workflow" layer. This allows a specific BaRS compliant solution to support a particular patient journey. The way a workflow is articulated is standardised and each particular workflow is made up of a combination of underlying standard operations (defined in the "transport layer") in a particular sequence.

Third there is the Payload layer. The "payloads" are collections of FHIR resources that make up the set of information that is required for the receiving system to complete or deliver the intended service or task that is being requested.

The workflow and payload elements can be predefined or completely dynamic, enabled by the inbuilt content negotiation mechanism, as required by the needs of each specific use case and the sophistication of the systems implementing compliant solutions.

The documentation for BaRS is separated into three groups (or "products"):

  • Core is the foundation containing all the things everyone has to do regardless of what flows BaRS is being used to support

  • Applications, apply the standard to a specific problem and build on this to support specific use cases

  • BaRS Pre-Releases, this is the same as above but for applications that are in a pre-release state, so not generally available until private/public beta is complete.


Foundation Principles

During the design and development of the standard, all key decisions are being tested against a set of foundation principles. These were set out at the beginning as a way to ensure that the vision for BaRS is delivered and all decisions are guided by this vision.

Low Barrier to Entry

There is little point for a standard with the ambition and scope of BaRS being so difficult to implement that no one actually does. Therefore all decisions are made with the intention of making it as easy as possible for all vendors to build solutions quickly and easily.

Any-to-Any Connectivity

From the beginning it has been very important to ensure that all solutions are easily scalable and it is possible to interoperate with another system without any prior knowledge or pre-configuration inplace. So that all interactions are:

  • live and "on-the-fly"
  • all information is available in realtime from the source
  • there is no prior knowledge required for transmission
  • there is no requirement for anything to use "point-to-point" interactions (although this approach is supported when approriate)

Universality

The primary vision for BaRS has always been to create one standard way of supporting movement of patients and their information accross services. Therefore all decisions have this idea at their heart. Research has allowed us to model the primary, high level steps as a sequence of discrete uncoupled processes that are the same every time these flows happen.

Additionally, in order to support all possible variations of these flows, the receiver must dictate the "payload".

Rather than the traditional approach of the sender sending everything they know, for the reciever to have to filter out everything they do not need to know, the reciever gets to state what they need to know to do the thing that is being requested of them. No more, no less.

Finally, all decisions are tested against as many obscure and exotic "what-if" scenarios as possible. The intention is to avoid building a standard that only works in one care setting but not another.

If you have come to this implementation guide directly it might be helpful to read some information about the program that is responsible for developing and maininting this standard, please see here: Booking and Referral Standard (BaRS)

Combining the elements together

It is common to use a recipe analogy to describe complex concepts. It is also possible to describe the payload entities within the BaRS standard using this analogy. In this analogy the recipe is for a specific cake which corresponds to a BaRS Application conformant solution developed by suppliers to enable the digitisation of a use case specific workflow.

Profiles

Profiles are the base ingredients for the BaRS and come from two sources.

  • UK Core specifies a set of constraints and/or extensions to specific base FHIR resources to enable consistent information flows across UK borders, to improve health and care outcomes for all citizens

  • BaRS specifies additional constraints and/or extensions to UK core profiles, that are common for all BaRS Applications

Cardinalities

All attributes defined in FHIR have cardinality as part of their definition - a minimum number of required appearances and a maximum number. These numbers specify the number of times the attribute may appear in any instance of the resource type. This equates to the Quantity in the recipe analogy. Failure to conform to the cardinality of a FHIR attribute will lead to a FHIR validation failure in the same was as altering the quantities of key ingredients will result in a failed cake. See https://hl7.org/fhir/conformance-rules.html for more details about cardinality in FHIR.

Necessity

Necessity is an additional layer of conformance and specifies if the population of an element by the SENDER is required for successful execution of the business process that the BaRS Application is enabling. This relates to optionality of ingredients in a recipe. If you want your cake to be a lemon cake, then you MUST add lemons! See Definition of conformance key words for more information.

Implementation guidance

Implementation guidance is provided at several levels in the BaRS, for example, at the FHIR element, resource and bundle levels. It describes how these attributes should be populated to support the business process that the BaRS Application. It corresponds to the Method in the recipe analogy, which also can be at the ingredient level or the recipe level.

Core Payload definition

BaRS will have Core Payload Definitions that will relate to all BaRS Applications that are build on that definition, e.g. Urgent Referral. These correspond to a Basic Recipe in the recipe analogy. A good example would be a vanilla sponge. This recipe can be added to to make a variety of cakes for different occasions (or use cases). For BaRS v1.0.0 core payload definitions are not documented as they require more BaRS use cases to be defined so that the common elements can be identified.

Application

A BaRS Application consists of implementation guidance that describes how a supplier builds a BaRS conformant solution for a specific workflow using the BaRS toolbox. This corresponds to the Full recipe for a specific cake, potentially for a specific occasion.

BaRS FHIR API end-to-end process


Elements of the standard

BaRS is made up of a set of documentation and optional infrastructure components

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 optional BaRS central infrastructure

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.

There are two elements to this infrastructure:

  • a routing proxy that enables systems to connect to each other in a scalable way that does not require each side to have pre-configured direct connections
  • a set of enabling discovery services that allow BaRS clients to "discover" events, tasks and requests that have been made using BaRS compliant systems from a number of contexts

The routing proxy is the main infrastructure component of BaRS and is hosted and maintained on the centralised NHS API Management platform. It is 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 proxy and a receiver only needs to accept requests from it.

Components of BaRS centralised infrastructure are as follows:

Component Description
BaRS Proxy API Senders direct all requests to this Proxy API for all requests.
Endpoint catalogue A component that 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 manag 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.

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. This is informed by user research and endorsed by specialist bodies in those fields.

Quick Start Guide

Follow this Quick Start Guide to best understand how to approach BaRS:

Discover

We recommend reading the following documentation as part of the discovery stage to inform planning:

Onboarding

Onboarding with our platform is a self-service process. This step is required to make requests of the BaRS API and have requests forwarded to your endpoint, as a Receiver. This must occur on both Integration (INT) and Production environments. The full step-by-guide can be followed by any solution on either environment.

Full details of the security model adopted by the platform can be found under the security section.

Design

The following sections provide the essential information needed to design and build a BaRS compliant solution. BaRS is devised in a way to support re-use of functionality across multiple uses cases, to this end the implementation guidance is split into BaRS Core and BaRS Application sections. All solutions must build the Core and add the specific requirements of the Application to support the given use case. BaRS Core is not sufficient on its own, an Application will always be required.

End-to-end workflow

When developing against the standard, understanding the end-to-end workflow is key. This section of the guide describes how a solution interacts with the BaRS API, along with the assumptions and expectations of Senders and Receivers. These are the roles suppliers will adopt when building a solution. This guide is written predominantly from the perspective of the request; the Sender and Receiver of the request. However, if the BaRS Application include a response workflow these roles swap, the Sender becoming the Receiver and vice versa.

BaRS includes several BaRS Application (use cases), each of which supports multiple use cases that share a common workflow and data model.

API Spec

The BaRS API specification provides detail of the structure of endpoints. The specification allows you to 'Try this API', calling endpoints to view anticipated responses. This is a purely technical document and must be read in conjunction with implementation guidance to build a compliant solution.

Security

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 use this to authenticate with the BaRS API. Additionally, requests will include HTTP header values identifying the organisation, software and user, which are passed through the BarS API to Receivers who apply their own access control to the request based on the headers content.
  • for Receivers accepting requests, the BaRS API secures the connection with the Receiver using TLS MA, using an NHS Root CA issued certificate. The HTTP header values (as described above) are also passed through. 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 workflow is as smooth and seamless as possible, the error responses returned must be clear to allow the appropriate next action to take place, for example, to include a missing element of information (highlighted by the error response).
  • there are several levels of interactions occurring from the Sender, through BaRS API to the Receiver and clearly identifying where the fault lies is important for swift resolution. All implementations must adhere to the error handling guidance which is part of the assurance process.

Build

Environments

The principle environment for development and testing is the INT (integration) environment. This is a like-live environment, harnessing full security and functionality that can expect to be encountered in Production. In addition, the BaRS API specification links to the Sandbox environment, which is capable of demonstrating the key functionality but without the security overhead.

Toolkit Workbench (TKW)

TKW - Toolkit Workbench - is a tool to assist development and assurance of supplier solutions to become BaRS compliant.

The tool supports testing of key high-level workflows e.g. a booking routine, including the asynchronous flows, as well as being capable of inspecting low level technical requirements. It reports the output in Validation Reports which clearly indicate to the reader where and why a test has failed. In addition, the tool supports consistent error states which are often difficult to create but required for development and assurance. TKW is deployed to the INT enviornment and, therefore, requests/responses will occur under Production like conditions.

Assure

Assurance for BaRS is achieved by completing and providing evidence, via a Supplier Conformance Assessment List (SCAL), through the Digital Onboarding Portal.

Supplier Conformance Assessment List (SCAL)

To complete assurance you need to:
  • complete all SCAL sections through the Digital Onboarding Portal
  • 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)
  • Provide evidence of compliance with DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems
  • State that you have reviewed the BaRS Clinical Safety Case Report and Hazard Log, have integrated transferred risks into your own Hazard Log and have implemented appropriate mitigation as stipulated

Deploy

Once a solution is developed (and assured, if deploying to Production) it can be deployed. This stage involves installing, configuring and thoroughly testing the solution to ensure it behaves as intended and users are conversant with all aspects of functionality. It is likely to involve numerous parties across multiple organisations and require meticulous planning. The guidance provided is a suggested check-list of steps to consider and is not exhaustive.

back to top