This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
(v5.0.0-ballot:
R5
Ballot
-
Mixed
Normative
and
STU
see
ballot
notes
)
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
TODO:
Discussion
(or
reference
to
one)
on
Polling
and
Subscription
Summary
Defining
URL:
http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate
12.8.1
Option
F:
Creation
of
Task
on
placer's
system
Version:
5.0.0-ballot
Name:
12.8.1.1
expirationDate
Steps
Title:
null
Modifier:
This
extension
is
not
a
modifier
extension
Placer
creates
Status:
draft
Definition:
The
date
when
the
request
in
its
own
system
via
POST,
an
internal
action,
or
POSTs
it
to
a
queue
server
system
Placer
creates
a
Task
resource
in
its
own
system
via
POST,
an
internal
action,
or
POSTs
it
value
set
version
is
no
longer
expected
to
a
queue
server
system,
pointing
be
used
to
create
new
content.
This
is
the
request
resource
and
seeking
fulfillment.
first
date-time
when
the
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
all
Inactive
value
set
versions.
The
Task
may
have
a
specified
performer,
in
which
case
step
3
start
Date_time
is
expected
to
be
done
by
that
performer.
If
the
Task
does
not
have
a
specified
"performer"
(although
may
have
performer
type),
then
this
is
a
case
as
of
an
"open"
task,
where
any
number
0001
UTC
of
fulfillers
may
attempt
to
"claim"
the
task.
Who
succeeds
Expiration
Date.
(deprecated)
The
date
when
the
value
set
version
is
determined
by
local
policies
and
procedures.
Fulfiller
system
uses
either
polling
or
pub/sub
no
longer
expected
to
become
aware
of
the
existence
of
the
task
A
common
case
may
be
the
conveyance
of
the
Task
id
used
to
a
fulfiller
by
other
means.
For
example,
a
lab
test
create
new
content.
This
is
ordered,
and
the
patient
takes
a
requisition
to
first
date-time
when
the
lab
of
his
choice.
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
all
Inactive
value
set
versions.
The
requisition
contains
the
Task
id
(as
a
bar
code,
or
stored
in
the
patient's
healthcare
smart
card),
and
the
lab
system
can
execute
a
direct
GET
for
the
Task,
thus
eliminating
the
need
for
subscription
or
polling.
Fulfiller
system
queries
to
retrieve
the
referenced
request
and
updates
the
Task
to
indicate
"acceptance"
and
agreement
to
fulfill
Fulfiller
may
update
the
Task
to
indicate
interim
progress
notes
Placer
start
Date_time
is
made
aware
expected
to
be
as
of
the
acceptance
0001
UTC
of
the
Task
and
any
changes
to
Expiration
Date.
(deprecated)
Comment
:
Upon
reaching
the
Task
either
through
its
ownership
of
Expiration
Date,
the
resource
or
using
polling
or
a
subscription
to
a
queue
server
system
value
set
Activity
Status
should
be
consdiered
as
inactive.
An
Inactive
value
set
version
may
no
longer
be
used
to
determine
the
same
Fulfiller
creates
an
event
resource
in
its
own
system
via
POST
or
internal
action,
or
POSTs
create
new
content,
but
it
may
be
used
to
a
queue
server
system
Fulfiller
PUTs
an
update
to
the
Task
resource
to
change
its
status
to
completed
and
to
point
evaluate
content
created
prior
to
the
event
resource
Placer
Expiration
Date.
This
extension
is
aware
of
the
completion
of
the
Task
either
through
deprecated,
use
the
ownership
CodeSystem.effectivePeriod.stop
element
instead.
Context
of
the
resource,
or
via
polling
or
subscription
to
a
queue
server
system,
and
retrieves
the
referenced
event
resource
Placer
updates
the
request
resource
to
indicate
completion
via
PUT
or
an
internal
action,
or
PUTs
the
update
to
a
queue
server
system
Use:
Use
on
Element
ID
CodeSystem
Uses
the
FHIR
REST
API
for
managing
the
workflow
Both
placer
and
fulfiller
can
track
the
state
of
the
workflow
Can
use
this
approach
for
request
other
than
just
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
Supports
cancellation
through
ability
of
placer
to
change
the
status
of
the
Task
to
cancelled.
12.8.1.3
Summary
Limitations
Full
Structure
Additional
complexity
of
using
Task
Additional
complexity
of
setting
up
and
maintaining
a
subscription
or
polling
infrastructure
Placer
and
fulfiller
must
have
a
FHIR
server,
and
placer's
FHIR
server
must
allow
"write"
updates
to
the
Task
resource
Placer
and
filler
may
need
to
be
able
to
communicate
directly
(i.e.
know
each
other's
respective
endpoints)
This
could
become
unmanageable
if
there
are
a
large
(or
dynamic)
number
of
placers
and
fillers
that
need
to
communicate
Placer
and
fulfiller
must
know
where
to
subscribe
for
content
-
this
could
be
a
large
number
of
systems
XML
Does
not
give
fulfiller
control
over
whether
the
task
can
be
cancelled
12.8.1.4
All
Usage
Recommendations
Summary
Name
When
following
the
state
of
the
workflow
is
important
When
there
is
a
need
to
know
that
a
fulfiller
has
accepted
to
perform
the
request
When
there
is
a
need
to
be
able
to
change
the
performance
of
the
request
When
there
are
multiple
steps
in
fulfilling
the
request
When
requests
are
not
(always)
directed
to
a
specific
filler
When
the
placer
needs
to
manage
the
Task
resource
A
provider
orders
a
bilirubin
test
for
a
patient,
to
be
done
at
the
provider's
facility
lab....
Description
&
Constraints
"Open"
lab
order
A
patient
is
scheduled
for
their
physical,
and
the
provider
sends
her
a
secure
message
to
have
a
fasting
blood
test
performed
before
the
office
visit.
The
message
has
a
link
to
a
requisition,
and
a
list
of
possible
lab
locations
where
the
test
can
be
done.
The
patient
chooses
a
lab
location
near
her
place
of
employment
and
a
test
is
scheduled.
The
lab
gets
the
requisition
from
the
patient
and,
using
the
information
on
how
to
retrieve
the
Task
from
the
provider's
system,
claims
the
test
to
be
performed...
12.8.2
Option
G:
POST
of
Task
to
fulfiller's
system
date
Placer
creates
the
request
in
its
own
system
via
POST
or
an
internal
action,
or
POSTs
it
to
a
queue
server
system
Placer
POSTs
a
Task
resource
to
the
filler
system,
pointing
to
the
request
resource
and
seeking
fulfillment
Fulfiller
system
GETs
the
referenced
request
Fulfiller
updates
the
Task
to
indicate
acceptance
of
the
task
Placer
either
polls
URL
=
http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate
expirationDate:
The
date
when
the
Task
value
set
version
is
no
longer
expected
to
note
acceptance
or
uses
a
subscription
be
used
to
determine
create
new
content.
This
is
the
same
Fulfiller
may
further
update
first
date-time
when
the
Task
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
all
Inactive
value
set
versions.
The
start
Date_time
is
expected
to
reflect
the
progress
made.
Using
the
same
method
be
as
in
step
5,
the
placer
becomes
aware
of
these
updates
Fulfiller
creates
an
event
resource
in
its
own
system
via
POST
or
an
internal
action,
or
POSTs
it
to
a
queue
server
system
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
Placer
either
polls
the
Task
to
note
completion
and
changes
or
uses
a
subscription
to
determine
the
same
Placer
system
queries
to
retrieve
the
referenced
event
resource
Placer
updates
the
request
resource
to
indicate
completion
via
PUT
or
an
internal
action,
or
PUTs
0001
UTC
of
the
update
to
a
queue
server
system
12.8.2.2
Expiration
Date.
(deprecated)
Benefits
Name
Additional
complexity
of
using
Task
Additional
complexity
of
using
subscription
or
polling
Placer
and
fulfiller
must
have
a
FHIR
server
and
fulfiller's
FHIR
server
must
allow
"write"
creation
of
the
Task
resource
by
the
placer
Placer
and
filler
may
need
to
be
able
to
communicate
directly
(i.e.
know
each
other's
respective
endpoints)
This
could
become
unmanageable
if
there
are
a
large
(or
dynamic)
number
of
placers
and
fillers
that
need
to
communicate
Might
not
apply
if
there's
a
queue
server
Placer
might
not
know
immediately
when
filler
system
has
retrieved
the
request
Type
When
following
the
state
of
the
workflow
is
important
When
there
is
a
need
to
know
that
a
fulfiller
has
accepted
to
perform
the
request
When
there
is
a
need
to
be
able
to
change
the
status
of
the
workflow
by
either
the
placer
or
the
fulfiller
When
there
are
multiple
steps
in
fulfilling
the
request
When
the
fulfiller
needs
to
manage
the
Task
resource
A
patient
is
suffering
from
a
poison
ivy
rash
and
is
prescribed
a
steroid
medication
to
manage
the
reaction.
The
provider
asks
the
patient
for
his
preferred
pharmacy
and
creates
the
Task
at
the
specified
pharmacy's
system.
0..1
Extension
URL
=
http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate
expirationDate:
The
patient
is
running
late
and
by
the
time
he
arrives
at
the
pharmacy,
it
is
closed.
He
calls
the
clinic
where
the
provider
practices
and
requests
that
the
pharmacy
where
date
when
the
order
value
set
version
is
no
longer
expected
to
be
fulfilled
is
changed
used
to
one
that
is
open
around
the
clock.
The
staff
at
the
clinic
cancels
the
Task
at
the
original
pharmacy
and
creates
a
new
Task
at
the
requested
new
one.
By
the
time
the
patient
arrives
at
the
create
new
pharmacy,
the
medication
is
ready
for
pickup.
Once
the
request
content.
This
is
fulfilled,
the
clinic
receives
the
notification
that
the
Task
is
complete,
and
first
date-time
when
the
prescription
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
all
Inactive
value
set
versions.
The
start
Date_time
is
also
marked
expected
to
be
as
complete.
12.8.3
Option
H:
POST
of
Task
to
a
workflow
broker
0001
UTC
of
the
Expiration
Date.
(deprecated)
Use
on
Element
ID
CodeSystem
TODO:
Still
needs
review
and
update
12.8.3.1
extension
Steps
0..0
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.8.3.2
Benefits
url
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.8.3.3
Limitations
1..1
uri
Requires
a
broker
to
exist
Broker
must
know
all
available
fillers
and
their
capabilities
to
allow
appropriate
assignment
Broker
must
understand
business
rules
for
permitting
changes
to
tasks
such
as
cancelation
<!-- expirationDate -->
<extension xmlns="http://hl7.org/fhir"
url="http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate" >
<!-- from Element: extension -->
<valueDate value="[date]"/><!--I 1..1Value of extension -->
</extension>
JSON
Template
{ // expirationDate
// from Element: extension
"extension" : [ // sliced by value:url in the specified order, Open ]
// extension: Extension: Prohibited
"url" : "http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate", //R!
"valueDate" : "<date>" //IR!Value of extension
}
Placer
creates
the
request
in
its
own
system
via
POST
or
an
internal
action
Placer
POSTs
a
Task
resource
to
the
filler
system,
pointing
to
the
request
resource
and
seeking
fulfillment
Fulfiller
system
GETs
the
referenced
request
Fulfiller
updates
the
Task
to
indicate
acceptance
of
the
task
Fulfiller
POSTs
a
Task,
which
also
points
to
the
request
resource
and
uses
the
Task.partOf
attribute
to
point
to
the
Task
from
step
2
(indicating
it
is
a
sub-Task)
Fulfiller
may
further
update
both
Tasks
to
reflect
the
progress
made.
Since
the
sub-Task
is
on
the
placer's
system,
the
placer
is
aware
of
these
updates
Fulfiller
creates
an
event
resource
in
its
own
system
via
POST
or
an
internal
action
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
Fulfiller
updates
the
sub-Task
resource
as
completed
and
points
to
the
event
resource.
Since
the
sub-Task
is
on
the
placer's
system,
the
placer
is
aware
of
the
completion
and
changes.
Placer
system
queries
to
retrieve
the
referenced
event
resource
Placer
updates
the
request
resource
to
indicate
completion
via
PUT
or
an
internal
action
Summary
12.8.4.2
Flags
Uses
the
FHIR
REST
API
for
managing
the
workflow
No
need
to
use
subscription
or
polling
Both
placer
and
fulfiller
can
track
and
change
the
state
of
the
workflow
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
Placer
can
initiate
task
cancellation,
but
filler
decides
whether
it's
possible
to
cancel
the
task
or
not
Description
&
Constraints
Additional
complexity
of
using
Task
Need
to
keep
the
two
Task
states
in
sync
Placer
and
fulfiller
must
each
have
a
FHIR
server
and
give
the
other
side
"write"
access
to
create
and
update
Task
resources.
Placer
and
filler
may
need
to
be
able
to
communicate
directly
(i.e.
know
each
other's
respective
endpoints)
This
could
become
unmanageable
if
there
are
a
large
(or
dynamic)
number
of
placers
and
fillers
that
need
to
communicate
Might
not
apply
if
there's
a
queue
server
12.8.4.4
Usage
Recommendations
When
following
the
state
of
the
workflow
is
important
When
there
is
a
need
to
know
that
a
fulfiller
has
accepted
to
perform
the
request
When
there
is
a
need
to
be
able
to
change
the
status
of
the
workflow
by
either
the
placer
or
the
fulfiller
When
there
are
multiple
steps
in
fulfilling
the
request
When
there
is
no
need
for
polling
or
subscription
infrastructure
When
us
of
the
FHIR
REST
API
is
preferred
to
any
other
method
of
communications
When
the
intended
fulfiller
is
known
in
advance
When
messaging-like
functionality
is
needed,
but
a
messaging
infrastructure
is
not
available
12.8.4.5
expirationDate
Usage
Examples
A
patient
is
seen
by
her
Primary
Care
Provider
(PCP)
for
shortness
of
breath
and
URL
=
http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate
expirationDate:
The
date
when
the
provider
decides
to
refer
her
value
set
version
is
no
longer
expected
to
a
cardiologist.
Because
of
the
referral,
the
provider's
system
creates
ServiceRequest
resource
and
POSTs
a
Task
resource
be
used
to
a
cardiologist's
practice
system,
requesting
a
referral.
create
new
content.
This
places
the
referral
request
on
a
referral
coordinator's
work
list
to
review.
Upon
accepting
the
referral,
the
Task
is
updated
as
accepted
and
a
new
sub-Task,
referencing
both
the
ServiceRequest
and
the
Task
created
by
first
date-time
when
the
provider's
system,
is
created
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
the
provider's
system.
all
Inactive
value
set
versions.
The
patient
gets
an
appointment
with
the
cardiologist
and
the
sub-Task
start
Date_time
is
updated
with
that
information,
allowing
the
provider's
system
to
inform
the
provider
of
the
change.
The
patient
misplaces
the
information
about
the
appointment
and
misses
the
visit
with
the
cardiologist.
The
cardiologist's
system
updates
the
sub-Task
expected
to
indicate
the
no-show
and
the
PCP
is
alerted
of
the
missed
appointment.
The
provider's
staff
gets
hold
of
the
patient
and
schedules
another
appointment
for
her
with
the
cardiologist.
Because
of
the
cardiologist's
system
scheduling
the
appointment,
the
sub-Task
is
updated
with
that
information.
The
patient
is
seen
and
the
sub-Task
is
updated
accordingly.
The
cardiologist
document
the
findings
about
the
patient
and
updates
the
sub-Task
be
as
complete,
adding
references
to
the
resources
representing
the
findings.
The
PCP
is
alerted
of
0001
UTC
of
the
updates
and
marks
the
referral
as
complete,
which
updates
the
original
Task
and
the
ServiceRequest
as
complete
as
well.
Expiration
Date.
(deprecated)
12.8.5
Option
J:
Messaging
Task
from
placer
to
fulfiller
Use
on
Element
ID
CodeSystem
Flags
Placer
sends
message
to
filler
with
a
MessageHeader,
where
the
"data"
element
points
to
the
Task
resource,
also
contained
in
the
message.
The
message
might
or
might
not
contain
any
other
relevant
resources
(e.g.
the
actual
request
resource),
or
an
"event"
code
saying
"please
fulfill"
Filler
system
sends
a
response
containing
the
same
Task
resource,
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)
by
including
an
updated
Task
resource
Placer
system
may
also
send
messages
to
the
fulfiller
containing
the
Task
resource
and
updating
the
state
of
the
workflow,
for
example
cancelling
the
task
Description
&
Constraints
Reduced
number
of
communications
All
relevant
data
can
be
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.8.5.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
using
Task
Need
message
delivery
infrastructure
in
place
12.8.5.4
extension
Usage
Recommendations
0..1
Extension
Appropriate
URL
=
http://hl7.org/fhir/StructureDefinition/codesystem-expirationDate
expirationDate:
The
date
when
existing
messaging
infrastructure
can
the
value
set
version
is
no
longer
expected
to
be
used
(e.g.
HL7
over
HTTP,
v2
LTP,
MLTP,
WSI
Web
Services,
Direct,
VISA,
REST,
etc.),
and
a
need
to
stay
consistent
with
that
architecture.
create
new
content.
This
is
the
first
date-time
when
the
value
set
version
becomes
Inactive,
so
this
value
MUST
present
on
all
Inactive
value
set
versions.
The
start
Date_time
is
expected
to
be
as
of
0001
UTC
of
the
Expiration
Date.
(deprecated)
12.8.5.5
Usage
examples
Use
on
Element
ID
CodeSystem
extension
12.8.6
Option
K:
Service
request
referencing
Task
from
placer
to
fulfiller
0..0
TODO:
This
scenario
needs
work
-
there's
not
a
lot
of
experience
using
FHIR
services
to
manage
the
fulfillment
process
12.8.6.1
Steps
url
Placer
creates
a
request
resource
on
their
own
system
or
a
queue
server
Placer
may
create
a
Task
resource
on
their
own
system
or
a
queue
server
Placer
invokes
a
service
on
the
filler
system
saying
"please
fulfill
this
request",
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.8.6.2
Benefits
1..1
uri
No
need
to
expose
RESTful
endpoints
for
either
requests
or
tasks
-
acts
like
a
remote
procedure
call
Requires
support
for
a
custom
operation
by
both
parties
(typically
at
least
a
different
operation
for
each
type
of
request)
No
way
to
get
insight
into
progress
without
invoking
another
custom
operation
value[x]
12.8.6.4
Usage
Recommendations
POST
of
"request"
resource
for
filler
system,
response
via
Task
Constraints
This
is
a
variation
of
Option
H
,
where
the
Workflow
broker
is
essentially
merged
with
the
fulfiller.
It
still
allows
the
placer
to
only
use
ele-1
:
All
FHIR
elements
must
have
a
POST
of
the
request
and
be
made
aware
of
the
changes
to
the
other
resources
via
subscription
@value
or
polling.
children
(xpath:
@value|f:*|h:div
)
Placer
system
invokes
a
"create"
action
by
POSTing
a
'request'
resource
(e.g.
ServiceRequest
etc.)
to
the
appropriate
RESTful
resource
endpoint
(e.g.
[base]/MedicationRequest)
on
the
filler,
placer
ext-1
:
Must
have
either
extensions
or
queue
server
system
and
sets
a
"tag"
on
the
resource
that
indicates
the
request
is
"actionable"
value[x],
not
both
(xpath:
exists(f:extension)!=exists(f:*[starts-with(local-name(.),
'value')])
)
Filler
POSTs
a
Task
resource
to
its
own
system
or
ele-1
:
On
Extension.extension:
All
FHIR
elements
must
have
a
queue
server
system,
pointing
to
the
request
resource
and
indicating
intent
to
fulfill
@value
or
refusal
to
fulfill
children
(xpath
on
Extension.extension:
@value|f:*|h:div
)
Placer
system
uses
ext-1
:
On
Extension.extension:
Must
have
either
polling
extensions
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
value[x],
not
both
(xpath
on
Extension.extension:
exists(f:extension)!=exists(f:*[starts-with(local-name(.),
"value")])
)
Placer
either
polls
the
Task
to
note
acceptance
and
changes
or
uses
ele-1
:
On
Extension.value[x]:
All
FHIR
elements
must
have
a
subscription
to
determine
the
same
Fulfiller
POSTs
an
event
resource
to
its
own
system
@value
or
to
a
queue
server
system
Fulfiller
Updates
the
Task
resource
to
change
its
status
to
completed
and
to
point
to
the
event
resource
children
(xpath
on
Extension.value[x]:
@value|f:*|h:div
)
Terminology
.
Page
versions:
expirationDate
url
|
Propose
a
change
