This page is part of the FHIR Specification (v1.4.0:
STU
3 Ballot 3). The current version which supercedes this version is
5.0.0
.
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
. For a full list of available versions, see the
Directory of published versions
.
Page
versions:
. Page versions:
R5
R4B
R4
R3
R2
This is the narrative for the resource. See also the
XML
or
or
JSON
format.
format.
OPERATION:
Fetch
Encounter
Record
OPERATION: Fetch Encounter Record
This
operation
is
used
to
return
all
the
information
related
to
an
encounter
described
in
the
resource
on
which
this
operation
is
invoked.
The
response
is
a
bundle
of
type
"searchset".
At
a
minimum,
the
encounter
resource
itself
is
returned,
along
with
any
other
resources
that
the
server
has
available
for
the
given
encounter
for
the
user.
The
server
also
returns
whatever
resources
are
needed
to
support
the
records
-
e.g.
linked
practitioners,
locations,
organizations
etc.
The
principle
intended
use
for
this
operation
is
to
provide
a
patient
with
access
to
their
record,
or
to
allow
a
client
to
retrieve
everything
for
an
encounter
for
efficient
display).
The
server
SHOULD
return
all
resources
that
it
has
that
are
in
the
encounter
compartment
for
the
identified
encounter,
and
any
resource
referenced
from
those,
including
binaries
and
attachments.
In
the
US
Realm,
at
a
mimimum,
the
resources
returned
SHALL
include
all
the
data
covered
by
the
meaningful
use
common
data
elements
(see
This operation is used to return all the information related to an encounter described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the encounter resource itself is returned, along with any other resources that the server has available for the given encounter for the user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their record, or to allow a client to retrieve everything for an encounter for efficient display). The server SHOULD return all resources that it has that are in the encounter compartment for the identified encounter, and any resource referenced from those, including binaries and attachments. In the US Realm, at a mimimum, the resources returned SHALL include all the data covered by the meaningful use common data elements (see
DAF
for
further
guidance).
Other
applicable
implementation
guides
may
make
additional
rules
about
the
information
that
is
returned.
Note
that
for
many
resources,
the
exact
nature
of
the
link
to
encounter
can
be
ambiguous
(e.g.
for
a
DiagnosticReport,
is
it
the
encounter
when
it
was
initiated,
or
when
it
was
reported?)
for further guidance). Other applicable implementation guides may make additional rules about the information that is returned. Note that for many resources, the exact nature of the link to encounter can be ambiguous (e.g. for a DiagnosticReport, is it the encounter when it was initiated, or when it was reported?)
Parameters
| Use | Name | Cardinality | Type | Binding | Documentation |
| OUT | return | 1..1 | Bundle |
|
The
key
differences
between
this
operation
and
simply
searching
the
encounter
compartment
are:
*
unless
the
client
requests
otherwise,
the
server
returns
the
entire
result
set
in
a
single
bundle
(rather
than
using
paging)
*
the
server
is
responsible
for
determining
what
resources
to
return
as
included
resources
(rather
than
the
client
specifying
which
ones)
The key differences between this operation and simply searching the encounter compartment are: * unless the client requests otherwise, the server returns the entire result set in a single bundle (rather than using paging) * the server is responsible for determining what resources to return as included resources (rather than the client specifying which ones)
Usage note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of the specification.