This
page
is
part
of
the
FHIR
Specification
(v4.3.0:
R4B
(v5.0.0:
R5
-
STU
).
The
This
is
the
current
published
version
which
supercedes
in
it's
permanent
home
(it
will
always
be
available
at
this
version
is
5.0.0
.
URL).
For
a
full
list
of
available
versions,
see
the
Directory
of
published
versions
.
Page
versions:
R5
R4B
R5
R4B
R4
R3
| Orders and Observations Work Group | Maturity Level : N/A | Standards Status : Informative | Compartments : Device , Encounter , Patient , Practitioner , RelatedPerson |
This is the narrative for the resource. See also the XML , JSON or Turtle format.
Note
that
this
operation
definition
is:
http://hl7.org/fhir/OperationDefinition/Observation-lastn
The
lastn
query
meets
the
common
need
for
searching
for
the
most
recent
or
last
n=number
of
observations
for
a
subject.
For
example,
retrieving
is
the
last
5
temperatures
formal
definition
for
a
patient
to
view
trends
or
fetching
the
most
recent
laboratory
results
or
vitals
signs.
To
ask
a
server
to
return
the
last
n=number
of
observations,
the
lastn
query
uses
the
normal
search
parameters
defined
for
the
Observation
resource.
However,
rather
than
their
normal
use,
they
are
interpreted
as
inputs
-
i.e..
instead
of
requiring
that
the
resources
literally
contain
the
search
parameters,
they
are
passed
to
a
server
algorithm
of
some
kind
that
uses
them
to
determine
the
most
appropriate
matches.
The
request
for
a
lastn
query
SHALL
include:
A
$lastn
operation
parameter
A
subject
using
either
the
patient
or
subject
search
parameter
A
category
parameter
and/or
a
search
parameter
that
contains
a
code
element
in
its
FHIRpath
expression.
(
e.g.,
code
or
code-value-concept
)
The
request
for
a
lastn
query
MAY
include:
Other
Observation
search
parameters
and
modifiers
The
response
from
a
lastn
query
is
a
set
of
observations:
Filtered
by
additional
parameters
If
not
explicitly
filtered
by
status
then
will
include
statuses
of
'entered-in-error'
'GROUP
BY'
Observation.code
Codes
SHALL
be
considered
equivalent
if
the
coding.value
and
coding.system
are
the
same.
Text
only
codes
SHALL
be
treated
and
grouped
based
as
an
OperationDefinition
on
Observation.
See
the
text.
For
codes
with
translations
(multiple
codings),
the
code
translations
are
assumed
to
be
equal
and
the
grouping
by
code
SHALL
follow
the
transitive
property
of
equality.
for
example:
Observation.code
for
observation
a
Observation.code
for
observation
b
Observation.code
for
observation
c
number
of
groups
[codes/text
in
each
group]
a
b
c
3
[a],[b],[c]
a
b
a,c
2
[a.c],[b]
a
b
a,b
1
[a,b]
'textM'
'Text'
't
e
x
t'
3
['text'],['Text'],['t
e
x
t']
Operation
documentation
Sorted
from
most
recent
to
the
oldest
Limited
to
the
number
of
requested
responses
per
group
specified
by
the
optional
max
query
parameter
In
case
of
a
tie
-
when
the
effective
times
for
>1
Observations
are
equal
-
both
will
be
returned.
Therefore,
more
Observations
may
be
returned
than
is
specified
in
max
.
For
example,
4
Observations
instead
of
3
if
the
3rd
and
4th
most
recent
observation
had
the
same
effective
time.
If
no
maximum
number
is
given
then
only
the
most
recent
Observation
in
each
group
is
returned.
The
set
of
returned
observations
should
represent
distinct
real
world
observations
and
not
the
same
observation
with
changes
in
status
or
versions.
If
there
are
no
matches,
the
lastn
query
SHALL
return
an
empty
search
set
with
no
error,
but
may
include
an
operation
outcome
with
further
advice.
URL: [base]/Observation/$lastn
Parameters
| Use | Name | Scope | Cardinality | Type | Binding | Documentation |
| IN | max | 0..1 | positiveInt |
|
||
| OUT | return | 1..1 | Bundle |
The set of most recent N Observations that match the lastn query search criteria. |
The
key
differences
between
this
query
operation
and
simply
searching
Observation
using
the
combination
of
_count
and
_sort
parameters
are:
This operation cannot be performed on observations that the user is not authorized to see. 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.