Terminology
This
page
is
part
of
the
FHIR
Specification
(v4.0.1:
R4
(v5.0.0-draft-final:
Final
QA
Preview
for
R5
-
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
R2
|
|
Maturity
Level
:
|
Standards
Status
:
|
|
This
variant
can
be
used
to
allow
a
stateless
client
(such
as
an
interface
engine)
to
submit
updated
results
to
a
server,
without
having
to
remember
the
logical
ids
that
the
server
has
assigned.
For
example,
a
client
updating
the
status
of
a
lab
result
from
"preliminary"
to
"final"
might
submit
the
finalized
result
using
PUT
path/Observation?identifier=http://my-lab-system|123
Note
that
transactions
and
conditional
create/update/delete
are
complex
interactions
and
it
is
not
expected
that
every
server
will
implement
them.
Servers
that
don't
support
the
conditional
update
SHOULD
return
an
HTTP
400
error
and
MAY
include
an
OperationOutcome
.
The
resource
MAY
contain
an
id
element,
but
does
not
need
to
(this
is
one
of
the
few
cases
where
a
resource
exists
without
an
id
element).
If
an
id
is
provided,
the
server
SHALL
ignore
it
-
see
documentation
for
the
update
interaction.
3.1.0.5
Managing
Resource
Contention
Lost
Updates
,
where
two
clients
update
the
same
resource,
and
the
second
overwrites
the
updates
of
the
first,
can
be
prevented
using
a
combination
of
the
ETag
and
If-Match
header.
This
is
also
known
as
'Optimistic
Locking'.
To
support
this
usage,
servers
SHOULD
always
return
an
ETag
header
with
each
resource:
HTTP 200 OK
Date: Sat, 09 Feb 2013 16:09:50 GMT
Last-Modified: Sat, 02 Feb 2013 12:02:47 GMT
ETag: W/"23"
Content-Type: application/fhir+json
If
provided,
the
value
of
the
ETag
SHALL
match
the
value
of
the
version
id
for
the
resource.
Servers
are
allowed
to
generate
the
version
id
in
whatever
fashion
that
they
wish,
so
long
as
they
are
valid
according
to
the
id
data
type,
and
are
unique
within
the
address
space
of
all
versions
of
the
same
resource.
When
resources
are
returned
as
part
of
a
bundle,
there
is
no
ETag
,
and
the
versionId
of
the
resource
is
used
directly.
If
the
client
wishes
to
request
a
version
aware
update,
it
submits
the
request
with
an
If-Match
header
that
quotes
the
ETag
from
the
server:
PUT /Patient/347 HTTP/1.1
If-Match: W/"23"
If
the
version
id
given
in
the
If-Match
header
does
not
match,
the
server
returns
a
412
Precondition
Failed
status
code
instead
of
updating
the
resource.
Servers
can
require
that
clients
provide
an
If-Match
header
by
returning
400
Client
Error
status
codes
when
no
If-Match
header
is
found.
Note
that
a
409
Conflict
can
be
returned
when
the
server
detects
the
update
cannot
be
done
(e.g.
due
to
server
side
pessimistic
locking).
3.1.0.6
patch
As
an
alternative
to
updating
an
entire
resource,
clients
can
perform
a
patch
operation.
This
can
be
useful
when
a
client
is
seeking
to
minimize
its
bandwidth
utilization,
or
in
scenarios
where
a
client
has
only
partial
access
or
support
for
a
resource.
The
patch
interaction
is
performed
by
an
HTTP
PATCH
command
as
shown:
PATCH [base]/[type]/[id] {?_format=[mime-type]}
The
body
of
a
PATCH
operation
SHALL
be
either:
a
JSON
Patch
document
with
a
content
type
of
application/json-patch+json
an
Raw
XML
Patch
document
with
a
content
type
of
application/xml-patch+xml
a
FHIRPath
Patch
parameters
resource
with
FHIR
Content
Type
In
either
case,
the
server
SHALL
process
its
own
copy
of
the
resource
in
the
format
indicated,
applying
the
operations
specified
in
the
document,
following
the
relevant
PATCH
specification.
When
the
operations
have
all
been
processed,
the
server
processes
the
resulting
document
as
an
Update
operation;
all
the
version
and
error
handling
etc.
apply
as
specified,
as
does
the
Prefer
Header
.
Processing
PATCH
operations
may
be
very
version
sensitive.
For
this
reason,
servers
SHALL
support
conditional
PATCH,
which
works
exactly
the
same
as
specified
for
update
in
Concurrency
Management
.
Clients
SHOULD
always
consider
using
version
specific
PATCH
operations
so
that
inappropriate
actions
are
not
executed.
Unlike
this
rest
of
this
page,
the
conditional
create,
update,
patch
and
delete
are
trial
use
until
further
experience
is
gained
with
their
use.
Their
status
will
be
reviewed
in
a
future
version
of
FHIR.
In
addition,
servers
that
support
PATCH,
and
that
support
Conditional
Update
SHOULD
also
support
conditional
PATCH.
When
the
server
processes
a
conditional
PATCH,
it
performs
a
search
using
its
standard
search
facilities
for
the
resource
type,
with
the
goal
of
resolving
a
single
logical
id
for
this
request.
The
action
it
takes
depends
on
how
many
matches
are
found:
No
matches
:
The
server
returns
a
404
Not
Found
One
Match
:
The
server
performs
the
update
against
the
matching
resource
Multiple
matches
:
The
server
returns
a
412
Precondition
Failed
error
indicating
the
client's
criteria
were
not
selective
enough
The
server
SHALL
ensure
that
the
narrative
in
a
resource
is
not
clinically
unsafe
after
the
PATCH
operation
is
performed.
Exactly
how
this
is
defined
and
can
be
achieved
depends
on
the
context,
and
how
narrative
is
being
maintained,
but
servers
may
wish
to
consider:
If
the
existing
narrative
has
a
status
!=
generated
,
the
server
could
reject
the
PATCH
operation
The
server
could
regenerate
the
narrative
once
the
operation
has
been
applied
to
the
data
In
some
limited
circumstances,
an
XML
PATCH
operation
could
update
the
narrative
The
server
could
delete
the
narrative,
on
the
basis
that
some
later
process
will
be
able
to
populate
it
correctly
Processing
XML
Patch
documents
is
tricky
because
of
namespace
handling.
Servers
SHALL
handle
namespaces
correctly,
but
note
that
FHIR
resources
only
contain
two
XML
namespaces,
for
FHIR
(
http://hl7.org/fhir
)
and
XHTML
(
http://www.w3.org/1999/xhtml
).
For
PATCH
Examples,
see
the
FHIR
test
cases
.
Patch
operations
may
be
performed
as
part
of
Batch
or
Transaction
Operations
using
the
FHIRPath
Patch
format.
Patch
is
not
defined
for
all
resources
-
see
not
about
PATCH
on
Binary
.
3.1.0.7
delete
The
delete
interaction
removes
an
existing
resource.
The
interaction
is
performed
by
an
HTTP
DELETE
command
as
shown:
DELETE [base]/[type]/[id]
The
request
body
SHALL
be
empty.
A
delete
interaction
means
that
subsequent
non-version
specific
reads
of
a
resource
return
a
410
HTTP
status
code
and
that
the
resource
is
no
longer
found
through
search
canonical
form
interactions.
Upon
successful
deletion,
or
if
the
resource
does
not
exist
at
all,
the
server
should
return
either
a
200
OK
if
the
response
contains
a
payload,
or
a
204
No
Content
with
no
response
payload,
or
a
202
Accepted
if
the
server
wishes
to
be
non-commital
about
the
outcome
of
the
delete.
Whether
to
support
delete
at
all,
or
for
a
particular
resource
type
or
a
particular
instance
is
at
the
discretion
of
the
server
based
on
the
policy
and
business
rules
that
apply
in
its
context.
If
the
server
refuses
to
delete
resources
of
that
type
as
a
blanket
policy,
then
it
should
return
the
405
Method
not
allowed
status
code.
If
the
server
refuses
to
delete
a
resource
because
of
reasons
specific
to
that
resource,
such
as
referential
integrity,
it
should
return
the
409
Conflict
status
code.
Note
that
the
servers
MAY
choose
to
enforce
business
rules
regarding
deletion
of
resources
that
are
being
referenced
by
other
resources,
but
they
+
also
MAY
NOT
do
so.
Performing
this
interaction
on
a
resource
that
is
already
deleted
has
no
effect,
and
the
server
should
return
either
a
200
OK
if
the
response
contains
a
payload,
or
a
204
No
Content
with
no
response
payload.
Resources
that
have
been
deleted
may
be
"brought
back
to
life"
by
a
subsequent
update
interaction
using
an
HTTP
PUT
.
Many
resources
have
a
status
element
that
overlaps
with
the
idea
of
deletion.
Each
resource
type
defines
what
the
semantics
of
the
deletion
interactions
are.
If
no
documentation
is
provided,
the
deletion
interaction
should
be
understood
as
deleting
the
record
of
the
resource,
with
nothing
about
the
state
of
the
real-world
corresponding
resource
implied.
For
servers
that
maintain
a
version
history,
the
delete
interaction
does
not
remove
a
resource's
version
history.
From
a
version
history
respect,
deleting
a
resource
is
the
equivalent
of
creating
a
special
kind
of
history
entry
that
has
no
content
and
is
marked
as
deleted.
Note
that
there
is
no
support
for
deleting
past
versions
-
see
notes
on
the
history
interaction.
Since
deleted
resources
may
be
brought
back
to
life,
servers
MAY
include
an
ETag
on
the
delete
response
to
allow
version
contention
management
when
a
resource
is
brought
back
to
life.
Note
that
irrespective
of
this
rule,
servers
are
free
to
completely
delete
the
resource
and
it's
history
if
policy
or
business
rules
make
this
the
appropriate
action
to
take.
3.1.0.7.1
Conditional
delete
Unlike
this
rest
of
this
page,
the
conditional
create,
update,
patch
and
delete
are
trial
use
until
further
experience
is
gained
with
their
use.
Their
status
will
be
reviewed
in
a
future
version
of
FHIR.
The
conditional
delete
interaction
allows
a
client
to
delete
an
existing
resource
based
on
some
selection
criteria,
rather
than
by
a
specific
logical
id
.
To
accomplish
this,
the
client
issues
an
HTTP
DELETE
as
shown:
DELETE [base]/[type]/?[search parameters]
When
the
server
processes
this
delete,
it
performs
a
search
as
specified
using
the
standard
search
facilities
for
the
resource
type.
The
action
it
takes
depends
on
how
many
matches
are
found:
No
matches
or
One
Match
:
The
server
performs
an
ordinary
delete
on
the
matching
resource
Multiple
matches
:
A
server
may
choose
to
delete
all
the
matching
resources,
or
it
may
choose
to
return
a
412
Precondition
Failed
error
indicating
the
client's
criteria
were
not
selective
enough.
A
server
indicates
whether
it
can
delete
multiple
resources
in
its
Capability
Statement
(.rest.resource.conditionalDelete)
This
variant
can
be
used
to
allow
a
stateless
client
(such
as
an
interface
engine)
to
delete
a
resource
on
a
server,
without
having
to
remember
the
logical
ids
that
the
server
has
assigned.
For
example,
a
client
deleting
a
lab
atomic
result
might
delete
the
resource
using
DELETE
/Observation?identifier=http://my-lab-system|123
.
Note
that
transactions
and
conditional
create/update/delete
are
complex
interactions
and
it
is
not
expected
that
every
server
will
implement
them.
Servers
that
don't
support
the
conditional
update
SHOULD
return
an
HTTP
400
error
and
MAY
include
an
OperationOutcome
.
3.1.0.8
create
The
create
interaction
creates
a
new
resource
in
a
server-assigned
location.
If
the
client
wishes
to
have
control
over
the
id
of
a
newly
submitted
resource,
it
should
use
the
update
interaction
instead.
The
create
interaction
is
performed
by
an
HTTP
POST
command
as
shown:
POST [base]/[type] {?_format=[mime-type]}
The
request
body
SHALL
be
a
FHIR
Resource.
The
resource
does
not
need
to
have
an
id
element
(this
is
one
of
the
few
cases
where
a
resource
exists
without
an
id
element).
If
an
id
is
provided,
the
server
SHALL
ignore
it.
If
the
request
body
includes
a
meta
,
the
server
SHALL
ignore
the
existing
versionId
and
lastUpdated
values.
The
server
SHALL
populate
the
id
,
meta.versionId
and
meta.lastUpdated
with
the
new
correct
values.
Servers
are
allowed
to
review
and
alter
the
other
metadata
values,
but
SHOULD
refrain
from
doing
so
(see
metadata
description
for
further
information).
A
server
SHOULD
otherwise
accept
the
resource
as
submitted
when
it
accepts
the
create,
and
return
the
same
content
when
it
is
subsequently
read.
However
some
systems
might
not
be
able
to
do
this;
see
the
note
on
transactional
integrity
for
discussion.
The
server
returns
a
201
Created
HTTP
status
code,
and
SHALL
also
return
a
Location
header
which
contains
the
new
Logical
Id
and
Version
Id
of
the
created
resource
version:
Location: [base]/[type]/[id]/_history/[vid]
where
[id]
and
[vid]
are
the
newly
created
id
and
version
id
for
the
resource
version.
The
Location
header
should
be
as
specific
as
possible
-
if
the
server
understands
versioning,
the
version
is
included.
If
a
server
does
not
track
versions,
the
Location
header
will
just
contain
[base]/[type]/[id].
The
Location
MAY
be
an
absolute
or
relative
URL.
Servers
SHOULD
return
an
ETag
header
with
the
versionId
(if
versioning
is
supported)
and
a
Last-Modified
header.
The
body
of
response
is
as
described
in
Managing
Return
Content
.
When
the
resource
syntax
or
data
is
incorrect
or
invalid,
and
cannot
be
used
to
create
a
new
resource,
the
server
returns
a
400
Bad
Request
HTTP
status
code.
When
the
server
rejects
the
content
of
the
resource
because
of
business
rules,
the
server
returns
a
422
Unprocessable
Entity
error
HTTP
status
code.
In
either
case,
the
server
SHOULD
include
a
response
body
containing
an
OperationOutcome
with
detailed
error
messages
describing
the
reason
for
the
error.
Note:
Servers
MAY
choose
to
preserve
XML
comments,
instructions,
and
formatting
or
JSON
whitespace
when
accepting
creates,
but
are
not
required
to
do
so.
The
impact
of
this
on
digital
signatures
may
need
to
be
considered.
Common
HTTP
Status
codes
returned
on
FHIR-related
errors
(in
addition
to
normal
HTTP
errors
related
to
security,
header
and
content
type
negotiation
issues):
400
Bad
Request
-
resource
could
not
be
parsed
or
failed
basic
FHIR
validation
rules
404
Not
Found
-
resource
type
not
supported,
or
not
a
FHIR
end-point
422
Unprocessable
Entity
-
the
proposed
resource
violated
applicable
FHIR
profiles
or
server
business
rules.
This
should
be
accompanied
by
an
OperationOutcome
resource
providing
additional
detail
In
general,
if
an
instance
fails
the
constraints
documented
in
the
CapabilityStatement
then
the
response
should
be
a
400,
whereas
if
the
instance
fails
other
non-externally
described
business
rules,
the
response
would
be
a
422
error.
However,
there's
no
expectation
that
servers
will
tightly
adhere
to
this
differentiation
(nor
is
it
clear
that
it
makes
much
difference
whether
they
do
or
not).
In
practice,
servers
may
also
return
5xx
errors
in
these
cases
without
being
deemed
non-conformant.
For
additional
information
on
how
systems
may
behave
when
processing
updates,
refer
to
the
Variations
between
Submitted
data
and
Retrieved
data
page.
3.1.0.8.1
Conditional
create
Unlike
this
rest
of
this
page,
the
conditional
create,
update,
patche
and
delete
are
trial
use
until
further
experience
is
gained
with
their
use.
Their
status
will
be
reviewed
in
a
future
version
of
FHIR.
The
conditional
create
interaction
allows
a
client
to
create
a
new
resource
only
if
some
equivalent
resource
does
not
already
exist
on
the
server.
The
client
defines
what
equivalence
means
in
this
case
by
supplying
a
FHIR
search
query
using
an
HL7
defined
extension
header
"
If-None-Exist
"
as
shown:
If-None-Exist: [search parameters]
The
parameter
just
contains
the
search
parameters
(what
would
be
in
the
URL
following
the
"?").
When
the
server
processes
this
create,
it
performs
a
search
as
specified
using
its
standard
search
facilities
for
the
resource
type.
The
action
it
takes
depends
on
how
many
matches
are
found:
No
matches
:
The
server
processes
the
create
as
above
One
Match
:
The
server
ignores
the
post
and
returns
200
OK
Multiple
matches
:
The
server
returns
a
412
Precondition
Failed
error
indicating
the
client's
criteria
were
not
selective
enough
This
variant
can
be
used
to
avoid
the
risk
of
two
clients
creating
duplicate
resources
for
the
same
record.
For
example,
a
client
posting
a
new
lab
result
might
specify
If-None-Exist:
identifier=http://my-lab-system|123
to
ensure
it
does
not
create
a
duplicate
record.
Note
that
transactions
and
conditional
create/update/delete
are
complex
interactions
and
it
is
not
expected
that
every
server
will
implement
them.
Servers
that
don't
support
the
conditional
update
SHOULD
return
an
HTTP
400
error
and
MAY
include
an
OperationOutcome
.
3.1.0.9
search
This
interaction
searches
a
set
of
resources
based
on
some
filter
criteria.
The
interaction
can
be
performed
by
several
different
HTTP
commands.
GET [base]/[type]{?[parameters]{&_format=[mime-type]}}
This
searches
all
resources
of
a
particular
type
using
the
criteria
represented
in
the
parameters.
Because
of
the
way
that
some
user
agents
and
proxies
treat
GET
and
POST
requests,
in
addition
to
the
get
based
search
method
above,
servers
that
support
search
SHALL
also
support
a
POST
based
search:
POST [base]/[type]/_search{?[parameters]{&_format=[mime-type]}}
Content-Type: application/x-www-form-urlencoded
param1=value¶m2=value
This
has
exactly
the
same
semantics
as
the
equivalent
GET
command.
Note
that
in
the
POST
variant,
parameters
may
appear
in
both
the
URL
and
the
body.
Parameters
have
the
same
meaning
in
either
place.
Since
parameters
can
repeat,
putting
them
in
both
places
is
the
same
as
repeating
them
(which
is
valid
for
some
parameters
and
not
for
others).
Note:
Supporting
GET
means
that
PHI
(Personal
health
information)
might
appear
in
search
parameters,
and
therefore
in
HTTP
logs.
For
this
reason
logs
should
be
regarded
as
being
as
sensitive
as
the
resources
themselves.
This
is
a
general
requirement
irrespective
of
the
use
of
GET
-
see
the
security
page
for
further
commentary.
All
these
search
interactions
take
a
series
of
parameters
that
are
a
series
of
name=value
pairs
encoded
in
the
URL
(or
as
an
application/x-www-form-urlencoded
(
Format
Specification
)
submission
for
a
POST
).
(See
W3C
HTML
forms
).
Note:
application/x-www-form-urlencoded
is
supported
for
POST
so
that
invoking
a
search
by
GET
or
POST
can
be
done
from
HTML
forms
in
a
browser
(though
considerable
active
content
might
be
required
in
the
browser),
although
this
is
not
the
main
usage.
A
HEAD
request
can
also
be
used
-
see
below
.
Searches
are
processed
as
specified
for
the
Search
handling
mechanism
.
If
the
search
succeeds,
the
server
SHALL
return
a
200
OK
HTTP
status
code
and
the
return
content
SHALL
be
a
Bundle
with
type
=
searchset
containing
the
results
of
the
search
as
a
collection
of
zero
or
more
resources
in
a
defined
order.
Note
that
resources
returned
in
the
search
bundle
MAY
be
located
on
the
another
server
than
the
one
that
performs
the
search
(i.e.
the
Bundle.entry.fullUrl
may
be
different
to
the
[base]
from
the
search
URL).
The
result
collection
can
be
long,
so
servers
may
use
paging.
If
they
do,
they
SHALL
use
the
method
described
below
(adapted
from
RFC
5005
(Feed
Paging
and
Archiving
)
Definition
for
breaking
the
collection
into
pages
if
appropriate.
The
server
MAY
also
return
an
OperationOutcome
resource
within
the
searchset
Bundle
entries
that
contains
additional
information
about
the
search;
if
one
is
sent
it
SHALL
NOT
include
any
issues
with
a
fatal
or
error
severity
,
and
it
SHALL
be
marked
with
a
Bundle.entry.search.mode
of
outcome
.
If
the
search
fails
(cannot
be
executed,
not
that
there
are
no
matches),
the
return
value
return
value
SHALL
be
a
status
code
4xx
or
5xx
with
an
OperationOutcome
.
Common
HTTP
Status
codes
returned
on
FHIR-related
errors
(in
addition
to
normal
HTTP
errors
related
to
security,
header
and
content
type
negotiation
issues):
Value
SetQuantityComparator
Applications
SHALL
return
a
resource
that
describes
the
functionality
of
the
server
end-point.
The
information
returned
depends
on
the
value
of
the
mode
parameter:
full
(or
mode
not
present)
A
Capability
Statement
that
specifies
which
resource
types
and
interactions
are
supported
normative
As
above,
but
only
the
normative
portions
of
the
Capability
Statement
terminology
A
TerminologyCapabilities
resource
that
provides
further
information
about
terminologies
which
are
supported
by
the
server
Servers
MAY
ignore
the
mode
parameter
and
return
a
CapabilityStatement
resource.
Note:
servers
might
be
required
to
support
this
parameter
in
further
versions
of
this
specification.
If
a
404
Unknown
is
returned
from
the
GET
,
FHIR
(or
the
specified
version)
is
not
supported
on
the
nominated
service
url.
An
ETag
header
SHOULD
be
returned
with
the
Response.
The
value
of
the
ETag
header
SHALL
change
if
the
returned
resource
changes.
Servers
SHOULD
check
for
the
fhirVersion
MIME-type
parameter
when
processing
this
request.
The
resource
returned
typically
has
an
arbitrary
id,
and
no
meta
element,
though
it
is
not
prohibited.
Capability
statements
can
become
quite
large;
servers
are
encouraged
to
support
the
_summary
and
_elements
parameters
on
the
capabilities
interaction,
though
this
is
not
required.
In
addition,
servers
are
encouraged
to
implement
the
$subset
and
$implements
operations
to
make
it
easy
for
a
client
to
check
conformance.
In
addition
to
this
capabilities
interaction,
a
server
may
also
choose
to
provide
the
standard
set
of
interactions
(
read
,
search
,
create
,
update
)
defined
on
this
page
for
the
CapabilityStatement
Resource
end-point.
This
is
different
from
the
capabilities
interaction:
capabilities
interaction
returns
a
capability
statement
describing
the
server's
current
operational
functionality
CapabilityStatement
end-point
manages
a
repository
of
capability
statements
(e.g.
the
HL7
capability
statement
registry)
All
servers
are
required
to
support
the
capabilities
interaction,
but
servers
may
choose
whether
they
wish
to
support
the
CapabilityStatement
end-point,
just
like
any
other
end-point.
Implementation
Note:
In
DSTU
2
and
earlier,
the
resource
that
this
interaction
returned
was
named
"Conformance".
Clients
often
connect
to
a
server,
and
use
the
capabilities
interaction
to
check
whether
they
are
version
and/or
feature
compatible
with
the
server.
Such
clients
should
be
able
to
process
either
a
Conformance
or
a
CapabilityStatement
resource.
3.1.0.11
batch/transaction
The
batch
and
transaction
interactions
submit
a
set
of
actions
to
perform
on
a
server
in
a
single
HTTP
request/response.
The
actions
may
be
performed
independently
as
a
"batch",
or
as
a
single
atomic
"transaction"
where
the
entire
set
of
changes
succeed
or
fail
as
a
single
entity.
Multiple
actions
on
multiple
resources
of
the
same
or
different
types
may
be
submitted,
and
they
may
be
a
mix
of
other
interactions
defined
on
this
page
(e.g.
read
,
search
,
create
,
update
,
delete
,
etc.),
or
using
the
operations
framework.
The
transaction
mode
is
especially
useful
where
one
would
otherwise
need
multiple
interactions,
possibly
with
a
risk
of
loss
of
referential
integrity
if
a
later
interaction
fails
(e.g.
when
storing
a
Provenance
resource
and
its
corresponding
target
resource,
or
and
IHE-MHD
transaction
"Provide
Document
Resources"
with
a
DocumentManifest,
and
some
number
of
DocumentReference,
List,
and
Binary
resources).
Note
that
transactions
and
conditional
create/update/delete
are
complex
interactions
and
it
is
not
expected
that
Usage
note:
every
server
will
implement
them.
Servers
that
don't
support
the
batches
or
transactions
SHOULD
return
an
HTTP
400
error
and
MAY
include
an
OperationOutcome
.
A
batch
or
transaction
interaction
is
performed
by
an
HTTP
POST
command
as
shown:
POST [base] {?_format=[mime-type]}
The
content
of
the
post
submission
is
a
Bundle
with
Bundle.type
=
batch
or
transaction
.
Each
entry
SHALL
carry
request
details
(
Bundle.entry.request
)
that
provides
the
HTTP
details
of
the
action
in
order
to
inform
the
system
processing
the
batch
or
transaction
what
to
do
for
the
entry.
If
the
HTTP
command
is
a
PUT
or
POST
,
then
the
entry
SHALL
contain
a
resource
for
the
body
of
the
action.
The
resources
in
the
bundle
are
each
processed
separately
as
if
they
were
an
individual
interaction
or
operation
as
otherwise
described
on
this
page,
or
the
Operations
framework
.
The
actions
are
subject
to
the
normal
processing
for
each,
including
the
meta
element
,
verification
and
version
aware
updates,
and
transactional
integrity
.
In
the
case
of
a
batch
each
entry
is
treated
as
if
an
individual
interaction
or
operation,
in
the
case
of
a
transaction
all
interactions
or
operations
either
succeed
or
fail
together
(see
below).
Examples:
Transaction
Example
with
Matching
Response
Batch
request
to
fetch
Meds
&
Allergies
with
Response
Batch
request
to
fetch
simple
Patient
Summary
with
Response
3.1.0.11.1
Batch
Processing
Rules
For
a
batch
,
there
SHALL
be
no
interdependencies
between
the
different
entries
in
the
Bundle
that
cause
change
on
the
server.
The
success
or
failure
of
one
change
SHOULD
not
alter
the
success
or
failure
or
resulting
content
of
another
change.
Servers
SHOULD
validate
that
this
is
the
case.
Note
that
it
is
considered
that
servers
execute
the
batch
in
the
same
order
as
that
specified
below
for
transactions,
though
the
order
of
execution
should
not
matter
given
the
previous
rule.
References
within
a
Bundle.entry.resource
to
another
Bundle.entry.resource
that
is
being
created
within
the
batch
are
considered
to
be
non-conformant.
When
processing
the
batch,
the
HTTP
response
code
is
200
Ok
if
the
batch
was
processed
correctly,
regardless
of
the
success
of
the
operations
within
the
Batch.
To
determine
the
status
of
the
operations,
look
inside
the
returned
Bundle.
A
response
code
on
an
entry
of
other
than
2xx
(200,
202
etc)
indicates
that
processing
the
request
in
the
entry
failed.
3.1.0.11.2
Transaction
Processing
Rules
For
a
transaction
,
servers
SHALL
either
accept
all
actions
and
return
a
200
OK,
along
with
a
response
bundle
(see
below),
or
reject
all
resources
and
return
an
HTTP
400
or
500
type
response.
It
is
not
an
error
if
the
submitted
bundle
has
no
resources
in
it.
The
outcome
of
processing
the
transaction
SHALL
NOT
depend
on
the
order
of
the
resources
in
the
transaction.
A
resource
can
only
appear
in
a
transaction
once
(by
identity).
Because
of
the
rules
that
a
transaction
is
atomic
where
all
actions
pass
or
fail
together
and
the
order
of
the
entries
doesn't
matter,
there
is
a
particular
order
in
which
to
process
the
actions:
Process
any
DELETE
interactions
Process
any
POST
interactions
Process
any
PUT
or
PATCH
interactions
Process
any
GET
or
HEAD
interactions
Resolve
any
conditional
references
If
any
resource
identities
(including
resolved
identities
from
conditional
update/delete)
overlap
in
steps
1-3,
then
the
transaction
SHALL
fail.
A
transaction
may
include
references
from
one
resource
to
another
in
the
bundle,
including
circular
references
where
resources
refer
to
each
other.
When
the
server
assigns
a
new
id
to
any
resource
in
the
bundle
which
effort
has
a
POST
method
as
part
of
the
processing
rules
above,
it
SHALL
also
update
any
references
to
that
resource
in
the
same
bundle
as
they
are
processed
(see
about
Ids
in
a
bundle
).
References
to
resources
that
are
not
part
of
the
bundle
are
left
untouched.
Version-specific
references
should
remain
as
version-specific
references
after
the
references
have
been
updated.
Note
that
when
building
a
transaction,
a
client
can
use
arbitrarily
chosen
version
references
since
they
will
all
be
re-assigned
anyway.
Servers
SHALL
replace
all
matching
links
in
the
bundle,
whether
they
are
found
in
the
resource
ids,
resource
references
,
elements
of
type
uri
,
url
,
oid
,
uuid
,
and
<a
href=""
&
<img
src=""
in
the
narrative.
Elements
of
type
canonical
are
not
replaced.
When
processing
a
"POST"
(create),
the
full
URL
is
treated
as
the
id
of
the
resource
on
the
source,
and
is
ignored;
the
server
generates
an
id
for
the
resource.
For
updates,
the
server
performs
a
mapping
between
the
fullUrl
specified
and
the
local
URL
the
server
knows
that
instance
as,
if
possible.
If
the
server
does
not
have
a
mapping
for
the
fullUrl,
the
server
ignores
the
base
URL
and
attempts
an
update
assuming
the
base
is
the
same
as
the
server
base.
This
allows
the
same
transaction
bundle
to
be
sent
to
multiple
systems
without
changing
the
fullUrls
for
each
target.
When
processing
a
batch
or
transaction,
a
server
MAY
choose
to
honor
existing
logical
ids
(e.g.
Observation/1234
remains
as
Observation/1234
on
the
server),
but
since
this
is
only
safe
in
controlled
circumstances
,
servers
may
choose
to
assign
new
ids
to
all
submitted
resources,
irrespective
of
any
claimed
logical
id
in
the
resource,
or
fullUrl
on
entries
in
the
batch/transaction.
Conditional
References
When
constructing
the
bundle,
the
client
might
not
know
the
logical
id
of
a
resource,
but
it
may
know
identifying
information
-
e.g.
an
identifier.
This
situation
arises
commonly
when
building
transactions
from
v2
messages.
The
client
could
resolve
that
identifier
to
a
logical
id
using
a
search,
but
that
would
mean
that
the
resolution
to
a
logical
id
does
not
occur
within
the
same
transaction
as
the
commit
(as
well
as
significantly
complicating
the
client).
Because
of
this,
in
a
transaction
(and
only
in
a
transaction),
references
to
resources
may
be
replaced
by
a
search
URI
that
describes
how
to
find
the
correct
reference:
<Bundle xmlns="http://hl7.org/fhir">
<id value="20160113160203" />
<type value="transaction" />
<entry>
<fullUrl value="urn:uuid:c72aa430-2ddc-456e-7a09-dea8264671d8" />
<resource>
<Observation>
<subject>
<reference value="Patient?identifier=12345"/>
</subject>
<--! rest of resource omitted -->
</Observation>
</resource>
<request>
<method value="POST" />
</request>
</entry>
<Bundle>
The
search
URI
is
relative
to
the
server's
[base]
path,
and
always
starts
with
a
resource
type:
[type]?parameters...
.
Only
filtering
parameters
are
allowed;
none
of
the
parameters
that
control
the
return
of
resources
are
relevant.
When
processing
transactions,
servers
SHALL:
check
all
references
for
search
URIs
For
search
URIs,
use
the
search
to
locate
matching
resources
if
there
are
no
matches,
or
multiple
matches,
the
transaction
fails,
and
an
error
is
returned
to
the
user
if
there
is
a
single
match,
the
server
replaces
the
search
URI
with
a
reference
to
the
matching
resource
3.1.0.11.3
Batch/Transaction
Response
For
a
batch,
or
a
successful
transaction,
the
response
the
server
SHALL
return
a
Bundle
with
type
set
to
batch-response
or
transaction-response
that
contains
one
entry
for
each
entry
in
the
request,
in
the
same
order,
with
the
outcome
of
processing
the
entry.
For
a
failed
transaction,
the
server
returns
a
single
OperationOutcome
instead
of
a
Bundle.
A
client
may
use
the
returned
Bundle
to
track
the
outcomes
of
processing
the
entry,
and
the
identities
assigned
to
the
resources
by
the
server.
Each
entry
element
SHALL
contain
a
response
element
which
details
the
outcome
of
processing
the
entry
-
the
HTTP
status
code,
and
the
location
and
ETag
header
values,
which
are
used
for
identifying
and
versioning
the
resources.
In
addition,
a
resource
may
be
included
in
the
entry,
as
specified
by
the
Prefer
header.
3.1.0.11.4
Accepting
other
Bundle
types
A
server
may
choose
to
accept
bundle
types
other
than
batch
or
transaction
when
POST
ed
to
the
[base]
URL.
Bundles
of
type
history
inherently
have
the
same
structure
as
a
transaction
,
and
can
be
treated
as
either
a
transaction
or
batch,
so
servers
SHOULD
accept
a
history
Bundle
-
this
makes
it
possible
to
replicate
data
from
one
server
to
another
easily
using
a
pub/sub
model.
Note,
however,
that
the
original
transaction
boundaries
might
not
be
represented
in
a
history
list,
and
a
resource
may
occur
more
than
once
in
a
history
list,
so
servers
processing
history
bundles
must
have
some
strategy
to
manage
this.
When
processing
a
history
bundle
via
a
transaction,
any
entries
with
the
request
method
of
POST
must
use
the
Bundle.entry.resource.id
(which
must
match
the
Bundle.entry.response.location
)
for
that
resource
so
that
references
are
preserved.
For
other
Bundle
types,
should
the
server
choose
to
accept
them,
there
will
be
no
request
element
(note
that
every
entry
will
have
a
resource).
In
this
case,
the
server
treats
the
entry
as
either
a
create
or
an
update
interaction,
depending
on
whether
it
recognizes
the
identity
of
the
resource
-
if
the
identity
of
the
resource
refers
to
a
valid
location
on
the
server,
it
should
treat
it
as
an
update
to
that
location.
Note:
this
option
allows
a
client
to
delegate
the
matching
process
to
the
server.
3.1.0.12
history
The
history
interaction
retrieves
the
history
of
either
a
particular
resource,
all
resources
of
a
given
type,
or
all
resources
supported
by
the
system.
These
three
variations
of
the
history
interaction
are
performed
by
HTTP
GET
command
as
shown:
GET [base]/[type]/[id]/_history{?[parameters]&_format=[mime-type]}
GET [base]/[type]/_history{?[parameters]&_format=[mime-type]}
GET [base]/_history{?[parameters]&_format=[mime-type]}
The
return
content
is
a
Bundle
with
type
set
to
history
containing
the
specified
version
history,
sorted
with
oldest
versions
last,
and
including
deleted
resources.
Each
entry
SHALL
minimally
contain
at
least
one
of:
a
resource
which
holds
the
resource
as
it
is
at
the
conclusion
of
the
interaction,
or
a
request
with
entry.request.method
The
request
provides
information
about
the
result
of
the
interaction
that
led
to
this
new
version,
and
allows,
for
instance,
a
subscriber
system
to
differentiate
between
newly
created
resources
and
updates
to
existing
resources.
The
principal
reason
a
resource
might
be
missing
is
that
the
resource
was
changed
by
some
other
channel
rather
than
via
the
RESTful
interface.
If
the
entry.request.method
is
a
PUT
or
a
POST
,
the
entry
SHALL
contain
a
resource.
The
interactions
create
,
update
,
and
delete
create
history
entries.
Other
interactions
do
not
(note
that
these
operations
may
produce
side-effects
such
as
new
AuditEvent
resources;
these
are
represented
as
create
interactions
in
their
own
right).
New
resources
or
updates
to
existing
resources
that
are
triggered
by
operations
also
appear
in
the
history,
as
do
updates
to
the
resources
that
result
from
interactions
outside
the
scope
of
the
RESTful
interface.
A
HEAD
request
can
also
be
used
-
see
below
.
A
create
interaction
is
represented
in
a
history
interaction
in
the
following
way:
<entry>
<resource>
<Patient>
<!-- the id of the created resource -->
<id value="23424"/>
<!-- snip -->
</Patient>
</resource>
<request>
<!-- POST: this was a create -->
<method value="POST"/>
<url value="Patient"/>
</request>
<!-- response carries the instant the server processed the create -->
<response>
<lastModified value="2014-08-15T10:35:02.034Z"/>
</response>
</entry>
A
delete
interaction
is
represented
in
a
history
interaction
in
the
following
way:
<entry>
<!-- no resource included for a delete -->
<request>
<method value="DELETE"/>
<url value="Patient/[id]"/>
</request>
<!-- response carries the instant the server processed the delete -->
<response>
<lastModified value="2014-08-20T11:05:34.174Z"/>
</response>
</entry>
Notes:
conditional
creates,
updates
and
deletes
are
converted
to
direct
updates
and
deletes
in
a
history
list
operations
do
not
appear
directly
in
the
history
log,
but
side
effects
(e.g.
creation
of
audit
logs.
stored
binaries,
etc.)
will
appear
where
relevant
The
resource
in
the
entry
is
the
resource
as
processed
by
the
server,
not
as
submitted
by
the
client
(
may
be
different
)
The
server
SHOULD
populate
at
least
response.lastModified
so
the
time
of
processing
is
clear
in
the
history
record
Servers
may
choose
to
only
record
successful
interactions.
Servers
may
choose
to
only
use
200
OK
instead
of
other
more
specific
success
codes
There
may
be
more
than
one
version
of
a
given
resource
in
the
history
In
addition
to
the
standard
_format
parameter,
the
parameters
to
this
interaction
may
also
include:
_count
:
integer
The
maximum
number
of
search
results
on
a
page,
excluding
related
resources
included
by
_include
or
_revinclude
or
OperationOutcomes.
The
server
is
not
bound
to
return
the
number
requested,
but
cannot
return
more
_since
:
instant
Only
include
resource
versions
that
were
created
at
or
after
the
given
instant
in
time
_at
:
date(Time)
Only
include
resource
versions
that
were
current
at
some
point
during
the
time
period
specified
in
the
date
time
value
(see
Search
notes
on
date
searching
)
_list
:
reference
Only
include
resource
versions
that
are
referenced
in
the
specified
list
(
current
list
references
are
allowed)
Each
of
these
parameters
SHALL
NOT
appear
more
than
once.
The
history
list
can
be
restricted
to
a
limited
period
by
specifying
a
_since
parameter
which
contains
a
full
date
time
with
time
zone.
Clients
should
be
aware
that
due
to
timing
imprecision,
they
may
receive
notifications
of
a
resource
update
on
the
boundary
instant
more
than
once.
Servers
are
not
required
to
support
a
precision
finer
than
by
second.
The
updates
list
can
be
long,
so
servers
may
use
paging.
If
they
do,
they
SHALL
use
the
method
described
below
for
breaking
the
list
into
pages
if
appropriate,
and
respect
the
specified
_count
across
pages.
The
history
interaction
can
be
used
to
set
up
a
subscription
from
one
system
to
another,
so
that
resources
are
synchronized
between
them.
Refer
to
the
Subscription
resource
for
an
alternate
means
of
system
synchronization.
Additional
Notes
about
maintaining
a
history
of
resources:
The
history
is
a
record
version
history
on
a
per-resource
basis.
It
is
not
intended
to
support
concurrent
versions,
or
multi-branch
version
history
Accordingly,
there
is
no
way
to
update
or
delete
past
versions
of
the
record,
except
that
the
metadata
can
be
modified
(mainly
for
access
control
purposes)
All
past
versions
of
a
resource
are
considered
to
be
superceded,
and
no
longer
active,
but
retained
for
audit/integrity
purposes
In
the
case
that
a
past
version
of
a
resource
needs
to
be
explicitly
documented
as
'entered-in-error'
,
use
a
Provenance
resource
pointing
to
the
past
version
of
the
resource
When
tracing
the
history
of
a
specific
resource,
applications
should
retrieve
any
provenance
resources
relating
to
the
resource
or
its
past
versions
If
a
request
is
made
for
a
history
that
is
not
available
(e.g.
the
system
does
not
keep
a
history
for
the
type,
or
the
particular
instance),
the
server
should
return
a
404
Not
Found
along
with
an
OperationOutcome
explaining
the
problem
Thereis
a
caveat
with
the
_list
parameter,
associated
with
changes
to
the
list
while
making
repeated
periodic
queries;
if
the
list
changes,
the
response
will
include
changes
to
the
resources
in
the
list
for
the
period
specified,
but
will
omit
both
later
changes
to
items
no
longer
in
the
list,
or
older
changes
associated
with
items
in
the
list.
This
might
not
be
a
problem,
but
implementers
should
be
aware
of
this
issue.
3.1.0.13
Transactional
Integrity
When
processing
create
and
update
interactions,
a
FHIR
server
is
not
obliged
to
accept
the
entire
resource
as
it
is;
when
the
resource
is
retrieved
through
a
read
interaction
subsequently,
the
resource
may
be
different.
The
difference
may
arise
for
several
reasons:
The
server
merged
updated
content
with
existing
content
The
server
applied
business
rules
and
altered
the
content
The
server
does
not
fully
support
all
the
features
or
possible
values
of
the
resource
Note
that
there
is
no
general-purpose
method
to
make
merging
with
existing
content
or
altering
the
content
by
business
rules
safe
or
predictable
-
what
is
possible,
safe
and/or
required
is
highly
context
dependent.
These
kinds
of
behaviors
may
be
driven
by
security
considerations.
With
regard
to
incomplete
support,
clients
can
consult
the
server's
base
CapabilityStatement
profile
references
to
determine
which
features
or
values
the
server
does
not
support.
The
PATCH
operation
offers
some
support
for
making
changes
to
a
part
of
a
resource
and
should
be
used
where
a
client
wishes
to
change
just
part
of
a
resource,
though
transactional
integrity
issues
are
still
important.
To
the
degree
that
the
server
alters
the
resource
for
any
of
the
3
reasons
above,
the
FHIR
server
will
create
implementation
consequences
for
the
eco-system
that
it
is
part
of,
which
will
need
to
be
managed
(i.e.
it
will
cost
more).
For
this
reason,
servers
SHOULD
change
the
resource
as
little
as
possible,
given
the
constraints
of
the
system
exposing
the
FHIR
resource.
However
due
to
the
variability
that
exists
within
healthcare,
this
specification
allows
that
servers
MAY
alter
the
resource
on
create/update.
Similarly,
to
the
degree
that
an
implementation
context
makes
special
rules
about
merging
content
or
altering
the
content,
that
context
will
become
more
expensive
to
maintain.
Although
these
rules
are
stated
with
regard
to
servers,
a
similar
concept
applies
to
clients
-
to
the
degree
that
different
client
systems
interacting
with
the
server
do
not
support
the
same
feature
set,
the
clients
and/or
the
server
will
be
forced
to
implement
custom
logic
to
prevent
information
from
being
lost
or
corrupted.
Some
of
these
problems
can
be
mitigated
by
following
a
pattern
built
on
top
of
version-aware
updates.
In
this
pattern:
The
server
provides
a
read
interaction
for
any
resource
it
accepts
update
interactions
on
Before
updating,
the
client
read
s
the
latest
version
of
the
resource
The
client
applies
the
changes
it
wants
to
the
resource,
leaving
other
information
intact
(note
the
extension
related
rules
around
this)
The
client
writes
the
result
back
as
an
update
interaction,
and
is
able
to
handle
a
409
or
412
response
(usually
by
trying
again)
If
clients
follow
this
pattern,
then
information
from
other
systems
that
they
do
not
understand
will
be
maintained
through
the
update.
Note
that
it
is
possible
for
a
server
to
choose
to
maintain
the
information
that
would
be
lost,
but
there
is
no
defined
way
for
a
server
to
determine
whether
the
client
omitted
the
information
because
it
wasn't
supported
(perhaps
in
this
case)
or
whether
it
wishes
to
delete
the
information.
3.1.0.13.1
Conformance
Both
client
and
server
systems
SHOULD
clearly
document
how
transaction
integrity
is
handled,
in
the
documentation
in
the
CapabilityStatement
.
3.1.0.14
Paging
Servers
SHOULD
support
paging
for
the
results
of
a
search
or
history
interaction,
and
if
they
do,
they
SHALL
conform
to
this
method
(adapted
from
RFC
5005
(Feed
Paging
and
Archiving)
for
sending
continuation
links
to
the
client
when
returning
a
Bundle
(e.g.
with
history
and
search
).
If
the
server
does
not
do
this
then
there
is
no
way
to
continue
paging.
This
example
shows
the
third
page
of
a
search
result:
<Bundle xmlns="http://hl7.org/fhir">
<!-- snip metadata -->
<!-- This Search url starts with base search, and adds the effective
parameters, and additional parameters for search state. All searches
SHALL return this value.
In this case, the search continuation method is that the server
maintains a state, with page references into the stateful list.
-->
<link>
<relation value="self">
<url value="http://example.org/Patient?name=peter&stateid=23&page=3"/>
</link>
<!-- 4 links for navigation in the search. All of these are optional, but recommended -->
<link>
<relation value="first"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=1"/>
</link>
<link>
<relation value="previous"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=2"/>
</link>
<link>
<relation value="next"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=4"/>
</link>
<link>
<relation value="last"/>
<url value="http://example.org/Patient?name=peter&stateid=23&page=26"/>
</link>
<!-- then the search results... -->
</Bundle>
The
links
are
opaque
to
the
client,
have
no
dictated
structure,
and
only
the
server
understands
them.
The
client
must
use
the
server
supplied
links
in
order
to
traverse
the
pages.
A
server
MAY
add
additional
state
tracking
parameters
to
the
links,
as
shown
in
the
example
above,
though
the
server
need
not
use
a
stateful
paging
method
as
shown
in
this
example
-
it
is
at
the
discretion
of
the
server
how
to
best
ensure
that
the
continuation
retains
integrity
in
the
context
of
ongoing
changes
to
the
resources.
An
alternative
approach
is
to
use
version
specific
references
to
the
records
on
the
boundaries,
but
this
is
subject
to
continuity
failures
when
records
are
updated.
A
server
MAY
inform
the
client
of
the
total
number
of
resources
returned
by
the
interaction
for
which
the
results
are
paged
using
the
Bundle.total
.
Note
that
for
search,
where
_include
can
be
used
to
return
additional
related
resources,
the
total
number
of
resources
in
the
feed
may
exceed
the
number
indicated
in
totalResults.
In
the
case
of
a
search
,
the
initial
request
may
be
made
via
a
POST,
but
the
follow
up
page
requests
will
be
made
via
GET
requests.
However
servers
SHOULD
allow
for
a
client
to
convert
the
follow
up
requests
to
be
made
via
a
POST.
3.1.0.15
Support
for
HEAD
Anywhere
that
a
GET
request
can
be
used,
a
HEAD
request
is
also
allowed.
HEAD
requests
are
treated
as
specified
in
HTTP:
same
response
as
a
GET,
but
with
no
body.
Servers
that
do
not
support
HEAD
MUST
respond
in
accordance
with
the
HTTP
specification,
for
example
using
a
405
("method
not
allowed")
or
a
501
("not
implemented").
3.1.0.16
Custom
Headers
This
specification
defines
or
recommends
some
custom
headers
that
implementers
can
use
to
assist
with
deployment/debugging
purposes:
X-Request-Id
A
unique
id
to
for
the
request/response
assigned
by
either
client
or
server.
Request:
assigned
by
the
client.
Response:
assigned
by
the
server
X-Correlation-Id
A
client
assigned
request
id
echoed
back
in
the
response
X-Forwarded-For
Identifies
the
originating
IP
address
of
a
client
to
an
intermediary
X-Forwarded-Host
Identifies
the
original
host
requested
by
the
client
in
the
Host
HTTP
request
header
X-Intermediary
Stamped
by
an
active
intermediary
that
changes
the
request
or
the
response
to
alter
it's
content
(see
below)
The
request
id
in
X-Request-Id
is
purely
to
help
connect
between
requests
and
logs/audit
trails.
The
client
can
assign
an
id
to
the
request,
and
send
that
in
the
X-Request-Id
header.
The
server
can
either
use
that
id
or
assign
it's
own,
which
it
returns
as
the
X-Request-Id
header
in
the
response.
When
the
server
assigned
id
is
different
to
the
client
assigned
id,
the
server
SHOULD
also
return
the
X-Correlation-Id
header
with
the
client's
original
id
in
it.
The
HTTP
protocol
may
be
routed
through
an
HTTP
proxy
(e.g.
as
squid).
Such
proxies
examples
are
transparent
to
the
applications,
though
implementers
should
be
alert
to
the
effects
of
caching,
particularly
including
the
risk
of
receiving
stale
content.
See
the
HTTP
specification
for
further
detail
Interface
engines
may
also
be
placed
between
the
consumer
correct
and
the
provider.
These
differ
from
proxies
because
useful,
but
they
actively
alter
the
content
and/or
destination
of
the
HTTP
exchange
and
are
not
bound
by
the
rules
that
apply
to
HTTP
proxies.
Such
agents
are
allowed,
but
SHALL
mark
the
request
with
an
X-Intermediary
header
to
assist
with
debugging/troubleshooting.
Any
agent
that
modifies
an
HTTP
request
or
response
content
other
than
under
the
rules
for
HTTP
proxies
SHALL
add
a
stamp
to
the
HTTP
headers
like
this:
X-Intermediary : [identity - usually a FQDN]
End
point
systems
SHALL
NOT
use
this
header
for
any
purpose.
Its
aim
is
to
assist
with
system
troubleshooting.
3.1.0.17
Summary
These
tables
present
a
summary
normative
part
of
the
interactions
described
here.
Note
that
all
requests
may
include
an
optional
Accept
header
to
indicate
the
format
used
for
the
response
(this
is
even
true
for
DELETE
since
an
OperationOutcome
may
be
returned).
Interaction
Path
Request
Verb
Content-Type
Body
Prefer
Conditional
read
/[type]/[id]
GET
N/A
N/A
N/A
O:
ETag
,
If-Modified-Since
,
If-None-Match
vread
/[type]/[id]/_history/[vid]
GET
N/A
N/A
N/A
N/A
update
/[type]/[id]
PUT
R
Resource
O
O:
If-Match
patch
/[type]/[id]
PATCH
R
(may
be
a
patch
type)
Patch
O
O:
If-Match
delete
/[type]/[id]
DELETE
N/A
N/A
N/A
N/A
create
/[type]
POST
R
Resource
O
O:
If-None-Exist
search
/[type]?
GET
N/A
N/A
N/A
N/A
/[type]/_search?
POST
application/x-www-form-urlencoded
form
data
N/A
N/A
search-all
?
GET
N/A
N/A
N/A
N/A
capabilities
/metadata
GET
N/A
N/A
N/A
N/A
transaction
/
POST
R
Bundle
O
N/A
history
/[type]/[id]/_history
GET
N/A
N/A
N/A
N/A
history-type
/[type]/_history
GET
N/A
N/A
N/A
N/A
history-all
/_history
GET
N/A
N/A
N/A
N/A
(operation)
/$[name]
,
/[type]/$[name]
or
/[type]/[id]/$[name]
POST
R
Parameters
N/A
N/A
GET
N/A
N/A
N/A
N/A
POST
application/x-www-form-urlencoded
form
data
N/A
N/A
Notes:
N/A
=
not
present,
R
=
Required,
O
=
optional
For
operations
defined
on
all
resources,
including
direct
access
to
the
meta
element,
see
Resource
Operations
Interaction
Response
Content-Type
Body
Location
Versioning
Status
Codes
read
R
R:
Resource
N/A
R:
ETag
,
Last-Modified
200
,
404
,
410
vread
R
R:
Resource
N/A
R:
ETag
,
Last-Modified
200
,
404
update
R
if
body
O:
Resource
(Prefer)
N/A
R:
ETag
,
Last-Modified
200
,
201
,
400
,
404
,
405
,
409
,
412
,
422
patch
R
if
body
O:
Resource
(Prefer)
N/A
R:
ETag
,
Last-Modified
200
,
201
,
400
,
404
,
405
,
409
,
412
,
422
delete
R
if
body
O:
OperationOutcome
N/A
N/A
200
,
202
,
204
,
404
,
405
,
409
,
412
create
R
if
body
O
:
Resource
(Prefer)
R
R:
ETag
,
Last-Modified
201
,
400
,
404
,
405
,
422
search
R
R:
Bundle
N/A
N/A
200
,
401
?
search-all
R
R:
Bundle
N/A
N/A
200
,
401
?
capabilities
R
R:
CapabilityStatement
N/A
N/A
200
,
404
transaction
R
R:
Bundle
N/A
N/A
200
,
400
,
404
,
405
,
409
,
412
,
422
history
R
R:
Bundle
N/A
N/A
200
history-type
R
R:
Bundle
N/A
N/A
200
history-all
R
R:
Bundle
N/A
N/A
200
(operation)
R
R:
Parameters/Resource
N/A
N/A
200
Note:
this
table
lists
the
status
codes
described
here,
but
other
status
codes
are
possible
as
described
by
the
HTTP
specification.
Additional
codes
that
are
likely
are
server
errors
and
various
codes
associated
with
authentication
protocols.
The
security
page
notes
several
security
related
issues
that
may
impact
which
codes
to
return.
®©
FHIR
®©
HL7.org
2011+.
FHIR
Release
4
(Technical
Correction
#1)
(v4.0.1)
R5
hl7.fhir.core#5.0.0-draft-final
generated
on
Fri,
Nov
Wed,
Mar
1,
2019
09:37+1100.
QA
Page
2023
23:05+1100.
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
Glossary
|
QA
|
Compare
to
R3
R4B
|
Compare
to
R5
Draft
|
|
Propose
a
change