Topics discussed:

• Nikolai's proposal is to let SQL queries reference other SQL queries, which turns out to be most of what dbt does. Analytics people build a DAG: tables at the bottom, a layer of views, another layer on top of that, and a graph saying what depends on what. SQL on FHIR already has queries referencing ViewDefinitions, so the missing piece is small — express the dependency, and give one query a name the next one can use as a table. Whether any given layer is materialised, a view, or ephemeral is left to the implementation, exactly as it is in dbt. The prize is being able to hand someone a whole data mart as an IG, which a vendor could then transpile into dbt, SQL Mesh or whatever they run.
• Arjun Sanyal had checked dependsOn against how Library already uses it for CQL and found it semantically compatible, so the spec impact looked near-zero. Gino Canessa wondered whether composedOf was closer to the truth, at least for the CTE-shaped case, but then made the more useful point: whichever word wins, the type won't carry enough information. A related artifact might be a query, or a source table, or a mapping table used inside a translate — logically different things — and the MIME type of the attachment can't tell you which. He went looking for a coded classification element on relatedArtifact, couldn't find one, and said he'd file a ticket, on the grounds they can't be the first people to want it.
• Steve Munini asked the awkward question: if a query can depend on a library, and a library can hold basically anything, can it depend on a CSV? Say, a list of US states. John liked it as a use case — in data lake land you pick up a CSV or a parquet file, infer the schema and start querying — but it isn't a query and it isn't a ViewDefinition. Nikolai's name for it was an external or virtual table, and the objection to standardising it now is that a reference to a local table isn't interoperable unless it means something to whoever receives it. Start with queries and ViewDefinitions; let implementations experiment with extensions.
• John made the case for terminology functions in SQL on FHIR, and the two that matter are memberOf, which already exists, and translate, which has no acceptable answer yet. The choice is stark: either force people to flatten system, code and display into columns and do the lookup in a second step, or offer a small abstraction that the runner fills in behind — which could be a terminology server, or concept tables, or OMOP's Athena, and the spec need not care which. His critique of FHIRPath's %terminology is that it went for total expressivity and got an interface nobody wants to use — you can't hand it a coding and get a translation, you call an arbitrary operation and traverse parameters — which is why Pathling implemented the ordinary functions faithfully and reinvented translate. He isn't going to build the rest if it's about to be removed.
• Two extension questions with the same shape. Nikolai wants FHIRPath to have modules — a way to declare a subset or an extension as a list of functions and operators — and Gino's answer was that no formal notation exists; guides already bolt functions on (SDC has questionnaire ones), they're just narrative scattered across pages, and even a consolidated page listing what a guide adds would be an improvement. Nikolai suggested a CodeSystem of functions; Gino, deadpan, offered a ConceptMap for the outputs. The other question was a proposed hash function for de-identification while flattening, where Gino hesitated on principle: which hash, reversible or not, whose implementation — he doesn't want to be on the hook for the wrong answer, and thinks a separate anonymisation guide extending SQL on FHIR would let people find out what's useful first. John added the practical killer: there's no portable way to hash in SQL anyway, and any new FHIRPath functions would go in a profile rather than the core spec.