From f3f71dd1aeb3aa43f99e4bdd019186af597be3cb Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 20 Jun 2025 13:11:09 +0100 Subject: [PATCH 1/5] Retry file names for core expander 1.0.7 --- .../Home/Core/1.0.7/Index.page.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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..b0b9fbe3 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 @@ -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}}
From 689de5421f1acc4a59149d42eb18ad7ade928335 Mon Sep 17 00:00:00 2001 From: luci-davies Date: Fri, 20 Jun 2025 13:25:29 +0100 Subject: [PATCH 2/5] Cardinality fixes and markdown bug resolved --- .../Applications/BaRS-APP1/Booking-Request-Payload.page.md | 2 +- .../Applications/BaRS-APP1/Referral-Payload.page.md | 2 +- .../Applications/BaRS-APP1/Referral-Response-Payload.page.md | 2 +- .../Applications/BaRS-APP2/Booking-Request-Payload.page.md | 4 ++-- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md index 17800b2d..7d638755 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Booking-Request-Payload.page.md @@ -29,7 +29,7 @@ This payload is used to support a booking workflow and contains all the required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md index 7ee66274..a736dd1a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Payload.page.md @@ -25,7 +25,7 @@ This payload is used to transmit all the necessary information that is required | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | | MUST | 0..1 | | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md index 4c0db6a4..42194400 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP1/Referral-Response-Payload.page.md @@ -25,7 +25,7 @@ Here is some placeholder text for the service request payload for this Applicati | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | 1..1 | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md index e13da39f..4af8da1e 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Applications/BaRS-Applications/Applications/BaRS-APP2/Booking-Request-Payload.page.md @@ -25,11 +25,11 @@ This payload is used to support a booking workflow and contains all the required | Data Item | Implementation Guidance | Necessity | Cadinality UKCore | Example Value(s) | -|------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|1.0.0-beta ------------------------------------------------------------------------------------------| +|------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------|-------------------|------------------------------------------------------------------------------------------| | Bundle | https://simplifier.net/nhsbookingandreferrals/barsbundlemessage | | 1..1 | | | Bundle.id | This id is generated by the originating sender of the message, retained in subsequent messages.. | MUST | | 79120f41-a431-4f08-bcc5-1e67006fcae0 | | Bundle.meta | https://www.hl7.org/fhir/resource.html#Meta | MUST | 0..1 | | -| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 1..1 | 1.0.0-beta | +| Bundle.meta.versionId | This MUST be populated with the version of the Application the bundle complies with. The Receiver will read this to know whether they are capable of processing. | MUST | 0..1 | 1.0.0-beta | | Bundle.meta.profile | This MUST be populated with the structure definition for BaRSBundleMessage : 'https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage' - FIXED VALUE | MUST | 0..1 | https://fhir.nhs.uk/StructureDefinition/BARSBundleMessage | | Bundle.meta.lastUpdated | All resources MUST include 'lastUpdated' value, under the meta section which MUST be the same timestamp for each resource when created from new, but MUST be a later timestamp on updates to resources, if the content of a particular resource contains updated info for subsequent updates. Otherwise, maintain the timestamp originally sent. | MUST | 0..1 | 2023-03-08T12:01:08.4677672+00:00 | | Bundle.type | This MUST be populated with 'message' - FIXED VALUE | MUST | 1..1 | message | From f94506419d4212fdf4d475c9fe82dd7d72756d3c Mon Sep 17 00:00:00 2001 From: Carl De'ath <74620667+cda69@users.noreply.github.com> Date: Fri, 20 Jun 2025 15:14:58 +0100 Subject: [PATCH 3/5] CoreVersionUpdates --- .../Live-ImplementationGuide-BaRS/Home/Core/1.0.7/Index.page.md | 2 +- .../Live-ImplementationGuide-BaRS/Home/Core/1.3.0/Index.page.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) 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..11989599 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. 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. From 1b660bbfb8d8913c9ecccf445b526cf085eaac5c Mon Sep 17 00:00:00 2001 From: Carl De'ath <74620667+cda69@users.noreply.github.com> Date: Fri, 20 Jun 2025 15:56:30 +0100 Subject: [PATCH 4/5] Typos --- .../Applications/BaRS-APP1/How-does-it-work.page.md | 2 +- .../Applications/BaRS-APP3/How-does-it-work.page.md | 2 +- .../Home/Core/1.0.7/Index.page.md | 4 ++-- .../Standard-Pattern-Composite-Messages/Cancellation.page.md | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) 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 11989599..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 @@ -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/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 From edb06c1f9693b48e907b79d512e1f73804c80296 Mon Sep 17 00:00:00 2001 From: Carl De'ath <74620667+cda69@users.noreply.github.com> Date: Fri, 20 Jun 2025 15:57:35 +0100 Subject: [PATCH 5/5] UpdatedCancelFlowSequenceImage --- .../BaRS_StandardPattern_Cancellation_Find_Id.svg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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