Value set as a relation: how far a relational terminology model goes before a classifier has to take over — Sep 8, 2026
Terminology abstraction — continuing last week's thread
With no formal agenda and the WGM approaching, the group picked up where it left off on terminology. John Grimes framed the question two ways: what abstraction do runners need for querying terminology, and — a separate but related problem Nikolai Ryzhikov has been circling — how do you distribute that terminology in the first place. John also pointed back at Pathling's local terminology mode as a working data point: seven relational tables built on roaring bitmaps that cover most of what analytic terminology needs, without letting the query author touch SQL.
The FHIRPath route is still live in parallel. Pathling has had terminology functions inside FHIRPath for years, and Brian Postlethwaite's cleanup proposal (including an inline translate) would make them more usable — but Grahame Grieve is wary of pushing terminology-query complexity onto query authors, and John relayed that concern.
Some things might be pretty simple, other things might actually require quite a chunk of SQL to actually do them properly.
Value set as a relation — Nikolai's framing
Nikolai's core claim: for most analytic queries, a pre-expanded value set is just a table you join against. You don't have to care whether it was materialised at load time, refreshed from a terminology server, or expanded on the fly — the abstraction is the relation.
He walked through the FHIR-to-OMOP case as the concrete driver. In OMOP, a single FHIR Observation can land in either the measurement or the observation table depending on the domain of the concept ID — which forces a terminology join that FHIRPath cannot express cleanly. And once you're writing multi-floor SQL to build a cohort ("women with these diseases, on these medications, with this temporal expression"), there is no place to slot a FHIRPath expression. The abstraction has to be relational at that layer.
We can treat the pre-expanded value set as a relation. How we got there, we don't know — fresh from terminology, expansion in our database, or pre-loaded. But it is abstraction, and I can join with it.
OMOP's Athena as the reference model — and where FHIR is a superset
Nikolai pointed at OMOP's Athena as evidence that a relational terminology distribution works in production — and at UMLS as the older, uglier, but similarly successful version of the same idea. His argument: informationally, FHIR terminology (code systems, concepts with properties, value sets with compose, concept maps) maps to a normal form of relational tables. Athena is essentially a subset of what FHIR can express; a FHIR-shaped relational model is more generic than Athena, not less.
Guillermo Rodriguez, from Health Samurai's terminology team, confirmed the current relational model in Termbox covers "almost everything" from the FHIR terminology resources at the logical layer. Storage and modelling are not the blocker — the additional processing to serve terminology operations in a form directly consumable from SQL is.
Right now I think we're able to express almost everything from the FHIR terminology resources into our model. But that's only the foundation. Serving the terminology operations in something like consumable information for analytics directly from SQL — we still need to make additional processing.
Where the model stops being enough: value sets that compose on other value sets and other code systems, very large code systems where you want an expression to pick out subsets, and anything that needs a classifier. Guillermo was blunt that some of these are not just performance issues — they raise real questions about feasibility of the query itself in pure SQL without an extra engine keeping a materialisation current.
Reproducibility: NCQA locks value sets per year
Michael E Campbell asked Arjun Sanyal — dropping by for the first time in a while — how measure-level value sets actually get pinned in practice. Arjun explained that NCQA locks value sets per measure on a yearly basis: the measure is published, the expansion is frozen, and if you want to re-run a prior year you need to have kept both the measure and that year's value-set expansion as a pair.
If you want to rerun something from the past, this is one of the most challenging parts of a HEDIS-style calculation — you have to have persistence of that year's value sets for that measure. You have to keep them as a pair.
Guillermo pointed out that the FHIR way to handle this is version-pinning inside the value set itself, plus capturing the expansion input parameters on the resulting ValueSet.expansion.parameter — a well-behaved terminology server should be able to reproduce the same expansion later, even against newer content. Nikolai's summary: expansion is logically a pure function of pinned versions plus parameters, and its output is a table of concepts. Which loops back to the "value set as relation" framing.
Where a classifier still has to take over
Gino Canessa pushed back on how much of the SNOMED semantics you actually want to lift into SQL. His example — myocardial infarction as a finding of a body site and an associated morphology of an infarction — is the kind of query where SNOMED distributes classified relationships in RF2 precisely because you can't rederive the hierarchy from the source data with a generic tool. SNOMED International classifies internally with a specific version of ELK and ships the inferred is-a graph as part of the release. Post-coordinated expressions and MRCM validation are a separate layer entirely.
Nikolai's counter: for pre-coordinated codes and the is-a graph, you can express it in a relational model — that is exactly what OMOP cohorts do all day against the ancestry table, and it works. Post-coordination is a smaller share of the real-world usage than the discussion made it sound.
If we're talking about this very crazy stuff, it's probably one percent of the real world.
John landed the boundary: pre-coordinated subsumption and membership can be relational; post-coordination and MRCM need a classifier and should be handed off to a terminology engine.
Two abstraction levels, two use cases
Steve Munini asked the framing question directly: is this problem only surfacing because SQL on FHIR added SQLQuery alongside ViewDefinition, or is it genuinely impossible to do performantly through view definitions and a terminology server? Nikolai's answer: both. There is a flattening phase — building the marts — where you can normalise terminology (translating ICD to SNOMED, for example) with FHIRPath-style helpers before the data lands in a table. And there is a querying phase — building cohorts and measures — where the terminology has to be joinable in SQL because the query itself is SQL.
John's synthesis after the back-and-forth was that the two approaches co-exist and can be powered from the same source of truth. A SQL on FHIR runner can:
- Ship a pre-baked expansion table for the simple, common case — you know your value sets up front and just want membership joins
- Layer FHIRPath terminology functions (
memberOf,subsumes,translate) for query-time work at the view layer - Expose a table-based abstraction — value sets as relations, closure tables for subsumption, concept-map tables for translation — for the complex analytic case where you need to join into cohort SQL
- Hand off to a terminology server or classifier for post-coordination and anything MRCM-shaped
Whether you export tables from a terminology server, load a distribution like Athena, or query the server live, the same governance and content pipeline can sit behind all three surfaces. Gino's caution: whatever you choose, the complexity does not disappear — it just moves. The design question is where you want the query author to meet it.
Next step: a proof of concept, and a follow-up terminology call
John wants a proof of concept in the reference implementation — with a diverse enough set of use cases (SQL metrics with membership, plus FHIR-to-OMOP with the domain-driven table split) to show whether the tabular abstraction actually earns its keep. Nikolai will spend more time with Athena, and Health Samurai's terminology team continues the FHIR-shaped relational model in Termbox. The dedicated terminology follow-up call with Grahame Grieve, Michael Lawley, Brian Postlethwaite, and Health Samurai's terminology team is still on John's action list — pushed slightly by the WGM proximity but not dropped.