Current Build

12.10 Resource Appointment - Content

Patient Administration Work GroupMaturity Level: 3 Trial UseCompartments: Device, Patient, Practitioner, RelatedPerson

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

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

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

    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.

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.

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.

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.

This resource is referenced by AppointmentResponse, CarePlan, ClinicalImpression and Encounter

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Appointment IDomainResourceA 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)
+ Only proposed or cancelled appointments can be missing start/end dates
+ Either start and end are specified, or neither
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierExternal Ids for this item
... status ?!Σ1..1codeproposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
AppointmentStatus (Required)
... serviceCategory Σ0..1CodeableConceptA broad categorisation of the service that is to be performed during this appointment
ServiceCategory (Example)
... serviceType Σ0..*CodeableConceptThe specific service that is to be performed during this appointment
ServiceType (Example)
... specialty Σ0..*CodeableConceptThe specialty of a practitioner that would be required to perform the service requested in this appointment
Practice Setting Code Value Set (Preferred)
... appointmentType Σ0..1CodeableConceptThe style of appointment or patient that has been booked in the slot (not service type)
v2 Appointment reason codes (Preferred)
... reason Σ0..*CodeableConceptReason this appointment is scheduled
Encounter Reason Codes (Preferred)
... indication 0..*Reference(Condition | Procedure)Reason the appointment is to takes place (resource)
... priority 0..1unsignedIntUsed to make informed decisions if needing to re-prioritize
... description 0..1stringShown on a subject line in a meeting request, or appointment list
... supportingInformation 0..*Reference(Any)Additional information to support the appointment
... start Σ0..1instantWhen appointment is to take place
... end Σ0..1instantWhen appointment is to conclude
... minutesDuration 0..1positiveIntCan be less than start/end (e.g. estimate)
... slot 0..*Reference(Slot)The slots that this appointment is filling
... created 0..1dateTimeThe date that this appointment was initially created
... comment 0..1stringAdditional comments
... incomingReferral 0..*Reference(ServiceRequest)The ServiceRequest provided as information to allocate to the Encounter
... participant I1..*BackboneElementParticipants involved in appointment
+ Either the type or actor on the participant SHALL be specified
.... type Σ0..*CodeableConceptRole of participant in the appointment
ParticipantType (Extensible)
.... actor Σ0..1Reference(Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location)Person, Location/HealthcareService or Device
.... required Σ0..1coderequired | optional | information-only
ParticipantRequired (Required)
.... status 1..1codeaccepted | declined | tentative | needs-action
ParticipationStatus (Required)
... requestedPeriod 0..*PeriodPotential date/time interval(s) requested to allocate the appointment within

doco Documentation for this format

UML Diagram (Legend)

Appointment (DomainResource)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)identifier : Identifier [0..*]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 (this element modifies the meaning of other elements)status : code [1..1] « The free/busy status of an appointment. (Strength=Required)AppointmentStatus! »A broad categorisation of the service that is to be performed during this appointmentserviceCategory : CodeableConcept [0..1] « (Strength=Example)ServiceCategory?? »The specific service that is to be performed during this appointmentserviceType : CodeableConcept [0..*] « (Strength=Example)ServiceType?? »The specialty of a practitioner that would be required to perform the service requested in this appointmentspecialty : CodeableConcept [0..*] « (Strength=Preferred)Practice Setting Code Value S...? »The style of appointment or patient that has been booked in the slot (not service type)appointmentType : CodeableConcept [0..1] « (Strength=Preferred)v2 Appointment reason ? »The reason that this appointment is being scheduled. This is more clinical than administrativereason : CodeableConcept [0..*] « The Reason for the appointment to take place. (Strength=Preferred)Encounter Reason ? »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 Procedureindication : Reference [0..*] « Condition|Procedure »The priority of the appointment. Can be used to make informed decisions if needing to re-prioritize appointments. (The iCal Standard specifies 0 as undefined, 1 as highest, 9 as lowest priority)priority : unsignedInt [0..1]The brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment fielddescription : string [0..1]Additional information to support the appointment provided when making the appointmentsupportingInformation : Reference [0..*] « Any »Date/Time that the appointment is to take placestart : instant [0..1]Date/Time that the appointment is to concludeend : instant [0..1]Number of minutes that the appointment is to take. This can be less than the duration between the start and end times (where actual time of appointment is only an estimate or is a planned appointment request)minutesDuration : positiveInt [0..1]The slots from the participants' schedules that will be filled by the appointmentslot : Reference [0..*] « Slot »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 appointmentcreated : dateTime [0..1]Additional comments about the appointmentcomment : string [0..1]The referral request this appointment is allocated to assess (incoming referral)incomingReferral : Reference [0..*] « ServiceRequest »A set of date ranges (potentially including times) that the appointment is preferred to be scheduled within. When using these values, the minutes duration should be provided to indicate the length of the appointment to fill and populate the start/end times for the actual allocated timerequestedPeriod : Period [0..*]ParticipantRole of participant in the appointmenttype : CodeableConcept [0..*] « Role of participant in encounter. (Strength=Extensible)ParticipantType+ »A Person, Location/HealthcareService or Device that is participating in the appointmentactor : Reference [0..1] « Patient|Practitioner|RelatedPerson|Device| HealthcareService|Location »Is this participant required to be present at the meeting. This covers a use-case where 2 doctors need to meet to discuss the results for a specific patient, and the patient is not required to be presentrequired : code [0..1] « Is the Participant required to attend the appointment. (Strength=Required)ParticipantRequired! »Participation status of the actorstatus : code [1..1] « The Participation status of an appointment. (Strength=Required)ParticipationStatus! »List of participants involved in the appointmentparticipant[1..*]

