Prove the query resource the way ViewDefinition was proved — same SQL on four engines — Jul 1, 2025

John's verdict on Arjun's draft — the base is fine, the seam is the worry

The query representation itself is uncontroversial and looks good — it's the intersection with the clinical reasoning and CRMI world he has no handle on, and he wants an example worked end to end before believing it holds together.

So he argued for layers: prove the base thing first, leave CQL for later.

Prove it the way ViewDefinition was proved

There are already tests that run view definitions across engines and check they agree; the same trick should work one level up — take a query resource, run it over view definitions in Spark SQL, DuckDB and Postgres, and you should get identical results.

Something small and embedded like SQLite would serve as the reference implementation.

Arjun's plan for the spec: a view query page mirroring the view definition page, plus a separate page of usage guidance.

Should $export or $run point at a view query too?

John: probably — it runs into the same problem of executing arbitrary SQL, but it's easy enough to allow in the spec and nothing is released yet, so it can go in as a proposal while people work through what it means in practice.

Steve: a $run on the query would be straightforward.

Four clinical reasoning requirements — Brian's list

• Reach a query from a FHIR measure
• Use one to pre-populate a questionnaire
• Use one as the inclusion criteria on a plan definition action
• Use one for dynamic values in an activity definition

Arjun was careful about the framing — this is not a CQL replacement. The point is that the model should let you pick your expression language rather than dictating one.

The missing artefact — a worked example

John's candidate shape: take a real measure — something like use of opioids at high dosage, which is a problem everywhere and has a CQL implementation you can read — and express it with view definitions and view queries.

The interesting part isn't the logic, it's the seam: how does the output get mapped back into a MeasureReport?

He offered a second candidate from his own work — a cardiovascular risk calculator built entirely in SDC, which sits right at the top of the complexity you can embed there.

Implementation status

Steve: $run nearly done, moving to $export. Flagged a Python implementation of SQL on FHIR that had arrived as a pull request.

John: Pathling is still neck-deep in implementing view definitions properly — which is where his stream of clarification issues against the base spec comes from — and has little capacity for the bleeding edge.