This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
(v5.0.0:
R5
-
Mixed
Normative
and
STU
)
).
This
is
the
current
published
version
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
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
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.7.1.2
12.11.1.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.7.1.3
12.11.1.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
filler'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
Only
way
to
cancel
the
request
is
with
a
separate
custom
operation
12.7.1.4
12.11.1.4
Usage
Recommendations
This
is
by
far
the
most
common
pattern
in
FHIR
for
simple
changes
as
it
requires
the
least
overhead.
However,
it
covers
only
automated
responses,
and
does
not
support
any
actual
workflows
of
more
than
one
step.
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.7.1.5
12.11.1.5
Usage
Examples
???
12.7.2
12.11.2
Option
B:
Direct
POST
of
request
to
fulfiller's
system
12.7.2.1
12.11.2.1
Steps
Placer
system
invokes
a
create
by
POSTing
a
'request'
resource
(e.g.
MedicationRequest
,
ServiceRequest
,
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
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.7.2.2
12.11.2.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.7.2.3
12.11.2.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),
must
each
have
a
FHIR
server,
and
must
have
"write"
permissions
to
each
other's
servers.
This
could
become
unmanageable
unmanagable
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"
This
completely
reverses
the
usual
provenance
of
resources,
as
the
request
only
exists
on
the
fulfiller's
system,
and
the
event
only
exists
on
the
placer's
system.
This
greatly
limits
the
use
of
these
resources
for
any
other
purpose.
The
only
way
to
stop
fulfillment
is
to
update
the
Request
to
have
a
'cancelled'
status
12.7.2.4
12.11.2.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.7.2.5
12.11.2.5
Usage
Examples
12.7.3
12.11.3
Option
C:
POST
of
request
to
placer/queue
server
system,
receiver
uses
polling
or
subscription
12.7.3.1
12.11.3.1
Steps
Placer
system
creates
a
'request'
resource
(e.g.
ServiceRequest
etc.)
by
a
system
action
or
a
POST
on
either
its
own
system
or
a
third-party
queue
server
system
and
places
an
"actionable"
tag
on
the
resource
that
indicates
the
request
is
intended
to
be
acted
upon.
The
request
explicitly
identifies
the
intended
fullfiller
The
filler
system
uses
polling
(or
a
subscription)
at
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.
At
some
later
point,
the
filler
creates
an
'event'
resource
(e.g.
MedicationDispense,
DiagosticReport,
Encounter,
etc.)
via
a
system
action,
or
a
POST
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
uses
polling
(or
a
subscription)
to
the
filler
or
queue
server
system
to
see
if
there
are
any
"new"
events
that
are
tied
to
any
outstanding
requests
the
placer
has
initiated
12.7.3.2
12.11.3.2
Benefits
Placer
and
fulfiller
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
Preserves
the
conventional
management
and
ownership
of
the
request
and
event
at
the
placer
and
fulfiller's
systems
respectively
No
need
for
Task
12.7.3.3
12.11.3.3
Limitations
Can
only
use
when
requesting
fulfillment
(can't
use
to
request
status
change
or
other
updates)
Additional
complexity
of
using
subscription
or
polling
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
or
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
might
not
know
when
(or
if)
filler
system
has
retrieved
the
request
If
the
Request
is
cancelled,
there's
no
guarantee
the
filler
will
notice
or
act
on
the
change
12.7.3.4
12.11.3.4
Usage
Recommendations
This
pattern
could
be
used
when
there's
no
support/need
for
complexity
of
Task,
usually
for
simple
two
step
workflows.
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.7.3.5
12.11.3.5
Usage
Examples
12.7.4
12.11.4
Option
D:
Messaging
request
from
placer
to
filler
&
acknowledgment
TODO:
needs
review
and
update
12.7.4.1
12.11.4.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.7.4.2
12.11.4.2
Benefits
Reduced
number
of
communications
All
relevant
data
sent
in
one
package
Responses
can
be
asynchronous,
and
content
may
be
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.7.4.3
12.11.4.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
Cancellation
requires
a
separate
purpose-specific
message
12.7.4.4
12.11.4.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.7.5
12.11.5
Option
E:
Services
request
from
placer
to
filler
&
acknowledgment
TODO:
Needs
review,
update
and
more
work
-
there's
not
a
lot
of
experience
using
FHIR
services
to
manage
the
fulfillment
process
12.7.5.1
12.11.5.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.7.5.2
12.11.5.2
Benefits
???
12.7.5.3
12.11.5.3
Limitations
???
12.7.5.4
12.11.5.4
Usage
Recommendations
TBD
12.7.6
12.11.6
Additional
Scenarios
TODO:
needs
review
and
update.
Possibly
add
options
about
using
messaging
and/or
services
instead
of
polling/subscription
in
above
scenarios
12.7.6.1
12.11.6.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.7.6.2
12.11.6.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.7.6.3
12.11.6.3
Cancellation
of
a
Task
using
REST
-
placer
owns
Placer
sends
an
update
to
the
Task
setting
the
status
to
"cancelled"
signaling
they
are
no
longer
concerned
about
the
outcome
of
the
task
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.7.6.4
12.11.6.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
can
cancel
the
task
and
update
the
"cancellation"
task
to
indicate
either
cancellation
is
complete
or
has
been
refused
Workflow
.
Page
versions:
R5
R4B
R4
R3
|
Propose
a
change