Appointment
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).
- Schema
- Usage
- Relationships
- Referenced By
Elements
Name | Required | Type | Description |
---|---|---|---|
identifier | Identifier[] | External Ids for this item DetailsThis 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). | |
status | ✓ | code | proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error | checked-in | waitlist DetailsThe 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. |
cancelationReason | CodeableConcept | The coded reason for the appointment being cancelled DetailsThe 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. | |
serviceCategory | CodeableConcept[] | A broad categorization of the service that is to be performed during this appointment DetailsA broad categorization of the service that is to be performed during this appointment. | |
serviceType | CodeableConcept[] | The specific service that is to be performed during this appointment DetailsThe 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. | |
specialty | CodeableConcept[] | The specialty of a practitioner that would be required to perform the service requested in this appointment DetailsThe specialty of a practitioner that would be required to perform the service requested in this appointment. | |
appointmentType | CodeableConcept | The style of appointment or patient that has been booked in the slot (not service type) DetailsThe style of appointment or patient that has been booked in the slot (not service type). | |
reasonCode | CodeableConcept[] | Coded reason this appointment is scheduled DetailsThe coded reason that this appointment is being scheduled. This is more clinical than administrative. | |
reasonReference | Reference< Condition | Procedure | Observation | ImmunizationRecommendation >[] | Reason the appointment is to take place (resource) DetailsReason 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. | |
priority | unsignedInt | Used to make informed decisions if needing to re-prioritize DetailsThe 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. | |
description | string | Shown on a subject line in a meeting request, or appointment list DetailsThe 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. | |
supportingInformation | Reference<Resource>[] | Additional information to support the appointment DetailsAdditional information to support the appointment provided when making the appointment. | |
start | instant | When appointment is to take place DetailsDate/Time that the appointment is to take place. | |
end | instant | When appointment is to conclude DetailsDate/Time that the appointment is to conclude. | |
minutesDuration | positiveInt | Can be less than start/end (e.g. estimate) DetailsNumber 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. | |
slot | Reference<Slot>[] | The slots that this appointment is filling DetailsThe slots from the participants' schedules that will be filled by the appointment. | |
created | dateTime | The date that this appointment was initially created DetailsThe 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. | |
comment | string | Additional comments DetailsAdditional 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. | |
patientInstruction | string | Detailed information and instructions for the patient DetailsWhile 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). | |
basedOn | Reference<ServiceRequest>[] | The service request this appointment is allocated to assess DetailsThe service request this appointment is allocated to assess (e.g. incoming referral or procedure request). | |
participant | ✓ | Appointmentparticipant[] | Participants involved in appointment DetailsList of participants involved in the appointment. |
id | string | Unique id for inter-element referencing DetailsUnique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | |
extension | Extension[] | Additional content defined by implementations DetailsMay 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. | |
modifierExtension | Extension[] | Extensions that cannot be ignored even if unrecognized DetailsMay 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. | |
type | CodeableConcept[] | Role of participant in the appointment DetailsRole 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. | |
actor | Reference< Patient | Practitioner | PractitionerRole | RelatedPerson | Device | HealthcareService | Location > | Person, Location/HealthcareService or Device DetailsA Person, Location/HealthcareService or Device that is participating in the appointment. | |
required | code | required | optional | information-only DetailsWhether 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. | |
status | ✓ | code | accepted | declined | tentative | needs-action DetailsParticipation status of the actor. |
period | Period | Participation period of the actor DetailsParticipation period of the actor. | |
requestedPeriod | Period[] | Potential date/time interval(s) requested to allocate the appointment within DetailsA 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. |
Search Parameters
Name | Type | Description | Expression |
---|---|---|---|
actor | reference | Any one of the individuals participating in the appointment | Appointment.participant.actor |
appointment-type | token | The style of appointment or patient that has been booked in the slot (not service type) | Appointment.appointmentType |
based-on | reference | The service request this appointment is allocated to assess | Appointment.basedOn |
date | date | Appointment date/time. | Appointment.start |
identifier | token | An Identifier of the Appointment | Appointment.identifier |
location | reference | This location is listed in the participants of the appointment | Appointment.participant.actor.where(resolve() is Location) |
part-status | token | The 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 |
patient | reference | One of the individuals of the appointment is this patient | Appointment.participant.actor.where(resolve() is Patient) |
practitioner | reference | One of the individuals of the appointment is this practitioner | Appointment.participant.actor.where(resolve() is Practitioner) |
reason-code | token | Coded reason this appointment is scheduled | Appointment.reasonCode |
reason-reference | reference | Reason the appointment is to take place (resource) | Appointment.reasonReference |
service-category | token | A broad categorization of the service that is to be performed during this appointment | Appointment.serviceCategory |
service-type | token | The specific service that is to be performed during this appointment | Appointment.serviceType |
slot | reference | The slots that this appointment is filling | Appointment.slot |
specialty | token | The specialty of a practitioner that would be required to perform the service requested in this appointment | Appointment.specialty |
status | token | The overall status of the appointment | Appointment.status |
supporting-info | reference | Additional information to support the appointment | Appointment.supportingInformation |
Inherited Elements
Name | Required | Type | Description |
---|---|---|---|
id | string | Logical id of this artifact DetailsThe logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes. The only time that a resource does not have an id is when it is being submitted to the server using a create operation. | |
meta | Meta | Metadata about the resource DetailsThe metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource. | |
implicitRules | uri | A set of rules under which this content was created DetailsA reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc. Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc. | |
language | code | Language of the resource content DetailsThe base language in which the resource is written. Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute). | |
text | Narrative | Text summary of the resource, for human interpretation DetailsA human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later. | |
contained | Resource[] | Contained, inline Resources DetailsThese resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope. This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels. | |
extension | Extension[] | Additional content defined by implementations DetailsMay be used to represent additional information that is not part of the basic definition of the resource. 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. | |
modifierExtension | Extension[] | Extensions that cannot be ignored DetailsMay be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it 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 is allowed to 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. |
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
- Discovery/Addressing
Before an appointment can be made, the address/endpoint details of the resource that we want to schedule an appointment with must be determined. This is often based on the healthcare service type and any formatting information which indicates how to make the request. This is typically handled via the Schedule resource.
- Checking Availability on the Schedule (optional)
This optional step permits the checking of any existing available times (Slot resources associated with a selected Schedule) that can be booked against. Just because a time is indicated as available doesn't guarantee that an appointment can be made. The booking system that is going to process the request may make other qualifying decisions to determine if the appointment can be made, such as permissions, assessments, availability of other resources, etc.
This step is optional, as the creation of the appointment is never a guaranteed action. But by performing this availability check, you can increase the chances of making a successful booking.
- Making the Appointment Request
When an appointment is required, a requester creates new Appointment resource with the Appointment.status="proposed".
All included participants (optional or mandatory) 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". - Replying to the request
The reply process is simply performed by the person/system handing the requests, updating the participant statuses on the appointment as needed. If there are multiple systems involved, then these will create AppointmentResponse entries with the desired statuses.
Once all participants have their participation status created/updated (and the main system marking the appointment participant records with the AppointmentResponse statuses) then the overall status of the Appointment is updated.
- Checking the overall status (Requester)
The requester (organizer) of the appointment checks for the overall status of the appointment (and appointment responses, where applicable) using FHIR pub-sub techniques.
Where the participant statuses indicate that a re-scheduling is required, then the process may start again, with other systems replying to a new set of times.
- Waitlisting the Appointment (optional)
This optional step permits creating a waitlisted appointment. This could occur if an appointment needs to be booked into a time that is not ideal for the patient due to lack of available time slots. In this workflow, there would be two appointments, the booked appointment in the time slot that is currently available, and the waitlisted appointment with a requestedPeriod spanning the time that the patient would prefer if new slots become available.
If new time slots become available during the requestedPeriod, the scheduling system, or staff at the scheduling organization, can notify the patient that a new time slot is available. If the patient chooses, the waitlisted appointment would then be booked into that specific slot, and the previously booked appointment would be canceled. The specific business process for notifying patients of new availability is not specified, and is up to the implementing system to determine.
There are 2 typical workflows that occur with appointments
- Outlook Style - Community
These types of requests are typically handled by selecting a specific time from a list of available slots, then making the request for that timeslot.
- Hospital Scheduling - Clinical
Clinical scheduling is often far more complex in its requirements and processing. Often this involves checking multiple availabilities across multiple systems and timing with other internal systems, not just those exposed by the Slot resources.
Consideration should be given to situations where scheduling needs to be handled in more of a queue-like process.
Implementation Note: Note: This type of clinical appointment scheduling has not been specifically covered with this definition of the Appointment resource (and other related resources), however if you would like to contribute to the modification of this resource to cover these use cases, please contact the HL7 Patient Administration work-group.
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.