Clinical Document Architecture (CDA)

A foundational requirement of CDA is that every document must be renderable as human-readable text using a standard web browser while simultaneously being structured for machine processing. This is achieved by embedding the narrative text block within a <text> element and linking it to formal, coded entries in the <entry> block. This design ensures a clinician can always read the document natively, while a decision support system can parse the structured data for automated checks.

All CDA documents derive their semantic structure from the HL7 V3 Reference Information Model (RIM), an object-oriented, domain-agnostic model of healthcare data. Key RIM classes used in CDA include:

• Act: Represents clinical actions like observations, procedures, and substance administrations.
• Entity: Represents physical things and beings, such as people, organizations, and devices.
• Role: Defines the capacity in which an Entity participates in an Act (e.g., a person as a 'patient' or 'provider').
• Participation: The association between a Role and an Act, contextualizing the involvement. This formal grounding ensures consistent semantics across all CDA implementations.

CDA defines a graduated hierarchy of machine-processability to accommodate varying levels of implementation maturity:

• Level 1 (Unconstrained): Only the CDA Header is fully coded. The document body is a single, unstructured narrative blob. This is the simplest to generate but offers minimal semantic interoperability.
• Level 2 (Section-Level Templates): The document body is divided into coded sections (e.g., 'Allergies', 'Medications'), each containing a narrative block. Structure is enforced, but content within sections is not formally coded.
• Level 3 (Fully Coded Entries): The narrative in each section is linked to machine-readable, coded clinical statements (entries) that can be processed by a computer. This level enables true semantic interoperability for clinical decision support and automated data aggregation.

A CDA document is defined by six key characteristics that distinguish it from a simple message or dataset:

• Persistence: The document continues to exist in an unaltered state for a time period defined by regulatory and clinical needs.
• Stewardship: A designated organization is responsible for the document's maintenance and integrity.
• Context: The document establishes its own clinical, temporal, and legal context, including the author, authenticator, encounter, and patient.
• Wholeness: The document is a complete, legally authenticated whole, not a partial update.
• Human Readability: As a core principle, it must be viewable by a clinician.
• Potential for Authentication: It must be capable of receiving a legally binding digital signature.

For Level 3 documents, the coded entries within a section are expressed using the Clinical Statement (CS) pattern, a specialized refinement of the RIM. A Clinical Statement is a complete, contextualized clinical assertion. Its core components include:

• Act: The clinical action itself (e.g., a diagnosis, a dispensed medication).
• Subject (Patient): The person who is the subject of the clinical action.
• Author: The clinician responsible for the statement.
• Informant: The source of the information.
• Performer: The entity carrying out the act (e.g., a lab performing a test). This pattern allows for unambiguous representation of complex clinical concepts like 'a known allergy to Penicillin, first observed on a specific date.'

The CDA Header provides a consistent, coded metadata envelope that is critical for document exchange and management, independent of the body's content. It identifies:

• Document ID and Type: A unique identifier and a LOINC code specifying the kind of document (e.g., 18842-5 for a Discharge Summary).
• Patient: The subject of care, identified by a demographic identifier.
• Author and Authenticator: The people and/or devices that created and legally signed the document.
• Custodian: The organization responsible for the document's stewardship.
• Encounter Data: Linking the document to a specific patient visit or episode of care. This header enables a Document Registry to index, query, and retrieve documents without parsing the clinical body.

The process of transforming legacy HL7 v2 pipe-delimited messages into structured CDA documents. Key challenges include:

• Mapping OBX segments (observation results) to CDA structured body entries
• Reconciling MSH header fields with CDA header metadata
• Handling custom Z-segments that lack standardized CDA equivalents

This bridging is critical for organizations migrating from legacy integration engines to document-based interoperability.

The automated process of verifying that a CDA document conforms to its XSD (XML Schema Definition). Validation checks include:

• Required element presence (e.g., ClinicalDocument/id)
• Correct data types (e.g., TS timestamps, PQ physical quantities)
• Cardinality constraints (e.g., exactly one recordTarget)

Schema validation is the first gate in document processing pipelines, catching structural errors before semantic or clinical validation occurs.

A query language used to navigate and extract data from CDA's hierarchical XML structure. Common extraction patterns include:

• //ClinicalDocument/recordTarget/patientRole/id/@extension for patient MRN
• //section[code/@code='10164-2']/text for History of Present Illness
• //entry/observation/code/@code for coded clinical findings

XPath is the workhorse of CDA parsing engines, enabling precise data extraction without full document deserialization.

The specification of mandatory code systems for CDA elements to ensure semantic interoperability. Critical bindings include:

• LOINC for document types and section codes (e.g., 11488-4 for Consultation Note)
• SNOMED CT for clinical findings and procedures
• RxNorm for medication entries

Without consistent vocabulary binding, two CDA documents describing the same clinical concept may use incompatible codes, breaking automated processing.