OMOP looks tidier for measures — Gino Canessa answers that its modelling bets are why SQL on FHIR exists — Mar 31, 2026
Nikolai — OMOP works extremely well for quality measures
Built around cohorts, the terminology arrives normalised, and population-level work looks tidier there than it does in FHIR.
Gino — that's exactly why SQL on FHIR exists
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 — 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.
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 sharper objection — the normalised terminology isn't true
Simplified, but not 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 — why has nothing built on OWL?
FHIR ships an OWL download, SNOMED is delivered in OWL, so why has nothing built on that?
Nikolai's answer — a fond eulogy:
I love RDF, triples and datalog, and think it's theoretically the best model for representing data that anyone has come up with. 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.
join — a 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: 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.
Async — go into the edge spec now, not wait
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.