Two philosophies of flattening, and what each one costs you later — May 5, 2026
Craig's FHIR-to-OMOP converter
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: 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.
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 — 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.
Column names encoding deep nested structure are fine for an LLM and painful for a BI tool or a human. 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 — the fairest short description of OMOP
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 — rename "inter-query dependencies" to "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 — what implementation feedback is actually worth
His team has been adopting the specs as they land and building products on top of them.
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.