residual-categories-in-fhir-terminology

{ "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 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.

Siehe auch: Zweiphasige FHIR Terminology.