This version of core is strictly a preview of what is currently in development for 1.2.0-alpha and should not be built against.
| Core Version | Minimum Guide Version | Minimum API Spec Version |
|---|---|---|
| v1.2.0-alpha | v1.8.0 | v1.2.0 |
BaRS Core 1.2.1-alpha
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.2.1 • 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 • Standard Pattern - Appointments • Booking • Updates • Cancellations • Rebook • Standard Pattern - DocumentReference • Sender • Receiver • Interface •
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.
Standard Pattern - Appointment
There are 4 capabilities that are required surrounding appointments. This section will provide information on how to meet them.
- The ability to book an appointment.
- The ability to cancel an appointment.
- The ability to update an appointment.
- The ability to rebook an appointment.
For more detail please visit the Appointment Standard Pattern section.
Standard Pattern - DocumentReference
In version 1.1.0 of the BaRS API Specification, functionality was added to accommodate the use of pointers (DocumentReference resources), to locate existing bookings and referrals.
The FHIR DocumentReference resource allows you to reference and locate clinical documents or resources. This section will walk you through the process of using a FHIR DocumentReference to find a resource's location and retrieve it.
For more detail please visit the DocumentReference Standard Pattern section.
Standard Pattern - Endpoints
This version of core is strictly a preview of what is currently in development for 1.2.0 and should not be built against.
BaRS employs an endpoint catalogue to match Target Identifiers with a stored endpoint. Target Identifiers are provided in a header which is descripted in the API Spec The following pages will describe how these entries can be managed, outside of the onboarding process.
The BaRS endpoints will utilise not only service ids and a physical endpoint, but data describing the healthcare service, the provider of that service and the organization which manages and/or supplies the endpoint in question.
BaRS will expose an interface to manage this information in the format of FHIR resources. Each resource will have a corresponding endpoint on the Proxy to assist in managing these endpoints.
For more detail please visit the Endpoint Standard Pattern section.