SQL on FHIR WG Meetings
SQL on FHIR WG Meeting — August 12, 2025
Nikolai Ryzhikov
Nikolai Ryzhikov
CTO at Health Samurai
Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions
BR
Brian Kaney
Bashir Sadjad
Bashir Sadjad
Software Engineer at Google
Steve Munini
Steve Munini
CEO and CTO, Helios Software
Aug 12, 2025

Topics discussed:

  • The interest coming from the SDC side is mostly analytics after the data is collected, not population — people want to turn questionnaires into a flat representation and build dashboards on top. A request on Zulip from Alex in Germany surfaced the missing piece: when you write a ViewDefinition for a specific questionnaire, you need a way to point back at that questionnaire, and Graham noted it's much the same problem as pointing at a profile. Nikolai also flagged that questionnaire items can be recursive, and SQL on FHIR has no repeat function to walk them.
  • Brian Kaney's answer was that FHIR already has this. Nearly every canonical resource in FHIR is definitional — plan definition, activity definition, library, value set, structure definition — and almost all of them carry relatedArtifact. ViewDefinition doesn't, and to Brian's genuine surprise neither does Questionnaire, which he couldn't explain. Rather than invent an element, do it the way Library does it. Nikolai: "OK, let's add this element." Nobody argued.
  • The operation definition still can't go in the IG, because IG Publisher won't bind an operation to a resource type that doesn't exist in R4. Nikolai has been pushing the other way — backport additional resources to R4 — and reported that Graham's first answer was that HAPI doesn't implement them, to which Nikolai pointed out HAPI has custom resources, which are hardly different. The landing spot: ship a system-level operation now, mark it informative rather than normative, upgrade later if the door opens. Brian's assessment of the timeline: "No one's going to be on R6 for at least a decade."
  • Nikolai counted three asynchronous patterns in FHIR: the original one inherited from bulk import/export, which is "just half FHIR stuff"; a second that returns a Bundle; and a third being drafted by Josh Mandel where the response can be anything, including a Parameters resource. SQL on FHIR's export documentation is betting on the third; if it doesn't land, they fall back to returning a Bundle. Related: once the operations move to system level, $export will collide with everyone else's, so they'll need to prefix — $view-definition-export, $view-definition-run.
  • Bashir Sadjad raised the question still hanging over Parquet on FHIR: the schema comes from the data, so SQL written against one version of the Parquet can simply fail against another. Nobody had an answer — it hadn't been discussed. He likes the idea of the much smaller schema, but wants a story for the downstream querying before committing to it.