use-contextHTTPHeaderChange

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/About-BaRS.page.md

@@ -26,7 +26,7 @@ The workflow and payload elements can be predefined or completely dynamic, enabl
 
 The documentation for BaRS is separated into three groups (or "products"):
 
-- {{pagelink:design-core-1.0.5}} is the foundation containing all the things *everyone* has to do regardless of what flows BaRS is being used to support
+- {{pagelink:design-core-1.0.6}} is the foundation containing all the things *everyone* has to do regardless of what flows BaRS is being used to support
 
 - {{pagelink:Applications}}, *apply* the standard to a specific problem and build on this to support specific use cases
 

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/About-BaRS/Quick-Start-Guide.page.md

@@ -6,7 +6,7 @@ Follow this **Quick Start Guide** to best understand how to approach BaRS:
 We recommend reading the following documentation as part of the discovery stage to inform planning: 
 
 * {{pagelink:definitions_key_terms, text:Definition of key terms}}  
-* {{pagelink:design-core-1.0.5, text:BaRS Core}} 
+* {{pagelink:design-core-1.0.6, text:BaRS Core}} 
 * {{pagelink:applications, text:BaRS Applications}}
 * [BaRS FHIR API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0)
 
@@ -16,10 +16,10 @@ We recommend reading the following documentation as part of the discovery stage
 Full details of the security model adopted by the platform can be found under the [security](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication) section.
 
 ### Design
-The following sections provide the essential information needed to design and build a BaRS compliant solution. BaRS is devised in a way to support re-use of functionality across multiple uses cases, to this end the implementation guidance is split into {{pagelink:design-core-1.0.5, text:BaRS Core}} and {{pagelink:applications, text:BaRS Application}} sections. All solutions **must** build the Core and add the specific requirements of the Application to support the given use case. BaRS Core is not sufficient on its own, an Application will always be required. 
+The following sections provide the essential information needed to design and build a BaRS compliant solution. BaRS is devised in a way to support re-use of functionality across multiple uses cases, to this end the implementation guidance is split into {{pagelink:design-core-1.0.6, text:BaRS Core}} and {{pagelink:applications, text:BaRS Application}} sections. All solutions **must** build the Core and add the specific requirements of the Application to support the given use case. BaRS Core is not sufficient on its own, an Application will always be required. 
 
 ### End-to-end workflow 
-When developing against the standard, understanding the {{pagelink:core-EndToEndWorkflow-1.0.5, text:end-to-end workflow}} is key. This section of the guide describes how a solution interacts with the BaRS API, along with the assumptions and expectations of Senders and Receivers. These are the roles suppliers will adopt when building a solution. This guide is written predominantly from the perspective of the request; the Sender and Receiver of the request. However, if the BaRS Application include a response workflow these roles swap, the Sender becoming the Receiver and vice versa. 
+When developing against the standard, understanding the {{pagelink:core-EndToEndWorkflow-1.0.6, text:end-to-end workflow}} is key. This section of the guide describes how a solution interacts with the BaRS API, along with the assumptions and expectations of Senders and Receivers. These are the roles suppliers will adopt when building a solution. This guide is written predominantly from the perspective of the request; the Sender and Receiver of the request. However, if the BaRS Application include a response workflow these roles swap, the Sender becoming the Receiver and vice versa. 
 
 BaRS includes several {{pagelink:applications, text:BaRS Application (use cases)}}, each of which supports multiple use cases that share a common workflow and data model.
 
