---
{
  "title": "Les catégories résiduelles dans la Terminology FHIR expliquées",
  "description": "Ce que signifient les catégories résiduelles dans la Terminology FHIR, comment elles influencent la création de ValueSet, et les pièges à éviter lors de la modélisation de concepts cliniques.",
  "date": "2026-03-16",
  "author": "Nikolai Ryzhikov",
  "reading-time": "3 min read",
  "tags": [
    "Terminology",
    "FHIR Standard",
    "Methodology"
  ],
  "tldr": "Les codes comme « other » et « unknown » dans les ensembles de valeurs sont définis par négation — leur signification change chaque fois que l'ensemble de valeurs est mis à jour. Cela corrompt silencieusement les données historiques et rend toute évolution sûre de la terminologie impossible. Utilisez plutôt des liaisons extensibles avec des codes spécifiques."
}
---
Certaines classifications médicales comportent des valeurs d'échappement — des codes comme `other`, `unknown`, `unspecified`, `not elsewhere classified`. Dans la théorie de la classification, ce sont des **catégories résiduelles** — des fourre-tout pour les données qui ne correspondent à aucune catégorie nommée. ICD utilise les suffixes `.8` et `.9` (NEC et NOS), HL7 v3 avait des saveurs nulles sur presque chaque attribut, et de nombreux ensembles de valeurs FHIR en contiennent également. Elles sont définies non pas par ce qu'elles *sont*, mais par ce qu'elles ne *sont pas* — une conjonction de négations : `other = ¬A ∧ ¬B ∧ ¬C`.

Les catégories résiduelles sont une mauvaise idée. Voici pourquoi : elles **corrompent les données existantes lorsque les terminologies évoluent**. Dans la version v1 d'un ensemble de valeurs, vous avez les codes `A`, `B` et `other`. `other` signifie « tout ce qui n'est pas A ou B ». Vous collectez un million d'enregistrements, certains codés comme `other`. Dans la version v2, l'ensemble de valeurs ajoute le code C. Désormais, `other` signifie « tout ce qui n'est pas A, B ou C » — mais votre million d'enregistrements indiquent toujours `other` avec l'ancienne signification, plus large. Certains d'entre eux sont en réalité C, mais il est impossible de déterminer lesquels. Le code est identique, la signification est différente. Chaque code ordinaire conserve sa signification entre v1 et v2. `other` est le seul code dont la signification **se rétrécit** à chaque mise à jour — et les données enregistrées sous l'ancienne signification sont **silencieusement corrompues**. Avec des téraoctets de données historiques, les requêtes rétrospectives et les analyses mélangent la sémantique v1 avec celle de v2, produisant des **résultats erronés sans aucune indication d'erreur**. ConceptMap ne peut pas exprimer ce mappage (un-à-plusieurs avec perte d'information), et l'agrégation entre systèmes échoue silencieusement (deux systèmes utilisant des versions différentes de l'ensemble de valeurs ont des codes `other` identiques qui signifient des choses différentes).

Vous pourriez tenter de corriger cela en épinglant des versions explicites de l'ensemble de valeurs à chaque valeur codée — mais cela échange un problème contre un autre : l'enfer des versions, où chaque requête, chaque mappage et chaque agrégation doit tenir compte de la version de `other` contre laquelle chaque enregistrement a été codé. Le remède n'est peut-être pas meilleur que le mal.

Si vous vous trouvez à avoir besoin de `other` dans un ensemble de valeurs, l'élément ne devrait pas être de type `code` avec une liaison `required`. Un élément `code` avec une liaison requise signifie que vous affirmez que la classification est exhaustive — chaque valeur possible figure dans la liste. Dès que vous ajoutez `other`, vous admettez que ce n'est pas le cas. Le bon choix est `CodeableConcept` avec une liaison `extensible` : l'ensemble de valeurs de base couvre les cas connus, et les implémenteurs ajoutent des codes spécifiques pour le reste. Réservez `code` + `required` aux classifications qui sont véritablement fermées et complètes — comme `active | inactive` ou `male | female | other | unknown` (et même ce dernier exemple est discutable).

Même lorsque des valeurs d'échappement sont disponibles dans un ensemble de valeurs FHIR — et elles le sont, partout dans la spécification — préférez ne pas les utiliser. Utilisez des [liaisons](/blog/fhir-additional-bindings) `extensible` avec des codes spécifiques, définis positivement. Utilisez `data-absent-reason` lorsque des données sont véritablement manquantes — c'est une méta-déclaration sur *pourquoi* une valeur est absente, et non une valeur clinique en soi. Traitez chaque `other` dans vos données de production comme un signal indiquant que l'ensemble de valeurs a besoin d'être étendu.

À la base, il s'agit de l'**hypothèse du monde ouvert par opposition au monde fermé**. Un monde fermé dit : tout ce qui n'est pas explicitement listé est faux. Cette façon de penser vous pousse à créer `other` — parce que chaque enregistrement *doit* avoir un code, et si la vraie réponse ne figure pas dans la liste, vous avez besoin d'un fourre-tout. Un monde ouvert dit : si vous ne savez pas quelque chose, laissez-le indéfini. Vous n'avez pas besoin de `other` parce que l'absence d'un code spécifique n'est pas un échec — c'est honnête. Les terminologies médicales vivent dans un monde ouvert : de nouvelles maladies apparaissent, la compréhension clinique évolue, les classifications se transforment. Concevoir des ensembles de valeurs comme si le monde était fermé — et boucher les lacunes avec `other` — c'est combattre la réalité avec un code qui aggrave les choses.

## Participer à la discussion

Participez à la discussion et partagez vos cas limites sur [Zulip](https://connect.health-samurai.io/).

Voir aussi : [La Terminology FHIR en deux phases](/blog/two-phase-fhir-terminology).