CDA → FHIR ohne Big Bang (Teil 2): Stolpersteine, Qualitätsregeln und Cutover-Checkliste

Von Friedhelm Matten · iscad-it
Zusammenfassung:
Teil 2 beschreibt, warum CDA→FHIR-Projekte häufig nicht an „Mapping“ scheitern, sondern an Terminologie, Identifiern, Narrativen, Testbarkeit und Governance. Der Beitrag zeigt typische Fehlerbilder, gibt Leitplanken für Qualität (Validierung, Testfälle, Monitoring) und bietet eine kompakte Cutover-Checkliste für den sicheren Übergang vom Parallelbetrieb in den Regelbetrieb.
Schlüsselwörter: HL7 CDA, HL7 FHIR, Terminologie, Identifier, Datenqualität, Validierung, Tests, Cutover, Implementation Guide

Die häufigsten Stolpersteine (und warum sie immer wieder passieren)

1) Terminologie: Das unsichtbare Fundament

Ohne verbindliche ValueSets, Mapping-Regeln und Freigabeprozesse wird aus „funktioniert“ schnell „funktioniert manchmal“. Typisches Symptom: Daten sind syntaktisch valide, aber semantisch uneinheitlich.

2) Identifier-Strategien: Wenn Referenzen nicht stabil sind

CDA-Dokumenten-IDs, interne Schlüssel, Patienten-IDs, Fallnummern: In FHIR wird Referenzierbarkeit zentral. Eine klare Identifier-Strategie entscheidet darüber, ob Bundles, Referenzen und deduplizierte Datenflüsse zuverlässig funktionieren.

3) Narrativ vs. strukturierte Daten

CDA enthält häufig wichtige Informationen im Narrativ. Der Anspruch, alles sofort vollständig zu strukturieren, führt oft zu Verzögerung und Qualitätsproblemen. Besser ist priorisiertes Strukturieren.

4) Overfitting: Profile werden zu projektspezifisch

Zu enge Profile treiben Sonderlogik. Leitplanke: so standardnah wie möglich, so spezifisch wie nötig – mit klaren Extensions- und Deprecation-Regeln.

5) Testbarkeit wird zu spät gedacht

Viele Probleme zeigen sich erst, wenn mehrere Partner implementieren. Deshalb braucht es früh eine Teststrategie: Beispiele, Szenario-Tests, Validator-Pipeline und reproduzierbares Fehlermanagement.

Qualitätssicherung als Migrationsbeschleuniger

  • Konformität: Validierung gegen Profile/IG.
  • Semantik: Terminologie-Konsistenz (ValueSet-Checks, Mapping-Reviews, Freigaben).
  • Vollständigkeit: Pflichtfelder/Must-Support pro Use Case.
  • Stabilität: Versionierung, Release-Notes, Deprecation, Rückwärtskompatibilität.

Cutover-Logik: Wann ist FHIR „bereit“?

  1. Use-Case-Abdeckung erreicht (priorisierte Szenarien Ende-zu-Ende).
  2. Qualitätsmetriken stabil (Validierungsquote, Terminologie-Fehler, Missing Fields).
  3. Partnerfähigkeit nachgewiesen (mindestens ein unabhängiger Implementierer).
  4. Betrieb gesichert (Monitoring, Support, Incident-Prozess, Versionierung).

Umsetzungs-Checkliste (kompakt)

  1. Zielbild klären (CDA vs FHIR) inkl. Ownership.
  2. Use Cases priorisieren und in testbare Szenarien übersetzen.
  3. Terminologie-Governance aufsetzen.
  4. Identifier-Strategie definieren.
  5. Profile/IG versionieren (Releases, Changelog, Deprecation).
  6. Testpipeline etablieren (Validator, Szenario-Tests, Beispiele).
  7. Dual Run mit Metriken fahren und Cutover-Kriterien prüfen.
  8. Partnerkommunikation inkl. Rückfallstrategie planen.

Fazit

CDA→FHIR gelingt am besten, wenn du mit klaren Mustern, Governance und messbarer Qualität arbeitest. Migration ist dann ein gesteuerter Übergang in einen stabil betreibbaren Interoperabilitätsbetrieb.