1 Einleitung

Die elektronische Kommunikation im Gesundheitswesen hat sich in den letzten zwei Jahrzehnten stark verändert. Einer der frühesten XML-basierten Standards war die HL7 Clinical Document Architecture (CDA): ein auf Dokumente fokussiertes Austauschformat für klinische Inhalte wie Arztbriefe, Entlassungsberichte oder Befunddokumente.

Heute dominiert in vielen Digitalisierungsinitiativen jedoch HL7 FHIR mit seinem API- und Ressourcenkonzept. Das wirft Fragen auf: Welche Rolle spielt CDA noch in modernen Architekturen? Wie unterscheidet sich der Dokumentenansatz von FHIRs Ressourcendenken? Und wo ergänzen sich beide Standards sinnvoll, statt miteinander zu konkurrieren?

Dieser Beitrag beleuchtet CDA in seinen Facetten und ordnet es im Verhältnis zu modernen FHIR-Ansätzen ein – technisch, semantisch und strategisch.

2 Was ist HL7 CDA?

2.1 Ziele und Grundprinzipien

Die Clinical Document Architecture (CDA) ist ein XML-basierter HL7-Standard zur Spezifikation von Struktur und Semantik klinischer Dokumente für den Austausch. Ein CDA-Dokument repräsentiert genau ein klinisches Dokument (z. B. Arztbrief, Befundbericht), nicht eine ganze Patientenakte.

CDA verfolgt sechs zentrale Eigenschaften klinischer Dokumentation:

• Persistenz – Dokumente sind dauerhaft und werden nicht „flüchtig“ überschrieben.
• Stewardship – klare Verantwortlichkeit (Autor, Ersteller, verwaltende Organisation).
• Potenzial für Authentifizierung – signierbare, rechtsverbindliche Dokumente.
• Kontext – Einbettung in Zeit, Ort, Versorgungsfall, beteiligte Akteure.
• Ganzheitlichkeit (Wholeness) – ein Dokument ist eine in sich geschlossene Einheit.
• Lesbarkeit durch Menschen – narrative Inhalte sind immer enthalten.

Damit adressiert CDA vor allem die Mensch-zu-Mensch-Kommunikation (z. B. Arzt↔Arzt, Arzt↔Pflege), mit der Option, in Teilen auch maschinenverarbeitbare Strukturen zu hinterlegen.

2.2 Aufbau: Header, Body und Ebenen

Ein CDA-Dokument besteht aus zwei Hauptkomponenten:

• Header: Metadaten zum Dokument – Patient, Autoren, Empfänger, Dokumenttyp, Zeitpunkt, Versorgungszusammenhang.
• Body: eigentlicher Inhalt, gegliedert in Sections (z. B. Anamnese, Diagnosen, Medikation). Enthält narrative Texte, optional ergänzt durch strukturierte Einträge.

CDA kennt zudem drei Levels mit zunehmender Strukturierung:

• Level 1: Schwerpunkt auf Formatierung und Layout von Freitext; Inhalte sind im Wesentlichen nicht computable.
• Level 2: strukturierte Gliederung in standardisierte Dokumenttypen und Sections; Inhalte werden mit Codesystemen klassifiziert.
• Level 3: feingranulare, maschinenlesbare Einträge auf Basis von HL7 v3 Datentypen.

Allen Levels gemeinsam: der narrative Block hat Vorrang – er ist die rechtlich maßgebliche Sicht; strukturierte Daten sind ergänzend.

2.3 Templates und Implementierungsleitfäden

In der Praxis wird CDA selten „roh“ verwendet. Stattdessen definieren Implementierungsleitfäden auf Basis von Templates konkrete Dokumentprofile. Beispiele:

• C-CDA (Consolidated CDA) in den USA als Sammlung harmonisierter Templates für Entlassungsbriefe, Arztbriefe, Medikationspläne usw.
• nationale Anpassungen im deutschsprachigen Raum, bei denen Befunde oder Arztbriefe auf CDA-Basis spezifiziert werden.

Templates schränken die generelle CDA-Spezifikation ein (z. B. Pflichtfelder, erlaubte Codesysteme), sodass interoperable Dokumenttypen entstehen.

3 HL7 CDA in der Praxis: Stärken und Grenzen

3.1 Typische Einsatzgebiete

CDA wird weltweit nach wie vor millionenfach täglich eingesetzt, vor allem für:

• Arztbriefe und Entlassbriefe,
• Befundberichte (Radiologie, Labor),
• Patientenübersichten / Summaries,
• dokumentengetriebene IHE-Szenarien (z. B. XDS-Infrastrukturen).

Die Dokumentzentrierung passt gut zu rechtlichen Anforderungen (Nachvollziehbarkeit, Signatur, Archivierung) und zur Arbeitsweise im klinischen Alltag (Arztbrief als „Goldstandard“ der Kommunikation).

3.2 Stärken

• Reife und Verbreitung: CDA ist ein ausgereifter Standard mit breiter Implementationsbasis.
• Fokus auf klinische Dokumente: sehr gut geeignet für abgeschlossene Kommunikationseinheiten mit Unterschrift und Archivierung.
• Human Readability by Design: narrative Inhalte sind integraler Bestandteil, nicht optional.
• Flexibler Detaillierungsgrad: von fast „PDF-in-XML“ (Level 1) bis hin zu hochgranularen, kodierten Einträgen (Level 3).