XML Template

<Appointment xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier External Ids for this item --></identifier>
 <status value="[code]"/><!-- 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error -->
 <serviceCategory><!-- 0..1 CodeableConcept A broad categorisation of the service that is to be performed during this appointment --></serviceCategory>
 <serviceType><!-- 0..* CodeableConcept The specific service that is to be performed during this appointment --></serviceType>
 <specialty><!-- 0..* CodeableConcept The specialty of a practitioner that would be required to perform the service requested in this appointment --></specialty>
 <appointmentType><!-- 0..1 CodeableConcept The style of appointment or patient that has been booked in the slot (not service type) --></appointmentType>
 <reason><!-- 0..* CodeableConcept Reason this appointment is scheduled --></reason>
 <indication><!-- 0..* Reference(Condition|Procedure) Reason the appointment is to takes place (resource) --></indication>
 <priority value="[unsignedInt]"/><!-- 0..1 Used to make informed decisions if needing to re-prioritize -->
 <description value="[string]"/><!-- 0..1 Shown on a subject line in a meeting request, or appointment list -->
 <supportingInformation><!-- 0..* Reference(Any) Additional information to support the appointment --></supportingInformation>
 <start value="[instant]"/><!-- 0..1 When appointment is to take place -->
 <end value="[instant]"/><!-- 0..1 When appointment is to conclude -->
 <minutesDuration value="[positiveInt]"/><!-- 0..1 Can be less than start/end (e.g. estimate) -->
 <slot><!-- 0..* Reference(Slot) The slots that this appointment is filling --></slot>
 <created value="[dateTime]"/><!-- 0..1 The date that this appointment was initially created -->
 <comment value="[string]"/><!-- 0..1 Additional comments -->
 <incomingReferral><!-- 0..* Reference(ServiceRequest) The ServiceRequest provided as information to allocate to the Encounter --></incomingReferral>
 <participant>  <!-- 1..* Participants involved in appointment -->
  <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type>
  <actor><!-- 0..1 Reference(Patient|Practitioner|RelatedPerson|Device|
    HealthcareService|Location) Person, Location/HealthcareService or Device --></actor>
  <required value="[code]"/><!-- 0..1 required | optional | information-only -->
  <status value="[code]"/><!-- 1..1 accepted | declined | tentative | needs-action -->
 </participant>
 <requestedPeriod><!-- 0..* Period Potential date/time interval(s) requested to allocate the appointment within --></requestedPeriod>
</Appointment>

JSON Template

