Schéma OMOP v5.4

Table Description

This table serves as the central identity management for all Persons in the database. It contains records that uniquely identify each person or patient, and some demographic information.

Columns

User Guide

All records in this table are independent Persons.

ETL Conventions

All Persons in a database needs one record in this table, unless they fail data quality requirements specified in the ETL. Persons with no Events should have a record nonetheless. If more than one data source contributes Events to the database, Persons must be reconciled, if possible, across the sources to create one single record per Person. The content of the BIRTH_DATETIME must be equivalent to the content of BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.

For detailed conventions, refer to the THEMIS repository.

Table Description

The OBSERVATION_PERIOD table defines spans of time during which clinical events are expected to be recorded for a person. It establishes the period when events indicate actual occurrences, and their absence suggests non-occurrence.

Columns

User Guide

Each person may have multiple non-overlapping OBSERVATION_PERIOD records. Events can exist outside these periods but cannot be assumed absent. Incidence and prevalence calculations should only use active observation periods. When defining cohorts, events outside these spans can inform inclusion criteria, though completeness isn't guaranteed. Short periods (single days) can distort rate calculations, so applying minimum observation time requirements is recommended.

ETL Conventions

Every person requires at least one OBSERVATION_PERIOD representing intervals with high clinical event capture. These may derive from enrollment periods (insurance data) or require inference (EHR systems). The start typically reflects the earliest clinical event, and the end reflects either the latest event or database cutoff. Single-event periods are valid. Overlapping or adjacent periods must be merged into one.

Table Description

The DEATH table contains the clinical event documenting how and when a Person dies. A Person can have at most one record in this table if evidence of death exists in the source data.

User Guide

Living persons should not have a record in this table. Each person can have at most one death record. If multiple death records exist in source data, choose the most reliable one based on data quality assessment.

ETL Conventions

If death information comes from multiple sources (e.g., EHR and claims), reconcile them to create a single death record. The death_type_concept_id should reflect the most reliable source. Cause of death should be mapped to a Standard Concept in the Condition domain when available.

Table Description

The VISIT_OCCURRENCE table contains events representing periods when persons engage with the healthcare system. These encounters are configured by specific circumstances including patient location (institutional vs. remote), provider availability, and stay duration.

Columns

User Guide

Visit types are organized hierarchically using standardized concepts from the Visit Domain. Common visit configurations include: Inpatient Visit (hospital admission with bed stay exceeding one day), Emergency Room Visit (same-day emergency department care), Outpatient Visit (same-day ambulatory care without bed), Home Visit (provider delivers service at patient location), Telehealth Visit (remote patient-provider interaction), Pharmacy/Laboratory Visits (specialized same-day visits), Case Management Visit (administrative interaction without providers). Visit duration, or 'length of stay', is defined as VISIT_END_DATE - VISIT_START_DATE.

ETL Conventions

Visit concepts derive from healthcare coding systems (CPT, Place of Service). When unavailable, visits must be inferred through defined ETL assumptions. Visits may be adjacent but cannot overlap on non-boundary dates. Multi-day visits cannot share days except at start/end points.

Table Description

The VISIT_DETAIL table represents granular details of parent VISIT_OCCURRENCE records. It maintains a 1:n relationship where each VISIT_OCCURRENCE may have zero or more associated VISIT_DETAIL records. Examples include unit transfers during hospital stays or individual claim lines within insurance claims.

Columns

User Guide

VISIT_DETAIL records must have their associated VISIT_OCCURRENCE_ID specified. Each VISIT_DETAIL_CONCEPT_ID should be a descendant of the parent visit's VISIT_CONCEPT_ID, maintaining hierarchical consistency within the visit domain structure.

ETL Conventions

Population of VISIT_DETAIL is optional but recommended when source data requires roll-up logic to create unified VISIT_OCCURRENCE records. In EHR systems, multiple provider interactions may be consolidated into a single visit using VISIT_DETAIL to preserve granular encounter information.

Table Description

This table documents clinical events indicating a disease or medical condition. Records capture diagnoses, signs, or symptoms either observed by healthcare providers or reported by patients.

