Topics discussed:

• The models can already do the whole chain — here's my data, here's my question, work out the data requirements, write the views, run queries, hand back an analysis. That's the easy part and it demos beautifully. The part everyone skips is knowing whether the output is good enough to actually use. The proposal: build an evaluation loop the same way the group built the spec's test suite. Hard checks first (is this a valid ViewDefinition?), then softer rubrics (did it reuse views that already exist? is it following good practice?), weighted into a score. Have humans judge, have LLMs judge, check they agree — once they do, let the LLMs judge and start optimising against the number.
• The awkward question is where a gold standard comes from, because it has to be public. The best candidate anyone found was published research papers using the MIMIC-IV FHIR data set: the paper states the data, the method and the result, so you can replay it and check. The comparison drawn was NCQA certification, which is a black box — they hand you a secret test deck, you hand back an answer sheet, and nobody ever looks at your code or how you got there.
• A different eval shape was argued for: hand the agent bulk-exported NDJSON and a question — find the cohort with these conditions, give me this number — and score only whether the answer is right, plus the time and resources it burned. Because it's detached from method, you can compare an agent given nothing but two tools (a ViewDefinition tool and a query tool) against a general-purpose coding agent as baseline. If a small model on a laptop with those two tools matches a frontier agent, that's the argument for the technology, made without hand-waving. Same logic makes it a fair bake-off against CQL, and it would work as a Kaggle-style competition or a connectathon activity.
• Reuse turned out to be the interesting question underneath. MIMIC-derived is a common set of views over MIMIC that hundreds of papers lean on — common requirements extracted out of a vast pile of individual use cases, which is more or less the problem OMOP solves. So in an agentic world, do you generate thousands of slightly different views, one per question, or do agents discover and reuse from a registry? Nobody knows yet, and the group noted it's a good sign they can even ask.
• Three concrete spec questions on the query Library. Should the label on relatedArtifact be required — it's the table name the ViewDefinition gets in the query, and falling back to the ViewDefinition's own name was thought a bad idea. Should output parameters describe the shape of the result, so a caller knows what columns come back without running anything (very useful to an agent; the objection was what happens when the declaration and reality disagree). And can query parameters be passed by name, the way FHIR's named queries do it, rather than as generic key/value pairs — so patient=... works on a plain GET.