Taction Software®
Healthcare IT Glossary

What is CDA?
Clinical Document Architecture

Healthcare generates enormous volumes of clinical documents — discharge summaries, progress notes, referral letters, operative reports, consultation notes. For decades, these documents existed as unstructured text, PDFs, or scanned images that couldn’t be read by other systems. CDA solved that by defining a standard way to structure clinical documents so they’re both human-readable and machine-processable.

Certifications

Tell Us Your Requirements

Our experts are ready to understand your business goals.

What is 1 + 1 ?

100% confidential & no spam

Definition of CDAHow CDA Works in HealthcareKey CDA Standards and SpecificationsImplementation ConsiderationsHow Taction Helps with CDA

Definition of CDA

CDA, which stands for Clinical Document Architecture, is an XML-based markup standard developed by HL7 International for the exchange of clinical documents. It defines both the structure and the semantics of a clinical document — specifying how content is organized, what metadata is attached, and how coded clinical data is embedded within the document body.

A CDA document has a header and a body. The header contains metadata — patient identification, author, document type, encounter information, custodian organization, and participants. The body contains the clinical narrative — the actual medical content organized into sections like “History of Present Illness,” “Medications,” “Assessment and Plan,” and “Discharge Instructions.”

What makes CDA powerful is its dual nature: every CDA document is simultaneously a human-readable clinical document (viewable in a browser or document viewer using an XSLT stylesheet) and a machine-readable data structure (parseable by systems that understand the XML schema and coded entries within it).

CDA is built on the HL7 Version 3 Reference Information Model (RIM), which gives it a rigorous semantic foundation. While HL7v3 itself saw limited adoption for messaging, CDA became one of its most successful derivatives — widely deployed for document exchange in the U.S. and internationally.

In simple terms: CDA is the HL7 standard that turns clinical documents into structured, shareable XML files that both humans and computers can understand.

How CDA Works in Healthcare

CDA documents flow between healthcare systems whenever clinical narratives need to be shared — during care transitions, referrals, hospital discharges, and public health reporting.

Here’s how CDA operates in real-world workflows:

The typical transmission path: an EHR generates a CDA document → the document passes through an integration engine or HIE → the receiving system validates and parses the document → structured data elements are imported into the receiving EHR → the clinical narrative is available for provider review.

Discharge summaries
When a patient is discharged from a hospital, the EHR system generates a CDA-formatted discharge summary containing the admission diagnosis, procedures performed, medications at discharge, follow-up instructions, and attending physician details. This document is transmitted to the patient’s primary care provider through a health information exchange (HIE) or direct messaging.
Referral and consultation notes
When a primary care physician refers a patient to a specialist, the referral letter and relevant clinical history can be packaged as a CDA document. The specialist’s system receives it, parses the structured data (medications, allergies, problem list), and imports relevant elements into their own EMR.
Care transitions
The Transitions of Care (ToC) workflow is one of CDA’s primary use cases. When a patient moves between settings — hospital to skilled nursing, ED to primary care, inpatient to outpatient — a CDA document carries the continuity-of-care information that the receiving provider needs.
Public health reporting
CDA is used for reporting to public health agencies — immunization records, case reports, and quality measure data can be structured as CDA documents for submission to registries and surveillance systems.
Patient access
Under ONC rules, patients have the right to receive their health information in a CDA-based format. Patient portals and personal health record applications consume CDA documents to display clinical summaries to patients.

Key CDA Standards and Specifications

CDA is not a single monolithic spec — it’s a framework with multiple levels and implementation guides:

Modern
CDA R2 (Release 2)
The current production standard, CDA Release 2, has been in use since 2005. It defines three levels of conformance: Level 1 (unrestricted body content — essentially free text in XML), Level 2 (section-level markup with LOINC section codes), and Level 3 (fully coded entries within sections, enabling granular machine processing). Most meaningful implementations target Level 2 or Level 3.
Modern
C-CDA (Consolidated CDA)
The most important CDA implementation guide in U.S. healthcare. C-CDA consolidates multiple earlier CDA templates into a single, harmonized set of document types — including Continuity of Care Document (CCD), Discharge Summary, Referral Note, Progress Note, History and Physical, and Consultation Note. C-CDA is mandated by ONC for certified EHR technology and is the document format used for Meaningful Use / Promoting Interoperability clinical document exchange.
Legacy
LOINC Section Codes
CDA documents use LOINC codes to identify document sections. For example, LOINC code 11348-0 identifies the “History of Past Illness” section, while 10160-0 identifies the “Medications” section. These standardized codes allow receiving systems to locate specific clinical content within a document programmatically.
Legacy
SNOMED CT and ICD-10 for Coded Entries
Within CDA Level 3 sections, individual clinical observations and diagnoses are encoded using terminology standards like SNOMED CT for clinical findings and ICD-10 for diagnoses. This coded data is what makes CDA documents machine-actionable — a receiving system can extract discrete medication lists, problem lists, and allergy data from a CDA document without natural language processing.
Legacy
CDA and FHIR
While CDA remains the dominant standard for clinical document exchange today, FHIR is increasingly used for real-time data access rather than document-based exchange. The FHIR DocumentReference resource can encapsulate CDA documents, and the FHIR Composition resource provides a FHIR-native alternative to CDA for some use cases. Organizations are increasingly building hybrid architectures — CDA for document exchange, FHIR APIs for granular data access.
Building an CDA integration? Let’s talk.
Book a free call

