commvita
Connected care platform
OMOP CDM · Research output

Delivering an OMOP data model for clinical research

The OMOP Common Data Model is the OHDSI community’s standard for observational research — one schema, one vocabulary, so a study written once runs against any conformant dataset. Because commvita’s record is already coded in OMOP’s own standard vocabularies (SNOMED CT, dm+d, ICD-10, OPCS-4, LOINC) and modelled on FHIR R4, an OMOP output is a tractable, mostly-mechanical build — not a research programme.

© 2026 Commvita Digital Health Solutions Ltd. All rights reserved.
Live vs demonstrated: Live — real, API-backed platform logic (wired end-to-end today) Demonstrated — representative control surface with seeded data / illustrative UI mock-up

Why an OMOP output is within reach

The expensive part of most OMOP ETLs is mapping messy source codes to standard concepts. commvita starts most of the way there — and the research governance is already built.

Already standards-coded

SNOMED · dm+d · ICD-10 · OPCS-4 · LOINC

The record is coded in the NHS Terminology Service vocabularies — and SNOMED CT, RxNorm/dm+d and LOINC are OMOP standard vocabularies, so much maps 1:1. The single costliest step of an OMOP ETL is largely done.

Where in commvita /terminology-service · /snomed-crosswalk.

FHIR R4 internal model

One canonical model

commvita’s internal model is FHIR R4 with a live integration layer (EPR Hub). There are well-trodden FHIR→OMOP ETL patterns to lean on, rather than reverse-engineering a bespoke schema.

Where in commvita /epr-hub · /data-fabric.

Research rails already built

SDE · federation · provenance

Clinical Studies (secure-data-environment, 3-tier anonymisation, immutable extract ledger), Federated Query, an OHDSI network node and open phenotypes (OMOP + AQL) already exist — the governance an OMOP output needs is in place.

Where in commvita /clinical-studies · /omop-cdm · /federated-query.
commvita / OMOP Transformation · vocabulary & data quality data custodian
Demonstration surface. Mapping completeness and DQD below are seeded — the console shows the workflow; a live ETL emitting populated CDM tables is the build described here.
Source vocabularyOMOP target domainStandard concept mappingCompleteness
SNOMED CT (UK)Condition / Observationsource_concept_id → concept_id● 94.7%
dm+dDrug exposure (RxNorm)dm+d → RxNorm● 92.0%
ICD-10ConditionICD-10 → SNOMED● 94.9%
LOINCMeasurementLOINC (standard)● 89.6%
OPCS-4ProcedureOPCS-4 → SNOMED● 85.5%
Run DQD (Data Quality Dashboard)Export CDM v5.4 · Parquet
Representative UI — mapping %/DQD seeded; the console demonstrates the transformation workflow

What “deliver OMOP” actually requires

Six steps turn the coded record into a conformant CDM. The genuine effort is in the vocabulary and the OMOP-only structures — not the commvita side.

1

Target the schema — OMOP CDM v5.4

person, observation_period, visit_occurrence, condition_occurrence, drug_exposure, procedure_occurrence, measurement, observation, death (+ the results schema for cohorts).

2

Load the OHDSI Standardized Vocabularies (Athena)

SNOMED, RxNorm/dm+d, LOINC, ICD-10→SNOMED maps — a few GB, with UMLS/licence terms accepted. This is what makes concept_id mapping real rather than illustrative.

3

Source→standard mapping with domain routing

Every source code to its standard concept and the correct CDM table by its OMOP domain — a SNOMED code can be a condition, an observation or a measurement. Non-standard→standard maps included.

4

ETL from the live record

Person from demographics, visits derived from encounters, drug_exposure from prescriptions (dm+d→RxNorm), measurement from observations (LOINC). FHIR→OMOP patterns apply.

5

Derive the OMOP-only structures

observation_period, visit_occurrence/visit_detail and drug_era/condition_era have no 1:1 source — they are computed. This is where most of the real work sits.

6

De-identify, then quality-gate

Date-shift / k-anonymise for disclosure (existing 3-tier anonymisation), then Achilles + DQD so the dataset is defensible for a researcher or an ethics committee.

Two ways to deliver it

File export per cohort

Parquet / CSV · the MVP

One file per CDM table for a defined cohort, issued through the existing extract ledger with a DQD summary. Simplest, fastest, and fits the secure-data-environment model already in place.

Where in commvita /clinical-studies · /omop-cdm.

Live CDM + ATLAS

Self-service · network studies

A live CDM database behind WebAPI / ATLAS for self-service cohort building and participation in OHDSI network studies — data stays at source, only aggregate results move.

Where in commvita /omop-cdm · OHDSI node · /federated-query.

Effort & difficulty — an honest split

DeliverableScopeEffortWhy
MVP OMOP exportReal ETL for person / observation_period / visit_occurrence / condition_occurrence / drug_exposure / measurement for a defined cohort → Parquet via the extract ledger + a DQD summary● ~2 weeksData already coded in standard vocabularies; SDE / extract-ledger governance already built
Production CDM v5.4Full table coverage, complete Athena vocabulary + correct domain routing, era derivation, DQD-passing, incremental refresh● ~2–3 monthsVocabulary completeness, domain routing and era logic are the genuine effort
ATLAS self-serviceLive CDM database + WebAPI / ATLAS, OHDSI network-study participation● incrementalMostly infrastructure + governance on top of a conformant CDM

Where it lives in commvita today

CapabilityModuleRouteStatus
Source coding (SNOMED/dm+d/ICD-10/OPCS/LOINC)NHS Terminology Service · SNOMED Crosswalk/terminology-service /snomed-crosswalk● Live
FHIR R4 model + integrationEPR Hub · Data Fabric/epr-hub /data-fabric● Live
OMOP transformation console (vocab map, DQD, network studies)OMOP Transformation/omop-cdm● Demonstrated
Federated analytics (data stays at source)Federated Query · OHDSI node/federated-query● Live
Cohort buildingCohort Discovery · Open Phenotypes/cohort-discovery /population-health● Live · ● node
Research governance (SDE, anonymisation, extract ledger)Clinical Studies/clinical-studies● Live
Populated CDM output (ETL → Parquet / live CDM)— build itemMVP scoped above● Not yet built
Honest state, and why it’s a strong one. Today the OMOP module is a demonstration control surface — the transformation workflow, mapping completeness and DQD are seeded, and there is no live ETL emitting populated CDM tables. What makes turning it real tractable is everything around it: the record is already coded in OMOP’s own standard vocabularies, the internal model is FHIR R4, and the research governance (SDE, anonymisation, extract ledger, federation) is built. An MVP export is a bounded, verifiable build — not a research programme. Non-SaMD analytics output; disclosure controlled by the secure-data-environment.
© 2026 Commvita Digital Health Solutions Ltd. All rights reserved. OHDSI OMOP CDM v5.4OHDSI Standardized Vocabularies (Athena) SNOMED CT UK · dm+d · LOINC · ICD-10 · OPCS-4FHIR R4 ICO anonymisation (k≥5) · SDE principlesNon-SaMD