Resource type: appointment

Description

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).

Elements

PathShortDefinitionComments
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)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).
identifierExternal Ids for this itemThis 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).
statusproposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error | checked-in | waitlistThe 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.
cancelationReasonThe coded reason for the appointment being cancelledThe coded reason for the appointment being cancelled. This is often used in reporting/billing/futher processing to determine if further actions are required, or specific fees apply.
serviceCategoryA broad categorization of the service that is to be performed during this appointmentA broad categorization of the service that is to be performed during this appointment.
serviceTypeThe specific service that is to be performed during this appointmentThe specific service that is to be performed during this appointment.For a provider to provider appointment the code "FOLLOWUP" may be appropriate, as this is expected to be discussing some patient that was seen in the past.
specialtyThe specialty of a practitioner that would be required to perform the service requested in this appointmentThe specialty of a practitioner that would be required to perform the service requested in this appointment.
appointmentTypeThe style of appointment or patient that has been booked in the slot (not service type)The style of appointment or patient that has been booked in the slot (not service type).
reasonCodeCoded reason this appointment is scheduledThe coded reason that this appointment is being scheduled. This is more clinical than administrative.
reasonReferenceReason the appointment is to take place (resource)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.
priorityUsed to make informed decisions if needing to re-prioritizeThe 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.
descriptionShown on a subject line in a meeting request, or appointment listThe 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.
supportingInformationAdditional information to support the appointmentAdditional information to support the appointment provided when making the appointment.
startWhen appointment is to take placeDate/Time that the appointment is to take place.
endWhen appointment is to concludeDate/Time that the appointment is to conclude.
minutesDurationCan be less than start/end (e.g. estimate)Number of minutes that the appointment is to take. This can be less than the duration between the start and end times. For example, where the actual time of appointment is only an estimate or if a 30 minute appointment is being requested, but any time would work. Also, if there is, for example, a planned 15 minute break in the middle of a long appointment, the duration may be 15 minutes less than the difference between the start and end.
slotThe slots that this appointment is fillingThe slots from the participants' schedules that will be filled by the appointment.
createdThe date that this appointment was initially createdThe 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.
commentAdditional commentsAdditional 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.
patientInstructionDetailed information and instructions for the patientWhile 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).
basedOnThe service request this appointment is allocated to assessThe service request this appointment is allocated to assess (e.g. incoming referral or procedure request).
participantParticipants involved in appointmentList of participants involved in the appointment.
participant.idUnique id for inter-element referencingUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
participant.extensionAdditional content defined by implementationsMay be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
participant.modifierExtensionExtensions that cannot be ignored even if unrecognizedMay be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions. Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
participant.typeRole of participant in the appointmentRole 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.
participant.actorPerson, Location/HealthcareService or DeviceA Person, Location/HealthcareService or Device that is participating in the appointment.
participant.requiredrequired | optional | information-onlyWhether this participant is required to be present at the meeting. This covers a use-case where two doctors need to meet to discuss the results for a specific patient, and the patient is not required to be present.
participant.statusaccepted | declined | tentative | needs-actionParticipation status of the actor.
participant.periodParticipation period of the actorParticipation period of the actor.
requestedPeriodPotential date/time interval(s) requested to allocate the appointment withinA set of date ranges (potentially including times) that the appointment is preferred to be scheduled within. The duration (usually in minutes) could also be provided to indicate the length of the appointment to fill and populate the start/end times for the actual allocated time. However in other situations the duration may be calculated by the scheduling system.This does not introduce a capacity for recurring appointments.

Scope and Usage

Appointment resources are used to provide information about a planned meeting that may be in the future or past. The resource only describes a single meeting, a series of repeating visits would require multiple appointment resources to be created for each instance. Examples include a scheduled surgery, a follow-up for a clinical visit, a scheduled conference call between clinicians to discuss a case, the reservation of a piece of diagnostic equipment for a particular use, etc. The visit scheduled by an appointment may be in person or remote (by phone, video conference, etc.) All that matters is that the time and usage of one or more individuals, locations and/or pieces of equipment is being fully or partially reserved for a designated period of time.

