FHIR-Profile sind kein Selbstzweck

0 Einordnung in unsere Artikelreihe

Dieser Beitrag schließt eine Lücke zwischen mehreren Themen, die wir bereits behandelt haben: KI als Co-Pilot in Interoperabilitätsvorhaben, die Rolle von Dokumentenwelten in CDA und deren schrittweiser Übergang (Teil 1, Teil 2), sowie die Bedeutung von Terminologien und Metadaten/Ontologien.

Denn in der Praxis ist Profilierung der Punkt, an dem alles zusammenkommt: fachliche Anforderungen, Semantik, Testbarkeit und Betrieb. Genau hier entscheidet sich, ob FHIR skalierbar wird – oder ob Projekte in Mapping-Backlogs, Sonderlogik und Versionschaos enden.

1 Warum Profile oft das falsche Problem lösen

In vielen FHIR-Vorhaben startet die Arbeit mit der Frage: „Welche Constraints brauchen wir auf dieser Ressource?“ Technisch ist das naheliegend – fachlich ist es häufig zu früh. Dann werden Unklarheiten aus Workshops, Prozessvarianten und unvollständigen Semantikentscheidungen direkt in Constraints gegossen.

Typische Symptome solcher Profile:

• sie sind fachlich schwer erklärbar („Warum ist dieses Feld Pflicht?“),
• sie sind projektgetrieben (statt domänengetrieben),
• sie sind kaum wiederverwendbar,
• sie sind nur syntaktisch valide, aber semantisch uneinheitlich.

2 Use Case → Informationsbedarf → Profil

Ein stabiles Profil entsteht nicht direkt aus einer Ressource, sondern aus einem fachlichen Bedarf. Der oft übersprungene Zwischenschritt ist der Informationsbedarf: Was muss wirklich übertragen werden, damit ein Prozess funktioniert und Entscheidungen sicher getroffen werden können?

2.1 Was ein Use Case liefern muss

• Wer tauscht Daten aus (Akteure, Systeme, Rollen)?
• Wann im Prozess (Trigger, Ereignis, Zeitbezug)?
• Wozu (Versorgung, Abrechnung, Forschung, Dokumentation)?
• Welche Entscheidung hängt an den Daten (z. B. Medikation fortsetzen, Diagnose verifizieren, Labor interpretieren)?

2.2 Vom Informationsbedarf zum Profil

Erst dann wird Profilierung sauber: Pflichtfelder, Kardinalitäten, Referenzen und Terminologie-Bindings sind die formale Umsetzung eines fachlich begründeten Informationsbedarfs – nicht dessen Ersatz.

3 Typische Anti-Pattern in der Profilierung

3.1 „Ein Profil pro Projekt“

Jedes Projekt definiert seine eigenen Profile – oft mit minimalen Abweichungen. Das erzeugt Fragmentierung, Mapping-Aufwand und steigende Betriebskosten.

Leitplanke: Profile sind Organisations- oder Domänen-Assets, keine Projektartefakte.

3.2 Over-Constraint als Scheinsicherheit

Alles wird verpflichtend gemacht: Kardinalitäten auf 1..1, enge ValueSets, projektspezifische Extensions. Kurzfristig wirkt das „sauber“, langfristig blockiert es neue Use Cases und Partneranbindungen.

Leitplanke: So restriktiv wie nötig – so offen wie möglich. Jeder Constraint braucht eine fachliche Begründung.

3.3 Profilierung ohne Terminologie-Strategie

FHIR standardisiert Transport und Struktur. Bedeutung entsteht über Terminologien. Ohne verbindliche Codesysteme, ValueSets und Mapping-Regeln wird Interoperabilität zur Illusion.

Vertiefung: Terminologien in FHIR: Ohne SNOMED/LOINC wird’s teuer.

Leitplanke: Ein Profil ohne Terminologie-Governance ist kein Vertrag, sondern eine Empfehlung.

3.4 Profile ohne Testbarkeit

Wenn Profile nur als StructureDefinition existieren, aber nicht als reproduzierbare Tests, bleibt Qualität eine Behauptung. Spätestens beim zweiten Implementierer zeigt sich die Lücke.

Leitplanke: Was nicht testbar ist, ist nicht interoperabel – egal wie korrekt es modelliert ist.

4 Profile als Vertrag: Governance statt Bastelarbeit

4.1 Ownership und Entscheidungsfähigkeit

Für jedes Profil muss klar sein: Wer ist fachlich verantwortlich? Wer entscheidet über Änderungen? Wer priorisiert Erweiterungen? Ohne Ownership werden Profile zu verwaisten Artefakten.

4.2 Versionierung, Changes und Deprecation

Änderungen sind normal. Entscheidend ist das Wie: Versionen mit klarer Semantik, dokumentierte Breaking Changes, Deprecation statt abruptem Entfernen. Das ist Interoperabilitätsbetrieb – nicht „Doku“.

Wer aus einer CDA-Welt kommt, kennt das Muster: stabile Austauschdefinitionen brauchen klare Regeln und Release-Prozesse. (vgl. CDA → FHIR ohne Big Bang (Teil 1) und Teil 2).

4.3 Profile im Implementation Guide (IG)

Ein IG ist nicht nur eine technische Sammlung. Er ist Kommunikationsmittel für Partner, fachliche Erläuterung, Referenz für Beispiele und Grundlage für Tests. Profile ohne IG-Kontext sind formal korrekt, aber praktisch schwach.

5 Qualität entsteht durch Tests, nicht durch Diskussionen

5.1 Was getestet werden muss

• Syntaktische Konformität: Validierung gegen Profile.
• Semantik: Terminologie-Validierung (ValueSets, Codesysteme, Versionen).
• Vollständigkeit: Pflichtfelder/Must-Support pro Use Case.
• Konsistenz: Referenzen, Identifier-Strategien, Wiederverwendung.

5.2 Profile als Messinstrument

Gute Profile ermöglichen Metriken: Validierungsquote, Terminologie-Fehler, fehlende Pflichtfelder, Impact über Versionen hinweg. So wird Interoperabilität steuerbar – nicht nur behauptet.

6 Weniger Profile, bessere Profile

Viele Organisationen haben zu viele Profile – und nur wenige davon sind stabil und wiederverwendbar. Ein nachhaltiger Ansatz bedeutet:

• zentrale, gut begründete Profile (Domäne/Organisation statt Projekt),
• Use-Case-Ableitung mit klarem Informationsbedarf,
• saubere Terminologien und Metadaten-Bezüge (vgl. Ontologien & ISO-Metadaten),
• verbindliche Tests und ein betriebliches Release-Modell.

7 Fazit

FHIR-Profile sind kein Selbstzweck und keine rein technische Übung. Sie sind Verträge zwischen Organisationen, Systemen und Menschen. Stabile Profile entstehen nicht durch „mehr Constraints“, sondern durch klare fachliche Entscheidungen, saubere Semantik, nachvollziehbare Governance und messbare Qualität im Betrieb.

Wer Profile so versteht, reduziert Komplexität statt sie zu vermehren – und schafft die Grundlage für echte, skalierbare Interoperabilität.