Topics discussed:

• Bartek's FHIRboard runs locally off a docker compose and is built around what he calls an analytical case: the set of ViewDefinitions you need to answer one real question, like the distribution of vaccinated patients or a care-gap query. Each view is turned into a DuckDB query by Dan's runner and executed over NDJSON files, and every view is saved as a database view — at which point one hand-written query can join across them, which is where he sees the real value. Superset is wired in over its API for the charts, and cases can be shared by link, though he was upfront that there's no permission model yet and it's there to show a direction.
• John's counter on the LLM idea was that models are very good at writing SQL over simple schemas and not good at writing a ViewDefinition from FHIR — so aim them at the half they're good at. He built an MCP server exposing read-only SQL over a set of views: Pathling turns a bulk export into Spark SQL views, and the model already knows Spark SQL. The neat part is that the view definitions become the prompt — each view and every column carries a description, so the semantics travel with the data and the model knows how to query it in whatever dialect. Generating the views themselves, he found, needs fine-tuning or more prompting to be reliable; Bartek said his own machine learning colleagues had told him the same thing.
• Bartek asked whether there could be one standard set of views per national implementation guide. John said it isn't this group's job to bless them, but it's very possible — the more general the IG, the trickier it gets, and it's probably more useful a level down: pathology results for antimicrobial resistance work, say, rather than all of AU Core. The vision he described is that every IG ships views giving a plain rendering of its data, analytic tools already know them because someone else wrote them, and the model does the last mile.
• Arjun Sanyal added the reason it isn't as simple as one generic set: writing a ViewDefinition is a bit like profiling — you're making decisions, about the flattening and about the subset. The group has moved away from the idea of super-generic views over something as broad as US Core, towards John's position that the more an IG scopes down the world, the more useful a canonical view representation of it becomes.
• On the query resource, Arjun was clear that nothing formal exists yet — it's only ever been discussed on calls. Portable queries have to meet the portable views somewhere, and since dialect variability is a large part of why SQL on FHIR exists at all, a query resource would have to be multi-dialect or expandable, without inventing yet another healthcare-specific query language. John's framing was tighter: the whole motivating principle is that simple views let you write simple SQL, so constrain a query resource to a subset of ANSI SQL known to run consistently across a wide range of engines, and it will reliably run over whatever a view produces.