A
set
of
information
summarized
from
a
list
of
other
resources.
A set of information summarized from a list of other resources.
6.1.1
Scope
and
Usage
Scope and Usage The
List
resource
is
a
flat,
possibly
ordered,
collection
of
records.
List
resources
are
used
in
many
places,
including
allergies,
medications,
alerts,
family
history,
medical
history,
etc.
List
resources
can
be
used
to
support
patient-specific
clinical
lists
as
well
as
lists
that
manage
workflows
such
as
tracking
patients,
managing
teaching
cases,
etc.
Resources
supported
by
the
List
resource
can
be
homogenous
–
consisting
of
only
one
type
of
resource
(e.g.,
allergy
list);
as
well
as
heterogeneous
–
containing
a
variety
of
resources
(e.g.,
a
problem
list
including
Querying a List of resources such as AllergyIntolerance, Condition or Medication-related resources is different than querying the resource-specific end point. For example, a List of AllergyIntolerance would represent a curated point-in-time snapshot of the patient's allergies and intolerances. On the other hand, querying the AllergyIntolerance endpoint would typically produce a larger set of records as it would both be non-currated (potentially containing duplicate or out-of-date records) as well as current - generated based on information as of "now" rather than the last time a human manually revised the List resource instance. Which mechanism is most appropriate for data retrieval will vary by use-case. In some cases, systems may not have an appropriate currated List to query.
Note that the presence of an item in a List resource SHALL NOT change the meaning of any information that would be understood by looking at the item outside the context of the List, because items may be accessed directly outside the list by RESTful means, or after a document is processed. For example, a List with a code that means "refuted conditions" can not have items that are Condition resources that do not have a
Condition.clinicalStatus
of
of
refuted
.
.
6.1.2
Boundaries
and
Relationships
Boundaries and Relationships There
are
five
mechanisms
in
FHIR
for
communicating
collections
of
resources:
This
List
resource
-
enumerates
a
flat
collection
of
resources
and
provides
features
for
managing
the
collection.
While
a
particular
List
instance
may
represent
a
"snapshot",
from
a
business
process
perspective
the
notion
of
"List"
is
dynamic
–
items
are
added
and
removed
over
time.
The
list
resource
references
other
resources.
Lists
may
be
curated
and
have
specific
business
meaning.
The
There are five mechanisms in FHIR for communicating collections of resources:
This List resource - enumerates a flat collection of resources and provides features for managing the collection. While a particular List instance may represent a "snapshot", from a business process perspective the notion of "List" is dynamic – items are added and removed over time. The list resource references other resources. Lists may be curated and have specific business meaning.
The
DomainResource
.
contained
element
-
allows
multiple
resources
to
be
nested
inside
any
DomainResource.
This
is
a
special
type
of
grouping
where
the
grouped
resources
lose
independent
existence
-
they
no
longer
have
their
own
identifiers,
can't
easily
be
queried
independently,
etc.
Use
of
this
grouping
is
a
technical
mechanism
for
managing
the
independence
of
resources
and
has
no
impact
on
meaning.
Contained,
bundles
and
remotely
referenced
resources
convey
the
same
meaning.
element - allows multiple resources to be nested inside any DomainResource. This is a special type of grouping where the grouped resources lose independent existence - they no longer have their own identifiers, can't easily be queried independently, etc. Use of this grouping is a technical mechanism for managing the independence of resources and has no impact on meaning. Contained, bundles and remotely referenced resources convey the same meaning.
Information
summarized
from
a
list
of
other
resources
Information summarized from a list of other resources
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
The deleted flag can only be used if the mode of the list is "changes"
A
list
can
only
have
an
emptyReason
if
it
is
empty
A list can only have an emptyReason if it is empty
Information
summarized
from
a
list
of
other
resources
Information summarized from a list of other resources
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
The deleted flag can only be used if the mode of the list is "changes"
A
list
can
only
have
an
emptyReason
if
it
is
empty
A list can only have an emptyReason if it is empty
Codes
that
provide
further
information
about
the
reason
and
meaning
of
the
item
in
the
list
Codes that provide further information about the reason and meaning of the item in the list
lst-1
:
A
list
can
only
have
an
emptyReason
if
it
is
empty
(xpath:
not(exists(f:emptyReason)
and
exists(f:entry))
: A list can only have an emptyReason if it is empty (
expression
:
emptyReason.empty() or entry.empty()
)
lst-2
:
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
(xpath:
(f:mode/@value
=
'changes')
or
not(exists(f:entry/f:deleted))
: The deleted flag can only be used if the mode of the list is "changes" (
expression
:
mode = 'changes' or entry.deleted.empty()
)
6.1.4
List
Order
List Order All
lists
are
considered
ordered
-
the
order
in
which
items
literally
appear
in
the
list
may
be
an
important
part
of
the
meaning
of
the
list.
Reordering
the
items
in
a
list
may
change
the
meaning
of
the
list.
While
a
list
always
contains
an
ordered
set
of
items,
the
significance
of
the
order
may
be
unknown,
or
it
may
be
insignificant.
As
an
example,
consider
a
list
of
patients
for
a
practitioner
to
visit.
The
list
may
be
in
order,
where
the
patients
are
to
be
visited
in
the
stated
order,
or
just
an
unsorted
list
of
patients
to
be
visited
in
any
order.
The
list
resource
has
a
property
All lists are considered ordered - the order in which items literally appear in the list may be an important part of the meaning of the list. Reordering the items in a list may change the meaning of the list.
While a list always contains an ordered set of items, the significance of the order may be unknown, or it may be insignificant. As an example, consider a list of patients for a practitioner to visit. The list may be in order, where the patients are to be visited in the stated order, or just an unsorted list of patients to be visited in any order.
The list resource has a property
orderedBy
that,
if
present,
specifies
the
meaning
of
the
item
order.
Note,
though,
that
the
meaning
of
the
order
may
be
known
implicitly
rather
than
specified
in
the
that, if present, specifies the meaning of the item order. Note, though, that the meaning of the order may be known implicitly rather than specified in the
orderedBy
element.
Applications
SHOULD
NOT
reorder
the
elements
in
a
list
unless
they
understand
the
impact
of
this
on
the
meaning
of
the
list.
element.
Applications SHOULD NOT reorder the elements in a list unless they understand the impact of this on the meaning of the list.
6.1.5
List
Mode
&
Item
Deleted
List Mode & Item Deleted There
are
several
different
kinds
of
uses
for
a
List
resource:
There are several different kinds of uses for a List resource:
6.1.5.1
The
processing
mode
that
applies
to
this
list
The processing mode that applies to this list
working
This
list
is
the
master
list,
maintained
in
an
ongoing
fashion
with
regular
updates
as
the
real
world
list
it
is
tracking
changes
This list is the master list, maintained in an ongoing fashion with regular updates as the real world list it is tracking changes
snapshot
This
list
was
prepared
as
a
snapshot.
It
should
not
be
assumed
to
be
current
This list was prepared as a snapshot. It should not be assumed to be current
changes
A
list
that
indicates
where
changes
have
been
made
or
recommended
A list that indicates where changes have been made or recommended
The
most
common
mode
is
"snapshot"
-
a
list
that
is
accurate
within
the
context
it
is
used
in
but
not
current
or
maintained
after
that;
e.g.,
medications
on
discharge
in
a
discharge
summary.
Note
that
these
lists
usually
have
a
status
of
'current'
-
they
were
current
when
they
were
prepared.
Some
kinds
of
lists
may
be
explicitly
retired
(particularly
if
mode
=
working),
but
most
will
not
be
maintained
after
creation.
A
change
list
may
include
deleted
items.
Some
examples
of
change
lists
are
a
reconciled
list
of
allergies,
a
discharge
medication
list
and
a
list
with
new,
updated
and
deleted
items
in
it
-
though
these
may
not
be
lists
that
include
changes
(this
is
an
implementation
decision).
In
order
to
ensure
that
the
list
is
safe
to
process,
any
item
where
the
flag
implies
that
the
item
has
actually
been
deleted
SHALL
have
the
deleted
element
set
to
true.
Note
that
there
is
no
implication
about
the
status
of
a
resource
that
has
been
deleted.
The
only
statement
that
is
made
is
that
the
resource
has
been
dropped
from
the
list.
However
applications
should
ensure
that
the
implication
of
adding
or
deleting
items
from
the
list
is
consistent
with
the
logical
status
of
the
resource
and
its
contents.
A
proper
use
of
List.mode
=
"changes"
with
a
deleted
resource
is
in
a
medications
list
for
a
discharge
summary.
See
Example
"med-list".
An
improper
use
would
be
if
the
list
was
a
working
list
of
patient
medications
in
a
clinical
tracking
system,
and
list
item
flags
were
used
to
implement
version
tracking
history
within
the
resource.
The most common mode is "snapshot" - a list that is accurate within the context it is used in but not current or maintained after that; e.g., medications on discharge in a discharge summary. Note that these lists usually have a status of 'current' - they were current when they were prepared. Some kinds of lists may be explicitly retired (particularly if mode = working), but most will not be maintained after creation.
A change list may include deleted items. Some examples of change lists are a reconciled list of allergies, a discharge medication list and a list with new, updated and deleted items in it - though these may not be lists that include changes (this is an implementation decision). In order to ensure that the list is safe to process, any item where the flag implies that the item has actually been deleted SHALL have the deleted element set to true.
Note that there is no implication about the status of a resource that has been deleted. The only statement that is made is that the resource has been dropped from the list. However applications should ensure that the implication of adding or deleting items from the list is consistent with the logical status of the resource and its contents.
A proper use of List.mode = "changes" with a deleted resource is in a medications list for a discharge summary. See Example "med-list". An improper use would be if the list was a working list of patient medications in a clinical tracking system, and list item flags were used to implement version tracking history within the resource.
6.1.6
Narrative
Content
Narrative Content The
narrative
portion
of
the
List
resource
should
contain
a
summary
of
the
items
in
the
list,
their
key
information,
along
with
a
human-readable
summary
of
their
flags
(if
present).
The
narrative
may
be
generated
from
the
data
content
and/or
narrative
of
the
resources
referred
to
in
the
list,
or
it
may
be
a
narrative
written
by
a
human,
which
is
partially
or
completely
matched
by
structured
data
in
the
linked
resources.
The
human
written
narrative
may
be
the
only
content
if
the
list
has
no
entries
(which
would
equate
to
a
narrative
only
section
in
a
document).
An
HTML
table
is
the
recommended
approach,
though
this
is
not
required.
Each
List.item
should
appear
in
the
narrative
for
the
resource;
i.e.
it
SHALL
NOT
be
necessary
to
retrieve
the
list
items
in
order
to
have
a
human-readable
rendering
of
the
content.
In
addition,
if
the
List.text.status
is
"generated",
then
the
narrative
should
not
suggest
the
list
contains
items
for
which
there
are
no
corresponding
List.item
elements.
If
the
list
has
flags,
the
representation
should
make
clear
use
of
visual
hints
(borders,
lines,
bullet
marks,
etc.)
to
ensure
that
human
readers
do
not
get
confused
about
which
flags
belong
with
which
item
on
space-poor
displays
(e.g.
to
prevent
wrapping
from
separating
the
flags
from
the
items).
Note
that
when
a
List
resource
is
used
in
a
The narrative portion of the List resource should contain a summary of the items in the list, their key information, along with a human-readable summary of their flags (if present). The narrative may be generated from the data content and/or narrative of the resources referred to in the list, or it may be a narrative written by a human, which is partially or completely matched by structured data in the linked resources. The human written narrative may be the only content if the list has no entries (which would equate to a narrative only section in a document).
An HTML table is the recommended approach, though this is not required. Each List.item should appear in the narrative for the resource; i.e. it SHALL NOT be necessary to retrieve the list items in order to have a human-readable rendering of the content. In addition, if the List.text.status is "generated", then the narrative should not suggest the list contains items for which there are no corresponding List.item elements. If the list has flags, the representation should make clear use of visual hints (borders, lines, bullet marks, etc.) to ensure that human readers do not get confused about which flags belong with which item on space-poor displays (e.g. to prevent wrapping from separating the flags from the items).
In a dynamic environment, the narrative content of the list will be limited to the version of the linked resources at the time the list was last updated. It may be even earlier if the narrative isn't updated to reflect the most recent version of all referenced resources at each update. Best practice for 'working' lists is to update the narrative to reflect the most recent content of all list elements each time the list is revised. Lists should therefore not be relied on as a real-time view of the referenced content. There are a few possible approaches to work around this issue:
Provide minimal information about the listed resources, possibly limited to only a link. (Not recommended as this severely limits the usefulness of the narrative and is particularly problematic for things like documents where the only attested content might be the List narrative)
Include only "generated" narrative, so the retriever can easily generate their own "current" view of the list by retrieving the referenced resources, ignoring the fixed narrative.
The server hosting the list can subscribe to all referenced resources and auto-update the narrative each time one of the referenced resources changes (or at least on a semi-frequent basis)
6.1.7
Empty
Reason
Empty Reason If
the
list
is
empty,
there
could
be
several
different
reasons
why
this
is
so.
For
example:
There
are
no
appropriate
entries
for
the
list
(i.e.
the
patient
has
no
known
medications/allergies/history)
The
sender
(human
or
system)
deemed
that
these
were
not
related
to
this
context
of
patient
care
(usually
for
privacy
related
reasons)
The
source
system
doesn't
support
these
type
of
entries
The
information
to
populate
the
list
wasn't
gathered
-
i.e.
"Not
asked"
Given
these
possibilities,
and
the
common
and
significant
first
case,
source
systems
SHOULD
provide
an
empty
reason
if
the
list
is
empty.
Because
of
the
importance
of
this
case,
the
special
value
"nil-known"
should
be
used
when
there
are
no
(significant)
entries
in
this
context
of
care.
Note
that
this
concept
is
sometimes
described
differently,
such
as
"patient
denies
taking
medications",
or
"patient
was
unable
to
identify
any
relevant
medical
history".
When
receiving
a
list,
systems
should
not
assume
that
the
list
is
complete
(some
entries
may
have
been
withheld
for
a
variety
of
reasons),
unless
there
are
specific
trading
partner
arrangements
in
place
or,
if
the
list
is
empty,
that
there
are
actually
nil
known,
unless
the
"nil-known"
code
is
present.
If
the
list
is
empty,
the
narrative
should
contain
text
equivalent
to
the
empty
reason.
If the list is empty, there could be several different reasons why this is so. For example:
There are no appropriate entries for the list (i.e. the patient has no known medications/allergies/history)
The sender (human or system) deemed that these were not related to this context of patient care (usually for privacy related reasons)
The source system doesn't support these type of entries
The information to populate the list wasn't gathered - i.e. "Not asked"
Given these possibilities, and the common and significant first case, source systems SHOULD provide an empty reason if the list is empty. Because of the importance of this case, the
special value "nil-known"
should be used when there are no (significant) entries in this context of care. Note that this concept is sometimes described differently, such as "patient denies taking medications", or "patient was unable to identify any relevant medical history".
When receiving a list, systems should not assume that the list is complete (some entries may have been withheld for a variety of reasons), unless there are specific trading partner arrangements in place or, if the list is empty, that there are actually nil known, unless the "nil-known" code is present.
If the list is empty, the narrative should contain text equivalent to the empty reason.
6.1.8
Search
Parameters
Search Parameters Search
parameters
for
this
resource.
The
common
parameters
also
apply.
See
List
identifier
status
subject
entry
<!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <identifier><!-- 0..* Identifier Business identifier --></identifier> <status value="[code]"/><!-- 1..1 current | retired | entered-in-error --> <mode value="[code]"/><!-- 1..1 working | snapshot | changes --> <title value="[string]"/><!-- 0..1 Descriptive name for the list --> <code><!-- 0..1 CodeableConcept What the purpose of this list is --></code> <subject><!-- 0..1 Reference(Patient|Group|Device|Location) If all resources have the same subject --></subject>
0..* Entries in the list --> <flag><!-- 0..1 CodeableConcept Status/Workflow information about this item --></flag> <deleted value="[boolean]"/><!--
