Topics discussed:

• Nikolai had been translating CQL quality measures into OMOP and reported that it works extremely well — OMOP is built around cohorts, the terminology arrives normalised, and population-level work looks tidier there than it does in FHIR. Gino pushed back on the whole framing: OMOP has already made modelling decisions for you, and that is precisely why SQL on FHIR exists. Quality measures run over live site data. A simplified table with one patient name is easier, right up until you need to track seven names and the model has one. Nikolai conceded the point — his claim was about clinical BI, not about FHIR being worse — and Gino's summary held: if OMOP meets your needs it's great, and if you need to express something OMOP doesn't have, you're out of luck. Arjun added the uncomfortable corollary: research practice has partly been tuned around OMOP's limits, so "just use OMOP for that" isn't as neutral as it sounds.
• Gino's second objection was sharper, because it went after OMOP's best feature. The normalised terminology is simplified, but it isn't true. Almost every site does its own mappings, because almost nobody actually uses those terminologies natively — vendors have internal procedure codes, and what those look like publicly shifts with every ICD and LOINC release. So sites maintain mapping tables and update them constantly, which means a normalised dataset is a good snapshot of what you believed at the moment you built it, and updating the terminology means regenerating everything.
• Steve Munini asked the question nobody asks out loud: FHIR ships an OWL download, SNOMED is delivered in OWL, so why has nothing built on that? Nikolai's answer was a fond eulogy — he loves RDF, triples and datalog, and thinks it's theoretically the best model for representing data that anyone has come up with — followed by the reason it lost. It's like functional programming: lovely, immutable, and not efficient enough, and people need performance. He does expect a revival on the back of graph RAG. Footnote for the historians: SMART was originally an RDF and SPARQL system before it was rewritten onto FHIR.
• The join function is a genuine breaking change waiting to happen. The tests carry an expectation that disagrees with FHIRPath — the correct answer is an empty collection — and every implementation was written to pass the tests, so fixing the tests breaks the implementations. It's worse than it needed to be because join leaked out of the experimental section into the non-experimental one, which John owned as the group's own fault. The plan is to wait for Brian's FHIRPath test refactor, check whether join is even going normative, and then bite the bullet as part of the ballot work.
• Nikolai argued against parking a pull request until an upstream spec settles — a very long-lived branch is a terrible thing to merge later — so the async work should go into the edge spec now and be corrected when the bulk data pattern lands. John agreed and added the tactical reason: pointing the async folks at a spec that already does the thing is a better way to align with them than waiting to see what they produce.