GB/T 42384-2023Health informatics - Data exchange standards - HL7 clinical document architecture (release 2) (English PDF)

1 Scope

This document defines the terms and definitions relating to the clinical document architecture (CDA), describes the technical artifacts of CDA, specifies the requirements for exchanging CDA documents in HL7 messages, and gives the CDA R-MIM, the CDA hierarchical description and the XML implementation of CDA.

The following are outside the scope of the document: clinical document data formats outside the exchange context, such as data formats used to store clinical documents; HL7 messages designed solely for the transmission of clinical documents; and the creation and management of documents.

The document applies to the research, development and management of clinical documents exchanged in healthcare information systems.

2 Normative references

The contents of the following documents constitute indispensable provisions of this document through normative reference in the text. For dated references, only the edition corresponding to that date applies; for undated references, the latest edition, including all amendments, applies.

The list comprises GB/T 30107-2013 Health informatics - HL7 V3 - Reference information model (ISO/HL7 21731:2006, MOD), with a note recording that the content of GB/T 30107-2013 cited here does not differ technically from the content cited from ISO/HL7 21731:2006; HL7 Vocabulary; the HL7 V3 XML Implementable Technology Specification (ITS); the HL7 Version 3 Standard: Data Types - Abstract Specification, Release 1; IETF RFC 2046 Multipurpose Internet Mail Extensions (MIME); IETF RFC 2557 MIME Encapsulation of Aggregate Documents; IETF RFC 3066 Tags for the Identification of Languages; and the XML Implementation Technology Specification - Data Types.

3 Terms and definitions

3.1 clinical document architecture, CDA: a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange.

3.2 document type definition, DTD: an XML document type declaration that contains, or points to, the grammar for a class of documents.

3.3 healthcare professional: a person entrusted with providing healthcare services directly or indirectly to a subject of care or to a group of subjects of care. The examples given are qualified practising physicians, practising assistant physicians, pharmacists, registered nurses, medical laboratory technicians, medical imaging technicians and village doctors. The entry is sourced from ENV 1613:1995, 3.13 and ISO 21549-7:2016, 3.9.

3.4 regulatory agency (or authorities): the collective name for the agencies or departments established by a geopolitical entity and responsible for regulating healthcare products.

3.5 reference information model, RIM: the HL7 information model from which all other information models, such as the R-MIM, and the models of messages are derived.

3.6 refined message information model, R-MIM: an information structure that represents the requirements for a set of messages.

3.7 extensible markup language, XML: a simple and very flexible text format derived from SGML (ISO 8879). A note records that XML was originally designed to meet the challenges of large-scale electronic publishing and that it plays an increasingly important role in the exchange of a wide variety of data on the web and elsewhere.

3.8 XML schema: a way of defining in detail the structure, content and semantics of an XML document; XML schemas are used to represent shareable vocabularies and allow machines to carry out rules made by people.

4 Abbreviated terms

The abbreviations listed are CDA, clinical document architecture; CE, coded with equivalents; CEN, Comité Européen de Normalisation; CNE, coded, no extension; CWE, coded with extension; DICOM, Digital Imaging and Communications in Medicine; DTD, document type definition; ED, encapsulated data; HL7, Health Level 7; LOINC, Logical Observation Identifiers Names and Codes; MIME, Multipurpose Internet Mail Extensions; R-MIM, refined message information model; RIM, reference information model; SGML, standardized generalized markup language; SNOMED, Systematized Nomenclature of Human and Veterinary Medicine; SNOMED-CT, Systematized Nomenclature of Medicine - Clinical Terms; UML, unified modelling language; W3C, World Wide Web Consortium; XML, eXtensible Markup Language.

5.1 What is CDA

Characteristics of a clinical document: a clinical document is a document about clinical observation and services and has the following characteristics. Persistence: the state of the clinical document stays unchanged for the period of time laid down by local regulatory requirements; a note records that the persistence of a clinical document has a definite scope and is unrelated to the persistence of an XML-encoded CDA document instance. Stewardship: the clinical document is maintained by an entrusted organisation. Potential for authentication: the clinical document is a set of information that can be legally authenticated. Context: the clinical document establishes a default context for its content. Wholeness: authentication of the clinical document applies to the whole document and not to parts of the document without the full document context. Human readability: the clinical document is human readable. A CDA document is a defined and complete information object that can include text, images, sound and other multimedia content.