{doco
  "resourceType" : "Appointment",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // External Ids for this item
  "status" : "<code>", // R!  proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
  "serviceCategory" : { CodeableConcept }, // A broad categorisation of the service that is to be performed during this appointment
  "serviceType" : [{ CodeableConcept }], // The specific service that is to be performed during this appointment
  "specialty" : [{ CodeableConcept }], // The 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)
  "reason" : [{ CodeableConcept }], // Reason this appointment is scheduled
  "indication" : [{ Reference(Condition|Procedure) }], // Reason the appointment is to takes place (resource)
  "priority" : "<unsignedInt>", // Used to make informed decisions if needing to re-prioritize
  "description" : "<string>", // Shown on a subject line in a meeting request, or appointment list
  "supportingInformation" : [{ Reference(Any) }], // Additional information to support the appointment
  "start" : "<instant>", // When appointment is to take place
  "end" : "<instant>", // When appointment is to conclude
  "minutesDuration" : "<positiveInt>", // Can be less than start/end (e.g. estimate)
  "slot" : [{ Reference(Slot) }], // The slots that this appointment is filling
  "created" : "<dateTime>", // The date that this appointment was initially created
  "comment" : "<string>", // Additional comments
  "incomingReferral" : [{ Reference(ServiceRequest) }], // The ServiceRequest provided as information to allocate to the Encounter
  "participant" : [{ // R!  Participants involved in appointment
    "type" : [{ CodeableConcept }], // Role of participant in the appointment
    "actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
    HealthcareService|Location) }, // Person, Location/HealthcareService or Device
    "required" : "<code>", // required | optional | information-only
    "status" : "<code>" // R!  accepted | declined | tentative | needs-action
  }],
  "requestedPeriod" : [{ Period }] // Potential date/time interval(s) requested to allocate the appointment within
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Appointment;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Appointment.identifier [ Identifier ], ... ; # 0..* External Ids for this item
  fhir:Appointment.status [ code ]; # 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
  fhir:Appointment.serviceCategory [ CodeableConcept ]; # 0..1 A broad categorisation of the service that is to be performed during this appointment
  fhir:Appointment.serviceType [ CodeableConcept ], ... ; # 0..* The specific service that is to be performed during this appointment
  fhir:Appointment.specialty [ CodeableConcept ], ... ; # 0..* The specialty of a practitioner that would be required to perform the service requested in this appointment
  fhir:Appointment.appointmentType [ CodeableConcept ]; # 0..1 The style of appointment or patient that has been booked in the slot (not service type)
  fhir:Appointment.reason [ CodeableConcept ], ... ; # 0..* Reason this appointment is scheduled
  fhir:Appointment.indication [ Reference(Condition|Procedure) ], ... ; # 0..* Reason the appointment is to takes place (resource)
  fhir:Appointment.priority [ unsignedInt ]; # 0..1 Used to make informed decisions if needing to re-prioritize
  fhir:Appointment.description [ string ]; # 0..1 Shown on a subject line in a meeting request, or appointment list
  fhir:Appointment.supportingInformation [ Reference(Any) ], ... ; # 0..* Additional information to support the appointment
  fhir:Appointment.start [ instant ]; # 0..1 When appointment is to take place
  fhir:Appointment.end [ instant ]; # 0..1 When appointment is to conclude
  fhir:Appointment.minutesDuration [ positiveInt ]; # 0..1 Can be less than start/end (e.g. estimate)
  fhir:Appointment.slot [ Reference(Slot) ], ... ; # 0..* The slots that this appointment is filling
  fhir:Appointment.created [ dateTime ]; # 0..1 The date that this appointment was initially created
  fhir:Appointment.comment [ string ]; # 0..1 Additional comments
  fhir:Appointment.incomingReferral [ Reference(ServiceRequest) ], ... ; # 0..* The ServiceRequest provided as information to allocate to the Encounter
  fhir:Appointment.participant [ # 1..* Participants involved in appointment
    fhir:Appointment.participant.type [ CodeableConcept ], ... ; # 0..* Role of participant in the appointment
    fhir:Appointment.participant.actor [ Reference(Patient|Practitioner|RelatedPerson|Device|HealthcareService|Location) ]; # 0..1 Person, Location/HealthcareService or Device
    fhir:Appointment.participant.required [ code ]; # 0..1 required | optional | information-only
    fhir:Appointment.participant.status [ code ]; # 1..1 accepted | declined | tentative | needs-action
  ], ...;
  fhir:Appointment.requestedPeriod [ Period ], ... ; # 0..* Potential date/time interval(s) requested to allocate the appointment within
]

