Portability of quality-indicator dashboards, the CQL-to-SQL fork, and the August 9 ballot — Jul 28, 2026
Ilya's real-time GP quality-indicators dashboard on Aidbox
Ilya walked a dashboard he's building for the HL7 Australia connectathon: real-time reporting on the Australian GP quality indicators, driven by ViewDefinitions and a chain of dependent SQL query libraries. He took John's existing ViewDefinition and query set, split the more complex SQL into smaller chunks so each library is one query composed by dependency, and wired it into Aidbox. The dashboard runs on the $query-run operation against a live FHIR store — no materialised views, just one large query composed of WITH statements, executed on demand.
The performance envelope was the news: fine at 100 patients, roughly 5 minutes per query at 1,000, and unusable at 10,000 (queries didn't finish inside 30 minutes). No optimisation applied — vanilla execution against a general-purpose FHIR store.
What Ilya actually wants to demonstrate at the connectathon isn't the perf number but the portability of the artefacts themselves — a digital health agency authors a package of view definitions and query libraries, and any AU Core-compliant EMR loads and runs it as-is:
I want to demonstrate portability — this set of ViewDefinitions and SQL libraries could be authored by someone else, and I just imported them and use it as it is. My software supports SQL on FHIR, this is an example of an Australian use case for GP quality indicators, but since I support all the standards I can take any third-party artefacts and run them.
Nikolai's framing back was that the ideal end-to-end story is an IG that inherits from AU Core, packages the ViewDefinitions and query libraries, and can be loaded into any FHIR-aware EHR — with something like Pathling handling the population-scale run when the primary care instance can't. John agreed and said he'd already made a start on that IG shape; the same run also has to emit the aggregated JSON format the Australian government portal actually accepts, so the end-to-end story includes that lowering step too.
Materialisation at the library level — the missing piece for performance
The perf demo turned into the recurring materialisation debate. Nikolai's position: if people are building dashboards on top of stacked ViewDefinitions and query libraries, the runtime has to be able to materialise intermediate layers, not just the leaf query.
It is not materialised, and that's why we want materialisation. If people are building these dashboards and they want to fly, ideally you should materialise, even build indexes and this kind of thing.
Ilya's specific ask: declare materialisation preferences (e.g. "materialise base_population by default") without editing the query artefacts themselves — otherwise portability breaks. He can already do it manually today by rewriting dependencies to point at pre-materialised tables, but that defeats the "import someone else's package as-is" story.
John's addition was that reusable intermediate views are the natural place to cache — and that a generic capability of "point a BI tool like Power BI or Tableau at these materialised views via something like ClickHouse" is a demonstration worth doing on top. Nikolai noted that even columnar engines benefit from materialising intermediate layers — the dbt community does this exactly for perf reasons on ClickHouse and similar.
CQL-to-SQL: direct transpiler vs ELM-based relational algebra
The materialisation thread pulled in the bigger open question: how do you generate SQL from CQL well? Two working approaches surfaced on the call, arrived at independently.
Nikolai has a direct CQL → SQL transpiler that goes through an intermediate representation (IST) — no ELM. FHIRPath expressions are kept as strings and translated separately (his trick: he implemented FHIRPath as a built-in in Postgres, so FHIRPath fragments compile down cleanly). The resulting SQL is a large but readable common table expression. He ran a HEDIS-style diabetes measure against what he estimated as 10,000-100,000 patients in about 5 seconds.
Brian is building an ELM-based relational algebra (RA) approach: ELM nodes map to RA functions, which then compile down to SQL on FHIR ViewDefinitions and query libraries. Only a handful of RA operators are wired up so far, but the argument for the approach is that it's mathematically provable rather than rule-by-rule brittle:
Evan's approach with RA is mathematically provable in a way that's different from running a whole bunch of edge case tests. It's the killer feature — a way more systematic approach.
Brian's concern with Nikolai's IST path was brittleness at the CQL surface — CQL keeps adding syntactic sugar that compiles to the same ELM, so targeting ELM avoids having to track surface-syntax changes forever. Nikolai's counter was that once you have FHIRPath handled inside the database, the CQL → SQL step is quite thin — and the super-compiler over the IST can fold e.g. two conditional selects with different value sets into one selection with an OR, which is where the real perf wins live.
Owen described a very similar POC to Brian's — ELM → SQL, emitting a SQLQuery resource and ViewDefinition parameters — and asked how the CQL → SQL translation deals with different underlying data models. Brian's answer was that this is precisely the beauty of the ViewDefinition layer: the CQL → SQL step doesn't have to care about the physical store, because the ViewDefinition is where each implementer maps to their own database shape.
The group aligned on framing CQL primarily as a formal specification language, not necessarily a runtime — the goal is to prove conformance to a published measure, not to mandate that everyone runs a CQL engine at population scale:
The consensus at the last DevDays was that people are considering CQL as a formal specification language. You are not forced to run it.
Brian wants to set up a dedicated call or Connectathon track focused on this CQL/SQL translation work, separate from the general SQL on FHIR meeting.
Terminology handling — expanded value sets as tables
Ilya's next question was where the guidance is for handling terminology in these translations — for example, expressing "has diabetes" via a value set. There is no standard approach in SQL on FHIR yet; the pragmatic first step everyone agreed on is expanding value sets into flat tables and joining them in SQL. Nikolai's team published a walk-through of exactly this pattern for HEDIS metrics.
John's addition is that Pathling now ships a local terminology system with FHIR and SNOMED CT importers into tables, and the shape of those tables is close to what analytics operations actually need — value-set membership, subsumption, and similar. But he pushed on where the interface should sit:
It comes down to what's the best interface or abstraction for the user. It could be an abstract table interface, or it could be FHIRPath functions at the view layer. You could have both. It's up to the implementer how to satisfy that behind the scenes — a terminology server, an Athena-style local table, whatever. You want to be able to write your definitions in SQL that just works.
Brian's team plans to start with the expanded/flat form and grow into subsumption-style queries later (their real use case is things like all branded pack codes with acetaminophen as a precise ingredient via RxNorm edges — a graph problem, better served by expanding via a terminology server first, then loading the flat result). Nikolai suggested the group could standardise or at least recommend the "value set as a table" pattern, potentially describable as a ViewDefinition over an expanded value set.
Ballot deadline and HL7 migration
August 9 is the deadline to finish the ballot-ready spec. John is doing a consistency and quality pass over the operation definitions — aligning parameters across $run, $export, ViewDefinition and SQLQuery operations, which are inconsistent today.
The spec repo has moved from the FHIR GitHub org to HL7, and the canonical base URL is moving to the HL7 Universal Realm URI. The updated spec is visible on build.fhir.org now; a redirect from the old URL is still outstanding. No spec decisions were taken today for lack of quorum, and John hopes to have quorum next meeting — he also plans a short (~10 min) Pathling demo next week to make the new spec surface more accessible than reading the operation definitions cold.
Nikolai asked Brian and Owen to review the updated spec — it now includes the SQLQuery view and both synchronous and asynchronous operations, and he wants outside eyes before ballot.