6.9 Resource Composition - Content

6.9.1 Scope and Usage

A Composition is also the basic structure from which FHIR 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 uses the term "Composition" to refer to a single commit to an EHR system, and offers some common examples: a consultation note, a progress note, a report or a letter, an investigation report, a prescription form and a set of bedside nursing observations. These logical examples are all valid uses of a Composition resource, but it is not required that all the resources are updated in a single commit.

6.9.2 Boundaries and Relationships

Composition is a structure for grouping information for purposes of persistance and attestability. There are several other grouping structures in FHIR with distinct purposes:

• The 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 are 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 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 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.

While a Composition organizes clinical and administrative content, it doesn't directly contain any of this information. The content of the various sections defined by a Composition are satisfied by the resources pointed to by those sections. 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 all gathered together into a Bundle for transport and persistence.

6.9.3 Background and Context

6.9.3.1 Composition Status Codes

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

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

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 "retracted" 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 retracted. Note that systems that handle compositions or derived documents and don't support the retracted 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.

6.9.3.2 Note for CDA aware readers

Many users of this specification are familiar with the Clinical Document Architecture (CDA) and related specifications. CDA is a primary design input to the composition resource (other principle inputs are other HL7 document specifications, and EN13606). There are two 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 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 Bundle.id is equivalent in function to ClinicalDocument.id (but not identical, if interconverting, since it's a transform between them)
• The composition section defines a section (or sub-section) of the document, but unlike in CDA, the section content is actually a reference to another resource that actually holds both the narrative and data content for the section. This design means that the narrative and data can be reused in many other ways. Note that the most common resource to use for the content of a section is the List resource. When a composition and its lists are wrapped into Document, the List narrative is part of the 'attested content' (see below), and an indivisible part of the document.

In addition, note that both the code lists (e.g. Composition status) and the composition resource are mapped to v3 and/or CDA.

• Structure
• UML
• XML
• JSON
• All

Structure

Name	Flags	Card.	Type	Description & Constraints
Composition			DomainResource	A set of resources composed into a single coherent clinical statement with clinical attestation
identifier	Σ	0..1	Identifier	Logical identifier of composition (version-independent)
date	Σ	1..1	dateTime	Composition editing time
type	Σ	1..1	CodeableConcept	Kind of composition (LOINC if possible) DocumentType (Required)
class	Σ	0..1	CodeableConcept	Categorization of Composition DocumentC80Class (Preferred)
title	Σ	0..1	string	Human Readable name/title
status	?! Σ	1..1	code	preliminary | final | appended | amended | entered-in-error CompositionStatus (Required)
confidentiality	?! Σ	0..1	code	As defined by affinity domain DocumentConfidentiality (Required)
subject	Σ	1..1	Any	Who and/or what the composition is about
author	Σ	1..*	Practitioner | Device | Patient | RelatedPerson	Who and/or what authored the composition
attester	Σ	0..*	Element	Attests to accuracy of composition
mode	Σ	1..*	code	personal | professional | legal | official CompositionAttestationMode (Required)
time	Σ	0..1	dateTime	When composition attested
party	Σ	0..1	Patient | Practitioner | Organization	Who attested the composition
custodian	Σ	0..1	Organization	Org which maintains the composition
event	Σ	0..*	Element	The clinical service(s) being documented
code	Σ	0..*	CodeableConcept	Code(s) that apply to the event being documented DocumentEventType (Required)
period	Σ	0..1	Period	The period covered by the documentation
detail	Σ	0..*	Any	Full details for the event(s) the composition consents
encounter	Σ	0..1	Encounter	Context of the conposition
section	I	0..*	Element	Composition is broken into sections A section must have either subsections or content
title		0..1	string	Label for section (e.g. for ToC)
code		0..1	CodeableConcept	Classification of section (recommended) CompositionSectionType (Required)
content	I	0..1	List	The Content of the section (narrative + data entries)
section	I	0..*	see section	Nested Section

<Composition xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier 
     Logical identifier of composition (version-independent) --></identifier>
 <date value="[dateTime]"/><!-- 1..1 Composition editing time -->
 <type><!-- 1..1 CodeableConcept Kind of composition (LOINC if possible) --></type>
 <class><!-- 0..1 CodeableConcept Categorization of Composition --></class>
 <title value="[string]"/><!-- 0..1 Human Readable name/title -->
 <status value="[code]"/><!-- 1..1 preliminary | final | appended | amended | entered-in-error -->
 <confidentiality value="[code]"/><!-- 0..1 As defined by affinity domain -->
 <subject><!-- 1..1 Reference(Any) Who and/or what the composition is about --></subject>
 <author><!-- 1..* Reference(Practitioner|Device|Patient|RelatedPerson) 
     Who and/or what authored the composition --></author>
 <attester>  <!-- 0..* Attests to accuracy of composition -->
  <mode value="[code]"/><!-- 1..* personal | professional | legal | official -->
  <time value="[dateTime]"/><!-- 0..1 When composition attested -->
  <party><!-- 0..1 Reference(Patient|Practitioner|Organization) Who attested the composition --></party>
 </attester>
 <custodian><!-- 0..1 Reference(Organization) Org which maintains the composition --></custodian>
 <event>  <!-- 0..* The clinical service(s) being documented -->
  <code><!-- 0..* CodeableConcept Code(s) that apply to the event being documented --></code>
  <period><!-- 0..1 Period The period covered by the documentation --></period>
  <detail><!-- 0..* Reference(Any) Full details for the event(s) the composition consents --></detail>
 </event>
 <encounter><!-- 0..1 Reference(Encounter) Context of the conposition --></encounter>
 <section>  <!-- 0..* Composition is broken into sections -->
  <title value="[string]"/><!-- 0..1 Label for section (e.g. for ToC) -->
  <code><!-- 0..1 CodeableConcept Classification of section (recommended) --></code>
  <content><!--  0..1 Reference(List) The Content of the section (narrative + data entries) --></content>
  <section><!--  0..* Content as for Composition.section Nested Section --></section>
 </section>
</Composition>

{
  "resourceType" : "Composition",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // 
     Logical identifier of composition (version-independent)
  "date" : "<dateTime>", // R!  Composition editing time
  "type" : { CodeableConcept }, // R!  Kind of composition (LOINC if possible)
  "class" : { CodeableConcept }, // Categorization of Composition
  "title" : "<string>", // Human Readable name/title
  "status" : "<code>", // R!  preliminary | final | appended | amended | entered-in-error
  "confidentiality" : "<code>", // As defined by affinity domain
  "subject" : { Reference(Any) }, // R!  Who and/or what the composition is about
  "author" : [{ Reference(Practitioner|Device|Patient|RelatedPerson) }], // R!  
     Who and/or what authored the composition
  "attester" : [{ // Attests to accuracy of composition
    "mode" : ["<code>"], // R!  personal | professional | legal | official
    "time" : "<dateTime>", // When composition attested
    "party" : { Reference(Patient|Practitioner|Organization) } // Who attested the composition
  }],
  "custodian" : { Reference(Organization) }, // Org which maintains the composition
  "event" : [{ // The clinical service(s) being documented
    "code" : [{ CodeableConcept }], // Code(s) that apply to the event being documented
    "period" : { Period }, // The period covered by the documentation
    "detail" : [{ Reference(Any) }] // Full details for the event(s) the composition consents
  }],
  "encounter" : { Reference(Encounter) }, // Context of the conposition
  "section" : [{ // Composition is broken into sections
    "title" : "<string>", // Label for section (e.g. for ToC)
    "code" : { CodeableConcept }, // Classification of section (recommended)
    "content" : { Reference(List) }, // C? The Content of the section (narrative + data entries)
    "section" : [{ Content as for Composition.section }] // C? Nested Section
  }]
}

Structure

Name	Flags	Card.	Type	Description & Constraints
Composition			DomainResource	A set of resources composed into a single coherent clinical statement with clinical attestation
identifier	Σ	0..1	Identifier	Logical identifier of composition (version-independent)
date	Σ	1..1	dateTime	Composition editing time
type	Σ	1..1	CodeableConcept	Kind of composition (LOINC if possible) DocumentType (Required)
class	Σ	0..1	CodeableConcept	Categorization of Composition DocumentC80Class (Preferred)
title	Σ	0..1	string	Human Readable name/title
status	?! Σ	1..1	code	preliminary | final | appended | amended | entered-in-error CompositionStatus (Required)
confidentiality	?! Σ	0..1	code	As defined by affinity domain DocumentConfidentiality (Required)
subject	Σ	1..1	Any	Who and/or what the composition is about
author	Σ	1..*	Practitioner | Device | Patient | RelatedPerson	Who and/or what authored the composition
attester	Σ	0..*	Element	Attests to accuracy of composition
mode	Σ	1..*	code	personal | professional | legal | official CompositionAttestationMode (Required)
time	Σ	0..1	dateTime	When composition attested
party	Σ	0..1	Patient | Practitioner | Organization	Who attested the composition
custodian	Σ	0..1	Organization	Org which maintains the composition
event	Σ	0..*	Element	The clinical service(s) being documented
code	Σ	0..*	CodeableConcept	Code(s) that apply to the event being documented DocumentEventType (Required)
period	Σ	0..1	Period	The period covered by the documentation
detail	Σ	0..*	Any	Full details for the event(s) the composition consents
encounter	Σ	0..1	Encounter	Context of the conposition
section	I	0..*	Element	Composition is broken into sections A section must have either subsections or content
title		0..1	string	Label for section (e.g. for ToC)
code		0..1	CodeableConcept	Classification of section (recommended) CompositionSectionType (Required)
content	I	0..1	List	The Content of the section (narrative + data entries)
section	I	0..*	see section	Nested Section

UML Diagram

XML Template

<Composition xmlns="http://hl7.org/fhir"> 
 <!-- from Resource: id, meta, implicitRules, and language -->
 <!-- from DomainResource: text, contained, extension, and modifierExtension -->
 <identifier><!-- 0..1 Identifier 
     Logical identifier of composition (version-independent) --></identifier>
 <date value="[dateTime]"/><!-- 1..1 Composition editing time -->
 <type><!-- 1..1 CodeableConcept Kind of composition (LOINC if possible) --></type>
 <class><!-- 0..1 CodeableConcept Categorization of Composition --></class>
 <title value="[string]"/><!-- 0..1 Human Readable name/title -->
 <status value="[code]"/><!-- 1..1 preliminary | final | appended | amended | entered-in-error -->
 <confidentiality value="[code]"/><!-- 0..1 As defined by affinity domain -->
 <subject><!-- 1..1 Reference(Any) Who and/or what the composition is about --></subject>
 <author><!-- 1..* Reference(Practitioner|Device|Patient|RelatedPerson) 
     Who and/or what authored the composition --></author>
 <attester>  <!-- 0..* Attests to accuracy of composition -->
  <mode value="[code]"/><!-- 1..* personal | professional | legal | official -->
  <time value="[dateTime]"/><!-- 0..1 When composition attested -->
  <party><!-- 0..1 Reference(Patient|Practitioner|Organization) Who attested the composition --></party>
 </attester>
 <custodian><!-- 0..1 Reference(Organization) Org which maintains the composition --></custodian>
 <event>  <!-- 0..* The clinical service(s) being documented -->
  <code><!-- 0..* CodeableConcept Code(s) that apply to the event being documented --></code>
  <period><!-- 0..1 Period The period covered by the documentation --></period>
  <detail><!-- 0..* Reference(Any) Full details for the event(s) the composition consents --></detail>
 </event>
 <encounter><!-- 0..1 Reference(Encounter) Context of the conposition --></encounter>
 <section>  <!-- 0..* Composition is broken into sections -->
  <title value="[string]"/><!-- 0..1 Label for section (e.g. for ToC) -->
  <code><!-- 0..1 CodeableConcept Classification of section (recommended) --></code>
  <content><!--  0..1 Reference(List) The Content of the section (narrative + data entries) --></content>
  <section><!--  0..* Content as for Composition.section Nested Section --></section>
 </section>
</Composition>

JSON Template

{
  "resourceType" : "Composition",
  // from Resource: id, meta, implicitRules, and language
  // from DomainResource: text, contained, extension, and modifierExtension
  "identifier" : { Identifier }, // 
     Logical identifier of composition (version-independent)
  "date" : "<dateTime>", // R!  Composition editing time
  "type" : { CodeableConcept }, // R!  Kind of composition (LOINC if possible)
  "class" : { CodeableConcept }, // Categorization of Composition
  "title" : "<string>", // Human Readable name/title
  "status" : "<code>", // R!  preliminary | final | appended | amended | entered-in-error
  "confidentiality" : "<code>", // As defined by affinity domain
  "subject" : { Reference(Any) }, // R!  Who and/or what the composition is about
  "author" : [{ Reference(Practitioner|Device|Patient|RelatedPerson) }], // R!  
     Who and/or what authored the composition
  "attester" : [{ // Attests to accuracy of composition
    "mode" : ["<code>"], // R!  personal | professional | legal | official
    "time" : "<dateTime>", // When composition attested
    "party" : { Reference(Patient|Practitioner|Organization) } // Who attested the composition
  }],
  "custodian" : { Reference(Organization) }, // Org which maintains the composition
  "event" : [{ // The clinical service(s) being documented
    "code" : [{ CodeableConcept }], // Code(s) that apply to the event being documented
    "period" : { Period }, // The period covered by the documentation
    "detail" : [{ Reference(Any) }] // Full details for the event(s) the composition consents
  }],
  "encounter" : { Reference(Encounter) }, // Context of the conposition
  "section" : [{ // Composition is broken into sections
    "title" : "<string>", // Label for section (e.g. for ToC)
    "code" : { CodeableConcept }, // Classification of section (recommended)
    "content" : { Reference(List) }, // C? The Content of the section (narrative + data entries)
    "section" : [{ Content as for Composition.section }] // C? Nested Section
  }]
}