Changes since DSTU2

Appointment
Appointment.serviceCategory
  • Added Element
Appointment.serviceType
  • Renamed from type to serviceType
  • Max Cardinality changed from 1 to *
Appointment.specialty
  • Added Element
Appointment.appointmentType
  • Added Element
Appointment.reason
  • Max Cardinality changed from 1 to *
  • Remove Binding http://hl7.org/fhir/ValueSet/encounter-reason (required)
Appointment.indication
  • Added Element
Appointment.supportingInformation
  • Added Element
Appointment.created
  • Added Element
Appointment.incomingReferral
  • Added Element
Appointment.participant.type
  • Change binding strength from required to extensible
Appointment.requestedPeriod
  • Added Element

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 3 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.).

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Appointment IDomainResourceA 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)
+ Only proposed or cancelled appointments can be missing start/end dates
+ Either start and end are specified, or neither
Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ0..*IdentifierExternal Ids for this item
... status ?!Σ1..1codeproposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
AppointmentStatus (Required)
... serviceCategory Σ0..1CodeableConceptA broad categorisation of the service that is to be performed during this appointment
ServiceCategory (Example)
... serviceType Σ0..*CodeableConceptThe specific service that is to be performed during this appointment
ServiceType (Example)
... specialty Σ0..*CodeableConceptThe specialty of a practitioner that would be required to perform the service requested in this appointment
Practice Setting Code Value Set (Preferred)
... appointmentType Σ0..1CodeableConceptThe style of appointment or patient that has been booked in the slot (not service type)
v2 Appointment reason codes (Preferred)
... reason Σ0..*CodeableConceptReason this appointment is scheduled
Encounter Reason Codes (Preferred)
... indication 0..*Reference(Condition | Procedure)Reason the appointment is to takes place (resource)
... priority 0..1unsignedIntUsed to make informed decisions if needing to re-prioritize
... description 0..1stringShown on a subject line in a meeting request, or appointment list
... supportingInformation 0..*Reference(Any)Additional information to support the appointment
... start Σ0..1instantWhen appointment is to take place
... end Σ0..1instantWhen appointment is to conclude
... minutesDuration 0..1positiveIntCan be less than start/end (e.g. estimate)
... slot 0..*Reference(Slot)The slots that this appointment is filling
... created 0..1dateTimeThe date that this appointment was initially created
... comment 0..1stringAdditional comments
... incomingReferral 0..*Reference(ServiceRequest)The ServiceRequest provided as information to allocate to the Encounter
... participant I1..*BackboneElementParticipants involved in appointment
+ Either the type or actor on the participant SHALL be specified
.... type Σ0..*CodeableConceptRole of participant in the appointment
ParticipantType (Extensible)
.... actor Σ0..1Reference(Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location)Person, Location/HealthcareService or Device
.... required Σ0..1coderequired | optional | information-only
ParticipantRequired (Required)
.... status 1..1codeaccepted | declined | tentative | needs-action
ParticipationStatus (Required)
... requestedPeriod 0..*PeriodPotential date/time interval(s) requested to allocate the appointment within

doco Documentation for this format

UML Diagram (Legend)

