Topics discussed:

• Eugene Vestel's tool 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. It has a manual path (pick a profile, choose elements, nested elements and joins, get a view definition and the SQL) and an LLM path that does the same from the profile. John Grimes 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 that came back is that 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 Ryzhikov walked through the $run draft. It 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 was 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 Grimes suggested letting $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. You'd 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 made the case from the other side: missing search parameters were exactly the pain that drove people to flatten data in the first place.
• Arjun Sanyal's third pass at the query resource built on Nikolai's sketch and Gino Canessa's OperationDefinition version. The notable turn is that he 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: Adam Culbertson 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.