This page is part of the FHIR Specification (v0.0.82: DSTU 1). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

• Content
• Examples
• Formal Definitions
• Mappings
• Profiles

6.1 Resource List - Content

A set of information summarized from a list of other resources.

6.1.3 Resource Content

<List xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: extension, modifierExtension, language, text, and contained -->
 <identifier><!-- 0..* Identifier Business identifier --></identifier>
 <code><!-- 0..1 CodeableConcept What the purpose of this list is --></code>
 <subject><!-- 0..1 Resource(Patient|Group|Device|Location) 
     If all resources have the same subject --></subject>
 <source><!-- 0..1 Resource(Practitioner|Patient|Device) 
     Who and/or what defined the list contents --></source>
 <date value="[dateTime]"/><!-- 0..1 When the list was prepared -->
 <ordered value="[boolean]"/><!-- 0..1 Whether items in the list have a meaningful order -->
 <mode value="[code]"/><!-- 1..1 working | snapshot | changes -->
 <entry>  <!--  0..* Entries in the list -->
  <flag><!-- 0..* CodeableConcept Workflow information about this item --></flag>
  <deleted value="[boolean]"/><!--  0..1 If this item is actually marked as deleted -->
  <date value="[dateTime]"/><!-- 0..1 When item added to list -->
  <item><!-- 1..1 Resource(Any) Actual entry --></item>
 </entry>
 <emptyReason><!--  0..1 CodeableConcept Why list is empty --></emptyReason>
</List>

Alternate definitions: Schema/Schematron, Resource Profile

6.1.3.1 Terminology Bindings

6.1.3.2 Constraints

• Inv-1: A list can only have an emptyReason if it is empty (xpath: not(exists(f:emptyReason) and exists(f:entry)))
• Inv-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:item/f:deleted)))

6.1.4 List Mode & Item Deleted

There are several different kinds of uses for a List resource:

The final mode - a changes list, may include deleted items. A typical case is a medication list in a discharge summary, where the list includes items that have been both added and deleted. 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.5 Narrative Content

The narrative portion of the List resource should contain a summary of key properties of the items in the list, along with a human-readable summary of their flags (if present).

An HTML table is the recommended approach, though this is not required. There should be a representation in the narrative for each item in the list, and vice versa, along with clear use of visual hints (borders, lines, bullet marks, etc.) to ensure that human readers do not get confused about which flags belongs with which item on space-poor displays (e.g. to prevent wrapping from separating the flags from the items).

This means that the narrative content of the list will be limited to the version of the contained 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.6 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.7 Search Parameters

Search parameters for this resource. The standard parameters also apply. See Searching for more information about searching in REST, messaging, and services.