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. Summary Care Record (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

Incident management and incident reporting

1. It is expected that system suppliers that are compliant with the Booking and Referral Service have an incident management and reporting system or process in place.
2. It is expected that BaRS compliant systems have a form of monitoring and alerting system in place.
3. If after initial triage of an incident, an issue with the BaRS proxy or other up or downstream system is suspected it MUST be reported to the NHS England National Service Desk (NSD) as soon as possible.

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 rendering 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 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 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.