Topics discussed:

• Gene's idea is to split the problem in half rather than go end to end. John framed it as: 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. Gene's motivation is blunt — everybody and their mother can run SQL in their existing reporting stack, and almost nobody can run CQL. 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 is that the C# route was chosen partly to inherit a whole toolchain — translate straight to SQL and there's no IDE, no debugger, no breakpoint.
• Steve argued the use cases run wider than quality measures. He 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 described 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 is that 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.
• The argument then widened to AI generally. John's position: 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 grounded it in precision. 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 was that 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.