NHSDigital · cda69 · Mar 19, 2025 · Mar 19, 2025
diff --git a/...e-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md b/...e-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md
@@ -7,6 +7,7 @@ topic: TRN-Core-1.1.6
 | Change                                   | Description                            | Impact                          | 
 |------------------------------------------|----------------------------------------|---------------------------------|
 | Guidance on 'use-context' HTTP header updated         | 'use-context' HTTP header is only require on write actions - POST, PUT and PATCH | <mark style="background-color: LightGreen">non-breaking</mark>  |
+| Standard Pattern - Appointments updated        | Provided further guidance on how Appointments can be managed outside of BaRS Applications, in generic workflows. Added links to maintaining the Registry | <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 <br>
 <hr>
diff --git a/.../Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md b/.../Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md
@@ -7,6 +7,7 @@ topic: TRN-Core-1.2.2
 | Change                                   | Description                            | Impact                          | 
 |------------------------------------------|----------------------------------------|---------------------------------|
 | Guidance on 'use-context' HTTP header updated         | 'use-context' HTTP header is only require on write actions - POST, PUT and PATCH | <mark style="background-color: LightGreen">non-breaking</mark>  |
+| Standard Pattern - Appointments updated        | Provided further guidance on how Appointments can be managed outside of BaRS Applications, in generic workflows. Added links to maintaining the Registry | <mark style="background-color: LightGreen">non-breaking</mark>  |
 
 <br>
 <hr>
diff --git a/.../Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.2.page.md b/.../Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.2.page.md
@@ -7,6 +7,7 @@
 | Bug fixes and corrections  |There have been several bug fixes and corrections in the guide, these includes typos, broken links or corrections.|
 | Build>Test>TKW Scenarios updated  |Updated  TKW Scenarios to reflect Applications rather than use-cases.|
 | Build>Test>TKW Scenarios updated  |Added new test scenarios for Application 5 - TKW Receiver.|
+| Home Page - Link to Standard Appointment Management   |Added new link to Standard Appointment Management, on the Home page, to provide easier access to non use-case specific workflow functionality supported by BaRS.|
 <br>
 <hr>
 

diff --git a/...onGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Cancel-Booking.page.md b/...onGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Cancel-Booking.page.md
@@ -6,9 +6,9 @@ topic: core-StandardPattern-appointment-cancel-1.1.6
 
 To cancel an appointment:
 
-* Perform a GET operation using the id of the appointment to /Appointment[id]
+* Perform a GET operation using the id of the appointment to /Appointment/{id}
 * Set the Appointment.status value to "cancelled"
-* Perform a PUT operation using the id of the appointment to /Appointment[id]
+* Perform a PUT operation using the id of the appointment to /Appointment/{id} or POST against /$process-message, with a corresponding FHIR bundle (BaRS Applications only)
 
 resource returned:
 ```json
@@ -108,3 +108,5 @@ Request body:
 ```
 
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_Cancel.drawio.svg" ></img>
+
+Once the appointment is cancelled, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.1.6, text: here}}.
diff --git a/...nGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md b/...nGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md
@@ -4,21 +4,21 @@ topic: core-StandardPattern-appointment-booking-1.1.6
 
 ## Appointment Resource
 
-Below are examples of each of the described interactions. The appointment resource adheres to the [UKCore-Appointment](https://simplifier.net/HL7FHIRUKCoreR4/UKCore-Appointment) definitiion.
+Below are examples of each of the described interactions. The appointment resource adheres to the [UKCore-Appointment](https://simplifier.net/HL7FHIRUKCoreR4/UKCore-Appointment) definition.
 
-Any operations that modify an existing resource must perform a read before a write.  GET /Appointment/[id]
+Any operations that modify an existing resource must perform a read before a write.  GET /Appointment/{id}
 
 ### Book
-Book
-The method for the initial booking of an appointment depends on the Application specific guidance within BaRS. However a typical sequence of events is:
+The method for the initial booking of an appointment depends on the {{pagelink:Home/Applications/BaRS-Applications, text:Application}} specific guidance within BaRS. Alternatively, booking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment workflow, either way, the typical sequence of events is:
 
 * Select the service to book an appointment with. 
 * Confirm BaRS Capabilities.
 * Request Available slots.
 * Select a slot.
 * Send a Request to book an appointment in that slot
 
-
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_Book.drawio.svg" ></img>
 
+Once the appointment is created, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.1.6, text: here}}.
+
 
diff --git a/...tionGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md b/...tionGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md
@@ -10,27 +10,30 @@ topic: core-StandardPattern-appointment-Introduction-1.1.6
 
 ## Introduction 
 
