2nd DSTU Draft For Comment

This page is part of the FHIR Specification (v0.4.0: DSTU 2 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

5.24 Resource Appointment - Content

This resource maintained by the Patient Administration Work Group

A scheduled healthcare event for a patient and/or practitioner(s) where a service may take place at a specific date/time.

5.24.1 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 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 also ease exposure to other appointment / calendar standards widely used outside of healthcare.

5.24.1.1 The basic workflow to create an appointment

  • Discovery/Addressing

    Before an appointment can be made the address of the resource that we want to schedule an appointment with must be determined. This is often based on the healthcare Service Type, 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 it is 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

    The request is performed by posting an Appointment to the address found during discovery. This will have a needs-action status for each of the participants. (The system that receives the request may modify the status of any posted appointment based on internal business rules, such as certain users do not have permission to request certain appointments)

  • Replying to the request

    The reply process is simply performed by the person/system handing the requests updating the Participant Statuses 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 appointmentresponses 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.

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

    Note: This type of clinical appointment scheduling has not been specifically covered with this definition of the appointment (and the 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.

5.24.2 Boundaries and Relationships

5.24.2.1 Appointment Statuses and Encounters

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

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

In an Emergency Room context, this appointment resource is probably not appropriate to be used. In these cases an encounter should be created.

The Appointment request pattern used is different to 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 has been provided to guide implementation of gateways between FHIR servers and iCAL systems.

This resource is referenced by AppointmentResponse, ClinicalAssessment and Encounter

5.24.3 Resource Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Appointment DomainResourceA scheduled healthcare event for a patient and/or practitioner(s) where a service may take place at a specific date/time
... identifier 0..*IdentifierExternal Ids for this item
... priority 0..1integerThe 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) (Need to change back to CodeableConcept)
... status M1..1codepending | booked | arrived | fulfilled | cancelled | noshow
AppointmentStatus (Required)
... type 0..1CodeableConceptThe type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)
... reason 0..1CodeableConceptThe reason that this appointment is being scheduled, this is more clinical than administrative
ApptReason (Incomplete)
... description 0..1stringThe brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment field
... start 1..1instantDate/Time that the appointment is to take place
... end 1..1instantDate/Time that the appointment is to conclude
... slot 0..*SlotThe slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot
... location 0..1LocationThe primary location that this appointment is to take place
... comment 0..1stringAdditional comments about the appointment
... order 0..1OrderAn Order that lead to the creation of this appointment
... participant 1..*ElementList of participants involved in the appointment
.... type 0..*CodeableConceptRole of participant in the appointment
ParticipantType (Incomplete)
.... actor 0..1AnyA Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device
.... required 0..1coderequired | optional | information-only
ParticipantRequired (Required)
.... status 1..1codeaccepted | declined | tentative | in-process | completed | needs-action
ParticipationStatus (Required)
... lastModifiedBy 0..1Practitioner | Patient | RelatedPersonWho recorded the appointment
... lastModified 0..1dateTimeDate when the appointment was recorded

UML Diagram

Appointment (DomainResource)This records identifiers associated with this appointment concern that are defined by business processed 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 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) (Need to change back to CodeableConcept)priority : integer 0..1The 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 appointmentAppointmentStatus »The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)type : CodeableConcept 0..1The reason that this appointment is being scheduled, this is more clinical than administrativereason : CodeableConcept 0..1 « The Reason for the appointment to take placeApptReason+ »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..1Date/Time that the appointment is to take placestart : instant 1..1Date/Time that the appointment is to concludeend : instant 1..1The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slotslot : Reference(Slot) 0..*The primary location that this appointment is to take placelocation : Reference(Location) 0..1Additional comments about the appointmentcomment : string 0..1An Order that lead to the creation of this appointmentorder : Reference(Order) 0..1Who recorded the appointmentlastModifiedBy : Reference(Practitioner|Patient| RelatedPerson) 0..1Date when the appointment was recordedlastModified : dateTime 0..1ParticipantRole of participant in the appointmenttype : CodeableConcept 0..* « Role of participant in encounterParticipantType+ »A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Deviceactor : Reference(Any) 0..1Is 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 appointmentParticipantRequired »Participation status of the Patientstatus : code 1..1 « The Participation status of an appointmentParticipationStatus »List of participants involved in the appointmentparticipant1..*

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>
 <priority value="[integer]"/><!-- 0..1 
     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) (Need to change back to CodeableConcept) -->
 <status value="[code]"/><!-- 1..1 pending | booked | arrived | fulfilled | cancelled | noshow -->
 <type><!-- 0..1 CodeableConcept 
     The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself) --></type>
 <reason><!-- 0..1 CodeableConcept The reason that this appointment is being scheduled, this is more clinical than administrative --></reason>
 <description value="[string]"/><!-- 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 field -->
 <start value="[instant]"/><!-- 1..1 Date/Time that the appointment is to take place -->
 <end value="[instant]"/><!-- 1..1 Date/Time that the appointment is to conclude -->
 <slot><!-- 0..* Reference(Slot) 
     The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot --></slot>
 <location><!-- 0..1 Reference(Location) 
     The primary location that this appointment is to take place --></location>
 <comment value="[string]"/><!-- 0..1 Additional comments about the appointment -->
 <order><!-- 0..1 Reference(Order) An Order that lead to the creation of this appointment --></order>
 <participant>  <!-- 1..* List of participants involved in the appointment -->
  <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type>
  <actor><!-- 0..1 Reference(Any) 
      A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device --></actor>
  <required value="[code]"/><!-- 0..1 required | optional | information-only -->
  <status value="[code]"/><!-- 1..1 accepted | declined | tentative | in-process | completed | needs-action -->
 </participant>
 <lastModifiedBy><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson) 
     Who recorded the appointment --></lastModifiedBy>
 <lastModified value="[dateTime]"/><!-- 0..1 Date when the appointment was recorded -->
