---
{
  "title": "Residualkategorien in der FHIR Terminology erklärt",
  "description": "Was Residualkategorien in der FHIR Terminology bedeuten, wie sie das Verfassen von ValueSets beeinflussen und welche Fallstricke beim Modellieren klinischer Konzepte zu vermeiden sind.",
  "date": "2026-03-16",
  "author": "Nikolai Ryzhikov",
  "reading-time": "3 min read",
  "tags": [
    "Terminology",
    "FHIR Standard",
    "Methodology"
  ],
  "tldr": "Codes wie „other" und „unknown" in Value Sets sind durch Negation definiert – ihre Bedeutung ändert sich jedes Mal, wenn das Value Set aktualisiert wird. Dadurch werden historische Daten unbemerkt korrumpiert und eine sichere Weiterentwicklung der Terminology wird unmöglich. Verwenden Sie stattdessen extensible Bindings mit spezifischen Codes."
}
---
Einige medizinische Klassifikationen verfügen über Ausweichcodes – Codes wie `other`, `unknown`, `unspecified`, `not elsewhere classified`. In der Klassifikationstheorie werden diese als **Residualkategorien** bezeichnet – Auffangbecken für Daten, die in keine der benannten Kategorien passen. ICD kennt die Suffixe `.8` und `.9` (NEC und NOS), HL7 v3 hatte Null Flavors an nahezu jedem Attribut, und viele FHIR-Value-Sets enthalten sie ebenfalls. Sie sind nicht dadurch definiert, was sie *sind*, sondern durch das, was sie *nicht sind* – eine Konjunktion von Negationen: `other = ¬A ∧ ¬B ∧ ¬C`.

Residualkategorien sind eine schlechte Idee. Hier ist der Grund: Sie **korrumpieren vorhandene Daten, wenn sich Terminologien weiterentwickeln**. In v1 eines Value Sets gibt es die Codes `A`, `B` und `other`. `other` bedeutet „alles, was nicht A oder B ist." Sie erfassen eine Million Datensätze, einige davon mit dem Code `other`. In v2 wird dem Value Set der Code C hinzugefügt. Nun bedeutet `other` „alles, was nicht A, B oder C ist" – aber Ihre Million Datensätze enthalten noch immer `other` mit der alten, weiteren Bedeutung. Einige davon sind tatsächlich C, aber es gibt keine Möglichkeit festzustellen, welche. Der Code ist derselbe, die Bedeutung ist eine andere. Jeder reguläre Code behält seine Bedeutung zwischen v1 und v2. `other` ist der einzige Code, dessen Bedeutung sich mit jeder Aktualisierung **verringert** – und die unter der alten Bedeutung erfassten Daten werden **unbemerkt korrumpiert**. Bei Terabytes historischer Daten vermischen retrospektive Abfragen und Analysen v1-Semantik mit v2-Semantik und produzieren **falsche Ergebnisse ohne jeden Hinweis auf einen Fehler**. ConceptMap kann dieses Mapping nicht ausdrücken (eins-zu-viele mit Informationsverlust), und systemübergreifende Aggregationen schlagen stillschweigend fehl (zwei Systeme mit unterschiedlichen Value-Set-Versionen haben identische `other`-Codes mit unterschiedlicher Bedeutung).

Man könnte versuchen, dieses Problem zu lösen, indem man jeder codierten Entität explizite Value-Set-Versionen zuweist – aber damit tauscht man ein Problem gegen ein anderes: Versions-Chaos, bei dem jede Abfrage, jedes Mapping und jede Aggregation berücksichtigen muss, gegen welche Version von `other` jeder Datensatz codiert wurde. Die Lösung ist möglicherweise nicht besser als das Problem.

Wenn Sie feststellen, dass Sie `other` in einem Value Set benötigen, sollte das Element nicht vom Typ `code` mit einem `required` Binding sein. Ein `code`-Element mit einem required Binding bedeutet, dass Sie behaupten, die Klassifikation sei vollständig – jeder mögliche Wert ist in der Liste enthalten. In dem Moment, in dem Sie `other` hinzufügen, geben Sie zu, dass dies nicht der Fall ist. Die richtige Wahl ist `CodeableConcept` mit einem `extensible` Binding: Das Basis-Value-Set deckt die bekannten Fälle ab, und Implementierer fügen für den Rest spezifische Codes hinzu. Reservieren Sie `code` + `required` für Klassifikationen, die wirklich abgeschlossen und vollständig sind – wie `active | inactive` oder `male | female | other | unknown` (und selbst dieses letzte Beispiel ist diskutabel).

Auch wenn Ausweichcodes in einem FHIR-Value-Set verfügbar sind – und das sind sie durchgehend in der Spezifikation – sollten Sie es vorziehen, sie nicht zu verwenden. Verwenden Sie `extensible` [Bindings](/blog/fhir-additional-bindings) mit spezifischen, positiv definierten Codes. Verwenden Sie `data-absent-reason`, wenn Daten tatsächlich fehlen – es handelt sich dabei um eine Meta-Aussage darüber, *warum* ein Wert fehlt, und nicht um einen klinischen Wert an sich. Betrachten Sie jedes `other` in Ihren Produktionsdaten als Signal, dass das Value Set erweitert werden muss.

Im Kern geht es hier um die **Open-World- versus Closed-World-Annahme**. Die Closed-World-Annahme besagt: Alles, was nicht explizit aufgeführt ist, ist falsch. Diese Denkweise verleitet dazu, `other` zu erstellen – weil jeder Datensatz *zwingend* einen Code haben muss und, wenn die eigentliche Antwort nicht in der Liste steht, ein Auffangbecken benötigt wird. Die Open-World-Annahme besagt: Wenn Sie etwas nicht wissen, lassen Sie es undefiniert. Sie brauchen `other` nicht, weil das Fehlen eines spezifischen Codes kein Versagen ist – es ist ehrlich. Medizinische Terminologien leben in einer offenen Welt: Neue Krankheiten entstehen, das klinische Verständnis wandelt sich, Klassifikationen entwickeln sich weiter. Value Sets so zu gestalten, als ob die Welt geschlossen wäre – und die Lücken mit `other` zu stopfen –, bedeutet, gegen die Realität anzukämpfen mit einem Code, der die Dinge nur verschlimmert.

## An der Diskussion teilnehmen

Nehmen Sie an der Diskussion teil und teilen Sie Ihre Grenzfälle in [Zulip](https://connect.health-samurai.io/).

Siehe auch: [Zweiphasige FHIR Terminology](/blog/two-phase-fhir-terminology).