Pointing a ViewDefinition at a questionnaire — FHIR's own answer was already sitting there — Aug 12, 2025
The SDC-side interest — analytics after collection
Mostly 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 — 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.
OK, let's add this element.
Nobody argued.
Backporting additional resources to R4
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.
No one's going to be on R6 for at least a decade.
Three asynchronous patterns in FHIR
- The original one inherited from bulk import/export — just half FHIR stuff
- A second that returns a Bundle
- 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 — the schema-versioning question still hangs 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.