Columns

User Guide

Conditions are organized in a hierarchical system within the Condition domain. Record all source conditions without applying analytical filters. Rule-out diagnoses should be excluded. Family history and past medical events belong in the OBSERVATION table.

ETL Conventions

All source codes mapping to standard Condition domain concepts must be recorded in this table. Duplicate conditions within the same encounter require ETL logic to determine whether to consolidate or maintain separate records.

Table Description

The DRUG_EXPOSURE table captures records documenting a person's exposure to a medication or biochemical substance introduced into the body. Drugs encompass prescription and over-the-counter medicines, vaccines, and biologic therapies.

Columns

User Guide

Records in this table indicate exposure to drugs. The table documents prescriptions written, prescriptions dispensed, and drugs administered by providers, with the DRUG_TYPE_CONCEPT_ID differentiating these types.

ETL Conventions

Quantity and dose information arrives in varied formats; ETL should capture as much detail as possible. Multiple records on the same day for identical drugs should not be deduplicated without strong evidence of true duplication. Special attention is required for prescription refills.

Table Description

The PROCEDURE_OCCURRENCE table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.

Columns

User Guide

Lab tests are distinct from procedures. Measurements represent observed results with expected amounts and units, whereas procedures are actions. Phlebotomy, though technically a procedure, is rarely captured separately since it's typically associated with lab work.

ETL Conventions

When handling duplicate records, the ETL must determine whether to consolidate them into a single record or maintain them separately. Source codes mapped to Standard Concepts in the Procedure Domain must be recorded in this table.

Table Description

The Device domain captures information regarding a person's exposure to a foreign physical object or instrument used for diagnostic or therapeutic purposes. This includes implantable objects like pacemakers and stents, medical equipment and supplies, instruments used in medical procedures, and materials used in clinical care.

Columns

User Guide

The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.

ETL Conventions

Source codes and source text fields that map to Standard Concepts within the Device Domain must be recorded in this table.

Table Description

The MEASUREMENT table records structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a person or their sample. This includes laboratory tests, vital signs, and quantitative pathology findings.

Columns

User Guide

Measurements are predominantly lab tests with a few exceptions, like blood pressure or function tests. Results are given in the form of a value and unit combination. When investigating measurements, look for operator_concept_ids (<, >, etc.).

ETL Conventions

Only source values mapping to Measurement domain concepts belong in this table. While measurements always have results, VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID fields are optional since source data often lacks result information.

Table Description

The OBSERVATION table captures clinical facts about a Person obtained through examination, questioning, or procedures. It records data that cannot be represented elsewhere, such as social facts, lifestyle choices, and medical history.

Columns

User Guide

Observations differ from Measurements because they don't require standardized testing to generate clinical facts. The table typically records when observations were obtained. Examples include medical history, family history, treatment needs, social circumstances, and healthcare utilization patterns.

ETL Conventions

Records mapping to domains other than Condition, Procedure, Drug, Specimen, Measurement, or Device belong here. Observations function as attribute-value pairs with the Observation Concept as the attribute and clinical facts as values. Values can be Concepts, numerical, or text.

Table Description

The NOTE table captures unstructured information recorded by a provider about a patient in free text notes.

User Guide

The NOTE table captures unstructured information recorded by a provider about a patient in free text notes. Notes should be organized using the HL7/LOINC CDO dimensions.

ETL Conventions

Apply the five-dimension CDO structure for note classification. Only two dimensions are required per standards: the note_class_concept_id and note_type_concept_id.

Table Description

The NOTE_NLP table encodes all output of NLP (Natural Language Processing) applied to clinical notes. Each row represents an extracted term from the NLP processing.

User Guide

The NOTE_NLP table stores the results of natural language processing pipelines. Each record represents a medical concept extracted from a clinical note, with its context (snippet), position in the text, and mapping to OMOP standard vocabularies.

ETL Conventions

The term_exists and term_temporal fields are essential for interpretation: a term may be mentioned as absent ("no diabetes") or historical ("history of pneumonia"). The nlp_system should document the tool used to enable reproducibility and quality assessment of extractions.

