---
{
  "title": "Las categorías residuales en FHIR Terminology explicadas",
  "description": "Qué significan las categorías residuales en FHIR Terminology, cómo afectan a la autoría de ValueSet y los errores que hay que evitar al modelar conceptos clínicos.",
  "date": "2026-03-16",
  "author": "Nikolai Ryzhikov",
  "reading-time": "3 min read",
  "tags": [
    "Terminology",
    "FHIR Standard",
    "Methodology"
  ],
  "tldr": "Códigos como «other» y «unknown» en los conjuntos de valores se definen por negación: su significado cambia cada vez que se actualiza el conjunto de valores. Esto corrompe silenciosamente los datos históricos e imposibilita una evolución segura de la terminología. Utilice enlaces extensibles con códigos específicos."
}
---

> For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt).
> Use it to discover all available pages before guessing URLs.

---
Algunas clasificaciones médicas tienen valores de escape: códigos como `other`, `unknown`, `unspecified`, `not elsewhere classified`. En la teoría de la clasificación, estas son **categorías residuales** — cajones de sastre para datos que no encajan en las categorías con nombre. ICD tiene los sufijos `.8` y `.9` (NEC y NOS), HL7 v3 tenía «null flavors» en casi todos los atributos, y muchos conjuntos de valores de FHIR también los incluyen. Se definen no por lo que *son*, sino por lo que *no son* — una conjunción de negaciones: `other = ¬A ∧ ¬B ∧ ¬C`.

Las categorías residuales son una mala idea. He aquí el motivo: **rompen los datos existentes cuando las terminologías evolucionan**. En la v1 de un conjunto de valores se tienen los códigos `A`, `B` y `other`. `other` significa «todo lo que no es A ni B». Se recopilan un millón de registros, algunos codificados como `other`. En la v2, el conjunto de valores añade el código C. Ahora `other` significa «todo lo que no es A, B ni C», pero el millón de registros sigue diciendo `other` con el significado anterior, más amplio. Algunos de ellos son en realidad C, pero no hay forma de saber cuáles. El código es el mismo; el significado es diferente. Todos los códigos ordinarios conservan su significado entre la v1 y la v2. `other` es el único código cuyo significado **se reduce** con cada actualización, y los datos registrados bajo el significado anterior quedan **silenciosamente corrompidos**. Con terabytes de datos históricos, las consultas retrospectivas y los análisis mezclan la semántica de la v1 con la de la v2, produciendo **resultados erróneos sin ninguna indicación de error**. ConceptMap no puede expresar esta correspondencia (de uno a varios con pérdida de información), y la agregación entre sistemas falla silenciosamente (dos sistemas con versiones diferentes del conjunto de valores tienen códigos `other` idénticos que significan cosas distintas).

Se podría intentar solucionar esto fijando versiones explícitas del conjunto de valores en cada valor codificado, pero eso intercambia un problema por otro: el infierno de las versiones, donde cada consulta, cada correspondencia y cada agregación debe tener en cuenta contra qué versión de `other` se codificó cada registro. El remedio puede no ser mejor que la enfermedad.

Si se necesita `other` en un conjunto de valores, el elemento no debería ser de tipo `code` con un enlace `required`. Un elemento `code` con un enlace requerido implica que la clasificación es exhaustiva: todos los valores posibles están en la lista. En el momento en que se añade `other`, se admite que no lo es. La opción correcta es `CodeableConcept` con un enlace `extensible`: el conjunto de valores base cubre los casos conocidos, y los implementadores añaden códigos específicos para el resto. Reserve `code` + `required` para clasificaciones que sean genuinamente cerradas y completas, como `active | inactive` o `male | female | other | unknown` (e incluso ese último ejemplo es debatible).

Incluso cuando los valores de escape están disponibles en un conjunto de valores de FHIR —y lo están, a lo largo de toda la especificación—, es preferible no utilizarlos. Utilice [enlaces](/blog/fhir-additional-bindings) `extensible` con códigos específicos y definidos positivamente. Utilice `data-absent-reason` cuando los datos estén genuinamente ausentes: es una metadeclaración sobre el *motivo* de la ausencia de un valor, no un valor clínico en sí mismo. Trate cada `other` en sus datos de producción como una señal de que el conjunto de valores necesita ampliarse.

En el fondo, esto tiene que ver con la **suposición de mundo abierto frente a mundo cerrado**. Un mundo cerrado dice: todo lo que no figura explícitamente en la lista es falso. Esta mentalidad impulsa a crear `other`, porque cada registro *debe* tener un código y, si la respuesta real no está en la lista, se necesita un cajón para ella. Un mundo abierto dice: si no se sabe algo, déjelo sin definir. No se necesita `other` porque la ausencia de un código específico no es un fallo, sino honestidad. Las terminologías médicas viven en un mundo abierto: aparecen nuevas enfermedades, la comprensión clínica cambia y las clasificaciones evolucionan. Diseñar conjuntos de valores como si el mundo fuera cerrado —y tapar los huecos con `other`— es combatir la realidad con un código que empeora las cosas.

## Únase al debate

Únase al debate y comparta sus casos extremos en [Zulip](https://connect.health-samurai.io/).

Véase también: [Terminología FHIR en dos fases](/blog/two-phase-fhir-terminology).