Kurze Antwort: Die Clinical Document Architecture (CDA) ist der Standard von HL7 für klinische Dokumente: Entlassungsbriefe, Überweisungsschreiben, Konsultationsnotizen, Patientenübersichten. Ein CDA-Dokument ist eine XML-Datei mit einem Header (wer, wann, über wen) und einem Body aus Abschnitten, die jeweils eine für Menschen lesbare Erzählung und optional maschinenlesbare, kodierte Einträge enthalten. C-CDA (Consolidated CDA) ist der US-Implementierungsleitfaden, der die Vorlagen für die gängigsten Dokumenttypen festlegt; das CCD (Continuity of Care Document) ist sein bekanntestes Mitglied. CDA Release 2 stammt aus dem Jahr 2005 und ist in mehreren nationalen und grenzüberschreitenden Programmen immer noch vorgeschrieben.
Wie ein Dokument aussieht
Ein CDA-Dokument ist eine XML-Datei mit einem ClinicalDocument-Root-Element. Dieses enthält einen Header (mit dem Dokumententyp als LOINC-Code, Template-ID-OIDs, einer ID, dem Gültigkeitszeitpunkt, einem Vertraulichkeits-Code, Patienteninformationen, Autor und Custodian) und einen Body mit Abschnitten. Jeder Abschnitt hat einen LOINC-Code, ein obligatorisches, für Menschen lesbares Textelement und optionale kodierte Einträge, die von Software gelesen werden können.
<ClinicalDocument xmlns="urn:hl7-org:v3">
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<templateId root="2.16.840.1.113883.10.20.22.1.2" extension="2015-08-01"/>
<id root="2.16.840.1.113883.19.5" extension="DOC-2026-0314"/>
<code code="34133-9" codeSystem="2.16.840.1.113883.6.1" displayName="Summarization of Episode Note"/>
<effectiveTime value="20260314101500+0100"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<recordTarget><patientRole>…</patientRole></recordTarget>
<author>…</author>
<custodian>…</custodian>
<component><structuredBody>
<component><section>
<templateId root="2.16.840.1.113883.10.20.22.2.6.1" extension="2015-08-01"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" displayName="Allergies and adverse reactions"/>
<title>Allergies</title>
<text><table><tr><td>Penicillin</td><td>Rash</td></tr></table></text>
<entry>…coded Allergy Concern Act…</entry>
</section></component>
</structuredBody></component>
</ClinicalDocument>
Drei Dinge sind zu beachten. Der Dokumenttyp und jeder Abschnitt werden durch einen LOINC-Code (34133-9, 48765-2) identifiziert. Vorlagen werden durch OIDs (2.16.840.1…) identifiziert, nicht durch URLs. Das <text>-Element ist obligatorisch und das, was ein Kliniker sieht; der <entry> ist optional und das, was die Software liest.
Die drei Ebenen
CDA definiert drei Struktur-Ebenen. Ebene 1 ist ein gültiger Header mit einem unstrukturierten Body, zum Beispiel einem eingebetteten PDF. Ebene 2 fügt einen strukturierten Body mit kodierten Abschnitten und Narrativ hinzu, aber ohne kodierte Einträge. Ebene 3 fügt kodierte Einträge hinzu, die Vorlagen folgen, sodass Software Allergien, Medikamente und Probleme importieren kann. Die meisten realen Dokumente liegen zwischen Ebene 2 und 3.
- Ebene 1: Ein gültiger Header plus ein unstrukturierter Body, z. B. ein eingebettetes PDF. Rechtlich ein CDA-Dokument; Computer können es ablegen, aber nicht lesen.
- Ebene 2: Strukturierter Body mit kodierten Abschnitten und Erzählung, keine kodierten Einträge. Die Software weiß, dass es einen Allergieabschnitt gibt; sie kann die Allergien nicht auflisten.
- Ebene 3: Abschnitte mit kodierten Einträgen nach Vorlagen. Die Software kann die Allergien, Medikamente und Probleme in den empfangenden Datensatz importieren.
Die meisten CDA-Dokumente in der Praxis liegen zwischen Ebene 2 und 3: Einige Abschnitte sind kodiert, andere nur als Erzählung.
Sechs Prinzipien, die es immer noch prägen
Die sechs Prinzipien hinter CDA sind: Beständigkeit (ein Dokument bleibt jahrelang unverändert), Stewardship (ein Custodian ist dafür verantwortlich), Möglichkeit zur Authentifizierung (es kann signiert werden), Kontext (der Header gilt für das gesamte Dokument), Ganzheitlichkeit (ein Abschnitt verliert außerhalb seines Dokuments an Bedeutung) und menschliche Lesbarkeit (das Narrativ wird ohne spezielle Software dargestellt). FHIR-Dokumente übernehmen dieselben sechs Prinzipien.
CDA wurde entwickelt mit den Prinzipien der Persistenz (ein Dokument bleibt jahrelang unverändert), Verwaltung (ein Verantwortlicher ist dafür zuständig), Potenzial zur Authentifizierung (es kann signiert werden), Kontext (der Header gilt für das gesamte Dokument), Ganzheitlichkeit (ein Abschnitt verliert außerhalb seines Dokuments seine Bedeutung) und menschliche Lesbarkeit (die Erzählung muss ohne spezielle Software gerendert werden können). FHIR-Dokumente (ein Bundle vom Typ document mit einer Composition) übernehmen dieselben Prinzipien; das zugrunde liegende Datenmodell ist anders, wie CDA vs FHIR erklärt.
C-CDA: Die US-Konsolidierung
C-CDA (Consolidated CDA) ist der US-Implementierungsleitfaden, der ab 2011 mehrere überlappende CDA-Leitfäden zu einem zusammengeführt hat. Er umfasst etwa ein Dutzend Dokumentvorlagen wie das Continuity of Care Document, Discharge Summary und Referral Note sowie eine gemeinsame Bibliothek von Abschnitts- und Eintrags-Vorlagen. C-CDA R2.1 ist für die ONC-Zertifizierung für Übergaben und Patientenübersichten erforderlich.
Vor 2011 verwendeten US-Implementierer mehrere überlappende CDA-Leitfäden. Consolidated CDA fasste sie zu einem zusammen, mit etwa einem Dutzend Dokumentvorlagen (Continuity of Care Document, Discharge Summary, Progress Note, Referral Note, Care Plan, Operative Note, Diagnostic Imaging Report und andere) und einer gemeinsamen Bibliothek von Abschnitts- und Eintragsvorlagen. C-CDA R2.1 ist für den Austausch bei Übergaben und Patientenübersichten von der US-EHR-Zertifizierung (ONC) vorgeschrieben und bleibt neben FHIR US Core für APIs bestehen.
Wo CDA im Jahr 2026 zu finden ist
Im Jahr 2026 lebt CDA im US-Provider-zu-Provider-Austausch als C-CDA über Direct Messaging und Health Information Exchanges, in Europas grenzüberschreitendem MyHealth@EU Patient Summary und ePrescription, in nationalen Programmen wie Deutschlands eArztbrief und ePA, Österreichs ELGA, Italiens FSE, den Niederlanden und der Schweiz, und überall als Header, der gescannte oder PDF-Dokumente umschließt.
- Vereinigte Staaten: C-CDA für den Dokumentenaustausch zwischen Anbietern, in Direct Messaging und Health Information Exchanges.
- Europa, grenzüberschreitend: MyHealth@EU tauscht die Patientenübersicht und die E-Rezept als CDA-Dokumente (die eHDSI-Vorlagen) aus, wobei FHIR-basierte Formate unter dem EHDS Einzug halten. Siehe E-Rezept über EU-Grenzen hinweg.
- Nationale Programme: Der deutsche elektronische Arztbrief (eArztbrief) und Teile der ePA, Österreichs ELGA-Dokumente, Italiens FSE, die Niederlande und die Schweiz verwenden CDA für Dokumente, oft über IHE XDS-Register.
- Überall: Gescannte und PDF-Dokumente, die in einen CDA-Header eingebettet sind, damit ein Dokumentenregister sie indizieren kann.
Was ein Empfänger tatsächlich erhält
Ein Empfänger eines CDA-Dokuments erhält immer ein lesbares Narrativ. Kodierte Daten kann er jedoch nur importieren, wenn der Absender konsistent Ebene-3-Vorlagen verwendet hat. Empfangssysteme zeigen typischerweise das Narrativ an und bieten an, Probleme, Medikamente und Allergien aus den Einträgen einzeln abzugleichen, da zwei Ebene-3-Dokumente von verschiedenen Anbietern selten dieselbe Tatsache identisch kodieren.
Ein CDA-Dokument ist zuverlässig zum Lesen und uneinheitlich zum Importieren. Die Erzählung ist immer vorhanden; die kodierten Einträge hängen von der Ebene und der Vorlagendisziplin des Absenders ab. Empfangssysteme zeigen dem Kliniker normalerweise die Erzählung an und bieten an, Probleme, Medikamente und Allergien aus den Einträgen "abzugleichen" und einzeln in den lokalen Datensatz zu übernehmen. Dieser Abgleichschritt existiert, weil zwei Level-3-Dokumente von verschiedenen Anbietern selten dieselbe Tatsache auf die gleiche Weise kodieren.
In Anpheros wird ein CDA-Dokument von einem Krankenhaus so gespeichert, wie es ist, als DocumentReference mit dem angehängten XML, und sein kodierter Inhalt wird, wo vorhanden, in FHIR-Ressourcen (Condition, AllergyIntolerance, MedicationStatement) abgebildet, wobei die Herkunft auf das Dokument zurückverweist. Siehe DocumentReference vs DiagnosticReport vs Binary.
Verwandte Seiten
- CDA vs FHIR
- HL7 vs FHIR: v2, CDA und FHIR
- FHIR Bundle erklärt
- DocumentReference vs DiagnosticReport vs Binary
- Die Internationale Patientenübersicht
- Standards für die Interoperabilität im Gesundheitswesen: die Karte
- TEFCA und QHINs erklärt
Quellen
- HL7 CDA Release 2 Produktübersicht
- HL7 C-CDA R2.1 Produktübersicht
- HL7 C-CDA Online-Navigation (Vorlagen)
- ONC-Zertifizierung: C-CDA-Anforderungen
- MyHealth@EU (Europäische Kommission)
Häufige Fragen
Ist CDA dasselbe wie HL7 v3?
CDA basiert auf dem HL7 v3 Reference Information Model und verwendet v3 Datentypen, weshalb seine XML-Struktur so aussieht. Der Rest der HL7 v3-Nachrichtenübermittlung fand wenig Akzeptanz; CDA ist der Teil von v3, der erfolgreich war.
Was ist ein CCD?
Das Continuity of Care Document ist der C-CDA-Dokumenttyp für eine Patientenübersicht: Probleme, Medikamente, Allergien, Impfungen, Ergebnisse, Verfahren, Vitalzeichen, Behandlungsplan. Es ist das US-Äquivalent der International Patient Summary.
Wird CDA durch FHIR ersetzt?
Für neue APIs und Apps ja; für den Dokumentenaustausch zwischen Institutionen langsam. Vorschriften in den USA und Europa schreiben für bestimmte Dokumente immer noch CDA vor, und FHIR-Dokumente werden eher parallel als ersetzend eingeführt.
Kann ein CDA-Dokument in FHIR konvertiert werden?
Ja, mit Einschränkungen. Der HL7 C-CDA on FHIR Implementierungsleitfaden bildet Dokumenttypen und Abschnitte ab; kodierte Einträge werden in FHIR-Ressourcen abgebildet, wo die Vorlagen übereinstimmen. Nur-Erzählungs-Abschnitte werden zu Composition-Abschnitten mit Text und ohne strukturierte Daten.
Kostenlos in der Sandbox testen
Ihr erster FHIR-Aufruf in 5 Minuten. Eine HL7 FHIR R4 API mit der Zustimmung des Patienten: probieren Sie sie in der Sandbox aus und verbinden Sie dann Ihre eigene App oder Ihr Kliniksystem.
Kostenlos · 30 synthetische Patienten · keine Karte
Anpheros entwickelt eine Patientenakte, die der Patient kontrolliert und mit jeder Klinik teilen kann, auf einer HL7 FHIR R4-Plattform mit Sitz in der EU. Diese Anleitungen helfen Ihnen, Ihre Gesundheit zu verstehen und zu organisieren; sie ersetzen nicht Ihren Arzt.
Über Anpheros →