6.1 List リソース

Home ＞ Infrastructure ＞ List [list]

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

The resource name as it appears in a RESTful URL is [root]/list/

There are 2 resources that provide for constructing collections of other resources:

• This List resource - enumerates a collection of resources that are in some list, and provides features for managing the list. The list resource references other resources
• 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

List resources are used in many places, including for allergies, medications, alerts, medical history, etc.

Alternate definitions: Schema/Schematron, Resource Profile

• 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)))

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

The final mode - a change 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 must 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 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.

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)

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.

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.