Base URLs
OMOPHub exposes two surfaces, both served over HTTPS: REST APIr4b, r5, and r6 available via path prefix)
Authentication
All requests require a Bearer token in theAuthorization header:
Get your API key from the OMOPHub Dashboard.
client_credentials via POST /oauth2/token for Spring Security OAuth2 clients - see the FHIR Terminology Service overview for details.
Core Capabilities
Search & Discovery- Full-text search across 100+ medical vocabularies (SNOMED CT, ICD-10, LOINC, RxNorm, NDC, HCPCS, ATC, and more)
- Semantic search powered by neural embeddings - match by clinical meaning, not just keywords
- Autocomplete, fuzzy matching, phonetic search, and faceted filtering
- Standard FHIR operations:
$lookup,$validate-code,$translate,$expand,$subsumes,$find-matches,$closure - OMOP-specific operation:
$difffor comparing concepts between vocabulary releases - CodeSystem and ValueSet search-type queries for client discovery (HAPI, EHRbase)
- FHIR batch Bundles, per-vocabulary CodeSystem stubs, and R4 / R4B / R5 / R6 wire formats on the same endpoint
- One-call resolution: FHIR
CodingorCodeableConcept→ OMOP standard concept + domain + CDM target table Maps totraversal for non-standard codes, semantic fallback for display-text-only inputs- Single, batch (up to 100 codings), and
CodeableConceptvariants with OHDSI vocabulary preference ranking
- Cross-vocabulary mapping between any OMOP vocabulary pair
- Mapping quality scores and coverage analysis
- Batch mapping: up to 100 concepts per request
- Traverse ancestor / descendant hierarchies with configurable depth and relationship-type filters
- Explore non-hierarchical relationships (
Maps to,Has ingredient,RxNorm has dose form, etc.) - Phoebe-powered concept recommendations for phenotype development
- Batch concept retrieval, relationship queries, hierarchy queries, and mappings (up to 100 per request)
- Bulk search and bulk semantic search for large ETL workloads
- Each batch / bulk request counts as one API call against your quota
- Synced with OHDSI ATHENA releases
- Version-specific API routing via
X-Vocab-Releaseheader orvocab_releasequery parameter
API Structure
RESTful design- Resource-based endpoints (
/concepts,/vocabularies,/search,/mappings,/fhir/resolve) - Standard HTTP methods (GET, POST)
- Consistent JSON response envelope
snake_casefor all fields (concept_id,vocabulary_id,domain_id,target_concept_code)- Consistent naming across REST API, SDK responses, and FHIR property codes
- Page-based:
page(1-indexed) andpage_size(default 20, max 1000) query parameters - Response
meta.paginationincludestotal_items,total_pages,page,page_size,has_next,has_previous
API Categories
Search
Text search, semantic search, autocomplete, facets, bulk search, and similarity.
Concepts
Look up by ID or code, get recommendations, traverse relationships, batch retrieval.
Concept Hierarchy
Ancestors, descendants, and full hierarchy trees with relationship-type filters.
Relationships
Relationship types and per-concept relationship queries.
Mappings
Cross-vocabulary mapping, batch mapping, coverage analysis, and validation.
Vocabularies
List, search, and inspect vocabulary metadata, statistics, and releases.
Domains & Classifications
OMOP domains, concept classes, and per-domain statistics.
FHIR Resolver
Coding and CodeableConcept → OMOP standard concept, CDM target table, in one call.FHIR Terminology Service
$lookup, $translate, $validate-code, $expand, $subsumes, and the full spec-conformant surface.Quick Start Examples
Search for Concepts
Semantic Search
Match by clinical meaning, not just keyword overlap. Uses neural embeddings.Get Concept Details
Map Between Vocabularies
Resolve a FHIR Code to OMOP
One call: FHIR system URI + code in, OMOP standard concept + CDM target table out.FHIR $lookup
Spec-conformant FHIR operation for clients that speak FHIR natively (HAPI, EHRbase, Firely).
Response Format
All REST API responses follow a consistent envelope:Parameters, Bundle, OperationOutcome, CodeSystem, ValueSet, ConceptMap) with Content-Type: application/fhir+json. XML is served via content negotiation - see the FHIR Terminology Service content type for the negotiation rules and XML support matrix.
Response Codes
OMOPHub uses standard HTTP status codes to signal success or failure.2xx codes indicate success, 4xx are client errors, 5xx are server errors.
| Status | Description |
|---|---|
200 | Request succeeded. |
400 | Invalid parameters - check request body or query string. |
401 | Missing or invalid API key. |
403 | Forbidden - insufficient permissions, or restricted vocabulary. |
404 | Resource not found. |
429 | Rate limit exceeded - check the Retry-After header. |
5xx | Server error - retry with exponential backoff. |
{"success": false, "error": {...}} envelope. FHIR Terminology Service errors on /fhir/* paths return a FHIR OperationOutcome resource instead.
See Errors for the complete error code reference and troubleshooting guide.
Rate Limits
Default free-tier limit: 2 requests per second, monthly call quota per plan. Batch and bulk endpoints process up to 100 items per request and count as one API call against your quota. Every response includesX-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers.
See Rate Limits for plan-specific limits and header semantics.
Next Steps
FHIR Terminology Service
$lookup, $translate, $validate-code, $expand, $subsumes, and OMOP-specific operations.FHIR Integration
End-to-end workflow from FHIR-coded data to OMOP CDM placement.
Search Endpoints
Text search, semantic search, autocomplete, and facets.
AI & MCP Server
Connect Claude, Cursor, or VS Code to medical vocabularies via the MCP Server.
Python SDK
Typed responses, async support, batch helpers.
R SDK
R6 client for vocabulary access in R workflows.
Errors
Complete error code reference and troubleshooting.
Rate Limits
Per-plan limits, batch metering, and the rate-limit response headers.