Topics discussed:

• Arjun's central argument, aimed at newcomers: every IT estate you can point a stick at already has a tabular, broadly SQL basis, with armies of SQL developers and, in a big system, tens of millions of dollars sunk into it. FHIR then arrives as a sort of alien creature that informaticists are excited about and the government mandates. Ask whether you can make decisions on it instead of the thing you already paid for, and the answer has been no — so the pitch reduces to "this will be semantically interoperable and amazing, and your costs go up", which is why the reply is always maybe next year. He was blunt that the community, himself included, has not done a good enough job demonstrating organic improvement in either cost reduction or revenue growth.
• On mandates: they work, and then they stop. The Cures Act pattern is to do the minimum possible and halt right there rather than go to the next level, which makes regulation a thin reed to lean the whole thing on. He'd much rather the driver were economic. His counter-example from patient access data is temporal: it's mandated one day after adjudication rather than the 30, 60 or 90 days of claims, which makes decisions possible that claims simply can't support — some ACO readmission measures work on windows of a week or two.
• Data quality is the use case he keeps wanting somebody to build. If you're making any decision on FHIR data — clinical, financial, operational — how do you know the quality of what you're getting? Today's audit is roughly 400 charts, sampled once, and the number doesn't move whether the plan has 5,000 members or 5 million; pass once and attest nothing changed and you may never do it again. One senior auditor called it audit theatre. His conclusion: no human process at a sane price audits at that scale, so it has to be automated, continuous and across the full population — which is precisely what SQL on FHIR is for, and roughly nobody is doing it.
• Why free infrastructure matters to a standard: Postgres, DuckDB, ClickHouse and Kafka cost nothing and would have cost tens of millions a decade ago. Working out how to point them at FHIR is, in Arjun's view, a big part of making FHIR analytics mainstream — and it matters most to the organisations with the least money, like rural systems and HIEs, who can't afford to reinvent the wheel. On picking between implementations, his advice was mundane: it mostly follows what you already run — a Microsoft SQL shop takes the MS SQL one, a Spark shop looks at Pathling, and greenfield is a different question from an installed base.
• Michael Weishuhn, a newcomer, raised the context problem: he wants an agent to pull just the values it needs out of a patient's record — historical A1C, say — rather than push the whole thing into the model, because older patients' records run to megabytes, blow out the context and drag quality down as the important parts get buried. Arjun's framing was that LLMs are extremely good at SQL, so hand them a standardised, predefined schema and let them write the query; Michael's version was to meet the LLM where it's strongest. Arjun's broader wish is for FHIR to be the intermediate format: given its breadth, terminology and extensions it can be bored out to nearly anything, while the alternatives can't represent FHIR — and he pointed at Josh Mandel's public analysis of Epic's EHI export, effectively a database dump with the vendor's schema intact, as the sort of thing a standard intermediate would fix, since every vendor's export is different.