Appointment
Introduction
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 (where the patient is a subject, but not a participant), 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 handling 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.
[%impl-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. [%end-note%]
Recurring Appointments
There are 2 main forms of recurring appointments recognized by FHIR:
- (recurring) Regular meetings which occur based on a template, usually pre-allocated with a well defined frequency and a set purpose
- (series) An appointment that has a series of follow up appointments which are more adhoc/irregular in nature
This type does not typically pre-allocate bookings, but are re-booked each time based on loose guidance. These could also have different services on each re-booking (potentially via a protocol)
Recurring (template/pattern)
The recurring appointment uses the recurrenceTemplate property to define when all of the occurrences of the appointment should occur. This value only exists on the original booking for the appointment, for all the subsequent occurrences the originatingAppointment refers back to original for the template details.
Accepting a recurring appointment can be done either as accepting the entire series (using AppointmentResponse.recurring=true) or can accept each occurrence individually (using AppointmentResponse.recurring=false along with AppointmentResponse.occurrenceDate or AppointmentResponse.recurrenceId to indicate which repetition specifically)
Note that in the template the timezone property defines which timezone the start/end times apply. This is required as the time properties only have the offset (+10), and not the zone (Australia/Melbourne), which means that they cannot be used by the template to generate 9am every Wednesday all year (as Melbourne changes to +11 during daylight saving time).
Series (simple chain)
A series appointment has no template information, and thus don't use the recurrenceTemplate property. Often when first booked it is likely not known that it will become a series of bookings, and only on conclusion of the encounter it is decided to follow-up and then book a new appointment (or even book it later on) and relate the new booking to the previous in the series through the previousAppointment property. This style of recurring appointment likely won't use the originatingAppointment property either.
As each appointment in a series is a separate appointment and booked as needed, the acceptance of requests here is just as it would be normally if they didn't have a sequence.
As each occurrence is booked independently there are no specific issues with timezones, as each instance exactly defines when it occurs (there is no template).
[%stu-note dstu2%] We are seeking input from the implementer community on the recurring appointment functionality and specifically if there is a need for a "recur forever" or similar flag.
Feedback here. [%end-note%]
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.
The Appointment resource represents an intention to perform a service. An Appointment does NOT represent an authorization. Authorization is typically provided via a ServiceRequest when required. Details about the fulfillment of the appointment are handled by the Encounter resource.
Appointment Statuses and Encounters
Appointments can be considered as Administrative only, and the Encounter is expected to have clinical implications. Both resources align with the Clinical Workflow Process Life Cycle pattern.
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.
Notes
Typical Status Transition Examples:
Typical flow of statuses for an appointment:
| Activity Description | Slot | Appointment | Appointment Response | Encounter |
|---|---|---|---|---|
| The schedule is created/published <br/> (Role: Scheduler) | freeBusyType = FREE | |||
| An appointment request is created after locating an available slot <br/> (Role: Requester) | status = pending <br/> participant.status = needs-action | |||
| The appointment request is processed and the slot status updated <br/> (Role: Scheduler) | freeBusyType = BUSY-TENTATIVE | |||
| The appointment is accepted as described - by all participants <br/> (Role: Participant(s)) | participantStatus = accepted | |||
| The appointment is confirmed as accepted by all participants <br/> (Role: Scheduler) | freeBusyType = BUSY | status = booked <br/> participant.status = accepted | ||
| Optional: Preparation for the appointment begins - could be preparing a room for the appointment, etc. <br/> (Role: Participants/Admin) | status = planned (optional) <br/> location.status = planned | |||
| The patient arrives for the appointment, often sitting in a waiting room <br/> (Role: Admin) | status = arrived | status = in-progress | ||
| subjectStatus = arrived | ||||
| location.status = active | ||||
| The practitioner and the patient meet and the provision of the service begins/occurs <br/> (Role: Participant(s)/Admin) | status = fulfilled | status = in-progress <br/> subjectStatus = receiving-care | ||
| The care provision concludes and the patient leaves, some administrative and/or cleanup actions take place <br/> (Role: Practitioner(s)/Admin/Billing - excluding patient) | status = discharged <br/> subjectStatus = departed | |||
| The encounter concludes, all paperwork has been completed and the encounter can be closed off <br/> (Role: Practitioner(s)/Admin) | status = finished <br/> location.status = completed |
Flow for the rejection/cancellation of an appointment
| Activity Description | Slot | Appointment | Appointment Response |
|---|---|---|---|
| The schedule is created/published <br/> (Role: Scheduler) | freeBusyType = FREE | ||
| An appointment request is created <br/> (Role: Requester) | status = pending <br/> participant.status = needs-action | ||
| The appointment request is processed and the slot status updated <br/> (Role: Scheduler) | freeBusyType = BUSY-TENTATIVE | ||
| Participant declines the Appointment <br/> (Role: Participant) | participantStatus = declined | ||
| The appointment is cancelled (typically the cancellationDate will be populated, along with a cancellation reason if applicable, this is often selected by the scheduler as could be used by the billing engine) <br/> (Role: Scheduler) | freeBusyType = FREE | status = cancelled | |
| cancellationDate = (date of cancellation) | |||
| cancellationReason = (cancellation reason if applicable) | |||
| participant.status = declined |
Flow for re-negotiation:
| Activity Description | Slot | Appointment | Appointment Response |
|---|---|---|---|
| The schedule is created/published <br/> (Role: Scheduler) | freeBusyType = FREE | ||
| An appointment is requested (e.g. with Brian and Peter) <br/> (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 <br/> (Role: Scheduler) | freeBusyType = BUSY-TENTATIVE | ||
| Brian accepts the appointment <br/> (Role: Participant-Brian) | (Brian).participantStatus = accepted | ||
| Appointment is updated with Brian's status <br/> (Role: Scheduler) | status = pending <br/> participant(Brian).status = accepted | ||
| Peter suggests a new time <br/> (Role: Participant-Peter) | (Peter).participantStatus = tentative <br/> (with new time) | ||
| Appointment is updated with new time, and indicates that action is needed by both participants <br/> (Role: Scheduler) | (new time details updated) | ||
| participant(Brian).status = needs-action | |||
| participant(Peter).status = needs-action | |||
| Brian accepts the appointment <br/> (Role: Participant-Brian) | (Brian).participantStatus = accepted | ||
| Appointment updated <br/> (Role: Scheduler) | participant(Brian).status = accepted | ||
| <br/> (Role: Participant-Peter) | (Peter).participantStatus = accepted | ||
| Appointment updated <br/> (Role: Scheduler) | freeBusyType = BUSY | status = booked <br/> 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 <br/> participant.status = accepted | ||
| Appointment is updated as a noshow <br/> (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 <br/> participant.status = accepted | |
| Waitlist appointment created | status = booked <br/> participant.status = accepted | status = waitlist <br/> requestedPeriod = (more convenient time period) |
| Patient notified of availability of a better slot | status = booked | status = proposed <br/> participant.status = needs-action |
| Patient accepts better slot | status = cancelled | status = booked <br/> participant.status = accepted |
Notes:
- Placer/Filler (HL7 V2)
The appointment information is effectively the same between the filler and placer, and given the nature of the FHIR resource, there is only a single resource for both purposes. The placer is the actor that performs the PUT or POST operation on the resource, and the filler is the actor that receives these resource messages and processes the information and makes a decision if the appointment can be used. - Terminology - ServiceCategory, ServiceType and Specialty
The 3 core clinical terminologies associated with the appointment may have relationships with each other through the terminology server, but not these might not be visible in the actual appointment resource or profile. - Interaction with other Standards
The strong desire is that implementers of this resource should consider providing this resource in the iCalendar format as an alternative representation. Many 3rd party applications and component providers have parsers and user interface controls to display this information. This may lower the entry point to integrate outside the health-care specific applications, and into the consumer space. This would permit the easier creation of a mobile application that creates appointments in the devices native calendar.
The iCalendar specification can be found at http://www.ietf.org/rfc/rfc2445.txt.
Insurance for Appointments
When appointments are scheduled, often insurance information is collected. This may be a single coverage, or multiple coverages. To document this preliminary coverage information, Appointment.account may be used to reference an Account which would contain the ordered list of Coverages that are expected to apply to the Appointment.
Payment Authorization for Appointments
Prior authorization for an Appointment would involve a Claim (to submit the prior authorization request) and a ClaimResponse (to receive the prior authorization approval). In this case, the Claim and ClaimResponse associated with the prior auth would reference the planned Appointment that was authorized. How the association between the prior authorization and the authorized services is described may vary by jurisdiction (e.g., Da Vinci PAS in the US).
[%stu-note dstu%] 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.
Implementer feedback is also sought to clarify desired relationship linkages between ServiceCategory, ServiceType and Specialty, along with how they have approached the definition.
Feedback here. [%end-note%]
StructureDefinition
Elements (Simplified)
- Appointment [0..*]: - 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)
- Appointment.identifier [0..*]: Identifier External Ids for this item
- Appointment.status [1..1]: code required:appointmentstatus proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error | checked-in | waitlist
- Appointment.cancellationReason [0..1]: CodeableConcept example:appointment-cancellation-reason The coded reason for the appointment being cancelled
- Appointment.class [0..*]: CodeableConcept preferred:EncounterClass Classification when becoming an encounter
- Appointment.serviceCategory [0..*]: CodeableConcept example:service-category A broad categorization of the service that is to be performed during this appointment
- Appointment.serviceType [0..*]: CodeableReference example:service-type The specific service that is to be performed during this appointment
- Appointment.specialty [0..*]: CodeableConcept example:c80-practice-codes The specialty of a practitioner that would be required to perform the service requested in this appointment
- Appointment.appointmentType [0..1]: CodeableConcept preferred:v2-0276 The style of appointment or patient that has been booked in the slot (not service type)
- Appointment.reason [0..*]: CodeableReference preferred:encounter-reason Reason this appointment is scheduled
- Appointment.priority [0..1]: CodeableConcept example:v3-ActPriority Used to make informed decisions if needing to re-prioritize
- Appointment.description [0..1]: string Shown on a subject line in a meeting request, or appointment list
- Appointment.replaces [0..*]: Reference(Appointment) Appointment replaced by this Appointment
- Appointment.virtualService [0..*]: VirtualServiceDetail Connection details of a virtual service (e.g. conference call)
- Appointment.supportingInformation [0..*]: Reference(Resource) Additional information to support the appointment
- Appointment.previousAppointment [0..1]: Reference(Appointment) The previous appointment in a series
- Appointment.originatingAppointment [0..1]: Reference(Appointment) The originating appointment in a recurring set of appointments
- Appointment.start [0..1]: instant When appointment is to take place
- Appointment.end [0..1]: instant When appointment is to conclude
- Appointment.minutesDuration [0..1]: positiveInt Can be less than start/end (e.g. estimate)
- Appointment.requestedPeriod [0..*]: Period Potential date/time interval(s) requested to allocate the appointment within
- Appointment.slot [0..*]: Reference(Slot) The slots that this appointment is filling
- Appointment.account [0..*]: Reference(Account) The set of accounts that may be used for billing for this Appointment
- Appointment.created [0..1]: dateTime The date that this appointment was initially created
- Appointment.cancellationDate [0..1]: dateTime When the appointment was cancelled
- Appointment.note [0..*]: Annotation Additional comments
- Appointment.patientInstruction [0..*]: CodeableReference Detailed information and instructions for the patient
- Appointment.basedOn [0..*]: [Reference(CarePlan](/Reference(CarePlan), DeviceRequest, MedicationRequest, ServiceRequest, RequestOrchestration, NutritionOrder, VisionPrescription)) The request this appointment is allocated to assess
- Appointment.subject [0..1]: [Reference(Patient](/Reference(Patient), Group)) The patient or group associated with the appointment
- Appointment.participant [1..*]: BackboneElement Participants involved in appointment
- Appointment.participant.type [0..*]: CodeableConcept extensible:encounter-participant-type Role of participant in the appointment
- Appointment.participant.period [0..1]: Period Participation period of the actor
- Appointment.participant.actor [0..1]: [Reference(Patient](/Reference(Patient), Group, Practitioner, PractitionerRole, CareTeam, RelatedPerson, Device, HealthcareService, Location)) The individual, device, location, or service participating in the appointment
- Appointment.participant.required [0..1]: boolean The participant is required to attend (optional when false)
- Appointment.participant.status [1..1]: code required:participationstatus accepted | declined | tentative | needs-action
- Appointment.recurrenceId [0..1]: positiveInt The sequence number in the recurrence
- Appointment.occurrenceChanged [0..1]: boolean Indicates that this appointment varies from a recurrence pattern
- Appointment.recurrenceTemplate [0..*]: BackboneElement Details of the recurrence pattern/template used to generate occurrences
- Appointment.recurrenceTemplate.timezone [0..1]: CodeableConcept required:timezones The timezone of the occurrences
- Appointment.recurrenceTemplate.recurrenceType [1..1]: CodeableConcept preferred:appointment-recurrrence-type The frequency of the recurrence
- Appointment.recurrenceTemplate.lastOccurrenceDate [0..1]: date The date when the recurrence should end
- Appointment.recurrenceTemplate.occurrenceCount [0..1]: positiveInt The number of planned occurrences
- Appointment.recurrenceTemplate.occurrenceDate [0..*]: date Specific dates for a recurring set of appointments (no template)
- Appointment.recurrenceTemplate.weeklyTemplate [0..1]: BackboneElement Information about weekly recurring appointments
- Appointment.recurrenceTemplate.weeklyTemplate.monday [0..1]: boolean Recurs on Mondays
- Appointment.recurrenceTemplate.weeklyTemplate.tuesday [0..1]: boolean Recurs on Tuesday
- Appointment.recurrenceTemplate.weeklyTemplate.wednesday [0..1]: boolean Recurs on Wednesday
- Appointment.recurrenceTemplate.weeklyTemplate.thursday [0..1]: boolean Recurs on Thursday
- Appointment.recurrenceTemplate.weeklyTemplate.friday [0..1]: boolean Recurs on Friday
- Appointment.recurrenceTemplate.weeklyTemplate.saturday [0..1]: boolean Recurs on Saturday
- Appointment.recurrenceTemplate.weeklyTemplate.sunday [0..1]: boolean Recurs on Sunday
- Appointment.recurrenceTemplate.weeklyTemplate.weekInterval [0..1]: positiveInt Recurs every nth week
- Appointment.recurrenceTemplate.monthlyTemplate [0..1]: BackboneElement Information about monthly recurring appointments
- Appointment.recurrenceTemplate.monthlyTemplate.dayOfMonth [0..1]: positiveInt Recurs on a specific day of the month
- Appointment.recurrenceTemplate.monthlyTemplate.nthWeekOfMonth [0..1]: Coding required:week-of-month Indicates which week of the month the appointment should occur
- Appointment.recurrenceTemplate.monthlyTemplate.dayOfWeek [0..1]: Coding required:days-of-week Indicates which day of the week the appointment should occur
- Appointment.recurrenceTemplate.monthlyTemplate.monthInterval [1..1]: positiveInt Recurs every nth month
- Appointment.recurrenceTemplate.yearlyTemplate [0..1]: BackboneElement Information about yearly recurring appointments
- Appointment.recurrenceTemplate.yearlyTemplate.yearInterval [1..1]: positiveInt Recurs every nth year
- Appointment.recurrenceTemplate.excludingDate [0..*]: date Any dates that should be excluded from the series
- Appointment.recurrenceTemplate.excludingRecurrenceId [0..*]: positiveInt Any recurrence IDs that should be excluded from the recurrence
Mappings
- Appointment Mappings — 111 mapping entries
Resource Packs
list-Appointment-packs.xml
<?xml version="1.0" encoding="UTF-8"?>
<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
<id value="Appointment-packs"/>
<status value="current"/>
<mode value="working"/>
</List>
Search Parameters
- 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. —
(start | requestedPeriod.start).first() - 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 - subject — reference — One of the individuals of the appointment is this patient —
Appointment.subject - patient — reference — One of the individuals of the appointment is this patient —
Appointment.participant.actor.where(resolve() is Patient) | Appointment.subject.where(resolve() is Patient) - group — reference — One of the individuals of the appointment is this patient —
Appointment.participant.actor.where(resolve() is Group) | Appointment.subject.where(resolve() is Group) - practitioner — reference — One of the individuals of the appointment is this practitioner —
Appointment.participant.actor.where(resolve() is Practitioner) - reason-code — token — Reference to a concept (by class) —
Appointment.reason.concept - reason-reference — reference — Reference to a resource (by instance) —
Appointment.reason.reference - 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 (by coding) that is to be performed during this appointment —
Appointment.serviceType.concept - service-type-reference — reference — The specific service (by HealthcareService) that is to be performed during this appointment —
Appointment.serviceType.reference - 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 - requested-period — date — During what period was the Appointment requested to take place —
requestedPeriod - originating-appointment — reference — Reference to the Appointment that contains the recurrence template —
Appointment.originatingAppointment - previous-appointment — reference — Reference to the Appointment that preceded this appointment in a series —
Appointment.previousAppointment - occurrence-changed — token — This Appointment has been changed from the recurrence template —
Appointment.occurrenceChanged - is-recurring — token — This Appointment is a part of a recurring series of appointments (has a template or an originating appointment) —
Appointment.recurrenceTemplate.exists() | Appointment.originatingAppointment.exists() - has-recurrence-template — token — This Appointment contains a recurrence template —
Appointment.recurrenceTemplate.exists()
Examples
- 2docs — appointment-example2doctors — Appointment between 2 doctors to discuss MRI results
- appointment-example — appointment-example
- appointment-example-request — appointment-example-request
- appointment-example2doctors — appointment-example2doctors
- appointment-examples-header — appointment-examples-header
- example — appointment-example — General Person Example
- examplereq — appointment-example-request — Appointment request
Mapping Exceptions
appointment-fivews-mapping-exceptions.xml
Divergent Elements
- FiveWs.context → Appointment.replaces
- FiveWs.context → Appointment.supportingInformation
Unmapped Elements
- FiveWs.what — Unknown
- FiveWs.recorded — Unknown
- FiveWs.author — Unknown
- FiveWs.actor — Unknown
- FiveWs.cause — Unknown
- FiveWs.version — Unknown
- FiveWs.witness — Unknown
- FiveWs.where — Unknown
- FiveWs.why — Unknown
- FiveWs.source — Unknown
- FiveWs.grade — Unknown
- FiveWs.planned — Unknown
- FiveWs.subject — Unknown
appointment-request-mapping-exceptions.xml
Divergent Elements
- Request.identifier → Appointment.identifier
- shortUnmatched | reason=Unknown | pattern=Business Identifier for appointment | resource=External Ids for this item
- definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this appointment by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=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).
- commentsUnmatched | reason=Unknown | pattern=The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler.
Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
- requirementsUnmatched | reason=Unknown | pattern=Allows identification of the appointment as it is known by various participating systems and in a way that remains consistent across servers.
- Request.basedOn → Appointment.basedOn
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=The request this appointment is allocated to assess
- definitionUnmatched | reason=Unknown | pattern=A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this appointment. Authorization from the 'basedOn' request flows through to the referencing appointment. | resource=The request this appointment is allocated to assess (e.g. incoming referral or procedure request).
- commentsUnmatched | reason=Unknown | pattern=basedOn represents the 'authorization' chain for an action, not the 'reason for action'. For example, an order might be placed on hold under the authorization for a surgery. However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications" .
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.
- Request.replaces → Appointment.replaces
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Request(s) replaced by this appointment | resource=Appointment replaced by this Appointment
- definitionUnmatched | reason=Unknown | pattern=Completed or terminated request(s) whose function is taken by this new appointment. | resource=Appointment replaced by this Appointment in cases where there is a cancellation, the details of the cancellation can be found in the cancellationReason property (on the referenced resource).
- commentsUnmatched | reason=Unknown | pattern=The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.
- Request.status → Appointment.status
- shortUnmatched | reason=Unknown | pattern=draft | active | on-hold | revoked | completed | entered-in-error | unknown | resource=proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error | checked-in | waitlist
- definitionUnmatched | reason=Unknown | pattern=The current state of the appointment. | resource=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.
- commentsUnmatched | reason=Unknown | pattern=The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding]](s) or using the]] resource. A nominal state-transition diagram can be found in the] documentation Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. A status of 'active' when doNotPerform is true means that the request to not perform is currently in force.
A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=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.
- Request.priority → Appointment.priority
- missingTypes | reason=Unknown | pattern=code
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- bindingStrength | reason=Unknown | pattern=required
- shortUnmatched | reason=Unknown | pattern=routine | urgent | asap | stat | resource=Used to make informed decisions if needing to re-prioritize
- definitionUnmatched | reason=Unknown | pattern=Indicates how quickly the appointment should be addressed with respect to other requests. | resource=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).
- Request.code → Appointment.serviceType
- missingTypes | reason=Unknown | pattern=CodeableConcept
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Service requested/ordered | resource=The specific service that is to be performed during this appointment
- definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action being asked to be done (or not done). | resource=The specific service that is to be performed during this appointment.
- Request.subject → Appointment.participant
- missingTypes | reason=Unknown | pattern=Reference(Patient, Group)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Individual the service is ordered/prohibited for | resource=Participants involved in appointment
- definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is to be performed/not performed on or for. | resource=List of participants involved in the appointment.
- requirementsUnmatched | reason=Unknown | pattern=Links the request to the Patient context.
- Request.occurrence[x] → Appointment.start
- missingTypes | reason=Unknown | pattern=dateTime, Period, Timing
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=When appointment is to take place
- definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=Date/Time that the appointment is to take place.
- Request.occurrence[x] → Appointment.end
- missingTypes | reason=Unknown | pattern=dateTime, Period, Timing
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=When appointment is to conclude
- definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=Date/Time that the appointment is to conclude.
- Request.occurrence[x] → Appointment.minutesDuration
- missingTypes | reason=Unknown | pattern=dateTime, Period, Timing
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=Can be less than start/end (e.g. estimate)
- definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=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.
- Request.occurrence[x] → Appointment.requestedPeriod
- missingTypes | reason=Unknown | pattern=dateTime, Timing
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=Potential date/time interval(s) requested to allocate the appointment within
- definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=A 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.
- Request.authoredOn → Appointment.created
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=When request was created/transitioned to active | resource=The date that this appointment was initially created
- definitionUnmatched | reason=Unknown | pattern=For draft appointments, indicates the date of initial creation. For requests with other statuses, indicates the date of activation. | resource=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.
- Request.performer → Appointment.participant
- missingTypes | reason=Unknown | pattern=Reference(Practitioner, PractitionerRole, Organization, CareTeam, HealthcareService, Patient, Device, RelatedPerson)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Specific desired (non)performer | resource=Participants involved in appointment
- definitionUnmatched | reason=Unknown | pattern=Indicates who or what is being asked to perform (or not perform) the {{request}}. | resource=List of participants involved in the appointment.
- Request.reason → Appointment.reason
- shortUnmatched | reason=Unknown | pattern=Why is service (not) needed? | resource=Reason this appointment is scheduled
- definitionUnmatched | reason=Unknown | pattern=Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this request. | resource=The reason that this appointment is being scheduled. This is more clinical than administrative. This can be coded, or 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.
- commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text. If doNoPerform is true, this will be the reason why the request is being made to not act.
- Request.supportingInfo → Appointment.supportingInformation
- missingTypes | reason=Unknown | pattern=Reference(Any)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Extra information to use in performing request | resource=Additional information to support the appointment
- definitionUnmatched | reason=Unknown | pattern=Information that may be needed by/relevant to the performer in their execution of this appointment. | resource=Additional information to support the appointment provided when making the appointment.
- commentsUnmatched | reason=Unknown | pattern=See guidance on notes vs. supportingInfo.
- Request.note → Appointment.note
- shortUnmatched | reason=Unknown | pattern=Comments made about appointment | resource=Additional comments
- definitionUnmatched | reason=Unknown | pattern=Comments made about the appointment by the requester, performer, subject or other participants. | resource=Additional notes/comments about the appointment.
- commentsUnmatched | reason=Unknown | pattern=See guidance on notes vs. supportingInfo. | resource=Additional text to aid in facilitating the appointment. For instance, a note 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.
Typically only the concept.text will be used, however occasionally a reference to some generic documentation (or specific) and also supports coded instructions if/when they are required.
Unmapped Elements
- Request.intent — Unknown
- Request.insurance — Unknown
- Request.groupIdentifier — Unknown
- Request.deliverTo — Unknown
- Request.encounter — Unknown
- Request.requester — Unknown
- Request.category — Unknown
- Request.reported — Unknown
- Request.relevantHistory — Unknown
- Request.statusReason — Unknown
- Request.performerType — Unknown
- Request.doNotPerform — Unknown
- Request.product — Unknown