-There are 4 capabilities that are required surrounding appointments. This section will provide information on how to meet them using the Appointment Resource.
+The [BaRS API](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir) suite can be used where there is no specific use-case supported by the {{pagelink:Home/Applications/BaRS-Applications, text:Applications}} to fulfil generic Appointment workflows. This section outlines the functionality supported, workflows involved and how these correspond with the [API Specification](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0). 
+
+This includes using {{pagelink:core-StandardPattern-document-reference-1.1.6, text: DocumentReference Standard Pattern}} to write pointers for Appointments to a central respository, commonly referred to as the Registry. 
+
+There are four functions that are required surrounding appointments. This section will provide information on how to meet them using the Appointment Resource.
 
 * The ability to book an appointment.
 * The ability to cancel an appointment.
 * The ability to update an appointment.
 * The ability to rebook an appointment.
 
-## interface
+## Interface
 
-The following table describes how the BaRS API accomodates these 4 capabilities using the /Appointment endpoint and the /Appointment/[id] endpoint
+The following table describes how the BaRS API accomodates these four capabilities using the [/Appointment](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#post-/Appointment) endpoint and the [/Appointment/{id}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) endpoint
 
 | Capability | Endpoint | VERB | Description |
 |------------|-----------|-----|--------------|
-| List   | /DocumentReference  | GET   | Using the {{pagelink:core-StandardPattern-document-reference-Introduction-1.1.6, text:DocumentReference}} pattern, a list of existing appointments for a patient can be viewed.  |
-| View   | /Appointment/[id]  | GET   | This action, using the id from the List capability, will allow that specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#get-/Appointment). |
+| List   | /DocumentReference  | GET   | Using the {{pagelink:core-StandardPattern-document-reference-Introduction-1.1.6, text:DocumentReference}} pattern, a list of existing appointments for a patient can be viewed with the central Registry.  |
+| View   | /Appointment/{id}  | GET   | This action, using the id from the List capability, will allow that specific Appointment Resource to be [retrieved](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#get-/Appointment) from the healthcare service who owns it. |
 | Get Slots   | /Slots   | GET   | Obtain a list of available booking slots from a specified receiving system using the [GET /Slots endpoint](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#get-/Slot)  |
-| Book | /Appointment or /$process-message | POST | This will invariably be a POST operation however the method for booking will depend on the BaRS Application/use case.|
-| [Cancel](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) | /Appointment[id] | PUT| The cancel of a booking will be setting the status of the appointment to "cancelled" |
-| [Update](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) | /Appointment[id] | PUT / PATCH| An update to an appointment will be a direct update to the existing resource |
-| Rebook | Composite of Cancel and then Book | Composite | requesting a new booking and then cancelling the existing booking will constitute a rebook |
+| Book | /Appointment or /$process-message | POST | This will be a POST operation, with a BaRS Application /$process-message is typically used, outside of supported use cases /Appointment is adopted.|
+| [Cancel](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) | /Appointment/{id} | PUT| The cancel of a booking will be setting the status of the appointment to "cancelled". Cancel is also possible using /$process-message |
+| [Update](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_1_0#put-/Appointment/-id-) | /Appointment/{id} | PUT / PATCH| An update to an appointment will be a direct update to the existing resource |
+| Rebook | Composite of Cancel and then Book | Composite | Requesting a new booking and then cancelling the existing one will constitute a rebook |
 
-The specification for these operations can be found [here](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0)
 
 In line with the BaRS standard all operations used to modify a resource must be preceded by a read of the resource by means of a [GET](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#get-/Appointment/-id-) operation.
diff --git a/...onGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Rebook-Methods.page.md b/...onGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Rebook-Methods.page.md
@@ -28,16 +28,15 @@ Use the cancel method described above.
 
 #### Process for rebook
 The method for the subsequent booking of an appointment depends on the Application specific guidance within BaRS. The only difference would be the Appointment Resource would include Appointment.replaces referencing the previous appointment for provenance.
-
-Using PUT:
+Alternatively, rebooking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment workflow, either way, the typical sequence of events using PUT or POST is:
 
 * Select the service to book an appointment with. 
 * Confirm BaRS Capabilities.
 * Request Available slots.
 * Select a slot.
-* Perform a GET operation using the id of the appointment to /Appointment[id]
+* Perform a GET operation using the id of the appointment to /Appointment/{id}
 * Set the Appointment.status value to "cancelled"
-* Perform a PUT operation using the id of the appointment to /Appointment[id]
+* Perform a PUT operation using the id of the appointment to /Appointment/{id} or POST against /$process-message, with a corresponding FHIR bundle (BaRS Applications only)
 
 Request Body
 
@@ -83,9 +82,9 @@ Using PATCH:
 * Confirm BaRS Capabilities.
 * Request Available slots.
 * Select a slot.
-* Perform a GET operation using the id of the appointment to /Appointment[id]
+* Perform a GET operation using the id of the appointment to /Appointment/{id}
 * Set the Appointment.status value to "cancelled"
-* Perform a PATCH operation using the id of the appointment to /Appointment[id]
+* Perform a PATCH operation using the id of the appointment to /Appointment/{id}
 
 ```json
 {
@@ -105,3 +104,5 @@ Using PATCH:
 ```
 
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_ReBook.drawio.svg" ></img>
+
+Once the appointment is rebooked, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.1.6, text: here}}.
diff --git a/...aRS/Home/Core/1.1.6/Appointment-StandardPattern/Update-Existing-Booking.page.md b/...aRS/Home/Core/1.1.6/Appointment-StandardPattern/Update-Existing-Booking.page.md
@@ -6,11 +6,11 @@ topic: core-StandardPattern-appointment-update-1.1.6
 
 To update an appointment:
 
-* Perofrm a GET operation using the id of the appointment to /Appointment[id]
+* Perform a GET operation using the id of the appointment to /Appointment/{id}
 * Ammend or append the resource as required.
-* Perform a PUT operation using the id of the appointment to /Appointment[id]
+* Perform a PUT operation using the id of the appointment to /Appointment/{id} or POST against /$process-message, with a corresponding FHIR bundle (BaRS Applications only)
 
-In this example a placeholder was created, and an update when the slot is selected. This is a hypothetical scenario.
+In this example a placeholder was created, and updated when the slot is selected. This is a hypothetical scenario.
 
 resource returned:
 ```json
@@ -70,3 +70,6 @@ Request Body
 }
 ```
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_Update.drawio.svg" ></img>
+
+Once the appointment is updated, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.1.6, text: here}}.
+
diff --git a/...onGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Cancel-Booking.page.md b/...onGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Cancel-Booking.page.md
@@ -6,9 +6,9 @@ topic: core-StandardPattern-appointment-cancel-1.2.2
 
 To cancel an appointment:
 
-* Perform a GET operation using the id of the appointment to /Appointment[id]
+* Perform a GET operation using the id of the appointment to /Appointment/{id}
 * Set the Appointment.status value to "cancelled"
-* Perform a PUT operation using the id of the appointment to /Appointment[id]
+* Perform a PUT operation using the id of the appointment to /Appointment/{id} or POST against /$process-message, with a corresponding FHIR bundle (BaRS Applications only)
 
 resource returned:
 ```json
@@ -108,3 +108,5 @@ Request body:
 ```
 
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_Cancel.drawio.svg" ></img>
+
+Once the appointment is cancelled, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.2.2, text: here}}.
diff --git a/...nGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md b/...nGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md
@@ -4,21 +4,21 @@ topic: core-StandardPattern-appointment-booking-1.2.2
 
 ## Appointment Resource
 
