Search, map, and resolve medical vocabularies. The OMOPHub is a terminology layer for OMOP, FHIR, and healthcare AI with 11M+ concepts through one managed API.

OMOPHub provides instant REST API access to OHDSI ATHENA standardized vocabularies - SNOMED CT, ICD-10, RxNorm, LOINC, and 100+ medical terminologies. Search concepts, build mappings, and automate ETL pipelines without setting up a local database.

Working with OMOP vocabularies traditionally requires downloading multi-gigabyte ATHENA files and maintaining a PostgreSQL database. OMOPHub eliminates this overhead:

Perfect for: ETL development, concept set building, phenotype definitions, AI/LLM integration, and any workflow requiring vocabulary access without infrastructure.

Python:

importomophub# Initialize client (uses OMOPHUB_API_KEY env var)client=omophub.OMOPHub()
# Search across vocabulariesresults=client.search.basic("diabetes mellitus", vocabulary_ids=["SNOMED", "ICD10CM"], standard_concept="S", page_size=10)
# Get concept with relationshipsconcept=client.concepts.get(201826) # Type 2 diabetes mellitus# Map SNOMED concept to ICD-10-CMmappings=client.mappings.get(201826, target_vocabulary="ICD10CM")

R:

library(omophub)
# Initialize client (uses OMOPHUB_API_KEY env var)client<-OMOPHubClient$new()
# Search across vocabulariesresults<-client$search$basic("diabetes mellitus", vocabulary_ids= c("SNOMED", "ICD10CM"), standard_concept="S", page_size=10)
# Map source codes to standard conceptsmappings<-client$mappings$get(201826, target_vocabulary="ICD10CM")

Node.js / TypeScript:

import{OMOPHub}from'@omophub/omophub-node';// Initialize client (uses OMOPHUB_API_KEY env var)constclient=newOMOPHub();// Search across vocabulariesconst{data: results}=awaitclient.search.basic('diabetes mellitus',{vocabularyIds: ['SNOMED','ICD10CM'],standardConcept: 'S',pageSize: 10,});// Get concept with relationshipsconst{data: concept}=awaitclient.concepts.get(201826);// Type 2 diabetes mellitus// Map SNOMED concept to ICD-10-CMconst{data: mappings}=awaitclient.mappings.get(201826,{targetVocabulary: 'ICD10CM',});

AI Agents (MCP):

Give Claude, Cursor, or any MCP-compatible AI agent direct access to OMOP vocabularies:

{
"mcpServers": {
"omophub": {
"command": "npx",
"args": ["-y", "@omophub/omophub-mcp"],
"env": {
"OMOPHUB_API_KEY": "oh_your_key_here"
}
}
}
}

Then just ask your AI agent:

"Map ICD-10 code E11.9 to SNOMED""Build a concept set for Type 2 diabetes including all descendants""Find concepts related to heart attack" (semantic search) "Give me everything about SNOMED concept 201826" (explore)

Get your API key →

SDK	Package	Repository
Python		omophub-python
R		omophub-R
Node.js		omophub-node
MCP Server		omophub-mcp

The OMOPHub MCP Server connects Claude, Cursor, VS Code, and any MCP-compatible AI client directly to the full OHDSI vocabulary. No SQL. No database. Just ask.

You: "Map ICD-10 code E11.9 to SNOMED"
Claude: Found it - E11.9 (Type 2 diabetes mellitus without complications)
maps to SNOMED concept 201826 via standard 'Maps to' relationship.

# Claude Desktop / Cursor / VS Code - add to your MCP config:
npx -y @omophub/omophub-mcp
# Docker
docker run -e OMOPHUB_API_KEY=oh_your_key_here -p 3100:3100 omophub/omophub-mcp

Full setup instructions for Claude Desktop, Cursor, VS Code, and Docker: omophub-mcp →

OMOPHub ships a FHIR R4 / R4B / R5 / R6 Terminology Service at https://fhir.omophub.com/fhir/{version}/ so FHIR-native tooling can plug in directly. The service implements the standard FHIR terminology operations against the same OHDSI vocabulary data as the REST API, with a documented XML support matrix and an OAuth2 client_credentials shim compatible with Spring Security clients.

Verified clients: HAPI FHIR 8.8.0 (RemoteTerminologyServiceValidationSupport), EHRbase (openEHR, via native OAuth2 client_credentials), fhirpy, fhircrackr, Firely, raw curl / httr2.

FHIR Terminology Service overview → · Interop test matrix →

A higher-level endpoint designed for FHIR-to-OMOP ETL pipelines. POST /v1/fhir/resolve takes a FHIR Coding (or CodeableConcept) and returns the OMOP standard concept, the CDM target table (condition_occurrence, measurement, drug_exposure, …), the mapping type, and optional Phoebe recommendations - in a single call. It collapses URI lookup, Maps to traversal, semantic-search fallback, and domain/resource alignment into one request.

Python:

importomophubclient=omophub.OMOPHub()
# Single Coding -> standard concept + CDM target tableresult=client.fhir.resolve(
system="http://snomed.info/sct",
code="44054006",
resource_type="Condition",
)
print(result["resolution"]["standard_concept"]["concept_name"]) # "Type 2 diabetes mellitus"print(result["resolution"]["target_table"]) # "condition_occurrence"# Batch up to 100 codings in one callbatch=client.fhir.resolve_batch([
{"system": "http://snomed.info/sct", "code": "44054006"},
{"system": "http://loinc.org", "code": "2339-0"},
{"system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "E11.9"},
])
# CodeableConcept with OHDSI vocabulary preference rankingcc=client.fhir.resolve_codeable_concept(
coding=[
{"system": "http://snomed.info/sct", "code": "44054006"},
{"system": "http://hl7.org/fhir/sid/icd-10-cm", "code": "E11.9"},
],
resource_type="Condition",
)
# SNOMED wins over ICD-10 per OHDSI preference order

