OMOP Common Data Model: What It Is + 2026 Guide

OMOP CDM has moved from an academic harmonisation experiment to the de-facto research standard adopted by the European Health Data Space, the FDA Sentinel Initiative, the All of Us Research Program and most major biobanks. For platforms running federated analytics, mapping source data to OMOP v5.4 is now the precondition for cross-cohort discovery — and the slowest, most expensive step in the entire research pipeline. AI-automated harmonisation collapses that step from months to minutes.

Why OMOP matters now

The Observational Health Data Sciences and Informatics (OHDSI) organisation now coordinates more than 810 million patient records mapped to OMOP CDM across roughly 250 data partners in 33 countries. That scale only works because every site speaks the same vocabulary. When the European Health Data Space (EHDS) Regulation came into force in early 2026, it codified what OHDSI had built informally: secondary-use health data must be queryable through a common semantic layer, with outputs governed and inputs sovereign.

The May 2026 UK Biobank incident sharpened the architectural argument. Approved researchers walked derived data out via a centralised SaaS TRE’s normal workflow — exactly the failure mode that federated infrastructure prevents. In a federated Trusted Research Environment, data never leaves the source. Compute moves to the custodian; only aggregate, airlock-vetted results return. But federation only delivers cross-cohort insight if the cohorts share a model. Without OMOP, every federated query becomes a bespoke ETL project.

OMOP CDM v5.4 — what’s actually in the standard

The clinical event tables

OMOP CDM v5.4 organises data into person-centric clinical event tables: PERSON, OBSERVATION_PERIOD, VISIT_OCCURRENCE, CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE, MEASUREMENT, OBSERVATION, DEATH and NOTE. Every event row references the standardised vocabularies table, which holds more than 12 million concept identifiers drawn from SNOMED CT, RxNorm, LOINC, ICD-10-CM, ATC, HCPCS and roughly 130 other terminologies. The v5.4 release added the EPISODE and EPISODE_EVENT tables for oncology and chronic disease analytics, plus expanded METADATA structures that record source-to-concept mapping provenance — the audit trail regulators now expect.

The standardised vocabularies

The Athena vocabulary repository, maintained by OHDSI, is the canonical source of OMOP concepts. Each source code — a hospital’s local lab code, an ICD-10 diagnosis, a national drug identifier — must be mapped to a standard concept_id and, where the source is a non-standard vocabulary, to its corresponding standard concept via the CONCEPT_RELATIONSHIP table. This double-mapping is what makes federated analytics tractable: a phenotype defined in OHDSI’s ATLAS tool resolves to identical concept sets at every site, regardless of which source terminology each custodian recorded.

Why v5.4, not v6.0

OMOP CDM v6.0 has been in extended development since 2018 but has not been adopted as the production standard by OHDSI or the major regulatory partners. The OHDSI community formally recommends v5.4 for new deployments, and the FDA Sentinel, EHDS and EMA DARWIN EU networks have all standardised on v5.4. Lifebit’s OMOP pipeline targets v5.4 with optional v6.0 extension tables where partners request them.

The manual ETL bottleneck

Mapping a single cohort to OMOP CDM has historically taken between three and eighteen months of clinical-informatics work. The task decomposes into vocabulary mapping (every local code matched to an OHDSI standard concept), structural transformation (source schemas restructured into the OMOP event tables), unit and value harmonisation (LOINC-anchored units, normalised ranges) and quality assessment using the OHDSI Data Quality Dashboard. A 500,000-patient hospital cohort typically requires six to twelve full-time equivalents over a calendar quarter to reach production-grade mapping with documented provenance.

That cost is the reason most national biobanks remain partially harmonised. CanPath, Genomics England, NIH’s All of Us and Singapore Synapxe have each invested years in OMOP conformance work. For smaller registries and regional hospital networks the calculation is unforgiving: by the time a cohort is mapped, the research question has often shifted, the source schema has drifted and another team has begun the same work in parallel.

AI-automated OMOP harmonisation — five to fifteen minutes per cohort

The current Lifebit pipeline reduces source-to-OMOP mapping to between five and fifteen minutes per cohort for typical hospital and registry datasets, with human review concentrated on edge cases rather than line-by-line code mapping. The pipeline combines three components: a large language model that proposes source-to-standard concept candidates against the Athena vocabulary, a deterministic validator that enforces OMOP v5.4 schema constraints and unit conventions, and a confidence-scored review queue that surfaces only ambiguous mappings to the clinical informaticist on call.

