This page is part of the FHIR Specification (v1.6.0:
STU
3 Ballot 4). 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
Patient
Record
OPERATION: Fetch Patient Record
This
operation
is
used
to
return
all
the
information
related
to
the
patient
described
in
the
resource
on
which
this
operation
is
invoked.
The
response
is
a
bundle
of
type
"searchset".
At
a
minimum,
the
patient
resource
itself
is
returned,
along
with
any
other
resources
that
the
server
has
that
are
related
to
the
patient,
and
that
are
available
for
the
given
user.
The
server
also
returns
whatever
resources
are
needed
to
support
the
records
-
e.g.
linked
practitioners,
medications,
locations,
organizations
etc.
The
principle
intended
use
for
this
operation
is
to
provide
a
patient
with
access
to
their
entire
record
(e.g.
"Blue
Button").
The
server
SHOULD
return
at
least
all
resources
that
it
has
that
are
in
the
patient
compartment
for
the
identified
patient,
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
as
defined
in
This operation is used to return all the information related to the patient described in the resource on which this operation is invoked. The response is a bundle of type "searchset". At a minimum, the patient resource itself is returned, along with any other resources that the server has that are related to the patient, and that are available for the given user. The server also returns whatever resources are needed to support the records - e.g. linked practitioners, medications, locations, organizations etc. The principle intended use for this operation is to provide a patient with access to their entire record (e.g. "Blue Button"). The server SHOULD return at least all resources that it has that are in the patient compartment for the identified patient, 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 as defined in
DAF
.
Other
applicable
implementation
guides
may
make
additional
rules
about
how
much
information
that
is
returned
. Other applicable implementation guides may make additional rules about how much information that is returned
URL:
[base]/Patient/$everything
URL: [base]/Patient/$everything
URL:
[base]/Patient/[id]/$everything
URL: [base]/Patient/[id]/$everything
Parameters
| Use | Name | Cardinality | Type | Binding | Documentation |
| IN | start | 0..1 | date |
|
|
| IN | end | 0..1 | date |
|
|
| OUT | return | 1..1 | Bundle |
|
The
key
differences
between
this
operation
and
simply
searching
the
patient
compartment
are:
The key differences between this operation and simply searching the patient 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).
This
frees
the
client
from
needing
to
determine
what
it
could
or
should
ask
for
It
is
assumed
that
the
server
has
identified
and
secured
the
context
appropriately,
and
can
either
associate
the
authorization
context
with
a
single
patient,
or
determine
whether
the
context
has
the
rights
to
the
nominated
patient,
if
there
is
one.
If
there
is
no
nominated
patient
(e.g.
the
operation
is
invoked
at
the
system
level)
and
the
context
is
not
associated
with
a
single
patient
record,
then
the
server
should
return
an
error.
Specifying
the
relationship
between
the
context,
a
user
and
patient
records
is
outside
the
scope
of
this
specification.
It is assumed that the server has identified and secured the context appropriately, and can either associate the authorization context with a single patient, or determine whether the context has the rights to the nominated patient, if there is one. If there is no nominated patient (e.g. the operation is invoked at the system level) and the context is not associated with a single patient record, then the server should return an error. Specifying the relationship between the context, a user and patient records is outside the scope of this specification.
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.