ViewDefinitions straight from IG profiles, and a third draft of the query resource — Jun 24, 2025
Eugene's tool — IG profiles to ViewDefinitions
Takes an implementation guide and produces view definitions from its profiles, on the reasoning that a profile is already a logical view over the raw resources — so US Core's ten-odd Observation profiles ought to convert mechanically rather than by hand.
Two paths:
- Manual — pick a profile, choose elements, nested elements and joins, get a view definition and the SQL
- LLM — does the same from the profile
John went straight at the LLM path — which model, what prompting strategy — and Eugene was frank that it's a proof of concept: the question was whether an LLM can do this at all, and it can.
Slicing is where it stops
Asked whether the tool reads slices, Eugene hadn't got there.
The clarification: slicing splits into two jobs — filtering by a slice is just a where clause and works today, but selecting an element from a named slice rather than by index is the awkward one.
Nikolai — the $run draft
Exists for interactive tools and debugging — you can hand it resources in the request rather than running against server data, which is what an IDE or a visual builder needs.
The open question he put to the group: how to resolve a view reference. A relative URL searches the server, an absolute one might hit an artifact registry and then fall back to fetching the URL, but a canonical is just a name and needn't resolve at all, so they may need separate parameters to tell them apart.
John — search API queries as export filters
Let $run and $export take a search API query as an optional filter, the way bulk export's _typeFilter does — clients already know how to build one, and since FHIR's search parameters are defined in FHIRPath it's implementable.
Filter the resources first, then transform.
Nikolai liked it and warned it isn't free: search parameters are full of fuzzy corners — strings over complex types, extensions, ranges — and implementing them properly is an adventure.
Eugene from the other side: missing search parameters were exactly the pain that drove people to flatten data in the first place.
Arjun's third pass at the query resource
Built on Nikolai's sketch and Gino's OperationDefinition version. The notable turn: made it language-agnostic — nothing stops a query being Python or JavaScript, so SQL is only the lead example — plus a dialect hierarchy, and a convention of one query per library.
That last one exists because CQL can index into a named expression inside a library and SQL can't, so the link has to come from the convention instead.
The naming argument — "view query" stuck
Adam wanted an SQL prefix to disambiguate from GraphQL query, CQL query and FHIR query, and would have applied it to ViewDefinition too.
Arjun took the other side hard — view definitions aren't SQL-dependent in any way, you get a CSV or a Parquet file out, and by his reading SQL on FHIR is itself a misnomer for what v2 does.
View query was the name that stuck.