SQL on FHIR WG Meetings
SQL on FHIR WG Meeting — August 26, 2025
Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions
Nikolai Ryzhikov
Nikolai Ryzhikov
CTO at Health Samurai
John Grimes
John Grimes
Principal Research Consultant CSIRO
Eugene Vestel
Eugene Vestel
Software Engineer
Steve Munini
Steve Munini
CEO and CTO, Helios Software
Aug 26, 2025

Topics discussed:

  • The FHIR version question finally got an answer, and the reasoning was practical rather than principled. Nikolai's position: R4 is much simpler right now because IG Publisher supports it, so publish for R4 and do a new edition when R6 is out — "otherwise we will fight against the tools." Arjun Sanyal agreed. Nikolai is separately still pressing Graham to backport additional resources into R4, on the grounds that it would fix far more than SQL on FHIR — it would help the awkward R4B subscription situation too, and he questioned why resources like the new test plan resource need to be in core at all.
  • Nikolai pushed back on the operation naming. Brian had proposed $sql-run, but a "SQL run" logically belongs to the query resource, not to the view — so it should be $view-definition-run and $view-definition-export. Arjun agreed and made the same point one level up: he keeps arguing the group is more generic than its name.
  • That reopened whether the query resource should be multilingual rather than SQL-only. Nikolai's counsel was to be narrow now and expand when something else earns it. John Grimes said that if it's built it should certainly be multilingual, but noted the SQL on FHIR paradigm already reaches past textual queries — Pathling uses ViewDefinitions with pandas data frames, which is a query but nothing you'd want to pass around as a resource. He also observed that people hearing "SQL on FHIR" often get it exactly backwards, assuming it maps their source system into FHIR.
  • John walked through the repeat directive he's been writing. You hand it a list of FHIRPath expressions and it descends recursively — for a QuestionnaireResponse you need both item and answer.item, because the answers have items too, so a single path won't flatten the tree. repeatOrNull is the left-join counterpart, standing to repeat as forEachOrNull stands to forEach: if the whole repeat block yields nothing you get nulls rather than the row being silently swallowed by what is effectively an inner join. Nikolai probed the recursive case — what if level three returns nothing? — and John said it's decided at the block level, not per level.
  • On AI, John argued the interesting work isn't the generation. If the task is producing ViewDefinitions from prompts, what's missing is the data sets, the benchmarks and the ground truth to evaluate whether the output is any good, plus a shared pool of examples everyone can feed into. Nikolai added that agents don't especially need MCP — they'll happily call a CLI or hit REST endpoints — what they need is $validate and $run, so they can close the loop: generate a view, validate it, run it, correct it.