Hey folks!
Quick disclosure: I’m a Director at Rhino Federated Computing, so yes, this is a vendor post. But I’m also a certified informatics nerd who did a PhD at Columbia 
The offer
Any OHDSI implementer can have a free license of our Data Harmonization Engine (DHE), a no-code tool for getting source data (EHR extracts, registries, claims, flat files) into the OMOP CDM (and user-defined custom schemas). If you are curious what a platform for federated learning looks like, you’ll get to see and try that out too! No strings other than you let me know how the tool could be improved!
Everyone is doing it…
It is super exciting to see so much academic and commercial activity of AI-assisted data harmonization. See Artem’s LLM-powered conversion tool post from last year. On the commercial side there’s the IQVIA OMOP Converter and on the open-source side is the very nice Perseus, tool on top of the OHDSI stack itself.
Lots of good papers also: Adams et al. JMIR 2025 built an LLM-embedding OMOP mapper hitting 0.92–0.99 precision, Zhou et al. AMIA 2024 got 96.5% on drug mapping with sentence transformers, and the Nottingham group’s open-source Carrot + Lettuce does AI-assisted mapping to standard concepts under an MIT license.
…but we are committed to federated harmonization
It’s harder than single-site conversion: federated data harmonization. We have customers who want to run studies across multiple continents that all need an OMOP instance, none of the data can leave any of them, and the person writing the mappings can’t look at row-level data at the clinical sites. You have to build mappings once and run the ETL inside each site’s own environment. Single-site conversion is the simpler case of the same problem, so if you’ve got one database and want OMOP, it handles that too.
Why give it away?
The most important one is that the OHDSI community is the toughest arena there is for validating an OMOP tool. If our mapping to OMOP holds up here, it holds up anywhere.
Second, unlocking access to distributed health data is literally why we started our company. Data that can’t move is still data that should be usable for research, and OMOP is how that research gets done at scale. More OMOP instances in the world is good for us and good for everyone here.
Third, both academic consortia and industry partners are asking us to map local data at their partner sites to OMOP so they can run federated analyses. We want that mapping to be excellent, not just adequate, and the fastest way to get there is to put the tool in front of people who will notice when it isn’t.
What you get
- AI-assisted semantic mapping — source values get matched to OMOP standard concepts and domains; you review, accept, or override using an intuitive interface.
- No-code syntactic mapping — source tables and columns map to OMOP tables, with transformation logic defined in the UI instead of hand-written SQL.
- Runs where the data lives — source data never leaves your environment.
- Mappings are portable — semantic mappings export as CSV (source value → OMOP concept and domain), transformation logic as JSON (every source-to-target mapping and rule, per OMOP table). Version them, document with them, reimplement them anywhere.
- Standard output — tables per the CDM v5.4 instance with support for 5.5 soon to follow.
How does it work?
In short, we do semantic mapping behind site firewalls using a purpose-built small language model (MedGemma) and we send metadata across the site firewall to a commercial LLM before the recommended mapping comes back and is deterministically transformed to an ETL.
If this sounds interesting to you reply here or email me! I’m daniel [at] rhinofcp [dot] com
Thanks and see you at the symposium later this month!