OMOP CDM v5.4 Data Model
Overview
This page describes what each table in the STARR-OMOP CDM v5.4 implementation holds, and how Stanford populates it. The fields themselves — type, requiredness, foreign keys and per-field descriptions — are in the data dictionary, which is searchable, filterable and downloadable as a spreadsheet.
Total Tables: 43
CARE_SITE
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.). For Stanford University, this includes a range of care sites from inpatient hospital facilities to outpatient clinics and specialized centers such as immunization and campus-specific health services.
6 fields — see them in the data dictionary.
CDM_SOURCE
The CDM_SOURCE table provides information about the source data and the process used to transform the data into the OMOP Common Data Model.
11 fields — see them in the data dictionary.
COHORT
The cohort table contains records identifying the subject(s) for defined cohort, during each period where they fit the cohort definition(s) defined in the cohort_definition table. 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. 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. This table is not currently populated in STARR OMOP.
4 fields — see them in the data dictionary.
COHORT_DEFINITION
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. This table is not currently populated in STARR OMOP.
7 fields — see them in the data dictionary.
CONCEPT
The primary purpose of the CONCEPT table is to provide a standardized representation of medical Concepts, allowing for consistent querying and analysis across the healthcare databases. Users can join the CONCEPT table with other tables in the CDM to enrich clinical data with standardized Concept information or use the CONCEPT table as a reference for mapping clinical data from source terminologies to Standard Concepts. Each concept is uniquely identified by a concept_id and has a concept_name, which describes the concept. Concepts can be classified into different domains, such as drug, procedure, condition, etc., and can have relationships with other concepts.
10 fields — see them in the data dictionary.
CONCEPT_ANCESTOR
The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher-level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage for Standard or Classification concepts. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept, and the other way around. For example, drug ingredients and drug products, beneath them in the hierarchy, are all descendants of a drug class ancestor. This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.
4 fields — see them in the data dictionary.
CONCEPT_CLASS
The CONCEPT_CLASS table includes semantic categories that reference the source structure of each Vocabulary. Concept Classes represent so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels (e.g. SNOMED) of the vocabulary structure. Vocabularies without any Concept Classes, such as HCPCS, use the vocabulary_id as the Concept Class. This reference table is populated with a single record for each Concept Class, which includes a Concept Class ID and a fully specified Concept Class name.
3 fields — see them in the data dictionary.
CONCEPT_RELATIONSHIP
The CONCEPT_RELATIONSHIP table contains records that define relationships between any two Concepts and the nature or type of the relationship. This table captures various types of relationships, including hierarchical, associative, and other semantic connections, enabling comprehensive analysis and interpretation of clinical concepts. Each relationship type is defined in the RELATIONSHIP table.
6 fields — see them in the data dictionary.
CONCEPT_SYNONYM
The CONCEPT_SYNONYM table captures alternative terms, synonyms, and translations of Concept Name into various languages linked to specific concepts, providing researchers with a comprehensive view of how Concepts may be expressed or referenced. Researchers can leverage the CONCEPT_SYNONYM table to expand search capabilities and improve query accuracy by incorporating synonymous terms into data analysis and retrieval processes. Also, researchers can enhance their mapping efforts between local terminologies and standardized concepts by identifying synonymous terms associated with concepts in the CONCEPT_SYNONYM table.
3 fields — see them in the data dictionary.
CONDITION_ERA
6 fields — see them in the data dictionary.
CONDITION_OCCURRENCE
16 fields — see them in the data dictionary.
COST
The cost table captures the various financial aspects of healthcare events. It includes the cost of procedures, drug exposures, visits, and other healthcare events, and can capture charges, payments, and adjustments for these events. This table is not currently populated in STARR OMOP.
22 fields — see them in the data dictionary.
DEATH
OMOP CDM v5.4 DEATH table. Stores information about a Person’s death, including the date/time, cause, and source type.
In STARR-OMOP, the cause of death fields are not currently available from source systems and remain NULL.
This table contains only EHR-sourced (Epic) death records. External death records (CDPH, LADMF, DMF, etc.) are stored in the _external_death_records extension table, one row per external death record per person.
7 fields — see them in the data dictionary.
DEVICE_EXPOSURE
The Device domain captures information about a persons exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material). 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.
19 fields — see them in the data dictionary.
DOMAIN
The DOMAIN table includes a list of OMOP-defined Domains to which the Concepts of the Standardized Vocabularies can belong. A Domain represents a clinical definition whereby we assign matching Concepts for the standardized fields in the CDM tables. For example, the Condition Domain contains Concepts that describe a patient condition, and these Concepts can only be used in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain, including a Domain ID and a descriptive name for every Domain.
3 fields — see them in the data dictionary.
DOSE_ERA
The dose_era table captures the time periods (eras) during which a person is exposed to a particular dose of a drug. 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. This table is not currently populated in STARR OMOP.
7 fields — see them in the data dictionary.
DRUG_ERA
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.
7 fields — see them in the data dictionary.
DRUG_EXPOSURE
The DRUG_EXPOSURE table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs. This table contains one record per exposure, preferentially bringing in administration records, then dispense records then order records.
23 fields — see them in the data dictionary.
DRUG_STRENGTH
The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.
12 fields — see them in the data dictionary.
EPISODE
The episode table captures aggregated information about periods of continuous engagement with healthcare or health maintenance activities. An episode is intended to represent a meaningful period of time within a broader context, such as a hospital stay, a period of illness, or a treatment cycle. The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases, outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example, cancers including their development over time, their treatment, and final resolution. In STARR-OMOP, the EPISODE table is currently populated only with episodes representing treatment plans (primarily for cancer patients). The EPISODE_EVENT table is currently not populated in STARR-OMOP.
13 fields — see them in the data dictionary.
EPISODE_EVENT
The episode_event table captures the events that are part of an episode. It includes various types of healthcare-related events such as condition occurrences, drug exposures, or procedures that occur as part of a single episode of care. The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode. This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes. This table is not currently populated in STARR OMOP.
3 fields — see them in the data dictionary.
FACT_RELATIONSHIP
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. Currently, this table contains relationships between systolic and diastolic blood pressures taken from the same patient encounter record, as well as mother-baby relationships for babies delivered at Stanford. Relationships are always present in both directions, so there are two rows for any given fact pairing.
5 fields — see them in the data dictionary.
IMAGE_OCCURRENCE
A record of image occurrences from the Vendor Neutral Archive (VNA). This does not include Echocardiograms, Ophthalmology images, or Pathology slides at present. We are also only including image occurrences that can be linked to the clarity procedure order information.
17 fields — see them in the data dictionary.
LOCATION
The location table represents a generic way to capture physical location or address information of Persons and Care Sites.
13 fields — see them in the data dictionary.
MEASUREMENT
The MEASUREMENT table contains records of Measurements, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample.
23 fields — see them in the data dictionary.
METADATA
The metadata table metadata information about a dataset that has been transformed to the OMOP Common Data Model. At the moment for STARR OMOP, this table only contains a single entry specifying the OMOP CDM version (in this case, OMOP CDM version 5.4.2).
9 fields — see them in the data dictionary.
NOTE
The NOTE table captures unstructured information that was recorded by a provider about a patient in free text notes on a given date.
17 fields — see them in the data dictionary.
NOTE_NLP
The note_nlp table encodes all output of NLP on clinical notes. Each row represents a single extracted term from a note.The note_nlp table captures the detailed outputs of natural language processing (NLP) applied to the unstructured text found in the note table. This table contains the detailed annotations, the corresponding note identifiers, and the concepts identified through the NLP pipeline. This table is not currently populated in STARR OMOP.
14 fields — see them in the data dictionary.
OBSERVATION
This table contains records of various observations made about individuals. It includes social history factors, ethnicity background, pregnancy and delivery observations, and other observations that are not captured in other tables.
21 fields — see them in the data dictionary.
OBSERVATION_PERIOD
The observation period table is intended to contain records of spans of time in which a patient’s clinical event history is considered observable, i.e. clinical events that happen to the person are recorded in the event tables, and absence of records indicate such events did not occur during this span of time. Please note that since STARR-OMOP only contains records of clinical events that are present in the Stanford EHR systems, it is not possible to determine if the absence of an event means that the event did not occur or if the patient was instead treated in a different healthcare system.
5 fields — see them in the data dictionary.
PAYER_PLAN_PERIOD
This table contains information about the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which fully/partially pays for (or directly provides) the care (billable healthcare services). These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person (Payer Plan Periods) are recorded in this table.
17 fields — see them in the data dictionary.
PERSON
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. If the patient is present in both SHC and LPCH Clarity, the SHC patient record is used.
18 fields — see them in the data dictionary.
PROCEDURE_OCCURRENCE
The PROCEDURE_OCCURRENCE table contains records of procedures that have been performed on patients. The procedures are typically performed by healthcare providers and are recorded in the source data. For STARR-OMOP this includes ordered procedures and billed procedures.
16 fields — see them in the data dictionary.
PROVIDER
The PROVIDER table contains a list of uniquely identified healthcare providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.
13 fields — see them in the data dictionary.
RELATIONSHIP
The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two Concepts in the CONCEPT_RELATIONSHIP table, the respective reverse relationships, and their hierarchical characteristics. Note that Concepts representing relationships between the clinical facts in the FACT_RELATIONSHIP table are stored in the CONCEPT table and belong to the Relationship Domain.
6 fields — see them in the data dictionary.
SOURCE_TO_CONCEPT_MAP
The SOURCE_TO_CONCEPT_MAP table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept. STARR builds this table as an empty placeholder so that the OMOP 5.4 schema is complete; local source-code mappings are carried in the custom vocabulary instead.
9 fields — see them in the data dictionary.
SPECIMEN
The specimen table captures data on biological samples, or specimens, from a person. A specimen record indicates characteristics, such as date/time, specimen type, specimen source, and anatomic site of origin, in which the specimen was collected. This table is not currently populated in STARR OMOP.
15 fields — see them in the data dictionary.
VISIT_DETAIL
The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.
19 fields — see them in the data dictionary.
VISIT_OCCURRENCE
This table contains Events where Persons engage with the healthcare system for a duration of time. They are often also called “Encounters”. Visits are defined by a configuration of circumstances under which they occur, such as (i) whether the patient comes to a healthcare institution, the other way around, or the interaction is remote, (ii) whether and what kind of trained medical staff is delivering the service during the Visit, and (iii) whether the Visit is transient or for a longer period involving a stay in bed.
17 fields — see them in the data dictionary.
VOCABULARY
The VOCABULARY table includes a list of the Vocabularies integrated from various sources or created de novo in OMOP CDM. This reference table contains a single record for each Vocabulary and includes a descriptive name and other associated attributes for the Vocabulary. The primary purpose of the VOCABULARY table is to provide explicit information about specific vocabulary versions and the references to the sources from which they are asserted. Users can identify the version of a particular vocabulary used in the database, enabling consistency and reproducibility in data analysis.
5 fields — see them in the data dictionary.
_EXTERNAL_DEATH_RECORDS
Extension table storing one row per external death record per person. External sources include CDPH (California Decedent Registry), LADMF (Limited Access Death Master File), other Clarity external death report organizations, and DMF (Social Security Death Master File).
This table complements the OMOP death table, which contains only EHR-sourced (Epic) death records. External death records are separated because they carry lower confidence than EHR-confirmed deaths and should not be given the same weight by researchers.
Unlike the death table, Clarity-sourced external records are not subject to the OMOP observation period date filtering. DMF-sourced records are limited to deaths at least 3 years before the data cut date due to SSA release lag.
This table is custom to STARR-OMOP and is not part of the standard OMOP CDM.
5 fields — see them in the data dictionary.
_VARIANT_OCCURRENCE
The VARIANT_OCCURRENCE table contains information about genetic variants identified in patients through genomic testing. This table is custom to STARR-OMOP and is not part of the standard OMOP CDM. Currently, it only contains variants identified via the STANFORD ACTIONABLE MUTATION PANEL FOR SOLID TUMORS (STAMP) test. The data is sourced from the Epic Genomics Suite, which incorporated STAMP tests starting in August of 2025. STAMP tests performed prior to this date are not currently included in this table.
28 fields — see them in the data dictionary.
_WHOLE_SLIDE_IMAGING
OMOP extension table for whole slide imaging data from pathology specimens. It contains both information from the PHI-scrubbed whole slide imaging files (svs or isyntac) and source clarity. This table only contains information for slide images we have in GCP buckets with OMOP EHR information.
20 fields — see them in the data dictionary.