diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md index 703139e4..866c11b2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.1.6.page.md +++ b/guides/Live-ImplementationGuide-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 | non-breaking | +| 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 | non-breaking |
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md index 55e221a8..308d4a93 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/BaRS-Core/1.2.2-alpha.page.md +++ b/guides/Live-ImplementationGuide-BaRS/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 | non-breaking | +| 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 | non-breaking |
\ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.2.page.md b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.2.page.md index 830919a5..6c36554a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/Releases/Technical-Release-Notes/Implementation-Guide-Change-Log/1.8.2.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/About-BaRS/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.|
diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Cancel-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Cancel-Booking.page.md index dd1d7486..4f6da157 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Cancel-Booking.page.md +++ b/guides/Live-ImplementationGuide-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: ``` + +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}}. \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md index 151ffa42..006b4312 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Initial-Booking.page.md @@ -4,13 +4,12 @@ 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. @@ -18,7 +17,8 @@ The method for the initial booking of an appointment depends on the Application * Select a slot. * Send a Request to book an appointment in that slot - +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/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md index 78426856..f26f24a5 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-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/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Rebook-Methods.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Rebook-Methods.page.md index b4e2c46a..5cc7ff28 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Rebook-Methods.page.md +++ b/guides/Live-ImplementationGuide-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: ``` + +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/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Update-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Update-Existing-Booking.page.md index 4ac1160a..b2e5131f 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.1.6/Appointment-StandardPattern/Update-Existing-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/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 } ``` + +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/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Cancel-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Cancel-Booking.page.md index dacab321..75c3316a 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Cancel-Booking.page.md +++ b/guides/Live-ImplementationGuide-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: ``` + +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}}. \ No newline at end of file diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md index f6d1470c..1f316cfd 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Initial-Booking.page.md @@ -4,13 +4,12 @@ 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. @@ -18,7 +17,8 @@ The method for the initial booking of an appointment depends on the Application * Select a slot. * Send a Request to book an appointment in that slot - +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}}. + diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md index cf084667..806c54de 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Introduction.page.md @@ -10,27 +10,30 @@ topic: core-StandardPattern-appointment-Introduction-1.2.2 ## 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_2_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_2_0#post-/Appointment) endpoint and the [/Appointment/{id}](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0#put-/Appointment/-id-) endpoint | Capability | Endpoint | VERB | Description | |------------|-----------|-----|--------------| -| List | /DocumentReference | GET | Using the {{pagelink:core-StandardPattern-document-reference-Introduction-1.1.4, 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). | -| 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_2_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_2_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 | - -The specification for these operations can be found [here](https://digital.nhs.uk/developer/api-catalogue/booking-and-referral-fhir/v1_2_0) +| 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_2_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_2_0#get-/Slot) | +| 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_2_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_2_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 | + 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/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Rebook-Methods.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Rebook-Methods.page.md index cac52ccf..7b44b769 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Rebook-Methods.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/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: ``` + +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.2.2, text: here}}. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Update-Existing-Booking.page.md b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Update-Existing-Booking.page.md index ed85c8ba..10bab0f2 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Update-Existing-Booking.page.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Core/1.2.2/Appointment-StandardPattern/Update-Existing-Booking.page.md @@ -6,11 +6,11 @@ topic: core-StandardPattern-appointment-update-1.2.2 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,5 @@ Request Body } ``` + +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.2.2, text: here}}. diff --git a/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md b/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md index 68cb8e00..66bc6fcc 100644 --- a/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md +++ b/guides/Live-ImplementationGuide-BaRS/Home/Index.guide.md @@ -10,6 +10,7 @@ You can use this guide to support your analysis and define the scope of your sol * {{pagelink:about_bars, text:About BaRS and quick start guide}} * {{pagelink:design-core-1.1.6, text:End to end workflow }} * {{pagelink:Home/Applications/BaRS-Applications, text:BaRS Applications}} +* {{pagelink:core-StandardPattern-appointment-1.2.2, text: Standard Appointment Management (use-case agnostic)}} * {{pagelink:build-testing, text:Tooling}}