OMOP CDM and Federated TREs: Standardise, Then Federate

Combining the Observational Medical Outcomes Partnership Common Data Model (OMOP CDM) with a federated Trusted Research Environment (TRE) solves two problems that neither solves alone: OMOP makes data from different institutions mean the same thing, and federation lets researchers analyse it without any institution surrendering custody. Standardise each site’s data to OMOP CDM in place, deploy the TRE’s compute at each site, and dispatch the same analysis everywhere — each site returns aggregate results, and patient-level data never moves. This is the working pattern behind the largest multi-site observational studies in health research today.

Why this combination matters now

Two forces are converging on research infrastructure teams. The first is scientific: single-site studies are underpowered for the questions that matter — rare diseases, drug safety signals, subgroup effects — and reviewers increasingly expect multi-site replication. The Observational Health Data Sciences and Informatics (OHDSI) community has demonstrated network studies running identical analyses across dozens of databases on hundreds of millions of patient records, which is only possible because every participating database speaks OMOP. The second force is regulatory: the European Health Data Space (EHDS) requires that secondary-use health data be analysed within secure processing environments, and national custodians are unwilling to export patient-level records at all. The May 2026 UK Biobank incident — approved researchers walking data out of a centralised environment through its normal workflow — hardened that position. Research networks therefore need an architecture where analysis is common but data movement is zero. That architecture is OMOP for the semantics, federation for the topology — and the organisations building it now are not choosing between standardisation and federation but sequencing them, because each multiplies the value of the other.

What each half contributes

OMOP CDM: making heterogeneous data comparable

The OMOP Common Data Model, maintained by the OHDSI community and currently at version 5.4, defines a standard relational schema (person, condition_occurrence, drug_exposure, measurement, and related tables) plus standardised vocabularies that map local codes — ICD-10, Read, local lab codes — onto common concepts drawn from SNOMED CT, RxNorm, and LOINC. Once two hospitals have transformed their records into OMOP, a query written against the model runs identically against both, and “type 2 diabetes” or “metformin exposure” resolves to the same concept set in each. This is data harmonisation in its most operational form: not a one-off cleaning exercise, but a persistent, queryable standard. The transformation itself — extract, transform, load (ETL) into OMOP with vocabulary mapping and quality checks — is the hard part, which is why data harmonisation has become a discipline and a product category of its own, and why Lifebit invests in AI-assisted mapping to compress ETL timelines from months to weeks.

The federated TRE: making comparable data reachable

A federated Trusted Research Environment inverts the usual data flow. Instead of pooling OMOP-formatted data into one warehouse, the TRE deploys secure compute at each custodian — inside the hospital’s or biobank’s own infrastructure — and sends the analysis to the data. Researchers work in a single workspace, define one study, and the platform executes it at every participating site. Only aggregate results (counts, effect estimates, model coefficients) return, and every output passes an automated airlock that enforces disclosure control before release. The custodian keeps full control: data never leaves the source, and the site can inspect and approve exactly what its node returns. The distinction between this query-dispatch pattern and federated model training is worth understanding when designing studies — see federated analytics versus federated learning for where each applies.

Why each half fails without the other

Federation without standardisation produces fast access to incomparable data: the same query returns systematically different answers at each site because “hypertension” is encoded three different ways. The failure is silent — results arrive, they are simply wrong to pool. Standardisation without federation produces comparable data nobody will share: a network of beautifully harmonised OMOP databases whose custodians decline every data-transfer agreement, or take eighteen months to sign one. Only the combination delivers analyses that are both semantically valid and institutionally feasible. Data harmonisation defines the common language; federation defines the common workflow.

Three architectures compared

The pattern in the wild

The OHDSI network is the reference demonstration that shared semantics enable distributed science: its published network studies, including large-scale hypertension and COVID-19 analyses, ran the same protocol against OMOP databases across continents without pooling records. In Europe, the European Health Data and Evidence Network (EHDEN) project funded the harmonisation of more than a hundred data sources to OMOP precisely so they could participate in federated studies. National programmes are following the same route: Genomics England provides researchers a secure environment where analysis comes to the data rather than the reverse, and Lifebit’s federated TRE deployments apply the same principle for national-scale genomics and health-data programmes — each site harmonised to a common model, each site analysed in place. The lesson across all of them is consistent: standardisation determines whether a network’s answers are scientifically poolable; federation determines whether the network can exist at all.

Implementation guide: sequencing the work

