OMOPHub

What's new at OMOPHub? April 2026 recap +51% new users +300% API queries served We shipped some major updates to OMOPHub: - FHIR Terminology Service: Healthcare systems using FHIR can now connect to OMOP vocabularies through a standards-compliant FHIR Terminology Service supporting R4, R5, and R6. No custom integration code, no glue layer. Just point your FHIR client at our endpoint and run $lookup, $expand, $translate, and $validate-code against 10M+ medical concepts. - Hosted MCP Server: Our Model Context Protocol server is now fully hosted. AI assistants like Claude, Cursor, and VS Code can query OMOP vocabularies in under a minute of setup - no Docker, no self-hosting, no infrastructure work. - AI agent documentation: Launched a complete documentation suite for AI builders: llms.txt, llms-full.txt, skill.md, and the OMOP-Loop integration pattern for grounding LLM-generated clinical codes. https://lnkd.in/eHkVj4ra - Python & R SDKs v1.7: FHIR interop built in. Both SDKs now speak FHIR natively alongside the standard OMOP API. Plus: vocabulary refresh (ATHENA v20260227) and continued performance work. Try it all on omophub.com and we keep shipping! #HealthcareData #OMOP #OHDSI #MedicalVocabularies #HealthTech #API #FHIR #MCP #AI

Last month we watched a webinar where a hospital informatician said: "We have FHIR. We need OMOP. And we have no idea how to get from one to the other." 100+ people on the call nodded. Belgium just officially chose OMOP for secondary use of health data. FHIR R4 is mandated for primary use. Every hospital in the country now sits between two standards, and the bridge doesn't exist. Except now it does. Today we're shipping a FHIR R4/R5/R6 Terminology Service for OMOPHub. What it means in practice: → Your EHRbase instance can validate coded elements against OMOP vocabularies → Your ETL pipeline can $translate ICD-10 codes to OMOP concepts in one API call → Your LLM pipeline can look up the correct SNOMED concept for "allergic rhinitis due to pollen" - programmatically → Your HAPI FHIR server can use OMOPHub as a remote terminology service And the one we're most excited about - the Concept Resolver: Give it a FHIR code (system + code). Get back the OMOP standard concept, the target CDM table, and PHOEBE-recommended related concepts. One call. The entire FHIR-to-OMOP vocabulary step of your ETL, as an API endpoint. Try: https://lnkd.in/e2BHRD7S What OMOPHub adds: - FHIR code in, OMOP concept + Phoebe recommendations out - R4/R5/R6 versions - Semantic search - Python, R, and MCP SDKs - Works with EHRbase out of the box Docs: https://lnkd.in/ebupqr_E If you're building FHIR-to-OMOP pipelines or you're one of those 100+ people who nodded on that call, we'd love to hear what your current vocabulary setup looks like. #FHIR #OMOP #OHDSI #HealthcareInteroperability #HealthTech #OpenEHR #EHDS

Today our colleague fell from a chair during a call. He's fine. But naturally, the first thing we did was check: is there a medical concept for this? Turns out - yes. ICD-10-CM W07: "Fall from chair." Mapped to SNOMED concept 4308870. The medical world really does have a code for everything. Find concepts with OMOPHub directly in your AI editor. Works with Claude Code, VS Code, Cursor. What's the most unexpected medical concept you've come across? Drop it in the comments 👇 https://lnkd.in/eRVdstu7 #OHDSI #OMOP #MCP #HealthcareData #HealthcareAI

We made an assumption when building OMOPHub. And the data proved we wrong. When we started, everyone in the OHDSI community said the same thing: "This is an R world." OHDSI was built by epidemiologists and biostatisticians. The tutorials are in R. The community tools are in R. So naturally, we prioritised the R SDK. It made total sense at the time. Then we launched. And we started looking at the actual usage data. Here's what we found: ~ 80% of API calls - Python ~ 15% - R ~ 5% - Postman, curl, and other tools This wasn't what we expected. But it makes sense when you think about it. The OMOP ecosystem is quietly attracting a new wave of people: data scientists, ML engineers, healthcare AI teams. They're doing the same work: ETL pipelines, concept mapping, phenotyping. But they're doing it in Python. The community didn't change overnight. It just gradually expanded beyond its origins. We think there's a lesson here about assumptions. The "obvious truth" in any field is usually a snapshot of who was there first - not who's there now. What do you use for your OMOP or healthcare data work? We'd love to know if your experience matches the data. #OHDSI #OMOP #HealthcareData #Python #RStats #RealWorldEvidence #HealthcareAI