Benefits of CDA: CDA documents can be encoded in XML, with a note recording that when a workable alternative implementation appears, suitable conformance requirements will be published so that the syntax is not restricted to XML in future; CDA documents integrate the machine-processable meaning of the HL7 RIM and use the HL7 V3 data types; and CDA has rich expressive power and flexibility, document-level, section-level and entry-level templates being usable to constrain the general CDA specification.

Goals and design principles of CDA: the stated goals are to give priority to the provision of care to patients; to allow cost-effective control to be implemented within as wide a range of systems as possible; to support the exchange of human-readable documents between users, including users of differing technical levels; to extend the lifetime of all information encoded in CDA; to support a wide range of post-exchange processing applications; to be compatible with a variety of document creation applications; to promote exchange independent of the underlying transfer or storage mechanism; to allow designs to be prepared quickly and reasonably; and to enable decision makers to control their information needs without extending the document.

The design principles derived from those goals are that CDA is compatible with XML and the HL7 RIM; that CDA is compatible with the clinical information representations of the HL7 organisation; that the technical barriers to using CDA are minimised; that CDA specifies the representation of the instances needed for exchange; that CDA imposes minimal constraints or requirements on the document structure and content needed for exchange; that CDA can be adapted through fine-grained markup, such as highly structured text and coded data; that CDA-based document specifications can accommodate the constraints and requirements raised by professionals, commercial bodies and regulatory agencies; that document specifications for document creation and processing map to CDA where the purpose is exchange; that CDA documents are human readable and can be rendered by a general CDA style sheet written with widely available and generally deployed XML-aware browsers, print drivers and a standard style sheet language; and that open standards are used.

5.2.1 Major components of a CDA document

An example gives the major components of a prototype CDA document, showing a ClinicalDocument element containing the CDA header and a structuredBody element, within which section elements contain a text element, observation entries and a substanceAdministration entry with a nested supply entry, one observation entry containing an externalObservation, and one section nested inside another section.

A CDA document is wrapped by the ClinicalDocument element and consists of a document header and a document body. The header lies between the ClinicalDocument element and the structuredBody element, identifies and classifies the document, and gives information on authentication, the encounter, the patient and the involved providers.

The clinical report contained in the document body may be an unstructured node or may be made up of structured markup; the example above gives a structured document body contained in a structuredBody element, which may be divided into recursively nested document sections.

A document section is wrapped by the section element. Each section may contain a single narrative block, any number of CDA entries and external references. The CDA narrative block is wrapped by the section element inside a text element and contains the human-readable content to be rendered; the principles governing the representation of the narrative block, the originator that partly fills it and the conformance requirements of the receiver that renders it are given in 5.2.3 and 5.3.

Within a document section, the narrative block represents the content to be rendered and the CDA entries represent the structured content provided for subsequent computer processing, such as decision support applications; CDA entries encode the content of the narrative block of the same section. The example above gives two observation entries and one substanceAdministration entry containing a nested supply entry, and defines several further CDA entries.

CDA entries may be nested and may also reference external objects. External references in CDA commonly occur within the context of a CDA entry. An external reference refers to content that exists outside the CDA document, such as some other image, procedure or observation wrapped by an externalObservation element. Authentication of a document that references external material does not extend to the referenced external material.

5.2.2 The "A" in CDA

In CDA release 1, the concept of CDA levels achieved the goals above through a set of hierarchical XML DTDs or XML schemas; that hierarchy formed an architecture, the "A" in CDA.

Although the concept of CDA levels in CDA release 2 stays consistent with CDA release 1, the way the levels are expressed is different. The current specification consists of a single CDA XML schema, and its architecture forms the ability to use one or more sets of hierarchical HL7 templates, which are used to constrain the richness and flexibility of CDA.

HL7 templates can be of many kinds, of which two are closely related to clinical documents: section-level templates, which constrain document sections on the basis of the document type; and entry-level templates, which constrain the entries within a document section.