Crucially, harmonisation runs at the data custodian. The mapping engine is deployed inside the federated TRE node, so source codes, patient identifiers and free-text notes never traverse a network boundary. Only the source-to-concept mapping table — concept identifiers, not patient rows — is exchanged with the federation registry, and only when the custodian approves publication. This is the architectural pattern reinforced by US patent 12,519,781: compute moves to data, governance stays with the custodian.

Manual ETL vs AI-automated OMOP mapping

Federated OMOP harmonisation is in production across several national-scale deployments. Genomics England’s 500,000 Genome Project uses OMOP-mapped phenotypes alongside genomic data to power its discovery cohort. CanPath, Canada’s pan-Canadian cohort connecting eight regional studies, deployed federated OMOP infrastructure in May 2026 to support cross-province epidemiological research without centralising provincial records. Singapore Synapxe’s national health data backbone uses OMOP CDM v5.4 as the common semantic layer for its federated analytics. Boehringer Ingelheim’s federated R&D network applies OMOP harmonisation across pharmaceutical partner cohorts to support real-world evidence generation under EMA’s DARWIN EU framework, and NIH NLM’s FedRAMP-authorised unified discovery service exposes OMOP-conformant biomedical data to approved researchers.

The Danish National Genome Center, Flatiron Health’s real-world oncology network and 23andMe’s federated research programme operate on the same architectural pattern. None of these custodians ship patient records to a central pool. Each holds its own OMOP-mapped instance behind its airlock, and federated queries return aggregate results that have passed automated disclosure control.

Practical next steps for a federated OMOP deployment

The OHDSI community publishes a well-trodden adoption path: install the OMOP CDM v5.4 schema, load the Athena vocabularies, run the OHDSI Data Quality Dashboard against a sample mapping, then iterate. For organisations evaluating federated rather than centralised infrastructure, three additional criteria matter. First, confirm that the harmonisation engine runs inside the custodian’s environment rather than requiring source data export — this is the difference between sovereignty and a managed-service relabelling. Second, require automated provenance: every source-to-concept mapping should carry a confidence score, a model version and a reviewer identity in the METADATA table. Third, validate that federated queries return only aggregate, airlock-vetted outputs, with row-level results staying inside the node.

Lifebit’s federated TRE platform delivers all three by default, deployed at the data custodian rather than as a SaaS tenancy. The Airlock Tower and Security Tower releases in April and May 2026 added automated disclosure control, output review workflows and tamper-evident audit logging on top of the OMOP harmonisation pipeline.

Frequently asked questions

Is OMOP CDM v5.4 the current production standard?

Yes. The Observational Health Data Sciences and Informatics (OHDSI) community formally recommends OMOP CDM v5.4 for new deployments. v6.0 remains in extended development and has not been adopted by FDA Sentinel, EHDS or EMA DARWIN EU.

How long does AI-automated OMOP mapping take compared with manual ETL?

The current Lifebit pipeline maps a typical hospital or registry cohort to OMOP CDM v5.4 in five to fifteen minutes, versus three to twelve months of manual clinical-informatics work. Human review concentrates on confidence-flagged edge cases rather than line-by-line code mapping.

Does federated OMOP harmonisation require sending source data to a central engine?

No. In a federated Trusted Research Environment, the mapping engine deploys inside the custodian’s node. Source codes, patient identifiers and free-text notes never traverse a network boundary — only the resulting concept-mapping table is shared, and only when the custodian approves publication.

Which vocabularies does the harmonisation engine cover?

Athena-aligned coverage includes SNOMED CT, RxNorm, LOINC, ICD-10-CM, ICD-9-CM, ATC, HCPCS, CPT-4, MedDRA, NDC and roughly 130 other source terminologies. Athena vocabulary refreshes are applied incrementally without re-running the full mapping.

Which deployments already run federated OMOP at national scale?

Genomics England’s 500,000 Genome Project, CanPath’s pan-Canadian cohort, Singapore Synapxe’s national health data backbone, Boehringer Ingelheim’s federated R&D network, NIH NLM’s unified discovery service and the Danish National Genome Center all run OMOP-mapped data behind federated airlocks.

How does OMOP relate to FHIR and other standards?

FHIR is an interoperability standard for moving health data between operational systems; OMOP CDM is a research model optimised for population analytics. Lifebit’s harmonisation pipeline ingests FHIR resources and emits OMOP CDM v5.4, so transactional and research workloads share a single mapping layer.

What audit trail does AI-automated mapping produce?

Every source-to-concept mapping is recorded in the OMOP METADATA and source-to-concept tables with a confidence score, model version, reviewer identity and timestamp. This satisfies the provenance requirements of the European Health Data Space Regulation and the FDA’s real-world evidence guidance.