The purpose of this identifier.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

Identifies the purpose for this identifier, if known .

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

Allows users to make use of identifiers when the identifier system is not known.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

A coded type for an identifier that can be used to determine which identifier to use for a specific purpose.

Time period during which identifier is/was valid for use.

A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times").

Period is not used for a duration (a measure of elapsed time). See Duration.

Organization that issued/manages the identifier.

The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured, and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

Who or what the composition is about. The composition can be about a person, (patient or healthcare practitioner), a device (e.g. a machine) or even a group of subjects (such as a document about a herd of livestock, or a set of patients that share a common exposure).

Essential metadata for searching for the composition. Identifies who and/or what the composition/document is about.

For clinical documents, this is usually the patient.

Describes the clinical encounter or type of care this documentation is associated with.

Provides context for the composition and supports searching.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent.

The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources).

This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified.

Aa resource (or, for logical models, the URI of the logical model).

An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.

When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy.

When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference

Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.

Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any).

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.

The type of relationship that this composition has with anther composition or document.

If this document appends another document, then the document cannot be fully understood without also accessing the referenced document.

The type of relationship between documents.

The label for this particular section. This will be part of the rendered content for the document, and is often used to build a table of contents.

Section headings are often standardized for different types of documents. They give guidance to humans on how the document is organized.

The title identifies the section for a human reader. The title must be consistent with the narrative of the resource that is the target of the section.content reference. Generally, sections SHOULD have titles, but in some documents, it is unnecessary or inappropriate. Typically, this is where a section has subsections that have their own adequately distinguishing title, or documents that only have a single section. Most Implementation Guides will make section title to be a required element.

A code identifying the kind of content contained within the section. This must be consistent with the section title.

Provides computable standardized labels to topics within the document.

The code identifies the section for an automated processor of the document. This is particularly relevant when using profiles to control the structure of the document.

If the section has content (instead of sub-sections), the section.code does not change the meaning or interpretation of the resource that is the content of the section in the comments for the section.code.

Classification of a section of a composition/document.

Identifies who is responsible for the information in this section, not necessarily who typed it in.

Identifies who is responsible for the content.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

The actual focus of the section when it is not the subject of the composition, but instead represents something or someone associated with the subject such as (for a patient subject) a spouse, parent, fetus, or donor. If not focus is specified, the focus is assumed to be focus of the parent section, or, for a section in the Composition itself, the subject of the composition. Sections with a focus SHALL only include resources where the logical subject (patient, subject, focus, etc.) matches the section focus, or the resources have no logical subject (few resources).

Typically, sections in a doument are about the subject of the document, whether that is a patient, or group of patients, location, or device, or whatever. For some kind of documents, some sections actually contain data about related entities. Typical examples are a section in a newborn discharge summary concerning the mother, or family history documents, with a section about each family member, though there are many other examples.

A human-readable narrative that contains the attested content of the section, used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.

Document profiles may define what content should be represented in the narrative to ensure clinical safety.

How the entry 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.

Sections are used in various ways, and it must be known in what way it is safe to use the entries in them.

This element is labeled as a modifier because a change list must not be misunderstood as a complete list.

The processing mode that applies to this section.

Specifies the order applied to the items in the section entries.

Important for presentation and rendering. Lists may be sorted to place more important information first or to group related entries.

Applications SHOULD render ordered lists in the order provided, but MAY allow users to re-order based on their own preferences as well. If there is no order specified, the order is unknown, though there may still be some order.

What order applies to the items in the entry.

A reference to the actual resource from which the narrative in the section is derived.

If there are no entries in the list, an emptyReason SHOULD be provided.

If the section is empty, why the list is empty. An empty section typically has some text explaining the empty reason.

Allows capturing things like "none exist" or "not asked" which can be important for most lists.

The various reasons for an empty section make a significant interpretation to its interpretation. Note that this code is for use when the entire section content has been suppressed, and not for when individual items are omitted - implementers may consider using a text note or a flag on an entry in these cases.

If a section is empty, why it is empty.

A nested sub-section within this section.

Nested sections are primarily used to help human readers navigate to particular portions of the document.