Topics discussed:

• Arjun described the query resource as a fairly simple thing nobody has written down: a resource that wraps a query and says which dialect and version it's in. He's more interested in it as a component of something wider — for want of a better name, an analytic.
• That analytic would package the metadata, a set of ViewDefinitions, a set of query resources, sample data and sample outputs together. Bundle all of it and you have something portable: not just the flattening, but the question and the evidence it was answered correctly.
• Steve made the case for why some grouping mechanism is needed at all, from his own implementation work: a ViewDefinition maps to one FHIR resource, but a real question of the data spans several. So you always end up with a collection of views plus a query on top before you get to an answer, and today there's nothing that holds them together.
• Arjun had gone away and read CRMI, and reported back that it is designed for authoring, packaging and distributing knowledge artifacts generically — a package can hold any FHIR artifact — with its real traction today being the npm tarballs an IG publishes. His conclusion was that it operates at a different architectural level from a query resource, so it's worth taking a CRMI mindset to this work, but the two won't slot together seamlessly.