--- { "title": "Ungebundene Bindings", "description": "Wie FHIR R5-Additional-Bindings die Grenzen des klassischen Ein-Binding-pro-Element-Modells durch geschichtete Terminology-Constraints lösen.", "date": "2026-03-24", "author": "Nikolai Ryzhikov", "reading-time": "14 min read", "tags": ["FHIR Standard", "FHIR Profiling", "Terminology"], "tldr": "Additional Bindings – eingeführt in FHIR R5 – ermöglichen es, mehrere Terminology-Constraints an ein einzelnes Element zu knüpfen, jedes mit einem eigenen Zweck: spezifische Codes für neue Daten vorschreiben, eine Einstiegs-Teilmenge vorschlagen, UI-Hinweise geben oder jurisdiktionsspezifische Regeln durchsetzen. Sie schichten sich über das Haupt-Binding und ersetzen es nie." } --- ## 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](http://hl7.org/fhir/R5/valueset-administrative-gender.html) 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](https://hl7.org/fhir/R4/extension-elementdefinition-maxvalueset.html), eingeführt in [STU3](http://hl7.org/fhir/STU3/extension-elementdefinition-maxvalueset.html) 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](https://chat.fhir.org/#narrow/stream/argonaut/topic/Extensible%2BMax) 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](https://hl7.org/fhir/R4/extension-elementdefinition-minvalueset.html), 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](/blog/how-to-create-a-fhir-implementation-guide)-Autoren immer wieder nach **mehreren Bindings** für ein einzelnes Element. Der häufigste Treiber war [IPS (International Patient Summary)](http://hl7.org/fhir/uv/ips/), 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](/articles/grahame-grieve-interview-future-of-fhir-in-2025) es [formulierte](https://chat.fhir.org/#narrow/stream/terminology/topic/Extension%20for%20additional%20bindings): „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](https://chat.fhir.org/#narrow/stream/terminology/topic/Extension%20for%20additional%20bindings) 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](http://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-Immunization-uv-ips.html). Das Feature wurde [dem R5-Ballot zugesagt](https://chat.fhir.org/#narrow/stream/fhir.2Finfrastructure-wg/topic/Modifications%20to%20ElementDefinition) 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](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Implementiing%20Additional%20Bindings%20for%20each%20purpose%20unclear): „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](http://hl7.org/fhir/R5/datatypes.html#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](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Implementiing%20Additional%20Bindings%20for%20each%20purpose%20unclear): „Die Verwendung von Slicing für ‚und'-Bindings gilt jetzt als Anti-Pattern und wird nicht mehr empfohlen." ## Struktur und Zwecke Ein [Additional Binding](http://hl7.org/fhir/R5/elementdefinition-definitions.html#ElementDefinition.binding.additional) ersetzt niemals das Haupt-Binding – es schichtet sich darüber. Jedes hat: | Eigenschaft | Beschreibung | |----------|-------------| | `purpose` | Warum dieses Binding existiert (siehe Tabellen unten) | | `valueSet` | Die ValueSet-URL | | `documentation` | Markdown, das die Verwendung im Kontext erklärt | | `shortDoco` | Eine kurze Klartextzusammenfassung für die tabellarische Darstellung | | `usage` | [UsageContext](http://hl7.org/fhir/R5/metadatatypes.html#UsageContext)-Einschränkung nach Jurisdiktion, Domäne oder Workflow | | `any` | Wenn `true`, erfüllt, wenn irgendeine Wiederholung passt (Standard: alle müssen passen) | So sieht es in einer StructureDefinition aus (vereinfachte Notation): ```yaml 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](http://hl7.org/fhir/R5/valueset-additional-binding-purpose.html)-ValueSet verwenden, keine eigenen Zwecke sind erlaubt. Hier sind die R5-Codes: ### Konformitätszwecke | Zweck | Bedeutung | |---------|---------------| | `required` | Das Element MUSS einen Code aus diesem ValueSet verwenden – im angegebenen Nutzungskontext | | `extensible` | Verwenden Sie Codes aus diesem ValueSet, wenn zutreffend – im angegebenen Nutzungskontext | | `current` | Neue Datensätze **MÜSSEN** dieses ValueSet verwenden. Legacy- oder extern bezogene Daten dürfen andere Codes verwenden | ### Guidance-Zwecke | Zweck | Bedeutung | |---------|---------------| | `minimum` | Alle konformen Anwendungen **müssen** diese Codes als gültig akzeptieren (Anwendungspflicht, keine Instanz-Constraint) | | `candidate` | Kann das Haupt-ValueSet in dokumentierten Situationen ersetzen (z. B. wenn eine Jurisdiktion einen Ersatz definiert) | | `preferred` | Dieses ValueSet wird in einem bestimmten Kontext bevorzugt (die Dokumentation sollte erläutern, warum) | | `ui` | Vorgeschlagene Codes für die **Benutzeroberflächen**-Suche und -Auswahl | | `starter` | Eine praktische **Teilmenge** zum Einstieg, wenn das vollständige ValueSet zu groß ist | | `component` | Dokumentiert, wie ein **Teil** des Haupt-ValueSets verwendet wird (z. B. pro Code-System) | 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. {% hint style="info" %} Der Zweck `maximum` existiert in R5, ist aber **in R6 veraltet**. Er war ursprünglich dazu gedacht, extensible Bindings zu begrenzen, aber seine Semantik war unklar (siehe die Extensible+Max-Saga oben). Verwenden Sie stattdessen `required` mit einem Nutzungskontext. {% endhint %} ## Über FHIR-Versionen hinweg | Version | Funktionsweise von Additional Bindings | |---|---| | **R4 und früher** | Nicht nativ. Verwenden Sie die [additional-binding-Extension](https://hl7.org/fhir/tools/StructureDefinition-additional-binding.html) aus dem Tooling Extensions IG. Der IG Publisher stellt sie dar; der Validator unterstützt sie. Die alten `maxValueSet`- und `minValueSet`-Extensions funktionieren noch, sind aber abgelöst. | | **R5** | Nativ als `ElementDefinition.binding.additional`. Vollständige Validator-Unterstützung. Kein `key`-Element – die Einschränkung von Additional Bindings in abgeleiteten Profilen ist begrenzt. | | **R6** | Nativ + `key`-Element zur Einschränkung über Profil-Ebenen hinweg. Neue Zwecke: `current-extensible`, `best-practice`, `open`. `maximum` veraltet. | Für R4-IGs werden Additional Bindings als Extension auf `ElementDefinition.binding` ausgedrückt: ```yaml 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: ```yaml 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`: ```yaml 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](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Context%20Dependent%20Additional%20Bindings). `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: ```yaml # 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](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Context%20Dependent%20Additional%20Bindings): „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: ```yaml # 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](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Implementiing%20Additional%20Bindings%20for%20each%20purpose%20unclear) 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](https://build.fhir.org/ig/FHIR/ig-guidance/). 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](https://chat.fhir.org/#narrow/stream/implementers/topic/Conditional%20additional%20bindings) (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](http://hl7.org/fhir/R5/elementdefinition-definitions.html#ElementDefinition.binding.additional) – formale Definition - [Additional Binding Purpose Codes](http://hl7.org/fhir/R5/codesystem-additional-binding-purpose.html) – alle Zweck-Codes mit Definitionen - [Terminologies: Binding Strengths](https://www.hl7.org/fhir/terminologies.html#strength) – wie Stärken mit Additional Bindings funktionieren - [Binding Examples](http://hl7.org/fhir/terminologies-binding-examples.html) – ausgearbeitete Beispiele - [Tooling Extensions IG](https://hl7.org/fhir/tools/StructureDefinition-additional-binding.html) – R4-Backport-Extension **Community ([chat.fhir.org](https://chat.fhir.org)):** - [Extension for additional bindings](https://chat.fhir.org/#narrow/stream/terminology/topic/Extension%20for%20additional%20bindings) – der ursprüngliche Vorschlag von 2022 von Grahame Grieve (49 Nachrichten) - [Implementing Additional Bindings for each purpose](https://chat.fhir.org/#narrow/stream/IG.20creation/topic/Implementiing%20Additional%20Bindings%20for%20each%20purpose%20unclear) – UND- vs. ODER-Semantik, Anwendungsfall-Matrix (27 Nachrichten) - [Conditional additional bindings](https://chat.fhir.org/#narrow/stream/implementers/topic/Conditional%20additional%20bindings) – UsageContext-Eingrenzung (66 Nachrichten) - [Extensible+Max](https://chat.fhir.org/#narrow/stream/argonaut/topic/Extensible%2BMax) – das Prä-R5-Muster (182 Nachrichten) - [Modifications to ElementDefinition](https://chat.fhir.org/#narrow/stream/fhir.2Finfrastructure-wg/topic/Modifications%20to%20ElementDefinition) – formale R5-Zusage (111 Nachrichten) Siehe auch: [Residualkategorien in der FHIR Terminology](/blog/residual-categories-in-fhir-terminology).