Short answer: the OMOP Common Data Model (Observational Medical Outcomes Partnership CDM), maintained by the OHDSI community, is a relational schema into which health data from any source (EHRs, claims, registries) is converted, together with a set of standardised vocabularies that map every local code to a standard concept id. Once a database is in OMOP, the same analysis code (a cohort definition, an incidence estimate, a comparative effectiveness study) runs unchanged against hundreds of databases worldwide, and only aggregate results are shared. OMOP is the model for research; FHIR is the model for exchange and care; a published mapping connects them, and most research platforms now accept FHIR as a source for their OMOP ETL.
The model in one picture
The OMOP Common Data Model represents everything as an event about a person during an observation period, with the clinical domain deciding the table: condition_occurrence for diagnoses, drug_exposure for medications, measurement for laboratory results and vital signs, procedure_occurrence, visit_occurrence, observation for other facts, plus person, death, note, specimen, provider and cost tables. Version 5.4 is the most widely run.
Everything is an event about a person during an observation period, with the clinical domain deciding the table:
| Table | Holds | Standard vocabulary (typical) | FHIR source |
|---|---|---|---|
| person | One row per person: gender, birth date, race, ethnicity, location | Gender, Race, Ethnicity concepts | Patient |
| observation_period | Spans during which data about the person is expected | — | Derived from coverage and encounter dates |
| visit_occurrence (and visit_detail) | Encounters: inpatient, outpatient, emergency, with dates | Visit concepts | Encounter |
| condition_occurrence | Diagnoses and problems with start and end | SNOMED CT | Condition (ICD codes mapped to SNOMED) |
| drug_exposure | Prescriptions, dispensings, administrations with quantity and days supply | RxNorm (and RxNorm Extension for non-US drugs) | MedicationRequest, MedicationStatement, MedicationAdministration, MedicationDispense |
| procedure_occurrence | Procedures performed | SNOMED CT, CPT4, ICD10PCS | Procedure |
| measurement | Lab results and vital signs with value, unit, range | LOINC, with UCUM units | Observation (laboratory, vital signs) |
| observation | Other clinical facts: history, social, scores | SNOMED CT, LOINC | Observation (other), QuestionnaireResponse, FamilyMemberHistory |
| device_exposure | Devices used | SNOMED CT | DeviceUseStatement, Procedure |
| death | Date and cause | SNOMED CT | Patient.deceased, Observation |
| note, note_nlp | Clinical notes and NLP-extracted terms | — | DocumentReference, DiagnosticReport |
| specimen | Specimens | SNOMED CT | Specimen |
| provider, care_site, location | Clinicians, facilities, places | Specialty concepts | Practitioner, Organization, Location |
| cost, payer_plan_period | Costs and coverage | — | Coverage, Claim (where available) |
Version 5.4 is the one most sites run; version 6 exists but was not widely adopted, and development continues on the 5.x line.
The vocabularies
The OMOP standardised vocabularies, distributed by OHDSI through Athena, load more than a hundred code systems (SNOMED CT, LOINC, RxNorm, ICD-10, ATC and others) into the concept, concept_relationship and concept_ancestor tables. Every code becomes a concept_id, either standard or mapped to a standard one, so analyses are written once while the original source code is preserved.
The second half of OMOP is Athena, OHDSI's vocabulary distribution: more than a hundred code systems (SNOMED CT, LOINC, RxNorm, ICD-10 and national variants, ATC, CPT, Read, and many more) loaded into tables concept, concept_relationship, concept_ancestor. Each code becomes a concept_id; each concept is either standard (the one analyses use), non-standard (a source code that maps to a standard one) or a classification. The ETL stores both the source concept (what the record said: ICD-10 E11.9) and the standard concept (SNOMED 44054006), so analyses are written once against standard concepts while the original is preserved. The concept_ancestor table lets a cohort ask for "any type of diabetes" in one join. See SNOMED CT vs ICD-10 for why the standard for conditions is SNOMED CT.
The ETL
The OMOP ETL is the work of converting a source database into the common data model, supported by OHDSI tools: WhiteRabbit profiles the source, Rabbit-in-a-Hat documents the table mapping, Usagi maps local codes to standard concepts, the Data Quality Dashboard checks the result against thousands of rules, and ACHILLES characterises the finished database.
Converting a source into OMOP is the main work. OHDSI's tools help: WhiteRabbit scans the source and profiles it; Rabbit-in-a-Hat documents the mapping from source tables to CDM tables; Usagi helps map local codes to standard concepts; the Data Quality Dashboard checks the result against thousands of rules; ACHILLES characterises the database. Typical decisions: how visits are defined, how medication records become exposures with days' supply, how units are normalised, what to do with codes that have no standard mapping, and how to handle updates (full reload vs incremental).
Analysis across the network
Analysis across the OHDSI network works by writing a study once and running it everywhere: researchers define cohorts in ATLAS, run estimation and prediction with the HADES R packages, and package the analysis as code that each site executes locally on its own OMOP database, sharing only aggregate results. DARWIN EU and EHDEN follow this model.
ATLAS is the web tool where researchers build cohort definitions (people with condition X, exposed to drug Y, within time windows), characterise them and run estimation and prediction studies with the HADES R packages (CohortMethod, PatientLevelPrediction, SelfControlledCaseSeries). A network study packages the analysis as code; each site runs it locally on its OMOP database and shares aggregate results; nobody pools record-level data. This is how the OHDSI community produced large multinational studies quickly during the pandemic, and it is the model behind the EMA's DARWIN EU network and the EHDEN project, which converted more than a hundred European databases to OMOP.
FHIR to OMOP
FHIR maps to OMOP at two levels: resources to tables and elements to columns, with FHIR codes translated through OMOP's vocabularies to standard concepts. HL7's FHIR to OMOP implementation guide and OHDSI's FHIR working group publish the mappings; several platforms run the ETL directly from a FHIR server or Bulk Data export.
FHIR and OMOP answer different needs: FHIR carries one patient's record between systems with full detail; OMOP flattens many patients' records for statistics. The mapping is natural at the resource level (table above) and detailed at the element level: FHIR codes map through OMOP's vocabularies to standard concepts; Observation.valueQuantity becomes measurement value_as_number with unit_concept_id; Encounter.class becomes visit_concept_id. HL7's FHIR to OMOP implementation guide (through the Vulcan accelerator) and OHDSI's FHIR working group publish the mappings and reference implementations; several platforms run the ETL directly from a FHIR server or a Bulk Data export. Ambiguities remain where FHIR is richer (multiple codings, statuses, provenance) or where OMOP needs what FHIR lacks (days' supply, observation periods).
What OMOP is not
OMOP is not a format for care and not anonymous by itself: it drops narrative, flattens statuses and carries no consent, provenance or workflow, so FHIR remains the exchange format, and an OMOP database still holds record-level data that must be governed like any health database, usually with pseudonymised person ids inside a secure environment.
It is not a format for care: it drops the narrative, flattens statuses and does not carry consent, provenance or workflow. It is not anonymous by itself: an OMOP database holds record-level data and is governed like any health database, usually with pseudonymised person ids and in secure environments. See Secondary use of health data and De-identification of health data.
In Anpheros
Anpheros records are FHIR R4 with standard codes (LOINC, SNOMED CT, ATC, ICD-10), which is the input an OMOP ETL wants; with the person's consent for a research purpose, pseudonymised FHIR extracts can feed a research platform's ETL. Anpheros itself computes only aggregate population signals over groups of 20 or more and does not operate an OMOP database on identified data.
Related pages
- Secondary use of health data: the map
- SNOMED CT vs ICD-10
- De-identification of health data
- FHIR Bulk Data export explained
- Terminology servers explained
- RxNorm vs ATC
Sources
- OHDSI: OMOP Common Data Model
- OHDSI: The Book of OHDSI
- OHDSI Athena: standardised vocabularies
- OHDSI: ATLAS
- HL7 Vulcan: FHIR to OMOP implementation guide
- EHDEN project
- EMA: DARWIN EU
Frequently asked questions
Is OMOP a replacement for FHIR?
No. FHIR exchanges one patient's detailed record between systems; OMOP structures many records for statistical analysis. Research platforms take FHIR (or other sources) in and produce OMOP.
Which OMOP version should I use?
5.4 is the widely deployed version with full tool support; most new conversions target it. Version 6 introduced changes the community did not adopt broadly.
Why does OMOP map ICD codes to SNOMED CT?
So that analyses can be written once against a single, hierarchical standard vocabulary for conditions, regardless of whether the source used ICD-10, ICD-10-CM, ICD-9-CM or Read codes. The source code is kept alongside.
Is an OMOP database anonymous?
Not by itself. It holds record-level data, usually with pseudonymised identifiers and without direct identifiers, and must be protected and governed like any health database, typically inside a secure environment.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
