Ballot reconciliation, terminology in SQL from Helios and Aidbox, and a CMS transpiler — Oct 27, 2026
Ballot reconciliation: a passing ballot that still has to be worked through
John Grimes opened with the item the group had been circling for weeks without touching: ballot reconciliation. The ballot is already in a passing state with 64 affirmative and 6 negative votes, which clears the quorum and affirmative thresholds, but every ballot ticket still has to be resolved before publication, and publication itself has to wait for R6 - currently expected by July.
Gino Canessa walked the Jira dashboard. There are 15 open ballot issues plus 9 non-ballot issues the group wants to close before publishing. The split between technical corrections and change requests matters for the mechanics: technical corrections (US English, typo fixes) can be applied without a vote, while change requests need a block vote or individual resolutions during a meeting. Negative-vote submitters are then asked to retract once their ticket is addressed.
Theoretically we could publish, but we want to resolve everything we can first. We've already met the quorum and the affirmative requirements, so we can theoretically not resolve them to their satisfaction, but we have to resolve every ballot ticket before we can go to the next stage of publishing anyway.
The plan: John takes technical corrections and asynchronous comment work in Jira; Gino's agent drafts proposed dispositions for the open tickets (his earlier September 21 run no longer covers most of what is now in the queue); and ballot reconciliation becomes a standing agenda item occupying up to half of each meeting until the queue is empty. A community PR, #406, adds date and uri to the primitives-only invariant and still needs review.
ValueSet dependencies as relatedArtifact on ViewDefinition
John presented a draft optional profile sitting alongside shareable and tabular - call it the "terminology dependent" profile for now, pending a better name - that adds a single FHIRPath function, memberOf, so views can test value set membership at the view layer in addition to in the SQL layer. Nikolai Ryzhikov pushed back on the implicit way value sets would be declared: parsing them out of FHIRPath expressions is possible, but awkward for packaging and dependency tracking.
If we're coming to building packages, resolving canonicals, building a dependency tree for canonical resources - it would be much nicer if you had it in
relatedArtifactthan trying to parse inside a FHIRPath expression. Then you can package it in a CRMI style, calculate dependencies, and so on.
Gino Canessa flagged that the metadata resource interface already defines relatedArtifact with a 0..* cardinality, and since nothing has been published yet, surfacing it on ViewDefinition is neither a breaking change nor particularly novel - every other canonical knowledge artifact already has it. John agreed to profile it to point specifically at value sets and to add guidance on whether declaring the value set is mandatory. Nikolai and Steve Munini both landed on mandatory:
If you're going to use
memberOf, you have to haverelatedArtifact.
John will add this to the draft PR (#412) for another round of discussion.
Two terminology-in-SQL implementations shipping, and the conformance tests that follow
Steve Munini demoed Helios's implementation, released the weekend before the meeting. The approach is deliberately straightforward: when a view is created with a relatedArtifact for a value set or concept map, Helios calls the terminology server, expands or pulls the artifact in full, and plants it into a dedicated table. When the last resource referencing that artifact is deleted or updated, the table is dropped so the database stays clean. Helios runs this on SQLite, Postgres, and MongoDB.
We took a pretty straightforward approach. For the related artifacts, we just create a table. If you're creating a view, it's calling the terminology server, doing the expand, and placing that in a separate table.
John Grimes noted the pattern matches what Pathling does, and that the polishing items - table lifetime, invalidation - can come after the mechanism itself is proven.
Nikolai then showed where Health Samurai's version has landed in Aidbox. The layout is different: rather than one table per value set, the team uses a single shared value-set table with views on top. The value-set builder is already open-source as part of the Aidbox UI, and the full release is one or two weeks out. Nikolai also walked through slides generated inside hyper-code with Nano Banana, with a live Aidbox iframe embedded as a dashboard inside the presentation itself.
Both implementations now need a shared conformance suite. Nikolai volunteered to write it, with a deliberate design choice to express it as an API client against the $run operation - which has the side benefit of forcing API support for implementers, not just FHIRPath or SQL support.
Our guy started doing the conformance test framework in TypeScript. Because it's API, I don't see the difference - this framework is built from modules, and that could be one of the modules. Like Inferno 2.0, more agentic-friendly.
John wants the tests to feed a compliance view analogous to the one that already exists for ViewDefinition, so that each implementation's coverage is visible and the pattern can pull more implementers into the game.
Vector tables: describable with type hints, not interoperable yet
Gino was asked whether SQL on FHIR can describe a vector table - someone wanting to add vector search to their FHIR store had asked the question, and no one in the group had tried it. Nikolai's take was that type hints and extensions could cover the description layer, but the result would not be portable until the SQL standard itself introduces a vector type.
It's not going to be interoperable, but maybe eventually when the SQL standard will incorporate vectors.
Nikolai was explicit that adding vector operations to FHIRPath is a non-starter; the right place for the operation itself is inside the database, with SQL on FHIR describing only the shape of the table. Gino will spend some cycles on it himself.
Pitching proprietary servers, and a scheduling view from Adam
Gino pitched SQL on FHIR to the Epic team the previous week - the pitch being that publishing the schema through SQL on FHIR would let analytics clients issue queries directly without a custom integration for every project. Epic's immediate response was that those are different servers right now, which Gino read as planting a seed rather than expecting a yes at a conference.
John framed the adoption path as deliberately light-touch: a proprietary system can expose a thin SQL on FHIR layer by mapping its primitives onto the spec's primitives, which is a connectathon-sized piece of work rather than a rewrite. Nikolai added that the design always kept this case in mind:
Even if people have trouble supporting the full spec, they can still just expose like 10 tables. It shouldn't cost too much for them - simpler than mapping to FHIR, but data becoming available through a standard interface, so people can transform it in ELT style in the database further.
Adam Culbertson picked up the thread for a concrete case: pulling scheduling slots through a view definition rather than through bulk publish. He already has a rough demo using view definitions on top of the base version of sports scheduling links, and is considering publishing a sample scheduling ViewDefinition as part of the IG. John offered him meeting time once there is something demoable, and reminded the group that IGs can now package both ViewDefinitions and SQL libraries, with the IG builder rendering them cleanly.
CMS measures as ViewDefinitions, and a possible FHIR education course
Nikolai flagged work from Marat Surmashev - Health Samurai's VP of Engineering - who built a transpiler that converts complex SQL quality-measure programs into ViewDefinitions and SQL views. Roughly 30 CMS and star metrics have been converted so far, with some corner cases still to resolve. Nikolai will propose inviting Marat to demo it either at this group or at the Analytics on FHIR conference.
Michael E Campbell relayed a note from a recent CQL course with Benji: the instructor called out SQL on FHIR specifically as the scalability option for population-health reporting.
He covered quite well that there was definitely a limitation to CQL, and really called out very specifically the work that you guys were doing on SQL on FHIR as the real scalability option. So it's really getting out there - this is the direction they see the industry moving for population health reporting.
John framed the connection: running CQL on a single patient for clinical decision support and running population-level indicators are two different problems with different implementation considerations, and SQL on FHIR is the layer that lets the same logic be defined consistently across both. Adam volunteered to put together a FHIR educational course on SQL on FHIR once the spec is balloted; Nikolai supported the idea.
Scheduling: Analytics on FHIR conference dates still open
Nikolai flagged that the Analytics on FHIR conference dates remain unresolved - it is likely two days rather than one, but the schedule has to work for John's and Grahame's time zones. John has an outstanding message from Valeria to reply to and will do so immediately after the meeting; the open dates are what is blocking the event from being published.