Was steht nicht in Ihrem FHIR-Profil?

Fachliche Präzisierung vom 15.09.2026: Was ein Profil offenlässt, „kann“ verloren gehen (statt „geht verloren“); der Validator wird nicht mehr als reiner Strukturwächter beschrieben; der Angebotshinweis verweist auf den SILD-Pilot. Ursprünglich veröffentlicht am 22. August 2026.

Ein FHIR-Profil ist kein technisches Dokument — es ist ein Vertrag zwischen Quell- und Zielsystem. Was der Vertrag nicht festschreibt, kann beim ersten Mapping verloren gehen.

Ein Profil ist eine Zusage

Wer ein Profil schreibt, sagt zu: So sieht das aus, was wir liefern. Kardinalitäten, Datentypen, gebundene ValueSets, Slices, Invarianten — jede dieser Festlegungen ist ein Satz im Vertrag, auf den sich das Zielsystem verlassen darf. Genau dafür sind Profile da, und darin sind sie stark.

Die stille Annahme dabei lautet: Was nicht im Profil steht, ist unwichtig. Sie ist falsch. Was nicht im Profil steht, ist ungeregelt — und über Ungeregeltes entscheidet beim Mapping die Implementierung.

Vier Lücken, die der Vertrag oft offenlässt

Vier Dinge stehen selten in Profilen und gehen deshalb leicht verloren. Sie lassen sich den vier Verlustmustern zuordnen, mit denen wir solche Fälle beschreiben.

• Wie genau muss der Code sein? Ein Profil bindet ein ValueSet, schreibt aber selten fest, welche Genauigkeit erhalten bleiben muss. Wird ein präziser Quellbegriff auf einen gröberen Zielbegriff abgebildet, ist das Ergebnis valide — und ungenauer als die Quelle.
• Wie genau muss die Zeit sein? dateTime erlaubt den Tag und erlaubt die Sekunde. Ein Verlauf von 08:12 bis 11:47 wird zum Ganztagseintrag, und kein Constraint verhindert das, solange keines es fordert.
• Welche Beiworte sind Pflicht? Einheit, Status, Negation. „Keine bekannte Allergie“ ist eine Aussage; ein fehlender Eintrag ist keine. Wo 0..1 steht, ist beides erlaubt.
• Welche Verweise müssen halten? Ein Befund ohne seine Auftragsreferenz bleibt ein gültiger Befund. Er beantwortet nur nicht mehr die Frage, zu der er gehörte.

Warum das erst beim Mapping auffällt — oder gar nicht

Solange Quell- und Zielsystem von denselben Menschen betreut werden, trägt das gemeinsame Verständnis die Lücke. Beim ersten Mapping über eine Organisationsgrenze hinweg trägt es nicht mehr. Wer abbildet, liest das Profil und hält sich daran; alles, was nicht darin steht, entscheidet er nach eigenem Ermessen — meist plausibel, meist undokumentiert und für die Gegenseite nicht erkennbar.

Der Validator bestätigt anschließend, dass das Ergebnis den Regeln entspricht. Das tut es auch. Er prüft Struktur, Profile, Terminologiebindungen und Invarianten und kann dabei Hinweise liefern — den Vergleich mit der Quelle leistet eine Zielvalidierung allein aber nicht. Diese zweite Prüfebene muss eigens festgelegt werden, etwa über projektspezifische Regeln oder Tests.

Was in den Vertrag gehört

Ein Profil wird nicht dadurch besser, dass es mehr Constraints enthält. Es wird besser, wenn es die vier Fragen oben beantwortet — und zwar dort, wo sie hingehören: als Festlegung im Profil, nicht als Fußnote im Implementation Guide und nicht als mündliche Absprache zwischen zwei Beteiligten, die das Projekt überdauern soll.

Dazu gehört auch der ehrlichste Teil: ausdrücklich zu benennen, was bewusst offen bleibt. Ein Vertrag mit einer erklärten Lücke ist besser als einer mit einer stillen — die erklärte Lücke kann jemand schließen.