Implementation Considerations

CDA implementation requires careful attention to template conformance, vocabulary binding, and integration architecture.

Template compliance is critical
CDA documents that don’t conform to the applicable C-CDA template specifications will be rejected by receiving systems, HIEs, and certification testing tools. Every section, entry, and coded element must follow the template’s cardinality, vocabulary binding, and nullFlavor rules. This is not a “close enough” standard — validation failures mean broken interoperability.
Vocabulary mapping is complex
CDA documents require coded data using SNOMED CT, LOINC, ICD-10, RxNorm (for medications), and CVX (for immunizations). If your source system stores clinical data using proprietary codes or free text, you need a vocabulary mapping and data management layer to translate into standard terminologies before generating CDA documents.
Stylesheet rendering matters
CDA documents are XML — not directly human-readable without an XSLT stylesheet. The quality of the stylesheet determines whether clinicians see a clean, well-organized document or a jumbled mess of raw data. Many organizations underinvest in stylesheet development, which degrades the clinical user experience.
Integration engine configuration
CDA documents are typically generated, validated, transformed, and routed through an integration engine like Mirth Connect. The engine handles outbound CDA generation from EHR data, inbound CDA parsing into discrete data elements, and routing to HIEs and external partners. Proper channel configuration, error handling, and logging are essential for production reliability.
Validation and testing tools
Before deploying CDA interfaces, use validation tools like the HL7 CDA Validator, Drummond Group’s testing platform, or NIST’s C-CDA validation tools to verify template conformance. Automated validation should be part of your CI/CD pipeline for any CDA-generating system.
Security and
HIPAA compliance. CDA documents contain extensive PHI — patient names, diagnoses, medications, provider information. All CDA document storage, transmission, and access must meet HIPAA Security Rule requirements including encryption, access controls, and audit logging.

How Taction Helps with CDA

At Taction, our integration team has deep experience building CDA generation, parsing, and exchange capabilities for healthcare organizations — from EHR vendors embedding CDA support in their products to health systems connecting to state and regional HIEs.

What we do:

Whether you’re building CDA capabilities into a new product, connecting to an HIE for the first time, or migrating from CDA to FHIR, our team delivers the healthcare software engineering precision these integrations demand.

CDA document generation
We build CDA generation pipelines that extract structured data from EHR and clinical systems and produce fully conformant C-CDA documents for discharge summaries, referral notes, care transitions, and quality reporting.
CDA parsing and data import
We build inbound CDA processing that parses received documents, extracts discrete clinical data (medications, allergies, problems, procedures), and imports it into your EHR or clinical data repository.
C-CDA template validation
We implement automated validation pipelines that check every outbound CDA document against C-CDA template specifications before transmission — catching conformance errors before they reach a trading partner.
HIE connectivity
We connect healthcare organizations to state and regional health information exchanges using CDA-based document exchange, Direct messaging, and IHE profiles.
CDA-to-FHIR bridging
For organizations transitioning toward FHIR-based workflows, we build bridge layers that convert CDA documents into FHIR resources and vice versa — maintaining backward compatibility while enabling modern API-based architectures.

Explore Related Terms

What is DICOM?What is ADT?What is MPI?What is Bulk FHIR?What is API Gateway?

Ready to discuss your CDA project?

Schedule a free call

Ready to Discuss Your Project With Us?

Your email address will not be published. Required fields are marked *

What is 1 + 1 ?

What's Next?

Our expert reaches out shortly after receiving your request and analyzing your requirements.

If needed, we sign an NDA to protect your privacy.

We request additional information to better understand and analyze your project.

We schedule a call to discuss your project, goals. and priorities, and provide preliminary feedback.

If you're satisfied, we finalize the agreement and start your project.