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
Release 1.11.0 of the BaRS Implementation Guide introduces BaRS Application 8 "Referrals to a broker for Healthcare Service selection" as an alpha release. BaRS Application 8 is designed to create interoperability for referrals between NHS England products. The next phase of content and navigation changes in the Implementation Guide are delivered. They are focussed on: the Home page, the Analysis section (formerly About BaRS) and relocation of content from this area. These changes are based on user feedback.
24
-
25
-
Application 5 is updated with the withdrawal of use cases for GP to Blood Pressure Check Service and GP to Pharmacy Contraception (Oral Contraception). Also included in this release are minor changes to BaRS Application 6 and bug fixes and corrections throughout the guide.
23
+
TBC
26
24
27
25
A clinical safety assessment of the scope of this release has determined that it has not significantly changed the clinical safety profile of the BaRS. No new hazards have been identified in this release. The latest version of the BaRS clinical safety case and hazard log can be downloaded from the <ahref= "https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/onboarding-support-information#hazard-log-and-clinical-safety-case-report-cscr-"target="_blank"> BaRS FHIR API onboarding support information page </a>.
28
26
@@ -181,12 +179,16 @@ Table detailing active versions of the latest Applications in Production (or cur
Release 1.11.0 of the BaRS Implementation Guide introduces BaRS Application 8 "Referrals to a broker for Healthcare Service selection" as an alpha release. BaRS Application 8 is designed to create interoperability for referrals between NHS England products. The next phase of content and navigation changes in the Implementation Guide are delivered. They are focussed on: the Home page, the Analysis section (formerly About BaRS) and relocation of content from this area. These changes are based on user feedback.
26
+
27
+
Application 5 is updated with the withdrawal of use cases for GP to Blood Pressure Check Service and GP to Pharmacy Contraception (Oral Contraception). Also included in this release are minor changes to BaRS Application 6 and bug fixes and corrections throughout the guide.
28
+
29
+
A clinical safety assessment of the scope of this release has determined that it has not significantly changed the clinical safety profile of the BaRS. No new hazards have been identified in this release. The latest version of the BaRS clinical safety case and hazard log can be downloaded from the <ahref= "https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/onboarding-support-information#hazard-log-and-clinical-safety-case-report-cscr-"target="_blank"> BaRS FHIR API onboarding support information page </a>.
30
+
31
+
</div>
32
+
</div>
33
+
34
+
<hr>
35
+
<br>
36
+
37
+
<divclass="bars-blg-expander">
38
+
<divclass="bars-blg-expander-entry"id="v1.10.0">
7
39
8
40
Product Link | Version | Handle | Phase | State | Release Date | Stability | Change Log Link
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -24,7 +24,7 @@ The extensions ALPHA, BETA or RC (Release Candidate) will be used to indicate th
24
24
An appreciation of the components involved in a released version must be understood when building solutions. These separate components come together under the umbrella of a given overall version but the components themselves are also versioned. This published implementation guide denotes the 'overall version' referenced.
25
25
26
26
Components involved in an overall version:-
27
-
***{{pagelink:design-core-1.4.0, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc.
27
+
***{{pagelink:design-core-1.4.1, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc.
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -13,7 +13,7 @@ To support the workflows for this Application of the standard the operations tha
13
13
14
14
### Make a Referral
15
15
16
-
Making a referral for this Application follows the {{pagelink:core-SPComposites-1.4.0, text:standard pattern for BaRS composite operations}}.
16
+
Making a referral for this Application follows the {{pagelink:core-SPComposites-1.4.1, text:standard pattern for BaRS composite operations}}.
17
17
18
18
The Message Definition that defines this payload for this Application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.4.0, text:standard pattern for BaRS cancellation}}.
89
+
To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}.
90
90
91
91
The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.4.0, text:standard pattern for BaRS Composite Messages}}.
250
+
Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
251
251
252
252
The Message Definition that defines this payload for this Application is: [BARS Message Definition - Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-bars-messagedefinition-booking-request)
To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.4.0, text:standard pattern for BaRS cancellation}}.
311
+
To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}.
312
312
313
313
The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ topic: APP1-Payloads
6
6
The specific guidance around the use of key FHIR resources is described below.
7
7
8
8
### MessageHeader Resource
9
-
{{pagelink:core-SPMessageHeader-1.4.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
9
+
{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used.
10
10
11
11
The MessageHeader resource for the Booking Request should have the following resource elements set as follows:
12
12
***MessageHeader.eventCoding** - **must** be populated with 'booking-request'
Copy file name to clipboardExpand all lines: guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Scope-and-Requirements.page.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -87,8 +87,8 @@ The payloads and workflow have been designed to support these services. Other {{
87
87
* The booking Receiver **must** accept the booking request regardless of whether the patient is known to the service provider
88
88
* The booking Receiver **must** accept potential patients who do **<ins>not</ins>** have a national validated identifier e.g. NHS Number.
89
89
* Where a national identifier is included, it **must** have a [verification status](https://simplifier.net/hl7fhirukcorer4/valueset-ukcore-nhsnumberverificationstatus) of 'Number present and verified' or 'Number present but not traced', otherwise, the referral Sender **must <ins>not</ins>** include it in the request
90
-
* Where the booking was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
91
-
* Where the booking was <ins>not</ins> successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
90
+
* Where the booking was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
91
+
* Where the booking was <ins>not</ins> successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
92
92
* If included in the synchronous HTTP response, the booking Sender **must** make available the human readable identifier for the booking to the end user
93
93
* The booking Sender **must** send accompanying clinical information in a BaRS referral request
94
94
* The booking Sender **must** reference the booking in the BaRS referral request (where the booking is made first in the workflow)
@@ -131,8 +131,8 @@ The payloads and workflow have been designed to support these services. Other {{
131
131
* The referral Receiver **must** clearly identify any included safeguarding concern to the end user
132
132
* The referral Receiver **must** accurately represent information made by the Sender to the end user
133
133
* The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
134
-
* Where the referral was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
135
-
* Where the referral was <ins>not</ins> successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.0, text:failure scenarios}} for more detail.
134
+
* Where the referral was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
135
+
* Where the referral was <ins>not</ins> successful, the Sender **must** present an appropriate message to the end user. See {{pagelink:core-failure_scenarios-1.4.1, text:failure scenarios}} for more detail.
136
136
* The referral Sender **must** include reference to any accompanying BaRS booking related to the referral
137
137
* The referral Sender's request **must** be referenced in the BaRS booking request (where the referral is made first in the workflow)
138
138
* The referral Receiver **must** link the explicitly related booking and referral requests
@@ -173,11 +173,11 @@ The payloads and workflow have been designed to support these services. Other {{
173
173
<br>
174
174
175
175
### Error Handling
176
-
* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.0, text:error handling guidance}}
176
+
* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}}
177
177
<br>
178
178
<br>
179
179
### Non Functional
180
-
* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.0, text:non functional requirements}}
180
+
* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
0 commit comments