Topics discussed:

• Craig McClendon has a FHIR-to-OMOP converter that predates this group — a JSON spec naming source, target and the transformations in between — and it does several things SQL on FHIR still can't: terminology lookups, foreign key construction, and record identity, meaning which fields decide whether an incoming resource is a new row or an update to an existing one. His plan is to point it at the current spec, use tags to paper over whatever's missing, and bring the resulting gap list back to the group to argue about priorities.
• The real discussion was two philosophies of flattening. Brady Bastian's BigQuery work, presented at Agents on FHIR a fortnight earlier, blows every FHIR resource out into tables with the FHIRPath encoded into the column keys — maximally generic, decide nothing up front. ViewDefinitions do the opposite: you decide, per analytic question, what the table looks like. Steve reached for one of Graham's lines — you can't reduce complexity, you can only move it around — and Arjun's objection to deferring it was that column names encoding deep nested structure are fine for an LLM and painful for a BI tool or a human. His broader point: healthcare has a real appetite for determinism, transparency and repeatability, and a design that needs a language model in the loop to be usable gives those up.
• Craig gave the fairest short description of OMOP anyone managed all quarter: a narrow, very normalised model that's convenient if you're hitting conditions, medications and encounters, whose genuine killer feature is Athena — hundreds of curated terminologies in one data model, so you don't curate them yourself. Step outside the model, though — genomics was the example — and there are no first-class tables and you're adding your own.
• Arjun wants "inter-query dependencies" renamed. He proposed "query pipelines" or "chained queries", and made the case that this is the next real chunk of work rather than a nicety: nobody uses a ViewDefinition or a query as an isolated thing, so there's always some superstructure around them, and this is what lets you declare it instead of improvising it. He also wants people who use dbt every day in the room, rather than the group reasoning about it from the outside.
• Steve made the case for what implementation feedback is actually worth. His team has been adopting the specs as they land and building products on top of them, and his point was that however baked an idea looks on paper, you don't know until hundreds of hours and terabytes have gone through it — which is the argument for shipping implementations before the ballot rather than after.