Some medical classifications have escape values — codes like other, unknown, unspecified, not elsewhere classified. In classification theory, these are residual categories — catch-all buckets for data that doesn't fit the named categories. ICD has .8 and .9 suffixes (NEC and NOS), HL7 v3 had null flavors on nearly every attribute, and many FHIR value sets include them too. They are defined not by what they are, but by what they are not — a conjunction of negations: other = ¬A ∧ ¬B ∧ ¬C.
Residual categories are a bad idea. Here is why: they break existing data when terminologies evolve. In v1 of a value set you have codes A, B, and other. other means "everything that isn't A or B." You collect a million records, some coded as other. In v2, the value set adds code C. Now other means "everything that isn't A, B, or C" — but your million records still say other with the old, broader meaning. Some of them are actually C, but there is no way to tell which ones. The code is the same, the meaning is different. Every regular code keeps its meaning between v1 and v2. other is the only code whose meaning shrinks with every update — and the data recorded under the old meaning is silently corrupted. With terabytes of historical data, retrospective queries and analytics mix v1 semantics with v2, producing wrong results without any indication of error. ConceptMap cannot express this mapping (one-to-many with information loss), and cross-system aggregation fails silently (two systems on different value set versions have identical other codes meaning different things).
You could try to fix this by pinning explicit value set versions to every coded value — but that trades one problem for another: version hell, where every query, every mapping, and every aggregation must account for which version of other each record was coded against. The cure may be no better than the disease.
If you find yourself needing other in a value set, the element should not be of type code with a required binding. A code element with a required binding means you claim the classification is exhaustive — every possible value is in the list. The moment you add other, you admit it isn't. The right choice is CodeableConcept with an extensible binding: the base value set covers the known cases, and implementers add specific codes for the rest. Reserve code + required for classifications that are genuinely closed and complete — like active | inactive or male | female | other | unknown (and even that last example is debatable).
Even when escape values are available in a FHIR value set — and they are, throughout the specification — prefer not to use them. Use extensible bindings with specific, positively-defined codes. Use data-absent-reason when data is genuinely missing — it is a meta-statement about why a value is absent, not a clinical value itself. Treat every other in your production data as a signal that the value set needs expansion.
At its root, this is about the open world vs. closed world assumption. A closed world says: everything not explicitly listed is false. This mindset pushes you to create other — because every record must have a code, and if the real answer isn't in the list, you need a bucket for it. An open world says: if you don't know something, leave it undefined. You don't need other because the absence of a specific code is not a failure — it's honest. Medical terminologies live in an open world: new diseases appear, clinical understanding shifts, classifications evolve. Designing value sets as if the world is closed — and plugging the gaps with other — is fighting reality with a code that makes things worse.
Join the discussion
Join the discussion and share your edge cases in Zulip.
See also: Two-phase FHIR terminology.