3.3 Grenzen

• Schwergewichtige XML-Struktur: CDA-Dokumente sind vergleichsweise umfangreich und komplex; moderne Web-Ökosysteme sind eher JSON- und API-zentriert.
• Grobe Granularität: Ein Dokument ist eine große Einheit – für Echtzeit-Interaktionen (z. B. Abfrage eines einzelnen Medikations-Eintrags) ist das unpraktisch.
• Komplexe Templates: C-CDA und nationale Leitfäden sind mächtig, aber für Entwicklerinnen und Entwickler nicht leicht zugänglich.

Damit ist CDA stark für dokumentorientierte Workflows geeignet, weniger für feingranulare, serviceorientierte Architekturen.

4 HL7 CDA und HL7 FHIR – unterschiedliche, aber verwandte Ansätze

4.1 Paradigma: Dokument vs. Ressource/API

HL7 FHIR ist ein Ressourcen- und API-basierter Standard, der Daten in kleinere, wiederverwendbare Bausteine zerlegt (z. B. Patient, Observation, Condition, MedicationStatement) und sie über RESTful Services oder andere Austauschmechanismen zugänglich macht.

Die wichtigsten Unterschiede im Paradigma:

• CDA: dokumentzentriert, XML-basiert, primär für Mensch-zu-Mensch-Kommunikation, Austausch in dokumentenorientierten Workflows.
• FHIR: ressourcenorientiert, JSON/XML/NDJSON, stark web- und API-orientiert, sowohl dokumentartige Bundles als auch feingranulare Abfragen möglich.

HL7 selbst beschreibt CDA und FHIR als komplementäre Standardfamilien: FHIR kann sowohl CDA-ähnliche Dokumente modellieren als auch vollständig neue, API-basierte Szenarien ermöglichen.

4.2 Semantik: Templates vs. Profile

Semantische Festlegung erfolgt bei beiden Standards über Spezialisierungsmechanismen – aber mit unterschiedlichem Vokabular:

• CDA-Templates definieren konkrete Dokumenttypen und schränken die generische Spezifikation ein.
• FHIR-Profile legen fest, wie Ressourcen in konkreten Use Cases verwendet werden (StructureDefinitions, ValueSets, CodeSystems).

Inhaltlich geht es in beiden Fällen um Pflichtfelder, Kodiersysteme, Kardinalitäten, erlaubte Wertebereiche und Referenzen. Für Organisationen, die aus einer CDA-Welt in eine FHIR-Welt migrieren, ist wichtig zu verstehen: Viele in C-CDA vorhandene semantische Festlegungen lassen sich konzeptionell in FHIR-Profile und Composition-Strukturen überführen.

4.3 Koexistenz und Migration: CDA ↔ FHIR

In der Praxis werden CDA und FHIR auf absehbare Zeit nebeneinander existieren. Typische Muster sind:

1. Bestandswelt (CDA) + neue FHIR-Schnittstellen: vorhandene CDA-Dokumente bleiben im Einsatz und werden archiviert, während neue Anwendungen (Portale, Apps, Gateways) über FHIR auf Daten zugreifen.
2. Konvertierung CDA → FHIR: CDA-Dokumente werden in FHIR-Strukturen transformiert, um sie feingranular auswerten zu können (Analytik, Entscheidungsunterstützung, Register).
3. FHIR als „neue CDA-Schicht“: FHIR bildet im Backend den Primärdatenspeicher; für rechtlich relevante Kommunikation werden daraus FHIR-basierte Dokumente generiert, die funktional CDA-Dokumenten entsprechen.

Strategisch stellt sich weniger die Frage „CDA oder FHIR?“, sondern eher: Wo brauche ich weiterhin dokumentzentrierte, rechtlich robuste Kommunikation – und wo brauche ich flexible, API-basierte Zugriffe auf Daten?

5 Fazit: CDA als stabile Säule im Übergang zur FHIR-Welt

HL7 CDA bleibt trotz des FHIR-Booms relevant:

• als normativ stabiler, etablierter Dokumentenstandard mit hoher Verbreitung in produktiven Systemen,
• als Antwort auf Anforderungen, bei denen Dokumente als abgeschlossene, signierbare, archivierbare Einheiten im Zentrum stehen,
• als Basis zahlreicher Implementierungsleitfäden für Arztbriefe, Befunde und Summaries.

Gleichzeitig bietet FHIR ein moderneres, entwicklerfreundliches API-Paradigma, feingranulare Zugriffe auf Gesundheitsdaten und eine bessere Integration in Cloud-, App- und Microservice-Landschaften.

Die sinnvollste Perspektive ist daher nicht „CDA vs. FHIR“, sondern:

• CDA als robuste Dokumenten- und Archivschicht,
• FHIR als flexible Integrations-, Analyse- und Interaktionsschicht,
• verbunden durch klar definierte Mappings und Transformationspfade (CDA ↔ FHIR).

Für Architektur- und Standardisierungsentscheidungen bedeutet das: Bestehende CDA-Infrastrukturen sollten nicht vorschnell ersetzt, sondern gezielt eingebettet werden. Neue Projekte sollten FHIR-native denken, aber CDA-Dokumente weiterhin als Teil des Gesamtökosystems berücksichtigen – insbesondere dort, wo rechtliche Anforderungen und etablierte Workflows es erfordern.