Topics discussed:

• The shape agreed: maintenance of the spec and its infrastructure as an ongoing stream, core spec development for the next milestone, authoring and publishing, the query resource, and use cases. On the core spec, the roles idea was borrowed from how SDC does it — split by role and give each role its API. A repository role is straightforward, essentially CRUD and search; a validator or a runner needs more than that. Bulk FHIR was folded in as an export API rather than kept as its own topic, on the argument that it is the same question and the group wants one coherent API strategy.
• The organising principle came from John: don't invent in isolation. Every spec work stream should have an implementation of something running in parallel, preferably rooted in reality and worth doing in its own right — so that when the group decides something, it can point at a real thing where it demonstrably works. Someone called it implementation-grounded standards work: not driven by the implementation, but never running ahead of one.
• The query resource — a resource carrying a SQL query in a stated dialect, linked to the ViewDefinitions it reads — was deliberately kept as its own stream, because the first decision is whether to do it at all. The case for it is that once views are flat, SQL is close to portable and dialect translators already exist, so queries could be packaged and distributed alongside the views. The caution raised was that designing the resource without concrete use cases is a bad idea; data quality checks and an OMOP conversion were suggested as the stress tests, one for aggregates and one for transformation.
• On US Core, the point made was that flattening all of it amounts to flattening all of FHIR, and you end up with unworkable tables — too many fields, too much nested repetition. The useful version is narrow use cases carved out of it: data quality assessment, patient contact details unnested down to the one address you'd actually use to reach someone, quantitative lab results, blood-pressure-style observation profiles that flatten obviously. Doing every kind of Observation is where it stops being tractable.
• FHIR-to-OMOP and MIMIC emerged as the anchoring projects. MIMIC already ships a derived layer that is effectively value-add views over the top, which is exactly what SQL on FHIR could produce instead. A funded FHIR-to-OMOP effort is intended to yield an open-source tool, and the group asked for it to be split early — real data and tooling on one side, the ViewDefinitions and test data on the other — so that the open half can be worked on collectively rather than handed over finished.