CQL confusion at the connectathon, Stars measures on SQL, and Owen Loveluck's Scala ELM engine — Sep 29, 2026
The connectathon: CQL confusion, and US Quality Core in the corner
Steve Munini came back from the connectathon with a spec-example bug list and a bigger observation: CQL is in a state of collective confusion. Multiple camps, no direction set, and — as always in that scenario — organisations wait for someone to lead and end up doing nothing.
Steve sat in on the US Quality Core track. US Quality Core is a draft IG from CMS built on top of a specific US Core version, on the theory that a shared quality-core IG plus universal implementation might finally unblock the CQL story. Epic participated, which is where the data actually lives. The technical picture was tractable; the organisational picture — getting providers to change workflow so the right code lands in the API — was the hard part.
Guys, this tech stuff is fine. But to actually get the organisation to maybe even change the workflow so that this particular code can end up eventually in an API — that's where all the real hard work is.
Brian Kaney presented an early AI-assisted measure-development approach: feed medical research, guidance, and clinical narrative in; get CQL out. Very early, but on the roadmap.
Michael on Stars measures — what to actually pitch payers
Michael E Campbell laid out what he is currently pitching to clients: run Medicare Stars measures on SQL on FHIR and compare against the payer's existing non-FHIR digital vendor. Either you get parity — which is proof enough that you can serve the measure — or you find a delta, and now the conversation is about lineage and transparency versus the incumbent opacity.
Michael's read from his own conversations with vendors: nobody is actually keeping CQL as CQL at population scale. Firely is transforming it (working closely with NCQA); Optum's Evan Mashkovsky is doing something transformation-shaped; even Strata — who claim to keep it in CQL — is almost certainly transforming the FHIR data under the hood into something quite different from nested resources. The published "must stay in CQL" line has softened; what matters is that the black-box tests pass.
It's hard to disrupt that attractiveness. From every data analyst to the data engineer, you're using SQL. CQL is a nice-to-have, I suppose.
Nikolai Ryzhikov confirmed the parallel data point: Health Samurai's Alexander pair (Alexander and Alexandra) manually translated a chunk of Stars metrics into ViewDefinitions for a customer and are expanding coverage. It is naive in places — the value-set story is still being nailed down — but it already runs, and a couple more clients are at least experimenting.
Three places terminology work can happen
Michael's clarifying question was about where the terminology work belongs when a Stars-style measure is locked to a fixed value set. Nikolai's response split it into three:
- Translation at extract. If your source is a local code, translate to LOINC or SNOMED as the ViewDefinition builds. Nikolai expects a
translatefunction to land in FHIRPath eventually. - Translation via join. If translation is polymorphic — e.g. an OMOP-style destination table depending on the concept's domain — you defer it to a later view that joins an extra concept-map table.
- Value set as expanded table. For the fixed-set case, load the expansion as a table and check inclusion or exclusion by join.
Each has its place. The heaviest of the three is the OMOP-style full normalisation, and that is exactly what Nikolai spent most of the call on.
The FHIR-to-OMOP bridge, and Nikolai's dream
Nikolai gave a deeper tour of OMOP than the previous meetings had space for. OMOP treats terminology as a single unified vocabulary: every concept from every code system gets a stable OMOP integer ID; every diagnosis normalises to SNOMED, every observation to LOINC, every medication to RxNorm; concept-map tables tie source code systems to the unified layer. The OMOP community pays a substantial engineering cost to keep this current, and the payoff is that any research query works against any conformant dataset.
FHIR deliberately did not go there. It is an interoperability standard, not a unification standard — different domains, different authorities, different release cadences all coexist. But the same relational shape — concept, relationship, property, designation tables — can serve FHIR terminology; it is roughly what OMOP does anyway, minus the forced unification.
Nikolai's dream, stated explicitly for once: connect these two worlds in real time. On-the-fly transformation of a FHIR record into OMOP form so the OMOP phenotype library (thousands of clinically-validated cohorts) and OMOP prediction models become usable inside a clinical decision-support flow. And the flip side matters for the EHDS: Europe is forcing FHIR at the source, so a good FHIR-to-OMOP bridge is what unblocks the secondary-use community that defaults to OMOP.
If these two worlds will be connected, that would be amazing. Especially agents now can do this — you're giving a FHIR record, it's on-the-fly transformed into OMOP, and then you can use this whole knowledge base to search for your cohort, for your outcomes, and try to predict what will work.
Michael's counterpoint on where OMOP falls short: OMOP's normalisation policy throws away data that does not conform to the target vocabularies. Fine for research, since noise gets pruned; not fine for coverage of real-world data. Nikolai agreed — the aspiration is the good profiling at ingest plus the OMOP model behind it, not one at the expense of the other.
CQL retrospective, and the AI reframe
Michael's takeaway from Evan Mashkovsky's talk (Optum) was that CQL got a real drubbing. Evan's line, as Michael related it: in retrospect it was a bad choice; it would be better to write SQL from an AI-driven narrative than to keep CQL as the intermediate layer. The measure specifications will still start as narrative and the black-box tests still gate correctness — but the intermediate step doesn't have to be CQL.
Nikolai's reference point was his own team fifteen years ago writing CMS decision-support rules directly in SQL. It took a few months, cost a few thousand dollars, passed certifications, and ran in production for years. The whole CQL journey, by contrast, is nearly a decade in and still not mature.
The SQL program is becoming input for LLM to write efficient program to do that. That's really what I see.
The reframing Steve and Nikolai landed on: treat CQL as a specification language, not a runtime. Feed it to an LLM alongside a valid test suite; produce implementation in CQL, JavaScript, C, or SQL — whichever fits the deployment. Health Samurai's team has started working on CQL-to-SQL translation as a semi-automated, semi-agent, partly transpiler pipeline.
Owen Loveluck: CQL as a DSL for prior auth
Owen Loveluck (1upHealth) came in with the strongest defence of CQL the group has heard in a while — but a very narrow one. He is using CQL to represent Da Vinci prior-authorisation rules: whether a service needs prior auth, with exceptions for certain locations, joined against FHIR data and terminology. Simple rules, not population analytics.
The pitch: CQL is a DSL you can store as safe, versioned data, separate from application source code. When rules change, you update the data, not the code. The ELM intermediate representation is small and well-specified enough that Owen wrote his own Scala engine in a couple of weeks — he estimates a day today — that passes the reference test suite and matches Brian Kaney's Rust engine, including reproducing three failures against the official Java implementation.
I like the DSL part of it. It would be better compared to something like Starlark that's used in Python as a DSL, compared to SQL. They're designed to solve different problems, and the name sounding almost the same has brought comparisons.
Nikolai's read: this is CQL doing what a first-class value-set language does well — declarative rules over FHIR resources against value sets, plus a bit of temporal logic. On the population side, Owen agreed it is a different problem and CQL is not what he would reach for.
Owen is planning to implement SQL on FHIR on 1upHealth's platform once other end-of-year commitments clear. Nikolai's ask: when the runner passes the test suite, publish the JSON at a public URL and 1upHealth appears in the implementation matrix automatically.
Housekeeping: spec examples, next meeting, December conference
Steve filed a GitHub issue on leftover attributes in the spec examples — residue from switching the ViewDefinition base to DomainResource — and will move it to Jira to fit the current process, with a proper look next week when more people are back from WGM travel. Nikolai reminded the group that the December online analytics-on-FHIR conference is on: Grahame Grieve agreed to keynote, and any SQL on FHIR or broader analytics talks are welcome — including early-stage implementations.