Appointment (DomainResource)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)identifier : Identifier [0..*]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 (this element modifies the meaning of other elements)status : code [1..1] « The free/busy status of an appointment. (Strength=Required)AppointmentStatus! »A broad categorisation of the service that is to be performed during this appointmentserviceCategory : CodeableConcept [0..1] « (Strength=Example)ServiceCategory?? »The specific service that is to be performed during this appointmentserviceType : CodeableConcept [0..*] « (Strength=Example)ServiceType?? »The specialty of a practitioner that would be required to perform the service requested in this appointmentspecialty : CodeableConcept [0..*] « (Strength=Preferred)Practice Setting Code Value S...? »The style of appointment or patient that has been booked in the slot (not service type)appointmentType : CodeableConcept [0..1] « (Strength=Preferred)v2 Appointment reason ? »The reason that this appointment is being scheduled. This is more clinical than administrativereason : CodeableConcept [0..*] « The Reason for the appointment to take place. (Strength=Preferred)Encounter Reason ? »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 Procedureindication : Reference [0..*] « Condition|Procedure »The priority of the appointment. Can be used to make informed decisions if needing to re-prioritize appointments. (The iCal Standard specifies 0 as undefined, 1 as highest, 9 as lowest priority)priority : unsignedInt [0..1]The brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment fielddescription : string [0..1]Additional information to support the appointment provided when making the appointmentsupportingInformation : Reference [0..*] « Any »Date/Time that the appointment is to take placestart : instant [0..1]Date/Time that the appointment is to concludeend : instant [0..1]Number of minutes that the appointment is to take. This can be less than the duration between the start and end times (where actual time of appointment is only an estimate or is a planned appointment request)minutesDuration : positiveInt [0..1]The slots from the participants' schedules that will be filled by the appointmentslot : Reference [0..*] « Slot »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 appointmentcreated : dateTime [0..1]Additional comments about the appointmentcomment : string [0..1]The referral request this appointment is allocated to assess (incoming referral)incomingReferral : Reference [0..*] « ServiceRequest »A set of date ranges (potentially including times) that the appointment is preferred to be scheduled within. When using these values, the minutes duration should be provided to indicate the length of the appointment to fill and populate the start/end times for the actual allocated timerequestedPeriod : Period [0..*]ParticipantRole of participant in the appointmenttype : CodeableConcept [0..*] « Role of participant in encounter. (Strength=Extensible)ParticipantType+ »A Person, Location/HealthcareService or Device that is participating in the appointmentactor : Reference [0..1] « Patient|Practitioner|RelatedPerson|Device| HealthcareService|Location »Is this participant required to be present at the meeting. This covers a use-case where 2 doctors need to meet to discuss the results for a specific patient, and the patient is not required to be presentrequired : code [0..1] « Is the Participant required to attend the appointment. (Strength=Required)ParticipantRequired! »Participation status of the actorstatus : code [1..1] « The Participation status of an appointment. (Strength=Required)ParticipationStatus! »List of participants involved in the appointmentparticipant[1..*]

XML Template

<Appointment xmlns="http://hl7.org/fhir"> doco
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..* Identifier External Ids for this item --></identifier>
 <status value="[code]"/><!-- 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error -->
 <serviceCategory><!-- 0..1 CodeableConcept A broad categorisation of the service that is to be performed during this appointment --></serviceCategory>
 <serviceType><!-- 0..* CodeableConcept The specific service that is to be performed during this appointment --></serviceType>
 <specialty><!-- 0..* CodeableConcept The specialty of a practitioner that would be required to perform the service requested in this appointment --></specialty>
 <appointmentType><!-- 0..1 CodeableConcept The style of appointment or patient that has been booked in the slot (not service type) --></appointmentType>
 <reason><!-- 0..* CodeableConcept Reason this appointment is scheduled --></reason>
 <indication><!-- 0..* Reference(Condition|Procedure) Reason the appointment is to takes place (resource) --></indication>
 <priority value="[unsignedInt]"/><!-- 0..1 Used to make informed decisions if needing to re-prioritize -->
 <description value="[string]"/><!-- 0..1 Shown on a subject line in a meeting request, or appointment list -->
 <supportingInformation><!-- 0..* Reference(Any) Additional information to support the appointment --></supportingInformation>
 <start value="[instant]"/><!-- 0..1 When appointment is to take place -->
 <end value="[instant]"/><!-- 0..1 When appointment is to conclude -->
 <minutesDuration value="[positiveInt]"/><!-- 0..1 Can be less than start/end (e.g. estimate) -->
 <slot><!-- 0..* Reference(Slot) The slots that this appointment is filling --></slot>
 <created value="[dateTime]"/><!-- 0..1 The date that this appointment was initially created -->
 <comment value="[string]"/><!-- 0..1 Additional comments -->
 <incomingReferral><!-- 0..* Reference(ServiceRequest) The ServiceRequest provided as information to allocate to the Encounter --></incomingReferral>
 <participant>  <!-- 1..* Participants involved in appointment -->
  <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type>
  <actor><!-- 0..1 Reference(Patient|Practitioner|RelatedPerson|Device|
    HealthcareService|Location) Person, Location/HealthcareService or Device --></actor>
  <required value="[code]"/><!-- 0..1 required | optional | information-only -->
  <status value="[code]"/><!-- 1..1 accepted | declined | tentative | needs-action -->
 </participant>
 <requestedPeriod><!-- 0..* Period Potential date/time interval(s) requested to allocate the appointment within --></requestedPeriod>
