CDA vs FHIR: Dokumente vs. Ressourcen, wann welche passen und wie man sie umwandelt

Kurze Antwort: CDA liefert Ihnen ein Dokument: eine signierte XML-Datei über einen Patienten zu einem bestimmten Zeitpunkt, mit einem für Menschen lesbaren Text und Einträgen, die ein Computer lesen kann. Dieses Dokument muss vollständig und unverändert bleiben. FHIR liefert Ihnen Ressourcen: einen Patienten, vierzig Beobachtungen, drei Zustände, die jeweils eine eigene URL haben und unabhängig über eine REST-API abgerufen, durchsucht und aktualisiert werden können. FHIR kann Ressourcen auch zu einem Dokument bündeln (ein Bundle vom Typ document, angeführt von einer Composition), was das direkte Äquivalent von CDA ist. Wählen Sie CDA, wenn eine Vorschrift oder ein Partner dies verlangt; wählen Sie FHIR für APIs, Apps und alles, was eher abgefragt als gelesen werden muss.

Die zwei Formen

CDA und FHIR haben zwei unterschiedliche Formen. CDA tauscht ganze XML-Dokumente aus, die auf HL7 v3 Datentypen basieren und durch OIDs identifiziert werden. Sie enthalten zwingend eine narrative Beschreibung, keine Abfragen, keine Aktualisierungen und eine Signatur des gesamten Dokuments. FHIR tauscht einzelne JSON- oder XML-Ressourcen oder Bundles aus, die durch kanonische URLs identifiziert werden. Es bietet integrierte REST-Abfragen, versionierte Aktualisierungen und Profile, die in Implementierungsleitfäden veröffentlicht werden.

Was der Unterschied in der Praxis bedeutet

In der Praxis bedeutet der Unterschied zwischen CDA und FHIR, dass CDA sich gut für Inhalte eignet, die einmal geschrieben und im Ganzen erhalten bleiben, wie z. B. ein unterschriebener Entlassungsbrief. FHIR hingegen eignet sich für Daten, die wachsen und abgefragt werden, wie z. B. eine Blutdruckserie. Ein CDA-Empfänger kann den Inhalt anzeigen, muss ihn aber zur Übernahme abgleichen. Ein FHIR-Empfänger erhält Ressourcen, die bereits wie seine eigene Akte geformt sind.

Ein Entlassungsbrief ist naturgemäß ein Dokument: Er wird einmal geschrieben, von einem Arzt unterschrieben und muss Jahre später genau so reproduzierbar sein, wie er gelesen wurde. Eine Blutdruckserie ist naturgemäß eine Sammlung von Ressourcen: Sie wächst täglich, wird grafisch dargestellt und gefiltert, und niemand unterschreibt sie. CDA bewältigt Ersteres gut und Letzteres schlecht (Sie würden das gesamte Dokument für jede neue Messung erneut senden). FHIR bewältigt Letzteres nativ und Ersteres über seinen Dokumentenmechanismus.

Der andere praktische Unterschied ist, was der Empfänger tun kann. Ein CDA-Empfänger kann das Dokument immer anzeigen; der Import seiner Einträge erfordert eine Abgleichung, Abschnitt für Abschnitt. Ein FHIR-Empfänger erhält Ressourcen, die bereits die Form seines eigenen Datensatzes haben; die schwierigen Fragen verlagern sich auf die Identität (ist das derselbe Patient?) und die Herkunft (wer hat das wann behauptet?). Siehe Patientenabgleich.

FHIR-Dokumente: der Treffpunkt

Ein FHIR-Dokument ist ein Bundle mit type: "document", dessen erster Eintrag eine Composition ist. Die Composition spielt die Rolle des CDA-Headers und der Abschnittsliste: Typ (LOINC), Datum, Autor, Subjekt, Custodian, Status und section[] mit einem Titel, einem Code, einem narrativen Text und Verweisen auf die Ressourcen, die die Daten enthalten.

{
  "resourceType": "Bundle",
  "type": "document",
  "identifier": {"system": "urn:ietf:rfc:3986", "value": "urn:uuid:3f2d7a3e-…"},
  "timestamp": "2026-03-14T10:15:00+01:00",
  "entry": [
    {"fullUrl": "urn:uuid:comp-1", "resource": {
      "resourceType": "Composition", "status": "final",
      "type": {"coding": [{"system": "http://loinc.org", "code": "60591-5", "display": "Patient summary Document"}]},
      "subject": {"reference": "urn:uuid:pat-1"},
      "date": "2026-03-14T10:15:00+01:00",
      "author": [{"reference": "urn:uuid:prac-1"}],
      "title": "Patient summary",
      "section": [{
        "title": "Allergies and intolerances",
        "code": {"coding": [{"system": "http://loinc.org", "code": "48765-2"}]},
        "text": {"status": "generated", "div": "<div xmlns=\"http://www.w3.org/1999/xhtml\"><p>Penicillin: rash</p></div>"},
        "entry": [{"reference": "urn:uuid:allergy-1"}]
      }]
    }},
    {"fullUrl": "urn:uuid:pat-1", "resource": {"resourceType": "Patient", "id": "pat-1"}},
    {"fullUrl": "urn:uuid:prac-1", "resource": {"resourceType": "Practitioner", "id": "prac-1"}},
    {"fullUrl": "urn:uuid:allergy-1", "resource": {"resourceType": "AllergyIntolerance", "id": "allergy-1", "patient": {"reference": "urn:uuid:pat-1"}, "code": {"coding": [{"system": "http://snomed.info/sct", "code": "764146007", "display": "Penicillin"}]}}}
  ]
}

