CGD Fixes

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

@@ -90,7 +90,7 @@ To cancel a referral this Application follows the {{pagelink:core-SPCancellation
 
 The Message Definition that defines the 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.
+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-APP3/How-does-it-work.page.md

@@ -106,7 +106,7 @@ To cancel a referral this Application follows the {{pagelink:core-SPCancellation
 
 The Message Definition that defines the 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.
+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/Core/1.0.7/Index.page.md

@@ -2,7 +2,7 @@
 topic: design-core-1.0.7
 ---
 
-# BaRS Core 1.0.6
+# BaRS Core 1.0.7
 
 BaRS consists of BaRS Core that provides a core set of functionality and BaRS Applications that provide distinct functionality for each use case.
 
@@ -60,9 +60,9 @@ You will find here a set of documentation, specifications and services that desc
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Initial-1.0.7 , text:Initial Request}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Update-1.0.7 , text:Sending an update}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Feedback-1.0.7 , text:Feedback (response) requests}}</br>
-&nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Retry-1.0.7 , text:Retry Scenario}}</br>
+&nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-RetryScenario-1.0.7 , text:Retry Scenario}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Onward-1.0.7 , text:Onwards Referrals}}</br>
-&nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-retry-1.0.7 , text:Definition of a Retry}}</br>
+&nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-RetryDefinition-1.0.7 , text:Definition of a Retry}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Receiver-1.0.7 , text:Receiver responsibilities}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:Core-TransactionalIntegrity-Sender-1.0.7 , text:Sender responsibilities}}</br>
 &nbsp;&nbsp;&nbsp;&nbsp;&bull; {{pagelink:core-TIFailureScenarios-1.0.7 , text:Failure Scenarios}}</br>

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md

@@ -22,7 +22,7 @@ topic: design-core-1.3.0
 </div>
 
 
-# BaRS Core 1.2.2-alpha
+# BaRS Core 1.3.0
 
 BaRS consists of BaRS Core that provides a core set of functionality and BaRS Applications that provide distinct functionality for each use case.
 

guides/Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Standard-Pattern-Composite-Messages/Cancellation.page.md

@@ -11,7 +11,7 @@ Cancellation, for any referral type or booking, is a stripped back request, cont
 
 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 (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.  
+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 on 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