A booking of a healthcare event among patient(s), practitioner(s), related person(s) and/or device(s) for a specific date/time. This may result in one or more Encounter(s).

This records identifiers associated with this appointment concern that are defined by business processes and/or used to refer to it when a direct URL reference to the resource itself is not appropriate (e.g. in CDA documents, or in written / printed documentation).

The overall status of the Appointment. Each of the participants has their own participation status which indicates their involvement in the process, however this status indicates the shared status.

If the Appointment's status is "cancelled" then all participants are expected to have their calendars released for the appointment period, and as such any Slots that were marked as BUSY can be re-set to FREE.

This element is labeled as a modifier because the status contains the code entered-in-error that mark the Appointment as not currently valid.

A broad categorisation of the service that is to be performed during this appointment.

The specific service that is to be performed during this appointment.

The specialty of a practitioner that would be required to perform the service requested in this appointment.

The style of appointment or patient that has been booked in the slot (not service type).

The reason that this appointment is being scheduled. This is more clinical than administrative.

Reason the appointment has been scheduled to take place, as specified using information from another resource. When the patient arrives and the encounter begins it may be used as the admission diagnosis. The indication will typically be a Condition (with other resources referenced in the evidence.detail), or a Procedure.

The priority of the appointment. Can be used to make informed decisions if needing to re-prioritize appointments. (The iCal Standard specifies 0 as undefined, 1 as highest, 9 as lowest priority).

Seeking implementer feedback on this property and how interoperable it is.

Using an extension to record a codeableconcept for named values may be tested at a future connectathon.

The brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment field.

Additional information to support the appointment provided when making the appointment.

Date/Time that the appointment is to take place.

Date/Time that the appointment is to conclude.

Number of minutes that the appointment is to take. This can be less than the duration between the start and end times (where actual time of appointment is only an estimate or is a planned appointment request).

The slots from the participants' schedules that will be filled by the appointment.

The date that this appointment was initially created. This could be different to the meta.lastModified value on the initial entry, as this could have been before the resource was created on the FHIR server, and should remain unchanged over the lifespan of the appointment.

This property is required for many use cases where the age of an appointment is considered in processing workflows for scheduling and billing of appointments.

Additional comments about the appointment.

Additional text to aid in facilitating the appointment. For instance, a comment might be, "patient should proceed immediately to infusion room upon arrival"

Where this is a planned appointment and the start/end dates are not set then this field can be used to provide additional guidance on the details of the appointment request, including any restrictions on when to book it.

While Appointment.comment contains information for internal use, Appointment.patientInstructions is used to capture patient facing information about the Appointment (e.g. please bring your referral or fast from 8pm night before).

The referral request this appointment is allocated to assess (incoming referral).

List of participants involved in the appointment.

Role of participant in the appointment.

The role of the participant can be used to declare what the actor will be doing in the scope of this appointment.

If the actor is not specified, then it is expected that the actor will be filled in at a later stage of planning.

This value SHALL be the same when creating an AppointmentResponse so that they can be matched, and subsequently update the Appointment.

A Person, Location/HealthcareService or Device that is participating in the appointment.

Is this participant required to be present at the meeting. This covers a use-case where 2 doctors need to meet to discuss the results for a specific patient, and the patient is not required to be present.

Participation status of the actor.

A set of date ranges (potentially including times) that the appointment is preferred to be scheduled within. When using these values, the minutes duration should be provided to indicate the length of the appointment to fill and populate the start/end times for the actual allocated time.

This does not introduce a capacity for recurring appointments.