Der International Patient Summary ist genau das: ein FHIR-Dokumentprofil mit einem CDA-Zwilling für Systeme, die ihn noch benötigen. Siehe auch FHIR Bundle erklärt.

Konvertierung dazwischen

Die Konvertierung zwischen CDA und FHIR funktioniert in beide Richtungen mit Einschränkungen. Der HL7 C-CDA on FHIR Implementierungsleitfaden bildet Dokumenttypen, Abschnitte und Einträge auf Composition-Profile und Ressourcen ab; reine narrative Abschnitte werden zu Text ohne Daten. FHIR zu CDA funktioniert für Ressourcen, die in C-CDA-Vorlagen passen. In beide Richtungen sollte das Original als DocumentReference mit Provenance aufbewahrt werden.

• CDA → FHIR: Der HL7 C-CDA on FHIR Implementierungsleitfaden bildet die US-Dokumenttypen und -abschnitte auf Composition-Profile ab; Einträge werden auf Ressourcen abgebildet (Problem Concern Act → Condition, Medication Activity → MedicationStatement, Result Observation → Observation). Die Abbildung ist deterministisch für gut vorlagenbasierte Inhalte der Stufe 3 und verlustbehaftet für rein narrative Abschnitte, die zu Text ohne Daten werden.
• FHIR → CDA: Möglich für Dokumente, deren Ressourcen den C-CDA-Vorlagen entsprechen. Frei formatierte FHIR-Ressourcen, die nie als Dokument gedacht waren (ein Strom von Wearable-Beobachtungen), ergeben kein sinnvolles CDA.
• Original beibehalten. In welcher Richtung Sie auch konvertieren, speichern Sie die Quelle, wie sie empfangen wurde, als DocumentReference, und lassen Sie Provenance von den konvertierten Ressourcen darauf verweisen. Konvertierung ist eine Ansicht, kein Ersatz.

Wann CDA immer noch die richtige Antwort ist

CDA ist immer noch die richtige Antwort, wenn die empfangende Partei es verlangt (US-Übergänge der Versorgung, MyHealth@EU Patientenübersicht und E-Rezept, verschiedene nationale Dokumentenregister), wenn der Inhalt rechtlich ein Dokument ist, das unterschrieben und im Ganzen aufbewahrt werden muss, oder wenn die Infrastruktur des Partners IHE XDS ist, das Dokumente statt Ressourcen indiziert. Andernfalls beginnen Sie mit FHIR.

Wenn die empfangende Partei dies verlangt (US-Übergänge der Versorgung, MyHealth@EU Patientenübersicht und E-Rezept heute, verschiedene nationale Dokumentenregister); wenn der Inhalt rechtlich ein Dokument ist, das signiert und vollständig aufbewahrt werden muss; wenn die Infrastruktur des Partners IHE XDS ist, die Dokumente und nicht Ressourcen indiziert. In allen anderen Fällen beginnen Sie mit FHIR und erstellen Sie ein FHIR-Dokument, wenn ein Dokument benötigt wird.

Verwandte Seiten

• CDA und C-CDA erklärt
• FHIR Bundle erklärt
• Der International Patient Summary
• HL7 vs FHIR
• DocumentReference vs DiagnosticReport vs Binary
• Patientenabgleich

Quellen

• HL7 FHIR R4: Documents
• HL7 FHIR R4: Composition
• HL7 C-CDA on FHIR implementation guide
• HL7 FHIR: comparison with CDA (Appendix)
• HL7 International Patient Summary IG

Häufige Fragen

Ist ein FHIR-Dokument nur CDA in JSON?

Nein. Es teilt die Prinzipien (vollständig, signiert, für Menschen lesbar, mit einem Header), aber sein Inhalt sind gewöhnliche FHIR-Ressourcen, sodass dieselbe Observation in einem Dokument existieren und über die API bereitgestellt werden kann. In CDA existiert ein Eintrag nur innerhalb seines Dokuments.

Kann ich ein FHIR-Dokument signieren?

Ja. Bundle.signature enthält eine digitale Signatur über das Bundle, und die IPS- und nationalen Leitfäden beschreiben, wie. In der Praxis verlassen sich viele Implementierungen auf Transportsicherheit und Herkunft statt auf Signaturen.

Hat FHIR templateId?

Das Äquivalent ist meta.profile, eine Liste kanonischer URLs der StructureDefinitions, deren Konformität die Ressource beansprucht. Validatoren prüfen die Konformität so, wie CDA-Schematrons Vorlagen prüfen.

Was sollte ein neues nationales Programm wählen?

Neuere Programme (das EHDS-Austauschformat, die US-Patientenzugangsregeln, die IPS) wählen FHIR, mit FHIR-Dokumenten für Zusammenfassungen und Briefe, und behalten einen CDA-Pfad nur für Legacy-Partner bei.

Anpheros Platform

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.

Kostenlose Sandbox anlegenEntwickler-Guides lesen →

Kostenlos · 30 synthetische Patienten · keine Karte

Erstellt von

Das Anpheros-Team

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 →