Consolidated CDA (C-CDA)

C-CDA documents organize clinical data into a header and a structured body. The body is composed of recursively nested sections that contain machine-readable entries.

• Header: Contains document metadata (author, patient, custodian) and a universal setId for version management.
• Sections: Constrained by specific templates (e.g., Allergies, Medications, Vital Signs) that dictate which entries are allowed.
• Narrative Block: Every section must include a human-readable narrative block, ensuring the document is legally valid even without parsing the structured entries.

The core of C-CDA's semantic power lies in its Clinical Statement pattern, a derivative of the HL7 Reference Information Model (RIM). This model links an Act (what was done) to its context.

• Act Classes: Observation, Procedure, SubstanceAdministration, Supply, and Encounter.
• Act Relationships: Entries are linked via entryRelationship elements to express cause, component, or justification.
• Temporal Expressions: The effectiveTime element uses precise timestamps or intervals to anchor clinical facts on a timeline.

C-CDA harmonizes multiple legacy implementation guides into a single standard with specific document-level templates for common exchange scenarios.

• Continuity of Care Document (CCD): A summary of a patient's most relevant clinical data, used for transitions of care.
• Consultation Note: Generated by a consulting provider, summarizing their findings and recommendations.
• Discharge Summary: A comprehensive summary of a hospitalization episode.
• Progress Note: Captures a patient's clinical status during an encounter.
• Diagnostic Imaging Report: Structures radiology findings and associated image references.

Semantic interoperability is enforced by binding coded elements to specific value sets drawn from standard terminologies. This eliminates local code ambiguity.

• SNOMED CT: Used for problems, procedures, and clinical findings.
• LOINC: Mandated for lab results, vital signs, and document type identification.
• RxNorm: The required vocabulary for encoding medications.
• UCUM: The standard for units of measure in physical quantity observations.
• HL7 AdministrativeGender: Constrains the gender code to a specific, narrow value set.

C-CDA defines two levels of conformance rigidity to balance standardization with implementation flexibility.

• Open Templates: Allow implementers to include additional elements beyond those defined in the specification, as long as the required core constraints are met. This supports local customization.
• Closed Templates: Prohibit any data not explicitly defined in the template. This is used for high-stakes, tightly regulated data elements where absolute consistency is required, such as quality reporting measures.

The United States Core Data for Interoperability (USCDI) standard defines a mandatory baseline of data classes that certified health IT must be able to exchange via C-CDA.

• USCDI v1: Established foundational classes like Allergies, Medications, and Problems.
• USCDI v2+: Expanded to include Social Determinants of Health (SDOH), sexual orientation, and gender identity.
• Provenance: Requires capturing the author, timestamp, and source system for every discrete data element.

The legacy pipe-and-hat delimited messaging standard that remains the dominant format for in-hospital ADT, ORM, and ORU transactions. While C-CDA handles document-level exchange, HL7 v2 handles transactional event streams. Interface engines frequently translate between v2 messages and C-CDA documents, mapping v2 segments like PID and OBR to CDA header and body structures.

A modern RESTful API standard that is gradually supplanting C-CDA for point-to-point data queries. FHIR's Composition and Bundle resources serve as the JSON/XML equivalents of CDA documents. The US Core Implementation Guide defines FHIR profiles that map directly to C-CDA data elements, enabling bidirectional transforms between the two formats for Meaningful Use compliance.

The highest level of interoperability where systems share clinically meaningful data with unambiguous interpretation. C-CDA achieves this through mandated value sets and terminology bindings:

• SNOMED CT for problems and procedures
• LOINC for lab results and document types
• RxNorm for medications
• UCUM for units of measure Without these bindings, a C-CDA is merely syntactic XML.

The documented lineage and lifecycle of clinical data tracking its origins, transformations, and movements. C-CDA embeds provenance in the header via:

• author and dataEnterer elements identifying who created the content
• legalAuthenticator for legally binding attestation
• custodian identifying the organization maintaining the document
• relatedDocument linking parent/replacement documents This audit trail is critical for medico-legal integrity.

An international initiative defining integration profiles that constrain how standards like C-CDA are used in specific clinical workflows. Key profiles include:

• XDS.b: Cross-enterprise document sharing registry/repository
• XDR: Point-to-point document push using CDA content
• XDM: Media-based exchange (USB, email) of CDA documents
• XPHR: Patient health record exchange These profiles resolve ambiguities in base C-CDA specifications.

Deterministic and probabilistic logic systems that verify the accuracy and completeness of C-CDA content. Validation occurs at multiple levels:

• Schema validation: XML structure conformance
• Schematron rules: Business logic constraints (e.g., 'a problem must have a code')
• Terminology validation: Codes must exist in the bound value set
• Clinical consistency: Discharge date must be after admission date ONC certification requires passing the C-CDA Validator tool.