Was steht nicht in Ihrem FHIR-Profil?

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

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 regelmäßig verloren. Sie sind keine Ausreißer, sondern Muster — beschrieben als die vier kanonischen Verlustmuster.

• 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 ist Strukturwächter, nicht Bedeutungswächter — dafür ist er gebaut, und darin ist er verlässlich. Die zweite Prüfebene muss jemand anderes stellen.

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.