This
page
is
part
of
the
FHIR
Specification
(v0.0.82:
(v1.0.2:
DSTU
1).
2).
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
Patient
Administration
Work
Group
|
Maturity Level : 1 | Compartments : 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 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.
Before
an
appointment
can
be
made
the
address
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,
any
formatting
information
which
indicates
how
to
make
the
request.
This
is
typically
handled
via
the
Schedule
resource.
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.
The
request
is
performed
by
posting
When
an
appointment
is
required,
a
requester
creates
new
Appointment
to
resource
with
the
address
found
during
discovery.
This
will
Appointment.status="proposed".
All
included
participants
(optional
or
mandatory)
should
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
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,
such
as
certain
users
do
statuses
may
be
automatically
updated,
for
example:
"reject
because
the
requested
participant
is
on
vacation"
or
"this
type
of
user
is
not
have
permission
allowed
to
request
certain
appointments)
those
specific
appointments".
The
reply
process
is
simply
performed
by
the
person/system
handing
the
requests
updating
the
Participant
Statuses
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.
The
Requester
requester
(organizer)
of
the
appointment
checks
for
the
overall
status
of
the
appointment
(and
appointmentresponses
appointment
responses,
where
applicable)
using
fhir
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.
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.
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.

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
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, 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
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.
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
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
|
I | DomainResource |
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)
Only proposed or cancelled appointments can be missing start/end dates Either start and end are specified, or neither |
|
|
Σ | 0..* | Identifier | External Ids for this item |
|
?! Σ | 1..1 | code |
proposed
|
pending
|
booked
|
arrived
|
fulfilled
|
cancelled
|
noshow
AppointmentStatus ( Required ) |
|
Σ | 0..1 | CodeableConcept |
The
type
of
appointment
that
is
being
booked
|
|
Σ | 0..1 | CodeableConcept |
Reason
this
appointment
is
|
|
0..1 |
|
Used
to
make
informed
decisions
if
needing
to
re-prioritize
|
|
|
0..1 | string |
Shown
on
a
subject
line
in
a
meeting
request,
or
appointment
|
|
|
Σ | 0..1 | instant | When appointment is to take place |
|
Σ | 0..1 | instant | When appointment is to conclude |
|
0..1 |
|
Can
be
|
|
|
0..* |
|
If provided, then no schedule and start/end values MUST match slot | |
|
0..1 |
|
Additional comments | |
|
I | 1..* |
|
Participants
involved
in
Either the type or actor on the participant MUST be specified |
|
Σ | 0..* | CodeableConcept |
Role
of
participant
in
the
appointment
ParticipantType ( Required ) |
|
Σ | 0..1 | Reference ( Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location ) |
Person,
Location/HealthcareService
or
Device
|
|
Σ | 0..1 | code |
required
|
optional
|
information-only
ParticipantRequired ( Required ) |
|
1..1 | code |
accepted
|
declined
|
tentative
|
needs-action
ParticipationStatus ( Required ) |
|
Documentation
for
this
format
| ||||
UML Diagram
XML Template
<Appointment xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension -->
<</identifier> <<identifier><!-- 0..* Identifier External Ids for this item --></identifier> <status value="[code]"/><!-- 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow --> <type><!-- 0..1 CodeableConcept The type of appointment that is being booked --></type><</reason> < 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) < 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 < < < 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> < <</order> <<reason><!-- 0..1 CodeableConcept Reason this appointment is scheduled --></reason> <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 --> <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) If provided, then no schedule and start/end values MUST match slot --></slot> <comment value="[string]"/><!-- 0..1 Additional comments --> <participant> <!-- 1..* Participants involved in appointment --> <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type> <actor><!-- 0..1 Reference(Patient|Practitioner|RelatedPerson|Device|A Person, Location/HealthcareService or Device that is participating in the appointment</actor> < <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> </Appointment>
JSON Template
{
"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
"type" : { CodeableConcept }, // The type of appointment that is being booked
"
"
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)
"
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
"
"
"
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
"
"
"
"reason" : { CodeableConcept }, // Reason this appointment is scheduled
"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
"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) }], // If provided, then no schedule and start/end values MUST match slot
"comment" : "<string>", // Additional comments
"participant" : [{ // R! Participants involved in appointment
"type" : [{ CodeableConcept }], // Role of participant in the appointment
"actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
A Person, Location/HealthcareService or Device that is participating in the appointment
"
"
HealthcareService|Location) }, // Person, Location/HealthcareService or Device
"required" : "<code>", // required | optional | information-only
"status" : "<code>" // R! accepted | declined | tentative | needs-action
}]
}
Structure
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
|
I | DomainResource |
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)
Only proposed or cancelled appointments can be missing start/end dates Either start and end are specified, or neither |
|
|
Σ | 0..* | Identifier | External Ids for this item |
|
?! Σ | 1..1 | code |
proposed
|
pending
|
booked
|
arrived
|
fulfilled
|
cancelled
|
noshow
AppointmentStatus ( Required ) |
|
Σ | 0..1 | CodeableConcept |
The
type
of
appointment
that
is
being
booked
|
|
Σ | 0..1 | CodeableConcept |
Reason
this
appointment
is
|
|
0..1 |
|
Used
to
make
informed
decisions
if
needing
to
re-prioritize
|
|
|
0..1 | string |
Shown
on
a
subject
line
in
a
meeting
request,
or
appointment
|
|
|
Σ | 0..1 | instant | When appointment is to take place |
|
Σ | 0..1 | instant | When appointment is to conclude |
|
0..1 |
|
Can
be
|
|
|
0..* |
|
If provided, then no schedule and start/end values MUST match slot | |
|
0..1 |
|
Additional comments | |
|
I | 1..* |
|
Participants
involved
in
Either the type or actor on the participant MUST be specified |
|
Σ | 0..* | CodeableConcept |
Role
of
participant
in
the
appointment
ParticipantType ( Required ) |
|
Σ | 0..1 | Reference ( Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location ) |
Person,
Location/HealthcareService
or
Device
|
|
Σ | 0..1 | code |
required
|
optional
|
information-only
ParticipantRequired ( Required ) |
|
1..1 | code |
accepted
|
declined
|
tentative
|
needs-action
ParticipationStatus ( Required ) |
|
Documentation
for
this
format
| ||||
XML Template
<Appointment xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension -->
<</identifier> <<identifier><!-- 0..* Identifier External Ids for this item --></identifier> <status value="[code]"/><!-- 1..1 proposed | pending | booked | arrived | fulfilled | cancelled | noshow --> <type><!-- 0..1 CodeableConcept The type of appointment that is being booked --></type><</reason> < 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) < 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 < < < 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> < <</order> <<reason><!-- 0..1 CodeableConcept Reason this appointment is scheduled --></reason> <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 --> <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) If provided, then no schedule and start/end values MUST match slot --></slot> <comment value="[string]"/><!-- 0..1 Additional comments --> <participant> <!-- 1..* Participants involved in appointment --> <type><!-- 0..* CodeableConcept Role of participant in the appointment --></type> <actor><!-- 0..1 Reference(Patient|Practitioner|RelatedPerson|Device|A Person, Location/HealthcareService or Device that is participating in the appointment</actor> < <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> </Appointment>
JSON Template
{
"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
"type" : { CodeableConcept }, // The type of appointment that is being booked
"
"
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)
"
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
"
"
"
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
"
"
"
"reason" : { CodeableConcept }, // Reason this appointment is scheduled
"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
"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) }], // If provided, then no schedule and start/end values MUST match slot
"comment" : "<string>", // Additional comments
"participant" : [{ // R! Participants involved in appointment
"type" : [{ CodeableConcept }], // Role of participant in the appointment
"actor" : { Reference(Patient|Practitioner|RelatedPerson|Device|
A Person, Location/HealthcareService or Device that is participating in the appointment
"
"
HealthcareService|Location) }, // Person, Location/HealthcareService or Device
"required" : "<code>", // required | optional | information-only
"status" : "<code>" // R! accepted | declined | tentative | needs-action
}]
}
Alternate definitions: Schema / Schematron , Resource Profile ( XML , JSON ), Questionnaire
| Path | Definition | Type | Reference |
|---|---|---|---|
| Appointment.status |
The
free/busy
status
of
an
|
Required |
|
| Appointment.type |
Additional
details
about
where
the
content
was
created
(e.g.
clinical
|
Preferred |
|
| Appointment.reason |
The
Reason
for
the
appointment
to
take
|
Required |
|
| Appointment.participant.type |
Role
of
participant
in
|
Required |
|
| Appointment.participant.required |
Is
the
Participant
required
to
attend
the
|
Required |
|
| Appointment.participant.status |
The
Participation
status
of
an
|
Required |
|

| Activity Description | Slot | Appointment | Appointment Response | Encounter |
|---|---|---|---|---|
|
The
Schedule
is
created/published
(Role: Scheduler) |
freeBusyType
=
FREE
|
|||
|
An
appointment
request
is
|
status
=
pending
|
|||
|
The
appointment
request
is
processed
and
the
slot
status
updated
|
freeBusyType
=
BUSY-TENTATIVE
|
|||
|
The
appointment
is
accepted
as
described
–
by
all
|
participantStatus
=
accepted
|
|||
|
The
appointment
is
confirmed
as
accepted
by
all
|
freeBusyType
=
|
status
=
booked
| ||
|
Optional:
Preparation
for
the
appointment
begins
–
could
be
preparing
a
room
for
the
appointment
|
status
=
planned
(optional)
|
|||
|
The
patient
arrives
for
the
appointment,
often
sitting
in
a
waiting
|
status
=
arrived
|
status
=
arrived
|
||
|
The
practitioner
and
the
patient
meet
and
the
provision
of
the
service
begins,
appointment
is
finished
with
|
status
=
fulfilled
|
status = in-progress | ||
|
The
encounter
| status = finished |
| Activity Description | Slot | Appointment | Appointment Response |
|---|---|---|---|
|
The
Schedule
is
created/published
(Role: Scheduler) |
freeBusyType
=
FREE
|
||
|
Appointment
Request
is
created
(Role: Requester) |
status
=
pending
|
||
|
The
appointment
request
is
processed
and
the
slot
status
updated
|
freeBusyType
=
BUSY-TENTATIVE
|
||
|
Participant
Declines
the
Appointment
(Role: Participant) | participantStatus = declined | ||
|
The
appointment
is
cancelled
| freeBusyType = FREE |
status
=
cancelled
|
| Activity Description | Slot | Appointment | Appointment Response |
|---|---|---|---|
|
The
Schedule
is
created/published
(Role: Scheduler) |
freeBusyType
=
FREE
|
||
|
An
appointment
is
requested
with
Brian
and
Peter
(Role: Requester) |
status
=
|
||
|
The
Schedule
is
updated
to
inform
others
of
interest
in
the
slot
|
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)
|
||
|
Brian
accepts
the
appointment
(Role: Participant-Brian) |
(Brian).participantStatus
=
accepted
|
||
|
Appointment
updated
(Role: Scheduler) | participant(Brian).status = accepted | ||
|
| (Peter).participantStatus = accepted | ||
|
Appointment
updated
| freeBusyType = BUSY |
status
=
booked
|
| Activity Description | Slot | Appointment | Appointment Response | Encounter |
|---|---|---|---|---|
|
|
freeBusyType
=
|
status
=
booked
| ||
|
Appointment
is
updated
as
a
noshow
| status = noshow |
(no
encounter
|
)
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.
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
.
DSTU Note: Implementer feedback on 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.
| Name | Type | Description | Paths |
| actor | reference | Any one of the individuals participating in the appointment |
Appointment.participant.actor
( Device , Location , HealthcareService , Patient , Practitioner , RelatedPerson ) |
| date | date | Appointment date/time. | Appointment.start |
| identifier | token | An Identifier of the Appointment | Appointment.identifier |
| location | reference | This location is listed in the participants of the appointment |
Appointment.participant.actor
( Location ) |
|
|
token | The Participation status of the subject, or other participant on the appointment. Can be used to locate participants that have not responded to meeting requests. | Appointment.participant.status |
| patient | reference | One of the individuals of the appointment is this patient |
Appointment.participant.actor
( Patient ) |
| practitioner | reference | One of the individuals of the appointment is this practitioner |
Appointment.participant.actor
( Practitioner ) |
| status | token | The overall status of the appointment | Appointment.status |