Topics discussed:

• Two alternatives to the macro language were put up against it. Brian asked why not target ANSI SQL 2016, which already standardises JSON access, and translate that instead of inventing a DSL. Dan Gottlieb's version: don't invent anything, write to one base SQL dialect and translate to the others — OMOP does exactly this for its warehouse (SQL Server as the base, a translation engine for Oracle and friends), and SQLGlot parses SQL into an AST and regenerates it in other dialects; you swap one join syntax for another without changing the shape of the query, and the further you go into your own DSL the more tooling you maintain forever. Nikolai's answer was empirical — the standard has been out for years and nobody implements it, only Postgres supports close to the full JSONPath spec, Oracle a little, everyone else has dot-and-index — so "unless you try you will not understand the details": build it in the playground and bring a proposal, because this is a hypothesis, not something he was driving.
• Ryan Brush reframed why the argument wasn't converging: people are starting from different objectives and different values — ease of implementation against a thorough, portable, standards-based spec — and the right answer depends on which you weigh more. He offered his own objective plainly: a well-defined way to describe flattened views of FHIR data that are portable across many database implementations, standing on existing standards wherever possible. Which, full disclosure, pulls him towards FHIRPath, or at least a subset of it, because it is established and its semantics are already defined.
• Then the data point that changed the room: proof-of-concept work at Google that translates a large set of FHIRPath expressions into SQL that ports across engines, running today on BigQuery and mostly on Apache Spark, emitting the right unnest or lateral view explode for each. It is genuinely more complicated — you parse FHIRPath into an AST and recursively translate that into SQL — and Ryan put the cost honestly: "is that complexity justified? That's where it gets back into what the values are." The upside he pointed at: once your columns are described by FHIRPath expressions, you can point them at a pile of NDJSON and get a data frame. A demo was promised for the following week.
• The goal itself was quietly moving, and Ryan asked the group to make it an explicit decision rather than a drift: from "find a SQL-on-FHIR representation that works in plain ANSI SQL" to "find a standard way to describe flattened views of FHIR data" — the base layer will always vary too much between engines to query portably. Three options were on the table: a definition language of its own (FHIRPath, JSON Path, something CQL-like), a base SQL dialect plus translation, or a macro language, possibly FHIRPath-based, mixed into SQL. One participant was sceptical that any standard set of views could ever cover even 90% of use cases — better to standardise how a view is defined and let the useful views spread on their own — while Evan wanted a base schema published soon, because every company that gets FHIR and a warehouse invents its own schema, and guidance arriving late means there is nothing left to standardise.
• Evan supplied the reason any of this matters: run the measures where the data lives. Today you download the whole database every night, deserialise it, and execute somewhere else — most of the time goes on the download and the deserialising — so even badly written in-database queries would be orders of magnitude faster, close to real time, and all the effort spent shrinking the data pulled down is solving the wrong problem. His own caveat was that real CQL is not the one-file demo measures everyone shows: interval arithmetic, date precision, continuous enrolment, measures with fourteen numerators — and without user-defined functions in the target database you may not get there at all. The call closed on the first sketch of a view: take the logical model Brian had demoed on the first call, attach a FHIRPath expression to each column saying what to extract, and that is your base view — join and build the rest on top, leaving whether it is materialised as a table, a view or a materialised view as an implementation decision.