Terminology relations draft PR, and StructureDefinition logical models for external tables — Oct 6, 2026
Ballot reconciliation parked for a side-sync
John Grimes opened by flagging that nobody on the call actually knew what ballot reconciliation entails procedurally. His understanding is a few working meetings to go through feedback, followed by something involving FHIR Infrastructure, but he wants to turn that into a chat-channel conversation on SQL on FHIR with the right people present and sync again next week. No one pushed back; the group moved on.
Terminology relations: value set membership and concept map translation
The main thread was John's work on terminology relations since the last meeting he attended. He has implemented value set membership and a concept map translation relation in both the SQL on FHIR reference implementation and Pathling, with a draft PR on the spec itself. The concept map relation is deliberately minimal - source, target, relationship type, with nulls on no-map rows to carry the "there is no mapping" case explicitly.
John demoed both. The reference implementation runs a cardiovascular-patients library that pulls a value set from either tx.fhir.org or a local file-system directory, matches patients by code membership, and returns the view. Pathling's version is config-plus-admin-UI shaped: register terminology dependencies alongside view-definition and SQL-query dependencies, let the engine resolve them (including implicit value sets via ECL or VCL URLs the terminology server already understands), then use them as relations in the query.
Nikolai Ryzhikov's ClickHouse implementation came in from the other direction. He loads terminology server expansions into a single concept table and builds views on top; the views behave as relations and are hard to distinguish from one.
I have a table with concepts. And I'm building views on top of concepts. So I'm loading data from terminology server, the expansion of value set into the one table. And then I'm creating view and view behaves like a relation. So it's hard to distinguish from relation.
Steve Munini's team deliberately hasn't implemented terminology yet - they are waiting to see where the spec lands. He has an issue filed and is still weighing tight coupling to the terminology server versus a looser just-create-tables-in-the-FHIR-server approach. John's upcoming end-to-end demo should give him enough to decide.
VCL, subsumption, and whether a dedicated relation is needed
The design debate inside the terminology thread was whether subsumption deserves its own relation. John's answer: value set membership plus VCL (value set compose language, the subset of value set composition that fits inside a URL and lets a terminology server resolve "all codes subsumed by X" without an explicit value set resource) covers the case well enough.
If you combine value set membership with VCL, you can have subsumption. So whether or not you want to have a dedicated subsumption relation is an open question.
Nikolai pushed on the complication John hinted at. For the naive implementation path - delegate expansion to the terminology server and load the result - VCL looks identical to any other value set URL. John clarified that VCL isn't a dependency of the terminology work; it was background context for why the subsumption case doesn't necessarily need its own relation. The implementation can treat any URL - value set, VCL, ECL - the same way, provided the resolver understands it.
Properties and designations got the same treatment and were left out of the PR. John found them polymorphic enough to be unpleasant to model as a relation, and - with value sets able to be defined on properties and designations handled via terminology server - the incremental value didn't justify the complexity.
Lifetime, freshness, and Aidbox's October target
Steve raised the question nobody had asked yet: when does any of this expire?
How do these things ever die? I'm just wondering about the lifetime of this stuff because you could just accumulate these and accumulate these, and these could be quite large over time.
Nikolai's answer: for one-off research you probably run on the fly, but for dashboards and clinical measures you materialize the view and cache the value set the same way you'd materialize a ViewDefinition. His separate concern was expansion parameters - whether anything that can be passed to a $expand operation materially affects the result in a way the relation can't capture. John's position is that for analytics almost everything that matters is in the value set definition itself; expansion parameters are mostly about request mechanics (page size, filtering for autocomplete, language packs). VCL is just another expression of a value set definition, so the same rule applies.
Pathling handles freshness with a client-side in-memory cache keyed on ETags from the terminology server, which lets it validate or expire entries incrementally. The reference implementation is naive and fetches every time. Nikolai noted that Aidbox is targeting an October release of this feature - ambitious but tractable since Aidbox and Termbox already keep concept maps and value sets split into relational form internally.
External tables via StructureDefinition logical models
Nikolai raised the one remaining gap for the FHIR-to-OMOP use case: a way to describe external tables (Athena, CSVs, Parquet files) as relations inside SQL on FHIR, so engines can load and join them without ad-hoc configuration. Pathling currently handles this via out-of-band config - register URI-to-location pairs ahead of time, then reference them with relatedArtifact - and uses it for things like MIMIC derived tables. The capability works; what the group wants to standardize is the reference mechanism.
Gino Canessa floated StructureDefinition logical models as the answer. Elements map to columns, FHIR types carry over with SQL type mappings via extensions, element ordering has defined meaning, and existing tooling for profiles and bindings becomes available for free.
We could probably also use structure definition as a logical model and build a profile that defines the SQL types and things like that. And if you just built the logical model that way and look through element definition as a logical model, if we constrain the types and things, that would actually have all kinds of things because we have constraints, we have bindings, we have fixed values, we have defaults.
Nikolai pointed out that this is essentially what the FHIR-to-OMOP IG already does - logical models for every OMOP table - which validates the approach. The group converged quickly. Gino is going to have an agent prototype a bidirectional converter between CREATE TABLE statements and conformant StructureDefinitions; John agreed that was the user-facing tooling question anyway. Extensions handle the SQL-dialect specifics (indexes, foreign keys, defaults, auto-increments) so the core model stays portable.
Nikolai also flagged Apache OC (universal data-catalog standard, Microsoft-backed, Power BI already translates to it) as a potential bridge from SQL on FHIR artifacts out to Unity Catalog and the broader data-catalog ecosystem - interesting but out of scope for the spec itself.
PRs reviewed
- sql-on-fhir.js uplift - open PR to align the reference implementation with ballot 3; John wants it merged before the terminology relations work layers on top.
- Terminology relations draft - John's spec PR defining the value set and concept map relations is up and open for review.
- View definition examples - Steve has a PR coming next week to fix incorrect or outdated examples; he is still working out whether the problem is in the examples themselves or in his queries against them.
John plans to revive the poll for terminology experts to review the design, and will bring a cleaner end-to-end demo (both reference impl and Pathling) to the next meeting.
Analytics on FHIR conference: seven to eight speakers, likely two days
Dates are not fixed yet - John needs to check availability and will loop in Valeria so the whole speaker set can be aligned. Current lineup is seven or eight speakers, which Nikolai suggested might stretch to two days with a few more invitations, possibly including speakers from the broader SQL world outside FHIR. Format will include a spec intro talk (Nikolai suggested John and Grahame Grieve could do a joint intro) and implementation showcases.