</Appointment>

JSON Template

{doco
  "resourceType" : "Appointment",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : [{ Identifier }], // External Ids for this item
  "status" : "<code>", // R!  proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
  "serviceCategory" : { CodeableConcept }, // A broad categorisation of the service that is to be performed during this appointment
  "serviceType" : [{ CodeableConcept }], // The specific service that is to be performed during this appointment
  "specialty" : [{ CodeableConcept }], // The 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)
  "reason" : [{ CodeableConcept }], // Reason this appointment is scheduled
  "indication" : [{ Reference(Condition|Procedure) }], // Reason the appointment is to takes place (resource)
  "priority" : "<unsignedInt>", // Used to make informed decisions if needing to re-prioritize
  "description" : "<string>", // Shown on a subject line in a meeting request, or appointment list
  "supportingInformation" : [{ Reference(Any) }], // Additional information to support the appointment
  "start" : "<instant>", // When appointment is to take place
  "end" : "<instant>", // When appointment is to conclude
  "minutesDuration" : "<positiveInt>", // Can be less than start/end (e.g. estimate)
  "slot" : [{ Reference(Slot) }], // The slots that this appointment is filling
  "created" : "<dateTime>", // The date that this appointment was initially created
  "comment" : "<string>", // Additional comments
  "incomingReferral" : [{ Reference(ServiceRequest) }], // The ServiceRequest provided as information to allocate to the Encounter
  "participant" : [{ // R!  Participants involved in appointment
    "type" : [{ CodeableConcept }], // Role of participant in the appointment
    "actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
    HealthcareService|Location) }, // Person, Location/HealthcareService or Device
    "required" : "<code>", // required | optional | information-only
    "status" : "<code>" // R!  accepted | declined | tentative | needs-action
  }],
  "requestedPeriod" : [{ Period }] // Potential date/time interval(s) requested to allocate the appointment within
}

Turtle Template

@prefix fhir: <http://hl7.org/fhir/> .doco


[ a fhir:Appointment;
  fhir:nodeRole fhir:treeRoot; # if this is the parser root

  # from Resource: .id, .meta, .implicitRules, and .language
  # from DomainResource: .text, .contained, .extension, and .modifierExtension
  fhir:Appointment.identifier [ Identifier ], ... ; # 0..* External Ids for this item
  fhir:Appointment.status [ code ]; # 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow | entered-in-error
  fhir:Appointment.serviceCategory [ CodeableConcept ]; # 0..1 A broad categorisation of the service that is to be performed during this appointment
  fhir:Appointment.serviceType [ CodeableConcept ], ... ; # 0..* The specific service that is to be performed during this appointment
  fhir:Appointment.specialty [ CodeableConcept ], ... ; # 0..* The specialty of a practitioner that would be required to perform the service requested in this appointment
  fhir:Appointment.appointmentType [ CodeableConcept ]; # 0..1 The style of appointment or patient that has been booked in the slot (not service type)
  fhir:Appointment.reason [ CodeableConcept ], ... ; # 0..* Reason this appointment is scheduled
  fhir:Appointment.indication [ Reference(Condition|Procedure) ], ... ; # 0..* Reason the appointment is to takes place (resource)
  fhir:Appointment.priority [ unsignedInt ]; # 0..1 Used to make informed decisions if needing to re-prioritize
  fhir:Appointment.description [ string ]; # 0..1 Shown on a subject line in a meeting request, or appointment list
  fhir:Appointment.supportingInformation [ Reference(Any) ], ... ; # 0..* Additional information to support the appointment
  fhir:Appointment.start [ instant ]; # 0..1 When appointment is to take place
  fhir:Appointment.end [ instant ]; # 0..1 When appointment is to conclude
  fhir:Appointment.minutesDuration [ positiveInt ]; # 0..1 Can be less than start/end (e.g. estimate)
  fhir:Appointment.slot [ Reference(Slot) ], ... ; # 0..* The slots that this appointment is filling
  fhir:Appointment.created [ dateTime ]; # 0..1 The date that this appointment was initially created
  fhir:Appointment.comment [ string ]; # 0..1 Additional comments
  fhir:Appointment.incomingReferral [ Reference(ServiceRequest) ], ... ; # 0..* The ServiceRequest provided as information to allocate to the Encounter
  fhir:Appointment.participant [ # 1..* Participants involved in appointment
    fhir:Appointment.participant.type [ CodeableConcept ], ... ; # 0..* Role of participant in the appointment
    fhir:Appointment.participant.actor [ Reference(Patient|Practitioner|RelatedPerson|Device|HealthcareService|Location) ]; # 0..1 Person, Location/HealthcareService or Device
    fhir:Appointment.participant.required [ code ]; # 0..1 required | optional | information-only
    fhir:Appointment.participant.status [ code ]; # 1..1 accepted | declined | tentative | needs-action
  ], ...;
  fhir:Appointment.requestedPeriod [ Period ], ... ; # 0..* Potential date/time interval(s) requested to allocate the appointment within
]