@@ -28,15 +28,15 @@ BaRS includes several {{pagelink:applications, text:BaRS Application (use cases)
 The BaRS [API specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_0_0) provides detail of the structure of endpoints. The specification allows you to 'Try this API', calling endpoints to view anticipated responses. This is a purely technical document and must be read in conjunction with implementation guidance to build a compliant solution. 
 
 ### Security
-All {{pagelink:core-Security-1.0.5, text:security}} is provided through our platform. There are two methods for securing interactions via BaRS API:
+All {{pagelink:core-Security-1.0.6, text:security}} is provided through our platform. There are two methods for securing interactions via BaRS API:
 * senders will [generate an access token](https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/application-restricted-restful-apis-signed-jwt-authentication#how-this-pattern-works) from the platform and use this to authenticate with the BaRS API. Additionally, requests will include HTTP header values identifying the organisation, software and user, which are passed through the BaRS API to Receivers who apply their own access control to the request based on the headers content.
 * for Receivers accepting requests, the BaRS API secures the connection with the Receiver using Transport Layer Security Mutual Authentication (TLS MA), using an [NHS Root CA issued certificate](https://digital.nhs.uk/services/path-to-live-environments/live-environment#rootca-and-subca-certificates). The HTTP header values (as described above) are also passed through. This provides the Receiver with sufficient information to accept or reject the request without having to inspect the payload body. 
 
 #### Error Handling 
-{{pagelink:core-ErrorHandling-1.0.5, text:Error handling}} is an important part of the standard for two key reasons:
+{{pagelink:core-ErrorHandling-1.0.6, text:Error handling}} is an important part of the standard for two key reasons:
 
 * to ensure workflow is as smooth and seamless as possible, the error responses returned **must** be clear to allow the appropriate next action to take place, for example, to include a missing element of information (highlighted by the error response).
-* there are several levels of interactions occurring from the Sender, through BaRS API to the Receiver and clearly identifying where the fault lies is important for swift resolution. All implementations **must** adhere to the {{pagelink:core-ErrorHandling-1.0.5, text:error handling guidance}} which is part of the {{pagelink:assure, text:assurance}} process.
+* there are several levels of interactions occurring from the Sender, through BaRS API to the Receiver and clearly identifying where the fault lies is important for swift resolution. All implementations **must** adhere to the {{pagelink:core-ErrorHandling-1.0.6, text:error handling guidance}} which is part of the {{pagelink:assure, text:assurance}} process.
 
 ### Build
 #### Environments

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.0.6.page.md

@@ -0,0 +1,14 @@
+---
+topic: TRN-Core-1.0.6
+---
+
+## {{page-title}}
+
+| Change                                   | Description                            | Impact                          | 
+|------------------------------------------|----------------------------------------|---------------------------------|
+| Guidance on 'use-context' HTTP header updated         | 'use-context' HTTP header is only require on write actions - POST, PUT and PATCH | <mark style="background-color: LightGreen">non-breaking</mark>  |
+
+<br>
+<hr>
+
+### Previous Releases

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md

@@ -0,0 +1,12 @@
+---
+topic: TRN-Core-1.1.6
+---
+
+## {{page-title}}
+
+| Change                                   | Description                            | Impact                          | 
+|------------------------------------------|----------------------------------------|---------------------------------|
+| Guidance on 'use-context' HTTP header updated         | 'use-context' HTTP header is only require on write actions - POST, PUT and PATCH | <mark style="background-color: LightGreen">non-breaking</mark>  |
+
+<br>
+<hr>

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md

@@ -0,0 +1,12 @@
+---
+topic: TRN-Core-1.2.2
+---
+
+## {{page-title}}
+
+| Change                                   | Description                            | Impact                          | 
+|------------------------------------------|----------------------------------------|---------------------------------|
+| Guidance on 'use-context' HTTP header updated         | 'use-context' HTTP header is only require on write actions - POST, PUT and PATCH | <mark style="background-color: LightGreen">non-breaking</mark>  |
+
+<br>
+<hr>

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/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.0.5, text:Core}}**: BaRS Core components - API Spec, Endpoint Catalogue etc.
+* **{{pagelink:design-core-1.0.6, 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.1.5, text:standard pattern for BaRS composite operations}}.
+Making a referral for this Application follows the {{pagelink:core-SPComposites-1.1.6, 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,9 +86,9 @@ X-Correlation-Id = <GUID_000002>
 
 ### Cancel a Referral
 
-To cancel a referral this Application follows the {{pagelink:core-SPComposites-1.1.5, text:standard pattern for BaRS composite operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the referral from the **receiver** as it may have changed locally. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy).
+To cancel a referral this Application follows the {{pagelink:core-SPComposites-1.1.6, text:standard pattern for BaRS composite operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the referral from the **receiver** as it may have changed locally. This is done by performing a "GET ServiceRequest by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy).
 
-The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.1.5, text:standard pattern}}.
+The response to this request will be the requested ServiceRequest resource which should be checked for its current status to ensure it does not already have a status of "revoked". If not, this version of the ServiceRequest should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.1.6, text:standard pattern}}.
 
 The message definition that defines this payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 
@@ -249,7 +249,7 @@ X-Correlation-Id = <GUID_00002>
 
 ### Make a booking
 
-Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.1.5, text:standard pattern for BaRS operations}}.
+Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.1.6, text:standard pattern for BaRS operations}}.
 
 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)
 