In practice, the two kinds of HL7 template can be used to compare the concept of levels in CDA release 1 and CDA release 2, as shown in Table 1. Table 1 pairs CDA release 1 level one with an unconstrained CDA specification, CDA release 1 level two with a CDA specification to which section-level templates are applied, and CDA release 1 level three with a CDA specification to which entry-level templates, and optionally section-level templates, are applied.

An example then gives one possible hierarchy formed by CDA plus HL7 templates, starting from the CDA schema and descending through a progress note section-level template, a progress note section-level template with a vital signs entry-level template, an endocrinology progress note section-level template with a vital signs entry-level template, a progress note section-level template with an ICU vital signs entry-level template, a cardiology progress note section-level template, a cardiology progress note section-level template with a cardiac exam entry-level template, an endocrinology progress note section-level template, and an endocrinology progress note section-level template with a vital signs entry-level template.

5.2.3 Human readability and renderable CDA documents

The requirement of CDA for human readability guarantees that a receiver of a CDA document can display the annotated clinical content algorithmically in a standard web browser. CDA release 2 merges narrative entries and CDA entries and gives specific content to the human readability requirement.

The requirements that shaped the design of CDA release 2 are as follows: every receiver of a CDA document has a determinate way of rendering the authenticated content; human readability does not require the sender to send a special style sheet together with the CDA document, and a single style sheet and a general rendering tool are used to render all CDA documents; human readability applies to authenticated content, other information possibly conveyed in the document being intended mainly for machine processing that is not authenticated and need not be rendered; when structured content is derived from narrative, a mechanism describes the process by which the machine-processable part is derived from the narrative block, such as who created it, who is responsible for coding it, what natural language processing algorithm was used and what software carried out the processing; and when narrative is derived from structured content, a mechanism identifies the process by which the narrative is derived from the structured data.

These principles and requirements form the current approach, in which the material rendered is located in the Section.text field, described in 8.4.5. The content model of that field is designed to meet the requirements above and corresponds closely to the content model of sections in CDA release 1. Structured observation content may reference narrative content in Section.text. Multimedia observations may be encoded outside the Section.text field, and the renderMultiMedia tag in the Section.text field provides an external pointer indicating where the referenced multimedia is to be rendered.

5.2.4 XML markup of CDA documents

This document specifies that CDA documents use XML markup. A CDA instance is valid against the CDA schema and may require additional validation, described in 5.3. As long as conformant instances are compatible, the use of various schema languages is not prohibited, such as W3C, DTD and RELAX NG (REgular LAnguage for XML Next Generation).

The design principles of the CDA schema are as follows. General requirements: the design of the CDA schema follows the more general CDA requirements given in 5.1.3. CDA schema and the HL7 V3 XML Implementable Technology Specification: the CDA schema follows the general HL7 V3 XML Implementable Technology Specification. RIM mapping: the CDA schema describes the XML markup style of the CDA instances used for exchange and applies only to the context defined by this document; moreover, although the CDA schema is not intended to convey or replace the R-MIM and the hierarchical description, it is useful in itself for implementation purposes, so that the CDA schema is not by itself a complete mapping between conformant instances and the HL7 RIM, and semantic interoperability of CDA instances requires the use of the CDA schema, the R-MIM, the hierarchical description and the corresponding RIM together with the corresponding knowledge. Document analysis: in deriving the content model, the CDA schema and conformant instances follow the document analysis requirements. A first note records that document analysis is a process that may be regarded as equivalent to use case documentation, that it looks at the instances or classes of a single document and analyses their structure and content, usually represented in a tree-structured "elm" notation, that it also looks at the lifecycle business rules of a document or class of documents, and that in general document analysis determines the content model and the overall structure and style of the XML. A second note records that document analysis is an iterative step in content model derivation, in which a bottom-up approach complements the top-down approach derived from the RIM, so that the schema and the instances are not only derived from the RIM but also represent identifiable artifacts in a simple way. Backward and forward compatibility: the CDA schema follows the compatibility requirements given in 5.5. Naming: by definition, XML markup is used for machine processing, but it is optimised for manual review, debugging and design.

Note Note on the printed text

Clause 1 of the printed Chinese text names the model "CDA R-MIN", where clause 8 and the rest of the document use "CDA R-MIM". The Foreword records that the "R-MIM" and "RMIM" spellings used in ISO/HL7 27932:2009 were unified as "R-MIM". The form R-MIM is used throughout this record.