Working the ballot queue, an extensible resource binding, and external tables — Nov 10, 2026
Ballot tickets: a process for the rest of the queue
John Grimes opened with the September ballot tickets. He had triaged them and drafted PRs for the technical corrections, each with a Jira comment linking the PR and proposing a disposition. He will do the same for six editorial tickets that were filed as change requests but read as technical corrections, and mark one more as a duplicate of an example fix he already made.
John and Adam Culbertson clarified how the decisions work: the working group does not vote on dispositions, it only reaches consensus on a recommendation. The FHIR-I group then votes, most likely as a block vote, and nothing merges until that happens. The plan is to spend up to half of each meeting on the remaining tickets, which John expects to take two or three meetings.
Contained resources: extraction becomes optional
The only ticket tied to a negative vote is about contained resources. The spec currently says implementers must extract contained resources into independent resources before they can be used in views. John pointed out that this is only needed if you want to treat them as resources — the data is reachable with plain FHIRPath as well. Nikolai Ryzhikov agreed and admitted the group had tried to specify more than it needed to.
So probably we can just treat it as a big JSON. And if you can extract it with a FHIRPath, that's okay. I do not see why we should restrict it.
The group marked the ticket persuasive and will draft a PR rewording the section to say extraction is optional. John also suggested adding tests that access contained data through FHIRPath.
ViewDefinition.resource: from a required code to an extensible URI
The second ticket asks to relax the required binding of ViewDefinition.resource to R6 resource types, so views can target additional resources, future normative resources and types dropped in R6. Nikolai argued that older resource types are needed because ViewDefinition has no notion of version — a view could apply R6 definitions to R4 data.
The group leaned toward an extensible binding, and John thinks the field should end up as a URI bound to resource types rather than the current code. Nikolai's research supports that path: StructureDefinition.type went from a required code in STU3 to an extensible code, and then to an extensible URI in R4. He also wants the binding to cover logical models, which are identified only by canonical URL.
I think maybe we should leave that one open for now and ask the question on Zulip about what type it should be and whether it would be appropriate to make it extensible.
The ticket was deferred, along with two others, to the next meeting.
External tables: describing OMOP and Athena in the spec
Nikolai presented his external tables draft, built from earlier working group discussions. A table is defined as a logical-model StructureDefinition based on a Relation profile, with columns in the differential and an extension pointing to where the data lives — CSV, Parquet or another format. A Library declares the table as a dependency, the same way it declares a value set, so a runner loads the file, creates a table and can join against it in a query.
His main driver is describing the full OMOP transformation, including Athena vocabulary tables, but the same mechanism could ship knowledge bases or research models as CSV or Parquet files, possibly bundled in IGs. There is already a JavaScript implementation in the reference implementation, but no spec PR yet; foreign keys are a discussion Nikolai would rather skip for now.
I think it's worthy of a spec PR and also some prototype implementation, which I'm happy to do on my side.
John added that Pathling could describe its configured external tables as StructureDefinitions served by its FHIR server, and he sees a link to the new schema-derivation PR (#424) and to materializing expensive views.
A 3.0.0 branch for ballot fixes
John wants a branch that represents the 3.0.0 release and receives only ballot resolution PRs, which would also be merged to main. Terminology in SQL, external tables and other new work are outside the balloted scope, so they keep evolving on main and can go to a later ballot as a follow-up release. Nikolai agreed. John still needs to confirm what the main branch means from HL7's side.
Adam described how the SMART scheduling links project handled the same situation — a Jira ticket and a branch per issue, with deferred tickets reopened later — and offered to take a few tickets on the repo.
A new R implementation and the Analytics on FHIR conference
A new implementation for R, fhirviews, translates ViewDefinitions to DuckDB SQL using FHIRPath.js and the R DuckDB bindings, much like FlatQuack. John invited its author, Roberto, to present at an upcoming meeting.
The Analytics on FHIR conference will run two days: the call for presentations brought four more presenters, including someone from Databricks who implemented SQL on FHIR. John said he can handle the scheduling around Australian time zones.