A few months ago, a data engineer at a Dutch academic medical center sent us a message. His team was preparing for a multi-site cardiovascular outcomes study under the new EHDS framework. The study design was done. The HADES scripts were ready. The sites were aligned. But before they could run a single DataQualityDashboard check, they were stuck on step zero: getting the vocabulary. Local databases on every site. Three sites, three setups, three slightly different vocabulary versions. Two weeks before they could run their first concept lookup - and even then, they weren't sure the versions matched across sites. We hear this story constantly. Different teams, same bottleneck. Here's what made it click for us: The OHDSI community defines a five-step process for EHDS-compliant observational studies: 1. Exploration 2. Initiation 3. Implementation 4. Execution 5. Dissemination Vocabulary quality is critical at two specific points: Step 1 - Exploration. You run DQD to assess concept coverage and mapping completeness. If your ATHENA copy is months out of date, your data quality output is quietly wrong. The pipeline looks fine. It isn't. Step 3 - Implementation. You apply HADES packages across multiple sites. The goal is comparable results across EU member states. That only works if every site is resolving concepts against the same vocabulary version. When each site runs its own local database, you can't guarantee that. This is exactly what OMOPHub was built to solve. One API. Same version, every site, every run. No local database, always current with OHDSI ATHENA releases. For teams building toward EHDS compliance, especially multi-site federated studies, vocabulary consistency isn't infrastructure. It's methodology. https://omophub.com/ehds #EHDS #OMOP #OHDSI #RealWorldEvidence #HealthcareData #EuropeanHealthDataSpace

LLMs are terrible at medical terminology. And that's actually fine. They don't need to memorize 10+ million OMOP concepts. They just need the right tools to look them up. Today we open-sourced an MCP server for OMOPHub that does exactly that. Your AI agent can now: → Search concepts across SNOMED CT, ICD-10, RxNorm, LOINC, and 100+ vocabularies → Get details for any OMOP concept by ID or code → Map between vocabularies in real time → Walk the full concept hierarchy: ancestors, descendants, or both No more hallucinated codes. No more invented concept IDs. Every result comes from the actual OMOP standardized vocabulary. Works with Claude Desktop, Claude Code, Cursor, and VS Code. One command: npx omophub-mcp Pascal Bolla's recent SNOMED MCP post struck a nerve - 150+ reactions and 30+ comments from people who share this exact pain. His tool solves it for SNOMED via FHIR servers. OMOPHub MCP extends it to the full OMOP vocabulary stack with built-in cross-vocabulary mapping. Same mission. Complementary approaches. Try it out: https://lnkd.in/eH8iQzVv Free API key: https://omophub.com More MCP tools for health informatics are coming. Follow along if you're interested. #OHDSI #OMOP #CDM #MCP #SNOMED #HealthData #ClinicalInformatics #AIinHealthcare #OpenSource #RealWorldData

What's new at OMOPHub? February 2026 recap User base growth 200% Served 250% API queries more than in January We shipped some major updates to OMOPHub: 1. Semantic Search API: Our API now combines lexical and semantic search for medical concepts. It detects query intent automatically (acronym? clinical description? drug name?) and adjusts the ranking strategy. Two fusion modes available: score-based and Reciprocal Rank Fusion. 2. MCP Server: AI assistants like Claude or Cursor can now query OMOP vocabularies directly through our new Model Context Protocol server. Search concepts, explore hierarchies, and look up mappings. All from your AI workflow. 3. Python & R SDKs v1.4: Both SDKs now support semantic search and similarity search out of the box. Plus: performance optimizations and updated documentation. Try it all on omophub.com and we keep sheeping! #HealthcareData #OMOP #OHDSI #MedicalVocabularies #HealthTech #API #MCP #AI

New OHDSI Vocabulary release (v20260227) is now available on OMOPHub! Here are some highlights: - HPO (Human Phenotype Ontology) added as a new vocabulary — with nearly 19,400 concepts and mappings to SNOMED - Over 100,000 new concepts added across vocabularies, including major updates to SPL (~41K), NDC (~24K), CIEL (~7.5K), EDI (~4.7K), HPO (~19.4K), RxNorm (~2K), and VANDF (~1.3K) - Thousands of improved and new concept mappings, including 27K+ RxNorm Extension concepts remapped from Standard to Non-standard with mapping - Domain reassignments across CIEL and MeSH for more accurate data categorization - New vocabulary dependencies introduced, connecting CIEL to LOINC, OMOP Extension, CVX, and more Full release notes: https://lnkd.in/eDkiFgNr #OHDSI #OMOP #CDM #RealWorldData #HealthData #Vocabularies #Informatics

Semantic Search for Python & R SDKs! Just Shipped! Find OMOP concepts using natural language. Now natively in both SDKs. "heart attack" → Myocardial infarction "sugar diabetes" → Type 2 diabetes mellitus More details: https://lnkd.in/eimh_i34 #OMOP #OHDSI

Big update to http://omophub.com's search API: Query "CHF" finds "congestive heart failure" New features: - Concept semantic search - Medical abbreviation expansion - Typo correction - Hybrid lexical+semantic fusion Docs: https://lnkd.in/eWHXccUh #OMOP #OHDSI