Example
PractitionerRole/example
(JSON)
A
list
is
a
curated
collection
of
resources.
2.39.1
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
homogeneous
–
consisting
of
only
one
type
of
resource
(e.g.
allergy
lists)
as
well
as
heterogeneous
–
containing
a
variety
of
resources
(e.g.
a
problem
list
including
Conditions
,
AllergyIntolerances
,
recent
Procedures
,
etc.).
Lists
will
typically
include
references
to
the
resources
that
make
up
the
list,
however
in
some
cases
the
details
of
the
content
of
the
list
might
be
expressed
in
narrative
only;
e.g.
a
text
record
of
a
family
history.
The
List
resource
is
only
needed
if
there
is
a
need
to
filter
the
set
of
resources
by
a
mechanism
that
cannot
be
accomplished
via
a
simple
query;
e.g.
there
is
no
need
to
have
a
list
for
all
AllergyIntolerances
that
exist
on
a
server
for
a
given
patient.
However,
List
is
an
appropriate
mechanism
to
provide
a
filtered
list
of
the
subset
of
AllergyIntolerances
that
are
deemed
to
be
"current".
Lists
are
allowed
to
contain
other
Lists,
to
create
a
nested
collection
of
Lists.
Querying
a
List
of
resources
such
as
AllergyIntolerance,
Condition
or
Medication-related
resources
is
different
than
querying
the
resource-specific
endpoint.
For
example,
a
List
of
AllergyIntolerance
resources
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-curated
(potentially
containing
duplicate
or
out-of-date
records)
and
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
might
not
have
an
appropriate
curated
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"
cannot
have
items
that
are
Condition
resources
that
do
not
have
a
verificationStatus
of
refuted
.
2.39.2
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
Group
resource
-
defines
a
group
of
specific
people,
animals,
devices,
etc.
by
enumerating
them,
or
by
describing
qualities
that
group
members
have.
The
group
resource
refers
to
other
resources,
possibly
implicitly.
Groups
are
intended
to
be
acted
upon
or
observed
as
a
whole;
e.g.
performing
therapy
on
a
group,
calculating
risk
for
a
group,
etc.
This
resource
will
commonly
be
used
for
public
health
(e.g.
describing
an
at-risk
population),
clinical
trials
(e.g.
defining
a
test
subject
pool)
and
similar
purposes.
The
Composition
resource
-
defines
a
set
of
healthcare-related
information
that
is
assembled
together
into
a
single
logical
document
that
provides
a
single
coherent
statement
of
meaning,
establishes
its
own
context
and
that
has
clinical
attestation
with
regard
to
who
is
making
the
statement.
The
Composition
resource
provides
the
basic
structure
of
a
FHIR
document
.
The
full
content
of
the
document
is
expressed
using
a
bundle.
Compositions
will
often
reference
Lists
as
the
focus
of
particular
sections.
The
Bundle
resource
-
is
an
infrastructure
container
for
a
group
of
resources.
It
does
not
have
a
narrative
and
is
used
to
group
collections
of
resources
for
transmission,
persistence
or
processing
(e.g.
messages,
documents,
transactions,
query
responses,
etc.)
The
content
of
bundles
is
typically
algorithmically
determined
for
a
particular
exchange
or
persistence
purpose.
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,
bundled,
and
remotely
referenced
resources
convey
the
same
meaning.
This
resource
is
referenced
by
MeasureReport
2.39.3
Resource
Content
Structure
Name
Flags
Card.
Type
Description
&
Constraints
List
I
TU
DomainResource
A
list
is
a
curated
collection
of
resources
+
Rule:
A
list
can
only
have
an
emptyReason
if
it
is
empty
+
Rule:
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
+
Rule:
An
entry
date
can
only
be
used
if
the
mode
of
the
list
is
"working"
Elements
defined
in
Ancestors:
id
,
meta
,
implicitRules
,
language
,
text
,
contained
,
extension
,
modifierExtension
identifier
0..*
Identifier
Business
identifier
status
?!
Σ
1..1
code
current
|
retired
|
entered-in-error
ListStatus
(
Required
)
mode
?!
Σ
1..1
code
working
|
snapshot
|
changes
ListMode
(
Required
)
title
Σ
0..1
string
Descriptive
name
for
the
list
code
Σ
0..1
CodeableConcept
What
the
purpose
of
this
list
is
Example
Use
Codes
for
List
(
Example
)
subject
Σ
0..1
Reference
(
Patient
|
Group
|
Device
|
Location
)
If
all
resources
have
the
same
subject
encounter
0..1
Reference
(
Encounter
)
Context
in
which
list
created
date
Σ
0..1
dateTime
When
the
list
was
prepared
source
Σ
0..1
Reference
(
Practitioner
|
PractitionerRole
|
Patient
|
Device
)
Who
and/or
what
defined
the
list
contents
(aka
Author)
orderedBy
0..1
CodeableConcept
What
order
the
list
has
List
Order
Codes
(
Preferred
)
note
0..*
Annotation
Comments
about
the
list
entry
I
0..*
BackboneElement
Entries
in
the
list
flag
0..1
CodeableConcept
Status/Workflow
information
about
this
item
Patient
Medicine
Change
Types
(
Example
)
deleted
?!
I
0..1
boolean
If
this
item
is
actually
marked
as
deleted
date
0..1
dateTime
When
item
added
to
list
item
1..1
Reference
(
Any
)
Actual
entry
emptyReason
I
0..1
CodeableConcept
Why
list
is
empty
List
Empty
Reasons
(
Preferred
)
Documentation
for
this
format
UML
Diagram
(
Legend
)
List
(
DomainResource
)
Identifier
for
the
List
assigned
for
business
purposes
outside
the
context
of
FHIR
identifier
:
Identifier
[0..*]
Indicates
the
current
state
of
this
list
(this
element
modifies
the
meaning
of
other
elements)
status
:
code
[1..1]
«
The
current
state
of
the
list.
(Strength=Required)
ListStatus
!
»
How
this
list
was
prepared
-
whether
it
is
a
working
list
that
is
suitable
for
being
maintained
on
an
ongoing
basis,
or
if
it
represents
a
snapshot
of
a
list
of
items
from
another
source,
or
whether
it
is
a
prepared
list
where
items
may
be
marked
as
added,
modified
or
deleted
(this
element
modifies
the
meaning
of
other
elements)
mode
:
code
[1..1]
«
The
processing
mode
that
applies
to
this
list.
(Strength=Required)
ListMode
!
»
A
label
for
the
list
assigned
by
the
author
title
:
string
[0..1]
This
code
defines
the
purpose
of
the
list
-
why
it
was
created
code
:
CodeableConcept
[0..1]
«
What
the
purpose
of
a
list
is.
(Strength=Example)
ExampleUseCodesForList
??
»
The
common
subject
(or
patient)
of
the
resources
that
are
in
the
list
if
there
is
one
subject
:
Reference
[0..1]
«
Patient
|
Group
|
Device
|
Location
»
The
encounter
that
is
the
context
in
which
this
list
was
created
encounter
:
Reference
[0..1]
«
Encounter
»
The
date
that
the
list
was
prepared
date
:
dateTime
[0..1]
The
entity
responsible
for
deciding
what
the
contents
of
the
list
were.
Where
the
list
was
created
by
a
human,
this
is
the
same
as
the
author
of
the
list
source
:
Reference
[0..1]
«
Practitioner
|
PractitionerRole
|
Patient
|
Device
»
What
order
applies
to
the
items
in
the
list
orderedBy
:
CodeableConcept
[0..1]
«
What
order
applies
to
the
items
in
a
list.
(Strength=Preferred)
ListOrderCodes
?
»
Comments
that
apply
to
the
overall
list
note
:
Annotation
[0..*]
If
the
list
is
empty,
why
the
list
is
empty
emptyReason
:
CodeableConcept
[0..1]
«
If
a
list
is
empty,
why
it
is
empty.
(Strength=Preferred)
ListEmptyReasons
?
»
Entry
The
flag
allows
the
system
constructing
the
list
to
indicate
the
role
and
significance
of
the
item
in
the
list
flag
:
CodeableConcept
[0..1]
«
Codes
that
provide
further
information
about
the
reason
and
meaning
of
the
item
in
the
list.
(Strength=Example)
PatientMedicineChangeTypes
??
»
True
if
this
item
is
marked
as
deleted
in
the
list
(this
element
modifies
the
meaning
of
other
elements)
deleted
:
boolean
[0..1]
When
this
item
was
added
to
the
list
date
:
dateTime
[0..1]
A
reference
to
the
actual
resource
from
which
data
was
derived
item
:
Reference
[1..1]
«
Any
»
Entries
in
this
list
entry
[0..*]
XML
Template
<
<!-- from -->
<!-- from -->
<</identifier>
<
<
<
<</code>
<</subject>
<</encounter>
<
<</source>
<</orderedBy>
<</note>
<
<</flag>
<
<
<</item>
</entry>
<</emptyReason>
</List>
Raw
JSON
Template
{
"resourceType" : "",
// from
// from
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
}],
"
}
Turtle
Template
@prefix fhir: <http://hl7.org/fhir/> .
[ a fhir:;
fhir:nodeRole fhir:treeRoot; # if this is the parser root
# from
# from
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
], ...;
fhir:
]
Changes
since
R3
List
List.status
Change
value
set
from
http://hl7.org/fhir/ValueSet/list-status
to
http://hl7.org/fhir/ValueSet/list-status|4.0.1
List.mode
Change
value
set
from
http://hl7.org/fhir/ValueSet/list-mode
to
http://hl7.org/fhir/ValueSet/list-mode|4.0.1
List.source
Type
Reference:
Added
Target
Type
PractitionerRole
List.entry.deleted
Default
Value
"false"
removed
See
the
Full
Difference
for
further
information
This
analysis
is
available
as
XML
(
canonical
form
or
+
also
see
JSON
.
See
R3
<-->
R4
Conversion
Maps
Format
Specification
(status
=
9
tests
that
all
execute
ok.
All
tests
pass
round-trip
testing
and
5
r3
resources
are
invalid
(0
errors).
)
Structure
Name
Flags
Card.
Type
Description
&
Constraints
List
I
TU
DomainResource
A
list
is
a
curated
collection
of
resources
+
Rule:
A
list
can
only
have
an
emptyReason
if
it
is
empty
+
Rule:
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
+
Rule:
An
entry
date
can
only
be
used
if
the
mode
of
the
list
is
"working"
Elements
defined
in
Ancestors:
id
,
meta
,
implicitRules
,
language
,
text
,
contained
,
extension
,
modifierExtension
identifier
0..*
Identifier
Business
identifier
status
?!
Σ
1..1
code
current
|
retired
|
entered-in-error
ListStatus
(
Required
)
mode
?!
Σ
1..1
code
working
|
snapshot
|
changes
ListMode
(
Required
)
title
Σ
0..1
string
Descriptive
name
for
the
list
code
Σ
0..1
CodeableConcept
What
the
purpose
of
this
list
is
Example
Use
Codes
for
List
(
Example
)
subject
Σ
0..1
Reference
(
Patient
|
Group
|
Device
|
Location
)
If
all
resources
have
the
same
subject
encounter
0..1
Reference
(
Encounter
)
Context
in
which
list
created
date
Σ
0..1
dateTime
When
the
list
was
prepared
source
Σ
0..1
Reference
(
Practitioner
|
PractitionerRole
|
Patient
|
Device
)
Who
and/or
what
defined
the
list
contents
(aka
Author)
orderedBy
0..1
CodeableConcept
What
order
the
list
has
List
Order
Codes
(
Preferred
)
note
0..*
Annotation
Comments
about
the
list
entry
I
0..*
BackboneElement
Entries
in
the
list
flag
0..1
CodeableConcept
Status/Workflow
information
about
this
item
Patient
Medicine
Change
Types
(
Example
)
deleted
?!
I
0..1
boolean
If
this
item
is
actually
marked
as
deleted
date
0..1
dateTime
When
item
added
to
list
item
1..1
Reference
(
Any
)
Actual
entry
emptyReason
I
0..1
CodeableConcept
Why
list
is
empty
List
Empty
Reasons
(
Preferred
)
Documentation
for
this
format
UML
Diagram
(
Legend
)
List
(
DomainResource
)
Identifier
for
the
List
assigned
for
business
purposes
outside
the
context
of
FHIR
identifier
:
Identifier
[0..*]
Indicates
the
current
state
of
this
list
(this
element
modifies
the
meaning
of
other
elements)
status
:
code
[1..1]
«
The
current
state
of
the
list.
(Strength=Required)
ListStatus
!
»
How
this
list
was
prepared
-
whether
it
is
a
working
list
that
is
suitable
for
being
maintained
on
an
ongoing
basis,
or
if
it
represents
a
snapshot
of
a
list
of
items
from
another
source,
or
whether
it
is
a
prepared
list
where
items
may
be
marked
as
added,
modified
or
deleted
(this
element
modifies
the
meaning
of
other
elements)
mode
:
code
[1..1]
«
The
processing
mode
that
applies
to
this
list.
(Strength=Required)
ListMode
!
»
A
label
for
the
list
assigned
by
the
author
title
:
string
[0..1]
This
code
defines
the
purpose
of
the
list
-
why
it
was
created
code
:
CodeableConcept
[0..1]
«
What
the
purpose
of
a
list
is.
(Strength=Example)
ExampleUseCodesForList
??
»
The
common
subject
(or
patient)
of
the
resources
that
are
in
the
list
if
there
is
one
subject
:
Reference
[0..1]
«
Patient
|
Group
|
Device
|
Location
»
The
encounter
that
is
the
context
in
which
this
list
was
created
encounter
:
Reference
[0..1]
«
Encounter
»
The
date
that
the
list
was
prepared
date
:
dateTime
[0..1]
The
entity
responsible
for
deciding
what
the
contents
of
the
list
were.
Where
the
list
was
created
by
a
human,
this
is
the
same
as
the
author
of
the
list
source
:
Reference
[0..1]
«
Practitioner
|
PractitionerRole
|
Patient
|
Device
»
What
order
applies
to
the
items
in
the
list
orderedBy
:
CodeableConcept
[0..1]
«
What
order
applies
to
the
items
in
a
list.
(Strength=Preferred)
ListOrderCodes
?
»
Comments
that
apply
to
the
overall
list
note
:
Annotation
[0..*]
If
the
list
is
empty,
why
the
list
is
empty
emptyReason
:
CodeableConcept
[0..1]
«
If
a
list
is
empty,
why
it
is
empty.
(Strength=Preferred)
ListEmptyReasons
?
»
Entry
The
flag
allows
the
system
constructing
the
list
to
indicate
the
Dr
Adam
Careful's
role
and
significance
of
the
item
in
the
list
flag
:
CodeableConcept
[0..1]
«
Codes
that
provide
further
information
about
the
reason
and
meaning
of
the
item
in
the
list.
(Strength=Example)
PatientMedicineChangeTypes
??
»
True
if
this
item
is
marked
as
deleted
in
the
list
(this
element
modifies
the
meaning
of
other
elements)
deleted
:
boolean
[0..1]
When
this
item
was
added
to
the
list
date
:
dateTime
[0..1]
A
reference
to
at
the
actual
resource
from
which
data
was
derived
item
:
Reference
[1..1]
«
Any
»
Entries
in
this
list
entry
[0..*]
XML
Template
<
<!-- from -->
<!-- from -->
<</identifier>
<
<
<
<</code>
<</subject>
<</encounter>
<
<</source>
<</orderedBy>
<</note>
<
<</flag>
<
<
<</item>
</entry>
<</emptyReason>
</List>
JSON
Template
Acme
Hospital
{
"resourceType" : "",
// from
// from
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
"
{
"resourceType" : "PractitionerRole",
"id" : "example",
"text" : {
"status" : "generated",
"div" : "<div xmlns=\"http://www.w3.org/1999/xhtml\">\n\t\t\t<p>\n\t\t\t\tDr Adam Careful is a Referring Practitioner for Acme Hospital from 1-Jan 2012 to 31-Mar\n\t\t\t\t2012\n\t\t\t</p>\n\t\t</div>"
},
"identifier" : [{
"system" : "http://www.acme.org/practitioners",
"value" : "23"
}],
"
"active" : true,
"period" : {
"start" : "2012-01-01",
"end" : "2012-03-31"
},
"practitioner" : {
"reference" : "Practitioner/example",
"display" : "Dr Adam Careful"
},
"organization" : {
"reference" : "Organization/f001"
},
"code" : [{
"coding" : [{
"system" : "http://terminology.hl7.org/CodeSystem/v2-0286",
"code" : "RP"
}]
}],
"specialty" : [{
"coding" : [{
"system" : "http://snomed.info/sct",
"code" : "408443003",
"display" : "General medical practice"
}]
}],
"location" : [{
"reference" : "Location/1",
"display" : "South Wing, second floor"
}],
"healthcareService" : [{
"reference" : "HealthcareService/example"
}],
"contact" : [{
"telecom" : [{
"system" : "phone",
"value" : "(03) 5555 6473",
"use" : "work"
},
{
"system" : "email",
"value" : "adam.southern@example.org",
"use" : "work"
}]
}],
"availability" : [{
"availableTime" : [{
"daysOfWeek" : ["mon",
"tue",
"wed"],
"availableStartTime" : "09:00:00",
"availableEndTime" : "16:30:00"
},
{
"daysOfWeek" : ["thu",
"fri"],
"availableStartTime" : "09:00:00",
"availableEndTime" : "12:00:00"
}],
"notAvailableTime" : [{
"description" : "Adam will be on extended leave during May 2017",
"during" : {
"start" : "2017-05-01",
"end" : "2017-05-20"
}
},
{
"description" : "Adam is generally unavailable on public holidays and during the Christmas/New Year break"
}]
}],
"endpoint" : [{
"reference" : "Endpoint/example"
}]
}
Turtle
Template
@prefix fhir: <http://hl7.org/fhir/> .
[ a fhir:;
fhir:nodeRole fhir:treeRoot; # if this is the parser root
# from
# from
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
fhir:
], ...;
fhir:
]
Changes
since
Release
3
List
List.status
Change
value
set
from
http://hl7.org/fhir/ValueSet/list-status
to
http://hl7.org/fhir/ValueSet/list-status|4.0.1
List.mode
Change
value
set
from
http://hl7.org/fhir/ValueSet/list-mode
to
http://hl7.org/fhir/ValueSet/list-mode|4.0.1
List.source
Type
Reference:
Added
Target
Type
PractitionerRole
List.entry.deleted
Default
Value
"false"
removed
See
the
Full
Difference
for
further
information
This
analysis
is
available
as
XML
or
JSON
.
See
R3
<-->
R4
Conversion
Maps
(status
=
9
tests
that
all
execute
ok.
All
tests
pass
round-trip
testing
and
5
r3
resources
are
invalid
(0
errors).
)
See
the
Profiles
&
Extensions
and
the
alternate
definitions:
Master
Definition
XML
+
JSON
,
XML
Schema
/
Schematron
+
JSON
Schema
,
ShEx
(for
Turtle
)
+
see
the
extensions
&
the
dependency
analysis
2.39.3.1
Terminology
Bindings
Path
Definition
Type
Reference
List.status
The
current
state
of
the
list.
Required
ListStatus
List.mode
The
processing
mode
that
applies
to
this
list.
Required
ListMode
List.code
What
the
purpose
of
a
list
is.
Example
ExampleUseCodesForList
List.orderedBy
What
order
applies
to
the
items
in
a
list.
Preferred
ListOrderCodes
List.entry.flag
Codes
that
provide
further
information
about
the
reason
and
meaning
of
the
item
in
the
list.
Example
PatientMedicineChangeTypes
List.emptyReason
If
a
list
is
empty,
why
it
is
empty.
Preferred
ListEmptyReasons
2.39.3.2
Constraints
id
Level
Location
Description
Expression
lst-1
Rule
(base)
A
list
can
only
have
an
emptyReason
if
it
is
empty
emptyReason.empty()
or
entry.empty()
lst-2
Rule
(base)
The
deleted
flag
can
only
be
used
if
the
mode
of
the
list
is
"changes"
mode
=
'changes'
or
entry.deleted.empty()
lst-3
Rule
(base)
An
entry
date
can
only
be
used
if
the
mode
of
the
list
is
"working"
mode
=
'working'
or
entry.date.empty()
2.39.4
Querying
Lists
vs.
the
underlying
resources
When
a
client
system
is
interested
in
a
patient's
medications,
allergies,
problems,
family
history
or
other
information
typically
handled
via
List
,
they
have
three
options:
They
can
query
for
List
instances
of
the
appropriate
type;
or
They
can
query
against
the
resource
endpoint
for
the
resources
that
make
up
the
list
(e.g.
AllergyIntolerance
,
Condition
MedicationStatement
,
etc.),
possibly
filtering
by
time,
etc.
They
can
query
against
the
resource
endpoint,
requesting
one
of
the
Current
resource
lists
Querying
directly
against
the
clinical
resource
endpoints
will
provide
an
un-curated
view
of
information.
A
server
may
contain
records
that
were
part
of
various
clinical
documents,
referrals
and
other
submission
sources
that
might
not
necessarily
be
considered
wholly
accurate
or
current,
but
which
must
be
retained
"as
is"
to
provide
a
record
of
what
data
was
received
or
seen
by
a
clinician
at
a
particular
point
in
time.
On
the
other
hand,
lists
are
almost
always
curated.
They
will
include
only
those
records
deemed
by
the
author
of
the
list
to
be
both
current
and
accurate.
This
can
be
both
an
advantage
and
a
disadvantage.
Lists
are
less
likely
to
include
irrelevant
content,
but
there's
a
risk
that
they
won't
be
completely
up-to-date
(new
content
may
have
been
added
that's
more
recent
than
when
a
given
list
was
last
updated).
It's
also
possible
that
the
list
author's
notion
of
"current"
or
"relevant"
may
differ
from
the
perspective
of
the
user
performing
the
query.
Also,
there's
the
challenge
that
multiple
lists
may
exist,
with
different
author
and
different
perspectives
The
Current
resource
lists
get
around
the
problem
of
multiple
lists
and
make
it
clear
which
list
is
considered
authoritative,
but
not
all
systems
will
necessarily
support
this
capability,
and
there's
still
the
possibility
that
the
list
won't
be
completely
up-to-date
or
will
exclude
information
that
is
of
interest
to
the
querying
system.
There's
no
right
and
wrong
way
to
retrieve
allergy,
medication
and
other
such
information.
Sometimes
retrieving
the
"current"
medication
list
will
provide
the
best
results,
sometimes
querying
the
raw
records
will
provide
better
results.
Sometimes
providing
the
contents
of
the
list
plus
a
filtered
view
of
the
raw
records
may
give
the
most
useful
information.
Determining
the
most
appropriate
approach
will
depend
on
the
needs
of
the
user
as
well
as
the
types
of
data
sources
for
information
held
on
the
server
and
patterns
of
list
maintenance.
Client
systems
may
well
need
to
adapt
their
behavior
in
different
environments
if
they
can't
count
on
consistent
server
behavior.
2.39.5
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
the
order
in
which
the
patients
are
to
be
visited,
or
it
may
be
an
unsorted
list
of
patients
to
be
visited
in
any
order.
The
List
resource
has
an
orderedBy
element
that,
if
present,
specifies
the
meaning
of
the
item
order.
Note,
however,
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.
2.39.6
List
Mode
&
Item
Deleted
There
are
several
different
kinds
of
uses
for
a
List
resource:
2.39.6.1
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.
snapshot
This
list
was
prepared
as
a
snapshot.
It
should
not
be
assumed
to
be
current.
changes
A
point-in-time
list
that
shows
what
changes
have
been
made
or
recommended.
E.g.
a
discharge
medication
list
showing
what
was
added
and
removed
during
an
encounter.
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
might
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
Usage
note:
every
effort
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
section
of
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.
2.39.7
Efficiency
and
size
issues
Some
kinds
of
List
resources
may
grow
to
a
considerable
size,
and
handling
them
may
require
more
care
than
typical
resources.
Some
approaches
to
consider
include:
Reading
portions
of
the
list
resource
using
GraphQL
Using
the
_list
parameter
rather
than
retrieving
the
list
Changing
the
resource
using
the
PATCH
interaction
rather
than
PUTting
the
whole
resource
2.39.8
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
Document
,
the
narrative
of
the
list
is
part
of
the
attested
content
of
the
document.
In
a
dynamic
environment,
the
narrative
content
of
a
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).
2.39.9
Empty
Reason
If
a
list
is
empty,
there
could
be
several
different
reasons
why
this
is
so.
For
example:
There
examples
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
types
of
entries
The
information
to
populate
the
list
wasn't
gathered
-
i.e.
"Not
asked"
Given
these
possibilities
-
especially
the
common
correct
and
significant
first
case
-
for
many
kinds
of
lists,
source
systems
SHOULD
provide
an
empty
reason
if
the
list
is
empty.
Because
of
the
importance
of
the
first
case,
the
special
value
"nil-known"
should
be
used
when
there
useful,
but
they
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
normative
part
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
a
list
is
empty,
the
narrative
should
contain
text
equivalent
to
the
empty
reason.
Note
that
there
are
also
many
kinds
of
lists
that
can
be
empty
with
no
need
for
an
empty
reason
(
example
)
2.39.10
Search
Parameters
Search
parameters
for
this
resource.
The
common
parameters
also
apply.
See
Searching
for
more
information
about
searching
in
REST,
messaging,
and
services.
specification.
Name
Type
Description
Expression
In
Common
code
token
What
the
purpose
of
this
list
is
List.code
13
Resources
date
date
When
the
list
was
prepared
List.date
17
Resources
empty-reason
token
Why
list
is
empty
List.emptyReason
encounter
reference
Context
in
which
list
created
List.encounter
(
Encounter
)
12
Resources
identifier
token
Business
identifier
List.identifier
30
Resources
item
reference
Actual
entry
List.entry.item
(Any)
notes
string
The
annotation
-
text
content
(as
markdown)
List.note.text
patient
reference
If
all
resources
have
the
same
subject
List.subject.where(resolve()
is
Patient)
(
Patient
)
33
Resources
source
reference
Who
and/or
what
defined
the
list
contents
(aka
Author)
List.source
(
Practitioner
,
Device
,
Patient
,
PractitionerRole
)
status
token
current
|
retired
|
entered-in-error
List.status
subject
reference
If
all
resources
have
the
same
subject
List.subject
(
Group
,
Device
,
Patient
,
Location
)
title
string
Descriptive
name
for
the
list
List.title
Administration
|
Propose
a
change