FHIR Clinical Documents
1.1.0 - STU 1.1 International flag

FHIR Clinical Documents, published by HL7 International / Structured Documents. This guide is not an authorized publication; it is the continuous build for version 1.1.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/fhir-clinical-document/ and changes regularly. See the Directory of published versions

Must Support

Page standards status: Informative

Must Support Definition

The MustSupport flag as used in this implementation guide SHALL be interpreted to mean:§mustSupport-1
  • Document creators supporting FHIR Clinical Documents SHALL be capable of populating elements flagged with MS.§mustSupport-2
  • Document consumers supporting FHIR Clinical Documents SHALL be capable of processing elements flagged as MS.§mustSupport-3

Conformance

The following conformance table is is automatically generated by the publisher. It only contains non-computable conformance statements from narrative and does not include profiling requirements or constraints from the Bundle and Composition profiles.

IdExpectationRule
 SHALL
 SHOULD NOT
 MAY
 SHOULD
 SHALL NOT
§bundle-1SHALLthe sender SHALL include the direct targets of all composition references in the bundle.
§creator-guidance-1SHALLSHALL place attested narrative into Composition.section.text.
§creator-guidance-2SHOULD NOTSHOULD NOT redundantly place attested narrative in both Composition.text and Composition.section.text.
§creator-guidance-3MAYMAY include narrative that is not derived from any structured data.
§creator-guidance-4SHOULDSHOULD include document metadata (e.g. patient) in Composition.text.
§creator-guidance-5MAYMAY include a list of document sections in Composition.text
§guidance-composition-1SHALLSHALL place attested narrative into Composition.section.text.
§guidance-composition-2SHOULD NOTSHOULD NOT redundantly place attested narrative in both Composition.text and Composition.section.text.
§guidance-composition-3MAYMAY include narrative that is not derived from any structured data.
§guidance-composition-4SHOULDSHOULD include document metadata (e.g. patient) in Composition.text.
§guidance-composition-5MAYMAY include a list of document sections in Composition.text.
§guidance-composition-6SHALLSHALL include, at a minimum, Composition.title, Composition.section.title and Composition.section.text in any rendition of the document.
§guidance-composition-7MAYMAY include Composition.text in a rendition of the document.
§guidance-composition-8MAYMAY render additional document information (such as patient name and date of birth) derived from structured Composition fields.
§guidance-composition-9SHALLComposition.category: Document creators SHALL include a category value of 'clinical-note'. This serves to differentiate a FHIR Clinical Document from an arbitrary FHIR Document.
§guidance-composition-10SHOULDComposition.custodian: A basic tenet of a clinical document is stewardship, where, by definition, a clinical document is maintained by an organization entrusted with its care. Stewardship is reflected by Composition.custodian. While FHIR R4 restricts a custodian to be an Organization, FHIR R6 will expand on this to accommodate patient authored notes. In anticipation, this IG sets the cardinality of Composition.custodian to 0..1, but stipulates that the custodian SHOULD be populated where it is a known organization.
§guidance-composition-11SHALL NOTparticipant: The participant extensions (data-enterer, informant, information-recipient, participant) derive from the HL7 Clinical Document Architecture standard. Several CDA participant types (e.g. author, custodian) already exist as Composition elements, whereas those not present on the base Composition resource have been added here as extensions (and will be proposed as new elements on the Composition R6 resource). Composition participants reflect activity at the document level (e.g. related to the act of documenting), and are not inherited by referenced resources such as Observations. FHIR Clinical Document creators SHALL NOT use the generic extension:participant where a more specific participant (such as 'informant') exists.
§guidance-composition-12SHALL NOTWhile the R5-Composition-status extension is not defined as a modifierExtension, its meaning SHALL NOT be ignored.
§guidance-readability-1SHALLFHIR core narrative guidance stipulates that a resource's narrative "SHALL reflect all content needed for a human to understand the essential clinical and business information for the resource".
§guidance-readability-2SHALL NOTHuman readability SHALL NOT require a sender to transmit a special style sheet along with a FHIR Clinical Document. It must be possible to render all FHIR Clinical Documents with a single style sheet and general-market display tools.
§mapping-1MAYCDA NonXMLBody: A CDA document with a nonXMLBody MAY be represented in FHIR using a DocumentReference that points to the information contained in the CDA's nonXMLBody. If the unstructured CDA document needs to be persisted as a “whole, authenticated document” (for example a previously digitally signed unstructured CDA document), it MAY be represented in FHIR using a DocumentReference that points to the complete CDA document
§mustSupport-1SHALLThe MustSupport flag as used in this implementation guide SHALL be interpreted to mean:
§mustSupport-2SHALLDocument creators supporting FHIR Clinical Documents SHALL be capable of populating elements flagged with MS.
§mustSupport-3SHALLDocument consumers supporting FHIR Clinical Documents SHALL be capable of processing elements flagged as MS.
§recipient-guidance-1SHALLSHALL include, at a minimum, Composition.title, Composition.section.title and Composition.section.text in any rendition of the document.
§recipient-guidance-2MAYMAY include Composition.text in a rendition of the document.
§recipient-guidance-3MAYMAY render additional document information (such as patient name and date of birth) derived from structured Composition fields.
§versioning-1SHOULDWhile out of scope for this IG, good practice suggests that where revision scenarios are possible, those resources subject to revision SHOULD carry a persistent resource identifier (.identifier).