diff --git a/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg b/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg index baa079cf..83a735c0 100644 --- a/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg +++ b/BaRS-Images/SequenceDiagrams/BaRS_StandardPattern_Cancellation_Find_Id.svg @@ -1,4 +1,4 @@ -
User
Sender
BaRS Proxy
Endpoint
Receiver
User
Sender
BaRS Proxy
Endpoint
Receiver
with ID
Find Patients Appointments
Get Appointment/ServiceRequest (ID)
Get Appointment/ServiceRequest (ID)
Appointment/ServiceRequest resource
Find Endpoint
Endpoint
Appointment/ServiceRequest resource
Show Appointments
Alt: with NHS No.
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Alt: with patient demographics
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Continue Cancellation workflow as outlined for use-case
 \ No newline at end of file +
User
Sender
BaRS Proxy
Endpoint
Receiver
User
Sender
BaRS Proxy
Endpoint
Receiver
with ID
Find Patient Appointments/\ServiceRequests 
Get Appointment/ServiceRequest (ID)
Get Appointment/ServiceRequest (ID)
Appointment/ServiceRequest resource
Find Endpoint
Endpoint
Appointment/ServiceRequest resource
Show 
Appointments/ServiceRequests
Alt: with NHS No.
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Get Appointment(s)/ServiceRequest(s) (NHS No.)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Alt: with patient demographics
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Get Appointment(s)/ServiceRequest(s) (Name, DoB and/or Postcode)
Appointment(s)/ServiceRequest (s) bundle
Find Endpoint
Endpoint
Appointment(s)/ServiceRequest (s) bundle
Continue Cancellation workflow as outlined for use-case
 \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md index ed4bcca7..977a2562 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/How-does-it-work.page.md +++ b/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: 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 f6f0d1e5..93aa1177 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 @@ -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: 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 25dc3dac..40b4e41b 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 @@ -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     • {{pagelink:Core-TransactionalIntegrity-Initial-1.0.7 , text:Initial Request}}
    • {{pagelink:Core-TransactionalIntegrity-Update-1.0.7 , text:Sending an update}}
    • {{pagelink:Core-TransactionalIntegrity-Feedback-1.0.7 , text:Feedback (response) requests}}
-    • {{pagelink:Core-TransactionalIntegrity-Retry-1.0.7 , text:Retry Scenario}}
+    • {{pagelink:Core-TransactionalIntegrity-RetryScenario-1.0.7 , text:Retry Scenario}}
    • {{pagelink:Core-TransactionalIntegrity-Onward-1.0.7 , text:Onwards Referrals}}
-    • {{pagelink:Core-TransactionalIntegrity-retry-1.0.7 , text:Definition of a Retry}}
+    • {{pagelink:Core-TransactionalIntegrity-RetryDefinition-1.0.7 , text:Definition of a Retry}}
    • {{pagelink:Core-TransactionalIntegrity-Receiver-1.0.7 , text:Receiver responsibilities}}
    • {{pagelink:Core-TransactionalIntegrity-Sender-1.0.7 , text:Sender responsibilities}}
    • {{pagelink:core-TIFailureScenarios-1.0.7 , text:Failure Scenarios}}
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 4a3475b9..f3ca3e8f 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 @@ -22,7 +22,7 @@ topic: design-core-1.3.0 -# 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. 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 9955e425..d1cad54f 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 @@ -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