September ballot on track, ViewDefinition graduates to additional resource, and terminology as tables — Sep 1, 2026
URL bug in composite ViewDefinition SearchParameters — trivial source fix
Steve Munini kicked off with a concrete find: switching his team's codebase from copy-pasting spec content to consuming the published hl7.fhir.uv.sql-on-fhir 3.0.0-ballot package surfaced two composite SearchParameters (ViewDefinition-context-type-quantity and ViewDefinition-context-type-value) that still reference legacy uv/sql-on-fhir canonicals in the source XML. Grahame Grieve had already patched the publisher build so the published artefact is fine, but the IG source still needs correcting.
Gino Canessa took the action to submit a PR against the source and file a Jira ticket so the fix shows up in the ballot dashboard.
Those should be changed to roots within… we defined all of them in our package, and publisher went and changed the core ones to be hl7.org/fhir URLs rooted because they're ViewDefinition URLs. So really we should just change them in our source anyway.
ViewDefinition as an additional resource in R6
The URL bug opened a longer thread on what a ViewDefinition actually is in R6. It is an "additional resource" — defined in the SQL on FHIR IG rather than FHIR core, following the same pattern as TestScript, TestPlan, and the capability statement IG. The SQL on FHIR IG will be the authoritative source; once R6 publishes (targeted H1 2027), the group can release new ViewDefinition versions on its own cadence instead of being bound to the FHIR core release cycle.
Gino noticed ViewDefinition is not listed on the FHIR Incubators overview page and that the resource proposal paperwork appears to be missing altogether. He is filing it with FMG to avoid surprises before publication.
We can start publishing once R6 is done, which should be H1 of 27. From that point on, we publish a new ViewDefinition whenever we feel the need to.
Michael E Campbell asked about the path to normative. Gino was blunt: not on the near-term roadmap. Even if everything else were ready, it is already too late to add a new normative resource to R6, and the group does not see normative status as a realistic goal for quite a while.
September ballot — 13 affirmatives, 0 negatives, closes Sep 14
The September 2026 ballot (BALDEF-2533) is open now and closes September 14. Voting is currently passing with 13 affirmatives and 0 negatives out of 151 eligible voters, with most eligible voters not yet having cast a vote. Larger organisations typically batch their reviews and file tickets late in the window, so Gino expects more submissions before close.
Ballot sign-up closed before the ballot opened (an ANSI rule to prevent stacking once totals become visible), which means Steve and John cannot vote on this cycle but can still file tickets — Gino offered to attach his vote to any change they want made.
Gino created two Jira dashboards while on the call: a general spec dashboard, and a ballot-specific one (dashboard ID 18524) to track incoming tickets. Every ballot ticket has to be resolved before publication, but the group's real deadline is R6 publishing (targeted H1 2027), since SQL on FHIR 3.0 depends on it.
Terminology abstraction — tabular schema vs FHIRPath functions
John Grimes opened the terminology thread by relaying feedback from Grahame Grieve at the AU connectathon. Two approaches are on the table and they are not mutually exclusive:
- A tabular abstraction where a value set behaves like a SQL table or view — pre-expanded and joinable, treated like any other table in the query
- FHIRPath terminology functions (
memberOf,subsumes,translate, plus%terminologies.*) as an optional runner capability
Grahame's concern is pushing complexity of terminology querying back to the query author. Brian Postlethwaite has a proposal to rationalise the existing FHIRPath terminology functions and add an inline translate, which John sees as a potential foundation for an optional terminology profile in SQL on FHIR runners.
Nikolai Ryzhikov argued the relational model — inspired by OMOP's Athena — covers most of what people actually need, is more "white box" than a FHIR terminology server, and takes less energy to implement. Health Samurai's Termbox is built on this approach.
Athena can cover like 90% of what FHIR wants to do. Athena is more white box than the FHIR black box… the guys can share more implementation, so it's economically less energy to implement.
Gino pushed back on the 90% figure, pointing out Athena does not cover post-coordinated SNOMED ECL codes, which are in active use. John extended the point beyond post-coordination: even querying pre-coordinated codes ("give me everything under this body site") needs a level of query expressivity that VCL captures well.
Guillermo Rodríguez, from Health Samurai's terminology team, confirmed the current relational model handles roughly 80% of cases without an expansion engine — but SNOMED-specific features like ECL and post-coordinated code validation still require an additional layer.
The model we have right now is not enough. We are able to solve like 80% of the problem without any engine for expanding value sets, but later we need something else to add more. There will be a percentage I don't see how to solve yet — that is the border.
John's read is that VCL is a good functional boundary: pre-coordinated subsumption and membership can be handled relationally; post-coordination requires a classifier and should be handed off to a terminology engine.
You're not going to be able to do any post-coordination without a classifier. You need to hand off to some sort of terminology engine or server anyway for that case.
Value set as a table vs a view
Owen Loveluck pushed on the modelling choice. If a value set is a materialised expansion, a table makes sense; but if the expansion could be defined or derived, the abstraction feels more like a view. Nikolai's response was that "table" is one framing but the important part is the interface — the runner can reference a value set through relatedArtifact, give it a table name, and join against it in SQL, whether the underlying implementation is a pre-loaded expansion or computed on the fly.
We are not talking that it should be done on the fly. The idea is we can imagine it as freshly pre-expanded and loaded into database — a cache. Finally, when you do expansion, it is a flat table.
Value set versioning and lineage for audit use cases
Michael E Campbell raised the audit angle. For quality measures like HEDIS, measure rates can shift purely because the underlying value set changed between years, and that lineage has to be captured at the metadata level or the trend analysis is meaningless. John added that historical SNOMED CT data analysis requires sweeping through inactivated and replaced codes across releases via translate and version URLs — which pushes on both versioning and the terminology-function layer at the same time.
Follow-up: a dedicated terminology meeting
The group wants a deeper follow-up call on terminology abstraction. John will set it up and invite Grahame Grieve, Michael Lawley, Brian Postlethwaite, and Health Samurai's terminology team (Guillermo and Orlando). John also plans to demo Pathling's local terminology mode alongside its full server mode as concrete implementation reference points.