-Below are examples of each of the described interactions. The appointment resource adheres to the [UKCore-Appointment](https://simplifier.net/HL7FHIRUKCoreR4/UKCore-Appointment) definitiion.
+Below are examples of each of the described interactions. The appointment resource adheres to the [UKCore-Appointment](https://simplifier.net/HL7FHIRUKCoreR4/UKCore-Appointment) definition.
 
-Any operations that modify an existing resource must perform a read before a write.  GET /Appointment/[id]
+Any operations that modify an existing resource must perform a read before a write.  GET /Appointment/{id}
 
 ### Book
-Book
-The method for the initial booking of an appointment depends on the Application specific guidance within BaRS. However a typical sequence of events is:
+The method for the initial booking of an appointment depends on the {{pagelink:Home/Applications/BaRS-Applications, text:Application}} specific guidance within BaRS. Alternatively, booking an appointment can be used outside of use-cases supported by a BaRS Application, to fulfil a generic Appointment workflow, either way, the typical sequence of events is:
 
 * Select the service to book an appointment with. 
 * Confirm BaRS Capabilities.
 * Request Available slots.
 * Select a slot.
 * Send a Request to book an appointment in that slot
 
-
 <img src="https://raw.githubusercontent.com/NHSDigital/NHSDigital-FHIR-BookingAndReferrals/main/BaRS-Images/SequenceDiagrams/BaRS_Foundation_Book.drawio.svg" ></img>
 
+Once the appointment is created, the Receiver is responsible for managing the pointer in the central Registry, as described {{pagelink:core-StandardPattern-document-reference-1.2.2, text: here}}.
+