How a ViewDefinition points back at the questionnaire it was built for — Aug 8, 2025

relatedArtifact — but ViewDefinition doesn't inherit it

An implementer asked how a ViewDefinition written for one specific Questionnaire actually says so. The answer was to not invent anything — canonical resources already point at each other with relatedArtifact.

Then somebody opened the spec mid-call and found relatedArtifact isn't on CanonicalResource at all, so ViewDefinition never inherited it. Adding it was judged uncontroversial.

Worth knowing: a relatedArtifact doesn't have to point at a FHIR thing — it can cite a PubMed article or the study that justifies the questionnaire existing.

Pre-populating a questionnaire — reuse SDC's mechanism

The instinct: reuse what SDC already has rather than build a parallel mechanism.

SDC's initialExpression and calculatedExpression take an Expression that can be FHIRPath or a pointer to a CQL library — so it could just as well point at a SQL query library.

The one thing that doesn't fit: wanting a single query to fill several fields at once.

System-level operation, no type binding

ViewDefinition isn't a resource type in R4, so the IG publisher won't let an operation bind to it.

The compromise: a system-level operation taking an untyped URL — the same trick the Subscriptions backport IG uses — constrained by pointing at ViewDefinition's StructureDefinition as a profile instead of a type.

A typed version can arrive later if additional resources are ever backported to R4, an idea argued for on the grounds that HAPI already supports custom resources, which aren't much different.

At system level $export would also collide with bulk export, hence $view-definition-export and $view-definition-run.

Search parameters on $run — no consensus

Adding them so you can pre-filter got no consensus. It's genuinely attractive for real-time queries, but it forces every implementer to build proper FHIR search first — described as a nice adventure that could take half a year, and not one everybody wants.

It may survive as strictly optional.

An open-source query tester and a TypeScript FHIRPath engine

A demo of an open-source query tester that runs against any server, proxying through its own backend so you never fight CORS — plus a new open-source TypeScript FHIRPath engine with a static analyser sitting behind a language server.

It does completion and tells you when you've reached for a property that doesn't exist, and being LSP it isn't tied to any one editor.