---
type: "resource"
title: "profile-catalog"
resource: "profile-catalog"
---
# profile-catalog


## Introduction


## Scope and Usage

A Composition is the basic structure from which [FHIR Documents](documents) - immutable bundles with attested narrative - are built. A single logical composition may be associated with a series of derived documents, each of which is a frozen copy of the composition.

Note: [EN 13606](http://en.wikipedia.org/wiki/EN_13606) uses the term "Composition" to refer to a single commit to an EHR system, and offers some common examples: a composition containing a consultation note, a progress note, a report or a letter, an investigation report, a prescription form or a set of bedside nursing observations. Using Composition for an attested EHR commit is a valid use of the Composition resource, but for FHIR purposes, it would be usual to make more granular updates with individual provenance statements.

The [Clinical Document profile](composition-core) constrains Composition to specify a clinical document (matching [CDA](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7)). See also the [comparison with CDA](comparison-cda).

## Boundaries and Relationships

Composition is a structure for grouping information for purposes of persistence and attestability. 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](documents). The full content of the document is expressed using a [Bundle](bundle) containing the Composition and its entries.

There are several other grouping structures in FHIR with distinct purposes:

-   The [List](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](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 [Bundle](bundle) resource - is an infrastructure container for a group of resources. It does not have 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 [QuestionnaireResponse](questionnaireresponse) resource - is similar to Composition in that both organize collections of items and can have a hierarchical structure. [Questionnaires](questionnaire) are also intended to help guide 'human' presentation of data. However, Compositions organize resources, while Questionnaires/QuestionnaireResponses organize specific elements. Also, a Questionnaire represents data 'to be gathered' and is subject-independent, while Compositions represent collections of data that are complete and are about a particular subject. It is possible for [StructureDefinitions](structuredefinition) or [GraphDefinitions](http://build.fhir.org/HL7/api-incubator/StructureDefinition-GraphDefinition) to act as 'templates' for FHIR documents that guide what data is collected for a particular purpose (e.g. a referral), but this differs from the gathering process that a Questionnaire provides where there are specific questions that must be asked and answered and rules that guide which questions are enabled in which circumstances.

The Composition resource organizes clinical and administrative content into sections, each of which contains a narrative, and references other resources for supporting data. The narrative content of the various sections in a Composition are supported by the resources referenced in the section entries. The complete set of content to make up a document includes the Composition resource together with various resources pointed to or indirectly connected to the Composition. See the [FHIR Documents](documents) documentation for guidance on how a Composition is used when creating a document bundle.

## Background and Context

### Composition Status Codes

Every composition has a status element, which describes the status of the content of the composition, taken from this list of codes:

<%codelist http://hl7.org/fhir/composition-status%>

Composition status generally only moves down through this list - it moves from `registered` or `preliminary` to `final` and then it may progress to `amended`. Note that in many workflows, only `final` compositions are made available and the `preliminary` status is not used.

![Diagram showing typical transitions of clinical status for the Composition resource](composition-state-machine.png)

A very few compositions are created entirely in error in the workflow - usually the composition concerns the wrong patient or is written by the wrong author, and the error is only detected after the composition has been used or documents have been derived from it. To support resolution of this case, the composition is updated to be marked as `entered-in-error` and a new derived document can be created. This means that the entire series of derived documents is now considered to be created in error and systems receiving derived documents based on retracted compositions SHOULD remove data taken from earlier documents from routine use and/or take other appropriate actions. Systems are not required to provide this workflow or support documents derived from retracted compositions, but they SHALL NOT ignore a status of `entered-in-error`. Note that systems that handle compositions or derived documents and don't support the error status need to define some other way of handling compositions that are created in error; while this is not a common occurrence, some clinical systems have no provision for removing erroneous information from a patient's record, and there is no way for a user to know that it is not fit for use - this is not safe.

### Note for CDA aware readers

Many users of this specification are familiar with the [Clinical Document Architecture](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7) (CDA) and related specifications. CDA is a primary design input to the Composition resource (other principal inputs are other HL7 document specifications and EN13606). There are three important structural differences between CDA and the Composition resource:

-   A composition is a logical construct - its `identifier` matches to the CDA `ClinicalDocument.setId`. Composition resources are wrapped into [Document](documents) structures, for exchange of the whole package (the composition and its parts), and this wrapped, sealed entity is equivalent to a CDA document, where the where the `Bundle.identifier` is equivalent to `ClinicalDocument.id` and `Bundle.meta.security` is equivalent to `ClinicalDocument.confidentialityCode`.
-   The composition section defines a section (or sub-section) of the document, but unlike CDA, the section entries are actually references to other [resources](resourcelist) that hold the supporting data content for the section. This design means that the data can be reused in many other ways.
-   Unlike CDA, the context defined in the `Composition` (the subject, author, event, event period and encounter) apply to the composition and do not specifically apply to the resources referenced from the `section.entry`. There is no context flow model in FHIR, so each resource referenced from within a `Composition` expresses its own individual context. In this way, clinical content can safely be extracted from the composition.

In addition, note that both the code lists (e.g., [Composition.status](valueset-composition-status)) and the Composition resource are [mapped](composition-mappings) to [HL7 v3](https://www.hl7.org/implement/standards/product_brief.cfm?product_id=186) and/or CDA.

## Notes


## Notes:

-   The author and the attester are often the same person, but this might not be the case in some clinical workflows.
-   The attester attests contents of the document resource, the subject resource and the resources referred to in the Composition.section.content references. Because documents are often derived Compositions and the attestation from the composition is held to apply to the document, the method for [presenting a document](documents#presentation) should be used when/if attesters review the content of the composition.
-   The custodian is responsible for the maintenance of the composition and any documents derived from it. With regard to the documents, they are responsible for the policy regarding persistence of the documents. Although they need not actually retain a copy of the document, they SHOULD do so.
-   It is acceptable for a Composition to contain only narrative (`Composition.section.text`) and no entries (`Composition.section.entry`)

## Compositions about multiple entities

Typically, a composition is made about the subject - e.g. a patient, or group of patients, location, or device - and the distinction between the subject and the composition describes the subject. Some kinds of documents contain data about other parties or entities that are relevant to the subject of the document. Some examples:

-   A neonatal discharge summary that contains information about the mother
-   A family history document that contains multiple sections for different family members
-   A social health evaluation document that contains information about the patient's family members
-   A procedure report that contains details about a device implanted in the patient

In all these cases, the subject of the document is a single patient, but some of the details are actually related to other persons or entities. When this happens, these other entities are detailed in the `Composition.section.focus` element. In the absence of a `focus`, it is assumed that the `subject` of the composition is the focus.

If a `focus` is specified, then the resources referred to from the section SHALL either:

-   specify that their `subject` (however named e.g. `patient`) or `focus` element (if present) is the focus indicated
-   not have a `subject` element

A few compositions genuinely cover multiple subjects - different sections are about different subjects. In such case, `Composition.subject` is omitted, and the extension [section-subject]([%extensions-location%]StructureDefinition-composition-section-subject) is used on each section to indicate the subject.

\[%stu-note dstu%\] Feedback is welcome on two issues related to Composition:

-   For many compositions, the title is the same as the text or a display name of Composition.type (e.g., a "consultation" or "progress note"). Note that [CDA](http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7) does not make title mandatory, but there are no known cases where it is useful for title to be omitted, so it is mandatory here during the trial use period.
-   A client can ask a server to generate a fully bundled document from a Composition resource using the $document operation. This operation definition does not resolve the question how document signatures are created. This is an open issue during the period of trial use, and feedback is requested regarding this question.

Feedback [here](http://hl7.org/fhir-issues). \[%end-note%\]

## StructureDefinition

### Elements (Simplified)

- **[Composition](/composition-definitions#Composition)** [0..*]: - A set of resources composed into a single coherent clinical statement with clinical attestation
- **[Composition.extension](/composition-definitions#Composition.extension)** [1..1]: [Extension](/Extension)([cqm-ValidityPeriod](/cqm-ValidityPeriod)) The validity of the catalog
- **[Composition.type](/composition-definitions#Composition.type)** [1..1]: [CodeableConcept](/CodeableConcept) The type of document - a Catalog
- **[Composition.category](/composition-definitions#Composition.category)** [1..1]: [CodeableConcept](/CodeableConcept) example:[catalog-type](/valueset-catalog-type) The Content of the section
- **[Composition.subject](/composition-definitions#Composition.subject)** [0..0]: Reference([Resource](/Resource)) Who and/or what the composition is about
- **[Composition.date](/composition-definitions#Composition.date)** [1..1]: [dateTime](/dateTime) When the Catalog was created
- **[Composition.section](/composition-definitions#Composition.section)** [0..*]: -

## Mappings

- [profile-catalog Mappings](/composition-mappings) — 0 mapping entries

## Mapping Exceptions


### composition-event-mapping-exceptions.xml

### Divergent Elements
- **Event.identifier** → **Composition.identifier**
  - shortUnmatched | reason=Unknown | pattern=Business identifier for composition | resource=Version-independent identifier for the Composition
  - definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this composition by the performer and/or other systems.  These identifiers remain constant as the resource is updated and propagates from server to server. | resource=A version-independent identifier for the Composition. This identifier stays constant as the composition is changed over time.
  - commentsUnmatched | reason=Unknown | pattern=Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)).  It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types.  For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=Similar to ClinicalDocument/setId in CDA. See discussion in resource definition for how these relate.
  - requirementsUnmatched | reason=Unknown | pattern=Allows identification of the composition as it is known by various participating systems and in a way that remains consistent across servers.
- **Event.basedOn** → **Composition.basedOn**
  - missingTypes | reason=Unknown | pattern=Reference(Request)
  - extraTypes | reason=Unknown
  - summary | reason=Unknown | pattern=true
  - requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the composition and tracking whether proposals/recommendations were acted upon. | resource=Allows tracing of authorization for the event and tracking whether proposals/recommendations were acted upon.
- **Event.status** → **Composition.status**
  - shortUnmatched | reason=Unknown | pattern=preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown | resource=registered | partial | preliminary | final | amended | corrected | appended | cancelled | entered-in-error | deprecated | unknown
  - definitionUnmatched | reason=Unknown | pattern=The current state of the composition. | resource=The workflow/clinical status of this composition. The status is a marker for the clinical standing of the document.
  - commentsUnmatched | reason=Unknown | pattern=A nominal state-transition diagram can be found in the (Event pattern documentation

Unknown does not represent "other" - one of the defined statuses must apply.  Unknown is used when the authoring system is not sure what the current status is. | resource=If a composition is marked as withdrawn, the compositions/documents in the series, or data from the composition or document series, should never be displayed to a user without being clearly marked as untrustworthy. The flag "entered-in-error" is why this element is labeled as a modifier of other elements.   

Some reporting work flows require that the original narrative of a final document never be altered; instead, only new narrative can be added. The composition resource has no explicit status for explicitly noting whether this business rule is in effect. This would be handled by an extension if required.
- **Event.code** → **Composition.type**
  - shortUnmatched | reason=Unknown | pattern=What service was done | resource=Kind of composition (LOINC if possible)
  - definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action that was or is being performed. | resource=Specifies the particular kind of composition (e.g. History and Physical, Discharge Summary, Progress Note). This usually equates to the purpose of making the composition.
- **Event.subject** → **Composition.subject**
  - missingTypes | reason=Unknown | pattern=Reference(Patient, Group)
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Individual service was done for/to | resource=Who and/or what the composition is about
  - definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is being or was performed on. | resource=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).
  - requirementsUnmatched | reason=Unknown | pattern=Links the composition to the Patient context.  May also affect access control. | resource=Essential metadata for searching for the composition. Identifies who and/or what the composition/document is about.
- **Event.encounter** → **Composition.encounter**
  - shortUnmatched | reason=Unknown | pattern=Encounter the composition is part of | resource=Context of the Composition
  - definitionUnmatched | reason=Unknown | pattern=The Encounter during which this composition was created or to which the creation of this record is tightly associated. | resource=Describes the clinical encounter or type of care this documentation is associated with.
  - commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter the composition was created during, but some compositions may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).
  - requirementsUnmatched | reason=Unknown | pattern=Links the composition to the Encounter context.  May also affect access control. | resource=Provides context for the composition and supports searching.
- **Event.occurrence[x]** → **Composition.date**
  - missingTypes | reason=Unknown | pattern=Period, Timing
  - shortUnmatched | reason=Unknown | pattern=When composition occurred/is occurring | resource=Composition editing time
  - definitionUnmatched | reason=Unknown | pattern=The date, period or timing when the composition did occur or is occurring. | resource=The composition editing time, when the composition was last logically changed by the author.
  - commentsUnmatched | reason=Unknown | pattern=This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur.  For the latter, look at the occurence element of the  Request this {{event}} is "basedOn".  The status code allows differentiation of whether the timing reflects a historic event or an ongoing event.  Ongoing events should not include an upper bound in the Period or Timing.bounds.
. | resource=The Last Modified Date on the composition may be after the date of the document was attested without being changed. This means that the date on an amended document is the date of the amendment, not the date of original authorship.
- **Event.performer** → **Composition.author**
  - extraTypes | reason=Unknown
  - shortUnmatched | reason=Unknown | pattern=Who performed composition and what they did | resource=Who and/or what authored the composition
  - definitionUnmatched | reason=Unknown | pattern=Indicates who or what performed the composition and how they were involved. | resource=Identifies who is responsible for the information in the composition, not necessarily who typed it in.

### Unmapped Elements
- **Event.partOf** — Unknown
- **Event.reported** — Unknown
- **Event.reason** — Unknown
- **Event.relevantHistory** — Unknown
- **Event.location** — Unknown
- **Event.statusReason** — Unknown
- **Event.performer.actor** — Unknown
- **Event.performer.function** — Unknown
- **Event.note** — Unknown
- **Event.category** — Unknown
- **Event.recorded** — Unknown
- **Event.product** — Unknown

### composition-fivews-mapping-exceptions.xml

### Unmapped Elements
- **FiveWs.what** — Unknown
- **FiveWs.recorded** — Unknown
- **FiveWs.actor** — Unknown
- **FiveWs.cause** — Unknown
- **FiveWs.where** — Unknown
- **FiveWs.init** — Unknown
- **FiveWs.why** — Unknown
- **FiveWs.source** — Unknown
- **FiveWs.who** — Unknown
- **FiveWs.grade** — Unknown
- **FiveWs.planned** — Unknown