NHS Booking and Referral Standard

Guide v1.6.0 | Core v1.1.3 | Package v1.31.0
  1. Home
  2. About BaRS
  3. BaRS Principles and Prerequisites

BaRS Principles and Prerequisites

This page describes BaRS principles and prerequisites for suppliers. Elements of these principles may be governed through the assurance process as conformant requirements. These will be reviewed and updated as part of a regular review cycle.

BaRS Principles
1 BaRS requires a service to be identified prior to initiating a BaRS interaction, BaRS is agnostic of the method used to identify the service
2 The receiving system supplier is responsible for the safe display of information to the end users of their system
3 Reusable workflows will be maintained
4 Non conformant payloads should be rejected in their entirety
5 Clinical information from external sources should be referenced in preference to duplicating, where clinically appropriate/unnecessarily (e.g. SCR)
6 Prior to a sender updating previously transmitted resources, the latest version of the primary resources must first be read from the original receiver and reconciled with locally held information
7 The receiver always specifies the payload, not the sender
8 When transporting information, clinical intent must be preserved between systems
9 Minimise technical burden by building reusable technology that is easy to adopt
10 Maintain core data structure to support multiple Applications
11 Only workflows identified by research are supported by the standard
12 Suppliers MUST support continuous development of the standard (see release management)
BaRS Prerequisites
1 Services will profile their services on the Service Directory so that each ServiceID is associated with a single workflow. (All products)
2 Systems MUST have a public facing internet connection
3 Systems MUST support JSON formats for all API interactions
4 Systems SHOULD have a FHIR Server or FHIR functionality in place
5 Systems SHOULD implement RESTful behaviour patterns
6 System Suppliers MUST complete the BaRS onboarding process
7 Systems MUST support Service Discovery

Principles for rendering BaRS payloads

BaRS does not specify how the BaRS Payload should be displayed in receiving systems. It is anticipated that where possible, the payload will be displayed in the system user interface (UI) as if it had been collected natively. However, it's recognised it may be necessary to display some or all of the payload in a textural data output e.g. PDF.

Some high level principles are provided as guidance to suppliers designing system UIs to ensure the payload is displayed in a way that can be understood by end users. Suppliers will be asked to self-declare that they have understood and implemented these principles in the Supplier Conformance Assessment List (SCAL).

Principle for redendering payloads
1 User Interface (UI) or report design should be informed by appropriate standards, including but not limited to:
  • Web Content Accessibility Guidelines(WCAG) 2
  • GOV.UK Design System
  • NHS Common User Interface (CUI) where still relevant
    • 2 UI design must be underpinned by a rigorous user-centred design process
  • User research should be performed to determine the most appropriate order: of information groupings to meet users needs e.g. clinical assessment information should follow established clinical narrative patterns
    • 3 Clinical governance processes to assure safe presentation of clinical information
  • Assessment of the presentation of clinical information to be undertaken as part of supplier DCB0129 activities
    • 4 All data must be clearly identified
  • All data must be labelled in an unambiguous way
  • Labels to be adjacent to the corresponding data item
  • Labels must be meaningful to the end user i.e. have business or clinical meaning rather than technical
  • There must be clear differentiation between similar data items (e.g. Home phone number, Works phone number)
    • 5 The most pertinent information must be displayed prominently
  • Use of bold, highlighting, boxed information
  • The most pertinent information displayed near the top top e.g. callback number, the chief concern, what the referral is for, when the referral action needs to be completed by.
    		•
    6 The most pertinent information must be displayed prominently Use of bold, highlighting, boxed information
  • The most pertinent information displayed near the top top e.g. callback number, the chief concern, what the referral is for, when the referral action needs to be completed by.
    • 7 Content to be presented consistently
  • Use of regular spacing
  • Consistent use of font and font sizes
    • 8 Relevant information to be grouped together
  • Contextually related elements should be grouped together e.g. patient demographics
    • Supplementary information required to interpret data must be grouped together e.g. Contact rank to be displayed with the relevant contact
    9 Display human readable identifiers
  • Avoid use of GUIDS
    • 10 Indicate where data has not been provided if it is appropriate
  • e.g. No medications stated
  • e.g. No known allergies

    • Principles for 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.

    Principles for integration systems Example
    1 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.
    3 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.
    4 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.
    5 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).
    6 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).
    7 Providers can easily join up their reporting data across the multiple systems involved. N/A
    8 End-to-end service must be maintained - any issues downstream of the BaRS connected system are managed by the BaRS compliant supplier. N/A
    9 End user systems that send or receive BaRS referrals by an integration system are not considered BaRS compliant. N/A
    10 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
    back to top