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 instead of 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’re 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● BuiltData 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◎ Not builtVocabulary 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 → CSV / Parquet)/clinical-studiescohort → populated CDM v5.4 tables + DQD summary, via the extract ledger● Live
Honest state. The transformation console’s mapping-completeness and DQD figures are seeded. The MVP export is built: for a defined cohort the platform emits populated CDM v5.4 tables (person, observation period, visits, conditions, drug exposures, measurements) as CSV, and Parquet where the runtime supports it, with a data-quality summary and the unmapped codes reported not dropped. Nothing leaves without a data sharing agreement and the disclosure gate. The production CDM — full table coverage, complete vocabularies, era derivation and incremental refresh — isn’t built, and is listed as a gap. 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