Four operations collapse into two, the ViewDefinition inheritance fix, and version 3.0 for ballot — Aug 4, 2026
Collapse the four operations into two
The main agenda item was what shape to enter the ballot with. Today the spec has four operations — $viewdefinition-run, $sql-query-run, $viewdefinition-export, $sql-query-export — and John's in-flight PR #392 only aligns their parameters, not their count. Nikolai opened by proposing a much sharper cut: keep a single run and a single export at the system level, let the export accept view definitions, SQL views, and queries in the same job, and let the server advertise which of the three input shapes it supports. His core argument was transactional consistency — a single export produces one snapshot and avoids materialising shared dependencies twice.
So if we bulk export, I'm expecting I can do everything at once.
Steve Munini backed the reduction — he'd hit the same duplication in his own implementation, filed PRs trying to clean it up, and thought the cleanest move was to wipe the slate and settle on common operations. John agreed to draft the unified PR the same day and asked for multiple reviewers to turn it around fast; the group is out of time before the August 9 ballot deadline, so anything that ships has to be reviewed out of session.
Gino's guidance on ballot scope framed how much needed to be perfect: the shape has to be right, imperfect details are fine, and a ballot note flagging work-in-progress is acceptable.
No, what we want to make sure we go into the ballot is the right scope. Details, that's very expected to change. It's just when you're broadening scope that people then say, oh, you have to go back to ballot. So in general, as long as we have kind of the shape we want, if the details aren't perfect, that's fine. I would even put a ballot note in there saying, this is what we're in progress, please give us feedback.
Naming the operations and the "context canonical" parameter
Tentative operation names are sql-run and sql-export at the system level. John pushed back on tabular — some implementations emit non-tabular output, and "SQL" is specific to this spec anyway. Nikolai floated SQLX as a fallback if sql-export felt too close to something else; Gino liked SQL and tabular both, and joked about tubular for anyone who grew up in the nineties. John will pick one in the PR and iterate.
The bigger open question is what to call the parameter that carries inline dependency resources (view definitions, SQL views, value sets, concept maps down the road). Nikolai wants a generic name that grows with the spec:
My take is that eventually we will add value sets and concept maps. So I would just call it something like generic — TX resource, or context resource, or just canonical. So when we add more canonical resources into our system, we can reuse this context stuff.
Grahame's precedent from the ValueSet $expand operation uses tx-resource for a similar concept. Nikolai's leaning is context-canonical or just canonical, on the reasoning that the parameter really carries the resolution context for the operation. No name was locked in — John takes a first pass in the PR.
Version 3.0 and the breaking-changes page
The group agreed the new version is 3.0.0, subject to Grahame's approval. Gino's read is that this is a major departure for implementers because the additional-resource change comes on top of the other breaking pieces. John walked through what actually broke since 2.0.0:
- Canonical base URL change (
sql-on-fhir.org→http://hl7.org/fhir/uv/sql-on-fhir) - Package ID change
ViewDefinition.identifiercardinality (0..1→0..*) — the old0..1was counterintuitive and no one remembered where it came from- Tightened
sql-expressionsinvariant - Inherited
cnl-0/dom-6constraints now firing against 2.0.0-conformant views
Nikolai's concern is coexistence — someone with a 2.0.0 implementation and view definitions in the wild should be able to run both versions in the same server without conflict. He asked, and got, ownership of a dedicated changelog page that documents each breaking change with motivation and describes how the old and new versions can coexist. Gino confirmed TSC now requires every IG to publish a changelog; tying breaking changes to Jira tickets isn't strictly required for ballot but will be before final publication.
ViewDefinition inheritance — additional resource with MetadataResource
Brian noticed that ViewDefinition currently inherits directly from CanonicalResource, which is the wrong pattern — PlanDefinition, Library, ValueSet and CodeSystem inherit from DomainResource and implement MetadataResource as an interface. Gino confirmed and offered to fix it in a PR the same day:
When you inherit like that, you're creating an interface. When you create a resource that does it, you need to inherit from domain resource and put an extension that says you're implementing the interface.
The mechanics are ugly for historical reasons — normative resources couldn't be changed to conform to later interfaces, so the workaround became an extension (structuredefinition-interface, structuredefinition-implements) that ideally should have been a first-class property. Nikolai's summary of the whole R5 metadata layer:
It's like drawing without eraser.
Brian expected this change to clear a large class of QA errors — the "unknown JSON property id", the false-positive collection warnings, the FHIRPath resolution noise. Gino agreed a class of them goes away but flagged that the R6 dependency for additional resources is not fully wired in the IG Publisher pipeline yet, so a residual set of known-issue errors will stay in QA either way. Because Fish (FHIR Shorthand) doesn't properly support additional resources today, Gino will define the changed structure in JSON directly rather than fighting the Sushi pipeline.
Once the IG-side change lands, the sequence to actually clear errors is: update the IG → build FHIR Core → build IG Publisher → rebuild the IG → check status. FHIR Core PR #2453 ("Enhancements and fixes to SQL on FHIR view runner") is on hold until then — John moved it to draft, since the inheritance change may alter that implementation and skipping steps just generates another round of Core changes. Gino noted Core changes are unlikely to land before ballot regardless, given the queue.
Terminology artifacts and THO — deferred post-ballot
The spec currently defines its own code systems (Export Status among them), and HL7 now discourages that pattern — reusable code systems are expected to live in THO (Terminology.HL7.org) so implementers across jurisdictions can share them. Keeping them in the IG requires filing for a THO exemption; moving them out requires the THO onboarding process. Neither is realistic before August 9.
John opened issue #396 and marked it post-ballot. Gino confirmed this doesn't block a first publication, but the third-edition version number will attract more scrutiny — someone at CFFG reliably files this ticket on every ballot. The pragmatic path is to note it, ship the ballot, and go through THO after.
Where it lands
John drafts the unified-operation PR today, Gino drafts the ViewDefinition inheritance fix in JSON today, Nikolai takes the changelog and the coexistence write-up. The group needs quorum out of session to review both PRs before August 9. Terminology-in-THO, the FHIR Core PR, and any lingering QA errors are explicitly post-ballot.