This
page
is
part
of
the
FHIR
Specification
(v1.8.0:
STU
3
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
12.1
Workflow
Description
Workflow
is
an
essential
part
of
healthcare
-
orders,
care
protocols,
referrals
are
the
drivers
of
most
activity
within
in-patient
settings
and
a
great
deal
of
activity
in
community
care
as
well.
FHIR
is
concerned
with
workflow
when
there's
a
need
to
share
information
about
workflow
state
or
relationships,
when
there's
a
need
to
coordinate
or
drive
the
execution
of
workflow
across
systems
and
when
there's
a
need
to
define
allowed
actions,
dependencies
and
conditions
on
behavior.
Workflow
state
&
relationships
FHIR
does
not
need
to
be
used
for
the
execution
of
workflow.
Orders,
care
plans,
lab
results,
hospital
admissions,
claim
payments
and
other
records
can
all
be
shared
using
FHIR
without
the
process
to
actually
solicit
fulfillment
of
those
orders
or
requesting
payment
of
those
claims
being
driven
by
a
FHIR
transaction.
Interoperable
support
for
workflow
execution
is
actually
a
more
advanced
FHIR
activity
because
it
requires
a
higher
degree
of
standardization.
Rather
than
merely
standardizing
the
data
to
exchange,
interoperable
workflow
execution
requires
standardization
of
the
processes,
roles
and
activities
of
the
different
systems.
However,
even
without
using
FHIR
for
workflow
execution,
there's
still
a
need
to
standardize
the
data
elements
related
to
workflow:
how
does
an
event
or
a
result
point
to
the
order
that
authorized
it?
How
do
parent
steps
and
child
steps
get
linked
together?
How
does
a
care
plan
identify
what
protocol
it's
adhering
to?
FHIR
defines
three
categories
of
resources
that
are
involved
in
activities
-
requests
,
events
and
definitions
.
Each
of
these
different
types
has
a
"pattern"
associated
with
it.
Resources
that
fall
into
that
type
are
encouraged
to
adhere
to
their
respective
pattern.
These
patterns
provide
standard
elements
that
are
typical
for
most
resources
of
each
type.
Strict
adherence
is
not
required
as
work
groups
are
expected
to
align
with
typical
domain
behavior
and
requirements
as
more
authoritative
than
"desired"
architectural
patterns.
In
some
cases,
capabilities
might
be
supported
with
extensions
rather
than
core
elements
where
a
pattern
capability
is
deemed
to
be
"not
common,
but
still
relevant"
for
a
given
resource.
A
full
description
of
the
patterns
and
their
interrelationships
can
be
found
in
the
Workflow
Resource
Patterns
section
of
this
page.
Workflow
execution
In
addition
to
defining
patterns
for
resources
used
in
workflow
processes,
FHIR
supports
the
execution
of
those
processes
as
well.
However,
FHIR
does
not
define
a
"one
size
fits
all"
solution
for
workflow
architecture.
FHIR
supports
a
variety
of
interoperability
paradigms
and
most
of
them
(
REST
,
Messaging
and
Services
)
provide
support
for
driving
workflow
execution.
(The
Document
paradigm
does
not
directly
support
driving
behavior,
though
it
can
be
combined
with
one
of
the
other
patterns
to
do
so.)
In
addition,
several
of
these
paradigms
allow
multiple
approaches
to
supporting
workflow,
depending
on
the
context
and
needs
of
the
workflow
process.
The
Workflow
Communication
Patterns
section
of
this
page
describes
a
number
of
options
for
workflow
execution,
summarizes
their
respective
pros
and
cons
and
makes
recommendations
for
the
circumstances
in
which
they
might
best
be
used.
Workflow
definition
The
definition
of
protocols,
order
sets,
guidelines
and
other
structures
that
define
what
sorts
of
activities
should
occur,
what
order
they
should
occur
on,
what
dependencies
they
have,
in
what
circumstances
they
should
start
or
end,
etc.
is
handled
by
a
pair
of
resources:
-
PlanDefinition
defines
the
interrelationships
of
steps
and
the
rules
around
their
execution
-
ActivityDefinition
defines
an
activity
to
be
performed
as
a
single
step
The
use
of
these
two
artifacts
is
documented
TODO.
12.1.1
Workflow
Resource
Patterns
Not
all
resources
in
FHIR
are
related
to
workflow
-
many
are
used
to
describe
entities
and
roles
(patients,
medications,
etc.)
or
infrastructure
(structure
definitions,
value
sets,
etc.).
However,
a
large
proportion
of
the
FHIR
resources
are
devoted
to
the
description
of
activities
in
one
fashion
or
another
and
almost
all
of
these
fall
into
the
realm
of
workflow
-
they
describe
things
that
can
be
done
(definitions),
are
desired
to
be
done
(requests)
or
that
have
been
done
(events).
The
table
below
summarizes
the
list
of
workflow-relevant
resources:
12.1.1.1
Workflow
resources
|
Requests
|
Resources
that
ask
for
or
express
a
desire/intention
for
something
to
be
done
|
|
|
|
|
|
|
Events
|
Resources
that
express
that
something
has
been
done
and
which
can
potentially
be
done
as
a
result
of
a
request
|
|
|
|
|
|
|
Definitions
|
Resources
that
define
something
that
can
potentially
happen
in
a
patient
and
time-independent
manner
|
|
|
|
|
|
|
*
|
The
Appointment
and
AppointmentResponse
resources
do
not
follow
the
same
sort
of
request/response
pattern
as
the
other
resources.
Their
design
is
based
on
iCal
conventions,
so
their
model
won't
reflect
the
same
alignment
as
most
other
resources.
They
are
included
here
for
completeness.
|
|
†
|
ProcessRequest
and
ProcessResponse
are
candidates
for
retirement
with
their
function
subsumed
by
Task
|
|
‡
|
The
Task
resource
takes
on
characteristics
of
both
"requests"
and
"events"
and
thus
shares
characteristics
from
both
patterns
|
Note
that
requests,
events
and
definitions
don't
exist
in
a
1:1:1
relationship.
Some
requests
and
events
have
obvious
pairings.
For
example,
a
SupplyRequest
will
generally
always
pair
with
a
SupplyDelivery
.
The
same
goes
for
EnrollmentRequest
/
EnrollmentResponse
,
etc.
On
the
other
hand,
for
other
resources
there
isn't
a
strict
pairing.
A
ReferralRequest
might
be
responded
to
by
an
Encounter
,
DiagnosticReport
,
Procedure
,
RiskAssessment
,
etc.
Similarly,
a
Procedure
might
be
triggered
by
a
DiagnosticRequest
,
ProcedureRequest
,
or
ReferralRequest
.
The
set
of
common
linkages
should
be
asserted
in
their
respective
resources.
The
specific
types
of
responses
for
a
given
request
will
be
governed
by
the
Request.code,
any
workflow
definitions/protocols
referenced
and
local
convention.
12.1.1.2
Workflow
Resource
Relationships
These
three
patterns
of
resources
have
a
standard
set
of
relationships,
both
with
themselves,
as
well
as
with
each
other.
Specifically:
-
both
requests
and
events
can
point
to
their
respective
definitions
-
events
and
requests
can
point
to
the
proposals,
plans
or
orders
they
are
based
on
-
events
and
definitions
can
be
organized
into
parent-child
relationships
of
parents
and
components
-
definitions
and
requests
can
both
replace
prior
versions
of
the
same
type
of
artifact
This
list
of
relationships
is
not
exhaustive,
but
covers
those
that
are
"standardized"
as
part
of
the
patterns.
Further
description
and
guidance
on
these
relationships
can
be
found
in
the
Request
,
Event
and
Definition
logical
models.
12.1.1.3
Request
Resource
Pattern
Requests
are
resources
that
represent
the
proposal,
plan
or
order
for
an
activity
to
occur.
A
Request
pattern
defines
the
common
elements
typically
present
on
all
request
resources.
The
amount
of
information
needed
for
a
Request
to
be
actionable
can
vary
by
circumstance.
Some
request
instances
may
not
be
"fully
specified"
-
additional
information
from
protocol,
patient
preference
and/or
professional
decision-making
may
be
necessary
before
the
authorized
action
can
occur.
For
example,
a
MedicationOrder
might
be
specified
without
indicating
a
strength
or
route
in
situations
where
the
pharmacy
(or
even
nursing
information)
has
the
authority
to
determine
those
parameters.
A
VisionPrescription
might
not
be
actionable
until
frames
have
been
chosen
and
the
necessary
measurements
of
the
patient's
face
have
been
taken
to
allow
the
lenses
to
be
positioned
appropriately
within
the
frames.
All
requests
with
an
intent
of
"order"
authorize
something.
Whether
what
is
authorized
is
sufficient
to
be
immediately
actionable
depends
on
who
is
fulfilling
the
order
and
the
context
in
which
the
fulfillment
request
is
made.
The
determination
of
whether
a
given
"request"
is
actionable
may
be
made
by
the
systems
involved
or
the
humans
being
asked
to
act.
As
well,
the
existence
of
a
"Request"
instance
doesn't
necessarily
imply
that
fufillment
will
be
requested
immediately
-
or
even
ever.
The
decision
to
request
fulfillment
may
be
delegated
to
the
patient
or
to
down-stream
practitioners.
Such
fufilling
practitioners
may
need
to
capture
additional
information
prior
to
executing
the
fufillment.
12.1.1.4
Event
Resource
Pattern
Events
are
resources
that
represent
the
ongoing
or
completed
execution
of
some
activity
or
observation.
For
example,
a
clinical
procedure,
a
financial
transaction,
the
recording
of
a
diagnosis,
etc.
An
Event
pattern
defines
the
common
elements
typically
present
on
all
event
resources.
12.1.1.5
Definition
Resource
Pattern
Definitions
are
resources
that
represent
activities
that
could
be
performed
in
a
time
and
subject-independent
manner
such
as
a
protocol,
order
set,
clinical
guideline,
etc.
A
Definition
pattern
defines
the
common
elements
typically
present
on
all
event
resources.
12.1.2
Workflow
Communication
Patterns
Workflow
execution
is
supported
in
FHIR
by
a
large
number
of
mechanisms.
In
considering
how
best
to
interoperate
around
workflow,
there
are
a
number
of
considerations:
-
Which
paradigm
do
you
want
to
use
(REST,
messaging
or
services)?
-
Is
there
infrastructure
in
place
to
support
polling,
push
notifications
via
subscriptions
or
both?
-
Is
there
a
need
for
confirmation
that
the
desired
performer
agrees
to
act,
or
can
that
be
presumed?
-
Is
there
a
need
to
negotiate
whether/how
the
requested
action
will
be
performed?
-
Can
the
requesting
and
performing
system
communicate
directly?
Are
they
able
to
post
to
each
other's
servers
(if
using
REST)?
-
Is
there
an
ability/need
to
have
a
queue
server
to
facilitate
workflow
execution?
-
How
many
potential
actors
are
involved?
-
Will
the
workflow
always
be
directed
or
is
there
a
pool
of
potential
performers
who
could
choose
to
perform
the
requested
action?
This
section
highlights
some
of
the
more
common
patterns
and
identifies
their
characteristics
and
limitations
and
provides
recommendations
on
when
each
approach
may
be
most
useful
or
relevant.
Please
note
that
this
list
of
patterns
is
not
exhaustive.
Patterns
can
be
combined
in
various
ways
and
there
are
likely
some
possibilities
we
haven't
thought
about
yet
(feel
free
to
submit
additional
patterns
using
the
'submit
a
change'
link
at
the
bottom
of
the
page).
As
well,
the
recommendations
given
here
are
just
that
-
recommendations.
Implementers
are
free
to
choose
which
patterns
they
wish
to
support.
Because
of
this,
tight
interoperability
around
workflow
execution
(as
with
any
other
tight
interoperability
using
FHIR)
will
depend
on
communicating
participants
doing
some
up-front
negotiation
around
how
they
plan
to
support
workflow
execution
or
all
communicating
partners
will
need
to
adhere
to
an
implementation
guide
that
sets
out
clear
interoperability
expectations.
Prior
to
reviewing
this
list
of
options,
readers
are
encouraged
to
be
familiar
with
the
following
pages
and
resources:
REST
,
messaging
,
operations
,
services
and
the
Subscription
resource.
The
scenarios
below
make
use
of
a
few
conventions:
-
The
focus
here
is
on
a
"request"
and
the
actioning
of
that
request.
Almost
all
workflows
can
be
broken
down
to
a
sequence
of
these
steps,
though
the
responsibilities
of
the
different
parties
may
shift
for
each
interaction
and
there
can
be
more
than
two
parties
involved
in
the
overall
workflow
-
The
request
could
be
as
simple
as
"please
look
at
this
information"
and
the
response
could
be
as
simple
as
an
implicit
"it's
been
looked
at"
or
the
request
could
be
for
some
more
involve
action
that
may
involve
reporting
back
multiple
interim
and
final
steps
-
The
requester
is
referred
to
as
the
"placer"
and
the
performer
is
referred
to
as
the
"filler",
which
are
often
seen
as
order-specific
terms.
However,
in
this
context,
the
terms
hold
whether
the
request
is
expressed
as
a
proposal,
plan
or
full-blown
order
-
Each
of
the
patterns
defines
the
set
of
steps
involved
in
processing
the
request,
lists
some
of
the
benefits
and
limitations
associated
with
the
approach
and
then
makes
recommendations
about
when
the
pattern
is
most
appropriate
-
The
descriptions
of
these
patterns
focuses
on
the
notion
of
requesting
fulfillment
of
a
request.
However
most
of
these
patterns
are
also
applicable
to
requests
for
status
change,
requests
for
information,
etc.
If
a
pattern
is
limited
in
the
types
of
execution
it
can
trigger,
this
will
be
noted
in
the
"limitations"
section.
12.1.2.1
Communication
Pattern
Overview
The
list
of
patterns
discussed
here
is
as
follows:
TODO:
Insert
Jose's
decision
tree
here?
12.1.2.2
Option
A:
Simple
RESTful
POST
or
PUT
12.1.2.2.1
Steps
-
The
placer
makes
a
RESTful
call
to
create
or
update
a
record
or
a
POST
to
invoke
an
operation
over
HTTP
-
The
receiver
responds
with
a
2xx
HTTP
response
indicating
whether
the
request
was
successfully
processed
or
not
and,
if
appropriate,
provides
the
response
to
the
request
in
the
payload
of
the
HTTP
response
12.1.2.2.2
Benefits
-
Simplest
of
all
the
possible
workflow
architectures
-
Placer
knows
whether
the
request
was
accepted
or
not
and
knows
when
the
task
has
been
done
12.1.2.2.3
Limitations
-
Only
works
for
automated
execution
where
the
decision
to
perform
the
request
and
the
execution
of
the
request
can
be
done
synchronously
within
the
HTTP
timeout
period
(generally
on
the
order
of
10s
of
seconds).
-
Requires
that
the
placer
have
authority
to
post
directly
to
the
placer's
system
-
Requires
that
the
"request"
be
expressible
as
a
simple
creation,
update
or
operation
invocation
-
Only
works
for
"fulfillment"
requests
for
Request
resources
-
can't
handle
request
for
state
changes
or
information
12.1.2.2.4
Usage
Recommendations
This
is
by
far
the
most
common
pattern
in
FHIR
for
simple
changes
as
it
requires
the
least
overhead.
However,
if
human
processing
is
involved
in
the
request
execution,
then
this
approach
won't
suffice.
This
approach
is
listed
here
to
make
sure
that
implementers
consider
whether
they
can
make
this
one
work
first
before
falling
back
to
one
of
the
more
sophisticated
patterns.
12.1.2.3
Option
B:
Direct
POST
of
request
to
fulfiller's
system
12.1.2.3.1
Steps
-
Placer
system
invokes
a
create
by
POSTing
a
'request'
resource
(e.g.
MedicationRequest
,
DiagnosticRequest
,
ReferralRequest
,
etc.)
to
the
appropriate
RESTful
resource
endpoint
(e.g.
[base]/MedicationRequest)
on
the
filler
system
and
places
an
actionable
tag
on
the
resource
that
indicates
the
request
is
intended
to
be
acted
upon,
not
merely
stored.
-
The
filler
synchronously
responds
with
a
"201"
indicating
that
that
they
have
received
and
stored
(created)
the
resource
on
their
system
-
At
some
later
point,
the
filler
POSTs
an
'event'
resource
(e.g.
MedicationDispense
,
DiagosticReport
,
Encounter
,
etc.)
to
the
appropriate
resource
endpoint
on
the
placer
system,
including
a
basedOn
link
to
the
'request'
resource
that
the
action
was
performed
in
fulfillment
of.
-
The
placer
system
synchronously
responds
with
a
"201"
indicating
they've
received
and
store
(created)
the
resource
on
their
system
12.1.2.3.2
Benefits
-
Lowest
amount
of
overhead.
No
need
for
Task
.
No
need
for
polling
or
subscriptions
-
Explicit
acknowledgement
that
filler
has
received
the
request
12.1.2.3.3
Limitations
-
Can
only
use
when
requesting
fulfillment
(can't
use
to
request
status
change
or
other
updates)
-
Placer
and
filler
must
be
able
to
communicate
directly
(i.e.
know
each
other's
respective
endpoints)
and
must
each
have
a
FHIR
server
and
must
have
"write"
permissions
to
each
other's
servers.
This
could
become
unmanageable
if
there
are
a
large
(or
dynamic)
number
of
placers
and
fillers
that
need
to
communicate
-
No
indication
of
agreement
to
act
on
the
request
-
There's
no
ability
to
negotiate
fulfillment
-
no
ability
to
say
"no"
12.1.2.3.4
Usage
Recommendations
Use
this
approach
when
there's
no
ability
to
have
queue
servers
and
no
support/need
for
complexity
of
Task,
polling
or
pub/sub
(and
no
need
for
negotiation
or
the
ability
for
the
filler
to
say
"no").
This
is
a
pseudo-messaging
architecture
that
doesn't
actually
use
messaging
architecture.
12.1.2.4
Option
C:
POST
of
request
to
placer/queue
server
system,
receiver
uses
polling
12.1.2.4.1
Steps
-
Placer
system
invokes
a
"create"
action
by
POSTing
a
'request'
resource
(e.g.
MedicationRequest,
DiagnosticOrder,
ReferralRequest,
etc.)
to
the
appropriate
RESTful
resource
endpoint
(e.g.
[base]/MedicationRequest)
on
either
its
own
system
or
a
third
party
queue
server
system
and
sets
a
"flag"
on
the
resource
that
indicates
the
request
is
"actionable".
The
request
explicitly
identifies
the
intended
fullfiller
-
The
filler
system,
at
some
agreed
frequency,
RESTfully
queries
the
placer
or
queue
server
system
to
see
if
there
are
any
"new"
requests
that:
are
tagged
as
"actionable",
have
the
filler
identified
as
the
intended
performer,
and
are
a
type
of
request
"of
interest"
to
the
filler.
(The
queries
could
be
initiated
by
the
filler
system
automatically
in
the
background
or
upon
triggering
by
user
of
the
filler
system.)
-
At
some
later
point,
the
filler
POSTs
an
'event'
resource
(e.g.
MedicationDispense,
DiagosticReport,
Encounter,
etc.)
to
the
appropriate
resource
endpoint
on
either
its
own
system,
the
same
queue
server
as
the
request
was
placed
on
or
some
alternate
queue
server,
including
a
link
to
the
'request'
resource
that
the
action
was
performed
in
fulfillment
of.
-
The
placer
system,
at
some
agreed
frequency,
RESTfully
queries
the
filler
or
queue
server
system
to
see
if
there
are
any
"new"
events
that
are
tied
to
any
outstanding
orders
the
placer
has
initiated.
(The
queries
could
be
initiated
by
the
placer
system
automatically
in
the
background
or
upon
triggering
by
user
of
the
placer
system.)
12.1.2.4.2
Benefits
-
Placer
&
Server
don't
have
to
communicate
directly
(can
act
through
queue
server).
This
can
reduce
the
number
of
point-to-point
interfaces
that
need
to
be
supported.
-
No
need
for
Task.
12.1.2.4.3
Limitations
-
Can
only
use
when
requesting
fulfillment
(can't
use
to
request
status
change
or
other
updates)
-
Placer
and
filler
must
regularly
poll
to
see
if
there's
anything
new.
(Can
represent
significant
communication
overhead)
-
Polling
by
the
placer
for
"anything
related
to
these
500
open
orders"
could
be
onerous,
especially
if
some
orders
never
get
closed.
-
Placer
and
fulfiller
must
know
where
to
poll
for
content
-
this
could
be
a
large
number
of
systems
-
No
indication
of
agreement
to
act
on
the
request
-
There's
no
ability
to
negotiate
fulfillment
-
no
ability
to
say
"no"
-
Placer
may
not
know
when
(or
if)
filler
system
has
retrieved
the
request
12.1.2.4.4
Usage
Recommendations
Use
this
when
there's
no
ability
to
have
queue
servers
and
no
support/need
for
complexity
of
Task
and
where
no
Subscription
infrastructure
exists.
This
is
a
more
typically
RESTful
approach
where
data
resides
on
the
server
"owned"
by
the
data
creator
and
is
accessed
by
other
systems.
12.1.2.5
Option
D:
POST
of
request
to
placer/queue
server
system,
receiver
uses
subscription
12.1.2.5.1
Steps
-
Same
as
Option
C
-
placer
posts
to
itself
or
to
queue
server
-
Filler
has
set
up
a
subscription
to
requests
of
interest
(same
criteria
as
for
B)
-
When
placer's
request
is
posted,
filler
receives
a
notification
that
a
new,
relevant
request
exists
and
queries
to
receive
it
-
Same
pattern
follows
for
transmission
of
response
from
filler
back
to
placer
12.1.2.5.2
Benefits
-
Placer
&
Server
don't
have
to
communicate
directly
(can
act
through
queue
server).
This
can
reduce
the
number
of
point-to-point
interfaces
that
need
to
be
supported.
-
No
need
for
Task
-
Lower
communication
overhead
than
polling
12.1.2.5.3
Limitations
-
Can
only
use
when
requesting
fulfillment
(can't
use
to
request
status
change
or
other
updates)
-
Additional
complexity
of
setting
up
and
maintaining
a
subscription
infrastructure
-
Placer
and
fulfiller
must
know
where
to
subscribe
for
content
-
this
could
be
a
large
number
of
systems
-
No
indication
of
agreement
to
act
on
the
request
-
There's
no
ability
to
negotiate
fulfillment
-
no
ability
to
say
"no"
-
Placer
may
not
know
when
(or
if)
filler
system
has
retrieved
the
request
12.1.2.5.4
Usage
Recommendations
Same
a
Option
C
,
but
in
an
environment
where
subscription
capability
does
exist.
12.1.2.6
Option
E:
POST
of
Task
to
filler
system
12.1.2.6.1
Steps
-
Placer
POSTs
the
request
to
its
own
system
or
to
a
queue
server
system
-
Placer
POSTs
a
Task
resource
to
the
filler
system,
pointing
to
the
request
resource
and
seeking
fulfillment
-
Fulfiller
system
queries
to
retrieve
the
referenced
request
-
Fulfiller
Updates
the
Task
to
indicate
acceptance
of
the
task
(and
possibly
interim
progress
notes)
-
Placer
either
polls
the
Task
to
note
acceptance
and
changes
or
uses
a
subscription
to
determine
the
same
-
Fulfiller
POSTs
an
event
resource
to
its
own
system
or
to
a
queue
server
system
-
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
-
Placer
system
becomes
aware
of
the
update
via
polling
or
subscription
and
retrieves
the
referenced
event
resource
12.1.2.6.2
Benefits
-
Can
use
this
approach
for
request
other
than
just
when
requesting
fulfillment
(e.g.
to
request
status
change
or
other
updates)
-
There's
an
ability
to
negotiate
fulfillment
-
i.e.
the
ability
to
say
"no"
-
Explicit
acknowledgement
that
filler
has
received
and
agreed
to
act
on
the
request
12.1.2.6.3
Limitations
12.1.2.6.4
Usage
Recommendations
Not
clear
why
would
anyone
do
this
.
.
.
12.1.2.7
Option
F:
POST
of
"open"
Task
to
queue
server
system
12.1.2.7.1
Steps
-
Placer
POSTs
the
request
to
its
own
system
or
to
a
queue
server
system
-
Placer
POSTs
a
Task
resource
to
its
own
system
or
a
queue
server
system,
pointing
to
the
request
resource
and
seeking
fulfillment.
Task
does
not
have
a
specified
"performer"
(but
may
have
performer
type)
-
Fulfiller
system
uses
either
polling
or
pub/sub
to
become
aware
of
the
existence
of
the
task
-
Fulfiller
system
queries
to
retrieve
the
referenced
request
-
Fulfiller
system
updates
the
Task
to
indicate
"ownership"
and
agreement
to
fulfill
-
Fulfiller
may
update
the
Task
to
indicate
interim
progress
notes
-
Placer
either
polls
the
Task
to
note
acceptance
and
changes
or
uses
a
subscription
to
determine
the
same
-
Fulfiller
POSTs
an
event
resource
to
its
own
system
or
to
a
queue
server
system
-
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
-
Placer
system
becomes
aware
of
the
update
via
polling
or
subscription
and
retrieves
the
referenced
event
resource
12.1.2.7.2
Benefits
-
No
need
for
placer
and
fulfiller
system
to
talk
to
each
other
directly
-
Can
use
this
approach
for
request
other
than
just
when
requesting
fulfillment
(e.g.
to
request
status
change
or
other
updates)
-
There's
an
ability
to
negotiate
fulfillment
-
i.e.
the
ability
to
say
"no"
-
Explicit
acknowledgement
that
filler
has
received
and
agreed
to
act
on
the
request
12.1.2.7.3
Limitations
12.1.2.7.4
Usage
Recommendations
Used
when
requests
are
not
(always)
directed
to
a
specific
filler
and
where
fillers
may
respond
to
tasks
from
multiple
placers.
This
creates
a
sort
of
"market"
where
fillers
choose
what
to
take
on
and
negotiate
what
work
they
perform.
12.1.2.8
Option
G:
POST
of
"request"
resource
for
filler
system,
response
via
Task
12.1.2.8.1
Steps
-
Placer
system
invokes
a
"create"
action
by
POSTing
a
'request'
resource
(e.g.
MedicationRequest,
DiagnosticOrder,
ReferralRequest,
etc.)
to
the
appropriate
RESTful
resource
endpoint
(e.g.
[base]/MedicationRequest)
on
the
filler,
placer
or
queue
server
system
and
sets
a
"tag"
on
the
resource
that
indicates
the
request
is
"actionable"
-
Filler
POSTs
a
Task
resource
to
its
own
system
or
a
queue
server
system,
pointing
to
the
request
resource
and
indicating
intent
to
fulfill
or
refusal
to
fulfill
-
Placer
system
uses
either
polling
or
pub/sub
to
become
aware
of
the
existence
of
the
task
and
fulfillment
intent
-
Fulfiller
may
update
the
Task
to
indicate
interim
progress
notes
-
Placer
either
polls
the
Task
to
note
acceptance
and
changes
or
uses
a
subscription
to
determine
the
same
-
Fulfiller
POSTs
an
event
resource
to
its
own
system
or
to
a
queue
server
system
-
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
-
Placer
system
becomes
aware
of
the
update
via
polling
or
subscription
-
Placer
system
retrieves
the
event
-
Placer
system
marks
the
request
as
"complete"
12.1.2.8.2
Benefits
-
There's
an
ability
to
negotiate
fulfillment
-
i.e.
the
ability
to
say
"no"
-
Explicit
acknowledgement
that
filler
has
received
and
agreed
to
act
on
the
request
(though
no
need
for
the
placer
to
check)
12.1.2.8.3
Limitations
-
Can
only
use
when
requesting
fulfillment
(can't
use
to
request
status
change
or
other
updates)
-
Additional
complexity
of
setting
up
and
maintaining
a
subscription
or
polling
infrastructure
-
Additional
complexity
of
using
Task
-
Placer
and
filler
may
need
to
be
able
to
communicate
directly
(i.e.
know
each
other's
respective
endpoints)
and
have
a
FHIR
server
and
have
"write"
permissions
to
each
other's
servers
(if
no
queue
server
is
used)
-
Placer
and
fulfiller
must
know
where
to
subscribe
for
content
-
this
could
be
a
large
number
of
systems
12.1.2.8.4
Usage
Recommendations
Use
this
when
the
filler
needs
to
have
complete
ownership
over
the
task
and
there's
no
ability
for
both
placer
&
filler
to
manipulate
tasks
on
a
common
server
12.1.2.9
Option
H:
Workflow
broker
12.1.2.9.1
Steps
-
Placer
POSTs
the
request
to
its
own
system
or
to
a
queue
server
system
-
Broker
detects
that
new
un-assigned
request
(without
a
Task
yet
created
and
falling
within
the
scope
of
the
Broker
to
ensure
fulfillment)
via
polling
or
subscription
-
Broker
POSTs
a
Task
resource
to
its
own
system
or
a
queue
server
system,
pointing
to
the
request
resource
and
seeking
fulfillment
from
a
specific
filler
Task
does
not
have
a
specified
"performer"
(but
may
have
performer
type)
-
If
the
Task
is
rejected
by
one
potential
recipient,
the
broker
may
create
a
new
task
to
seek
fulfillment
from
others
-
Continue
as
per
Option
G
12.1.2.9.2
Benefits
-
Offloads
responsibility
for
seeking
fulfillment
from
the
placer
system,
but
more
actively
solicits
fulfillment
than
a
simple
"post
the
task
and
see
who
takes
it".
Also
allows
prioritized
assignment
of
tasks
(i.e.
some
fillers
may
be
preferred
over
others)
12.1.2.9.3
Limitations
-
Requires
a
broker
to
exist
-
Broker
must
know
all
available
fillers
and
their
capabilities
to
allow
appropriate
assignment
12.1.2.9.4
Usage
Recommendations
Appropriate
in
environments
that
have
a
workflow
engine
that
takes
on
responsibility
for
ensuring
fulfillment
12.1.2.10
Option
I:
Messaging
request
from
placer
to
filler
&
acknowledgment
12.1.2.10.1
Steps
-
Placer
sends
message
to
filler
system
including
Request
resource
(and
other
relevant
resources)
along
with
a
MessageHeader
with
an
"event"
code
saying
"please
fulfill"
and
"data"
element
pointing
to
the
Request
resource
as
the
item
to
fulfill.
Message
could
potentially
use
Task
instead
of
MessageHeader.event
to
convey
desired
action
(ongoing
discussion)
-
Filler
system
sends
a
response
indicating
receipt
of
the
message
and,
optionally
an
indication
of
their
intention
to
fulfill
the
request
-
Filler
system
may
send
incremental
messages
to
the
placer
showing
progress
(e.g.
specimen
collected,
preliminary
results,
final
results)
12.1.2.10.2
Benefits
-
Reduced
number
of
communications
-
All
relevant
data
sent
in
one
package
-
Responses
can
be
asynchronous
and
content
may
routed
-
There's
an
ability
to
negotiate
fulfillment
-
i.e.
the
ability
to
say
"no"
-
Can
request
things
other
than
just
fulfillment
(e.g.
please
suspend)
-
Explicit
acknowledgement
that
filler
has
received
and
agreed
to
act
on
the
request
(though
no
need
for
the
placer
to
check)
12.1.2.10.3
Limitations
-
Messaging
is
"heavy"
-
Need
to
negotiate
what
allowed
responses
are
and
what
data
can
be
present
in
request
and
response
messages
-
Additional
complexity
of
setting
up
and
maintaining
a
subscription
or
polling
infrastructure
-
Additional
complexity
of
using
Task
-
Need
message
delivery
infrastructure
in
place
12.1.2.10.4
Usage
Recommendations
Existing
messaging
infrastructure
(e.g.
v2
LTP,
MLTP,
WSI
Web
Services,
Direct,
VISA,
REST,
etc.)
and
a
need
to
stay
consistent
with
that
architecture
12.1.2.11
Option
J:
Services
request
from
placer
to
filler
&
acknowledgment
This
scenario
needs
work
-
there's
not
a
lot
of
experience
using
FHIR
services
to
manage
the
fulfillment
process
12.1.2.11.1
Steps
-
Placer
may
create
and
store
a
Request
resource
on
their
own
system
or
a
queue
server.
-
Placer
invokes
a
service
on
the
filler
system
saying
"please
fulfill
this
order",
including
the
content
or
a
reference
to
the
request
resource
and
any
other
relevant
data
-
Filler
system
responds
(synchronously
if
using
HTTP,
but
may
be
asynchronous
if
using
SOAP
or
other
transport
mechanisms)
with
conformation
of
receipt
and,
optionally
indication
of
intention
to
fulfill
and/or
results
12.1.2.11.2
Benefits
12.1.2.11.3
Limitations
12.1.2.11.4
Usage
Recommendations
TBD
12.1.2.12
Additional
Scenarios
12.1.2.12.1
Querying
the
status
of
a
workflow
using
REST
-
Placer
sends
query
for
Task(s)
that
have
a
focus
of
the
request
of
interest
to
a
system
(placer
system,
queue
server
or
filler)
that
holds
tasks
related
to
their
request.
-
System
returns
a
query
response
showing
all
related
tasks
(typically
just
one).
Task
shows
current
status.
12.1.2.12.2
Querying
the
status
of
a
workflow
using
services
-
Placer
invokes
a
"what's
the
status
of
this
order"
service,
passing
the
request
business
identifier
or
URL
of
the
request
-
Services
responds
with
a
Task
showing
the
current
state
of
the
fulfillment
of
the
request
12.1.2.12.3
Cancellation
of
a
Task
using
REST
-
placer
owns
-
Placer
sends
an
update
to
the
Task
setting
the
status
to
"cancelled"
-
Filler
receives
notification
of
the
update
(because
the
task
is
on
their
system
or
because
they
poll
it
or
are
subscribed
to
it)
and
ceases
work
if
they
are
able
12.1.2.12.4
Cancellation
of
a
Task
using
REST
-
filler
owns
-
Placer
creates
a
new
task
requesting
cancellation
of
the
original
fulfillment
task
Fulfillment
of
the
"cancellation
task"
can
be
requested
using
any
of
the
mechanisms
above
-
Filler
decides
whether
they
are
able
to
cancel
the
task
and
update
the
"cancellation"
task
to
indicate
either
cancellation
is
complete
or
has
been
refused
12.1.3
Open
Issues
STU
Notes:
-
It
is
possible
to
replace
some
portions
of
the
MessageHeader
with
a
reference
to
the
Task
resource.
Doing
so
would
mean
consistency
in
how
asynchronous
requests
are
represented
using
REST
and
messaging.
However,
it
introduces
an
additional
layer
of
complexity
and
formality
into
the
messaging
paradigm
that
may
be
unwelcome,
particularly
for
those
systems
that
do
not
currently
foresee
a
need
to
support
both
RESTful
and
messaging
invocations
of
workflow
-
The
OperationDefinition
resource
could
be
used
to
define
types
of
tasks
and
the
sets
of
parameters
that
are
allowed
to
go
with
them.
Is
this
an
appropriate
use
of
the
OperationDefinition
resource?
-
The
SupplyRequest
,
DeviceUseRequest
and
VisionPrescription
resources
have
a
significant
degree
of
overlap.
Should
they
remain
distinct
resources?
Workflow
|
Propose
a
change