Ungebundene Bindings

Ein Element, ein Binding – und seine Grenzen

Seit FHIR DSTU2 hat jedes kodierte Element genau ein Binding – eine Regel, die das Element an eine Menge erlaubter Codes (ein ValueSet) mit einer bestimmten Stärke knüpft. Die Stärke gibt an, wie streng die Codes befolgt werden müssen: required bedeutet, Sie MÜSSEN einen Code aus dieser Menge verwenden; extensible bedeutet, verwenden Sie einen, wenn er auf Ihr Konzept zutrifft, andernfalls dürfen Sie andere Codes nutzen; preferred und example sind zunehmend lockerere Empfehlungen. Für einfache Elemente wie Patient.gender (gebunden an AdministrativeGender mit required-Stärke) funktioniert dieses Modell einwandfrei.

Doch als die FHIR-Nutzung wuchs – über Jurisdiktionen, klinische Domänen und regulatorische Regime hinweg – stieß das Ein-Binding-Modell an seine Grenzen. Profile-Autoren (Personen, die StructureDefinitions schreiben – Constraint-Mengen auf Basis von FHIR-Ressourcen) stießen immer wieder auf Probleme, die ein einzelnes ValueSet nicht ausdrücken konnte.

Die Extensible+Max-Saga

Der erste Workaround war das Extensible+Max-Muster. US Core benötigte eine Möglichkeit zu sagen: „Verwenden Sie Codes aus diesem kleinen ValueSet, aber wenn Sie erweitern müssen, bleiben Sie innerhalb dieser größeren Grenze." Die Lösung war die maxValueSet-Extension, eingeführt in STU3 und in R4 verfeinert.

Sie sorgte sofort für Verwirrung. Die Spezifikation beschrieb sie als „ein ‚required'-Binding über dem extensible-Binding" – aber niemand war sich einig, was das in der Praxis bedeutete. Die zentrale Spannung, die in einem 182-Nachrichten-Thread auf chat.fhir.org offen zutage trat: Argonaut benötigte „diesen Code oder Freitext" für die ONC-Konformität – Krankenhäuser hatten Freitextprobleme, die „buchstäblich ein String im lokalen System" waren (Jenni Syed). Aber keine Kombination von Binding-Stärken konnte das ausdrücken. Josh Mandel wies darauf hin, dass US Core Immunization vaccineCode an CVX mit sowohl extensible als auch max – auf dasselbe ValueSet – gebunden hatte: „Aus einer Interoperabilitätsperspektive kann ich nicht verstehen, warum die Wahl von extensible und maximum besser ist als einfach extensible zu wählen."

Parallel dazu versuchte eine minValueSet-Extension, eine Untergrenze für extensible Bindings festzulegen – wenn ein Code aus dieser Menge zutrifft, müssen Sie ihn verwenden. Aber sie vermischte Sender-Constraints mit Empfänger-Pflichten, und Validatoren konnten sie nicht durchsetzen.

Beide Extensions konnten nur zwei enge Anwendungsfälle ausdrücken, und selbst diese wurden kaum verstanden.

Das „Ich möchte mehrere Bindings"-Problem

Gleichzeitig baten IG-Autoren immer wieder nach mehreren Bindings für ein einzelnes Element. Der häufigste Treiber war IPS (International Patient Summary), das eine Auswahl von Terminology-Bindings auf einem CodeableConcept ausdrücken musste – verschiedene Code-Systeme für verschiedene Jurisdiktionen. Das einzige verfügbare Werkzeug war Slicing – FHIRs Mechanismus, um zu sagen: „Dieses wiederholende Element muss Einträge haben, die bestimmten Mustern entsprechen." Auf CodeableConcept.coding angewendet, ermöglichte Slicing, ein Coding aus SNOMED und ein weiteres aus ICD-10 zu verlangen. Aber es war komplex zu verfassen, für Implementierer schwer verständlich und in der Profil-Darstellung weitschweifig.

Wie Grahame Grieve es formulierte: „Es gibt viel Slicing in Implementation Guides, weil Autoren sagen wollen: ‚Einer der Codes muss aus ValueSet X stammen.' Das ist die häufigste Verwendung von Slicing, und man muss es tun, weil ein Binding auf alle Wiederholungen des Codes zutrifft. Aber Slicing ist für Implementierer schwierig."

Grahames Vorschlag (Februar 2022)

Im Februar 2022 schlug Grahame Grieve eine neue Extension auf ElementDefinition.binding vor – additional bindings. Die Kernidee: Das Haupt-Binding bleibt das Konformitäts-Binding (was der Validator durchsetzt), aber Sie können zusätzliche Bindings mit verschiedenen Zwecken anhängen:

