Members of the Health Level Seven (HL7) Structured Documents Technical Committee have announced the publication of a revised HL7 Clinical Document Architecture specification. CDA Release 2.0 is currently being balloted within the HL7 committee and is available for public review.

The HL7 Clinical Document Architecture is an XML-based document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. Known earlier as the Patient Record Architecture (PRA), CDA "provides an exchange model for clinical documents such as discharge summaries and progress notes, and brings the healthcare industry closer to the realization of an electronic medical record. By leveraging the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable (so they are easily parsed and processed electronically) and human-readable so they can be easily retrieved and used by the people who need them. CDA documents can be displayed using XML-aware Web browsers or wireless applications such as cell phones..."

The HL7 CDA was designed to "give priority to delivery of patient care. It provides cost effective implementation across as wide a spectrum of systems as possible. It supports exchange of human-readable documents between users, including those with different levels of technical sophistication, and promotes longevity of all information encoded according to this architecture. CDA enables a wide range of post-exchange processing applications and is compatible with a wide range of document creation applications."

A CDA document is a defined and complete information object that can exist outside of a messaging context and/or can be a MIME-encoded payload within an HL7 message; thus, the CDA complements HL7 messaging specifications.

The CDA specification prescribes XML markup for CDA Documents: CDA instances must valid against the CDA Schema and may be subject to additional validation, as described in the conformance section. "There is no prohibition against multiple schema languages (e.g., W3C XML Schema, DTDs, RELAX-NG), as long as conforming XML instances are compatible. The CDA Schema conforms to the HL7 Version 3 Implementation Technology Specification (ITS). This Schema describes the style of XML markup of CDA instances for the purpose of exchange and thus cannot be understood outside the context of this defining specification including the normative R-MIM and Hierarchical Description. Semantic interoperability of CDA instances requires use and knowledge of the CDA Schema, R-MIM and HD as well as the corresponding RIM."

CDA is extensible under the HL7 Version 3 XML Extensibility Rules. It "seeks to standardize the highest level of shared meaning while providing a clean and standard mechanism for tagging meaning that is not shared. In order to support local extensibility requirements, it is permitted to include additional XML elements and attributes that are not included in the CDA schema."

The CDA Release 2.0 distribution includes a prose document in HTML, XML schemas, data dictionary, and sample CDA documents.

Health Level Seven is one of several American National Standards Institute (ANSI)-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Its Version 3 Standard "is built around subject domains, for each of which it provides storyboard descriptions, trigger events, interaction designs, domain object models derived from the Reference Information Model (RIM), hierarchical message descriptors (HMDs) and a prose description of each element. Implementation of these domains further depends upon a nonnormative V3 Guide and normative specifications for: data types; the XML implementable technical specifications (ITS) or message wire format; message and control wrappers; and transport protocols."

The HL7 Structured Documents Technical Committee is producing a "comprehensive architecture to facilitate exchange and processing of electronic healthcare documents. It supports HL7 through education in the development, evolution, and use of structured document specifications."

A Second International Conference on the Clinical Document Architecture (CDA) will be held October 18-19, 2004 in conjunction with the Fifth HL7 International Affiliates Meeting in Acapulco, Mexico. "Building on the success of the first International Conference on the CDA held in Berlin two years ago, the Acapulco meeting will bring together the expanding CDA user base with standards developers, tools designers and researchers for further exploration of this specification for clinical documents." The Keynote Speaker Dr. Naomi Sager will present an address "XML Structuring of Clinical Narrative Using Natural Language Processing."

CDA Introduction and Overview

Key aspects of the CDA include the following: (1) CDA documents are encoded in Extensible Markup Language; (2) CDA documents derive their meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types; (3) The CDA specification is richly expressive and flexible — document-level, section-level and entry-level templates can be used to constrain the generic CDA specification...

A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content...

The HL7 CDA clinical document contains observations and services, and has the following characteristics:

• Persistence: continues to exist in an unaltered state, for a time period defined by local and regulatory requirements
• Stewardship: maintained by an organization entrusted with its care
• Potential for authentication: constitutes an assemblage of information that is intended to be legally authenticated
• Context: establishes the default context for its contents
• Wholeness: authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document
• Human readability: human readable, guarantees that a receiver of a CDA document can algorithmically display the clinical content of the note on a standard Web browser

A CDA document is wrapped by the <ClinicalDocument> element, and contains a header and a body. The header lies between the <ClinicalDocument> and the <StructuredBody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. A CDA document section is wrapped by the <Section> element. Each section can contain a single narrative block and any number of CDA entries and external references. The CDA narrative block is wrapped by the <text> element within the <Section> element, and provides a slot for the human readable content needing to be rendered. Within a document section, the narrative block represents content to be rendered, whereas CDA entries represent structured content provided for a computer. CDA entries encode content present in the narrative block of the same section. CDA external references always occur within the context of a CDA entry, and are wrapped by the <reference> element. External references refer to things that exist outside the CDA document — such as some other image, some other procedure, or some other observation (which is wrapped by the <ExternalObservation> element). The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block.

