BaRS Core 1.0.5

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

You will find here 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.

> Expand for full Core directory

• Core 1.0.5
  • End to end workflow
    • Service Discovery
    • Authenticate with BaRS
    • BaRS FHIR API
    • HTTP Header
    • Routing
    • Authentication and Authorisation
    • Transactional Integrity
    • HTTP Response Headers
    • Processing Requests
    • Responses
    • Reversing Roles
    • Asynchronous Workflow
  • Core Functionality Requirements.
    • All
    • Caching
    • Booking Sender
    • Booking Receiver
    • Referral Sender
    • Referral Receiver
  • BaRS FHIR Usage
    • Frameworks
    • REST
    • FHIR Operations
    • $process-message
    • Bundle
    • Journey ID
    • How to handle times
    • LastUpdatedDate
  • Security and Authorisation
    • Sender
    • OAuth Endpoints
    • Receiver
    • Authorisation
  • Error Handling
    • Overview
    • BaRS interactions(sending)
    • OperationOutcome Example
    • Diagnostic Text
    • Example Errors
    • Sender Responsibilities
    • BaRs interactions(receiving)
    • Receiver responsibilities
    • Failure Scenarios
  • Transactional Integrity
    • Initial Request
    • Sending an update
    • Feedback (response) requests
    • Retry Scenario
    • Onwards Referrals
    • Definition of a Retry
    • Receiver responsibilities
    • Sender responsibilities
    • Failure Scenarios
  • Non functional Requirements
    • Requirements
    • Processing Times
  • Standard Pattern - Composite Messages
    • Standard Pattern for Composites
    • Message Headers
    • Cancellation
    • Use Case Categories

End to end workflow

This section covers the core elements of workflow outlined within the Booking and Referral Standard. There are two caveats when reading this:

Workflow is dependent on its Application or use case, for example in 999 - CAS validation, there is no step to perform a booking. See the relevant use case page in the BaRS Applications section.
The order of workflow is interchangeable. It is possible to:
- make a referral before a booking
- refer without booking
- book without referring

For more detail please visit the End to End Workflow section.

Core Functionality Requirements

BaRS should provide different functionality depending on:

its Application or use case
whether it acts as a sender or receiver

This list of functionality will expand in later versions of BaRS.

There are requirements in each of the central areas of functionality which every BaRS Application must adopt:

For more detail please visit the Core Functionality Requirements section.

Content Negotiation

Content Negotiation within BaRS leverages multiple variables within the CapabilityStatement and MessageDefinition to ensure that a Sender and a Receiver are Compatible. Though some of this is possible due to the Versioning Negotiation, Content Negotiation further builds on that concept with the capabilities published by the server and the identification of message definitions and use cases therein to ensure a workflow can be completed.

For more detail please visit the Content Negotiation section.

BaRS FHIR usage

BaRS uses FHIR to achieve interoperability between healthcare IT systems. This section explains how BaRS makes use of some key FHIR concepts which need to be understood by developers implementing the standard.

For more detail please visit the BaRS FHIR usage section.

Security and Authorisation

For more detail on Security and Authorisation, please visit the Security and Authorisation section.

Error Handling

There are multiple points where an error may occur to prevent booking and referral operations from completing successfully. This section provides error handling guidance for BaRS and its associated API. For More Detail on error handling, there is specific information on failure scenarios available in the section in addition to information included on this page.

For more detail please visit the Error Handling section.

Transactional Integrity

Transactional integrity is employed to ensure data integrity is maintained between two parties. It helps ensure that the success or failure of a message is known and can be confirmed.

For more detail please visit the Transactional Integrity section.

Non Functional Requirements

The non functional requirements apply to all APIs designed to receive requests from BaRS. This includes sender systems receiving asynchronous responses and feedback, as well as receiving systems. All items detailed will be adhered to.

For more detail please visit the Non Functional Requirements section.

Standard Pattern - Composite Messages

Most implementations of the BaRS that are applying the standard to support a particular use case or operational workflow will follow the same basic set of foundational operations with little deviation.

In order to establish a guarantee of compatibility between different solutions compliant with the standard, all implementations must support all the underlying foundational operations and patterns.

For more detail please visit the Standard Pattern - Composite Messages section.

NHS Booking and Referral Standard