R:

library(omophub)
client<-OMOPHubClient$new()
tbl<-client$fhir$resolve_batch(
list(
list(system="http://snomed.info/sct", code="44054006"),
list(system="http://loinc.org", code="2339-0"),
list(system="http://hl7.org/fhir/sid/icd-10-cm", code="E11.9")
),
as_tibble=TRUE
)
# Returns a tibble ready for dplyr/tidyr with flat columns for# source/standard concept, target CDM table, status, and similarity score.

Node.js / TypeScript:

import{OMOPHub}from'@omophub/omophub-node';constclient=newOMOPHub();// Single Coding -> standard concept + CDM target tableconst{data: result}=awaitclient.fhir.resolve({system: 'http://snomed.info/sct',code: '44054006',resourceType: 'Condition',});console.log(result?.resolution.standard_concept.concept_name);// "Type 2 diabetes mellitus"console.log(result?.resolution.target_table);// "condition_occurrence"// Batch up to 100 codings in one callconst{data: batch}=awaitclient.fhir.resolveBatch([{system: 'http://snomed.info/sct',code: '44054006'},{system: 'http://loinc.org',code: '2339-0'},{system: 'http://hl7.org/fhir/sid/icd-10-cm',code: 'E11.9'},]);// CodeableConcept with OHDSI vocabulary preference ranking (up to 20 codings)const{data: cc}=awaitclient.fhir.resolveCodeableConcept([{system: 'http://snomed.info/sct',code: '44054006'},{system: 'http://hl7.org/fhir/sid/icd-10-cm',code: 'E11.9'},],{resourceType: 'Condition'});// SNOMED wins over ICD-10 per OHDSI preference order

The Node SDK accepts either the flat form ({ system, code }) or the nested FHIR form ({ coding: { system, code, ... } }) for resolve() - useful when piping Coding objects straight from FHIR client libraries.

Type interop (Python): The resolver accepts any Coding-like input via duck typing - plain dict, omophub's lightweight Coding TypedDict, or fhir.resources / fhirpy objects with no extra conversion. Neither library is a required dependency.

FHIR Integration guide → · FHIR → OMOP Standardization workflow →

Access all major medical terminologies synced with official ATHENA releases:

Clinical: SNOMED CT, ICD-10-CM, ICD-10-PCS, ICD-9-CM, Read Codes
Drugs: RxNorm, RxNorm Extension, NDC, ATC, dm+d
Labs: LOINC
Procedures: HCPCS, ICD-10-PCS
Other: MeSH, UCUM, Gender, Race, and 90+ more

Note: Licensed vocabularies (CPT, MedDRA) are not available due to license restrictions.

View versions supported →

• Concept Search - Full-text search with filters by vocabulary, domain, concept class
• Semantic Search - Natural language queries using neural embeddings (e.g., "high blood sugar" finds "Hyperglycemia")
• Similar Concepts - Find related concepts by semantic, lexical, or hybrid similarity
• Hierarchy Navigation - Traverse ancestors, descendants, and relationships
• Cross-Vocabulary Mappings - Map between ICD-10, SNOMED, RxNorm, and more
• Batch Operations - Process thousands of concepts in single requests (lexical and semantic)
• FHIR Terminology Service - Full FHIR R4/R4B/R5/R6 terminology operations ($lookup, $validate-code, $translate, $expand, $subsumes, $find-matches, $closure, $diff) for FHIR-native tooling (HAPI FHIR, EHRbase, fhirpy, fhircrackr)
• FHIR-to-OMOP Concept Resolver - One-call FHIR Coding → OMOP standard concept + CDM target table, with OHDSI vocabulary preference ranking and semantic-search fallback
• PHOEBE Support - Recommended concept sets for phenotyping

• < 50ms response time for most queries
• 99.9% uptime with global edge distribution
• Release sync with ATHENA vocabulary releases

• HIPAA & GDPR compliant architecture
• End-to-end encryption for all API traffic
• Immutable audit trails with 7-year retention
• SOC 2 Type II controls

• ETL Development - Look up concepts and validate mappings without database access
• FHIR-to-OMOP ETL - Resolve FHIR Coding / CodeableConcept values to OMOP standard concepts and CDM target tables in one call
• Phenotype Building - Explore hierarchies and build concept sets programmatically
• Clinical Research - Query vocabularies for cohort definitions
• FHIR Server Integration - Delegate terminology validation from HAPI FHIR, EHRbase, or any FHIR server via RemoteTerminologyServiceValidationSupport
• AI/LLM Integration - Ground medical AI models with structured vocabulary data; connect via MCP for agent-native access
• Data Quality - Validate codes and check standard concept mappings

OMOPHub is an independent service - we are not affiliated with OHDSI or ATHENA. We operate on dedicated infrastructure, separate from the official ATHENA vocabulary download service.

While we use the same publicly available OHDSI vocabulary data, OMOPHub is a third-party API built to provide convenient programmatic access without the overhead of local database management.

OMOPHub offers a free plan with 3,000 API calls per month and full API access.

• Issues & Bugs: Open an issue in the relevant SDK repository
• General Questions and Requests:Contact Us

We welcome contributions to our open-source SDKs:

1. Fork the repository
2. Create a feature branch
3. Submit a pull request

See individual SDK repositories for contribution guidelines.