Example sections include: History of Present Illness, Past Medical History, Medications, Allergies and Adverse Reactions, Family History, Social History, Physical Exam [Vital Signs, Skin, Lungs, Cardiac], Labs, In-office Procedure, Assessment, Plan, etc.

A complete understanding of CDA requires an understanding of the normative artifacts used to define the specification. The CDA Hierarchical Description is the definitive source for CDA conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description. The CDA Hierarchical Description is derived from the CDA R-MIM, which in turn is derived from the HL7 Reference Information Model (RIM). The HL7 RIM is the definitive source for class and attribute definitions. [For example:]

• HL7 Reference Information Model: The HL7 RIM is the definitive reference source for class and attribute definitions. The CDA specification does not exhaustively replicate RIM definitions, but instead refers the reader to the RIM for complete definitions. While CDA may further constrain RIM definitions, at no time will CDA definitions conflict with those in the RIM. CDA, Release Two is derived from HL7 RIM, Version 2.03.

• HL7 V3 Data Types: HL7 defines both an abstract data type specification, which is the definitive reference, and an XML-specific data type representation. Data types define the structural format of the data carried within a RIM attribute and influence the set of allowable values an attribute may assume. Some data types have very little intrinsic semantic content. However HL7 also defines more extensive data types such as the one for an entity's name. Every attribute in the RIM is associated with one and only one data type. CDA, Release Two is based on the HL7 V3 Data Types, Release One abstract and XML-specific specification. A reader will often find that the XML-specific description of a data type is sufficient for implementation, but at times will want to refer to the abstract data type specification for a more comprehensive discussion...

• HL7 Vocabulary Domains: Vocabulary domains represent value sets for coded CDA components. These domains can include HL7-defined concepts or can be drawn from HL7-recognized coding systems such as LOINC or SNOMED. The HL7 Vocabulary chapter is the definitive reference source for the definitions of HL7-defined concepts. While CDA may further constrain these definitions, at no time will CDA definitions conflict with those in the Vocabulary chapter. Vocabulary domains have a coding strength that can be "Coded, No Extensions" (CNE), in which case the only allowable values for the CDA component are those in the vocabulary domain; or "Coded, With Extensions" (CWE), in which case values other than those in the vocabulary domain (such as local codes) can be used if necessary. Every vocabulary domain has a unique HL7-assigned identifier, and every concept within a vocabulary domain has a unique code... A number of vocabulary domains and coding systems already in existence (e.g., LOINC, SNOMED) may be used to encode concepts in CDA documents (e.g., Section.code, Observation.code). These domains are referenced as external domains according to HL7 V3 processes...

• HL7 CDA R-MIM: The CDA R-MIM is a graphical aid to understanding the specification. Because the CDA Hierarchical Description, and subsequently the CDA Schema, are derived from the R-MIM, the R-MIM serves as a good basis for describing the standard. The narrative description of the specific clones used by CDA is organized to correspond with the R-MIM... The R-MIM is a subset of a D-MIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific. The content of an R-MIM is drawn from the D-MIM for the specific domain in which the R-MIM is used. The R-MIM may include clones of selected classes with alias names specific to the perspective of the message(s) to be derived. The R-MIM represents the information content for one or more abstract message structures, also called Hierarchal Message Definitions (HMDs)...

• HL7 CDA Hierarchical Description: In simplest terms, an HMD is a tabular representation of the sequence of elements (i.e., classes, attributes and associations) represented in an R-MIM and that define the message without reference to the implementation technology. The HMD defines a single base message structure — the 'common' message type. This base message structure is never sent and thus has no corresponding trigger event. It is the template from which the other specific and corresponding message types are drawn. The RoseTree tool therefore requires that a specific HMD is identified in order that an appropriate HMD can be output and an XML schema produced. The HMD and its contained message types may be downloaded as an Excel spreadsheet and a sample XML Example is also available... The CDA HD is the definitive source for CDA conformance rules, and serves as the source from which the CDA Schema is derived. While a CDA instance must validate against the CDA Schema, it must also adhere to the conformance rules stated in the CDA Hierarchical Description.

• HL7 CDA Schema: The definitive description of HL7 XML Implementation Technology Specification and the process used to go from Hierarchical Description to Schema is [available online]. CDA, Release Two is based on the HL7 V3 XML Implementable Technology Specification for V3 Structures, Release One. Specific enhancements to the CDA Schema, above and beyond those defined in the HL7 V3 XML ITS, are described below in CDA Schema Section 2.5 Looking at the CDA R-MIM, a reader can typically identify the corresponding XML elements and attributes..." [adapted from the Release 2.0 balloted version 2004-08]