20260703 dd ig 1.12.0

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/1.5.0.page.md

@@ -0,0 +1,28 @@
+---
+topic: TRN-API-1.5.0
+---
+<br>
+
+<div class="bars-blg-expander">
+<div class="bars-blg-expander-entry" id="v1.5.0">
+
+## {{page-title}}
+
+### Change Log
+
+### in BaRS 1.12.0
+
+| Change                                       | Description                                                         | Impact |
+|----------------------------------------------|---------------------------------------------------------------------|--------|
+| <div class="imgHandshake">{{render:handshake}}</div> - Added optional Related Person | Added Related Person as an optional element that could be sent to provide next of kin information to Receivers | <mark style="background-color: Yellow">Addition</mark>   |
+
+
+
+<br>
+<hr>
+
+</div>
+</div>
+
+<hr>
+<br>

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/API-Spec-Change-Log/toc.yaml

@@ -2,6 +2,8 @@
   filename: Index.page.md
 - name: Global
   filename: Global.page.md
+- name: 1.5.0
+  filename: 1.5.0.page.md
 - name: 1.4.1
   filename: 1.4.1.page.md
 - name: 1.4.0

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Releases/Technical-Release-Notes/BaRS-Core/1.5.0.page.md

@@ -6,7 +6,7 @@ topic: TRN-Core-1.5.0
 
 | Change                                   | Description                            | Impact                          | 
 |------------------------------------------|----------------------------------------|---------------------------------|
-
+| API version increment | API Spec version incremented from v1.4.1 to v1.5.0 |    <mark style="background-color: Green">Non-breaking</mark>  | 
 
 <br>
 <hr>

guides/Live-ImplementationGuide-BaRS/Home/Analysis/Versioning.guide.md

@@ -24,7 +24,7 @@ The extensions ALPHA, BETA or RC (Release Candidate) will be used to indicate th
 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. 
 
 Components involved in an overall version:- 
-* **{{pagelink:design-core-1.4.1, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc.
+* **{{pagelink:design-core-1.5.0, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc.
 * **[Package](https://simplifier.net/NHSBookingandReferrals/~packages)**: FHIR package
 * **{{pagelink:applications, text:Application}}**: the use cases i.e. '111 to ED'
 * **{{pagelink:fhir_assets, text:FHIR Assets}}**: MessageDefinitions and profiles

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md

@@ -13,7 +13,7 @@ To support the workflows for this Application of the standard the operations tha
 
 ### Make a Referral
 
-Making a referral for this Application follows the {{pagelink:core-SPComposites-1.4.1, text:standard pattern for BaRS composite operations}}.
+Making a referral for this Application follows the {{pagelink:core-SPComposites-1.5.0, text:standard pattern for BaRS composite operations}}.
 
 The Message Definition that defines this payload for this Application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
 
@@ -86,7 +86,7 @@ X-Correlation-Id = <GUID_000002>
 
 ### Cancel a Referral
 
-To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}. 
+To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.5.0, text:standard pattern for BaRS cancellation}}. 
 
 The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 
@@ -247,7 +247,7 @@ X-Correlation-Id = <GUID_00002>
 
 ### Make a booking
 
-Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
+Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.5.0, text:standard pattern for BaRS Composite Messages}}.
 
 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)
 
