Topics discussed:

• Gene Vestel showed a mock-up that takes one CQL measure down two paths and produces a MeasureReport from each — one via CQL evaluation, one via a SQL query generated from that CQL — then puts the two reports and their timings side by side. His argument for why this should be possible: a quality measure isn't nuclear engineering, it's a collection of lookups and evaluations asking whether the values in a resource meet a requirement. The prototype does the translation with an LLM; the real version would compile ELM to SQL piece by piece.
• Arjun Sanyal's objection was schema stability. Nothing guarantees that birthDate in CQL is DOB in the system you're running against, so a translation that works on paper meets a mapping problem in the real world. Gene conceded the point and turned it into a precondition: you'd have to pin the CQL to a known set of resources and to the ViewDefinitions aligned with them — his prototype quietly assumes that's already true.
• Steve Munini asked which corners of CQL wouldn't survive the trip. Gene's answer was that it scales with complexity: a one-liner that identifies the diabetic patients is trivial, a thousand-line medication adherence HEDIS measure with hundreds of logical statements is another animal entirely — but if you treat CQL as a collection of operations and lookups, the same machinery should extend.
• Nikolai reframed it so translation isn't the point. CQL isn't always the source of truth — sometimes the source of truth is just a report someone wants — so the value is giving people the same logic expressible as ViewDefinitions plus SQL and letting them pick per use case, since some measures are painful to run performantly over a whole population in CQL. He added the useful inversion: if CQL is the official statement of the logic, run both over the same data sets with the corner cases in, and if the results match you can trust your SQL version — CQL becomes the reference implementation you test against.
• Nikolai's other topic was materialisation, and he was careful that it isn't export. The user-facing shape is "here's a ViewDefinition, here's a destination, keep it up to date, I don't care how" — closer to a materialised view plus REFRESH than to re-exporting and reloading. It doesn't fit the export API: no output files, no formats, and you need to see the view's status or refresh it by hand. That points at a separate operational resource rather than a definitional one. Steve was interested and asked whether this meant Postgres views or ANSI views; Nikolai said neither necessarily — sometimes it's an unlogged table, and the destination might be Postgres or ClickHouse. Steve noted that change-data-capture adapters pushing every table change onto a Kafka topic are the same shape of problem, and worth characterising at spec level.