## New Appointment **New Appointment** interaction should be implemented by defined FHIR messaging context in HL7 FHIR. It supports booking an appointment based on the the ServiceRequest initiated by the requester system to an eReferral server. 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 booking an appointment among patient(s) and practitioner(s),for a specific date/time.These are sent via a /Bundle POST to an endpoint hosted by the eReferral server. ### Interaction Diagrams The following diagram illustrates the high-level interaction for booking an appointment. {{render:eReferral-Ontario/NewAppointment-jpg}} **Actor:** FHIR ServiceRequest receiving Application **Role:** Send Appointment bundle based on a known identifier-ServiceRequest ID. ### Appointment Operation This operation supports an HTTP POST specifying the allowed identifiers( e.g. ServiceRequest identifiers) of a single patient instance for FHIR recieving application to book an appointment **Trigger Events** 1. Before an appointment can be made, the address/endpoint details of the resource that we want to schedule an appointment with must be determined. 2. When an FHIR referral recieving application initiates the request for appointment for a patient, it invokes a 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|POST|POST|[base]/Appointment?|[Appointment](https://simplifier.net/guide/eReferraldraftiGuide/Appointment)| | The interaction summary table below lists the HTTP status codes that may be returned for the POST operations for appointment booking. |Interaction|Content-Type|Body|Location|Versioning|HTTP Status Codes|Comments |- |POST|R|R: Appointment|Bundle|N/A|200,400,500| | **Expected Behavior** Referral receiving System SHALL send the appointment bundle containing Appointment resource with relevant ServiceRequest ID provided by the FHIR requesting 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 POST operation. ** New Appointment Request** **eReferral Receiving Systems** will submit a FHIR Bundle containing a 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 a response bundle, and the eReferral will be viewable in the eReferral Server system. When an appointment is required, a requester creates new Appointment resource with the Appointment.status="proposed".All included participants should have the status="needs-action" to allow filtering and displaying appointments to user-participants for accepting or rejecting new 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. POST to the target service's /Endpoint (which is specified in the/HealthcareService) ***'POST [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**