FIXES+Apps-Update-Cancel

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP1/1.0.8.page.md

@@ -11,6 +11,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati
 |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------|
 | Implementation Guidance updated  | encounter.class.display value corrected from "Emergency" to "emergency" |  <mark style="background-color: Yellow">correction</mark>  |
 |NHSD-Requesting-Practioner Examples updated  | FHIRPractioner corrected to FHIRPractionerRole  |  <mark style="background-color: Yellow">correction</mark>  |
+| Simplified cancellation guidance   | Updated cancellation guidance, for bookings and referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 
 

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP3/1.0.4.page.md

@@ -10,6 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati
 | Change                                    | Description                                     | Impact                                                                  | 
 |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------|
 | Implementation Guidance updated  | patient.identifier.system Implementaton Guidance corrected |  <mark style="background-color: Yellow">correction</mark>  |
+| Simplified cancellation guidance   | Updated cancellation guidance, for referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 
 

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP4/1.2.3.page.md

@@ -10,6 +10,10 @@ This is a minor "patch" with clarifications to limited areas of the Implementati
 | Change                                    | Description                                     | Impact                                                                  | 
 |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------|
 | Implementation Guidance updated  | patient.identifier.system Implementaton Guidance corrected |  <mark style="background-color: Yellow">correction</mark>  |
+| Simplified cancellation guidance   | Updated cancellation guidance, for validations, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
+| Clarified cancellation payload guidance   | Updated cancellation guidance, for validation, under 'Payloads for Requestors', clarifying a Validation can be considered as a type of 'referral' when reading Standard Pattern documentation. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
+
+
 
 
 

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP5/1.1.3.page.md

@@ -16,6 +16,7 @@ This stable release (v1.1.3) of Application 5 sees minor corrections.
 | SNOMED Code Updated  | The SNOMED Code used to define a minor illness referral has been updated from '1577041000000100-Community Pharmacist Consultation Service for minor illness (procedure)' to '2140231000000104-Referral to Community Pharmacy Pharmacy First Service (procedure)', as requested by Pharmacy First Programme Clinical Lead |  <mark style="background-color: Yellow">correction</mark>  |
 | Implementation Guidance updated  | encounter.class.display value corrected from "Emergency" to "emergency" |  <mark style="background-color: Yellow">correction</mark>  |
 |NHSD-Requesting-Practioner Examples updated  | FHIRPractioner corrected to FHIRPractionerRole  |  <mark style="background-color: Yellow">correction</mark>  |
+| Simplified cancellation guidance   | Updated cancellation guidance, for referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 
 ### Payload Change Log

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP6/1.0.0-beta.5.page.md

@@ -10,7 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati
 | Change                                    | Description                                     | Impact                                                                  | 
 |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------|
 | Implementation Guidance updated  | patient.identifier.system Implementaton Guidance corrected |  <mark style="background-color: Yellow">correction</mark>  |
-
+| Simplified cancellation guidance   | Updated cancellation guidance, for bookings referrals, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 
 

guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/TRN-APP7/1.0.0-alpha.4.page.md

@@ -10,8 +10,7 @@ This is a minor "patch" with clarifications to limited areas of the Implementati
 | Change                                    | Description                                     | Impact                                                                  | 
 |-------------------------------------------|-------------------------------------------------|-------------------------------------------------------------------------|
 |NHSD-Requesting-Practioner Examples updated  | FHIRPractioner corrected to FHIRPractionerRole  |  <mark style="background-color: Yellow">correction</mark>  |
-
-
+| Simplified cancellation guidance   | Updated cancellation guidance, for bookings, under 'How does it work?', now pointing to Standard Patterns documentation. Reworded the description on use of Message Definitions when building a cancellation request. |   <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 ### Payload Change Log
 

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

@@ -15,7 +15,7 @@ To support the workflows for this Application of the standard the operations tha
 
 Making a referral for this Application follows the {{pagelink:core-SPComposites-1.3.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}}
+The Message Definition that defines this payload for this Application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
 
 
 
@@ -86,15 +86,13 @@ X-Correlation-Id = <GUID_000002>
 
 ### Cancel a Referral
 
-To cancel a referral this Application follows the {{pagelink:core-SPComposites-1.3.0, 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-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. 
 
-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.3.0, text:standard pattern}}.
+The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 
-The message definition that defines this payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
+If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral request can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above.
 