Ich möchte eine Extension auf ElementDefinition.binding definieren, die zusätzliche Bindings spezifiziert. ElementDefinition.binding ist das Konformitäts-Binding: was der Validator durchsetzt – und davon kann es nur eines geben. Aber darüber hinaus werden Designer in der Lage sein, zusätzliche Bindings anzugeben.

Seine ursprüngliche Zweck-Liste – conformance, required, recommended, UI, starter, component, minimum, maximum – adressierte jede Lücke, um die die Community Workarounds entwickelt hatte. Die Motivation:

An einigen Stellen verwenden wir extensible+max und wollen eigentlich ein Basis-ValueSet mit einem empfohlenen ValueSet. An einigen Stellen verwenden wir extensible, und wir wollen eigentlich ein ziemlich großes Basis-ValueSet mit einem required – das ist es, was die Gesetzgebung für neue Datensätze will.

Rob Hausam erkannte sofort den Wert für IPS: „Ich stimme zu, dass dies wie ein Ersatz für Slicing auf CodeableConcept.coding aussieht... Wenn das alles zutrifft, wann können wir damit in IPS beginnen?"

Lloyd McKenzie widersprach: „Wenn Regeln für verschiedene Kontexte unterschiedlich sind, dann braucht man verschiedene Profile." Aber Grahame entgegnete: „Es ist kein guter Dienst an den Nutzern, unzählige Profile zu haben, die sich nur nach Nutzungskontext und einigen Bindings unterscheiden."

Bis April 2022 hatte der IG Publisher Entwurfs-Rendering-Unterstützung, und Grahame fügte das any-Flag hinzu – „wenn any = true, dann gilt das Binding nur für eine der Wiederholungen, nicht für alle." Bis August 2022 verwendete IPS es bereits. Das Feature wurde dem R5-Ballot zugesagt als ElementDefinition.binding.additional und wurde in R5 (März 2023) als erstklassiges Element ausgeliefert – nicht mehr als Extension.

Wie es funktioniert: Semantik zuerst

Bevor wir in den Zweck-Katalog eintauchen, zwei grundlegende Regeln.

Regel 1: Alle Bindings sind UND. Das Haupt-Binding und jedes zusätzliche Binding gelten gleichzeitig. Lloyd McKenzie formulierte es klar: „Alle Bindings gelten immer. Punkt." Allerdings beißen nicht alle Bindings gleich stark:

• Bindings mit einem usage-Kontext werden ignoriert, wenn Sie sich nicht in diesem Kontext befinden
• Guidance-Zwecke (starter, ui, component, preferred) haben kein Konformitätsgewicht
• current-Bindings gelten nur für Daten, die seit der Erklärung der Konformität erfasst wurden – nicht für Legacy-Daten
• extensible-Bindings haben den Standard-Ausweg: Sie müssen nicht konform sein, wenn kein Code im ValueSet auf Ihr Konzept zutrifft

