SQL on FHIR WG Meetings

Compiling CQL into ViewDefinitions plus plain SQL — and the most common CQL engine is still a human — Oct 28, 2025

Arjun Sanyal
Arjun Sanyal
Principal Antidote Solutions
Steve Munini
Steve Munini
CEO and CTO, Helios Software
John Grimes
John Grimes
Principal Research Consultant CSIRO
Eugene Vestel
Eugene Vestel
Founder at HealthClaw.io
Oct 28, 2025

Gene's proposal — split the problem in half rather than go end to end

Work out the data requirements of the measure, generate a set of views that satisfy them, then write simpler, more portable SQL on top of those views to finish the query.

Eugene Vestel
Eugene Vestel
Founder at HealthClaw.io

Everybody and their mother can run SQL in their existing reporting stack, and almost nobody can run CQL.

The most common CQL engine today is still a human

On alternatives: Arjun could name only one publicly known viable route, the ELM-to-C# translation lineage; John supplied the other one — humans, who hand-translate CQL into whatever SQL matches their stack.

Arjun's caveat on going direct to SQL: the C# route was chosen partly to inherit a whole toolchain — translate straight to SQL and there's no IDE, no debugger, no breakpoint.

The use cases run wider than quality measures

Steve described a chief medical informatics officer tired of re-deriving a data model for every incoming project, who wanted to unify on something like FHIR plus CQL purely to raise the velocity of the work.

Prior auth came up too, and Arjun added clinical practice guidelines and interactive questionnaires as the space he tends to see it in.

John — a prototype worth stealing

An MCP server over Pathling holding MIMIC and a set of ViewDefinitions, so an agent can answer a question — his example was an antimicrobial resistance one, along the lines of an updated antibiogram — by running SQL over the views and producing visualisations.

His hypothesis for Gene's problem: agents may do better on the split version than the direct one, possibly as a team of agents — one doing CQL to data requirements to views, another running SQL over views, which the group already knows works well even for complicated things.

AI as human augmentation

John Grimes
John Grimes
Principal Research Consultant CSIRO

It's all human augmentation and will stay that way for these use cases. The real effect is that the cost of producing software has dropped enough that jobs previously not worth attempting come into frame. What shifts is where the effort goes: once you can verify an answer is correct, the code itself becomes disposable, so testing and evaluation matter two or three times more than they did.

Arjun agreed evaluation is where AI-assisted work is essentially all profit, because you were never going to do it to that standard by hand.

Steve — the precision continuum

He'd been introduced to someone running analytic questions directly over a pile of FHIR JSON with an LLM, which alarmed him — and the honest answer was that the client only wanted roughly how many people with a condition left the hospital last month, and roughly was the keyword.

That's a legitimate place to be imprecise. It is not where this group operates: when the requirement is that every time a diagnosis appears, X, Y and Z happen, a miss means somebody gets hurt.

Arjun's follow-on: he'd like to see a spread of use cases across the precision continuum, since almost everyone driving FHIR analytics today sits at the highest-precision end.