You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md
+3-62Lines changed: 3 additions & 62 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,67 +1,8 @@
1
1
# {{page-title}}
2
2
3
-
The NHS Booking and Referral standard (known as BaRS) is a **framework standard** for interoperability.
4
-
5
-
- BaRS offers a **universal** standard way to **digitise workflows** that support all cross service patient journeys in the NHS
6
-
- It is based on [FHIR R4](https://hl7.org/fhir/R4/) and fully supports [UK Core](https://simplifier.net/hl7fhirukcorer4)
7
-
- It is a set of instructions, rules and guidance on how to use the building blocks of FHIR to **digitise workflows**
8
-
- This provides a **framework** for suppliers to build solutions in a way that **guarantees compatibility**
9
-
10
-
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 suppliers 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).
11
-
12
-
13
-
## Summary of the key features
14
-
15
-
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.
16
-
17
-
There are three main "layers" that make up the framework within BaRS:
18
-
19
-
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.
20
-
21
-
**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.
22
-
23
-
**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.
24
-
25
-
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.
26
-
27
-
The documentation for BaRS is separated into three groups (or "products"):
28
-
29
-
- {{pagelink:design-core-1.0.7}} is the foundation containing all the things *everyone* has to do regardless of what flows BaRS is being used to support
30
-
31
-
- {{pagelink:Applications}}, *apply* the standard to a specific problem and build on this to support specific use cases
32
-
33
-
- {{pagelink:prereleases}}, 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.
34
-
35
-
<br>
36
-
37
-
## Foundation Principles
38
-
39
-
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.
40
-
41
-
**Low Barrier to Entry**
42
-
43
-
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** suppliers to build solutions quickly and easily.
44
-
45
-
**Any-to-Any Connectivity**
46
-
47
-
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:
48
-
49
-
- live and "on-the-fly"
50
-
- all information is available in realtime from the source
51
-
- there is no prior knowledge required for transmission
52
-
- there is no requirement for anything to use "point-to-point" interactions (although this approach is supported when approriate)
53
-
54
-
**Universality**
55
-
56
-
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.
57
-
58
-
Additionally, in order to support all possible variations of these flows, the receiver *must* dictate the "payload".
59
-
60
-
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.
61
-
62
-
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.
63
-
64
-
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)](https://digital.nhs.uk/services/booking-and-referral-standard"Booking and Referral Standard (BaRS)")
3
+
The NHS Booking and Referral standard (BaRS) Implementation Guide is intended as a resource to support product and development teams in their BaRS development journey. You can find out more about what BaRS is, how it works, who it's for and which system suppliers are already assured or working on their development on the [BaRS NHS Service Catalogue](https://digital.nhs.uk/services/booking-and-referral-standard) pages.
4
+
5
+
This section provides information to help you use the Implementation Guide.
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Index.page.md
| {{pagelink:application4, text: Referral into UEC for Validation (Application 4)}} | <p>999-CAS Validation<br> <p>999 AST to Falls Lifting Service<br> <p>999 AST to Community Services <br> |2.0.0| <ahref="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7"target="_blank">v1.0.0</a> | <ahref="https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Design/BaRS-Core?version=1.0.0"target="_blank">v1.0.0</a> |
26
26
| {{pagelink:application5, text: Referrals into Pharmacy (Application 5)}} | <p>Primary Care to Community Pharmacy (Pharmacy First)<br> <p>Primary Care to Pharmacy Contraception (Oral Contraception) <br> <p>Primary Care to Pharmacy Blood Pressure Check Service<br> | 1.1.3 | <ahref="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0"target="_blank">v1.3.0</a> | {{pagelink:design-core-1.3.1, text:v1.3.0}} |
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Pre-releases/Index.page.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,15 @@ topic: prereleases
6
6
7
7
This section contains implementation guides for applications that are currently in a pre-release state.
8
8
9
-
They are offered as a preview of a developing guide for information only. They are not intended to be used until the completed v1.0.0 version of a guide is released<p> If you are interested in developing a BaRS compliant solution right now for a use case covered by one of these guides, please use the contact form <ahref="https://digital.nhs.uk/services/booking-and-referral-standard/enquiry-form"target="_blank">here</a> and the team will be in touch
9
+
They are offered as a preview of a developing guide for information only. They are not intended to be used until the completed v1.0.0 version of a guide is released.<p> If you are interested in developing a BaRS compliant solution right now for a use case covered by one of these guides, please use the contact form <ahref="https://digital.nhs.uk/services/booking-and-referral-standard/enquiry-form"target="_blank">here</a> and the team will be in touch.
10
10
11
11
These guides are designed to be used in conjunction with the documentation for {{pagelink:design-core}}.
12
12
13
13
14
14
15
15
| Application | Use Cases | Current Release | API Specification | Core Version |
| {{pagelink:application6, text: Referrals into an Ambulance Service Trust (Application 6)}} | <p>CAD to CAD Out of Area Referral<br>CAD to CAD Call Assist Request<br>CAD to CAD Mutual Aid Request | 1.0.0-beta.5| <ahref="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0"target="_blank">API Spec v1.3.0 and above</a> | {{pagelink:design-core-1.1.4, text:Core v1.3.0 and above}} |
17
+
| {{pagelink:application6, text: Referrals into an Ambulance Service Trust (Application 6)}} | <p>CAD to CAD Out of Area Referral<br>CAD to CAD Call Assist Request<br>CAD to CAD Mutual Aid Request | 1.0.0-beta.6| <ahref="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0"target="_blank">API Spec v1.3.0 and above</a> | {{pagelink:design-core-1.1.4, text:Core v1.3.0 and above}} |
18
18
| {{pagelink:application7, text: Bookings into GP Practice (Application 7)}} | <p>Appointments for Patient facing services into GP Practice | 1.0.0-alpha.4 | <ahref="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.3.0"target="_blank">API Spec v1.3.0 and above</a> | {{pagelink:design-core-1.1.4, text:Core v1.3.0 and above}} |
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Build/Testing-and-Environments/Connect-as-a-receiver.page.md
+27-18Lines changed: 27 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,15 +6,16 @@ topic: Connect-as-a-receiver
6
6
7
7
BaRS uses TLS-MA to communicate with Receiving endpoints. Receiving endpoints need a certificate under the NHS Root CA to facilitate TLS-MA. The receiver needs to follow these steps to access Integration (INT) and Production (PROD) environments.
8
8
9
-
To connect to the BaRS proxy as a receiver follow these steps:
9
+
### How to connect to the BaRS proxy as a Receiver:
10
10
11
11
Step 1: Apply for your domain [apply for a new nhs.uk domain](https://digital.nhs.uk/services/networking-addressing/apply-for-an-nhs.uk-domain-for-websites-and-web-applications). You must complete Section 5: For website or application records visible on the public internet.
12
12
13
13
Step 2: Request a certificate under the NHS Root CA. The FQDN must be an nhs.uk address.
14
-
* There are different certificate chains for INT and PROD
15
-
* [INT Certificate](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates) chains (**Note:**_these may be out of date_)
16
-
* [PROD Certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment) chains (**Note:**_these may be out of date_)stered, you can then begin the process to obtain your certificate by generating a certificate request.
17
-
The fully qualified domain name (FQDN) is equal to the certificate name (CN) by convention.
14
+
There are different certificate chains for INT and PROD:
15
+
*[INT Certificate](https://digital.nhs.uk/services/path-to-live-environments/integration-environment#rootca-and-subca-certificates) chains (**Note:**_these may be out of date_)
16
+
*[PROD Certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment) chains (**Note:**_these may be out of date_)
17
+
18
+
Your domain must be registered before you begin the process to obtain your certificate generating a certificate request. The fully qualified domain name (FQDN) is equal to the certificate name (CN) by convention.
18
19
19
20
Step 3: Create a Certificate Signing Request (*.csr). This is the file you will send to us so we can generate a signed certificate for your endpoints. Create a private key; a password is optional.
Step 4: Send the .csr file to be signed by NHS England and get the client certificate. To do this, follow these environment specific steps:
30
31
31
32
#### Client certificate: Integration (INT)
33
+
32
34
Step 1: Contact ITOC to make a [Combined endpoint and service registration request](https://digital.nhs.uk/services/path-to-live-environments/path-to-live-forms/combined-endpoint-and-service-registration-request)
33
35
{{render:Onboarding FORM.png}}
34
-
In the form:
35
-
* Select Create/renew a certificate only (No endpoint)
36
-
* Specify Integration environment
37
-
* FQDN must match your domain and CN on the cert e.g. '**BaRS-INT-\<ODS Code\>.\<Supplier name\>.thirdparty.nhs.uk**'
38
-
* In Additional comments/notes, state ‘BaRS’ certificate request
39
-
* Add ‘N/A’ in the Party Key field because there is no relation to SDS endpoints
36
+
37
+
In the form:
38
+
* Select Create/renew a certificate only (No endpoint)
39
+
* Specify Integration environment
40
+
* FQDN must match your domain and CN on the cert e.g. '**BaRS-INT-\<ODS Code\>.\<Supplier name\>.thirdparty.nhs.uk**'
41
+
* In Additional comments/notes, state ‘BaRS’ certificate request
42
+
Add ‘N/A’ in the Party Key field because there is no relation to SDS endpoints
43
+
40
44
Step 2: Receive certificate from ITOC
45
+
41
46
Step 3: Email <england.bookingandreferralstandard@nhs.net> with Receiver URL for BaRS/API-M to add to the Endpoint Catalogue
42
47
43
48
#### Client certificate: Production (PROD)
49
+
44
50
**Production endpoints can only be requested when Solution Assurance issue the supplier with the Technical Conformance certificate**
45
-
Step1: Send the .csr to <dir@nhs.net>, indicating this is for a BaRS Receiver endpoint
46
-
* Format for FQDN on PROD for:
47
-
* Supplier hosted solutions is ‘**BaRS-PROD-\<ODS Code\>.\<Supplier name\>.thirdparty.nhs.uk**’
48
-
* This option is used for multi-tenanted solutions.
49
-
* Service Provider hosted solutions is ‘**BaRS-PROD-\<ODS Code\>.\<Provider name\>.nhs.uk**’
50
-
* This option is used for non multi-tenanted solutions. If multiple endpoints are needed, the ODS code can be appended with an identifier for the setting.
51
-
* It may be that the provider already has a 'nhs.uk' standard domain DNS entry. If one exists, it should be used for this new subdomain.
51
+
52
+
Step 1: Send the .csr to <dir@nhs.net>, indicating this is for a BaRS Receiver endpoint
* Service Provider hosted (on-premise) solutions‘**BaRS-PROD-\<ODS Code\>.\<Provider name\>.nhs.uk**’
58
+
52
59
Step 2: Receive certificate from DIR Team
60
+
53
61
Step 3: Email <england.bookingandreferralstandard@nhs.net> with Receiver URL for BaRS/API-M to add to the Endpoint Catalogue
62
+
54
63
Step 4: Make changes to your [firewall exceptions](https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Deploy/Technical-deployment\Firewallexceptions) to receive messages from the BaRS proxy.
55
64
56
65
#### Installing and configuring your application to use the certificate
0 commit comments