Teams combining OMOP and federation should sequence the work in five steps. First, profile each source — inventory tables, coding systems, and completeness before promising any study timelines. Second, run the ETL to OMOP CDM v5.4 locally at each site, keeping the source-to-concept mappings under version control; the mapping decisions are scientific decisions and must be reviewable. Third, measure harmonisation quality with the OHDSI Data Quality Dashboard’s checks (conformance, completeness, plausibility) and publish each site’s results to the network — a federated study is only as strong as its weakest node’s data quality. Fourth, deploy the federated TRE nodes inside each custodian’s infrastructure and verify the airlock rules with a test study before any real protocol runs. Fifth, standardise the study workflow itself: shared concept-set definitions, a common analysis package executed identically everywhere, and pre-registered aggregation rules, so that site-level differences in results reflect populations rather than pipelines.

The tooling for most of this already exists in the open. The OHDSI ecosystem provides ATLAS for defining cohorts and concept sets against any OMOP database, and the HADES family of R packages for standardised estimation and prediction methods, so a network does not need to invent its analysis layer — it needs to decide how that layer is dispatched and governed. This is the division of labour in a well-designed federated OMOP network: the community standard defines what an analysis means, and the federated TRE defines where it runs, who approved it, and what is allowed back out. Keeping that separation clean also future-proofs the network — when OMOP CDM moves to its next version, or when a study needs a method the platform has never seen, the change lands in one layer without disturbing the other. Networks that entangle the two, hard-coding analysis logic into their infrastructure or governance rules into their study code, pay for it at every upgrade.

Common pitfalls

Four mistakes recur. Treating ETL as a one-off project rather than a maintained pipeline — source systems change, vocabularies update twice a year, and an unmaintained OMOP instance drifts out of comparability within eighteen months. Harmonising centrally “just for convenience” — copying raw data to a central team for transformation quietly recreates the centralised architecture the network was built to avoid; the ETL should run where the data lives. Ignoring vocabulary-version skew — two sites on different vocabulary releases can classify the same drug differently, so pin and synchronise vocabulary versions across the network. And under-scoping the airlock — disclosure rules written for tabular outputs need extending before sites return model files or genomic summary statistics, both of which can carry more information than they appear to. A fifth, subtler mistake is organisational: assigning harmonisation to a data engineering team and federation to an infrastructure team with no shared roadmap. The two workstreams share failure modes — a vocabulary update that breaks a concept set is indistinguishable, from a researcher’s seat, from a node that silently dropped out of a study — so they need shared monitoring and a single owner for network data quality.

What to do next

If you operate or are designing a multi-site research network, run a two-part readiness assessment. On the semantics side: what fraction of each source maps cleanly to OMOP standard concepts today, and who owns the mapping backlog? On the topology side: which custodians would join a network where participation requires no patient-level data transfer, and what would each need to host a compute node? In most networks, the second list is far longer than the list of custodians willing to sign transfer agreements — which is the strategic case for the combined architecture. Data harmonisation makes the network scientifically meaningful; the federated TRE makes it institutionally possible.

Frequently asked questions

What is the OMOP Common Data Model?

OMOP CDM is an open community standard, maintained by OHDSI, that defines a common relational schema and standardised vocabularies for observational health data. Data transformed into OMOP can be queried with the same analysis code regardless of which institution or country it came from.

What is a federated TRE?

A federated Trusted Research Environment is a secure analysis platform deployed at each data custodian rather than in one central location. Researchers dispatch analyses to every site from a single workspace; only aggregate, disclosure-checked results return, and patient-level data never moves.

Why combine OMOP with federation instead of building a central OMOP warehouse?

A central warehouse requires every custodian to transfer patient-level data, which many legally cannot and most will not. Federation removes the transfer requirement while OMOP preserves comparability, so the network achieves warehouse-grade analytics without warehouse-grade legal and sovereignty risk.

Does OMOP harmonisation have to happen before federation?

The ETL to OMOP should run locally at each site, but the two workstreams can proceed in parallel: sites can deploy TRE nodes and validate connectivity while their harmonisation pipelines mature. A site joins live studies once its data quality checks pass.

How do you verify data quality across a federated OMOP network?

Run the OHDSI Data Quality Dashboard checks at every site and share the results across the network. Because the checks themselves are standardised, quality becomes comparable in the same way the data is — sites can be benchmarked and study protocols can set minimum thresholds.

Can federated OMOP networks support AI model training?

Yes. The same topology that dispatches statistical analyses can dispatch model training, with each site computing updates locally and only parameters being aggregated — federated learning rather than federated analytics. OMOP ensures the features feeding the model mean the same thing at every site.