FHIR-to-OMOP next steps, a member-of profile for FHIRPath, and distributing terminology in relational form — Oct 13, 2026
Helios implementation and the "not done until three or four" bar
Steve Munini stepped out early to pick up a relative from the hospital and left two of his engineers, Alvaro Salinas Dockar and Mauricio Penaranda, on the call. John Grimes used the opening to recap the terminology-relations work for them: value set and concept map dependencies declared alongside a SQL on FHIR query, each exposed to the query as a joinable table whose contents the implementation populates however it wants - live call to a terminology server, pre-packaged batch for ETL, or something in between. Both Pathling and the JavaScript reference implementation now support both abstractions.
Steve's team is picking it up next; Mauricio handles the database side and Alvaro expects to have something to show at next week's call. Nikolai Ryzhikov asked them to keep a running list of corner cases and anything they dislike while implementing - that is the feedback the spec most needs right now. John was explicit about the bar for calling this part of the work done:
We don't really regard something as done in this spec until we've got at least three or four implementations that we can see that are diverse and that can actually show that this is feasible and portable.
John also flagged flat-quack as another target he wants to port onto the new terminology relations once bandwidth allows.
FHIR-to-OMOP: a shared conformance test suite as the central contract
Nikolai proposed dedicating a run of upcoming meetings to FHIR-to-OMOP and inviting people who care, with the first step being to split his prototype repo into three distinct pieces. The first and most important piece is a golden test suite: FHIR input, OMOP output, independent of the technology used to perform the conversion. The second is a set of profiles that guarantee a conforming resource can be translated to OMOP, mostly a terminology-and-required-fields exercise. The third is the dbt-style SQL-on-FHIR conversion itself, which belongs to Health Samurai and should be treated as one reference implementation among many.
The deliberate shape is that the tests are the central contract and the conversion machinery is pluggable:
I think the central part is the test. The guys from the FHIR-to-OMOP group tried to write FML for that. We want to write SQL. I'm pretty sure that in real production people will do a hybrid or something else, converting with code, converting with something else. So the conformance test should be first, so people can test against this test suite and be sure they are converting the right way.
Nikolai sees the core suite as a manually curated set that everyone agrees on, with optional modules contributed by implementers from real projects (with corner cases, with mapping decisions documented). The FHIR-to-OMOP working group has already built a logical model that can express these tests, so the test repo could eventually transfer to them. Nikolai had earlier discussed this with Davera and the response was positive.
Nikolai has also written a small number of concept maps for required FHIR bindings - gender, encounter status, that kind of thing - which do not currently exist on the OHDSI side. The right move is to contribute these back to Athena so OHDSI assigns stable IDs, though finding the person responsible for terminology at OHDSI has been difficult.
John's work covers four or five real studies as SQL-on-FHIR view sets with a Pathling harness that executes them end-to-end against the full MIMIC-IV. He plans to tidy it up and open-source it so Nikolai can pull the tests out and merge them with his own. In the process they turned up discrepancies between direct MIMIC-to-OMOP conversion and the MIMIC-to-FHIR-to-OMOP path, including some points where John and Nikolai both disagree with the official MIMIC-to-OMOP conversion. Fake ICD codes in MIMIC that need to be mapped to real ones before any OMOP mapping can happen is one of the open items.
A student from the University of Lubeck has been sitting with John for six months building agentic SQL-on-FHIR analytics pipelines over MIMIC-on-FHIR and has also converted MIMIC-derived (the layer of aggregated views that sits on top of MIMIC-IV) to SQL on FHIR. John expects to surface that work alongside the OMOP open-sourcing.
John is also putting together an OMOP track for the Australian connectathon in December and would like to walk in with something concrete to demo.
A member-of profile for FHIRPath
John wants a new optional view-definition profile that adds a single function from the FHIR spec, memberOf, giving FHIRPath parity with the terminology support the group just finished adding on the SQL side. The idea is progressive enhancement: implementations declare support for the profile, and clients can then rely on memberOf inside FHIRPath expressions without the function becoming part of the core subset.
John also wants translate in the profile eventually, but the current translate is not very good; he will pick up Brian Kaney's JIRA tickets on modernizing the terminology FHIRPath functions, which Brian has been unable to progress alongside everything else, and work with Grahame to form up a cleaner proposal.
Nikolai agreed. The implementation looks tractable, especially now that value sets have a relational representation to lean on:
If we're introducing value sets and this representation, it looks like people can do that. There still will be some challenge for the ETL-line guys, but I think they will figure out. We probably can do some reference implementation here with some naive value-set lookup.
John pointed out the symmetry: once an engine can produce a value-set relation, implementing memberOf becomes "do a SQL lookup on that relation and put the boolean into a column" - the same primitive, exposed through a different interface.
Distributing terminology in a lossless relational format
Nikolai raised the terminology-distribution thread he has been pushing in the Zulip chat with Grahame and Michael. The core problem: huge JSON code systems have run out of memory even inside Ontoserver, and the current ecosystem assumes an always-on terminology server with syndication layered on top - which falls over as soon as a server is offline or overloaded. Nikolai wants something closer to NPM for terminology:
I would love to have something like NPM distribution but done for terminology, which means it could be huge amounts of data. So it should be like some S3 bucket-based protocol - how you can distribute terminology, how you can distribute the diffs - and then you need some format to do that.
Nikolai's claim is that this is already technically possible. Termbox is fully relational internally, with a logical model that is very close to Athena's, and the Health Samurai team is passing roughly 70 to 80 percent of Grahame's terminology tests from that representation alone - enough to cover ECL and start on VCL. A community-standard relational format (CSV, Parquet) that is isomorphic to the FHIR terminology model and lossless would let implementers share scripts and content without each one having to maintain its own ingestion pipeline from raw RF2, LOINC releases, and so on.
John partly agreed and partly pushed back. He is skeptical that raw-format distribution scales on its own, since every consumer would then redo the same expensive enrichment and indexing work that a terminology server does once:
If we just distributed the raw format everywhere and asked everybody to do that themselves, that would be a huge amount of unnecessary compute. So there almost needs to be space for intermediate distribution formats that are pre-baked and ready to go for serving. The requirements for online terminology services are distinct from analytics, and analytics has not really had a look-in on this.
His procedural read was that the right next step is a sustained working meeting between Nikolai, Grahame, Michael, and the clinical-architecture people in the US who supply much of that layer in the US ecosystem. Nikolai noted that he disagrees with Grahame's current position (FHIR terminology servers everywhere plus syndication) and that this is exactly the kind of disagreement that needs the room, not another round of Zulip threads.
Both agreed that medications are the hard part - RxNorm is nice in isolation but there is no cross-country standardization and that will take years, possibly tracking the global adoption of OMOP. LOINC and ICD are easier because they already map to SNOMED, and SNOMED itself has an agenda to open up its licensing, which if it lands removes a large chunk of the current friction. The remaining open question is funding: whatever model replaces the current one still has to connect users to payers so the terminologies can continue to be maintained.
Nikolai framed the stakes bluntly: distributing even just the open parts of FHIR terminology - the code systems inside IGs - plus agreements with LOINC, RxNorm, and SNOMED on acceptable terms would cover roughly 80 percent of the problem and save a lot of human-years across the ecosystem. The two parked the rest of the philosophy for Zulip.
Ballot reconciliation deferred, STU release wanted
Ballot reconciliation came up and was deferred again because it depends on Gino Canessa, who was not on this call. The plan is to invite him next week. John also flagged that he wants an STU release of the work already completed - the terminology relations, the view-definition subset, the pieces that have shipped PRs - independent of whatever remains in the ballot queue.
The group will probably skip next week's meeting because John is at the SNOMED CT conference, and will reconvene the week after.