```
### 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:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md
index 15d3ec80..f6f0d1e5 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP3/How-does-it-work.page.md
+++ b/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}}
In addition to that the specific workflow parameters that are required are as follows:
@@ -102,15 +102,11 @@ X-Correlation-Id =
### 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:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md
index 37fd5a2e..f98155d1 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/How-does-it-work.page.md
+++ b/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}}
@@ -142,15 +142,11 @@ X-Correlation-Id =
## 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:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md
index 53c42366..52de63fb 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP4/Payloads-for-Requestors.page.md
+++ b/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.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md
index 9de967c0..e59a6f3e 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP5/How-does-it-work.page.md
@@ -164,7 +164,7 @@ When a service is chosen, the "Service ID" field in the DOS data will be used as
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}}
@@ -236,15 +236,11 @@ X-Correlation-Id =
### 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:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md
index ba9fcd3a..1f4bc5da 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP6/How-does-it-work.page.md
@@ -120,7 +120,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}}
In addition to that the specific workflow parameters that are required are as follows:
@@ -190,15 +190,11 @@ X-Correlation-Id =
### 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 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. 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 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 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:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md
index 25d3e2d6..4d91b503 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP7/How-does-it-work.page.md
@@ -80,7 +80,7 @@ X-Correlation-Id =
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:
@@ -146,14 +146,11 @@ This diagram illustrates the workflow and interactions of a booking cancellation
-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).
+To cancel a booking 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 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}}.
+The Message Definition that defines the payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
-The message definition that defines this payload for this Application is: [BARS Message Definition - Cancel Booking Request](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionbookingrequestcancelled)
-
-
-As a general principle, when performing an update type of operation (of which cancellation is a special case), only the focus resource is altered. Any resources that are mandated due to contextual, linking or referential integrity reasons play a supporting role, although any resources that include elements that are being changed are included too. This is always defined within the relevant message definition.
+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.
In addition the specific workflow parameters that are required are as follows:
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md
index f5de480d..25dc3dac 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md
@@ -11,7 +11,7 @@ You will find here a set of documentation, specifications and services that desc
> Expand for full Core directory
-• {{pagelink:design-core-1.0.7 , text: Core 1.0.6}}
+• {{pagelink:design-core-1.0.7 , text: Core 1.0.7}}
• {{pagelink:core-EndToEndWorkflow-1.0.7 , text:End to end workflow}}
• {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.0.7 , text:Service Discovery}}
• {{pagelink:core-EndToEndWorkflow-BaRSAuth-1.0.7 , text:Authenticate with BaRS}}
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md
index 4dd1d828..4a3475b9 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md
@@ -3,9 +3,6 @@ topic: design-core-1.3.0
---
Important: Versioning information
-
-This version of core is strictly a preview of what is currently in development for 1.2.2-alpha and should not be built against.
-
@@ -34,7 +31,7 @@ You will find here a set of documentation, specifications and services that desc
> Expand for full Core directory
-• {{pagelink:design-core-1.3.0 , text: Core 1.2.2}}
+• {{pagelink:design-core-1.3.0 , text: Core 1.3.0}}
• {{pagelink:core-EndToEndWorkflow-1.3.0 , text:End to end workflow}}
• {{pagelink:core-EndToEndWorkflow-ServiceDiscovery-1.3.0 , text:Service Discovery}}
• {{pagelink:core-EndToEndWorkflow-BaRSAuth-1.3.0 , text:Authenticate with BaRS}}
@@ -83,9 +80,9 @@ You will find here a set of documentation, specifications and services that desc
• {{pagelink:Core-TransactionalIntegrity-Initial-1.3.0 , text:Initial Request}}
• {{pagelink:Core-TransactionalIntegrity-Update-1.3.0 , text:Sending an update}}
• {{pagelink:Core-TransactionalIntegrity-Feedback-1.3.0 , text:Feedback (response) requests}}
- • {{pagelink:Core-TransactionalIntegrity-Retry-1.3.0 , text:Retry Scenario}}
+ • {{pagelink:Core-TransactionalIntegrity-RetryScenario-1.3.0 , text:Retry Scenario}}
• {{pagelink:Core-TransactionalIntegrity-Onward-1.3.0 , text:Onwards Referrals}}
- • {{pagelink:Core-TransactionalIntegrity-retry-1.3.0 , text:Definition of a Retry}}
+ • {{pagelink:Core-TransactionalIntegrity-RetryDefinition-1.3.0 , text:Definition of a Retry}}
• {{pagelink:Core-TransactionalIntegrity-Receiver-1.3.0 , text:Receiver responsibilities}}
• {{pagelink:Core-TransactionalIntegrity-Sender-1.3.0 , text:Sender responsibilities}}
• {{pagelink:core-TIFailureScenarios-1.3.0 , text:Failure Scenarios}}
@@ -243,7 +240,7 @@ For more detail please visit the {{pagelink:core-StandardPattern-document-refere
Important: Versioning information - Preview
-This version of core is strictly a preview of what is currently in development for 1.2.0 and should not be built against.
+This version of core is strictly a preview of what is currently in development for 1.3.0 and should not be built against.
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md
index fc24caa7..d48f1dbe 100644
--- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md
+++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md
@@ -9,15 +9,18 @@ The ability to reverse a digital request, by performing a cancellation, whether
Cancellation, for any referral type or booking, is a stripped back request, containing only the specific resources a Receiver requires to the fulfil the request. There are separate MessageDefinitions involved when engaged in [referral](https://simplifier.net/nhsbookingandreferrals/messagedefinition-barsmessagedefinitionservicerequestrequestcancelled/~json) and [booking](https://simplifier.net/NHSBookingandReferrals/MessageDefinition-BARSMessageDefinitionBookingRequestCancelled/~json) cancellation workflows.
-A prerequisite when performing a cancellation of any request is to perform a read (GET) of either the booking or referral to be cancelled. The Sender **must** only make a cancellation request if the entity has a status which means it is still current; 'active' in the case of a referral (ServiceRequest) and 'booked' for a booking (Appointment). This ensures the Sender has the latest version of the entity they are about to change or, if it is no longer current (because its been actioned by the Receiver), allows the Sender to advise the end user so an alternative (often manual) workflow can be started. The Receiver **must not** process a cancellation request for a booking or referral which is not current, instead they **must** return an appropriate {{pagelink:core-ErrorHandling-1.3.0, text:error}} response.
+A prerequisite when performing a cancellation of any request is to perform a read (GET) of either the booking or referral to be cancelled. The Sender **must** only make a cancellation request if the entity has a status which means it is still current; 'active' in the case of a referral (ServiceRequest) and 'booked' for a booking (Appointment). This ensures the Sender has the latest version of the resource they are about to change or, if it is no longer current (because its been actioned by the Receiver), allows the Sender to advise the end user so an alternative (often manual) workflow can be started. The Receiver **must not** process a cancellation request for a booking or referral which is not current, instead they **must** return an appropriate {{pagelink:core-ErrorHandling-1.3.0, text:error}} response.
-The Sender **must** obtain the (resource).id value of the booking (Appintment) or referral (ServiceRequest) to be able to generate the cancellation request. If the Sender made the original request, they will know this and can directly request the specific resource to check the status, using the GET (read) by Id request. Alternatively, if they did not generate the original request or there was a problem with the synchronous response being received, the booking or referral can be obtained by searching for active entities for the patient, either by using the national identifier (NHS No.) or patient demographics (Name (as defined by [FHIR](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/2834389 )), Date of Birth, Home Address Postcode) (See diagram under 'Options for obtaining booking or referral' for detailed workflows). This will return a (FHIR) bundle of responses (typically, containing only one resource) which the Sender can match based on dateTime (elements dependent of resource) and use-case category values to identify the resource of interest. If the Sender cannot match the resource they should advise the user the cancellation cannot be performed and to revert to manual cancellation options instead.
+The Sender **must** obtain the (resource).Id value of the booking (Appointment) or referral (ServiceRequest) to be able to generate the cancellation request. If the Sender made the original request, they will likely know this and can directly request the specific resource to check the status, using the GET (read) by Id request. Alternatively, if they did not generate the original request (or there was a problem with the synchronous response being received) the resource can be obtained by searching for active bookings or referrals for the patient, either by using the national identifier (NHS No.) or patient demographics (Name (as defined by [FHIR](https://simplifier.net/packages/hl7.fhir.r4.core/4.0.1/files/2834389 )), Date of Birth, Home Address Postcode) (See diagram under 'Options for obtaining booking or referral' for detailed workflows). This will return a (FHIR) bundle of responses (typically, containing only one entry) which the Sender can match based on dateTime (elements dependent of resource) and use-case category values to identify the resource of interest. If the Sender cannot match the resource they should advise the user the cancellation cannot be performed and to revert to manual cancellation options instead.
#### Options for obtaining booking or referral
-The below diagram details the options for obtaining the booking (Appointment) or referral (ServiceRequest) resource, prior to cancellation. The Sender **must** know the (resource).status and (resource).id values, as minimum, to build a valid cancellation request.
+
+The below diagram details the options for obtaining the booking (Appointment) or referral (ServiceRequest) resource, prior to cancellation. The Sender must know the (resource).status and (resource).id values, as minimum, to build a valid cancellation request.
+
+
