6.8 Resource Composition - Content

6.8.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 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 uses of the Composition resource, but for FHIR purposes, it would be usual to make more granular updates with individual provenance statements.

6.8.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 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 containing the Composition and its entries.

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 all gathered together into a Bundle for transport and persistence. The following list of Composition references SHALL be included in the bundle:

• Composition.subject
• Composition.author
• Composition.attester.party
• Composition.custodian
• Composition.event.detail
• Composition.encounter
• Composition.section.entry

Other resources referred to by those resources may be included in the bundle at the discretion of the authoring system, or as specified by any applicable profiles.

6.8.3 Background and Context

6.8.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.8.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 entries are actually references to other resources 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 confidentiality, subject, author, event and 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) 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) FHIR Document Type Codes (Preferred)
class	Σ	0..1	CodeableConcept	Categorization of Composition FHIR Document Class Codes (Example)
title	Σ	1..1	string	Human Readable name/title
status	?! Σ	1..1	code	preliminary | final | amended | entered-in-error CompositionStatus (Required)
confidentiality	?! Σ	0..1	code	As defined by affinity domain v3 Code System Confidentiality (Required)
subject	Σ	1..1	Reference(Any)	Who and/or what the composition is about
author	Σ	1..*	Reference(Practitioner | Device | Patient | RelatedPerson)	Who and/or what authored the composition
attester	Σ	0..*	BackboneElement	Attests to accuracy of composition
mode	Σ	1..*	code	personal | professional | legal | official CompositionAttestationMode (Required)
time	Σ	0..1	dateTime	When composition attested
party	Σ	0..1	Reference(Patient | Practitioner | Organization)	Who attested the composition
custodian	Σ	0..1	Reference(Organization)	Org which maintains the composition
event	Σ	0..*	BackboneElement	The clinical service(s) being documented
code	Σ	0..*	CodeableConcept	Code(s) that apply to the event being documented v3 Code System ActCode (Example)
period	Σ	0..1	Period	The period covered by the documentation
detail	Σ	0..*	Reference(Any)	The event(s) being documented
encounter	Σ	0..1	Reference(Encounter)	Context of the conposition
section	I	0..*	BackboneElement	Composition is broken into sections A section can only have an emptyReason if it is empty A section must at least one of text, entries, or sub-sections
title		0..1	string	Label for section (e.g. for ToC)
code		0..1	CodeableConcept	Classification of section (recommended) Document Section Codes (Example)
text	I	0..1	Narrative	Text summary of the section, for human interpretation
mode	?! Σ	0..1	code	working | snapshot | changes ListMode (Required)
orderedBy		0..1	CodeableConcept	What order the section entries are in List Order Codes (Preferred)
entry	I	0..*	Reference(Any)	A reference to data that supports this section
emptyReason	I	0..1	CodeableConcept	Why the section is empty List Empty Reasons (Preferred)
section	I	0..*	see section	Nested Section
Documentation for this format

<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]"/><!-- 1..1 Human Readable name/title -->
 <status value="[code]"/><!-- 1..1 preliminary | final | 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) The event(s) being documented --></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>
  <text><!--  0..1 Narrative Text summary of the section, for human interpretation --></text>
  <mode value="[code]"/><!-- 0..1 working | snapshot | changes -->
  <orderedBy><!-- 0..1 CodeableConcept What order the section entries are in --></orderedBy>
  <entry><!--  0..* Reference(Any) A reference to data that supports this section --></entry>
  <emptyReason><!--  0..1 CodeableConcept Why the section is empty --></emptyReason>
  <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>", // R!  Human Readable name/title
  "status" : "<code>", // R!  preliminary | final | 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) }] // The event(s) being documented
  }],
  "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)
    "text" : { Narrative }, // C? Text summary of the section, for human interpretation
    "mode" : "<code>", // working | snapshot | changes
    "orderedBy" : { CodeableConcept }, // What order the section entries are in
    "entry" : [{ Reference(Any) }], // C? A reference to data that supports this section
    "emptyReason" : { CodeableConcept }, // C? Why the section is empty
    "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) FHIR Document Type Codes (Preferred)
class	Σ	0..1	CodeableConcept	Categorization of Composition FHIR Document Class Codes (Example)
title	Σ	1..1	string	Human Readable name/title
status	?! Σ	1..1	code	preliminary | final | amended | entered-in-error CompositionStatus (Required)
confidentiality	?! Σ	0..1	code	As defined by affinity domain v3 Code System Confidentiality (Required)
subject	Σ	1..1	Reference(Any)	Who and/or what the composition is about
author	Σ	1..*	Reference(Practitioner | Device | Patient | RelatedPerson)	Who and/or what authored the composition
attester	Σ	0..*	BackboneElement	Attests to accuracy of composition
mode	Σ	1..*	code	personal | professional | legal | official CompositionAttestationMode (Required)
time	Σ	0..1	dateTime	When composition attested
party	Σ	0..1	Reference(Patient | Practitioner | Organization)	Who attested the composition
custodian	Σ	0..1	Reference(Organization)	Org which maintains the composition
event	Σ	0..*	BackboneElement	The clinical service(s) being documented
code	Σ	0..*	CodeableConcept	Code(s) that apply to the event being documented v3 Code System ActCode (Example)
period	Σ	0..1	Period	The period covered by the documentation
detail	Σ	0..*	Reference(Any)	The event(s) being documented
encounter	Σ	0..1	Reference(Encounter)	Context of the conposition
section	I	0..*	BackboneElement	Composition is broken into sections A section can only have an emptyReason if it is empty A section must at least one of text, entries, or sub-sections
title		0..1	string	Label for section (e.g. for ToC)
code		0..1	CodeableConcept	Classification of section (recommended) Document Section Codes (Example)
text	I	0..1	Narrative	Text summary of the section, for human interpretation
mode	?! Σ	0..1	code	working | snapshot | changes ListMode (Required)
orderedBy		0..1	CodeableConcept	What order the section entries are in List Order Codes (Preferred)
entry	I	0..*	Reference(Any)	A reference to data that supports this section
emptyReason	I	0..1	CodeableConcept	Why the section is empty List Empty Reasons (Preferred)
section	I	0..*	see section	Nested Section
Documentation for this format

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]"/><!-- 1..1 Human Readable name/title -->
 <status value="[code]"/><!-- 1..1 preliminary | final | 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) The event(s) being documented --></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>
  <text><!--  0..1 Narrative Text summary of the section, for human interpretation --></text>
  <mode value="[code]"/><!-- 0..1 working | snapshot | changes -->
  <orderedBy><!-- 0..1 CodeableConcept What order the section entries are in --></orderedBy>
  <entry><!--  0..* Reference(Any) A reference to data that supports this section --></entry>
  <emptyReason><!--  0..1 CodeableConcept Why the section is empty --></emptyReason>
  <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>", // R!  Human Readable name/title
  "status" : "<code>", // R!  preliminary | final | 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) }] // The event(s) being documented
  }],
  "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)
    "text" : { Narrative }, // C? Text summary of the section, for human interpretation
    "mode" : "<code>", // working | snapshot | changes
    "orderedBy" : { CodeableConcept }, // What order the section entries are in
    "entry" : [{ Reference(Any) }], // C? A reference to data that supports this section
    "emptyReason" : { CodeableConcept }, // C? Why the section is empty
    "section" : [{ Content as for Composition.section }] // C? Nested Section
  }]
}