</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
  "priority" : <integer>, // 
     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) (Need to change back to CodeableConcept)
  "status" : "<code>", // R! pending | booked | arrived | fulfilled | cancelled | noshow
  "type" : { CodeableConcept }, // 
     The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)
  "reason" : { CodeableConcept }, // The reason that this appointment is being scheduled, this is more clinical than administrative
  "description" : "<string>", // 
     The brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment field
  "start" : "<instant>", // R! Date/Time that the appointment is to take place
  "end" : "<instant>", // R! Date/Time that the appointment is to conclude
  "slot" : [{ Reference(Slot) }], // 
     The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot
  "location" : { Reference(Location) }, // 
     The primary location that this appointment is to take place
  "comment" : "<string>", // Additional comments about the appointment
  "order" : { Reference(Order) }, // An Order that lead to the creation of this appointment
  "participant" : [{ // R! List of participants involved in the appointment
    "type" : [{ CodeableConcept }], // Role of participant in the appointment
    "actor" : { Reference(Any) }, // 
      A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device
    "required" : "<code>", // required | optional | information-only
    "status" : "<code>" // R! accepted | declined | tentative | in-process | completed | needs-action
  }],
  "lastModifiedBy" : { Reference(Practitioner|Patient|RelatedPerson) }, // 
     Who recorded the appointment
  "lastModified" : "<dateTime>" // Date when the appointment was recorded
}

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Appointment DomainResourceA scheduled healthcare event for a patient and/or practitioner(s) where a service may take place at a specific date/time
... identifier 0..*IdentifierExternal Ids for this item
... priority 0..1integerThe 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) (Need to change back to CodeableConcept)
... status M1..1codepending | booked | arrived | fulfilled | cancelled | noshow
AppointmentStatus (Required)
... type 0..1CodeableConceptThe type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)
... reason 0..1CodeableConceptThe reason that this appointment is being scheduled, this is more clinical than administrative
ApptReason (Incomplete)
... description 0..1stringThe brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment field
... start 1..1instantDate/Time that the appointment is to take place
... end 1..1instantDate/Time that the appointment is to conclude
... slot 0..*SlotThe slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot
... location 0..1LocationThe primary location that this appointment is to take place
... comment 0..1stringAdditional comments about the appointment
... order 0..1OrderAn Order that lead to the creation of this appointment
... participant 1..*ElementList of participants involved in the appointment
.... type 0..*CodeableConceptRole of participant in the appointment
ParticipantType (Incomplete)
.... actor 0..1AnyA Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device
.... required 0..1coderequired | optional | information-only
ParticipantRequired (Required)
.... status 1..1codeaccepted | declined | tentative | in-process | completed | needs-action
ParticipationStatus (Required)
... lastModifiedBy 0..1Practitioner | Patient | RelatedPersonWho recorded the appointment
... lastModified 0..1dateTimeDate when the appointment was recorded

UML Diagram

