Topics discussed:

• The query resource got its first concrete shape: something simple whose body is a SQL query, probably reusing FHIR's existing Expression datatype so the dialect and the expression travel together, with a link to the set of ViewDefinitions it runs against — those views being its schema. The open questions are the interesting ones. What are the table names, and can the view's name serve? Should there be parameters, since you often want to inject something rather than query everything? And a proposal worth more than it sounds: a canonical mapping from ViewDefinition column types to SQL types, because today the type in a view is only a suggestion from whoever wrote it, and a query you distribute can't rely on a suggestion.
• CRMI came up as the obvious neighbour, and got an introduction for those who hadn't met it: an IG consolidating what it means for a knowledge artifact to be shareable, computable and executable — how you package it, version it, distribute it, resolve its dependencies. It already covers value sets, libraries, measures, plan definitions, structure definitions. A ViewDefinition is a knowledge artifact by that definition, so the suggestion was to align rather than reinvent — take the basic CRUD and search parts, skip the rest, and see whether ViewDefinition eventually belongs there.
• The IG publisher already does more of the integration than people expected. Given a ViewDefinition in a guide, it validates it with SQL-on-FHIR-specific logic, registers the view as a table in the publisher's internal SQLite database, runs the view over the resources in the IG, and populates the table — and a page can render the output of a SQL query against that database. That is a decent chunk of what "IG integration" was meant to mean, already built.
• There is a fork in the road behind it. The publisher's output is deliberately static, and an HL7-balloted publication has to use the stock template, so the interactive parts people actually want — visual builders, live runners, evaluating a view to see what it does — can't live there. Custom templates carrying React components exist for clinical guidelines and quality measures, but you cannot publish official content with them. The suggestion was to split it: the static official publication in the IG, the interactive exploration hosted separately as a community project, with narrative links bridging the two.
• A related doubt about authoring: FHIR Shorthand may not be the right way to write a view. The comparison drawn was CQL, where a .cql file gets a first-class editing experience through editor plugins, versus writing views in shorthand because that's what IGs happen to use. Either way, what has to come out of the far end is a FHIR package, and you can build one of those without the IG publisher. Separately, the Parquet schema was promoted out of the parking lot into a work stream of its own; value sets and terminology stayed parked.