Topics discussed:

• John's example was cardiovascular risk — a case you'd assume is simple until you scratch it. A guideline is natural language, interpreted case by case. Ask a clinician whether the patient has moderate to severe chronic kidney disease and they tick a box. Automate the same question and you must decide what it means: a recent diagnosis? Pathology at a certain level? Over what period, observed at what intervals? Most of the guideline, as he put it, is actually in the clinician's head, and it isn't consistently applied today — which is fine, because clinicians are clinicians.
• The consequence is the part he cared about. Once you settle those criteria you set them in stone, so even with a human in the loop the same black-and-white test runs every time, where before you had a population of clinicians each applying judgement. That produces quite different outcomes, systematically — which is where bias comes in, and what happens to care if everyone adopts the same automated tool. It looks sophisticated, but it can be harmful precisely because it's different enough from the thing we know works.
• The intent problem is the sharpest version. "Is the patient on blood-pressure-lowering medicines?" seems easy — look at what they were prescribed. But a drug taken as a migraine prophylactic may overlap with cardiovascular use. The prescribing clinician was working from intent in their head, and a later clinician reads the record filtering for that intent subconsciously. The structured record doesn't carry it, so you end up inferring from substance and licensed use — which is a different question from the one being answered in practice.
• Arjun's counter was that the comparison isn't automation versus perfect judgement. Delivery of evidence-based care in the US sits well below what a reasonable person would expect, and that has definite costs too. He put himself hand-wavily in the middle: decades of criticism of quality measures, some evidence they've improved care across several dimensions, a lot of belief that on a cost-adjusted basis the result is neutral or negative — much of that because they're mostly process measures, mostly not personalised, and not very sophisticated.
• On why authoring tools keep missing, John's line was that if the tool is about CQL, you're probably doing it wrong: "how do I write CQL" isn't a business problem, it's a problem cooked up by the people who built the tools. The user's actual question is how to deliver better care. Arjun, reacting to a conference write-up whose fifth bullet suggested clinicians should learn CQL, was less diplomatic — any other answer is better than that one. John added that what the community lacks isn't FHIR expertise but people who can build genuinely good UI for non-technical users; it produces mountains of tooling aimed at implementers and integrators. His other observation: nobody has an incentive to improve data quality until someone actually tries to use the data, so building this stuff is itself the forcing function.