## Update Appointment **Update Appointment** interaction should be implemented by defined FHIR messaging context in HL7 FHIR. It supports updating the booked appointment based on the the ServiceRequest initiated by the receiving system. In FHIR messaging, a "request message" is sent from a source application to a destination application when an event happens. Events mostly correspond to things that happen in the real world. The request message consists of a Bundle identified by the type "message", with the first resource in the bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the bundle depend on the type of the request. The events supported in this specification , along with the resources that are included in them are mentioned in MessageHeader. The destination application processes the request and returns one or more response messages which are also a bundle of resources identified by the type "message", with the first resource in each bundle being a **MessageHeader resource** with a response section that reports the outcome of processing the message and any additional response resources required. ### Scope These transactions involves updating an booked appointment among patient(s) and practitioner(s),for a specific date/time.These are sent via a /Bundle PUT to an endpoint hosted by the eReferral server. ### Interaction Diagrams The following diagram illustrates the high-level interaction for updating an appointment. {{render:eReferral-Ontario/UpdatedAppointment-jpg}} **Actor:** FHIR ServiceRequest Receiving Application **Role:** Send updated appointment bundle based on a known identifier -ServiceRequest ID **Actor:** FHIR Receiving Application **Role:** Returns an HTTP Success 200 response ### Update Appointment Operation This operation supports an HTTP PUT specifying the allowed identifiers( e.g. ServiceRequest identifiers) of a single patient instance for FHIR receiving application to update an booked appointment. **Trigger Events** 1. Before an appointment can be updated, the address/endpoint details of the resource that we want to update an appointment with must be determined. 2.When an FHIR referral recieving application initiates the request for update appointment for a patient, it invokes an appointment request and send it to the sender system. **Summary of Supported Operations** The table below shows the allowed transactions for each profile and how they support FHIR endpoints, resources and their corresponding HTTP operations (https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html): |Resource | Transaction | HTTP Operations|URL|Request Body Resource|Response Body Resource |- |Appointment|PUT|PUT|[base]/Appointment?|[Update Appointment](https://simplifier.net/guide/eReferraldraftiGuide/Appointment)| | The interaction summary table below lists the HTTP status codes that may be returned for the PUT operations for Appointment booking. |Interaction|Content-Type|Body|Location|Versioning|HTTP Status Codes|Comments |- |PUT|R|R: Appointment|Bundle|N/A|200,400,500| | **Expected Behavior** Referral receiving System SHALL send the update appointment bundle containing Appointment resource with relevant ServiceRequest ID provided by the FHIR requesting/receiving application. eReferral receiving system reply process is simply performed by the person/system handling the requests, updating the participant statuses on the appointment as needed, or an http error if an internal error occurs. ### Resource Profiles This eReferral FHIR operation is based on the HL7 FHIR STU R4 PUT operation. ** Update Appointment Request** **eReferral Receiving Systems** will submit a FHIR Bundle containing an Appointment + other relevant resources to the endpoint of a pre-selected target HealthcareService, hosted by an eReferral server. On successful submission, the sending system will receive an HTTP response When an appointment is required to be updated, receiving system creates Update Appointment resource with the Appointment.status="updated".All included participants should have the status="needs-action" to allow filtering and displaying appointments to user-participants for accepting or rejecting Update and updated requests. Based on internal system business rules, certain statuses may be automatically updated, for example: "reject because the requested participant is on vacation" or "this type of user is not allowed to request those specific appointments". **Sending an Appointment has following key components: 1. Build a /Bundle including the / Appointment and other relevant resources 2. PUT to the target service's /Endpoint (which is specified in the/HealthcareService) ***'PUT [endpoint.address]'*** **Appointment Response** The reply process is simply performed by the person/system handing the requests, updating the participant statuses on the appointment as needed. **Examples**