Table Description

The EPISODE table aggregates lower-level clinical events (CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases, outcomes and treatments.

User Guide

The EPISODE table is particularly useful for oncology where disease and treatment episodes are tracked. A patient may have multiple episodes for different cancers or different treatment lines. Episodes can be hierarchically organized via episode_parent_id. Examples include cancer episodes with diagnosis, treatment phases, and resolution.

ETL Conventions

Write only episodes that can be easily derived from source data. The episode_concept_id defines the nature of the episode (Disease Episode for illness, Treatment Episode for treatment). The episode_object_concept_id specifies what the episode is about (e.g., the type of cancer). Individual events are linked via the EPISODE_EVENT table.

Table Description

The EPISODE_EVENT table connects qualifying clinical events (CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry.

User Guide

EPISODE_EVENT is a linking table that associates clinical events (conditions, procedures, drugs) to their respective episodes. This is used instead of FACT_RELATIONSHIP for linking events to episodes. For example, for a cancer episode, you can link the initial diagnosis, various chemotherapy treatments, and follow-up assessments.

ETL Conventions

Some episodes may have no linked events. The episode_event_field_concept_id indicates which table the event_id comes from. The concepts used correspond to CDM field identifiers (e.g., concept for condition_occurrence_id, drug_exposure_id, etc.). The same event can be associated with multiple episodes if clinically relevant.

Table Description

The SPECIMEN table contains records identifying biological samples from persons.

User Guide

Code anatomic sites at most specific granularity. The SPECIMEN table documents biological samples independent of any analyses performed. Results of analyses on these specimens are in MEASUREMENT. This table is particularly important for biobanks and research where sample traceability is essential.

ETL Conventions

Enable higher-level classification via Standardized Vocabularies. A single physical specimen may generate multiple MEASUREMENT records if multiple analyses are performed. The anatomic_site_concept_id uses SNOMED concepts for localization.

Table Description

The FACT_RELATIONSHIP table contains records about the relationships between facts stored as records in any table of the CDM. Relationships can be defined between facts from the same domain, or different domains.

User Guide

All relationships are directional, and each relationship is represented twice symmetrically within the table. For example, two persons who are related have two records of relationships between them.

ETL Conventions

The domain_concept_id uses domain concepts (Drug, Condition, Measurement, etc.). For symmetric relationships, create two records (A to B and B to A). The relationship_concept_id defines the semantics of the relationship.

Table Description

The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites.

User Guide

The current LOCATION table is US-centric. The state field is a two-character abbreviation of the US state code, and the ZIP code is stored as 3, 5, or 9 digits. These fields can be adapted for international use.

ETL Conventions

For privacy protection, patient addresses should be generalized (e.g., ZIP code only, no complete address). Latitude/longitude coordinates may be offset or rounded. Care site locations can be more precise.

Table Description

The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).

User Guide

A Care Site is a unique combination of location information and place of service nature. Care sites can include hierarchical relationships, such as a hospital having multiple units (emergency, ICU, cardiology).

ETL Conventions

The granularity of care_site depends on source data and analytical needs. You can represent the entire hospital or go down to the department level. The place_of_service_concept_id uses CMS Place of Service concepts or European equivalents.

Table Description

The PROVIDER table contains a list of uniquely identified healthcare providers. These are individual providers (physicians, nurses, pharmacists, etc.) involved in patient care.

User Guide

The table contains individual providers only. Pooled records are used when the source lacks individual provider identification. Clinical events can reference the provider_id to identify who performed the act or prescribed the treatment.

ETL Conventions

NPI and DEA are US identifiers; use equivalent national identifiers for other countries (RPPS in France, for example). The provider_name can be pseudonymized for data protection. The same provider can work at multiple care_sites.

Table Description

The COST table captures records containing the cost of any medical event recorded in one of the clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, etc.

User Guide

The COST table represents both receivables (amounts charged) and payments. Typically, there is one record per payer response. Each cost is linked to a specific clinical event via cost_event_id and cost_domain_id.

ETL Conventions

Amounts are in monetary units defined by currency_concept_id. Detailed payment fields depend on the local healthcare system structure. All amounts are optional depending on available data.

Table Description

The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer.

User Guide

A Person can have multiple overlapping payer plan periods representing different coverage types (e.g., primary and supplemental insurance). This information is crucial for healthcare access analysis and population tracking.

ETL Conventions

Create separate periods for each coverage change. Periods should not overlap for the same type of coverage. Dates should be accurate to the day. In some countries, distinguish between mandatory and supplemental insurance.

Table Description

The CONCEPT table is a fundamental building block of the Standardized Vocabularies. It contains records uniquely identifying fundamental units of meaning for expressing clinical information.

User Guide

Standard Concepts (standard_concept = 'S') can be used as normative expressions within the CDM and analytics. Non-standard concepts serve as sources for mapping. Use CONCEPT_RELATIONSHIP to find mappings.

ETL Conventions

This table is provided by OHDSI and should not be modified. During ETL, map source codes to standard concept_ids. Always verify that the concept is valid (valid_end_date in the future, invalid_reason NULL) before using it.

Table Description

The VOCABULARY table includes a list of the Vocabularies integrated from various sources or created de novo by the OMOP community. It provides explicit information about vocabulary versions and source references.

User Guide

VOCABULARY lists available terminologies and their versions. Most commonly used vocabularies are: SNOMED (conditions, procedures), RxNorm/RxNorm Extension (drugs), LOINC (lab measurements), ICD10CM/ICD10 (diagnostic classifications).

ETL Conventions

This table is provided by OHDSI via Athena. The vocabulary version is important for analysis reproducibility. Custom vocabularies can be added with a vocabulary_id starting with a high number (>2000000000).

Table Description

The DOMAIN table includes a list of OMOP-defined Domains to which concepts can belong. Domains represent clinical definitions that assign matching concepts to standardized CDM fields.

User Guide

Main domains are: Condition (diagnoses), Drug (medications), Procedure (procedures), Measurement (measurements/lab tests), Observation (observations), Device (devices), Specimen (specimens). A concept's domain determines the destination table during ETL.

ETL Conventions

This table is provided by OHDSI. During ETL, check the concept's domain_id to know which table to insert the record into. The same source code may map to concepts in different domains depending on context.

Table Description

The CONCEPT_CLASS table contains semantic categories referencing the structure of each vocabulary. It represents horizontal or vertical levels of vocabulary structure.

User Guide

Classes vary by vocabulary. For SNOMED: Clinical Finding, Procedure, etc. For RxNorm: Ingredient, Clinical Drug, Branded Drug, etc. For LOINC: Lab Test, Clinical Observation, etc. The class helps filter concepts during searches.

ETL Conventions

Table provided by OHDSI. Useful for understanding concept hierarchy within a vocabulary. For example, in RxNorm, Ingredients are active substances, Clinical Drugs combine ingredient + dosage + form.

Table Description

The CONCEPT_SYNONYM table contains alternative terms, synonyms, and translations of concept names. It expands search capabilities and improves query accuracy for data retrieval.

User Guide

CONCEPT_SYNONYM is useful for free-text concept searches. A concept can have multiple synonyms, including in different languages. For example, "Myocardial infarction" may have synonyms like "Heart attack", "MI".

ETL Conventions

Table provided by OHDSI. Can be enriched with local translations. The language_concept_id uses ISO language concepts (e.g., 4180186 for English, 4182503 for French). Useful for building multilingual search interfaces.

Table Description

The CONCEPT_RELATIONSHIP table contains records defining relationships between concepts and their nature/type. It enables exploration of hierarchical and semantic connections within healthcare data.

User Guide

Key relationships: "Maps to" (mapping to standard concept), "Is a" (parent-child hierarchy), "Has ingredient" (drug composition). For ETL mapping, search for "Maps to" relationships from source concepts to standard concepts.

ETL Conventions

For mapping, use the query: SELECT concept_id_2 FROM concept_relationship WHERE concept_id_1 = [source_concept_id] AND relationship_id = 'Maps to' AND invalid_reason IS NULL. Relationships are directional; the inverse relationship often exists with a reverse relationship_id.

Table Description

The RELATIONSHIP table provides a reference list of all relationship types between concepts. It documents direct/reverse relationships and their hierarchical characteristics.

User Guide

Main relationships: "Maps to" / "Mapped from" (mapping), "Is a" / "Subsumes" (hierarchy), "Has ingredient" / "Ingredient of" (composition). Hierarchical relationships (is_hierarchical = 1) are used for navigating concept trees.

ETL Conventions

Table provided by OHDSI. Relationships with defines_ancestry = 1 are used to compute the CONCEPT_ANCESTOR table. Always use the appropriate relationship based on the desired navigation direction.

Table Description

The CONCEPT_ANCESTOR table contains complete hierarchical relationships between concepts for simplified analysis. It includes all parent-child and higher-level ancestry connections.

User Guide

CONCEPT_ANCESTOR is essential for inclusive queries. For example, to find all patients with "diabetes", the query automatically includes "type 1 diabetes", "type 2 diabetes", etc. Each concept is also its own ancestor (min_levels = 0).

ETL Conventions

Table computed by OHDSI from hierarchical relationships. Example query to find all descendants: SELECT descendant_concept_id FROM concept_ancestor WHERE ancestor_concept_id = [parent_id]. Use min_levels_of_separation = 0 to include the concept itself.

Table Description

The SOURCE_TO_CONCEPT_MAP table maintains local source codes and mappings to standard concepts for ETL. Use tools like Usagi or Perseus to populate this table; it supports code mapping processes.

User Guide

SOURCE_TO_CONCEPT_MAP is the working table for ETL. It stores correspondences between your local codes (internal codes, facility codes) and OMOP standard concepts. It complements CONCEPT_RELATIONSHIP for non-standard vocabularies.

ETL Conventions

Create a custom vocabulary_id for your source (e.g., "LOCAL_HOSPITAL"). Populate this table before ETL with all necessary mappings. The same source_code can map to multiple target_concept_ids if needed. Document manual mappings for reproducibility.

Table Description

The DRUG_STRENGTH table contains structured content about the amount/concentration of ingredients in drug products. It provides supplemental information supporting standardized drug utilization analysis.

User Guide

DRUG_STRENGTH allows calculation of administered doses. For solid forms, use amount_value/amount_unit. For liquids, use the numerator/denominator ratio. A multi-ingredient drug has multiple rows, one per ingredient.

ETL Conventions

Table provided by OHDSI for RxNorm and RxNorm Extension vocabularies. Useful for standardizing dose calculations and pharmacoepidemiology studies. DDD (Defined Daily Dose) can be calculated from this data.

Table Description

The CONDITION_ERA table contains spans of time when a Person is assumed to have a given condition. It aggregates chronic conditions and closely timed visits using a 30-day persistence window.

User Guide

CONDITION_ERA simplifies disease duration analysis. Conditions close in time (gap <= 30 days by default) are merged into a single era. Useful for identifying patients with chronic conditions or recurrences.

ETL Conventions

Derived table, generated by an ETL script from CONDITION_OCCURRENCE. The standard algorithm uses a 30-day gap to merge consecutive occurrences. The condition_concept_id is standardized to the most specific level available.

Table Description

A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras. Every record in the DRUG_EXPOSURE table should be part of a drug era based on the dates of exposure.

User Guide

NA

ETL Conventions

The SQL script for generating DRUG_ERA records can be found here.

Table Description

A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient.

User Guide

NA

ETL Conventions

Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.

Table Description

The subject of a cohort can have multiple, discrete records in the cohort table per cohort_definition_id, subject_id, and non-overlapping time periods. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINITION tables are kept in a separate schema to alleviate confusion.

User Guide

NA

ETL Conventions

Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time.

Table Description

The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.

User Guide

NA

ETL Conventions

NA

Table Description

The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.

User Guide

NA

ETL Conventions

NA

Table Description

The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.

User Guide

NA

ETL Conventions

NA