This definition takes the concepts of appointments in a clinical setting and also extends them to be relevant in the community healthcare space, and to ease exposure to other appointment / calendar standards widely used outside of healthcare.

The basic workflow to create an appointment

There are 2 typical workflows that occur with appointments

Boundaries and Relationships

Appointment Request/Response Pattern

When using a request-response style of appointment this is done using Appointment and AppointmentResponse resources.
The request is made in the form of an Appointment with a proposed or pending status, and the list of actors with a participation status of "needs-action".

Participants in the appointment respond with their acceptance (or not) to the appointment by creating AppointmentResponse resources.
Once all the participants have replied, then the Appointment resource is able to be updated with an overall status which collates the results of all the participants and presents the approved details of the appointment.

The participant type property can be used to represent a specific role that a practitioner is required to perform for the appointment. This could be specified without an actor when the actual practitioner is not known, and will be filled in closer to the scheduled time.
This property must be the same between the Appointment-participant and the AppointmentResponse so that the appropriate values can be allocated. If you need multiple actors of a specific type, then multiple participants with that type value are included on the appointment.

Appointment Statuses and Encounters

Appointments can be considered as Administrative only, and the Encounter is expected to have clinical implications.

In general, it is expected that appointments will result in the creation of an Encounter. The encounter is typically created when the service starts, not when the patient arrives. When the patient arrives, an appointment can be marked with a status of Arrived.

In an Emergency Room context, the appointment Resource is probably not appropriate to be used. In these cases an Encounter should be created.

The Appointment request pattern used is different from the order-response pattern used elsewhere in FHIR.
This is due to the close relationship to the iCal standard. Many non-clinical systems use generic non-health appointment systems which implement this standard, and the desire to integrate with the consumer who has no access to health based software is highly desirable.
The mappings to the iCal standard have been provided to guide implementation of gateways between FHIR servers and iCal systems.

Appointment Locations and Participation

The location of the appointment is to be defined by using a participant that references a Location or HealthcareService resource.
This permits the location to also have its availability checked via a schedule and any conflicts more easily managed.

Typical Status Transition Examples:

Typical flow of statuses for an appointment:

Activity Description Slot Appointment Appointment Response Encounter
The schedule is created/published
(Role: Scheduler)
freeBusyType = FREE
An appointment request is created after locating an available slot
(Role: Requester)
status = pending
participant.status = needs-action
The appointment request is processed and the slot status updated
(Role: Scheduler)
freeBusyType = BUSY-TENTATIVE
The appointment is accepted as described – by all participants
(Role: Participant(s))
participantStatus = accepted
The appointment is confirmed as accepted by all participants
(Role: Scheduler)
freeBusyType = BUSY status = booked
participant.status = accepted
Optional: Preparation for the appointment begins – could be preparing a room for the appointment, etc.
(Role: Participants/Admin)
status = planned (optional)
location.status = planned
The patient arrives for the appointment, often sitting in a waiting room
(Role: Admin)
status = arrived status = arrived
location.status = present
The practitioner and the patient meet and the provision of the service begins
(Role: Scheduler/Participant(s)/Admin)
status = fulfilled status = in-progress
The encounter concludes
(Role: Scheduler/Participant(s)/Admin)
status = finished

Flow for the rejection/cancellation of an appointment

Activity Description Slot Appointment Appointment Response
The schedule is created/published
(Role: Scheduler)
freeBusyType = FREE
An appointment request is created
(Role: Requester)
status = pending
participant.status = needs-action
The appointment request is processed and the slot status updated
(Role: Scheduler)
freeBusyType = BUSY-TENTATIVE
Participant declines the Appointment
(Role: Participant)
participantStatus = declined
The appointment is cancelled
(Role: Scheduler)
freeBusyType = FREE status = cancelled
participant.status = declined