-As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition.
-
-In addition the specific workflow parameters that are required are as follows:
+In addition, the specific workflow parameters that are required are as follows:
 
 <div class="nhsd-m-emphasis-box">
     <div class="nhsd-a-box nhsd-a-box--border-grey">
@@ -251,7 +249,7 @@ X-Correlation-Id = <GUID_00002>
 
 Making a booking for this Application follows the {{pagelink:Core-StandardPattern-1.3.0, 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)
+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)
 
 In addition to that the specific workflow parameters that are required are as follows:
 
@@ -310,14 +308,12 @@ X-Correlation-Id = <GUID_00002>
 ```
 ### Cancel a Booking
 
-To cancel a booking this Application follows the {{pagelink:core-standardpattern-1.3.0, 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.3.0, text:standard pattern}}.
+To cancel a booking this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. 
 
-The message definition that defines this payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
+The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
 
+If the update-to-cancel is taking place as part of a re-book routine, once the cancellation is complete, the new booking request can be sent. This step in the workflow would follow the same process as 'Make a Booking' detailed above.
 
-As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed. This is always defined within the relevent message definition.
 
 In addition the specific workflow parameters that are required are as follows:
 

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

@@ -32,7 +32,7 @@ To support the workflows for this application of the standard the operations tha
 
 Making a referral for this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}}.
 
-The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
+The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Referral}}
 <p>
 
 In addition to that the specific workflow parameters that are required are as follows:
@@ -102,15 +102,11 @@ X-Correlation-Id = <GUID_000002>
 
 ### Cancel a Referral
 
-To cancel a referral this application follows the {{pagelink:Core-StandardPattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as descbribed on the linked section, the referral **sender** must perform a read of the referral to be cancelled, from the referral **receiver**, prior to cancellation to ensure they are working with the most up-to date information and it has not already been actioned. 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-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. 
 
-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" or "completed". 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.3.0, text:standard pattern}}.
+The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 
-The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
-
-As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be include. This is always defined within the relevent message definition.
-
-If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above.
+If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral request can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above.
 
 In addition the specific workflow parameters that are required are as follows:
 

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

@@ -70,7 +70,7 @@ To support the workflows for this application of the standard the operations tha
 
 Making a Validation Request for this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}}.
 
-The message definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Validation}}
+The Message Definition that defines this payload for this application is: {{link:MessageDefinition-BARS-MessageDefinition-ServiceRequest-Request-Validation}}
 <p>
 
 <hr>
@@ -142,15 +142,11 @@ X-Correlation-Id = <GUID_000002>
 
 ## Cancel Validation Request
 
-To cancel a Validation Request this application follows the {{pagelink:core-standardpattern-1.3.0, text:standard pattern for BaRS operations}} with an additional step. Before beginning the standard pattern as described on the linked section, the referral **sender** must perform a read of the referral to be cancelled, from the referral **receiver**, prior to cancellation to ensure they are working with the most up-to date information and it has not already been actioned or completed. 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 Validation Request this Application follows the {{pagelink:core-SPCancellation-1.3.0, text:standard pattern for BaRS cancellation}}. 
 
-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" or "completed". 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.3.0, text:standard pattern}}.
+The Message Definition that defines the payload for this Application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
 
-The message definition that defines this payload for this application is: {{link:messagedefinition-barsmessagedefinitionservicerequestrequestcancelled}}
-
-As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource, any resources that are mandated due to contextual, linking or referential integrity reasons and any resources that include elements that are being changed, **should** be included. This is always defined within the relevant message definition.
-
-If the update-to-cancel is taking place as part of a re-referral routine, once the cancellation is complete, the new referral message can be sent. This step in the workflow would follow the same process as 'Make a referral' detailed above.
+If the update-to-cancel is taking place as part of a resend validation routine, once the cancellation is complete, the new validation request can be sent. This step in the workflow would follow the same process as 'Make a Validation Request' detailed above.
 
 In addition the specific workflow parameters that are required are as follows:
 

guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md

@@ -102,7 +102,7 @@ The level of consent currently supported by BaRS is for 'Direct Care' only. In e
 
 ## Validation Cancellation Payload
 
-The ability to cancel a Validation 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.3.0, text:Standard Patterns - Cancellation}}.
+The ability to cancel a Validation 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.3.0, text:Standard Patterns - Cancellation}}. A Validation can be considered a type of 'referral' when reading the guidance.
 
 <br>