@@ -310,9 +310,9 @@ X-Correlation-Id = <GUID_00002>
 ```
 ### Cancel a Booking
 
-To cancel a booking this Application follows the {{pagelink:core-standardpattern-1.1.5, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the booking from the **receiver** as it may have changed locally. This is done by performing a "GET Appointment by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy).
+To cancel a booking this Application follows the {{pagelink:core-standardpattern-1.1.6, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, it is first necessary to retrieve the latest version of the booking from the **receiver** as it may have changed locally. This is done by performing a "GET Appointment by ID" call to the **receiving** system's corresponding API endpoint (via the BaRS proxy).
 
-The response to this request will be the requested Appointment resource which should be checked for its current status to ensure it does not already have a status of "cancelled". If not, this version of the Appointment should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.1.5, text:standard pattern}}.
+The response to this request will be the requested Appointment resource which should be checked for its current status to ensure it does not already have a status of "cancelled". If not, this version of the Appointment should be used when re-submitting the modified resource in the POST bundle as described in the {{pagelink:Core-StandardPattern-1.1.6, text:standard pattern}}.
 
 The message definition that defines this 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

@@ -53,7 +53,7 @@ This Application supports the use of the following use cases:
 
 ### Overview
 
-This page provides guidance for implementing the Booking and Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.0.5, text:BaRS Core implementation guide}} and Payload Definitions when developing to the standard.
+This page provides guidance for implementing the Booking and Referral Standard (BaRS) specifically for the use cases listed above. It should be used alongside the {{pagelink:design-core-1.0.6, text:BaRS Core implementation guide}} and Payload Definitions when developing to the standard.
 
 ### Data model endorsements
 

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.1.5, text:Standard Patterns for BaRS Operations}} explains in detail how the **MessageHeader** resource **must** be used. 
+{{pagelink:core-SPMessageHeader-1.1.6, 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'
@@ -27,7 +27,7 @@ There are two *coding* entries within *ServiceRequest.category* which are key to
 1. Denotes the type of referral e.g. Transfer of care
 2. Denotes the use case and must be populated with the relevant use case from [use-case CodeSystem](
 https://simplifier.net/nhsbookingandreferrals/usecases-categories-bars
-). e.g. 111 - ED. 999 - UTC, CAS - SEDEC. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.0.5, text:use-case categories}}
+). e.g. 111 - ED. 999 - UTC, CAS - SEDEC. Please refer to the guidance in {{pagelink:core-SPUseCaseCategories-1.0.6, text:use-case categories}}
 
 An important function of the ServiceRequest resource is to link the booking and referral when they are related in a workflow. If the booking is successfully made before the referral, the Sender will have the *Appointment.Id* value (from the synchronous HTTP response) and this **must** be included as a relative reference, under *ServiceRequest.supportingInfo*, in the referral request. The element *ServiceRequest.supportingInfo* **may** also be used to provide reference to other resources in the request i.e. Rejected Services. This is outlined in the element guidance below.