Wenn Sie ODER-Semantik wünschen („senden Sie einen Code aus ValueSet A oder ValueSet B"), kombinieren Sie diese in einem einzelnen gruppierten ValueSet. Additional Bindings geben Ihnen kein ODER.

Bei einem CodeableConcept – FHIRs Datentyp, der mehrere parallele Code-Darstellungen (Codings) desselben Konzepts tragen kann – bedeuten mehrere required Bindings, dass Sie möglicherweise mehrere Codings benötigen, wobei jedes einem Binding entspricht. So funktioniert „muss SNOMED UND ICD-10 senden" ohne Slicing.

Regel 2: Das any-Flag ändert die Wiederholungs-Semantik. Standardmäßig gilt ein Binding für alle Wiederholungen eines Elements. Das Setzen von any = true bedeutet, dass das Binding erfüllt ist, wenn irgendeine Wiederholung passt. Dies ist der Schlüsselmechanismus, der Coding-Slices ersetzt – und wie Lloyd McKenzie anmerkte: „Die Verwendung von Slicing für ‚und'-Bindings gilt jetzt als Anti-Pattern und wird nicht mehr empfohlen."

Struktur und Zwecke

Ein Additional Binding ersetzt niemals das Haupt-Binding – es schichtet sich darüber. Jedes hat:

So sieht es in einer StructureDefinition aus (vereinfachte Notation):

binding:
  strength: extensible
  valueSet: http://hl7.org/fhir/ValueSet/observation-codes
  additional:
    - purpose: starter
      valueSet: http://example.org/ValueSet/common-lab-codes
      documentation: >
        A manageable subset of ~200 common laboratory codes
        for implementers getting started.
    - purpose: current
      valueSet: http://example.org/ValueSet/2026-lab-codes
      documentation: >
        Required for all new observations captured after 2026-01-01.
        Legacy data may use codes outside this set.

Die Zwecke haben sich seit Grahames Vorschlag von 2022 weiterentwickelt (einige wurden umbenannt, conformance wurde entfernt). Das purpose-Element hat ein required Binding – Sie können nur Codes aus dem AdditionalBindingPurposeCodes-ValueSet verwenden, keine eigenen Zwecke sind erlaubt. Hier sind die R5-Codes:

Konformitätszwecke

Guidance-Zwecke

R6 fügt current-extensible (extensible-Semantik für neue Daten), best-practice (im Best-Practice-Validierungsmodus markiert) und open (keine Einschränkungen, zur Dokumentation) hinzu.

Über FHIR-Versionen hinweg

Für R4-IGs werden Additional Bindings als Extension auf ElementDefinition.binding ausgedrückt:

binding:
  strength: extensible
  valueSet: http://hl7.org/fhir/ValueSet/observation-codes
  extension:
    - url: http://hl7.org/fhir/tools/StructureDefinition/additional-binding
      extension:
        - url: purpose
          valueCode: current
        - url: valueSet
          valueCanonical: http://example.org/ValueSet/2026-codes
        - url: documentation
          valueMarkdown: Required for new records.

In R5+ wird dasselbe nativ ausgedrückt – kein Extension-Wrapper erforderlich.

Szenarien

Konformität über mehrere Jurisdiktionen

Ein internationales Profil benötigt verschiedene Code-Systeme in verschiedenen Ländern – SNOMED CT in den USA, ICD-10-GM in Deutschland. Vor Additional Bindings bedeutete dies entweder separate Profile pro Jurisdiktion oder komplexes Slicing. Jetzt können Sie es in einem einzigen Profil mit required + any: true + usage ausdrücken:

binding:
  strength: extensible
  valueSet: http://hl7.org/fhir/ValueSet/condition-code
  additional:
    - purpose: required
      valueSet: http://example.org/ValueSet/us-snomed-conditions
      any: true
      usage:
        - code: { code: US, system: urn:iso:std:iso:3166 }
      documentation: US jurisdiction — at least one SNOMED CT coding required.
    - purpose: required
      valueSet: http://example.org/ValueSet/de-icd10gm-conditions
      any: true
      usage:
        - code: { code: DE, system: urn:iso:std:iso:3166 }
      documentation: German jurisdiction — at least one ICD-10-GM coding required.

Drei Funktionen arbeiten hier zusammen: required macht das Binding durchsetzbar, any: true bedeutet „mindestens ein Coding muss passen" (nicht alle – Sie können also weiterhin andere Codings daneben senden), und usage begrenzt jedes Binding auf seine Jurisdiktion. Ein US-System sieht nur die SNOMED-Anforderung; ein deutsches System sieht nur ICD-10-GM. Das extensible Haupt-Binding gilt für beide.

Legacy-Datenmigration

Ein häufiges Problem: Ein Land wechselt zu einem neuen Kodierungsstandard, aber Krankenhäuser haben jahrzehntelange Daten im alten Format. Ohne Additional Bindings musste man wählen – entweder ist das Binding locker genug für Legacy-Daten (und man verliert die Konformität für neue Daten) oder es ist streng für neue Daten (und alte Datensätze scheitern bei der Validierung).

Additional Bindings lösen dies mit current + minimum:

binding:
  strength: extensible
  valueSet: http://hl7.org/fhir/ValueSet/condition-code
  additional:
    - purpose: current
      valueSet: http://example.org/ValueSet/icd-11-conditions
      documentation: >
        All new diagnoses captured after 2026-01-01 must use ICD-11.
    - purpose: minimum
      valueSet: http://example.org/ValueSet/icd-10-icd-11-conditions
      documentation: >
        Systems must accept both ICD-10 and ICD-11 codes.

Das Haupt-Binding bleibt breit (condition-code – extensible). Das current-Binding sagt: „Ab jetzt ICD-11 verwenden." Das minimum-Binding sagt: „Aber jedes konforme System muss ICD-10 in eingehenden Daten weiterhin akzeptieren." Keines ersetzt das Haupt-Binding – sie fügen Präzision dort hinzu, wo das alte Modell nur einen Regler hatte.

Kategorie-abhängige Bindings (SDOH)

Dies ist ein reales Muster aus US Core SDOH-Profilen. Condition.code ist an ein breites ValueSet gebunden, aber verschiedene Kategorien erhalten engere Bindings – wenn die Kategorie food-insecurity ist, muss der Code aus dem SDOH Food Insecurity Diagnoses VS stammen; bei housing-instability aus einem anderen VS. Jedes Additional Binding verwendet usage, um nach Kategorienwert einzugrenzen:

# Condition.code
binding:
  strength: required
  valueSet: http://hl7.org/fhir/us/core/ValueSet/us-core-condition-code
  additional:
    - purpose: required
      valueSet: http://hl7.org/fhir/us/sdoh/ValueSet/food-insecurity-diagnoses
      usage:
        - code: { code: food-insecurity, system: http://hl7.org/fhir/us/sdoh/CodeSystem/sdoh-category }
      documentation: >
        When Condition.category = food-insecurity,
        code must come from this ValueSet.
    - purpose: required
      valueSet: http://hl7.org/fhir/us/sdoh/ValueSet/housing-instability-diagnoses
      usage:
        - code: { code: housing-instability, system: http://hl7.org/fhir/us/sdoh/CodeSystem/sdoh-category }
      documentation: >
        When Condition.category = housing-instability,
        code must come from this ValueSet.

Der usage-Kontext hier ist keine Jurisdiktion – es ist eine klinische Kategorie innerhalb derselben Ressource. Der Validator prüft: Wenn die Condition category = food-insecurity hat, dann gilt das Additional Binding für food-insecurity und code muss aus diesem spezifischen ValueSet stammen. Wenn die Kategorie nicht passt, wird das Binding ignoriert. Wie Grahame bestätigte: „Wenn Ihre Kategorie eine der festgelegten Kategorien ist, dann gilt das ValueSet für diese Kategorie."

UI-Hinweise für große ValueSets

Nicht alle Additional Bindings betreffen Konformität. Die Zwecke ui und starter haben kein Validierungsgewicht – sie helfen Implementierern, bessere Oberflächen zu erstellen. Ein Vitalzeichen-Profil hat möglicherweise 100.000+ LOINC-Codes in seinem extensible Binding, aber die UI benötigt nur eine Handvoll:

# Observation.code (vital signs)
binding:
  strength: extensible
  valueSet: http://hl7.org/fhir/ValueSet/observation-vitalsignresult
  additional:
    - purpose: starter
      valueSet: http://example.org/ValueSet/common-vitals
      documentation: >
        15 most common vital sign codes. Start here
        if you're building a new system.
    - purpose: ui
      valueSet: http://example.org/ValueSet/vitals-picker
      documentation: >
        Curated list optimized for dropdown selection.
        Not a conformance constraint.

Der Zweck starter sagt „beginnen Sie Ihre Implementierung mit diesen Codes." Der Zweck ui sagt „zeigen Sie diese Codes in einem Auswahl-Element an." Keiner beeinflusst die Validierung – ein System kann jeden Code senden, der unter dem extensible Haupt-Binding gültig ist. Aber sie lösen ein reales Problem: Implementierer, die einem 100.000-Code-ValueSet gegenüberstehen und nicht wissen, wo sie anfangen sollen.

Noch in Entwicklung

Der Mechanismus ist ausgereift, aber die Community arbeitet noch an Grenzfällen. Noch Ende 2025 schrieb Eric Haas: „Wir haben dieses Thema beim WGM diskutiert, und als Profiler bin ich immer noch verwirrt, wie Additional Bindings funktionieren sollen." Er und Gay Dolin erstellen eine Matrix expliziter Anwendungsfälle mit Beispielen für den FHIR Guidance IG. Wichtige Bereiche, die noch verfeinert werden:

• Bedingte Bindings – die Verwendung von usage (UsageContext) zur Eingrenzung von Bindings nach Jurisdiktion oder Workflow ist mächtig, aber in der Praxis komplex (66 Nachrichten und mehr).
• Validator-Verhalten – wie Verstöße gemeldet werden, variiert je nach Zweck: required erzeugt Fehler, Guidance-Zwecke wie starter und ui sind nur informativ.

Referenzen und Community-Diskussionen

Spezifikation:

• ElementDefinition.binding.additional – formale Definition
• Additional Binding Purpose Codes – alle Zweck-Codes mit Definitionen
• Terminologies: Binding Strengths – wie Stärken mit Additional Bindings funktionieren
• Binding Examples – ausgearbeitete Beispiele
• Tooling Extensions IG – R4-Backport-Extension

Community (chat.fhir.org):

• Extension for additional bindings – der ursprüngliche Vorschlag von 2022 von Grahame Grieve (49 Nachrichten)
• Implementing Additional Bindings for each purpose – UND- vs. ODER-Semantik, Anwendungsfall-Matrix (27 Nachrichten)
• Conditional additional bindings – UsageContext-Eingrenzung (66 Nachrichten)
• Extensible+Max – das Prä-R5-Muster (182 Nachrichten)
• Modifications to ElementDefinition – formale R5-Zusage (111 Nachrichten)

Siehe auch: Residualkategorien in der FHIR Terminology.