Appointment (DomainResource)This records identifiers associated with this appointment concern that are defined by business processed 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 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) (Need to change back to CodeableConcept)priority : integer 0..1The 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 appointmentAppointmentStatus »The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)type : CodeableConcept 0..1The reason that this appointment is being scheduled, this is more clinical than administrativereason : CodeableConcept 0..1 « The Reason for the appointment to take placeApptReason+ »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..1Date/Time that the appointment is to take placestart : instant 1..1Date/Time that the appointment is to concludeend : instant 1..1The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slotslot : Reference(Slot) 0..*The primary location that this appointment is to take placelocation : Reference(Location) 0..1Additional comments about the appointmentcomment : string 0..1An Order that lead to the creation of this appointmentorder : Reference(Order) 0..1Who recorded the appointmentlastModifiedBy : Reference(Practitioner|Patient| RelatedPerson) 0..1Date when the appointment was recordedlastModified : dateTime 0..1ParticipantRole of participant in the appointmenttype : CodeableConcept 0..* « Role of participant in encounterParticipantType+ »A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Deviceactor : Reference(Any) 0..1Is 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 appointmentParticipantRequired »Participation status of the Patientstatus : code 1..1 « The Participation status of an appointmentParticipationStatus »List of participants involved in the appointmentparticipant1..*

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>
 <priority value="[integer]"/><!-- 0..1 
     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) (Need to change back to CodeableConcept) -->
 <status value="[code]"/><!-- 1..1 pending | booked | arrived | fulfilled | cancelled | noshow -->
 <type><!-- 0..1 CodeableConcept 
     The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself) --></type>
 <reason><!-- 0..1 CodeableConcept The reason that this appointment is being scheduled, this is more clinical than administrative --></reason>
 <description value="[string]"/><!-- 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 field -->
 <start value="[instant]"/><!-- 1..1 Date/Time that the appointment is to take place -->
 <end value="[instant]"/><!-- 1..1 Date/Time that the appointment is to conclude -->
 <slot><!-- 0..* Reference(Slot) 
     The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot --></slot>
 <location><!-- 0..1 Reference(Location) 
     The primary location that this appointment is to take place --></location>
 <comment value="[string]"/><!-- 0..1 Additional comments about the appointment -->
 <order><!-- 0..1 Reference(Order) An Order that lead to the creation of this appointment --></order>
 <participant>  <!-- 1..* List of participants involved in the appointment -->
  <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type>
  <actor><!-- 0..1 Reference(Any) 
      A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device --></actor>
  <required value="[code]"/><!-- 0..1 required | optional | information-only -->
  <status value="[code]"/><!-- 1..1 accepted | declined | tentative | in-process | completed | needs-action -->
 </participant>
 <lastModifiedBy><!-- 0..1 Reference(Practitioner|Patient|RelatedPerson) 
     Who recorded the appointment --></lastModifiedBy>
 <lastModified value="[dateTime]"/><!-- 0..1 Date when the appointment was recorded -->
</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
  "priority" : <integer>, // 
     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) (Need to change back to CodeableConcept)
  "status" : "<code>", // R! pending | booked | arrived | fulfilled | cancelled | noshow
  "type" : { CodeableConcept }, // 
     The type of appointments that is being booked (ideally this would be an identifiable service - which is at a location, rather than the location itself)
  "reason" : { CodeableConcept }, // The reason that this appointment is being scheduled, this is more clinical than administrative
  "description" : "<string>", // 
     The brief description of the appointment as would be shown on a subject line in a meeting request, or appointment list. Detailed or expanded information should be put in the comment field
  "start" : "<instant>", // R! Date/Time that the appointment is to take place
  "end" : "<instant>", // R! Date/Time that the appointment is to conclude
  "slot" : [{ Reference(Slot) }], // 
     The slot that this appointment is filling. If provided then the schedule will not be provided as slots are not recursive, and the start/end values MUST be the same as from the slot
  "location" : { Reference(Location) }, // 
     The primary location that this appointment is to take place
  "comment" : "<string>", // Additional comments about the appointment
  "order" : { Reference(Order) }, // An Order that lead to the creation of this appointment
  "participant" : [{ // R! List of participants involved in the appointment
    "type" : [{ CodeableConcept }], // Role of participant in the appointment
    "actor" : { Reference(Any) }, // 
      A Person of device that is participating in the appointment, usually Practitioner, Patient, RelatedPerson or Device
    "required" : "<code>", // required | optional | information-only
    "status" : "<code>" // R! accepted | declined | tentative | in-process | completed | needs-action
  }],
  "lastModifiedBy" : { Reference(Practitioner|Patient|RelatedPerson) }, // 
     Who recorded the appointment
  "lastModified" : "<dateTime>" // Date when the appointment was recorded
}

 

Alternate definitions: Schema/Schematron, Resource Profile (XML, JSON), Questionnaire

5.24.3.1 Terminology Bindings

PathDefinitionTypeReference
Appointment.status The free/busy status of an appointmentFixedhttp://hl7.org/fhir/appointmentstatus
Appointment.reason The Reason for the appointment to take placeIncompletehttp://hl7.org/fhir/vs/encounter-reason
Appointment.participant.type Role of participant in encounterIncompletehttp://hl7.org/fhir/vs/encounter-participant-type
Appointment.participant.required Is the Participant required to attend the appointmentFixedhttp://hl7.org/fhir/participantrequired
Appointment.participant.status The Participation status of an appointmentFixedhttp://hl7.org/fhir/participationstatus

5.24.4 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. Brian: Does this seem right that the filler and placer are applied in this way?

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

5.24.5 Search Parameters

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

NameTypeDescriptionPaths
actorreferenceAny one of the individuals participating in the appointmentAppointment.participant.actor
(Any)
datedateAppointment date/time.Appointment.start
partstatustokenThe Participation status of the subject, or other participant on the appointmentAppointment.participant.status
patientreferenceOne of the individuals of the appointment is this patientAppointment.participant.actor
(Patient)
statustokenThe overall status of the appointmentAppointment.status