HL7 CDA in the light of modern FHIR approaches – positioning, facets, and interplay

1 Introduction

Electronic communication in healthcare has changed significantly over the past two decades. One of the earliest XML-based standards was the HL7 Clinical Document Architecture (CDA): a document-focused exchange format for clinical content such as physician letters, discharge summaries, or diagnostic documents.

Today, however, HL7 FHIR dominates many digitalization initiatives with its API and resource concept. This raises questions: What role does CDA still play in modern architectures? How does the document approach differ from FHIR’s resource thinking? And where do both standards complement each other meaningfully, instead of competing with one another?

This article examines CDA in its facets and positions it in relation to modern FHIR approaches—technically, semantically, and strategically.

2 What is HL7 CDA?

2.1 Goals and basic principles

Clinical Document Architecture (CDA) is an XML-based HL7 standard for specifying the structure and semantics of clinical documents for exchange. A CDA document represents exactly one clinical document (e.g., physician letter, diagnostic report), not an entire patient record.

CDA follows six key characteristics of clinical documentation:

• Persistence – documents are permanent and are not “transiently” overwritten.
• Stewardship – clear accountability (author, creator, managing organization).
• Potential for authentication – signable, legally binding documents.
• Context – embedding in time, place, episode of care, involved actors.
• Wholeness – a document is a self-contained unit.
• Human readability – narrative content is always included.

Thus, CDA primarily addresses human-to-human communication (e.g., physician↔physician, physician↔nursing), with the option of also including machine-processable structures in parts.

2.2 Structure: header, body, and levels

A CDA document consists of two main components:

• Header: metadata about the document – patient, authors, recipients, document type, timestamp, care context.
• Body: the actual content, structured into sections (e.g., history, diagnoses, medication). Contains narrative texts, optionally supplemented by structured entries.

CDA also defines three levels with increasing structuring:

• Level 1: focus on formatting and layout of free text; content is essentially not computable.
• Level 2: structured organization into standardized document types and sections; content is classified with code systems.
• Level 3: fine-grained, machine-readable entries based on HL7 v3 data types.

Common to all levels: the narrative block takes precedence—it is the legally authoritative view; structured data is supplementary.

2.3 Templates and implementation guides

In practice, CDA is rarely used “raw”. Instead, implementation guides define concrete document profiles based on templates. Examples:

• C-CDA (Consolidated CDA) in the USA as a collection of harmonized templates for discharge summaries, physician letters, medication lists, etc.
• national adaptations in German-speaking countries, where findings or physician letters are specified on a CDA basis.

Templates constrain the general CDA specification (e.g., required fields, permitted code systems), resulting in interoperable document types.

3 HL7 CDA in practice: strengths and limitations

3.1 Typical areas of use

CDA is still used worldwide millions of times daily, especially for:

• physician letters and discharge letters,
• diagnostic reports (radiology, laboratory),
• patient overviews / summaries,
• document-driven IHE scenarios (e.g., XDS infrastructures).

The document-centered approach fits well with legal requirements (traceability, signature, archiving) and with working methods in everyday clinical practice (the physician letter as the “gold standard” of communication).

3.2 Strengths

• Maturity and adoption: CDA is a mature standard with a broad implementation base.
• Focus on clinical documents: very well suited for completed communication units with signature and archiving.
• Human readability by design: narrative content is an integral part, not optional.
• Flexible level of detail: from almost “PDF-in-XML” (Level 1) through to highly granular, coded entries (Level 3).

3.3 Limitations

• Heavyweight XML structure: CDA documents are comparatively extensive and complex; modern web ecosystems tend to be JSON- and API-centered.
• Coarse granularity: a document is a large unit—for real-time interactions (e.g., querying a single medication entry) this is impractical.
• Complex templates: C-CDA and national guides are powerful, but not easily accessible for developers.

Thus, CDA is strong for document-oriented workflows, and less suited for fine-grained, service-oriented architectures.

4 HL7 CDA and HL7 FHIR – different, but related approaches

4.1 Paradigm: document vs. resource/API

HL7 FHIR is a resource- and API-based standard that breaks data down into smaller, reusable building blocks (e.g., Patient, Observation, Condition, MedicationStatement) and makes them accessible via RESTful services or other exchange mechanisms.

The most important differences in paradigm:

• CDA: document-centered, XML-based, primarily for human-to-human communication, exchange in document-oriented workflows.
• FHIR: resource-oriented, JSON/XML/NDJSON, strongly web- and API-oriented, both document-like bundles and fine-grained queries are possible.

HL7 itself describes CDA and FHIR as complementary standard families: FHIR can model both CDA-like documents and enable completely new, API-based scenarios.

4.2 Semantics: templates vs. profiles

Semantic constraints are implemented in both standards via specialization mechanisms—but with different vocabulary:

• CDA templates define concrete document types and constrain the generic specification.
• FHIR profiles specify how resources are used in specific use cases (StructureDefinitions, ValueSets, CodeSystems).

In terms of content, both are about required fields, coding systems, cardinalities, permitted value ranges, and references. For organizations migrating from a CDA world to a FHIR world, it is important to understand: Many semantic constraints present in C-CDA can conceptually be transferred into FHIR profiles and Composition structures.

4.3 Coexistence and migration: CDA ↔ FHIR

In practice, CDA and FHIR will coexist side by side for the foreseeable future. Typical patterns are:

1. Existing landscape (CDA) + new FHIR interfaces: existing CDA documents remain in use and are archived, while new applications (portals, apps, gateways) access data via FHIR.
2. Conversion CDA → FHIR: CDA documents are transformed into FHIR structures to enable fine-grained analysis (analytics, decision support, registries).
3. FHIR as the “new CDA layer”: FHIR forms the primary data store in the backend; for legally relevant communication, FHIR-based documents are generated from it that functionally correspond to CDA documents.

Strategically, the question is less “CDA or FHIR?”, and more: Where do I still need document-centered, legally robust communication—and where do I need flexible, API-based access to data?

5 Conclusion: CDA as a stable pillar in the transition to the FHIR world

HL7 CDA remains relevant despite the FHIR boom:

• as a normatively stable, established document standard with wide adoption in production systems,
• as an answer to requirements where documents as completed, signable, archivable units are central,
• as the basis of numerous implementation guides for physician letters, findings, and summaries.

At the same time, FHIR offers a more modern, developer-friendly API paradigm, fine-grained access to health data, and better integration into cloud, app, and microservice landscapes.

The most sensible perspective is therefore not “CDA vs. FHIR”, but:

• CDA as a robust document and archiving layer,
• FHIR as a flexible integration, analytics, and interaction layer,
• connected via clearly defined mappings and transformation paths (CDA ↔ FHIR).

For architecture and standardization decisions, this means: Existing CDA infrastructures should not be replaced prematurely, but embedded in a targeted way. New projects should think FHIR-native, but continue to consider CDA documents as part of the overall ecosystem—especially where legal requirements and established workflows require it.