Flow for re-negotiation:

Activity Description Slot Appointment Appointment Response
The schedule is created/published
(Role: Scheduler)
freeBusyType = FREE
An appointment is requested (e.g. with Brian and Peter)
(Role: Requester)
status = proposed
participant(Brian).status = needs-action
participant(Peter).status = needs-action
The schedule is updated to inform others of interest in the slot
(Role: Scheduler)
freeBusyType = BUSY-TENTATIVE
Brian accepts the appointment
(Role: Participant-Brian)
(Brian).participantStatus = accepted
Appointment is updated with Brian's status
(Role: Scheduler)
status = pending
participant(Brian).status = accepted
Peter suggests a new time
(Role: Participant-Peter)
(Peter).participantStatus = tentative
(with new time)
Appointment is updated with new time, and indicates that action is needed by both participants
(Role: Scheduler)
(new time details updated)
participant(Brian).status = needs-action
participant(Peter).status = needs-action
Brian accepts the appointment
(Role: Participant-Brian)
(Brian).participantStatus = accepted
Appointment updated
(Role: Scheduler)
participant(Brian).status = accepted

(Role: Participant-Peter)
(Peter).participantStatus = accepted
Appointment updated
(Role: Scheduler)
freeBusyType = BUSY status = booked
participant(Peter).status = accepted

Flow for a patient no-show:

Activity Description Slot Appointment Appointment Response Encounter
(from typical status flow) freeBusyType = BUSY status = booked
participant.status = accepted
Appointment is updated as a noshow
(Role: Scheduler/Admin)
status = noshow (no encounter created)

Flow for a patient waitlist:

Activity Description Appointment (inconvenient) Appointment (preferred)
An appointment is booked for an inconvenient time using a typical status flow status = booked
participant.status = accepted
Waitlist appointment created status = booked
participant.status = accepted
status = waitlist
requestedPeriod = (more convinient time period)
Patient notified of availability of a better slot status = booked status = proposed
participant.status = needs-action
Patient accepts better slot status = cancelled status = booked
participant.status = accepted

Notes:

[%stu-note%] Implementer feedback is sought on the values for Appointment.priority and how interoperable they are. Using an extension to record a CodeableConcept for named values may be tested at a future Connectathon.

Feedback here. [%end-note%]

Search Parameters

actorAny one of the individuals participating in the appointmentAppointment.participant.actor
appointment-typeThe style of appointment or patient that has been booked in the slot (not service type)Appointment.appointmentType
based-onThe service request this appointment is allocated to assessAppointment.basedOn.where(resolve() is ServiceRequest)
dateAppointment date/time.Appointment.start
identifierAn Identifier of the AppointmentAppointment.identifier
locationThis location is listed in the participants of the appointmentAppointment.participant.actor.where(resolve() is Location)
part-statusThe Participation status of the subject, or other participant on the appointment. Can be used to locate participants that have not responded to meeting requests.Appointment.participant.status
patientOne of the individuals of the appointment is this patientAppointment.participant.actor.where(resolve() is Patient)
practitionerOne of the individuals of the appointment is this practitionerAppointment.participant.actor.where(resolve() is Practitioner)
reason-codeCoded reason this appointment is scheduledAppointment.reasonCode
reason-referenceReason the appointment is to take place (resource)Appointment.reasonReference
service-categoryA broad categorization of the service that is to be performed during this appointmentAppointment.serviceCategory
service-typeThe specific service that is to be performed during this appointmentAppointment.serviceType
slotThe slots that this appointment is fillingAppointment.slot
specialtyThe specialty of a practitioner that would be required to perform the service requested in this appointmentAppointment.specialty
statusThe overall status of the appointmentAppointment.status
supporting-infoAdditional information to support the appointmentAppointment.supportingInformation

Extension Definitions

These are extension definitions for this resource defined by the spec