FHIRboard groups views into an 'analytical case', and why John points an LLM at SQL instead — Apr 8, 2025
FHIRboard — analytical case as the unit
Runs locally off a docker compose and is built around what Bartek calls an analytical case: the set of ViewDefinitions you need to answer one real question — 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 — models are good at SQL, bad at ViewDefinition
Models are very good at writing SQL over simple schemas and not good at writing a ViewDefinition from FHIR. 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: 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.
One standard set of views per national IG?
Bartek asked whether there could be one standard set of views per national implementation guide.
John: 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: 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.
Why 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.
The query resource — nothing formal exists yet
Arjun was clear: 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.