Workflow
This
page
is
part
of
the
FHIR
Specification
(v1.0.2:
DSTU
(v3.0.2:
STU
2).
3).
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
R3
R2
|
Patient
Administration
Work
Group
|
Maturity
Level
:
|
Trial Use | 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 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
also
to
ease
exposure
to
other
appointment
/
calendar
standards
widely
used
outside
of
healthcare.
Before
an
appointment
can
be
made
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,
Type
and
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
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
resources,
etc.
This
step
is
optional
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.
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".
The
reply
process
is
simply
performed
by
the
person/system
handing
the
requests
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
Appointment
is
updated.
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.
These
types
of
requests
are
typically
handled
by
selecting
a
specific
time
from
a
list
of
available
slots.
Then
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
appointmentAppointment resource (andtheother 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
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
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
clinical
implications.
In
general
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
the
appointment
resource
Resource
is
probably
not
appropriate
to
be
used.
In
these
cases
an
encounter
Encounter
should
be
created.
The
Appointment
request
pattern
used
is
different
to
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
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
location
of
the
appointment
is
to
be
defined
by
using
a
participant
that
references
a
location
Location
or
HealthcareService.
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
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
Appointment
|
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 Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension |
|
identifier
|
Σ | 0..* | Identifier |
External
Ids
for
this
item
|
status
|
?! Σ | 1..1 | code |
proposed
|
pending
|
booked
|
arrived
|
fulfilled
|
cancelled
|
noshow
|
entered-in-error
AppointmentStatus ( Required ) |
|
serviceCategory
|
Σ | 0..1 | CodeableConcept |
A
broad
categorisation
of
the
service
that
is
to
be
performed
during
this
appointment
ServiceCategory ( Example ) |
|
serviceType
| Σ | 0..* | CodeableConcept |
The
specific
service
that
is
ServiceType ( Example ) |
|
specialty
| Σ | 0..* | CodeableConcept |
The
specialty
of
a
practitioner
that
would
be
required
to
perform
the
service
requested
in
this
appointment
Practice Setting Code Value Set ( Preferred ) |
|
appointmentType
| Σ | 0..1 | CodeableConcept |
The
style
of
appointment
or
patient
that
has
been
booked
in
the
slot
(not
service
type)
v2 Appointment reason codes ( Preferred ) |
|
reason
|
Σ | 0..* | CodeableConcept |
Reason
this
appointment
is
scheduled
Encounter Reason Codes ( |
indication
| 0..* | Reference ( Condition | Procedure ) |
Reason
the
appointment
is
to
takes
place
(resource)
| |
|
priority
|
0..1 | unsignedInt | Used to make informed decisions if needing to re-prioritize | |
|
description
|
0..1 | string | Shown on a subject line in a meeting request, or appointment list | |
|
supportingInformation
| 0..* | Reference ( Any ) |
Additional
information
to
support
the
appointment
| |
|
start
|
Σ | 0..1 | instant | When appointment is to take place |
|
end
|
Σ | 0..1 | instant | When appointment is to conclude |
|
minutesDuration
|
0..1 | positiveInt | Can be less than start/end (e.g. estimate) | |
|
slot
|
0..* | Reference ( Slot ) |
The
slots
that
this
appointment
is
filling
|
|
|
created
| 0..1 | dateTime | The date that this appointment was initially created | |
|
comment
|
0..1 | string | Additional comments | |
|
incomingReferral
| 0..* | Reference ( ReferralRequest ) |
The
ReferralRequest
provided
as
information
to
allocate
to
the
Encounter
| |
participant
|
I | 1..* | BackboneElement |
Participants
involved
in
appointment
+ Either the type or actor on the participant |
type
|
Σ | 0..* | CodeableConcept |
Role
of
participant
in
the
appointment
ParticipantType ( |
|
actor
|
Σ | 0..1 | Reference ( Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location ) | Person, Location/HealthcareService or Device |
|
required
|
Σ | 0..1 | code |
required
|
optional
|
information-only
ParticipantRequired ( Required ) |
status
|
1..1 | code |
accepted
|
declined
|
tentative
|
needs-action
ParticipationStatus ( Required ) |
|
|
requestedPeriod
| 0..* | Period |
Potential
date/time
interval(s)
requested
to
allocate
the
appointment
within
| |
|
Documentation
for
this
format
|
||||
UML Diagram ( Legend )
XML Template
<<Appointment xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension -->
<</identifier> < <</type> <</reason> < < < < < <</slot> < < <</type> <|<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(ReferralRequest) The ReferralRequest 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
{ "resourceType" : "",{" " " " " " " " " " " " " "|"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(ReferralRequest) }], // The ReferralRequest 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/> .
Changes since DSTU2
| Appointment | |
| Appointment.serviceCategory |
|
| Appointment.serviceType |
|
| Appointment.specialty |
|
| Appointment.appointmentType |
|
| Appointment.reason |
|
| Appointment.indication |
|
| Appointment.supportingInformation |
|
| Appointment.created |
|
| Appointment.incomingReferral |
|
| Appointment.participant.type |
|
| Appointment.requestedPeriod |
|
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
| Name | Flags | Card. | Type |
Description
&
Constraints
|
|---|---|---|---|---|
|
Appointment
|
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 Elements defined in Ancestors: id , meta , implicitRules , language , text , contained , extension , modifierExtension |
|
|
identifier
|
Σ | 0..* | Identifier |
External
Ids
for
this
item
|
|
status
|
?! Σ | 1..1 | code |
proposed
|
pending
|
booked
|
arrived
|
fulfilled
|
cancelled
|
noshow
|
entered-in-error
AppointmentStatus ( Required ) |
|
serviceCategory
|
Σ | 0..1 | CodeableConcept |
A
broad
categorisation
of
the
service
that
is
to
be
performed
during
this
appointment
ServiceCategory ( Example ) |
|
serviceType
| Σ | 0..* | CodeableConcept |
The
specific
service
that
is
ServiceType ( Example ) |
|
specialty
| Σ | 0..* | CodeableConcept |
The
specialty
of
a
practitioner
that
would
be
required
to
perform
the
service
requested
in
this
appointment
Practice Setting Code Value Set ( Preferred ) |
|
appointmentType
| Σ | 0..1 | CodeableConcept |
The
style
of
appointment
or
patient
that
has
been
booked
in
the
slot
(not
service
type)
v2 Appointment reason codes ( Preferred ) |
|
reason
|
Σ | 0..* | CodeableConcept |
Reason
this
appointment
is
scheduled
Encounter Reason Codes ( |
|
indication
| 0..* | Reference ( Condition | Procedure ) |
Reason
the
appointment
is
to
takes
place
(resource)
| |
|
priority
|
0..1 | unsignedInt | Used to make informed decisions if needing to re-prioritize | |
|
description
|
0..1 | string | Shown on a subject line in a meeting request, or appointment list | |
|
supportingInformation
| 0..* | Reference ( Any ) |
Additional
information
to
support
the
appointment
| |
|
start
|
Σ | 0..1 | instant | When appointment is to take place |
|
end
|
Σ | 0..1 | instant | When appointment is to conclude |
|
minutesDuration
|
0..1 | positiveInt | Can be less than start/end (e.g. estimate) | |
|
slot
|
0..* | Reference ( Slot ) |
The
slots
that
this
appointment
is
filling
|
|
|
created
| 0..1 | dateTime | The date that this appointment was initially created | |
|
comment
|
0..1 | string | Additional comments | |
|
incomingReferral
| 0..* | Reference ( ReferralRequest ) |
The
ReferralRequest
provided
as
information
to
allocate
to
the
Encounter
| |
|
participant
|
I | 1..* | BackboneElement |
Participants
involved
in
appointment
+ Either the type or actor on the participant |
|
type
|
Σ | 0..* | CodeableConcept |
Role
of
participant
in
the
appointment
ParticipantType ( |
|
actor
|
Σ | 0..1 | Reference ( Patient | Practitioner | RelatedPerson | Device | HealthcareService | Location ) | Person, Location/HealthcareService or Device |
|
required
|
Σ | 0..1 | code |
required
|
optional
|
information-only
ParticipantRequired ( Required ) |
|
status
|
1..1 | code |
accepted
|
declined
|
tentative
|
needs-action
ParticipationStatus ( Required ) |
|
|
requestedPeriod
| 0..* | Period |
Potential
date/time
interval(s)
requested
to
allocate
the
appointment
within
| |
|
Documentation
for
this
format
|
||||
XML Template
<<Appointment xmlns="http://hl7.org/fhir"><</identifier> < <</type> <</reason> < < < < < <</slot> < < <</type> <|<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(ReferralRequest) The ReferralRequest 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
{ "resourceType" : "",{" " " " " " " " " " " " " "|"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(ReferralRequest) }], // The ReferralRequest 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/> .
Changes
since
DSTU2
| Appointment | |
| Appointment.serviceCategory |
|
| Appointment.serviceType |
|
| Appointment.specialty |
|
| Appointment.appointmentType |
|
| Appointment.reason |
|
| Appointment.indication |
|
| Appointment.supportingInformation |
|
| Appointment.created |
|
| Appointment.incomingReferral |
|
| Appointment.participant.type |
|
| Appointment.requestedPeriod |
|
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:
Schema
/
Schematron
,
Resource
Profile
Master
Definition
(
XML
,
JSON
),
Questionnaire
XML
Schema
/
Schematron
(for
)
+
JSON
Schema
,
ShEx
(for
Turtle
)
| Path | Definition | Type | Reference |
|---|---|---|---|
| Appointment.status | The free/busy status of an appointment. | Required | AppointmentStatus |
| Appointment.serviceCategory | Example |
| |
| Appointment.serviceType | Example | ServiceType | |
| Appointment.specialty | Preferred | Practice Setting Code Value Set | |
| Appointment.appointmentType | Preferred | v2 Appointment reason codes | |
| Appointment.reason | The Reason for the appointment to take place. |
|
Encounter Reason Codes |
| Appointment.participant.type | Role of participant in encounter. |
|
ParticipantType |
| Appointment.participant.required | Is the Participant required to attend the appointment. | Required | ParticipantRequired |
| Appointment.participant.status | The Participation status of an appointment. | Required | ParticipationStatus |
on
:
:
| Activity Description | Slot | Appointment | Appointment Response | Encounter |
|---|---|---|---|---|
|
The
(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
(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
(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
(Role: Scheduler) |
freeBusyType = FREE | ||
|
(Role: Requester) |
status
=
pending
participant.status = needs-action |
||
|
The
appointment
request
is
processed
and
the
slot
status
updated
(Role: Scheduler) |
freeBusyType = BUSY-TENTATIVE | ||
|
Participant
(Role: Participant) |
participantStatus = declined | ||
|
The
appointment
is
cancelled
(Role: Scheduler) |
freeBusyType = FREE |
status
=
cancelled
participant.status = declined |
| Activity Description | Slot | Appointment | Appointment Response |
|---|---|---|---|
|
The
(Role: Scheduler) |
freeBusyType = FREE | ||
|
An
appointment
is
requested
(Role: Requester) |
status
=
proposed
participant(Brian).status = needs-action participant(Peter).status = needs-action |
||
|
The
(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) |
)
The
appointment
information
is
effectively
the
same
between
the
filler
and
placer,
and
given
the
nature
of
the
fhir
FHIR
resource,
there
is
only
a
single
resource
for
both
purposes.
The
Placer
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
.
DSTUSTU Note: Implementer feedbackonis sought on the values for Appointment.priority and how interoperable they are. Using an extension to record acodeableconceptCodeableConcept for named values may be tested at a futureconnectathon.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 |
| In Common |
| actor | reference | Any one of the individuals participating in the appointment |
Appointment.participant.actor
( Practitioner , Device , |
|
| appointment-type | token | The style of appointment or patient that has been booked in the slot (not service type) | Appointment.appointmentType | |
| date | date | Appointment date/time. | Appointment.start | |
| identifier | token | An Identifier of the Appointment | Appointment.identifier | |
| incomingreferral | reference | The ReferralRequest provided as information to allocate to the Encounter |
Appointment.incomingReferral
( ReferralRequest ) | |
| location | reference | This location is listed in the participants of the appointment |
Appointment.participant.actor
( Location ) |
|
| part-status | token | The Participation status of the subject, or other participant on the appointment. Can be used to locate participants that have not responded to meeting requests. | Appointment.participant.status | |
| patient | reference | One of the individuals of the appointment is this patient |
Appointment.participant.actor
( Patient ) |
|
| practitioner | reference | One of the individuals of the appointment is this practitioner |
Appointment.participant.actor
( Practitioner ) |
|
| service-type | token | The specific service that is to be performed during this appointment | Appointment.serviceType | |
| status | token | The overall status of the appointment | Appointment.status |
©
®©
HL7.org
2011+.
FHIR
DSTU2
(v1.0.2-7202)
Release
3
(STU;
v3.0.2-11200)
generated
on
Sat,
Thurs,
Oct
24,
2015
07:43+1100.
2019
11:53+1100.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU1
DSTU2
|
|
Propose
a
change