EHDS mandates secondary use of health data across the EU. OMOP CDM is the recommended semantic standard - and FHIR is how the data arrives. OMOPHub is the vocabulary layer between them.
The problem
Building an EHDS-ready pipeline means solving vocabulary access before anything else.
01 -
5 GB+ compressed. Millions of rows. Local PostgreSQL required. Every team does it separately. Every 6-months you do it again.
02 -
EHDS cross-border exchange and most EHR exports are FHIR-native. Your SPE analysis runs on OMOP CDM. In between sits every CodeableConcept that needs to be resolved to a standard OMOP concept with the right domain, the right target table, and the right standard flag — a job that breaks most ETL pipelines because it's three lookups and a Maps to traversal for every code.
03 -
Health Data Access Bodies (HDABs) have the power to issue fines when data isn't made available on time. Vocabulary infrastructure that blocks your ETL doesn't just slow you down - it creates direct regulatory exposure.
How OMOPHub helps
One REST API. 100+ OMOP vocabularies. No setup, no local database, no 6-months download cycle.
The OHDSI community defines a five-step process for EHDS-compliant studies: Exploration → Initiation → Implementation → Execution → Dissemination. OMOPHub is active in steps 1 and 3 - vocabulary validation before a study begins, and consistent concept resolution during analysis.
Query SNOMED CT, ICD-10, LOINC, RxNorm, and 100+ vocabularies via a single endpoint. Your ETL pipeline calls the API instead of querying a local database that may be months out of date.
openEHR archetypes are bound to SNOMED. OMOPHub returns the corresponding OMOP standard concept with domain, class, and relationship data - so your pipeline never guesses.
BioLORD-powered semantic search understands clinical language. Map free text or ambiguous terms to the correct OMOP concept, ready for EHDS-compliant secondary use analytics.
POST /v1/fhir/resolve takes a FHIR Coding - system URI, code, display - and returns the standard OMOP concept, the mapping type, and the CDM target table. URI resolution, source lookup, Maps to traversal, domain → table mapping, and semantic fallback in a single call. Batch up to 100 codings per request for bulk ETL.
curl -X POST https://api.omophub.com/v1/fhir/resolve \ -H "Authorization: Bearer $KEY" \ -d '{ "system": "http://snomed.info/sct", "code": "44054006", "resource_type": "Condition" }'# → concept_id: 201826 "Type 2 diabetes mellitus" # → target_table: condition_occurrence # → mapping_type: direct
fhir.omophub.com/fhir/{r4, r4b, r5, r6} implements $lookup, $validate-code, $translate, $expand, $subsumes, $closure, $find-matches, and the OMOPHub-custom $diff for vocabulary version comparison. Point your HAPI FHIR server, SMART on FHIR app, or CDS Hooks service at a real terminology service - no local ATHENA install, no version drift.
Used alongside the tools that power EHDS implementation
Primary use ↔ Secondary use
EHDS separates primary use - clinical care and cross-border exchange via EEHRxF and MyHealth@EU - from secondary use - research and policy in Secure Processing Environments. Primary use is FHIR. Secondary use recommends OMOP CDM. The gap between them is every clinical code that needs to be resolved from its source vocabulary to an OMOP standard concept with the correct domain and CDM target table. OMOPHub closes that gap with a composite resolver for ETL and a conformant FHIR terminology service for interoperability tools.
EHDS operational models
The EHDS framework supports two ways research gets done. OMOPHub is prerequisite infrastructure for both.
Data is uploaded to a Secure Processing Environment for analysis. This model works only if your data is correctly mapped to OMOP CDM - wrong vocabulary mappings may corrupt the entire study. OMOPHub validates your mappings before upload.
Validate source codes with $validate-code and translate them with $translate before upload - catch domain misalignment (e.g. an Observation resolving to the Drug domain) at ETL time, not after the study has run.
Data stays local; only aggregated results are shared back to the SPE. Consistent vocabulary mappings across sites are required for results to be comparable. OMOPHub provides that consistency via API.
Every site calls the same fhir.omophub.com endpoint on the same OMOP vocabulary release. The X-Vocab-Release response header makes the version used at each site auditable - federated results stay comparable.
Both models require OMOP CDM semantic interoperability. Vocabulary errors discovered post-submission mean re-running the study.
Built for European healthcare
Healthcare data pipelines run on schedules. Vocabulary lookups need to work when your ETL runs at 2 AM.
OMOPHub serves vocabulary metadata only - no patient data flows through our infrastructure. GDPR Article 5 considerations are built into the architecture.
Vocabularies are updated quarterly in line with OHDSI ATHENA releases. No manual downloads. Your pipeline uses the same version as the OHDSI community.
Built on Google Cloud Run with Redis caching. Response times under 50ms for concept lookups. Uptime SLAs available on Pro, Scale and Enterprise plans.
API key scoping, usage logs, and per-key rate limits. Scale and Enterprise plans include access audit logs. Ready for EHDS data governance requirements.
Multi-version FHIR Terminology Service from a single endpoint. R4 for current production, R5 for new builds, R6 for conformance testing. Version-pinned OMOP vocabulary releases via the X-Vocab-Release header keep regulated pipelines reproducible across vocabulary updates.
Python, R, and MCP clients are open source on GitHub. Security and compliance teams can audit exactly what gets sent to the API - no black-box behavior, no surprises in your vendor review.
Get started
Used by EHDS implementation teams across Europe. Free tier available. No credit card.