Changes since DSTU2

Appointment
Appointment.serviceCategory
  • Added Element
Appointment.serviceType
  • Renamed from type to serviceType
  • Max Cardinality changed from 1 to *
Appointment.specialty
  • Added Element
Appointment.appointmentType
  • Added Element
Appointment.reason
  • Max Cardinality changed from 1 to *
  • Remove Binding http://hl7.org/fhir/ValueSet/encounter-reason (required)
Appointment.indication
  • Added Element
Appointment.supportingInformation
  • Added Element
Appointment.created
  • Added Element
Appointment.incomingReferral
  • Added Element
Appointment.participant.type
  • Change binding strength from required to extensible
Appointment.requestedPeriod
  • Added Element

See the Full Difference for further information

This analysis is available as XML or JSON.

See R2 <--> R3 Conversion Maps (status = 3 tests that all execute ok. All tests pass round-trip testing and all r3 resources are valid.).

 

Alternate definitions: Master Definition (XML, JSON), XML Schema/Schematron + JSON Schema, ShEx (for Turtle)

PathDefinitionTypeReference
Appointment.status The free/busy status of an appointment.RequiredAppointmentStatus
Appointment.serviceCategory ExampleServiceCategory
Appointment.serviceType ExampleServiceType
Appointment.specialty PreferredPractice Setting Code Value Set
Appointment.appointmentType Preferredv2 Appointment reason codes
Appointment.reason The Reason for the appointment to take place.PreferredEncounter Reason Codes
Appointment.participant.type Role of participant in encounter.ExtensibleParticipantType
Appointment.participant.required Is the Participant required to attend the appointment.RequiredParticipantRequired
Appointment.participant.status The Participation status of an appointment.RequiredParticipationStatus

  • app-1: On Appointment.participant: Either the type or actor on the participant SHALL be specified (expression on Appointment.participant: type.exists() or actor.exists())
  • app-2: Either start and end are specified, or neither (expression : start.empty() xor end.exists())
  • app-3: Only proposed or cancelled appointments can be missing start/end dates (expression : (start.exists() and end.exists()) or (status in ('proposed' | 'cancelled')))
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
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
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
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)
  • 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.

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

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 .

Search parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

NameTypeDescriptionExpressionIn Common
actorreferenceAny one of the individuals participating in the appointmentAppointment.participant.actor
(Practitioner, Device, Patient, HealthcareService, RelatedPerson, Location)
appointment-typetokenThe style of appointment or patient that has been booked in the slot (not service type)Appointment.appointmentType
datedateAppointment date/time.Appointment.start
identifiertokenAn Identifier of the AppointmentAppointment.identifier
incomingreferralreferenceThe ServiceRequest provided as information to allocate to the EncounterAppointment.incomingReferral
(ServiceRequest)
locationreferenceThis location is listed in the participants of the appointmentAppointment.participant.actor
(Location)
part-statustokenThe 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
patientreferenceOne of the individuals of the appointment is this patientAppointment.participant.actor
(Patient)
practitionerreferenceOne of the individuals of the appointment is this practitionerAppointment.participant.actor
(Practitioner)
service-typetokenThe specific service that is to be performed during this appointmentAppointment.serviceType
statustokenThe overall status of the appointmentAppointment.status