@@ -308,7 +308,7 @@ X-Correlation-Id = <GUID_00002>
 ```
 ### Cancel a Booking
 
-To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}. 
+To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.5.0, text:standard pattern for BaRS cancellation}}. 
 
 The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Index.page.md

@@ -20,7 +20,7 @@ topic: Application1
 <tbody>
 	<tr>
 		<td>Application 1 v2.1.0</td>
-		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core?version=1.10.0" target="_blank">v1.0.x</a></td>
+		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core?version=1.12.0" target="_blank">v1.0.x</a></td>
 		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/home?version=1.12.0" target="_blank">v1.12.0</td>
 		<td><a href="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7" target="_blank">v1.0.0</a></td>
 	</tr>

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Payloads.page.md

@@ -6,7 +6,7 @@ topic: APP1-Payloads
 The specific guidance around the use of key FHIR resources is described below. 
 
 ### MessageHeader Resource
-{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used. 
+{{pagelink:core-SPMessageHeader-1.5.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used. 
 
 The MessageHeader resource for the Booking Request should have the following resource elements set as follows:
 * **MessageHeader.eventCoding** - **must** be populated with 'booking-request'

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Scope-and-Requirements.page.md

@@ -87,8 +87,8 @@ The payloads and workflow have been designed to support these services. Other {{
 * The booking Receiver **must** accept the booking request regardless of whether the patient is known to the service provider
 * The booking Receiver **must** accept potential patients who do **<ins>not</ins>** have a national validated identifier e.g. NHS Number.
 * 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
-* 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.
-* 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.
+* Where the booking was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.5.0, text:failure scenarios}} for more detail.
+* 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.5.0, text:failure scenarios}} for more detail.
 * If included in the synchronous HTTP response, the booking Sender **must** make available the human readable identifier for the booking to the end user
 * The booking Sender **must** send accompanying clinical information in a BaRS referral request
   * 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 {{
 * The referral Receiver **must** clearly identify any included safeguarding concern to the end user
 * The referral Receiver **must** accurately represent information made by the Sender to the end user
 * The referral Sender **must** make available the human readable identifier for the referral, included in the HTTP synchronous response, to the end user
-* 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.
-* 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.
+* Where the referral was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.5.0, text:failure scenarios}} for more detail.
+* 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.5.0, text:failure scenarios}} for more detail.
 * The referral Sender **must** include reference to any accompanying BaRS booking related to the referral
   * The referral Sender's request **must** be referenced in the BaRS booking request (where the referral is made first in the workflow)
   * 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 {{
 <br>
 
 ### Error Handling 
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}} 
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.5.0, text:error handling guidance}} 
 <br>
 <br>
 ### Non Functional 
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.5.0, text:non functional requirements}}
 
 <br>
 <br>

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/How-does-it-work.page.md

@@ -13,7 +13,7 @@ To support the workflows for this Application of the standard the operations tha
 
 ### Make a Referral
 
-Making a referral for this Application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
+Making a referral for this Application follows the {{pagelink:core-standardpattern-1.5.0, text:standard pattern for BaRS Composite Messages}}.
 
 The message definition that defines this payload for this Application is: {{link:https://fhir.nhs.uk/MessageDefinition/bars-message-servicerequest-request-referral}}
 
@@ -140,7 +140,7 @@ X-Correlation-Id = <GUID_00002>
 
 ### Make a booking
 
-Making a booking for this Application follows the {{pagelink:core-standardpattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
+Making a booking for this Application follows the {{pagelink:core-standardpattern-1.5.0, text:standard pattern for BaRS Composite Messages}}.
 
 The message definition that defines this payload for this Application is: {{link:https://fhir.nhs.uk/MessageDefinition/bars-message-servicerequest-request-referral}}
 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Index.page.md

@@ -21,7 +21,7 @@ topic: Application2
 <tbody>
 	<tr>
 		<td>Application 2 v2.1.0</td>
-		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core?version=1.10.0" target="_blank">v1.0.x</a></td>
+		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/Home/Core?version=1.12.0" target="_blank">v1.0.x</a></td>
 		<td><a href="https://simplifier.net/guide/nhsbookingandreferralstandard/home?version=1.12.0" target="_blank">v1.12.0</td>
 		<td><a href="https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1.0.7" target="_blank">v1.0.0</a></td>
 	</tr>

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Payloads.page.md

@@ -6,7 +6,7 @@ topic: APP2-Payloads
 The specific guidance around the use of key FHIR resources is described below. 
 
 ### MessageHeader Resource
-{{pagelink:core-SPMessageHeader-1.4.1, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used. 
+{{pagelink:core-SPMessageHeader-1.5.0, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used. 
 
 The MessageHeader resource for the Booking Request should have the following resource elements set as follows:
 * **MessageHeader.eventCoding** - **must** be populated with 'booking-request'

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Scope-and-Requirements.page.md

@@ -80,8 +80,8 @@ The payloads and workflow have been designed to support these services. Other {{
 * The booking Receiver **must** accept the booking request regardless of whether the patient is not known to the service provider
 * The booking Receiver **must** accept potential patients who do <ins>not</ins> have a national validated identifier e.g. NHS Number.
 * 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
-* 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.
-* 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.
+* Where the booking was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.5.0, text:failure scenarios}} for more detail.
+* 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.5.0, text:failure scenarios}} for more detail.
 * The booking Sender **must** send accompanying clinical information in a BaRS referral request
   * The booking Sender's request **must** be referenced in the BaRS referral request (where the booking is made first in the workflow)
   * The booking Receiver **must** link the explicitly related booking and referral requests
@@ -108,8 +108,8 @@ The payloads and workflow have been designed to support these services. Other {{
 * Any new or existing safeguarding concern, recorded as part of the assessment, **must** be included in the referral Sender's request
 * The referral Receiver **must** clearly identify any included safeguarding concern to the end user
 * The referral Receiver **must** accurately represent information made by the Sender to the end user
-* 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.
-* 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.
+* Where the referral was <ins>not</ins> successful, the Receiver **must** send an appropriate response. See {{pagelink:core-failure_scenarios-1.5.0, text:failure scenarios}} for more detail.
+* 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.5.0, text:failure scenarios}} for more detail.
 * The referral Sender **must** include reference to any accompanying BaRS booking related to the referral
   * The referral Sender's request **must** be referenced in the BaRS booking request (where the referral is made first in the workflow)
   * The referral Receiver **must** link the explicitly related booking and referral requests
@@ -130,11 +130,11 @@ The payloads and workflow have been designed to support these services. Other {{
 <br>
 <br>
 ### Error Handling 
-* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.4.1, text:error handling guidance}} 
+* Suppliers **must** adhere to the {{pagelink:core-ErrorHandling-1.5.0, text:error handling guidance}} 
 <br>
 <br>
 ### Non Functional 
-* Suppliers **must** adhere to the {{pagelink:core-NFR-1.4.1, text:non functional requirements}}
+* Suppliers **must** adhere to the {{pagelink:core-NFR-1.5.0, text:non functional requirements}}
 <br>
 <br>
 <hr>

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md

@@ -30,7 +30,7 @@ To support the workflows for this application of the standard the operations tha
 
 ### Make a Referral
 
-Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.4.1, text:standard pattern for BaRS Composite Messages}}.
+Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.5.0, text:standard pattern for BaRS Composite Messages}}.
 
 The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
 <p>
@@ -102,7 +102,7 @@ X-Correlation-Id = <GUID_000002>
 
 ### Cancel a Referral
 
-To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.4.1, text:standard pattern for BaRS cancellation}}. 
+To cancel a referral this Application follows the {{pagelink:core-SPCancellation-1.5.0, text:standard pattern for BaRS cancellation}}. 
 
 The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/Payloads.page.md

@@ -5,7 +5,7 @@ topic: APP3-Payloads
 ## {{page-title}}
 
 ### MessageHeader Resource
-For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.4.1, text:Standard Pattern Message Header}}. 
+For detailed information on the use of MessageHeader please refer to the {{pagelink:core-SPMessageHeader-1.5.0, text:Standard Pattern Message Header}}. 
 
 The MessageHeader resource for the Referral Request should have the following resource elements set as follows:
 * **MessageHeader.eventCoding** - **must** be populated with 'servicerequest-request'
@@ -91,7 +91,7 @@ The level of consent currently supported by BaRS is for 'Direct Care' only. In e
 
 ## Referral Cancellation Payload
 
-The ability to cancel a Referral Request is a core workflow in BaRS. For details on the use of the standard pattern for cancellation please see the following {{pagelink:core-SPCancellation-1.4.1, text:Standard Patterns - Cancellation}}.
+The ability to cancel a Referral Request is a core workflow in BaRS. For details on the use of the standard pattern for cancellation please see the following {{pagelink:core-SPCancellation-1.5.0, text:Standard Patterns - Cancellation}}.
 
 <br>
 <hr>