# STARR-OMOP Docs ============================================================ # STARR-OMOP v5.4 Stanford Electronic Health Record data in OMOP Common Data Model version 5.4 ============================================================ ## Introduction STARR-OMOP is Stanford Electronic Health Record data from its two Hospitals in an Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM). Use OMOP for observational science, population health science, collaborative network studies and reproducible data science. There are a number of popular CDMs to choose from including i2b2, Pediatric Learning Healthcare System (PEDSNet), Patient-Centered Clinical Research Network (PCORNet), Health Care Systems Research Network, and the US Food and Drug Administration Sentinel. Choosing a particular CDM over another is a matter of meeting specific research objectives. It is not uncommon for an academic medical center to support more than one. Our second generation research clinical data warehouse (r-CDW) needs to support a large number of use cases. For this r-CDW, we chose OMOP CDM. OMOP CDM demonstrates applicability for many different use cases including: - **Claims and EHR** - Proven for integrated analysis of administrative claims and electronic health records - **Longitudinal registries** - EHR-based patient registries for long-term studies - **Transactional databases** - Hospital operational data for quality improvement - **Comparative effectiveness research** - Strong results with minimal information loss during transformation - **Clinical phenotyping** - Speeds up implementation of clinical phenotypes across networks - **Research reproducibility** - Promotes consistent, reproducible research methods ## OMOP Common Data Model v5.4 The OMOP Common Data Model (CDM) is a standardized data structure for observational healthcare data. Version 5.4 represents the latest evolution of this model, maintained by the Observational Health Data Sciences and Informatics (OHDSI) community. ### Key Features - **Standardized Vocabularies**: Maps local codes to standard concepts (SNOMED-CT, RxNorm, LOINC) - **Person-Centric Design**: All clinical events linked to individual patients - **Domain Tables**: Organized by clinical domain (conditions, drugs, procedures, measurements, etc.) - **Temporal Relationships**: Captures timing and sequence of clinical events - **Hierarchical Concepts**: Supports analysis at multiple levels of granularity ### Core Clinical Domains The CDM organizes healthcare data into the following core domains: #### Clinical Event Tables - **Person** - Demographics and patient identity - **Observation Period** - Time spans of available data - **Visit Occurrence** - Healthcare encounters - **Condition Occurrence** - Diagnoses and symptoms - **Drug Exposure** - Medications and prescriptions - **Procedure Occurrence** - Medical procedures - **Device Exposure** - Medical devices - **Measurement** - Lab tests and vital signs - **Observation** - Clinical facts not in other domains #### Health System Tables - **Provider** - Healthcare providers - **Care Site** - Healthcare facilities - **Location** - Geographic information - **Payer Plan Period** - Insurance coverage #### Derived Tables - **Condition Era** - Continuous condition periods - **Drug Era** - Continuous drug exposure periods - **Episode** - Disease phases and treatments ### OHDSI Community & Tools OMOP is supported by an open-source public-private partnership that welcomes community participation. There is a robust community of end users, developers, and thought leaders actively engaged in various shared repositories, discussion forums, training and workshops. **Popular OHDSI tools include:** - **ATLAS** - Web-based cohort definition and analysis - **ACHILLES** - Database characterization and profiling - **Data Quality Dashboard** - Comprehensive data quality checks - **HADES** - Health Analytics Data-to-Evidence Suite (R packages) For comprehensive OMOP CDM v5.4 documentation, visit the official OHDSI documentation. ## STARR-OMOP Pipeline Research IT receives raw Clarity from each of the two hospitals and builds a filtered Clarity for each. These filtered Clarity databases then become the source for OMOP ETLs. Patients at the two hospitals are linked via their MRN. We first build an OMOP database with all PHI present. Then, we build two PHI-scrubbed databases that are accessible to Stanford researchers without an IRB: - **STARR-OMOP-confidential** - Contains PHI scrubbed clinical text (NOTES) using TiDE - **STARR-OMOP-confidential-lite** - Subset without clinical notes, used by ATLAS and ACE (Advanced Cohort Engine) ### Refresh Schedule - **STARR-OMOP-confidential**: Monthly refresh - **STARR-OMOP-confidential-lite**: Monthly refresh Patient identifiers remain stable between refreshes. ## Access & Services ### Getting Access To access STARR-OMOP-confidential and STARR-OMOP-confidential-lite databases, please follow the steps here. ### Consultation Services For OMOP PHI, Limited Data Sets, linking with Clarity, or sharing with non-Stanford researchers, please request a consultation service. ### Documentation & Training For documentation and training resources, please refer to research support. ## Data Model Documentation The Data Model Tables page describes what each OMOP table holds and how Stanford populates it — the implementation notes that do not fit in a grid cell, one section per table. Every section links to that table's fields in the data dictionary below. The documentation is extracted directly from our data transformation layer, ensuring it remains synchronized with the actual implementation. View Data Model Tables → ## Data Dictionary The fields themselves are in the Data Dictionary: every field of every table with its data type, whether it is required, the tables it references, and its description. One searchable, sortable, filterable grid per table, plus a single **All Fields** view across the whole model. It is generated from the same dbt models as the data model page, so the two cannot fall out of step. The complete dictionary is also downloadable as an Excel workbook, one sheet per table. View Data Dictionary → Download as Excel (.xlsx) ## Frequently Asked Questions Common questions about STARR-OMOP are automatically collected from individual FAQ entries and compiled into a comprehensive list. Each question includes detailed explanations, code examples, and best practices for working with the OMOP data model. View FAQ → ============================================================ # OMOP CDM v5.4 Data Model What each table holds and how Stanford populates it ============================================================ ## 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. --- ============================================================ # FAQ Frequently Asked Questions for STARR-OMOP ============================================================ Below is a list of frequently asked questions for STARR-OMOP v5.4. ## How do I know which event is represented in each row ### Question How do I know which events are represented by a single row in each one of the tables (e.g. `condition_occurrence`)? I only see numbers and dates but no other information. ### Explanation The OMOP CDM tables use concept IDs to represent clinical events. These concept IDs are numeric identifiers that map to human-readable terms in the `concept` table. To understand what a row represents, you need to join the clinical event table with the `concept` table. In the `condition_occurrence` table, the `condition_concept_id` field contains the standardized concept representing the condition. To get the actual condition name, you join with the `concept` table. Let's demonstrate how to retrieve condition information with their human-readable names: 1. Importing Python BigQuery package to interact with BigQuery. 2. Setting the project ID for query execution. 3. Creating the BigQuery Client to run queries. 1. The person_id links to the patient who has this condition. 2. The condition_concept_id is the numeric code representing the condition. 3. The concept_name from the concept table provides the human-readable condition name. 4. The vocabulary_id indicates which standardized vocabulary this concept comes from (e.g., SNOMED). 5. The condition_start_date indicates when the condition was diagnosed or observed. 6. The condition_occurrence table contains all condition records. 7. The concept table contains the mapping from concept IDs to readable names. 8. Joining on condition_concept_id = concept_id links the numeric code to its meaning. 9. Select only the SNOMED concepts. They are the majority of the concepts in the condition_occurrence table. 10. Execute the query and convert results to a pandas DataFrame. Now let's check the table You can apply this same pattern to any OMOP-CDM table that contains concept IDs. For example: - In `drug_exposure`, join `drug_concept_id` with the `concept` table - In `procedure_occurrence`, join `procedure_concept_id` with the `concept` table - In `measurement`, join `measurement_concept_id` with the `concept` table ### Conclusion OMOP CDM tables store standardized numeric concept IDs to represent clinical events. To see what these numbers mean, you must join with the `concept` table using the appropriate concept_id field. This design allows for standardized, interoperable healthcare data analysis while maintaining semantic meaning through the vocabulary tables. The `concept` table acts as a central reference that translates all numeric codes into human-readable descriptions. ============================================================ # About ============================================================ Welcome to the STARR-OMOP Documentation #### STARR-OMOP v5.4 - Getting Access - Released Datasets - Technical Specifications - Data Model Tables - Data Dictionary - Changes from OMOP-CDM 5.3 to 5.4 - FAQ #### STARR-OMOP v5.3 (*Archived*) - Technical Specifications - User Guide - Data Dictionary - FAQ ============================================================ # Page Not Found ============================================================ The page you requested cannot be found (perhaps it was moved or renamed). You may want to try searching to find the page's new location. ============================================================ # Changes from OMOP-CDM 5.3 to 5.4 ============================================================ We are pleased to release the first **STARR-OMOP CDM 5.4 dataset,** using the **August 2025 OHDSI vocabulary**. For ease of comparison, this dataset has been generated from the same source EHR data as the OMOP CDM 5.3 January 2026 release (which used the January 2023 OHDSI vocabulary). The two datasets are: * **OMOP 5.3:** `som-rit-phi-starr-prod.starr_omop_cdm5_confidential_2026_01_18` * **OMOP 5.4:** `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_2026_01_18` We strongly encourage users to **compare their cohorts and analyses between the 5.3 and 5.4 datasets** and review any differences. Changes in vocabulary, mappings, and ETL logic may require adjustments in your downstream work in order to achieve the same study goals. We welcome feedback from users and ask that you please report any unexpected issues or questions to the STARR-OMOP team as soon as possible (email: starr-omop-support@stanford.edu). Based on user feedback during this transition period, we plan to **maintain both 5.3 and 5.4 in parallel for ONE additional release cycle** before fully transitioning to 5.4 and retiring 5.3. If your project requires a **static dataset using the previous CDM/vocabulary**, please copy the dataset into your own Nero GCP project to ensure long-term reproducibility. Going forward, we plan to incorporate OHDSI vocabulary updates as they become available (twice a year), with a **short lag to allow for ETL updates, validation, and testing prior to release**. The release notes below are divided into the following sections for readability: * Key Updates and Potential Impact for Researchers, with some recommendations * Table Specific Changes, including impact on overall row counts * New and Upcoming Stanford Specific Data Domain Tables * Additional Details ## Key Updates and Potential Analysis Impact **CDM Version Upgrade** * **What changed:** Dataset upgraded from OMOP CDM 5.3 → 5.4, including new fields and some renamed columns per OMOP standards. * **Potential impact:** Most queries will continue to work, but queries referencing renamed fields or schema elements may require updates. * **Recommended action:** Review queries referencing CDM schema fields, please report to us if errors occur. **Vocabulary Update** * **What changed:** Vocabulary updated to the August 2025 OHDSI Standardized Vocabularies. OHDSI vocabularies are updated twice per year. * **Potential impact:** Concept mappings, concept hierarchies, and domain assignments may change. Cohort definitions, concept sets, and event counts may differ. * **Recommended action:** Re-run cohorts and validate concept sets using the updated vocabulary. Update concept sets as needed to maintain consistency. **Source Value Transparency** * **What changed:** `*_source_value` fields now stored as JSON strings containing additional context about the originating source fields and values. * **Potential impact:** Queries treating source values as simple strings may capture different rows due to changes in what information is included. More detailed source-level analysis is now possible. * **Recommended action:** Review queries using `*_source_value` and consider using JSON functions (e.g., `JSON_VALUE`) for targeted retrieval. **Date & Data Quality Filtering** * **What changed:** Clinical events before Jan 1, 2000 have been filtered out across all clinical event tables, not just the visit tables. Data quality filters (such as removal of cancelled events) have been standardized across domains. * **Potential impact:** Some events previously included may now be removed, while others may be newly included due to more consistent filtering. Persons may no longer qualify for OMOP if all their clinical events are filtered out. * **Recommended action:** Validate event counts and cohort sizes when comparing 5.3 vs 5.4. Ensure study period start dates are 2000 or later. **Diagnosis Mapping Strategy** * **What changed:** Diagnosis mappings now use a consistent strategy to map from a source EHR `dx_id` to an ICD code across all diagnosis sources. * **Potential impact:** Some diagnosis records may map to different standard concepts or domains compared to prior releases. * **Recommended action:** Revalidate cohorts or phenotypes based on diagnosis codes. **Expanded Procedure & Device Mapping** * **What changed:** Expanded mappings now incorporate HCPCS codes and billing procedure data, improving representation of procedures and devices. * **Potential impact:** Procedure and device counts have increased due to additional mapped records. * **Recommended action:** Review cohorts and analyses relying on procedure or device counts. **Improved Domain Routing** * **What changed:** Improved routing of concepts between condition, procedure, measurement, and device tables. * **Potential impact:** Some records may appear in different OMOP domains than before, potentially affecting queries restricted to a specific table. * **Recommended action:** Check analyses that assume specific domains for certain concepts. **Additional Death Data Source** * **What changed:** California Department of Public Health death data has been added to the PHI OMOP death table. Note that this data is not yet part of the confidential dataset. * **Potential impact:** Additional death records appear in the PHI dataset, improving mortality capture and potentially impacting survival analyses. Multiple death dates may be present for some patients. * **Recommended action:** Revalidate survival analyses or mortality outcomes, especially if you have been using the identified OMOP. Determine which death sources to include in your analysis. **Location Table Deduplication** * **What changed:** The location table has been deduplicated and aligned more closely with OMOP CDM specifications (one row per unique street address). * **Potential impact:** Persons or `care_sites` that share the same street address will now have foreign keys linking to the same `location_id`. * **Recommended action:** All analyses should still work as before; use the `location_id` on the `care_site` or `person` table to link to the location table. **Note Filtering Changes** * **What changed:** More relaxed filtering rules for notes (ex. not requiring an associated encounter) allow more clinical notes to appear in the note table. * **Potential impact:** Increased note counts and improved coverage of clinical documentation. * **Recommended action:** Expect larger note volumes and update note-based analyses if needed. **New Stanford-Specific Domain Tables** * **What changed:** New Stanford-specific domains including `image_occurrence` (available now), with `_whole_slide_imaging` and `_genomic_variants` planned for the next release. * **Potential impact:** Enables research using imaging and genomic data integrated with OMOP clinical data. * **Recommended action:** Researchers interested in imaging/genomics can explore these new tables as they become available. **Note Type Source Information now in `note_source_value` instead of `note_title`** * **What changed:** The `note_source_value` field now contains information about the note type from multiple sources. The `note_title` field is no longer used and is null for all rows. * **Potential impact:** Queries that relied on the `note_title` field will no longer return useful results. * **Recommended action:** Analyses should be updated to instead point to `note_source_value`, and reviewed for consistency as the strings now contain more source fields. ## Table Specific Changes, and logic justification ### Person **Minimum date filter** In STARR-OMOP, we require patients in OMOP to have at least one record in the OMOP clinical event tables. As we are now applying a **minimum date filter of Jan 1, 2000** to all clinical event tables, patients who only had clinical events prior to 2000 are no longer eligible for inclusion in OMOP. **SHC/LPCH reconciliation** If a patient has a record in both the SHC and LPCH Clarity patient tables, we currently select ONLY the SHC record to populate the OMOP `person` table. Previously, we were coalescing the SHC and LPCH records within each individual field (sex, race, primary care provider, location, etc.), which results in slightly more populated fields but can also be inconsistent. We are still exploring ways to select the best information available for each patient from both sources and plan to update this in the future. **Row count impact** Reduction in row count, as patients who had only events prior to 2000 are no longer eligible for OMOP due to all their clinical events being filtered out. ### Condition_occurrence **Updated mapping from source diagnosis IDs to ICD codes for improved consistency across diagnosis sources** We have adopted a consistent approach to assigning ICD-9/10 CM codes using the `dx_id`s present in the EHR source data. For context, there are multiple different ways of linking a `dx_id` (which is the only diagnosis identifier on the individual event record) to its corresponding ICD codes using Clarity tables: * The table `clarity_edg` is the main lookup table for diagnoses (primary identifier: `dx_id`) in Clarity. This table has two fields containing ICD-9 and ICD-10 codes for each `dx_id`: `current_icd9_list` and `current_icd10_list`. Note that both fields can contain multiple ICD codes (comma-delineated). * The tables `edg_hx_icd9_list` and `edg_hx_icd10_list` contain mappings from `dx_id`s to ICD-9-CM and ICD-10-CM codes respectively, over specific time ranges (hx = ‘historical’ i.e. over time). There can be multiple rows per `dx_id` in these tables, each with an effective start date, effective end date, and `code_list` containing the ICD codes. The logic we are applying across all source tables that contain `dx_id`s in OMOP CDM 5.4 is to try to use the ICD-9 or ICD-10 mapping that is consistent with the date of diagnosis (i.e., look for the diagnosis date to be between the start and end dates of the mapping from the `edg_hx_icd…_list` tables). * If we don’t have a mapping for that time period, then we use the `current_icd9_list` field from `clarity_edg` if the `dx_date` is on or before September 30th, 2015 (which is the last date that ICD-9-CM was supposed to be used), or the `current_icd_10_list` field if the date is on or after October 1st, 2016 (the first date of ICD-10). * If we still don’t have an ICD mapping, we’ll resort to using a populated `current_icd_list`, regardless of whether it's for the correct time period. * If we don’t have a `dx_date`, we assume an ICD-10 period and use the current ICD-10 list. The goal with this approach was to keep the ICD mappings time-appropriate and stable as much as possible (the historical mappings shouldn’t be changing anymore), but to still use the ‘current’ code list (which may be updated at any point in time) if we don’t have the correct historical information, because it facilitates the mapping to a reasonable OMOP `concept_id`. We find that we achieve very good coverage of `dx_id`-to-ICD mappings using this approach (>99.99% of records with a `dx_id` have a corresponding ICD code). Note that the ICD codes are available in OMOP in the `condition_source_value` field as well as in the `condition_source_concept_id` (join to the concept table to get the ICD code and name); however, the OMOP-designated standard vocabulary for conditions is usually SNOMED, so the final `condition_concept_id` is assigned via the standard OMOP vocabulary mapping from the ICD code to the standard SNOMED code. This assignment of ICD codes differs somewhat from what we were doing in 5.3, which was not consistent across all sources of diagnoses. You may notice changes to the source or standard concept IDs for certain diagnoses as a result of this update. **Source values now include full diagnosis context in JSON string format** The `condition_source_value` field in 5.4 now contains the ***`dx_id`, `dx_name`, `code_type` (ICD-9-CM or ICD-10-CM), and `code_list`*** (ICD code(s) mapped from the `dx_id` according to the above logic). Note that the `code_list` can contain more than one ICD code; each of the codes in the `code_list` will result in its own row in the OMOP table, since each ICD code has its own mapping to a standard OMOP concept, and the entire code list is included in the `source_value` field for all resulting rows. Previously, just the individual code (often an ICD code, but not always) was used to populate the source value field. It was not obvious from the source value field whether it was an ICD-9-CM, ICD-10-CM, or custom code. It was also unclear whether multiple ICD codes were needed to fully map the source `dx_id`. This should now be more clearly reflected in the updated `condition_source_value`. Below is an example of two rows that originated from the same `dx_id`, using the old format vs the new format. In both rows: * The **old `condition_source_value`** contained only the code with no context; the **new `condition_source_value`** has multiple kinds of information to provide full context. * The condition_source_concept_id is the OMOP concept ID for the ICD code, which is not a standard concept. * The condition_concept_id is the OMOP concept ID for the corresponding standard concept, typically a SNOMED code. | Old `condition_source_value` | Updated `condition_source_value` | `condition_source_concept_id` | `condition_concept_id` | | :---- | :---- | :---- | :---- | | `583.81` | `{"dx_id": 100390, "dx_name": "Lupus nephritis (CMS-HCC)", "code_type": "ICD-9-CM", "code_list": "710.0, 583.81"}` | 44826730 | 198124 | | `710.0` | `{"dx_id": 100390, "dx_name": "Lupus nephritis (CMS-HCC)", "code_type": "ICD-9-CM", "code_list": "710.0, 583.81"}` | 44819941 | 257628 | : {tbl-colwidths="[15,45,20,20]"} **Temporary removal of ICD-O** We are currently not generating ICD-O codes for insertion into the `condition_occurrence` table. Previously, these codes were constructed by concatenating ICD-10 diagnosis codes with histology information from the cancer staging source tables. Due to concerns about the validity and reliability of this concatenation approach, this process has been temporarily suspended. We are actively evaluating alternative methods and hope to incorporate more reliable ICD-O representations in a future release. **Row Count Impact** We see a reduction in row counts as Vocabulary updates led to more rows being domain-routed to other tables. ### Condition-Era table (deliberately left blank) We decided not to populate the table because the 'end' dates are unreliable. ### Death Table **Inclusion of CDPH death dates – ONLY in STARR-OMOP PHI dataset** In the OMOP baseline/PHI dataset, we are now including CDPH (California Department of Public Health) death dates, in addition to the existing death date sources (Clarity and LADMF). The non-Clarity death dates are put in a custom field called `_death_date_external` that specifies both the source and the death date, and may contain multiple death dates (across different sources or from the same source). Persons are included in the baseline/PHI death table if they have a death date from ANY source, but as part of the deidentification step, the `_death_date_external` field is dropped, and only rows/columns pertaining to the Clarity death date are retained. *Hence, the final confidential dataset remains restricted to ONLY the Clarity death date, as before.* **Row Count Impact** Significant increase in rows for the identified death table. ### Drug Exposure **Source Value Improvement** There are no major changes to the logic of the drug exposure table. The `drug_source_value` has been improved to contain both the `medication_id` and the `medication_name`. **Row Count Impact** There has been a small decrease in the mapping rate. This is primarily due to cleaning up custom mappings and retaining only the most prevalent drugs. We are relying primarily on the `medication_id`-to-RxNorm mapping tables in Epic Clarity. Since custom mappings need to be maintained separately and can easily go out of date, we are actively trying to rely more on the existing source data mappings, which should help improve data quality going forward. ### Drug Era **Row Count Impact** There is no change to the logic of the `drug_era` table, but small changes in the mapping for the underlying `drug_exposure` data have slightly increased the row count. ### Device Exposure **Inclusion of both ordered and billing procedures** The device exposure table currently contains only records that are domain-routed from procedure source tables (i.e., they were records in a procedure table in Clarity, but map to a standard OMOP concept in the device domain, and are therefore brought into the OMOP device table). However, we are now allowing both billing procedures and ordered procedures to be domain-routed into this table (Note: In 5.3, only ordered procedures were checked for domain routing). **Inclusion of HCPCS billing procedures** We expanded our source procedure mapping to include HCPCS codes from billing tables in addition to CPT codes. **Row Count Impact** Row Count has gone up significantly because of the above two ETL changes. ### Care Site **Updated Filtering/Clean up** Care sites are now included in the identified OMOP `care_site` table only if that `care_site_id` is referenced elsewhere in OMOP (the other OMOP tables with foreign keys to `care_site` are the `person`, `provider`, `visit_occurrence`, and `visit_detail` tables). This clean-up step was earlier only happening in the de-id step and was not reflected in the identified OMOP. **Row Count Impact** Reduction in row count in the identified OMOP, no change in confidential OMOP. ### Location **Deduplication** The location table is now at the level of one row per unique street address. Multiple entities (including multiple patients and multiple `care_site`s) will link to the same `location_id` if they share the same street address. The previous implementation in OMOP 5.3 had one row per patient and one row per `care_site`, which is less efficient and does not follow the OMOP CDM specifications. **Updated Filtering** Locations are now only included in the OMOP baseline/PHI location table if that `location_id` is referenced elsewhere in OMOP (the other OMOP tables with foreign keys to location are the `person` and `care_site` tables). This step was previously happening at the end of the DEID process, so there is no change to the confidential OMOP table. **Addition of New Fields/Columns** There are new fields on the location table in 5.4 that weren’t present in 5.3: `country_concept_id`, `country_source_value`, `latitude`, and `longitude`. (Note that we were already providing fields `_latitude` and `_longitude` in OMOP 5.3, with the underscores at the beginning signifying that they were not part of the official OMOP CDM 5.3 data model – now those fields are official and don’t have the underscore at the beginning). **Row Count Impact** Reduction in row count due to deduplication and filtering. ### Measurement **Field/Column name updates** There is 1 new field (`unit_source_concept_id`) and 2 fields that were present in STARR-OMOP 5.3 but have had the names updated to match the official 5.4 specs (`measurement_event_id`, `meas_event_field_concept_id`). These fields had been previously added to 5.3 ahead of the official CDM update because they were needed for the implementation of the oncology information that relies on linking cancer modifiers in the measurement table to cancer diagnoses in the `condition_occurrence` table using those fields. **Row Count Impact** Increase in overall row count primarily because of improved concept mapping from flowsheet data – for eg: SPO2 flowsheet concept previously in observation domain (rerouted), is now mapping to a measurement concept. ### Note **`note_title` population logic update** We have stopped populating the `note_title` field because it is not provided in the source Clarity data. The information previously in the `note_title` field was actually ‘note type’, and is now provided in the `note_source_value` field per the CDM specifications. We are now providing the full context for the note across the many note-type fields available in the source data in the `source_value` field. Previously, to create the `note_title` field, we were coalescing the following fields in this order for notes coming from the `hno_notes` table: `ip_note_type`, `note_type_noadd`, `pre_ucn_note_type`, and `trn_doc_type`. For notes coming from the order impression/order narrative tables or for pathology reports, the `note_title` field was set to the `order_type`, or to ‘procedure’ if the `order_type` was null. **`note_source_value` field update** The `note_source_value` field in 5.3 contained an internal note ID that was obscured during the process of de-identification. The field now contains multiple fields to give full context on the ‘type’ of note. The exact fields vary depending on the source table; for example, notes originating from the `hno_notes` table have the following fields: `note_type_noadd`, `ip_note_type`, `pre_ucn_note_type`, `trn_doc_type`, and `letter_reason`. For most notes, not all of these fields will be populated. **Updated Filtering** We have relaxed the filtering rules applied to the note table in certain cases – our approach is to favor inclusion rather than exclusion when there is no clear data quality or privacy reason to remove records. Different research use cases often require different types of information, and we believe this approach best serves the research community. Notes are no longer excluded if they lack an associated `pat_enc_csn_id` in the source Clarity data. Because OMOP is a person-centric data model, a linkage to an encounter is not required for inclusion in OMOP. In addition, notes with a null `note_status` are now included regardless of note type. Previously, only RTF notes with a null `note_status` were retained. During our review of the source data, we observed that `note_status` is populated inconsistently and appears to depend on specific documentation workflows. For example, all SHC notes where `pre_ucn_note_type` = 'Radiology Study Results' have a null `note_status`, and approximately 97% of SHC notes with `pre_ucn_note_type` = 'RTF Letter' also have a null `note_status`. This is why a special case had previously been added to the OMOP note ETL to allow null `note_status` values specifically for RTF Letter notes. Rather than attempting to selectively include certain note types with null `note_status`, and because we do not have a clear rationale for excluding these notes, we have updated the ETL to allow notes with a null `note_status` across all note types. Please note that we are still excluding notes with a `note_status` of ‘Deleted’, ‘Incomplete’, etc. **Addition of accession number** The accession number has now been added to the Note table (note: this change was also made recently in OMOP 5.3). This column is not part of the official OHDSI OMOP 5.4 CDM, so the column name begins with an `_` to indicate it is an additional column. Currently, the accession number is only populated for radiology and pathology reports. This column can be used to link to the `image_occurrence` and `_whole_slide_imaging` (coming soon!) table in STARR-OMOP and may also be useful for external linkages, depending on the research use case. Please note that accession number is not guaranteed to be unique, so joins on accession number should also include `person_id`. **Row count Impact** Increase in note row count due to more relaxed filtering logic. ### Procedure Occurrence **More consistent domain routing** We previously allowed only records from encounter diagnosis source tables to be domain-routed into the procedure table, and ignored records originating in the billing diagnosis source tables (for domain routing). This resulted in those records not being present in the final OMOP in either the `condition_occurrence` or `procedure_occurrence` tables. We are now domain-routing all condition source tables to the procedure table as specified by the domain of the standard concept. This has resulted in an increase in rows in the `procedure_occurrence` table relative to OMOP 5.3. **Improved standard concept mapping** We have improved the standard concept mapping rate of our source procedure data by utilizing LOINC codes for certain ordered procedures that do not have an available CPT/HCPCS/ICD procedure code (mostly applicable to orders for labs), as well as improving our utilization of existing CPT/HCPCS/ICD procedure codes by independently verifying code validity rather than relying entirely on the existing classification of codes in the source data. We are still custom-mapping certain common procedures that have no standard procedure code in the source data, but the number of custom mappings is much lower than in the prior OMOP. We hope this will result in improved maintenance of mapping rates over time compared to our prior approach, as we are better leveraging the ongoing work the hospital does to keep the codes mapped. Note that many of the lab procedures now mapped to a standard concept via their LOINC codes are also being domain-routed into the measurement table, per the OMOP vocabulary domain specifications. **Row Count Impact** Overall increase in row counts as we are now allowing domain-routing from billing condition source tables (previously only encounter condition source tables were being domain-routed). ### Observation **Temporary Source data removal** We have not yet brought in source data from the Clarity table `medical_hx` into the observation table, even though it was present in 5.3. Following additional investigation, we have determined that this information should be preserved and plan to reintroduce it in a future iteration of the OMOP 5.4 dataset. **Domain routing impact** Although not an ETL change to the observation table itself, we updated the custom mappings for several prevalent source values that were previously in the observation table but are now not, or vice versa. For example, SPO2 from flowsheets used to be mapped to a concept in the observation domain, but is now mapped to a concept in the measurement domain, and therefore can be found in the measurement table, whereas the flowsheet for inspired nitrous oxide moved back from the measurement table into the observation table. **Row Count Impact** Small overall reduction in row counts due to temporary loss of a data source. ### Observation_period **Row Count Impact** Overall reduction as there is a reduction in the person table. ### Provider **Updated Filtering/Clean up** Providers are now included in the OMOP baseline/PHI provider table only if that `provider_id` is referenced elsewhere in OMOP (foreign keys to provider are present in the `condition_occurrence`, `device_exposure`, `drug_exposure`, `measurement`, `note`, `observation`, `person`, `procedure_occurrence`, `visit_detail`, and `visit_occurrence` tables). This step was previously happening at the end of the DEID process, so there is no change to the confidential OMOP table. **Row Count Impact** Reduction in row Count for the PHI OMOP Provider table; no change for the confidential table. ### Visit Occurrence **`visit_concept_id` mapping update** We have overhauled the way source encounters are assigned to a standard `visit_concept_id` in OMOP. This change has resulted in a decrease in the overall mapping rate of visits to standard `visit_concept_id`s; however, we have much higher confidence in the mappings that do exist. Most standard patient visit types continue to be well represented under the new mapping approach. Encounters that are no longer mapped typically correspond to administrative events, legacy system conversions, or other records that do not represent true patient visits. OMOP does not provide a standard visit concept ID to represent administrative visits. We use the following source information to classify an encounter: * Encounter type (`enc_type`) * Visit type (`appt_prc`) * Patient class (`adt_pat_class`) * Admission type (`hosp_admsn_type`) * Department name (`effective_dept_name`) Other key changes from the prior visit classification are that encounters that occur during an inpatient stay are no longer classified as inpatient themselves – only the primary hospitalization is classified as inpatient `visit_type`. Sub-encounters such as a visit to radiology or imaging that occurred during the hospital stay are now typically classified as ‘outpatient’. We are also no longer using the concept ‘Hospital’, which previously served as a catch-all for unclassified visits but was confusing for our users because it is listed in the vocabulary hierarchy as a descendant of both ‘inpatient’ and ‘outpatient’ visit types. **Change in handling of ‘history’ encounters** ‘History’ encounters are created in Epic to hold information recorded about a patient’s social or medical history. In addition to having their own encounter ID, they also typically have a linkage to the actual patient encounter (such as an office visit) that prompted the collection of the patient’s history information. In OMOP 5.4, we have chosen to link facts about a patient’s medical and/or social history to the actual patient encounter rather than the ‘history’ encounter, which means that most of these encounters no longer qualify for inclusion in OMOP because they no longer have associated clinical events. The actual social history information is still present in OMOP in the observation table. **Row Count Impact** Overall reduction in row counts as events coming from history encounters are linked to the actual patient encounter, so many history encounters no longer have associated events and are therefore filtered out. ### Visit_detail There is no update to the logic of the `visit_detail` table from 5.3 to 5.4. **Row Count Impact** Very slight increase in row count, due to changes to the logic of the underlying tables that are referenced in `visit_detail`. ### Payer_plan_period There is no change to the logic of the `payer_plan_period` table between 5.3 and 5.4. **Row Count Impact** Slight reduction in row count, due to a reduction in the person table. ### Fact_relationship There is no update to the logic of the `fact_relationship` table from 5.3 to 5.4. **Row Count Impact** Slight increase in row count, due to changes to the logic of the underlying tables that are referenced in `fact_relationship`. ## New and Upcoming Stanford Specific Data Domain Tables We have added, and may continue to add, Stanford-specific tables that support the needs of our research community. These tables are often motivated by data types required for high-priority institutional projects that leverage the OMOP CDM, even if they are not yet part of the official OMOP schema. ### Image_occurrence (available) `image_occurrence` is a relatively new table to STARR-OMOP (note that it was also added to STARR-OMOP CDM 5.3 last year). It links the DICOM images to OMOP EHR data and provides links to deidentified DICOM files, the radiology reports housed in the OMOP notes table, and the relevant procedure housed in the procedure table. It also contains DICOM metadata such as study and series description, accession number, modality, and anatomic site (BodyPartExamined). The table does not include Echocardiograms, Ophthalmology images, or Pathology slides at present, and additional permissions are required to access the DICOM images. ### _whole_slide_imaging (upcoming) `_whole_slide_imaging` is a Stanford-specific extension table designed to link pathology slides with EHR data (the table name has an underscore prefix to indicate that it is custom to Stanford and is not part of the official OHDSI OMOP CDM). ISyntax and SVS files have been converted to tiff and JSON files and de-identified. Each record represents a single whole slide image with associated metadata including: * Patient identifier (`person_id`) * Accession number linking to clinical specimens * URIs to both JSON metadata and TIFF image files * Specimen source and type classifications * Procedure timing information * Links to clinical notes The table name is prefixed with “`_`” to distinguish it from a standard OMOP table. ### _variant_occurrence (upcoming) `_variant_occurrence` is a Stanford-specific extension table designed to provide data on genetic variants (the table name has an underscore prefix to indicate that it is custom to Stanford and is not part of the official OHDSI OMOP CDM). The table currently contains only variants detected by the Stanford Actionable Mutations Panel for Solid Tumors, and is sourced from a Clarity table that is part of the Epic Genomics Module, which went online at SHC in late 2025. There has not been any backfill of this source table, so we only have variant information from late 2025 onwards in the OMOP table. Each record represents a single genetic variant that has been identified by a STAMP test, and has associated metadata including: * Patient identifier (`person_id`) * Visit identifier (`visit_occurrence_id`) * Provider identifier (`provider_id`) * `order_datetime` * `test_name` * Variant type * Chromosome * Amino acid change * Genomic DNA change * Allelic frequency (VAF) * Accession number The table name is prefixed with “`_`” to distinguish it from a standard OMOP table. ## Additional Notes ### Vocabulary Version The standardized vocabulary is central to the creation of an OMOP common data model, and the particular vocabulary version can have a big impact on the resulting dataset. In addition to determining which standard concept(s) are used to represent a given source concept, the domain of the standard concept also determines which table that record will appear in. The OHDSI standardized vocabulary is released twice per year, and our goal is to remain closely aligned with these updates. Going forward, we plan to incorporate vocabulary updates on a regular basis, typically with a short lag to allow for ETL updates, validation, and testing prior to release. To verify which version of the Athena vocabulary a particular STARR-OMOP dataset is using, check the `vocabulary_version` field on the `cdm_source` table. For projects that require a static version of OMOP using a specific vocabulary, we recommend creating a copy of the specific STARR-OMOP dataset in your own Nero GCP project to ensure long-term reproducibility of analyses. ### Rationale for updating `source_value` fields To improve transparency and support diverse research needs, OMOP `*_source_value` fields are now represented as JSON strings that include both the original source value and contextual information about where the data originated in the source system. This change: * Improves transparency in how source data are represented in OMOP * Preserves source-level context used during ETL decision making * Supports research use cases that benefit from source-level granularity beyond standardized concept IDs * Maintains OMOP CDM compliance Because data in a given `source_value` field may originate from multiple locations in Clarity, we use JSON strings to represent both the originating fields and their corresponding values, allowing us to preserve the full source context. Here is an example that highlights the updates to the `source_value` field: | Previous `drug_source_value` field | New `drug_source_value` field | | :---- | :---- | | `73` | `{"medication_id": 214251, "medication_name": "PRENATAL + DHA 28 MG IRON- 975 MCG-200 MG PO CMPK"}` | : {tbl-colwidths="[30,70]"} In this example, the value “73” represents an RxNorm code corresponding to a single ingredient that is only one component of the medication. The updated `drug_source_value` field now includes both the source `medication_id`, which is the primary identifier for the record in the source system, and the human-readable `medication_name`, making it much easier for the researcher to understand the original source record. The new `source_value` fields can still be treated as regular ‘strings’ – and can be used to get a frequency count of the unique values or search for substrings across the entire field. They can also be easily parsed using the JSON functions available in BigQuery SQL to extract specific elements when needed. Note that not all elements will be present in each `source_value` json string; some inspection of the source values is needed to determine what elements are present and would be useful for a given investigation. ### Updates to Date Filtering and Inclusion Logic **Consistency** We improved the implementation of date filtering to ensure that all OMOP clinical event tables are treated consistently. Previously, some filtering logic was applied only to specific tables and used date fields that were not always aligned with the official OMOP event dates. For example, certain `visit_occurrence` records were filtered based on source date fields indicating dates prior to 2000, even though those fields were not the same ones used to populate the OMOP `visit_occurrence_date`. As a result, some visits prior to 2000 still remained, and other clinical event tables were not subject to the same filtering rules. We now apply date filtering consistently across all OMOP clinical event tables so that event dates fall between January 1, 2000 and the date of data extraction from Clarity. These filtering decisions impact which patients and visits appear in OMOP. A patient must have at least one clinical event in an OMOP table to be included in the person table. Similarly, visits must have an associated clinical event to be retained. As a result, the updated filtering rules may change which patients and visits qualify for inclusion in OMOP. **Conservative Inclusion Approach** Our general approach is to favor inclusion unless there is a clear data quality or privacy reason to exclude records. Because different research use cases may require different types of information, we aim to preserve data when possible rather than remove it without a clear rationale. ============================================================ # Released Datasets ============================================================ A reverse-chronological log of STARR-OMOP dataset releases. The most recent release is listed first. Each dataset name below links directly to the Google Cloud Console, pinned to that dataset in your active GCP session. Query costs are billed to your own active billing project. ## Dataset Variants Every release ships in four variants. The suffix on the dataset name identifies each one: - **Core** (no suffix) — full PHI-scrubbed dataset: structured data plus clinical text and text-derived NLP concepts. - _1pcent — a random 1% sample of the core dataset, for testing and sandbox exploration. - _lite — structured data only; clinical text and NLP tables removed. - _1pcent_lite — a random 1% sample of the lite variant. The `_latest` alias always points to the most recent release snapshot. ## Latest Datasets These stable aliases always resolve to the most recent release. Use these for ongoing work — they roll forward automatically with each new release. - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_latest` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_latest` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_lite_latest` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_lite_latest` ## Release History The dated snapshots below are immutable — pin one for reproducible analyses. ### June 2026 Snapshot cut on **June 8, 2026** (`_2026_06_08`). The `_latest` aliases currently resolve to this release. - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_2026_06_08` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_2026_06_08` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_lite_2026_06_08` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_lite_2026_06_08` ### January 2026 Snapshot cut on **January 18, 2026** (`_2026_01_18`). - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_2026_01_18` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_2026_01_18` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_lite_2026_01_18` - `som-rit-phi-starr-prod.starr_omop_cdm54_confidential_1pcent_lite_2026_01_18` ============================================================ # Getting Access to STARR-OMOP v5.4 ============================================================ Launched in Q4 2019, the STARR-OMOP-confidential database provides pre-IRB direct SQL access to a PHI-scrubbed High Risk dataset in the OMOP Common Data Model. It is a non-human-subjects dataset containing complete clinical text as well as clinical concepts derived from text processing, and it supports complex electronic phenotyping. The data is hosted on the Google Cloud Platform BigQuery analytical data warehouse, and researchers access it from their secure Nero workspace. #### Prerequisites Before you start, make sure you have: - A full Stanford **SUNetID**. - A **Stanford PI affiliation**. A Stanford PI must sponsor your access. In exceptional cases, Stanford Directors and C-suite executives can act as PI. #### Access Steps Steps 1 and 2 can be done in parallel. 1. **Sign the Data Privacy Attestation (DPA).** Open the Data Privacy Attestation form, click **New**, and under **Project Type** select **"STARR Nav deID data"**. ("Nav" stands for Navigator, a collection of pre-IRB clinical datasets.) 2. **Request a Nero account.** Request a Nero account and specify that you are requesting access for **STARR-OMOP-confidential**. A Stanford PI affiliation is required, and you will need a Nero GCP account. 3. **Wait for account provisioning.** Once your Nero project has been created, you will receive an email from the Stanford Research Computing Center (SRCC) confirming that access has been granted, along with some introductory information. 4. **Email the STARR-OMOP support team** to request the dataset in BigQuery. Include your **Nero GCP project name** and your **PI's ORCID**. Email starr-omop-support@stanford.edu with the exact subject line: > Requesting STARR-OMOP-confidential data in BigQuery #### Which Dataset Do I Need? If you are doing population health research or a network study, you likely never need identified data — use **STARR-OMOP-confidential** or **STARR-OMOP-confidential-lite** (the lite dataset has no clinical text in the NOTE table). A limited data set or human-subject data in the OMOP CDM is available through a data services consultation request. #### Contacts & Links - **Support:** starr-omop-support@stanford.edu - **Data Privacy Attestation:** redcap.stanford.edu - **Nero account request:** nero-docs.stanford.edu - **Consultation request:** starr.stanford.edu/consultation-services ============================================================ # OMOP Data Dictionary Every STARR-OMOP CDM v5.4 table and field in one searchable page, downloadable as an Excel workbook. ============================================================ Every table and field in the OMOP CDM v5.4 implementation, in one searchable page. Start in **All Fields** to search every table at once, or pick a single table from the list. Each one is a grid: search it, filter any column from the box under its header, click a header to sort, choose which columns to show, group the rows, click a long description to expand it, click a row for its full detail, and download whatever you have filtered down to as CSV. Take the whole thing away as an Excel workbook with the button below. Download as Excel (.xlsx) ## What this describes These definitions describe the **OMOP CDM v5.4** schema as defined in the dbt models, not the contents of any one released dataset. Individual released datasets (de-identified, limited, full) share this schema but differ in which rows and values they contain. | | | |---|---| | Data model | OMOP CDM v5.4 | | Source repository | https://github.com/susom/starr-data-lake.git | | Source branch | main | | Source commit | 3541247 | | Source commit date | 2026-08-25 | | Source path | dbt/omop_cdm54/models/baseline | | Generated by | scripts/generate_exports.py | | Tables | 43 | | Fields | 504 | No field has been added, retyped or dropped since 2026-08-20. ### Columns | | | |---|---| | **Table** | Table the field belongs to. Links to that table's fields. | | **Category** | Core CDM or Stanford extension (underscore-prefixed tables are Stanford additions). | | **Field** | Column name as defined in the dbt model. | | **Required** | Yes when dbt declares the column a primary key or not null. | | **Type** | BigQuery data type, canonicalised to a single spelling. | | **References** | Tables this field is declared a foreign key to, from the dbt model's constraints. Blank means no foreign key is declared — not necessarily that none exists. | | **Fields** | Number of fields in the table. | | **Description** | Description from the dbt model. | For what each table is for and how Stanford populates it, see OMOP CDM v5.4 Data Model. The fields are here; the narrative is there. --- ## All Fields All 504 fields across 43 tables. Search here to find which table contains a given field. Table Category Field Required Type References Description CARE_SITE Core CDM care_site_id Yes INT64 Unique identifier for each care site. CARE_SITE Core CDM care_site_name No STRING The name of the care site as it appears in the source data. This field is used to identify the specific name or title associated with the care site, formatted as "Care Site Name | Department Specialty." Examples of typical entries include: - "EHC PHARMACY | PHARMACY" - "INFUSION TREATMENT CENTER-SNHC | INFUSION" - "RADIATION THERAPY SPLTY | RADIATION ONCOLOGY" This format combines the department name with its specialty. CARE_SITE Core CDM place_of_service_concept_id No INT64 This field summarizes the typical type of care provided at the site. Examples include Inpatient Hospital (ID: 8717), which covers overnight facilities like Stanford Hospital; Skilled Nursing Facility (ID: 8863), providing rehabilitative and nursing care; Outpatient Hospital on Campus (ID: 8756), representing campus-based outpatient services; Mass Immunization Center (ID: 8858), for mass vaccination programs; Home (ID: 0), representing healthcare in a patient’s residence; and Office (ID: 0), which refers to office-based outpatient care like physician offices Typically, if a care site provides multiple levels of care, assign the `place_of_service_concept_id` that represents the primary or most frequent type of care. For example, if most visits to a care site are inpatient, the `place_of_service_concept_id` should represent "Inpatient Hospital." The VISIT_OCCURRENCE table can further refine specific settings for individual visits. CARE_SITE Core CDM location_id No INT64 The location_id from the LOCATION table representing the physical location of the care site. This ID connects to the LOCATION table to capture the exact address or physical space associated with the care site. CARE_SITE Core CDM care_site_source_value No STRING The identifier of the care site as it appears in the source data. For STARR-OMOP, this is the Epic Clarity department ID. CARE_SITE Core CDM place_of_service_source_value No STRING The source value representing the place of service of the care site as it appears in the original data. This value can reflect specific labels like "Inpatient Hospital," "Office," or "On Campus - Outpatient Hospital" that map to broader `place_of_service_concept_id` categories. CDM_SOURCE Core CDM cdm_source_name Yes STRING Descriptive name for the data source. CDM_SOURCE Core CDM cdm_source_abbreviation Yes STRING Abbreviated name of the data source. CDM_SOURCE Core CDM cdm_holder Yes STRING The organization responsible for the CDM instance. CDM_SOURCE Core CDM source_description No STRING Brief description of the source data. CDM_SOURCE Core CDM source_documentation_reference No STRING Reference or URL for documentation of the source data. CDM_SOURCE Core CDM cdm_etl_reference No STRING Reference or URL for documentation of the ETL process. CDM_SOURCE Core CDM source_release_date Yes DATE The date when the source data was last refreshed or released. CDM_SOURCE Core CDM cdm_release_date Yes DATE The date when the CDM instance was created or last updated. CDM_SOURCE Core CDM cdm_version No STRING OMOP CDM version number (e.g., '5.4.2'). CDM_SOURCE Core CDM cdm_version_concept_id Yes INT64 CONCEPT Concept ID representing the CDM version. For OMOP CDM v5.4, this is 705800. CDM_SOURCE Core CDM vocabulary_version Yes STRING Version of the OMOP Vocabulary used in this CDM instance. COHORT Core CDM cohort_definition_id No INT64 This is the identifier given to the cohort, usually by the ATLAS application. This can be used to link to the cohort_definition table for further information on the programmatic generation of the cohort, however it is not explicitly listed as being a foreign key in the OMOP CDM v5.4 documentation. COHORT Core CDM subject_id No INT64 A unique identifier for the subject associated with the cohort record. Cohort records in the OMOP CDM v5.4 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 corresponding cohort_definition_id record in the Cohort Definition table will define the type of subject through the subject_concept_id field. COHORT Core CDM cohort_start_date No DATE The start date for the time period during which the person is in the cohort. COHORT Core CDM cohort_end_date No DATE The end date for the time period during which the person is in the cohort. COHORT_DEFINITION Core CDM cohort_definition_id No INT64 A unique identifier for each cohort definition. COHORT_DEFINITION Core CDM cohort_definition_name No STRING A short description of the cohort. COHORT_DEFINITION Core CDM cohort_definition_description No STRING A complete description of the cohort. COHORT_DEFINITION Core CDM definition_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type of definition (e.g., Type defining what kind of Cohort Definition the record represents and how the syntax may be executed). COHORT_DEFINITION Core CDM cohort_definition_syntax No STRING Syntax or code to operationalize the Cohort Definition. COHORT_DEFINITION Core CDM subject_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit). COHORT_DEFINITION Core CDM cohort_initiation_date No DATE A date to indicate when the Cohort was initiated in the COHORT table. CONCEPT Core CDM concept_id Yes INT64 A unique identifier for each Concept across all domains. CONCEPT Core CDM concept_name Yes STRING An unambiguous, meaningful and descriptive name for the Concept. CONCEPT Core CDM domain_id Yes STRING DOMAIN The domain_id indicates the domain to which the Concept belongs. The domain_id is a foreign key to the DOMAIN table. CONCEPT Core CDM vocabulary_id Yes STRING VOCABULARY A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted. CONCEPT Core CDM concept_class_id Yes STRING The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. The concept_class_id is a foreign key to the CONCEPT_CLASS table. CONCEPT Core CDM standard_concept No STRING This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are S (Standard Concept) and C (Classification Concept), otherwise the content is NULL. CONCEPT Core CDM concept_code Yes STRING The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies. CONCEPT Core CDM valid_start_date Yes DATE The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. CONCEPT Core CDM valid_end_date Yes DATE The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning the Concept is valid until it becomes deprecated. CONCEPT Core CDM invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. CONCEPT_ANCESTOR Core CDM ancestor_concept_id Yes INT64 CONCEPT The Concept Id for the higher-level concept that forms the ancestor in the relationship. CONCEPT_ANCESTOR Core CDM descendant_concept_id Yes INT64 CONCEPT The Concept Id for the lower-level concept that forms the descendant in the relationship. CONCEPT_ANCESTOR Core CDM min_levels_of_separation Yes INT64 The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. CONCEPT_ANCESTOR Core CDM max_levels_of_separation Yes INT64 The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. CONCEPT_CLASS Core CDM concept_class_id Yes STRING A unique identifier for each concept class in the OMOP CDM. CONCEPT_CLASS Core CDM concept_class_name Yes STRING The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc. CONCEPT_CLASS Core CDM concept_class_concept_id Yes INT64 CONCEPT An identifier for the concept that represents the Concept Class. The concept_class_concept_id is a foreign key to the CONCEPT table. CONCEPT_RELATIONSHIP Core CDM concept_id_1 Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the first Concept in the relationship. CONCEPT_RELATIONSHIP Core CDM concept_id_2 Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the second Concept in the relationship. CONCEPT_RELATIONSHIP Core CDM relationship_id Yes STRING RELATIONSHIP A foreign key to the RELATIONSHIP table indicating the type of relationship between concept_id_1 and concept_id_2. It contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship. The relationship_id defines the nature of the relationship, such as 'is a', 'maps to', 'related to', etc. CONCEPT_RELATIONSHIP Core CDM valid_start_date Yes DATE The date when the Relationship was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. CONCEPT_RELATIONSHIP Core CDM valid_end_date Yes DATE The date when the Relationship is invalidated. The default value is 31-Dec-2099, meaning the Relationship is valid until it becomes deprecated. CONCEPT_RELATIONSHIP Core CDM invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update), or NULL (when the valid_end_date is the default value). CONCEPT_SYNONYM Core CDM concept_id Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the Concept to which the synonym belongs. CONCEPT_SYNONYM Core CDM concept_synonym_name Yes STRING Name of the synonym for the Concept. CONCEPT_SYNONYM Core CDM language_concept_id Yes INT64 CONCEPT Foreign key to the CONCEPT table indicating the language to which the Concept Synonym belongs. CONDITION_ERA Core CDM condition_era_id No INT64 The unique identifier for each condition era. CONDITION_ERA Core CDM person_id No INT64 A foreign key identifier to the person_id in the person table for whom the condition era is recorded. CONDITION_ERA Core CDM condition_concept_id No INT64 A foreign key identifier to the standard concept_id in the concept table for the condition recorded. CONDITION_ERA Core CDM condition_era_start_date No DATE The start date of the condition era. CONDITION_ERA Core CDM condition_era_end_date No DATE The end date of the condition era. CONDITION_ERA Core CDM condition_occurrence_count No INT64 The number of condition occurrences that contributed to this condition era. CONDITION_OCCURRENCE Core CDM condition_occurrence_id Yes INT64 The unique key given to each OMOP condition occurrence record. In STARR-OMOP, this ID is currently NOT stable across releases, so the same condition occurrence will likely have a different ID from one STARR-OMOP release to the next. CONDITION_OCCURRENCE Core CDM person_id No INT64 PERSON A foreign key identifier to the person_id in the person table for whom the condition is recorded. CONDITION_OCCURRENCE Core CDM condition_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the condition recorded. This field is recommended for primary use in analyses and must be used for network studies. Only records whose source values map to concepts with a domain of 'Condition' (or unmapped concepts, aka '0' condition-concept_id) are allowed in this table. CONDITION_OCCURRENCE Core CDM condition_start_date No DATE The date when the condition was recorded. For problem list entries, this is the date the condition was first noted by the patient, or first entered into the problem list if the noted date is not available. See the condition_type_concept_id to identify the record provenance. CONDITION_OCCURRENCE Core CDM condition_start_datetime No DATETIME The date and time when the condition was recorded. For problem list entries, this is the date and time the condition was first noted by the patient, or first entered into the problem list if the noted date and time is not available. See the condition_type_concept_id to identify the record provenance. CONDITION_OCCURRENCE Core CDM condition_end_date No DATE The date when the condition was resolved or removed from the problem list. This field is null for all condition records that did not originate from the problem list (aka billing or encounter diagnoses). See the condition_type_concept_id to identify the record provenance. CONDITION_OCCURRENCE Core CDM condition_end_datetime No DATETIME The date and time when the condition was resolved or removed from the problem list. This field is null for all condition records that did not originate from the problem list (aka billing or encounter diagnoses). See the condition_type_concept_id to identify the record provenance. CONDITION_OCCURRENCE Core CDM condition_type_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the provenance of the condition record, such as 'EHR billing record', 'EHR encounter record', or 'EHR problem list'. CONDITION_OCCURRENCE Core CDM condition_status_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the status of the condition record, such as 'primary diagnosis' or 'admission diagnosis', where available. CONDITION_OCCURRENCE Core CDM stop_reason No STRING The reason the condition is no longer valid. This information is unavailable in our EHR and this field is therefore null for all of STARR-OMOP. CONDITION_OCCURRENCE Core CDM provider_id No INT64 PROVIDER A foreign key identifier to the provider_id in the provider table for the provider associated with the condition record. CONDITION_OCCURRENCE Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier to the visit_occurrence_id in the visit_occurrence table for the visit during which the condition was recorded. CONDITION_OCCURRENCE Core CDM visit_detail_id No INT64 VISIT_DETAIL A foreign key identifier to the visit_detail_id in the visit_detail table for the visit detail during which the condition was recorded. This field is currently not populated in STARR-OMOP. CONDITION_OCCURRENCE Core CDM condition_source_value No STRING The verbatim value of the original condition information as it appears in the source data. In STARR-OMOP, this contains the dx_id (internal identifier), dx_name (description of the condition), and the ICD-9-CM or ICD-10-CM code(s) associated with that dx_id, separated by pipes. Note that there may be multiple ICD codes listed, in which case they will be separated by commas Example: "12345 | Uncontrolled type 2 diabetes mellitus with microalbuminuria, with long-term current use of insulin | E11.29, E11.65, R80.9, Z79.4" CONDITION_OCCURRENCE Core CDM condition_source_concept_id No INT64 CONCEPT A foreign key identifier to the concept_id in the concept table for the condition as it appears in the source data. In STARR-OMOP, this field contains the concept_id corresponding to the ICD-9-CM or ICD-10-CM code associated with the condition if available. There will be one row per individual ICD-9-CM or ICD-10-CM code listed in the condition_source_value as described above. CONDITION_OCCURRENCE Core CDM condition_status_source_value No STRING The verbatim value of the original condition status information as it appears in the source data. In STARR-OMOP, this field is derived from a combination of the primary_dx flag and the source table name, and is not available for all records. COST Core CDM cost_id Yes INT64 A unique identifier for each cost record. One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. COST Core CDM cost_event_id No INT64 A foreign key identifier to the event for which cost is recorded. This could be a procedure, drug exposure, visit, device exposure, measurement, observation, or other event. COST Core CDM cost_domain_id No STRING A foreign key to the predefined domain identifier in the Standardized Vocabularies representing the type of domain to which the cost record belongs. COST Core CDM cost_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type of cost, such as charge, payment, or adjustment. COST Core CDM currency_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the currency, such as USD, EUR, etc. COST Core CDM total_charge No FLOAT64 Overall total amount charged for the services associated with the cost record. COST Core CDM total_cost No FLOAT64 Overall total cost of services associated with the cost record. COST Core CDM total_paid No FLOAT64 Overall total amount paid for the services associated with the cost record. COST Core CDM paid_by_payer No FLOAT64 Total amount contributed and/or reimbursed by the payer for the services associated with the cost record. COST Core CDM paid_by_patient No FLOAT64 Total amount paid by the patient for the services associated with the cost record. COST Core CDM paid_patient_copay No FLOAT64 Total copay amount (fixed amount paid by the patient) for the services associated with the cost record. COST Core CDM paid_patient_coinsurance No FLOAT64 Total coinsurance (percentage of total medical cost covered by the patient - applicable only once patient has reached their deductible amount) for the services associated with the cost record. COST Core CDM paid_patient_deductible No FLOAT64 Total deductible (upfront payment by patient before payer starts covering medical costs) associated with the cost record. COST Core CDM paid_by_primary No FLOAT64 Total amount paid by patient's primary payer for services associated with the cost record. COST Core CDM paid_ingredient_cost No FLOAT64 Total amount charged by the wholesale distributor or manufacturer if cost record reflects a drug cost. COST Core CDM paid_dispensing_fee No FLOAT64 Total amount charged by the pharmacy and the sales tax if cost record reflects a drug cost. COST Core CDM payer_plan_period_id No INT64 A foreign key identifier to the payer_plan_period table. COST Core CDM amount_allowed No FLOAT64 Total amount allowed by the payer for services associated with the cost record. COST Core CDM revenue_code_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the revenue code for services associated with the cost record. Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. COST Core CDM revenue_code_source_value No STRING Revenue code for services associated with the cost record, as recorded in source data. Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. COST Core CDM drg_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the Diagnosis Related Group (DRG) associated with the cost record. Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. COST Core CDM drg_source_value No STRING Diagnosis Related Group for the services associated with the cost record, as recorded in the source data. Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. DEATH Core CDM person_id Yes INT64 PERSON A foreign key to the Person table. The ID of the Person for whom this death record belongs. This field serves as the de facto primary key for the table (validated via dbt `unique` and `not_null` data tests, as the OMOP CDM does not define a formal primary key for the DEATH table), since only one record per person_id is allowed. DEATH Core CDM death_date No DATE The date the Person was deceased, sourced from the Epic EHR system. Populated using priority order: SHC EHR > LPCH EHR. DEATH Core CDM death_datetime No DATETIME The date and time the Person was deceased, if available. If no time information is available or if the time appears in the source data as 00:00:00 (default time value), this field is NULL. The prioritization of death sources is the same as for death_date: SHC EHR > LPCH EHR. DEATH Core CDM death_type_concept_id No INT64 A foreign key to the Type Concept in the Standardized Vocabularies reflecting the source of the DEATH record. Always 32817 (EHR), indicating the death was sourced from the Epic Clarity patient table. DEATH Core CDM cause_concept_id No INT64 A foreign key to the Standard Concept representing the Person's cause of death, if available. This information is not available in STARR-OMOP; always 0 (effectively NULL). DEATH Core CDM cause_source_value No STRING The source code representing the cause of death, if available. This information is not available in STARR-OMOP; always NULL. DEATH Core CDM cause_source_concept_id No INT64 A foreign key to a concept representing the cause-of-death code, if the code belongs to a vocabulary in the OMOP Vocabularies. This information is not available in STARR-OMOP; always 0 (effectively NULL). DEVICE_EXPOSURE Core CDM device_exposure_id Yes INT64 A unique identifier for each device exposure event. DEVICE_EXPOSURE Core CDM person_id Yes INT64 PERSON A foreign key identifier to the person table identifying the person exposed to the device. DEVICE_EXPOSURE Core CDM device_concept_id Yes INT64 CONCEPT A foreign key that refers to a standard device concept identifier in the Vocabulary. The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to. DEVICE_EXPOSURE Core CDM device_exposure_start_date Yes DATE Start date of the device exposure event. DEVICE_EXPOSURE Core CDM device_exposure_start_datetime No DATETIME Datetime for the start of the device exposure event if available in the source data. This is not a required field. DEVICE_EXPOSURE Core CDM device_exposure_end_date No DATE The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if available in the source data. This is not a required field. DEVICE_EXPOSURE Core CDM device_exposure_end_datetime No DATETIME Datetime for the end of the device exposure event if available in the source data. This is not a required field. DEVICE_EXPOSURE Core CDM device_type_concept_id Yes INT64 CONCEPT A foreign key to the predefined Type Concept identifier in the Vocabulary, which denotes the provenance of the record, as in whether the record is from administrative claims or EHR. This is has been set to 44818707 (EHR Detail) for all rows in the device_exposure table. DEVICE_EXPOSURE Core CDM unique_device_id No STRING This is the Unique Device Identification (UDI-DI) number for devices regulated by the FDA. This field is not currently populated in STARR OMOP. DEVICE_EXPOSURE Core CDM production_id No STRING This is the Production Identifier (UDI-PI) portion of the Unique Device Identification. This field is not currently populated in STARR OMOP. DEVICE_EXPOSURE Core CDM quantity No INT64 The number of individual devices used. DEVICE_EXPOSURE Core CDM provider_id No INT64 PROVIDER A foreign key to the provider in the PROVIDER table who is associated with the device_exposure record, e.g. the provider who wrote the prescription or the provider who implanted the device. DEVICE_EXPOSURE Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit in the VISIT_OCCURRENCE table during which the device was prescribed or given. DEVICE_EXPOSURE Core CDM visit_detail_id No INT64 VISIT_DETAIL A foreign key to the visit detail in the VISIT_DETAIL table during which the device was prescribed or given. This is not currently populated in STARR OMOP at the moment. However researchers can use the visit_occurrence_id to link to the visit_detail table and view all visit_detail records associated with said visit_occurrence record. DEVICE_EXPOSURE Core CDM device_source_value No STRING This field houses the verbatim value from the source data representing the device exposure that occurred. DEVICE_EXPOSURE Core CDM device_source_concept_id No INT64 CONCEPT The source CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to. This concept may not necessarily be standard. Please refer to the device_concept_id field for the standard concept. DEVICE_EXPOSURE Core CDM unit_concept_id No INT64 CONCEPT A foreign key to a standard concept identifier for the unit associated with the device exposure, if available in the source data. This is not a required field. DEVICE_EXPOSURE Core CDM unit_source_value No STRING This field houses the verbatim value from the source data representing the unit of the Device. For example, blood transfusions are considered devices and can be given in mL quantities. This is not a required field. DEVICE_EXPOSURE Core CDM unit_source_concept_id No INT64 CONCEPT A foreign key to a concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. Please refer to the unit_concept_id field for the standard concept. This is not a required field. DOMAIN Core CDM domain_id Yes STRING A unique identifier for each domain in the OMOP CDM. DOMAIN Core CDM domain_name Yes STRING The name describing the Domain, e.g. Condition, Procedure, Measurement etc. DOMAIN Core CDM domain_concept_id Yes INT64 An identifier representing the domain concept the DOMAIN record belongs to. The domain_concept_id is a foreign key to the CONCEPT table. DOSE_ERA Core CDM dose_era_id Yes INT64 A unique identifier for each dose_era record. DOSE_ERA Core CDM person_id No INT64 A foreign key identifier to the person table for each dose_era record DOSE_ERA Core CDM drug_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the drug that forms the dose_era record. DOSE_ERA Core CDM unit_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the dose unit associated with the dose_era record. DOSE_ERA Core CDM dose_value No FLOAT64 The numeric value of the dose associated with the dose_era record. DOSE_ERA Core CDM dose_era_start_date No DATE The start date of the dose era associated with the dose_era record. DOSE_ERA Core CDM dose_era_end_date No DATE The end date of the dose era associated with the dose_era record. DRUG_ERA Core CDM drug_era_id Yes INT64 DRUG_ERA Core CDM person_id No INT64 PERSON DRUG_ERA Core CDM drug_concept_id No INT64 CONCEPT DRUG_ERA Core CDM drug_era_start_date No DATE DRUG_ERA Core CDM drug_era_end_date No DATE DRUG_ERA Core CDM drug_exposure_count No INT64 DRUG_ERA Core CDM gap_days No INT64 DRUG_EXPOSURE Core CDM drug_exposure_id Yes INT64 Unique identifier for each drug_exposure. DRUG_EXPOSURE Core CDM person_id No INT64 A foreign key identifier to the person in the person table who is the subject of the visit. DRUG_EXPOSURE Core CDM drug_concept_id No INT64 drug_concept_id DRUG_EXPOSURE Core CDM drug_exposure_start_date No DATE The date the drug was administered, dispensed or ordered DRUG_EXPOSURE Core CDM drug_exposure_start_datetime No DATETIME The datetime the drug was administered, dispensed or ordered DRUG_EXPOSURE Core CDM drug_exposure_end_date No DATE Drug end date, if no end date is available then this is equal to the start date DRUG_EXPOSURE Core CDM drug_exposure_end_datetime No DATETIME Drug end datetime, if no end date is available then this is equal to the start date DRUG_EXPOSURE Core CDM verbatim_end_date No DATE End date as it is shown in the source data DRUG_EXPOSURE Core CDM drug_type_concept_id No INT64 Shows the provenance of the record - e.g. 'EHR Administration', 'EHR Order', 'Patient Reported' or 'EHR Dispense' DRUG_EXPOSURE Core CDM stop_reason No STRING The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. DRUG_EXPOSURE Core CDM refills No INT64 This is filled in for prescriptions only and represents the number of refills at the time of prescription. DRUG_EXPOSURE Core CDM quantity No FLOAT64 The amount of drug received. DRUG_EXPOSURE Core CDM days_supply No INT64 Days supply as found in the source data. If there is no days supply then this is left blank. DRUG_EXPOSURE Core CDM sig No STRING Verbatim instructions for the drug as given by the provider DRUG_EXPOSURE Core CDM route_concept_id No INT64 The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain DRUG_EXPOSURE Core CDM lot_number No STRING Lot number DRUG_EXPOSURE Core CDM provider_id No INT64 The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug. DRUG_EXPOSURE Core CDM visit_occurrence_id No INT64 The Visit during which the drug was prescribed, administered or dispensed. DRUG_EXPOSURE Core CDM visit_detail_id No INT64 The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. DRUG_EXPOSURE Core CDM drug_source_value No STRING This field houses the verbatim value from the source data representing the drug exposure that occurred. In this case it is the in-house shc or lpch medication_id, not RxNorm code. DRUG_EXPOSURE Core CDM drug_source_concept_id No INT64 This is the concept representing the drug source value and may not necessarily be standard. DRUG_EXPOSURE Core CDM route_source_value No STRING This field houses the verbatim value from the source data representing the drug route. DRUG_EXPOSURE Core CDM dose_unit_source_value No STRING This field houses the verbatim value from the source data representing the dose unit of the drug given. DRUG_STRENGTH Core CDM drug_concept_id Yes INT64 CONCEPT Foreign key to the concept_id in CONCEPT table representing the Branded Drug or Clinical Drug Product. DRUG_STRENGTH Core CDM ingredient_concept_id Yes INT64 CONCEPT Foreign key to the concept_id in CONCEPT table representing the active ingredient contained within the drug product. Note that Combination Drugs will have more than one record in this table, one for each active Ingredient. DRUG_STRENGTH Core CDM amount_value No FLOAT64 The numeric value or the amount of active ingredient contained within the drug product. DRUG_STRENGTH Core CDM amount_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the Unit of measure for the amount of active ingredient contained within the drug product. DRUG_STRENGTH Core CDM numerator_value No FLOAT64 The concentration of the active ingredient contained within the drug product. DRUG_STRENGTH Core CDM numerator_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the Unit of measure for the concentration of active ingredient. DRUG_STRENGTH Core CDM denominator_value No FLOAT64 The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.). DRUG_STRENGTH Core CDM denominator_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the representing the denominator unit for the concentration of active ingredient. DRUG_STRENGTH Core CDM box_size No INT64 The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient. DRUG_STRENGTH Core CDM valid_start_date Yes DATE The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. DRUG_STRENGTH Core CDM valid_end_date Yes DATE The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning the Concept is valid until it becomes deprecated. DRUG_STRENGTH Core CDM invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. EPISODE Core CDM episode_id Yes INT64 A unique identifier for each episode. EPISODE Core CDM person_id No INT64 A foreign key identifier to the person table for each episode record. EPISODE Core CDM episode_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the episode. EPISODE Core CDM episode_start_date No DATE The start date of the episode. EPISODE Core CDM episode_start_datetime No DATETIME The start date and time of the episode. EPISODE Core CDM episode_end_date No DATE The end date of the episode. If the episode is ongoing, this field can be NULL. EPISODE Core CDM episode_end_datetime No DATETIME The end date and time of the episode. If the episode is ongoing, this field can be NULL. EPISODE Core CDM episode_parent_id No INT64 An identifier to the parent episode within which this episode occurs. This creates a hierarchical structure of episodes. This field is currently not populated in STARR-OMOP. EPISODE Core CDM episode_number No INT64 A number representing the order of occurrence of the episode within an individual person. This field is currently not populated in STARR-OMOP. EPISODE Core CDM episode_object_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the disease phase, outcome, or other abstraction of which the episode consists. This field is currently set to 0 for all rows in STARR-OMOP. EPISODE Core CDM episode_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of episode. EPISODE Core CDM episode_source_value No STRING The source code for the episode as it appears in the source data. EPISODE Core CDM episode_source_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the source value of the episode. This field is currently set to 0 for all rows in STARR-OMOP. EPISODE_EVENT Core CDM episode_id No INT64 EPISODE A unique identifier for the episode to which this event belongs. EPISODE_EVENT Core CDM event_id No INT64 This field is the primary key of the linked record in the database. For example, if the Episode Event is a Condition Occurrence, then the CONDITION_OCCURRENCE_ID of the linked record goes in this field. EPISODE_EVENT Core CDM episode_event_field_concept_id No INT64 CONCEPT A foreign key to the Standardized Vocabularies that identifies the table and/or field that the event_id (primary key of the linked event record) came from. FACT_RELATIONSHIP Core CDM domain_concept_id_1 Yes INT64 CONCEPT The concept representing the domain of fact 1, from which the corresponding table and field can be inferred. This field identifies which field fact_id_1 originates from (e.g., measurement.measurement_id, person.person_id). Join to the concept table to retrieve the name and other information about the concept. FACT_RELATIONSHIP Core CDM fact_id_1 Yes INT64 The unique identifier for fact 1. Use domain_concept_id_1 to determine which table and field this ID originates from (e.g., measurement_id from measurement table). This field can then be joined to that table to retrieve more information about the fact. FACT_RELATIONSHIP Core CDM domain_concept_id_2 Yes INT64 CONCEPT The concept representing the domain of fact 2, from which the corresponding table and field can be inferred. This field identifies which field fact_id_2 originates from (e.g., measurement.measurement_id, person.person_id). Join to the concept table to retrieve the name and other information about the concept. FACT_RELATIONSHIP Core CDM fact_id_2 Yes INT64 The unique identifier for fact 2. Use domain_concept_id_2 to determine which table and field this ID originates from (e.g., measurement_id from measurement table). This field can then be joined to that table to retrieve more information about the fact. FACT_RELATIONSHIP Core CDM relationship_concept_id Yes INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the relationship between fact 1 and fact 2. Examples include 'systolic to diastolic', 'diastolic to systolic', 'parent to child', 'child to parent'. IMAGE_OCCURRENCE Core CDM image_occurrence_id No INT64 The unique key that is given to an imaging study record. IMAGE_OCCURRENCE Core CDM person_id No INT64 A foreign key identifier to the person in the person table who is the subject of the image occurrence IMAGE_OCCURRENCE Core CDM procedure_occurrence_id No INT64 A foreign key identifier to the OMOP procedure_occurrence table. IMAGE_OCCURRENCE Core CDM visit_occurrence_id No INT64 A foreign key identifier to the OMOP visit_occurrence table IMAGE_OCCURRENCE Core CDM anatomic_site_source_value No STRING Text description of the part of the body examined as appears in the source DICOM metadata. IMAGE_OCCURRENCE Core CDM wadors_uri No STRING A Web Access to DICOM Objects. IMAGE_OCCURRENCE Core CDM local_path No STRING Local path to DICOM Object. IMAGE_OCCURRENCE Core CDM image_occurrence_date No DATE The date the series started. IMAGE_OCCURRENCE Core CDM image_occurrence_datetime No DATETIME The datetime the series started. IMAGE_OCCURRENCE Core CDM image_study_uid No STRING Unique identifier for the study. A study can be made up of multiple series. The combination of study_instance_uid and series_instance_uid is a unique identifier. IMAGE_OCCURRENCE Core CDM image_series_uid No STRING Unique identifier for the series. A series can be made up of multiple images. The combination of study_instance_uid and series_instance_uid is a unique identifier. IMAGE_OCCURRENCE Core CDM modality_source_value No STRING Type of device, process, or method that originally acquired or produced the data used to create the instances (images) in this series as appears in the source DICOM metadata. IMAGE_OCCURRENCE Core CDM _accession_number No STRING Accession number for the series, note that this is not guaranteed to be unique and must be combined with person_id to link between tables IMAGE_OCCURRENCE Core CDM _study_description No STRING Study description as it appears in the DICOM metadata IMAGE_OCCURRENCE Core CDM _series_description No STRING Series description as it appears in the DICOM metadata IMAGE_OCCURRENCE Core CDM _note_id No INT64 A foreign key identifier to the OMOP NOTE table IMAGE_OCCURRENCE Core CDM _number_of_series_related_instances No INT64 Number Composite Object Instances within a specific Series that match the search criteria when performing a Query/Retrieve operation LOCATION Core CDM location_id Yes INT64 A unique identifier for each location in the Location table. LOCATION Core CDM address_1 No STRING The first line of the street address. LOCATION Core CDM address_2 No STRING The second line of the street address. LOCATION Core CDM city No STRING The city of the address. LOCATION Core CDM state No STRING The state of the address. LOCATION Core CDM zip No STRING The 5-digit zip code of the address. LOCATION Core CDM county No STRING The county of the address. LOCATION Core CDM location_source_value No STRING The verbatim value for the location as it shows up in the source. LOCATION Core CDM country_source_value No STRING The verbatim value for the country as it shows up in the source. LOCATION Core CDM country_concept_id No INT64 The standard concept ID representing the country. Join to the concept table for more information. LOCATION Core CDM latitude No FLOAT64 The latitude of the location. LOCATION Core CDM longitude No FLOAT64 The longitude of the location. LOCATION Core CDM _census_block_group No STRING The census block group of the location. MEASUREMENT Core CDM measurement_id Yes INT64 The unique key given to a Measurement record for a Person. This is the primary key for this table. MEASUREMENT Core CDM person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the visit. MEASUREMENT Core CDM measurement_concept_id No INT64 CONCEPT This is the field recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the measurement_source value which represents a measurement MEASUREMENT Core CDM measurement_date No DATE The date of the measurement MEASUREMENT Core CDM measurement_datetime No DATETIME This is the datetime of the measurement. If time is not available the convention is to set the time to midnight (00:00:0000). MEASUREMENT Core CDM measurement_time No STRING This is present for backwards compatibility and will be deprecated in an upcoming OMOP-CDM version. Is it set to NULL for STARR-OMOP MEASUREMENT Core CDM measurement_type_concept_id No INT64 CONCEPT This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources. For STARR-OMOP, it is set to EHR record (concept_id=32817) MEASUREMENT Core CDM operator_concept_id No INT64 CONCEPT Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. This is intended for measurments that are ranges and it is not expected to be populated for most measurements. MEASUREMENT Core CDM value_as_number No FLOAT64 This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic. The relationship for the two records (systolic/diastolic) is captured in the FACT_RELATIONSHIP table. MEASUREMENT Core CDM value_as_concept_id No INT64 CONCEPT If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the 'Meas Value' domain. (e.g. 'normal', 'abnormal', 'positive', 'negative', 'detected', 'not detected', etc.) MEASUREMENT Core CDM unit_concept_id No INT64 CONCEPT This concept represents the mapping of the UNIT_SOURCE_VALUE column. It is mapped to the Unit domain that best represents the unit as given in the source data MEASUREMENT Core CDM range_low No FLOAT64 This represent the lower bound of the range of the value_as_number as presented in the source date. This data is not always available. Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and will remain NULL if not given. MEASUREMENT Core CDM range_high No FLOAT64 This represent the upper bound of the range of the value_as_number as presented in the source date. This data is not always available. Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and will remain NULL if not given. MEASUREMENT Core CDM provider_id No INT64 PROVIDER The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result. MEASUREMENT Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE The encounter in which the Measurement occurred. MEASUREMENT Core CDM visit_detail_id No INT64 VISIT_DETAIL The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. MEASUREMENT Core CDM measurement_source_value No STRING This field contains the exact value from the source data that represents the measurement that occurred. TODO: Update with more information about the column used. MEASUREMENT Core CDM measurement_source_concept_id No INT64 CONCEPT This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. MEASUREMENT Core CDM unit_source_value No STRING This field contains the exact value from the source data that represents the unit of measurement used. MEASUREMENT Core CDM unit_source_concept_id No INT64 CONCEPT This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. MEASUREMENT Core CDM value_source_value No STRING This field houses the verbatim result value of the Measurement from the source data. This includes numbers (e.g. 5.6), text (e.g. 'normal'), etc. MEASUREMENT Core CDM measurement_event_id No INT64 If the Measurement record is related to another record in the database, this field is the primary key of the linked record. MEASUREMENT Core CDM meas_event_field_concept_id No INT64 CONCEPT If the Measurement record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. METADATA Core CDM metadata_id Yes INT64 The primary key for Metadata table, auto-incremented. At this moment there is a single row in this table so the metadata_id is populated with the number 0. METADATA Core CDM metadata_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the metadata record in question. For example, the concept_id 705800 which represents the metadata concept 'OMOP CDM version 5.4.2' is populated here. METADATA Core CDM metadata_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type concept for the metadata record in question. METADATA Core CDM name No STRING The concept_name for the metadata_concept_id representing the metadata record. METADATA Core CDM value_as_string No STRING This is the string value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have string results, rather, this field is here to house values should they exist. METADATA Core CDM value_as_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the concept_id mapping for result of the Metadata, if applicable and available. METADATA Core CDM value_as_number No FLOAT64 This is the numeric value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have numeric results, rather, this field is here to house values should they exist. METADATA Core CDM metadata_date No DATE The date when the metadata record was added to the dataset. METADATA Core CDM metadata_datetime No DATETIME The datetime when the metadata record was added to the dataset. NOTE Core CDM note_id Yes INT64 A unique identifier for each note in note table. NOTE Core CDM person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the note. NOTE Core CDM note_date No DATE The date when the note was recorded. This field used colesce date fields from multiple date sources. NOTE Core CDM note_datetime No DATETIME The exact date and time when the note was recorded. This field used colesce date fields from multiple date sources. NOTE Core CDM note_type_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that specifies the provenance of the note like EHR. NOTE Core CDM note_class_concept_id No INT64 CONCEPT The standard concept ID representing the note type from multiple note_source_value. Join to the concept table for more information. NOTE Core CDM note_title No STRING The title of the note. This is currently NULL in the OMOP CDM. NOTE Core CDM note_text No STRING The text of the note which was pulled by different rows corresponding to the most recent contact date for that note and concatenating new line characters. NOTE Core CDM encoding_concept_id No INT64 CONCEPT This is the Concept representing the character encoding type. NOTE Core CDM language_concept_id No INT64 CONCEPT The standard concept ID representing the language of the note. NOTE Core CDM provider_id No INT64 PROVIDER The provider_id from the PROVIDER table representing the provider who recorded the note. NOTE Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit_occurrence_id in the VISIT_OCCURRENCE table. not all the notes have a link to a visit_occurrence_id as the pat_csn_id is not always populated. NOTE Core CDM visit_detail_id No INT64 VISIT_DETAIL A foreign key to the visit_detail_id in the VISIT_DETAIL table. Currently NULL in the OMOP CDM. NOTE Core CDM note_source_value No STRING The type of note as it appears in the source data. This field is the note title such as progress_note, telephone encounter, ED notes, etc. NOTE Core CDM note_event_id No INT64 A foreign key to the note_event_id in the NOTE_EVENT table. This field is not populated and it is currently NULL in the OMOP CDM. NOTE Core CDM note_event_field_concept_id No INT64 The standard concept ID representing the note event field. Join to the concept table for more information. This field is not populated and it is currently NULL in the OMOP CDM. NOTE Core CDM _accession_number No STRING The accession number associated with the note, only available for pathology reports and radiology reports for images in the image_occurrence table. NOTE_NLP Core CDM note_nlp_id Yes INT64 A unique identifier for each note_nlp entry. NOTE_NLP Core CDM note_id No INT64 This is the NOTE_ID for the NOTE record the NLP record is associated to. NOTE_NLP Core CDM section_concept_id No INT64 The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID 45875957. NOTE_NLP Core CDM snippet No STRING A small window of text surrounding the term NOTE_NLP Core CDM offset No STRING Character offset of the extracted term in the input note NOTE_NLP Core CDM lexical_variant No STRING Raw text extracted from the NLP tool. NOTE_NLP Core CDM note_nlp_concept_id No INT64 A foreign key to the predefined concept identifier in the concept table reflecting the normalized term output of the NLP pipeline. NOTE_NLP Core CDM note_nlp_source_concept_id No INT64 A foreign key to the predefined concept identifier in the concept table reflecting the source term output of the NLP pipeline. NOTE_NLP Core CDM nlp_system No STRING Name and version of the NLP system that extracted the term. Useful for data provenance. NOTE_NLP Core CDM nlp_date No DATE Date of processing the note using the NLP system. NOTE_NLP Core CDM nlp_datetime No DATETIME Timestamp of processing the note using the NLP system. NOTE_NLP Core CDM term_exists No STRING Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false - Negation = true Subject = [anything other than the patient] Conditional = true/li> Rule_out = true Uncertain = very low certainty or any lower certainties. A complete lack of modifiers would make Term_exists true. NOTE_NLP Core CDM term_temporal No STRING Term_temporal is to indicate if a condition is present or just in the past. The following would be past - History = true Concept_date = anything before the time of the report). NOTE_NLP Core CDM term_modifiers No STRING Various modification qualifiers for the term. Negation = false Subject = patient Conditional = false Rule_out = false Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. OBSERVATION Core CDM observation_id Yes INT64 A unique identifier for each observation in the observations table. OBSERVATION Core CDM person_id No INT64 PERSON The unique identifier for the person to whom the observation belongs. OBSERVATION Core CDM observation_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table representing the observation being made. This field is the primary id for analysis. OBSERVATION Core CDM observation_date No DATE The date when the observation was made, in the format YYYY-MM-DD. For ethnicity background, the date is the latest date from visit occurrence. OBSERVATION Core CDM observation_datetime No DATETIME The exact date and time when the observation was recorded. OBSERVATION Core CDM observation_type_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that specifies the type of observation such as patient reported or EHR OBSERVATION Core CDM value_as_number No FLOAT64 The quantitative value of the observation, represented as a number (float). OBSERVATION Core CDM value_as_string No STRING The qualitative value of the observation, represented as a string such as the categories for ethinicty OBSERVATION Core CDM value_as_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that represents the value of the observation. OBSERVATION Core CDM qualifier_concept_id No INT64 Optional qualifier for the observation, providing additional granularity. Currently all null values OBSERVATION Core CDM unit_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table representing the unit of measurement for the observation such as mL. OBSERVATION Core CDM provider_id No INT64 PROVIDER Foreign key to the provider who made the observation, representing healthcare personnel involved. OBSERVATION Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier for the visit during which the observation was made OBSERVATION Core CDM visit_detail_id No INT64 VISIT_DETAIL A foreign key detailed identifier for the specific visit that generated the observation. OBSERVATION Core CDM observation_source_value No STRING The raw source value for the observation as provided in the source data. OBSERVATION Core CDM observation_source_concept_id No INT64 CONCEPT A foreign key identifier corresponding to the concept_id in the concept table for the observation's source concept in the source data. OBSERVATION Core CDM unit_source_value No STRING The raw source value for the unit of measurement as provided in the source data. OBSERVATION Core CDM qualifier_source_value No STRING The raw source value for the qualifier as provided in the source data, if applicable. OBSERVATION Core CDM value_source_value No STRING The raw value of the observation from the source data. This field houses the verbatim result value of the Observation from the source data. OBSERVATION Core CDM observation_event_id No INT64 If the Observation record is related to another record in the database, this field is the primary key of the linked record. OBSERVATION Core CDM obs_event_field_concept_id No INT64 If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. OBSERVATION_PERIOD Core CDM observation_period_id Yes INT64 The unique key given to each OMOP observation period record. In STARR-OMOP, this ID is currently NOT stable across releases, so the same person's observation period may have a different ID from one STARR-OMOP release to the next. Instead, use the person_id to uniquely identify a given observation period, as each person only has one observation period using our current algorithm for defining observation periods. OBSERVATION_PERIOD Core CDM person_id Yes INT64 OBSERVATION_PERIOD Core CDM observation_period_start_date Yes DATE The date on which the observation period for the person begins. This is calculated as the date of the earliest clinical event recorded for the person in the OMOP CDM tables visit_occurrence, condition_occurrence, procedure_occurrence, measurement, drug_exposure, device_exposure, and observation. OBSERVATION_PERIOD Core CDM observation_period_end_date Yes DATE The date on which the observation period for the person ends. This is calculated as the earliest of the following three dates: 1) patient's death date + 60 day grace period, 2) source data cut date, 3) date of the latest clinical event recorded for the person in the OMOP CDM tables visit_occurrence, condition_occurrence, procedure_occurrence, measurement, drug_exposure, device_exposure, and observation. OBSERVATION_PERIOD Core CDM period_type_concept_id Yes INT64 A foreign key identifier to a standard concept_id in the concept table for the type of observation period. In STARR-OMOP, this is set to 32882, 'Standard algorithm from EHR'. PAYER_PLAN_PERIOD Core CDM payer_plan_period_id Yes INT64 A unique identifier for each record in the payer_plan_period table. PAYER_PLAN_PERIOD Core CDM person_id No INT64 PERSON A foreign key identifier to the person table for the person covered by the plan detailed in each payer_plan_period record. PAYER_PLAN_PERIOD Core CDM payer_plan_period_start_date No DATE Start date of the plan coverage described in each payer_plan_period record. This is obtained from the mem_eff_from_date in the STARR Common shc_payors and lpch_payors tables. PAYER_PLAN_PERIOD Core CDM payer_plan_period_end_date No DATE End date of the plan coverage described in each payer_plan_period record. This is obtained from the mem_eff_to_date in the STARR Common shc_payors and lpch_payors tables. PAYER_PLAN_PERIOD Core CDM payer_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table. Upon mapping payer_concept_id to the standard concept_id in the concept table, this field represents the entity that would reimburse billable services for any provider(s) administering care to the person in each payer_plan_period record. It contains the standard concept obtained after mapping the qrda_sop_code_c field from STARR Common shc_payors and lpch_payors tables to the concept_code field in the concept table. The concept domain is 'Payer' and the vocabulary is 'SOPT'. PAYER_PLAN_PERIOD Core CDM payer_source_value No STRING Payer information as it appears in the source data. The value is represented as an array containing the fin_class_name, qrda_sopt_code_c, and sop_code_name values from the STARR Common shc_payors and lpch_payors tables. PAYER_PLAN_PERIOD Core CDM payer_source_concept_id No INT64 CONCEPT A foreign key identifier to the source concept_id in the concept table. This field represents the entity that would reimburse billable services for any provider(s) administering care to the person in each payer_plan_period record, as it appears in the source data. It contains the source concept obtained after mapping the qrda_sop_code_c field from STARR Common shc_payors and lpch_payors tables to the concept_code field in the concept table. The concept domain is 'Payer' and the vocabulary is 'SOPT'. PAYER_PLAN_PERIOD Core CDM plan_concept_id No INT64 CONCEPT This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in. This is not currently populated in STARR OMOP due to the need for custom mapping. PAYER_PLAN_PERIOD Core CDM plan_source_value No STRING This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in, as detailed in the source data. The value is represented as an array containing the benefit_plan_id and benefit_plan_name values from the STARR Common shc_payors and lpch_payors tables. PAYER_PLAN_PERIOD Core CDM plan_source_concept_id No INT64 CONCEPT This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in, as mapped from the source data. This is not currenlty populated in STARR OMOP due to the need for custom mapping. PAYER_PLAN_PERIOD Core CDM sponsor_concept_id No INT64 CONCEPT This field represents the sponsor who finances the plan detailed in each payer_plan_period record. This includes self-insured, small group health plan and large group health plan. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM sponsor_source_value No STRING This is the plan sponsor as it appears in the source data. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM sponsor_source_concept_id No INT64 CONCEPT This field represents the sponsor of the plan as mapped from the source data. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM family_source_value No STRING The common identifier for all people (often a family) that covered by the same policy. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM stop_reason_concept_id No INT64 CONCEPT This field represents the reason the person left the plan detailed in each payer_plan_period record, if known. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM stop_reason_source_value No STRING This is the plan stop reason as it appears in the source data. We are not populating this in STARR OMOP currently. PAYER_PLAN_PERIOD Core CDM stop_reason_source_concept_id No INT64 CONCEPT This field represents the plan stop reason as mapped from the source data. We are not populating this in STARR OMOP currently. PERSON Core CDM person_id Yes INT64 A unique identifier for each person in the person table. PERSON Core CDM gender_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's sex. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. PERSON Core CDM year_of_birth No INT64 Year of birth of the person, in the format YYYY. The year of birth is extracted from the person's date of birth. PERSON Core CDM month_of_birth No INT64 Month of birth of the person, as an integer. The month of birth is extracted from the person's date of birth. PERSON Core CDM day_of_birth No INT64 Day of birth of the person, as an integer. The day of birth is extracted from the person's date of birth. PERSON Core CDM birth_datetime No DATETIME Date and time of birth of the person. Time defaults to 00:00:00 if unavailable. PERSON Core CDM race_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's race. If multiple races are recorded in the source data for that patient, this field will be set to 0, as there is currently no standard concept for multiple races. See the race_source_value field to determine if the patient has multiple races. PERSON Core CDM ethnicity_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's ethnicity (Hispanic/Latino or Non-Hispanic/Non-Latino). Additional ethnic background information is available in the observation table. PERSON Core CDM location_id No INT64 LOCATION Foreign key to the location in the Location table representing the most recent known address for the patient. PERSON Core CDM provider_id No INT64 PROVIDER Foreign key to the provider in the Provider table representing the patient's most recent primary care provider. PERSON Core CDM care_site_id No INT64 CARE_SITE Foreign key to the care site in the Care Site table representing the patient's most recent known care site. PERSON Core CDM person_source_value No STRING A unique identifier for each person as it appears in the source data. In identified STARR-OMOP, this field contains the patient's medical record number (MRN) and date of birth concatenated with a pipe, ex. "12345678 | 1900-01-01". PERSON Core CDM gender_source_value No STRING The verbatim value for the patient's sex as it appears in the source data. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. PERSON Core CDM gender_source_concept_id No INT64 Foreign key to the concept in the Concept table representing the patient's sex as it appears in the source data. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. PERSON Core CDM race_source_value No STRING The verbatim value for the patient's race as it appears in the source data. If multiple races are recorded in the source data for that patient, then this field will say 'Multiple'. PERSON Core CDM race_source_concept_id No INT64 Foreign key to the concept in the Concept table representing the patient's race as it appears in the source data. PERSON Core CDM ethnicity_source_value No STRING The verbatim value for the patient's ethnicty (Hispanic/Latino or Non-Hispanic/Non-Latino) as it appears in the source data. Additional ethnic background information is available in the observation table. PERSON Core CDM ethnicity_source_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's ethnicity (Hispanic/Latino or Non-Hispanic/Non-Latino) as it appears in the source data. PROCEDURE_OCCURRENCE Core CDM procedure_occurrence_id Yes INT64 The unique key given to a procedure record for a person. PROCEDURE_OCCURRENCE Core CDM person_id No INT64 PERSON The person_id of the person for whom the procedure is recorded. This can be used to join to the person table to find more information about the person PROCEDURE_OCCURRENCE Core CDM procedure_concept_id No INT64 CONCEPT The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure PROCEDURE_OCCURRENCE Core CDM procedure_date No DATE This is the date when the procedure was performed or ordered on the patient. This is the start date of the procedure. PROCEDURE_OCCURRENCE Core CDM procedure_datetime No DATETIME This is the date and time where the procedure was performed / ordered on the patient. PROCEDURE_OCCURRENCE Core CDM procedure_end_date No DATE This is the date where the procedure ended. If not available is set to the same as procedure_date. PROCEDURE_OCCURRENCE Core CDM procedure_end_datetime No DATETIME This is the date and time where the procedure ended. If not available is set to the same as procedure_datetime. PROCEDURE_OCCURRENCE Core CDM procedure_type_concept_id No INT64 CONCEPT This field is used to determine the provenance of the Procedure record. PROCEDURE_OCCURRENCE Core CDM modifier_concept_id No INT64 CONCEPT The modifiers are intended to give additional information about the procedure. In some cases up to 4 modifiers can be associated with a procedure in the source data. In this column we are selecting only the first modifier from the source data. PROCEDURE_OCCURRENCE Core CDM quantity No INT64 This is the quantity of the procedure performed. If not available is set to 1. PROCEDURE_OCCURRENCE Core CDM provider_id No INT64 PROVIDER The provider associated with the procedure record, e.g. the provider who ordered or performed the Procedure. PROCEDURE_OCCURRENCE Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE The visit during which the procedure occurred. PROCEDURE_OCCURRENCE Core CDM visit_detail_id No INT64 VISIT_DETAIL The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Currently it is not populated for this table PROCEDURE_OCCURRENCE Core CDM procedure_source_value No STRING this is the source value as it appears in the source data. Includes a JSON string with the provenance of the data that includes names and codes. PROCEDURE_OCCURRENCE Core CDM procedure_source_concept_id No INT64 This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. PROCEDURE_OCCURRENCE Core CDM modifier_source_value No STRING This field houses the four possible modifiers found in the source data. It is a JSON string with the values of the four possible modifiers PROVIDER Core CDM provider_id Yes INT64 This is the primary key of the table. This is a unique identifier for every provider. It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. PROVIDER Core CDM provider_name No STRING The name of the provider as it appears in the source data PROVIDER Core CDM npi No STRING This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS). PROVIDER Core CDM dea No STRING This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances. PROVIDER Core CDM specialty_concept_id Yes INT64 This is the standardized specialty associated with the provider. For providers with multiple specialties, the first specialty that is listed in Clarity is selected. This field includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists. PROVIDER Core CDM care_site_id No INT64 This is the CARE_SITE_ID for the location that the provider primarily practices in. PROVIDER Core CDM year_of_birth No INT64 Year of birth of the provider PROVIDER Core CDM gender_concept_id No INT64 This is the standardized representation for the provider's sex. 8532 for Female, 8507 for Male. PROVIDER Core CDM provider_source_value No STRING This field contains a combination of the Clarity unique provider identifier and the source data (shc, lpch) (e.g. "12345678 | shc"). This is the field that is used to derive the primary key of this table PROVIDER Core CDM specialty_source_value No STRING This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists. PROVIDER Core CDM specialty_source_concept_id No INT64 The concept ID representing the source value, if available. This may be a custom concept (2,000,000,000 or higher) if the source value is not coded in an OMOP vocabulary. For now this is zero for all providers. PROVIDER Core CDM gender_source_value No STRING This is an integer representing provider's sex as it appears in the source data. 1 for Female, 2 for Male PROVIDER Core CDM gender_source_concept_id No INT64 The concept ID representing the source value, if available. This may be a custom concept (2,000,000,000 or higher) if the source value is not coded in an OMOP vocabulary. For now this is zero for all providers. RELATIONSHIP Core CDM relationship_id Yes STRING The type of relationship captured by the relationship record. RELATIONSHIP Core CDM relationship_name Yes STRING Relationship name. RELATIONSHIP Core CDM is_hierarchical Yes STRING Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not. RELATIONSHIP Core CDM defines_ancestry Yes STRING Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0. RELATIONSHIP Core CDM reverse_relationship_id Yes STRING The identifier for the relationship used to define the reverse relationship between two concepts. RELATIONSHIP Core CDM relationship_concept_id Yes INT64 CONCEPT A foreign key to the CONCEPT table for the unique relationship concept. SOURCE_TO_CONCEPT_MAP Core CDM source_code No STRING The source code being translated into a Standard Concept. SOURCE_TO_CONCEPT_MAP Core CDM source_concept_id No INT64 A foreign key to the Source Concept that is being translated into a Standard Concept. This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings. SOURCE_TO_CONCEPT_MAP Core CDM source_vocabulary_id No STRING A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept. SOURCE_TO_CONCEPT_MAP Core CDM source_code_description No STRING An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the Concept. SOURCE_TO_CONCEPT_MAP Core CDM target_concept_id No INT64 A foreign key to the Standard Concept that the source code is being mapped to. SOURCE_TO_CONCEPT_MAP Core CDM target_vocabulary_id No STRING A foreign key to the VOCABULARY table defining the vocabulary of the target Concept. SOURCE_TO_CONCEPT_MAP Core CDM valid_start_date No DATE The date when the mapping instance was first recorded. SOURCE_TO_CONCEPT_MAP Core CDM valid_end_date No DATE The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. The default value is 31-Dec-2099, meaning the mapping is valid until it becomes deprecated. SOURCE_TO_CONCEPT_MAP Core CDM invalid_reason No STRING Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update), or NULL (when the valid_end_date is the default value). SPECIMEN Core CDM specimen_id Yes INT64 A unique identifier for each specimen record. SPECIMEN Core CDM person_id No INT64 A foreign key identifier to the person table for each specimen record. SPECIMEN Core CDM specimen_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of specimen for the specimen record. SPECIMEN Core CDM specimen_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the provenance of the specimen record, such as it being a fact or observation from an EHR or survey. SPECIMEN Core CDM specimen_date No DATE The date when the specimen was collected from the Person. SPECIMEN Core CDM specimen_datetime No DATETIME The date and time when the specimen was collected from the Person. SPECIMEN Core CDM quantity No FLOAT64 Quantity of the specimen collected. SPECIMEN Core CDM unit_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the unit of measure for the specimen quantity. SPECIMEN Core CDM anatomic_site_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the anatomic site from which the specimen was obtained. SPECIMEN Core CDM disease_status_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the disease status associated with the specimen. SPECIMEN Core CDM specimen_source_id No STRING The identifier for the specimen in the source data. SPECIMEN Core CDM specimen_source_value No STRING The source code for the specimen as it appears in the source data. SPECIMEN Core CDM unit_source_value No STRING The source code for the unit of measure of the specimen quantity as it appears in the source data. SPECIMEN Core CDM anatomic_site_source_value No STRING The source code for the anatomic site of the specimen as it appears in the source data. SPECIMEN Core CDM disease_status_source_value No STRING The source code for the disease status associated with the specimen as it appears in the source data. VISIT_DETAIL Core CDM visit_detail_id Yes INT64 A unique identifier for each visit detail record. VISIT_DETAIL Core CDM person_id No INT64 PERSON A foreign key identifier to the person who is the subject of care during the visit. VISIT_DETAIL Core CDM visit_detail_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the type of visit detail. VISIT_DETAIL Core CDM visit_detail_start_date No DATE The date when the visit detail event started. VISIT_DETAIL Core CDM visit_detail_start_datetime No DATETIME The date and time when the visit detail event started. VISIT_DETAIL Core CDM visit_detail_end_date No DATE The date when the visit detail event ended. VISIT_DETAIL Core CDM visit_detail_end_datetime No DATETIME The date and time when the visit detail event ended. VISIT_DETAIL Core CDM visit_detail_type_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the provenance of the visit detail record. For STARR-OMOP, this is always 'EHR Encounter Record' VISIT_DETAIL Core CDM provider_id No INT64 PROVIDER A foreign key to the provider who is responsible for the visit detail event. VISIT_DETAIL Core CDM care_site_id No INT64 CARE_SITE A foreign key to the care site where the visit detail event occurred. VISIT_DETAIL Core CDM visit_detail_source_value No STRING The source value for the visit detail record. VISIT_DETAIL Core CDM visit_detail_source_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the source of the visit detail record. For STARR-OMOP, this is 0 for all records. VISIT_DETAIL Core CDM admitted_from_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the location of the patient prior to the current visit detail. In STARR-OMOP, this is populated based on the prior department within a given encounter. VISIT_DETAIL Core CDM admitted_from_source_value No STRING The source value for the location of the patient prior to the current visit detail. VISIT_DETAIL Core CDM discharged_to_source_value No STRING The source value for the location of the patient after the current visit detail. VISIT_DETAIL Core CDM discharged_to_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the location of the patient after the current visit detail. In STARR-OMOP, this is populated based on the subsequent department within a given encounter. VISIT_DETAIL Core CDM preceding_visit_detail_id No INT64 A foreign key to the visit detail record that immediately preceded the current visit detail record. VISIT_DETAIL Core CDM parent_visit_detail_id No INT64 A foreign key to the visit detail record that is the parent of the current visit detail record. In STARR-OMOP, this is null for all records. VISIT_DETAIL Core CDM visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit occurrence record that subsumes the visit detail record. VISIT_OCCURRENCE Core CDM visit_occurrence_id Yes INT64 A unique identifier for each visit. This identifier is stable across STARR-OMOP releases. VISIT_OCCURRENCE Core CDM person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the visit. VISIT_OCCURRENCE Core CDM visit_concept_id No INT64 CONCEPT A foreign key identifier to the concept in the concept table representing the visit type (such as inpatient, outpatient, telehealth, etc.). VISIT_OCCURRENCE Core CDM visit_start_date No DATE The date when the visit started. VISIT_OCCURRENCE Core CDM visit_start_datetime No DATETIME The date and time when the visit started. If no time information is available, the time is set to 00:00:00. VISIT_OCCURRENCE Core CDM visit_end_date No DATE The date when the visit ended. If no end date is available, the end date is assumed to be the same as the start date. VISIT_OCCURRENCE Core CDM visit_end_datetime No DATETIME The date and time when the visit ended. If no end datetime is available, the end datetime is assumed to be the same as the start datetime. If no time information is available, the time is set to 00:00:00. VISIT_OCCURRENCE Core CDM visit_type_concept_id No INT64 CONCEPT A foreign key identifier to the concept in the concept table representing the provenance of the visit record. For STARR-OMOP, this is always 'EHR encounter record'. VISIT_OCCURRENCE Core CDM provider_id No INT64 PROVIDER A foreign key identifier to the provider in the provider table who is the main care provider for the patient during the visit. VISIT_OCCURRENCE Core CDM care_site_id No INT64 CARE_SITE A foreign key identifier to the care site in the care site table where the visit occurred. VISIT_OCCURRENCE Core CDM visit_source_value No STRING Descriptors for the visit type as they appear in the source data stored in a JSON. The source fields are encounter type, ADT (admission/discharge/transfer) patient class, hospital admission type, and appointment procedure (aka visit type). Note that not all fields are populated for all visits. VISIT_OCCURRENCE Core CDM visit_source_concept_id No INT64 A foreign key identifier to the concept in the concept table representing the visit type as it appears in the source data. In STARR-OMOP, this is set to 0 as we derive the final visit type concept ID from the source information via an algorithm. VISIT_OCCURRENCE Core CDM admitted_from_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept in the concept table representing the admitting source. VISIT_OCCURRENCE Core CDM admitted_from_source_value No STRING The verbatim value for the admitting source as it appears in the source data. VISIT_OCCURRENCE Core CDM discharged_to_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept in the concept table representing the discharge destination. VISIT_OCCURRENCE Core CDM discharged_to_source_value No STRING The verbatim value for the discharge destination as it appears in the source data. VISIT_OCCURRENCE Core CDM preceding_visit_occurrence_id No INT64 A foreign key identifier to the visit in the visit table that immediately preceded the current visit for that patient. VOCABULARY Core CDM vocabulary_id Yes STRING A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. VOCABULARY Core CDM vocabulary_name Yes STRING The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc. VOCABULARY Core CDM vocabulary_reference No STRING External reference to documentation or available download of the about the vocabulary. VOCABULARY Core CDM vocabulary_version No STRING Version of the Vocabulary as indicated in the source. VOCABULARY Core CDM vocabulary_concept_id Yes INT64 An identifier for the vocabulary that the VOCABULARY record belongs to. The vocabulary_concept_id is a foreign key to the CONCEPT table. _EXTERNAL_DEATH_RECORDS Stanford extension external_death_record_id Yes INT64 Surrogate primary key — sequential integer assigned via ROW_NUMBER(). _EXTERNAL_DEATH_RECORDS Stanford extension person_id Yes INT64 PERSON A foreign key to the Person table identifying the person for whom this external death record exists. _EXTERNAL_DEATH_RECORDS Stanford extension death_date No DATE The death date reported by the external source. _EXTERNAL_DEATH_RECORDS Stanford extension death_datetime No DATETIME The death datetime reported by the external source, if time information is available. NULL when the source only provides a date or the time is 00:00:00. _EXTERNAL_DEATH_RECORDS Stanford extension external_death_record_source No STRING Provenance label identifying the external source of this death record. Known values in production data: - 'Match on California Decedent Registry': CDPH data - 'LADMF': Limited Access Death Master File - 'DMF': Death Master File (tokenized match from DMF data) - 'External Organization': third-party org reports _VARIANT_OCCURRENCE Stanford extension variant_occurrence_id Yes INT64 This is the primary key of the table. This is a unique identifier for every variant occurrence. It is assumed that every variant occurrence with a different unique identifier is in fact a different event and should be treated independently. _VARIANT_OCCURRENCE Stanford extension person_id No INT64 PERSON A foreign key identifier to the person_id in the person table for whom the condition is recorded. _VARIANT_OCCURRENCE Stanford extension visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier to the visit_occurrence_id in the visit_occurrence table for the visit associated with the ordered test. _VARIANT_OCCURRENCE Stanford extension procedure_occurrence_id No INT64 PROCEDURE_OCCURRENCE A foreign key identifier to the OMOP procedure_occurrence table for the procedure order for the variant test. _VARIANT_OCCURRENCE Stanford extension provider_id No INT64 PROVIDER A foreign key identifier to the provider in the provider table who authorized the order for the variant test. _VARIANT_OCCURRENCE Stanford extension order_datetime No DATETIME The datetime when the test was ordered. _VARIANT_OCCURRENCE Stanford extension test_name No STRING The name of the test associated with the variant record. _VARIANT_OCCURRENCE Stanford extension variant_name No STRING The name of the genetic variant identified in the test. _VARIANT_OCCURRENCE Stanford extension variant_type No STRING The variant type, such as 'Simple', 'Pharmacogenomic genotype', 'Negative', etc. _VARIANT_OCCURRENCE Stanford extension assessment No STRING The assessment of the variant, such as 'Detected', 'Not Detected', 'Negative', etc. _VARIANT_OCCURRENCE Stanford extension genome_assembly No STRING The genome assembly used for the variant, such as 'GRCh37', 'GRCh38', 'hg38', etc. _VARIANT_OCCURRENCE Stanford extension chromosome No STRING The chromosome on which the variant is located, such as '1', '2', 'X', 'Y', etc. _VARIANT_OCCURRENCE Stanford extension transcript_ref_seq No STRING The external identifier defining the Transcript Reference Sequence. _VARIANT_OCCURRENCE Stanford extension dna_change No STRING The change at the DNA level relative to the Transcript Reference Sequence. _VARIANT_OCCURRENCE Stanford extension dna_var_type No STRING The descriptive name for the DNA sequence variation type, such as 'Substitution', 'Copy number gain', 'Deletion', etc. _VARIANT_OCCURRENCE Stanford extension amino_acid_change No STRING The change at the amino acid (protein) level caused by the DNA change. _VARIANT_OCCURRENCE Stanford extension variant_molecular_consequence No STRING The descriptive name for the molecular consequence of the variant, such as 'Missense Variant', 'Nonsense', 'Frameshift Variant', etc. _VARIANT_OCCURRENCE Stanford extension genomic_dna_change No STRING The change at the DNA level relative to the Genomic Reference Sequence. _VARIANT_OCCURRENCE Stanford extension allelic_frequency No NUMERIC(18,5) The percentage of all of the reads at this genomic location that were represented by the given allele. For homozygotes it will be close to 100%; for heterozygotes it will be close to 50%. It can be a smaller number when there are mosaics or multiple chromosomes, or mixtures of tumor cells and normal cells. It is stored in the system as a decimal between 0 and 1 - this is calculated by dividing the percentage by 100. _VARIANT_OCCURRENCE Stanford extension copy_number_lower No NUMERIC(9,2) The lower bound of the copy number range for the variant. _VARIANT_OCCURRENCE Stanford extension copy_number_upper No NUMERIC(9,2) The upper bound of the copy number range for the variant. _VARIANT_OCCURRENCE Stanford extension gene_name No STRING The name of the gene associated with the variant record, such as 'POLE', 'TP53', 'CYP2D6', etc. _VARIANT_OCCURRENCE Stanford extension phenotype_spec_var_class No STRING The descriptive name for the phenotype variant class, such as 'Pathogenic', 'Likely Pathogenic', 'Uncertain Significance', etc. _VARIANT_OCCURRENCE Stanford extension interpretation No STRING The full text interpretation associated with the variant record, aggregated from individual interpretation lines. _VARIANT_OCCURRENCE Stanford extension accession_number No STRING The specimen accession numbers associated with the ordered test, stored as a comma-separated string if multiple accession numbers are present. _VARIANT_OCCURRENCE Stanford extension stamp_pipeline_version No STRING The version of the STAMP pipeline used for the test associated with the variant record. _VARIANT_OCCURRENCE Stanford extension specimen_type No STRING The specimen type associated with the order for the variant record, such as 'Blood', 'Tissue/Bone - Biopsy', 'Existing Patient Material', etc. _VARIANT_OCCURRENCE Stanford extension specimen_source No STRING The specimen source associated with the order for the variant record, such as 'Blood, from Venipuncture', 'Saliva', 'Liver', etc. _WHOLE_SLIDE_IMAGING Stanford extension whole_slide_imaging_id Yes INT64 Unique identifier for the whole slide imaging record _WHOLE_SLIDE_IMAGING Stanford extension accession_number Yes STRING Specimen accession number _WHOLE_SLIDE_IMAGING Stanford extension specimen No STRING Specimen identifier _WHOLE_SLIDE_IMAGING Stanford extension block No STRING Block identifier _WHOLE_SLIDE_IMAGING Stanford extension slide No STRING Slide identifier _WHOLE_SLIDE_IMAGING Stanford extension person_id Yes INT64 Reference to the person in the OMOP CDM _WHOLE_SLIDE_IMAGING Stanford extension acquisition_date No DATETIME Date and time when the slide was scanned from the wsi file metadata. This field is null for Aperio Leica slides as these were manually scanned after slides had been created. _WHOLE_SLIDE_IMAGING Stanford extension procedure_start_time No DATETIME Date and time when the associated procedure started. _WHOLE_SLIDE_IMAGING Stanford extension specimen_received_date No DATETIME Date and time when the specimen was received by the lab. Closest date to acquisition_date for the Aperio Leica slides. _WHOLE_SLIDE_IMAGING Stanford extension brand No STRING WSI scanner brand (Philips or Aperio Leica) _WHOLE_SLIDE_IMAGING Stanford extension scanner No STRING Scanner model name _WHOLE_SLIDE_IMAGING Stanford extension mpp No FLOAT64 Microns per pixel - spatial resolution of the scan _WHOLE_SLIDE_IMAGING Stanford extension json_uri No STRING GCP URI to the deidentified JSON metadata file _WHOLE_SLIDE_IMAGING Stanford extension tiff_uri No STRING GCP URI to the deidentified TIFF file _WHOLE_SLIDE_IMAGING Stanford extension specimen_source_category_value No INT64 Specimen source category value _WHOLE_SLIDE_IMAGING Stanford extension specimen_source No STRING Specimen source description _WHOLE_SLIDE_IMAGING Stanford extension specimen_type_category_value No INT64 Specimen type category value _WHOLE_SLIDE_IMAGING Stanford extension specimen_type No STRING Specimen type description _WHOLE_SLIDE_IMAGING Stanford extension spec_task_list No array<struct<task_c int64, task_name string>> List of specimen tasks _WHOLE_SLIDE_IMAGING Stanford extension note_id No INT64 Note_id for associated pathology report. It is possible that a slide link to more than one note when this happens we bring in one line per note. --- ## Tables 43 tables. Click a table name to open its fields. Table Category Fields Description CARE_SITE Core CDM 6 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. CDM_SOURCE Core CDM 11 The CDM_SOURCE table provides information about the source data and the process used to transform the data into the OMOP Common Data Model. COHORT Core CDM 4 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. COHORT_DEFINITION Core CDM 7 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. CONCEPT Core CDM 10 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. CONCEPT_ANCESTOR Core CDM 4 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. CONCEPT_CLASS Core CDM 3 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. CONCEPT_RELATIONSHIP Core CDM 6 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. CONCEPT_SYNONYM Core CDM 3 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. CONDITION_ERA Core CDM 6 CONDITION_OCCURRENCE Core CDM 16 COST Core CDM 22 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. DEATH Core CDM 7 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. DEVICE_EXPOSURE Core CDM 19 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. DOMAIN Core CDM 3 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. DOSE_ERA Core CDM 7 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. DRUG_ERA Core CDM 7 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. DRUG_EXPOSURE Core CDM 23 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. DRUG_STRENGTH Core CDM 12 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. EPISODE Core CDM 13 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. EPISODE_EVENT Core CDM 3 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. FACT_RELATIONSHIP Core CDM 5 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. IMAGE_OCCURRENCE Core CDM 17 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. LOCATION Core CDM 13 The location table represents a generic way to capture physical location or address information of Persons and Care Sites. MEASUREMENT Core CDM 23 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. METADATA Core CDM 9 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). NOTE Core CDM 17 The NOTE table captures unstructured information that was recorded by a provider about a patient in free text notes on a given date. NOTE_NLP Core CDM 14 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. OBSERVATION Core CDM 21 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. OBSERVATION_PERIOD Core CDM 5 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. PAYER_PLAN_PERIOD Core CDM 17 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. PERSON Core CDM 18 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. PROCEDURE_OCCURRENCE Core CDM 16 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. PROVIDER Core CDM 13 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. RELATIONSHIP Core CDM 6 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. SOURCE_TO_CONCEPT_MAP Core CDM 9 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. SPECIMEN Core CDM 15 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. VISIT_DETAIL Core CDM 19 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. VISIT_OCCURRENCE Core CDM 17 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. VOCABULARY Core CDM 5 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. _EXTERNAL_DEATH_RECORDS Stanford extension 5 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. _VARIANT_OCCURRENCE Stanford extension 28 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. _WHOLE_SLIDE_IMAGING Stanford extension 20 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. --- ## 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. Field Required Type References Description care_site_id Yes INT64 Unique identifier for each care site. care_site_name No STRING The name of the care site as it appears in the source data. This field is used to identify the specific name or title associated with the care site, formatted as "Care Site Name | Department Specialty." Examples of typical entries include: - "EHC PHARMACY | PHARMACY" - "INFUSION TREATMENT CENTER-SNHC | INFUSION" - "RADIATION THERAPY SPLTY | RADIATION ONCOLOGY" This format combines the department name with its specialty. place_of_service_concept_id No INT64 This field summarizes the typical type of care provided at the site. Examples include Inpatient Hospital (ID: 8717), which covers overnight facilities like Stanford Hospital; Skilled Nursing Facility (ID: 8863), providing rehabilitative and nursing care; Outpatient Hospital on Campus (ID: 8756), representing campus-based outpatient services; Mass Immunization Center (ID: 8858), for mass vaccination programs; Home (ID: 0), representing healthcare in a patient’s residence; and Office (ID: 0), which refers to office-based outpatient care like physician offices Typically, if a care site provides multiple levels of care, assign the `place_of_service_concept_id` that represents the primary or most frequent type of care. For example, if most visits to a care site are inpatient, the `place_of_service_concept_id` should represent "Inpatient Hospital." The VISIT_OCCURRENCE table can further refine specific settings for individual visits. location_id No INT64 The location_id from the LOCATION table representing the physical location of the care site. This ID connects to the LOCATION table to capture the exact address or physical space associated with the care site. care_site_source_value No STRING The identifier of the care site as it appears in the source data. For STARR-OMOP, this is the Epic Clarity department ID. place_of_service_source_value No STRING The source value representing the place of service of the care site as it appears in the original data. This value can reflect specific labels like "Inpatient Hospital," "Office," or "On Campus - Outpatient Hospital" that map to broader `place_of_service_concept_id` categories. --- ## 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. Field Required Type References Description cdm_source_name Yes STRING Descriptive name for the data source. cdm_source_abbreviation Yes STRING Abbreviated name of the data source. cdm_holder Yes STRING The organization responsible for the CDM instance. source_description No STRING Brief description of the source data. source_documentation_reference No STRING Reference or URL for documentation of the source data. cdm_etl_reference No STRING Reference or URL for documentation of the ETL process. source_release_date Yes DATE The date when the source data was last refreshed or released. cdm_release_date Yes DATE The date when the CDM instance was created or last updated. cdm_version No STRING OMOP CDM version number (e.g., '5.4.2'). cdm_version_concept_id Yes INT64 CONCEPT Concept ID representing the CDM version. For OMOP CDM v5.4, this is 705800. vocabulary_version Yes STRING Version of the OMOP Vocabulary used in this CDM instance. --- ## 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. Field Required Type References Description cohort_definition_id No INT64 This is the identifier given to the cohort, usually by the ATLAS application. This can be used to link to the cohort_definition table for further information on the programmatic generation of the cohort, however it is not explicitly listed as being a foreign key in the OMOP CDM v5.4 documentation. subject_id No INT64 A unique identifier for the subject associated with the cohort record. Cohort records in the OMOP CDM v5.4 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 corresponding cohort_definition_id record in the Cohort Definition table will define the type of subject through the subject_concept_id field. cohort_start_date No DATE The start date for the time period during which the person is in the cohort. cohort_end_date No DATE The end date for the time period during which the person is in the cohort. --- ## 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. Field Required Type References Description cohort_definition_id No INT64 A unique identifier for each cohort definition. cohort_definition_name No STRING A short description of the cohort. cohort_definition_description No STRING A complete description of the cohort. definition_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type of definition (e.g., Type defining what kind of Cohort Definition the record represents and how the syntax may be executed). cohort_definition_syntax No STRING Syntax or code to operationalize the Cohort Definition. subject_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit). cohort_initiation_date No DATE A date to indicate when the Cohort was initiated in the COHORT table. --- ## 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. Field Required Type References Description concept_id Yes INT64 A unique identifier for each Concept across all domains. concept_name Yes STRING An unambiguous, meaningful and descriptive name for the Concept. domain_id Yes STRING DOMAIN The domain_id indicates the domain to which the Concept belongs. The domain_id is a foreign key to the DOMAIN table. vocabulary_id Yes STRING VOCABULARY A foreign key to the VOCABULARY table indicating from which source the Concept has been adapted. concept_class_id Yes STRING The attribute or concept class of the Concept. Examples are ‘Clinical Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. The concept_class_id is a foreign key to the CONCEPT_CLASS table. standard_concept No STRING This flag determines where a Concept is a Standard Concept, i.e. is used in the data, a Classification Concept, or a non-standard Source Concept. The allowable values are S (Standard Concept) and C (Classification Concept), otherwise the content is NULL. concept_code Yes STRING The concept code represents the identifier of the Concept in the source vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that concept codes are not unique across vocabularies. valid_start_date Yes DATE The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. valid_end_date Yes DATE The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning the Concept is valid until it becomes deprecated. invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. --- ## 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. Field Required Type References Description ancestor_concept_id Yes INT64 CONCEPT The Concept Id for the higher-level concept that forms the ancestor in the relationship. descendant_concept_id Yes INT64 CONCEPT The Concept Id for the lower-level concept that forms the descendant in the relationship. min_levels_of_separation Yes INT64 The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. max_levels_of_separation Yes INT64 The maximum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis. --- ## 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. Field Required Type References Description concept_class_id Yes STRING A unique identifier for each concept class in the OMOP CDM. concept_class_name Yes STRING The name describing the Concept Class, e.g. Clinical Finding, Ingredient, etc. concept_class_concept_id Yes INT64 CONCEPT An identifier for the concept that represents the Concept Class. The concept_class_concept_id is a foreign key to the CONCEPT table. --- ## 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. Field Required Type References Description concept_id_1 Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the first Concept in the relationship. concept_id_2 Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the second Concept in the relationship. relationship_id Yes STRING RELATIONSHIP A foreign key to the RELATIONSHIP table indicating the type of relationship between concept_id_1 and concept_id_2. It contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship. The relationship_id defines the nature of the relationship, such as 'is a', 'maps to', 'related to', etc. valid_start_date Yes DATE The date when the Relationship was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. valid_end_date Yes DATE The date when the Relationship is invalidated. The default value is 31-Dec-2099, meaning the Relationship is valid until it becomes deprecated. invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update), or NULL (when the valid_end_date is the default value). --- ## 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. Field Required Type References Description concept_id Yes INT64 CONCEPT A foreign key to the CONCEPT table indicating the Concept to which the synonym belongs. concept_synonym_name Yes STRING Name of the synonym for the Concept. language_concept_id Yes INT64 CONCEPT Foreign key to the CONCEPT table indicating the language to which the Concept Synonym belongs. --- ## CONDITION_ERA 6 fields. Field Required Type References Description condition_era_id No INT64 The unique identifier for each condition era. person_id No INT64 A foreign key identifier to the person_id in the person table for whom the condition era is recorded. condition_concept_id No INT64 A foreign key identifier to the standard concept_id in the concept table for the condition recorded. condition_era_start_date No DATE The start date of the condition era. condition_era_end_date No DATE The end date of the condition era. condition_occurrence_count No INT64 The number of condition occurrences that contributed to this condition era. --- ## CONDITION_OCCURRENCE 16 fields. Field Required Type References Description condition_occurrence_id Yes INT64 The unique key given to each OMOP condition occurrence record. In STARR-OMOP, this ID is currently NOT stable across releases, so the same condition occurrence will likely have a different ID from one STARR-OMOP release to the next. person_id No INT64 PERSON A foreign key identifier to the person_id in the person table for whom the condition is recorded. condition_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the condition recorded. This field is recommended for primary use in analyses and must be used for network studies. Only records whose source values map to concepts with a domain of 'Condition' (or unmapped concepts, aka '0' condition-concept_id) are allowed in this table. condition_start_date No DATE The date when the condition was recorded. For problem list entries, this is the date the condition was first noted by the patient, or first entered into the problem list if the noted date is not available. See the condition_type_concept_id to identify the record provenance. condition_start_datetime No DATETIME The date and time when the condition was recorded. For problem list entries, this is the date and time the condition was first noted by the patient, or first entered into the problem list if the noted date and time is not available. See the condition_type_concept_id to identify the record provenance. condition_end_date No DATE The date when the condition was resolved or removed from the problem list. This field is null for all condition records that did not originate from the problem list (aka billing or encounter diagnoses). See the condition_type_concept_id to identify the record provenance. condition_end_datetime No DATETIME The date and time when the condition was resolved or removed from the problem list. This field is null for all condition records that did not originate from the problem list (aka billing or encounter diagnoses). See the condition_type_concept_id to identify the record provenance. condition_type_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the provenance of the condition record, such as 'EHR billing record', 'EHR encounter record', or 'EHR problem list'. condition_status_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table for the status of the condition record, such as 'primary diagnosis' or 'admission diagnosis', where available. stop_reason No STRING The reason the condition is no longer valid. This information is unavailable in our EHR and this field is therefore null for all of STARR-OMOP. provider_id No INT64 PROVIDER A foreign key identifier to the provider_id in the provider table for the provider associated with the condition record. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier to the visit_occurrence_id in the visit_occurrence table for the visit during which the condition was recorded. visit_detail_id No INT64 VISIT_DETAIL A foreign key identifier to the visit_detail_id in the visit_detail table for the visit detail during which the condition was recorded. This field is currently not populated in STARR-OMOP. condition_source_value No STRING The verbatim value of the original condition information as it appears in the source data. In STARR-OMOP, this contains the dx_id (internal identifier), dx_name (description of the condition), and the ICD-9-CM or ICD-10-CM code(s) associated with that dx_id, separated by pipes. Note that there may be multiple ICD codes listed, in which case they will be separated by commas Example: "12345 | Uncontrolled type 2 diabetes mellitus with microalbuminuria, with long-term current use of insulin | E11.29, E11.65, R80.9, Z79.4" condition_source_concept_id No INT64 CONCEPT A foreign key identifier to the concept_id in the concept table for the condition as it appears in the source data. In STARR-OMOP, this field contains the concept_id corresponding to the ICD-9-CM or ICD-10-CM code associated with the condition if available. There will be one row per individual ICD-9-CM or ICD-10-CM code listed in the condition_source_value as described above. condition_status_source_value No STRING The verbatim value of the original condition status information as it appears in the source data. In STARR-OMOP, this field is derived from a combination of the primary_dx flag and the source table name, and is not available for all records. --- ## 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. Field Required Type References Description cost_id Yes INT64 A unique identifier for each cost record. One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. cost_event_id No INT64 A foreign key identifier to the event for which cost is recorded. This could be a procedure, drug exposure, visit, device exposure, measurement, observation, or other event. cost_domain_id No STRING A foreign key to the predefined domain identifier in the Standardized Vocabularies representing the type of domain to which the cost record belongs. cost_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type of cost, such as charge, payment, or adjustment. currency_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the currency, such as USD, EUR, etc. total_charge No FLOAT64 Overall total amount charged for the services associated with the cost record. total_cost No FLOAT64 Overall total cost of services associated with the cost record. total_paid No FLOAT64 Overall total amount paid for the services associated with the cost record. paid_by_payer No FLOAT64 Total amount contributed and/or reimbursed by the payer for the services associated with the cost record. paid_by_patient No FLOAT64 Total amount paid by the patient for the services associated with the cost record. paid_patient_copay No FLOAT64 Total copay amount (fixed amount paid by the patient) for the services associated with the cost record. paid_patient_coinsurance No FLOAT64 Total coinsurance (percentage of total medical cost covered by the patient - applicable only once patient has reached their deductible amount) for the services associated with the cost record. paid_patient_deductible No FLOAT64 Total deductible (upfront payment by patient before payer starts covering medical costs) associated with the cost record. paid_by_primary No FLOAT64 Total amount paid by patient's primary payer for services associated with the cost record. paid_ingredient_cost No FLOAT64 Total amount charged by the wholesale distributor or manufacturer if cost record reflects a drug cost. paid_dispensing_fee No FLOAT64 Total amount charged by the pharmacy and the sales tax if cost record reflects a drug cost. payer_plan_period_id No INT64 A foreign key identifier to the payer_plan_period table. amount_allowed No FLOAT64 Total amount allowed by the payer for services associated with the cost record. revenue_code_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the revenue code for services associated with the cost record. Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. revenue_code_source_value No STRING Revenue code for services associated with the cost record, as recorded in source data. Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. drg_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the Diagnosis Related Group (DRG) associated with the cost record. Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. drg_source_value No STRING Diagnosis Related Group for the services associated with the cost record, as recorded in the source data. Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. --- ## 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. Field Required Type References Description person_id Yes INT64 PERSON A foreign key to the Person table. The ID of the Person for whom this death record belongs. This field serves as the de facto primary key for the table (validated via dbt `unique` and `not_null` data tests, as the OMOP CDM does not define a formal primary key for the DEATH table), since only one record per person_id is allowed. death_date No DATE The date the Person was deceased, sourced from the Epic EHR system. Populated using priority order: SHC EHR > LPCH EHR. death_datetime No DATETIME The date and time the Person was deceased, if available. If no time information is available or if the time appears in the source data as 00:00:00 (default time value), this field is NULL. The prioritization of death sources is the same as for death_date: SHC EHR > LPCH EHR. death_type_concept_id No INT64 A foreign key to the Type Concept in the Standardized Vocabularies reflecting the source of the DEATH record. Always 32817 (EHR), indicating the death was sourced from the Epic Clarity patient table. cause_concept_id No INT64 A foreign key to the Standard Concept representing the Person's cause of death, if available. This information is not available in STARR-OMOP; always 0 (effectively NULL). cause_source_value No STRING The source code representing the cause of death, if available. This information is not available in STARR-OMOP; always NULL. cause_source_concept_id No INT64 A foreign key to a concept representing the cause-of-death code, if the code belongs to a vocabulary in the OMOP Vocabularies. This information is not available in STARR-OMOP; always 0 (effectively NULL). --- ## 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. Field Required Type References Description device_exposure_id Yes INT64 A unique identifier for each device exposure event. person_id Yes INT64 PERSON A foreign key identifier to the person table identifying the person exposed to the device. device_concept_id Yes INT64 CONCEPT A foreign key that refers to a standard device concept identifier in the Vocabulary. The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to. device_exposure_start_date Yes DATE Start date of the device exposure event. device_exposure_start_datetime No DATETIME Datetime for the start of the device exposure event if available in the source data. This is not a required field. device_exposure_end_date No DATE The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if available in the source data. This is not a required field. device_exposure_end_datetime No DATETIME Datetime for the end of the device exposure event if available in the source data. This is not a required field. device_type_concept_id Yes INT64 CONCEPT A foreign key to the predefined Type Concept identifier in the Vocabulary, which denotes the provenance of the record, as in whether the record is from administrative claims or EHR. This is has been set to 44818707 (EHR Detail) for all rows in the device_exposure table. unique_device_id No STRING This is the Unique Device Identification (UDI-DI) number for devices regulated by the FDA. This field is not currently populated in STARR OMOP. production_id No STRING This is the Production Identifier (UDI-PI) portion of the Unique Device Identification. This field is not currently populated in STARR OMOP. quantity No INT64 The number of individual devices used. provider_id No INT64 PROVIDER A foreign key to the provider in the PROVIDER table who is associated with the device_exposure record, e.g. the provider who wrote the prescription or the provider who implanted the device. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit in the VISIT_OCCURRENCE table during which the device was prescribed or given. visit_detail_id No INT64 VISIT_DETAIL A foreign key to the visit detail in the VISIT_DETAIL table during which the device was prescribed or given. This is not currently populated in STARR OMOP at the moment. However researchers can use the visit_occurrence_id to link to the visit_detail table and view all visit_detail records associated with said visit_occurrence record. device_source_value No STRING This field houses the verbatim value from the source data representing the device exposure that occurred. device_source_concept_id No INT64 CONCEPT The source CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to. This concept may not necessarily be standard. Please refer to the device_concept_id field for the standard concept. unit_concept_id No INT64 CONCEPT A foreign key to a standard concept identifier for the unit associated with the device exposure, if available in the source data. This is not a required field. unit_source_value No STRING This field houses the verbatim value from the source data representing the unit of the Device. For example, blood transfusions are considered devices and can be given in mL quantities. This is not a required field. unit_source_concept_id No INT64 CONCEPT A foreign key to a concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. Please refer to the unit_concept_id field for the standard concept. This is not a required field. --- ## 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. Field Required Type References Description domain_id Yes STRING A unique identifier for each domain in the OMOP CDM. domain_name Yes STRING The name describing the Domain, e.g. Condition, Procedure, Measurement etc. domain_concept_id Yes INT64 An identifier representing the domain concept the DOMAIN record belongs to. The domain_concept_id is a foreign key to the CONCEPT table. --- ## 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. Field Required Type References Description dose_era_id Yes INT64 A unique identifier for each dose_era record. person_id No INT64 A foreign key identifier to the person table for each dose_era record drug_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the drug that forms the dose_era record. unit_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the dose unit associated with the dose_era record. dose_value No FLOAT64 The numeric value of the dose associated with the dose_era record. dose_era_start_date No DATE The start date of the dose era associated with the dose_era record. dose_era_end_date No DATE The end date of the dose era associated with the dose_era record. --- ## 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. Field Required Type References Description drug_era_id Yes INT64 person_id No INT64 PERSON drug_concept_id No INT64 CONCEPT drug_era_start_date No DATE drug_era_end_date No DATE drug_exposure_count No INT64 gap_days No INT64 --- ## 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. Field Required Type References Description drug_exposure_id Yes INT64 Unique identifier for each drug_exposure. person_id No INT64 A foreign key identifier to the person in the person table who is the subject of the visit. drug_concept_id No INT64 drug_concept_id drug_exposure_start_date No DATE The date the drug was administered, dispensed or ordered drug_exposure_start_datetime No DATETIME The datetime the drug was administered, dispensed or ordered drug_exposure_end_date No DATE Drug end date, if no end date is available then this is equal to the start date drug_exposure_end_datetime No DATETIME Drug end datetime, if no end date is available then this is equal to the start date verbatim_end_date No DATE End date as it is shown in the source data drug_type_concept_id No INT64 Shows the provenance of the record - e.g. 'EHR Administration', 'EHR Order', 'Patient Reported' or 'EHR Dispense' stop_reason No STRING The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. refills No INT64 This is filled in for prescriptions only and represents the number of refills at the time of prescription. quantity No FLOAT64 The amount of drug received. days_supply No INT64 Days supply as found in the source data. If there is no days supply then this is left blank. sig No STRING Verbatim instructions for the drug as given by the provider route_concept_id No INT64 The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain lot_number No STRING Lot number provider_id No INT64 The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug. visit_occurrence_id No INT64 The Visit during which the drug was prescribed, administered or dispensed. visit_detail_id No INT64 The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. drug_source_value No STRING This field houses the verbatim value from the source data representing the drug exposure that occurred. In this case it is the in-house shc or lpch medication_id, not RxNorm code. drug_source_concept_id No INT64 This is the concept representing the drug source value and may not necessarily be standard. route_source_value No STRING This field houses the verbatim value from the source data representing the drug route. dose_unit_source_value No STRING This field houses the verbatim value from the source data representing the dose unit of the drug given. --- ## 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. Field Required Type References Description drug_concept_id Yes INT64 CONCEPT Foreign key to the concept_id in CONCEPT table representing the Branded Drug or Clinical Drug Product. ingredient_concept_id Yes INT64 CONCEPT Foreign key to the concept_id in CONCEPT table representing the active ingredient contained within the drug product. Note that Combination Drugs will have more than one record in this table, one for each active Ingredient. amount_value No FLOAT64 The numeric value or the amount of active ingredient contained within the drug product. amount_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the Unit of measure for the amount of active ingredient contained within the drug product. numerator_value No FLOAT64 The concentration of the active ingredient contained within the drug product. numerator_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the Unit of measure for the concentration of active ingredient. denominator_value No FLOAT64 The amount of total liquid (or other divisible product, such as ointment, gel, spray, etc.). denominator_unit_concept_id No INT64 CONCEPT A foreign key to the concept_id in the CONCEPT table representing the representing the denominator unit for the concentration of active ingredient. box_size No INT64 The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient. valid_start_date Yes DATE The date when the Concept was first recorded. The default value is 1-Jan-1970, meaning the Concept has no (known) date of inception. valid_end_date Yes DATE The date when the Concept became invalid because it was deleted or superseded (updated) by a new concept. The default value is 31-Dec-2099, meaning the Concept is valid until it becomes deprecated. invalid_reason No STRING Reason the Concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value. --- ## 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. Field Required Type References Description episode_id Yes INT64 A unique identifier for each episode. person_id No INT64 A foreign key identifier to the person table for each episode record. episode_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the episode. episode_start_date No DATE The start date of the episode. episode_start_datetime No DATETIME The start date and time of the episode. episode_end_date No DATE The end date of the episode. If the episode is ongoing, this field can be NULL. episode_end_datetime No DATETIME The end date and time of the episode. If the episode is ongoing, this field can be NULL. episode_parent_id No INT64 An identifier to the parent episode within which this episode occurs. This creates a hierarchical structure of episodes. This field is currently not populated in STARR-OMOP. episode_number No INT64 A number representing the order of occurrence of the episode within an individual person. This field is currently not populated in STARR-OMOP. episode_object_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the disease phase, outcome, or other abstraction of which the episode consists. This field is currently set to 0 for all rows in STARR-OMOP. episode_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of episode. episode_source_value No STRING The source code for the episode as it appears in the source data. episode_source_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the source value of the episode. This field is currently set to 0 for all rows in STARR-OMOP. --- ## 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. Field Required Type References Description episode_id No INT64 EPISODE A unique identifier for the episode to which this event belongs. event_id No INT64 This field is the primary key of the linked record in the database. For example, if the Episode Event is a Condition Occurrence, then the CONDITION_OCCURRENCE_ID of the linked record goes in this field. episode_event_field_concept_id No INT64 CONCEPT A foreign key to the Standardized Vocabularies that identifies the table and/or field that the event_id (primary key of the linked event record) came from. --- ## 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. Field Required Type References Description domain_concept_id_1 Yes INT64 CONCEPT The concept representing the domain of fact 1, from which the corresponding table and field can be inferred. This field identifies which field fact_id_1 originates from (e.g., measurement.measurement_id, person.person_id). Join to the concept table to retrieve the name and other information about the concept. fact_id_1 Yes INT64 The unique identifier for fact 1. Use domain_concept_id_1 to determine which table and field this ID originates from (e.g., measurement_id from measurement table). This field can then be joined to that table to retrieve more information about the fact. domain_concept_id_2 Yes INT64 CONCEPT The concept representing the domain of fact 2, from which the corresponding table and field can be inferred. This field identifies which field fact_id_2 originates from (e.g., measurement.measurement_id, person.person_id). Join to the concept table to retrieve the name and other information about the concept. fact_id_2 Yes INT64 The unique identifier for fact 2. Use domain_concept_id_2 to determine which table and field this ID originates from (e.g., measurement_id from measurement table). This field can then be joined to that table to retrieve more information about the fact. relationship_concept_id Yes INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the relationship between fact 1 and fact 2. Examples include 'systolic to diastolic', 'diastolic to systolic', 'parent to child', 'child to parent'. --- ## 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. Field Required Type References Description image_occurrence_id No INT64 The unique key that is given to an imaging study record. person_id No INT64 A foreign key identifier to the person in the person table who is the subject of the image occurrence procedure_occurrence_id No INT64 A foreign key identifier to the OMOP procedure_occurrence table. visit_occurrence_id No INT64 A foreign key identifier to the OMOP visit_occurrence table anatomic_site_source_value No STRING Text description of the part of the body examined as appears in the source DICOM metadata. wadors_uri No STRING A Web Access to DICOM Objects. local_path No STRING Local path to DICOM Object. image_occurrence_date No DATE The date the series started. image_occurrence_datetime No DATETIME The datetime the series started. image_study_uid No STRING Unique identifier for the study. A study can be made up of multiple series. The combination of study_instance_uid and series_instance_uid is a unique identifier. image_series_uid No STRING Unique identifier for the series. A series can be made up of multiple images. The combination of study_instance_uid and series_instance_uid is a unique identifier. modality_source_value No STRING Type of device, process, or method that originally acquired or produced the data used to create the instances (images) in this series as appears in the source DICOM metadata. _accession_number No STRING Accession number for the series, note that this is not guaranteed to be unique and must be combined with person_id to link between tables _study_description No STRING Study description as it appears in the DICOM metadata _series_description No STRING Series description as it appears in the DICOM metadata _note_id No INT64 A foreign key identifier to the OMOP NOTE table _number_of_series_related_instances No INT64 Number Composite Object Instances within a specific Series that match the search criteria when performing a Query/Retrieve operation --- ## LOCATION The location table represents a generic way to capture physical location or address information of Persons and Care Sites. 13 fields. Field Required Type References Description location_id Yes INT64 A unique identifier for each location in the Location table. address_1 No STRING The first line of the street address. address_2 No STRING The second line of the street address. city No STRING The city of the address. state No STRING The state of the address. zip No STRING The 5-digit zip code of the address. county No STRING The county of the address. location_source_value No STRING The verbatim value for the location as it shows up in the source. country_source_value No STRING The verbatim value for the country as it shows up in the source. country_concept_id No INT64 The standard concept ID representing the country. Join to the concept table for more information. latitude No FLOAT64 The latitude of the location. longitude No FLOAT64 The longitude of the location. _census_block_group No STRING The census block group of the location. --- ## 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. Field Required Type References Description measurement_id Yes INT64 The unique key given to a Measurement record for a Person. This is the primary key for this table. person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the visit. measurement_concept_id No INT64 CONCEPT This is the field recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the measurement_source value which represents a measurement measurement_date No DATE The date of the measurement measurement_datetime No DATETIME This is the datetime of the measurement. If time is not available the convention is to set the time to midnight (00:00:0000). measurement_time No STRING This is present for backwards compatibility and will be deprecated in an upcoming OMOP-CDM version. Is it set to NULL for STARR-OMOP measurement_type_concept_id No INT64 CONCEPT This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources. For STARR-OMOP, it is set to EHR record (concept_id=32817) operator_concept_id No INT64 CONCEPT Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. This is intended for measurments that are ranges and it is not expected to be populated for most measurements. value_as_number No FLOAT64 This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic. The relationship for the two records (systolic/diastolic) is captured in the FACT_RELATIONSHIP table. value_as_concept_id No INT64 CONCEPT If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the 'Meas Value' domain. (e.g. 'normal', 'abnormal', 'positive', 'negative', 'detected', 'not detected', etc.) unit_concept_id No INT64 CONCEPT This concept represents the mapping of the UNIT_SOURCE_VALUE column. It is mapped to the Unit domain that best represents the unit as given in the source data range_low No FLOAT64 This represent the lower bound of the range of the value_as_number as presented in the source date. This data is not always available. Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and will remain NULL if not given. range_high No FLOAT64 This represent the upper bound of the range of the value_as_number as presented in the source date. This data is not always available. Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are provided by the source and will remain NULL if not given. provider_id No INT64 PROVIDER The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result. visit_occurrence_id No INT64 VISIT_OCCURRENCE The encounter in which the Measurement occurred. visit_detail_id No INT64 VISIT_DETAIL The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. measurement_source_value No STRING This field contains the exact value from the source data that represents the measurement that occurred. TODO: Update with more information about the column used. measurement_source_concept_id No INT64 CONCEPT This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. unit_source_value No STRING This field contains the exact value from the source data that represents the unit of measurement used. unit_source_concept_id No INT64 CONCEPT This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. value_source_value No STRING This field houses the verbatim result value of the Measurement from the source data. This includes numbers (e.g. 5.6), text (e.g. 'normal'), etc. measurement_event_id No INT64 If the Measurement record is related to another record in the database, this field is the primary key of the linked record. meas_event_field_concept_id No INT64 CONCEPT If the Measurement record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. --- ## 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. Field Required Type References Description metadata_id Yes INT64 The primary key for Metadata table, auto-incremented. At this moment there is a single row in this table so the metadata_id is populated with the number 0. metadata_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the metadata record in question. For example, the concept_id 705800 which represents the metadata concept 'OMOP CDM version 5.4.2' is populated here. metadata_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the type concept for the metadata record in question. name No STRING The concept_name for the metadata_concept_id representing the metadata record. value_as_string No STRING This is the string value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have string results, rather, this field is here to house values should they exist. value_as_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the concept_id mapping for result of the Metadata, if applicable and available. value_as_number No FLOAT64 This is the numeric value of the result of the Metadata, if applicable and available. It is not expected that all Metadata will have numeric results, rather, this field is here to house values should they exist. metadata_date No DATE The date when the metadata record was added to the dataset. metadata_datetime No DATETIME The datetime when the metadata record was added to the dataset. --- ## 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. Field Required Type References Description note_id Yes INT64 A unique identifier for each note in note table. person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the note. note_date No DATE The date when the note was recorded. This field used colesce date fields from multiple date sources. note_datetime No DATETIME The exact date and time when the note was recorded. This field used colesce date fields from multiple date sources. note_type_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that specifies the provenance of the note like EHR. note_class_concept_id No INT64 CONCEPT The standard concept ID representing the note type from multiple note_source_value. Join to the concept table for more information. note_title No STRING The title of the note. This is currently NULL in the OMOP CDM. note_text No STRING The text of the note which was pulled by different rows corresponding to the most recent contact date for that note and concatenating new line characters. encoding_concept_id No INT64 CONCEPT This is the Concept representing the character encoding type. language_concept_id No INT64 CONCEPT The standard concept ID representing the language of the note. provider_id No INT64 PROVIDER The provider_id from the PROVIDER table representing the provider who recorded the note. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit_occurrence_id in the VISIT_OCCURRENCE table. not all the notes have a link to a visit_occurrence_id as the pat_csn_id is not always populated. visit_detail_id No INT64 VISIT_DETAIL A foreign key to the visit_detail_id in the VISIT_DETAIL table. Currently NULL in the OMOP CDM. note_source_value No STRING The type of note as it appears in the source data. This field is the note title such as progress_note, telephone encounter, ED notes, etc. note_event_id No INT64 A foreign key to the note_event_id in the NOTE_EVENT table. This field is not populated and it is currently NULL in the OMOP CDM. note_event_field_concept_id No INT64 The standard concept ID representing the note event field. Join to the concept table for more information. This field is not populated and it is currently NULL in the OMOP CDM. _accession_number No STRING The accession number associated with the note, only available for pathology reports and radiology reports for images in the image_occurrence table. --- ## 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. Field Required Type References Description note_nlp_id Yes INT64 A unique identifier for each note_nlp entry. note_id No INT64 This is the NOTE_ID for the NOTE record the NLP record is associated to. section_concept_id No INT64 The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship ‘Subsumes’ to CONCEPT_ID 45875957. snippet No STRING A small window of text surrounding the term offset No STRING Character offset of the extracted term in the input note lexical_variant No STRING Raw text extracted from the NLP tool. note_nlp_concept_id No INT64 A foreign key to the predefined concept identifier in the concept table reflecting the normalized term output of the NLP pipeline. note_nlp_source_concept_id No INT64 A foreign key to the predefined concept identifier in the concept table reflecting the source term output of the NLP pipeline. nlp_system No STRING Name and version of the NLP system that extracted the term. Useful for data provenance. nlp_date No DATE Date of processing the note using the NLP system. nlp_datetime No DATETIME Timestamp of processing the note using the NLP system. term_exists No STRING Term_exists is defined as a flag that indicates if the patient actually has or had the condition. Any of the following modifiers would make Term_exists false - Negation = true Subject = [anything other than the patient] Conditional = true/li> Rule_out = true Uncertain = very low certainty or any lower certainties. A complete lack of modifiers would make Term_exists true. term_temporal No STRING Term_temporal is to indicate if a condition is present or just in the past. The following would be past - History = true Concept_date = anything before the time of the report). term_modifiers No STRING Various modification qualifiers for the term. Negation = false Subject = patient Conditional = false Rule_out = false Uncertain = true or high or moderate or even low (could argue about low). Term_modifiers will concatenate all modifiers for different types of entities (conditions, drugs, labs etc) into one string. Lab values will be saved as one of the modifiers. --- ## 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. Field Required Type References Description observation_id Yes INT64 A unique identifier for each observation in the observations table. person_id No INT64 PERSON The unique identifier for the person to whom the observation belongs. observation_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table representing the observation being made. This field is the primary id for analysis. observation_date No DATE The date when the observation was made, in the format YYYY-MM-DD. For ethnicity background, the date is the latest date from visit occurrence. observation_datetime No DATETIME The exact date and time when the observation was recorded. observation_type_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that specifies the type of observation such as patient reported or EHR value_as_number No FLOAT64 The quantitative value of the observation, represented as a number (float). value_as_string No STRING The qualitative value of the observation, represented as a string such as the categories for ethinicty value_as_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table that represents the value of the observation. qualifier_concept_id No INT64 Optional qualifier for the observation, providing additional granularity. Currently all null values unit_concept_id No INT64 CONCEPT Foreign key to the standard concept in the Concept table representing the unit of measurement for the observation such as mL. provider_id No INT64 PROVIDER Foreign key to the provider who made the observation, representing healthcare personnel involved. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier for the visit during which the observation was made visit_detail_id No INT64 VISIT_DETAIL A foreign key detailed identifier for the specific visit that generated the observation. observation_source_value No STRING The raw source value for the observation as provided in the source data. observation_source_concept_id No INT64 CONCEPT A foreign key identifier corresponding to the concept_id in the concept table for the observation's source concept in the source data. unit_source_value No STRING The raw source value for the unit of measurement as provided in the source data. qualifier_source_value No STRING The raw source value for the qualifier as provided in the source data, if applicable. value_source_value No STRING The raw value of the observation from the source data. This field houses the verbatim result value of the Observation from the source data. observation_event_id No INT64 If the Observation record is related to another record in the database, this field is the primary key of the linked record. obs_event_field_concept_id No INT64 If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from. --- ## 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. Field Required Type References Description observation_period_id Yes INT64 The unique key given to each OMOP observation period record. In STARR-OMOP, this ID is currently NOT stable across releases, so the same person's observation period may have a different ID from one STARR-OMOP release to the next. Instead, use the person_id to uniquely identify a given observation period, as each person only has one observation period using our current algorithm for defining observation periods. person_id Yes INT64 observation_period_start_date Yes DATE The date on which the observation period for the person begins. This is calculated as the date of the earliest clinical event recorded for the person in the OMOP CDM tables visit_occurrence, condition_occurrence, procedure_occurrence, measurement, drug_exposure, device_exposure, and observation. observation_period_end_date Yes DATE The date on which the observation period for the person ends. This is calculated as the earliest of the following three dates: 1) patient's death date + 60 day grace period, 2) source data cut date, 3) date of the latest clinical event recorded for the person in the OMOP CDM tables visit_occurrence, condition_occurrence, procedure_occurrence, measurement, drug_exposure, device_exposure, and observation. period_type_concept_id Yes INT64 A foreign key identifier to a standard concept_id in the concept table for the type of observation period. In STARR-OMOP, this is set to 32882, 'Standard algorithm from EHR'. --- ## 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. Field Required Type References Description payer_plan_period_id Yes INT64 A unique identifier for each record in the payer_plan_period table. person_id No INT64 PERSON A foreign key identifier to the person table for the person covered by the plan detailed in each payer_plan_period record. payer_plan_period_start_date No DATE Start date of the plan coverage described in each payer_plan_period record. This is obtained from the mem_eff_from_date in the STARR Common shc_payors and lpch_payors tables. payer_plan_period_end_date No DATE End date of the plan coverage described in each payer_plan_period record. This is obtained from the mem_eff_to_date in the STARR Common shc_payors and lpch_payors tables. payer_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept_id in the concept table. Upon mapping payer_concept_id to the standard concept_id in the concept table, this field represents the entity that would reimburse billable services for any provider(s) administering care to the person in each payer_plan_period record. It contains the standard concept obtained after mapping the qrda_sop_code_c field from STARR Common shc_payors and lpch_payors tables to the concept_code field in the concept table. The concept domain is 'Payer' and the vocabulary is 'SOPT'. payer_source_value No STRING Payer information as it appears in the source data. The value is represented as an array containing the fin_class_name, qrda_sopt_code_c, and sop_code_name values from the STARR Common shc_payors and lpch_payors tables. payer_source_concept_id No INT64 CONCEPT A foreign key identifier to the source concept_id in the concept table. This field represents the entity that would reimburse billable services for any provider(s) administering care to the person in each payer_plan_period record, as it appears in the source data. It contains the source concept obtained after mapping the qrda_sop_code_c field from STARR Common shc_payors and lpch_payors tables to the concept_code field in the concept table. The concept domain is 'Payer' and the vocabulary is 'SOPT'. plan_concept_id No INT64 CONCEPT This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in. This is not currently populated in STARR OMOP due to the need for custom mapping. plan_source_value No STRING This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in, as detailed in the source data. The value is represented as an array containing the benefit_plan_id and benefit_plan_name values from the STARR Common shc_payors and lpch_payors tables. plan_source_concept_id No INT64 CONCEPT This field represents the specific health benefit plan that the person in each payer_plan_period record is enrolled in, as mapped from the source data. This is not currenlty populated in STARR OMOP due to the need for custom mapping. sponsor_concept_id No INT64 CONCEPT This field represents the sponsor who finances the plan detailed in each payer_plan_period record. This includes self-insured, small group health plan and large group health plan. We are not populating this in STARR OMOP currently. sponsor_source_value No STRING This is the plan sponsor as it appears in the source data. We are not populating this in STARR OMOP currently. sponsor_source_concept_id No INT64 CONCEPT This field represents the sponsor of the plan as mapped from the source data. We are not populating this in STARR OMOP currently. family_source_value No STRING The common identifier for all people (often a family) that covered by the same policy. We are not populating this in STARR OMOP currently. stop_reason_concept_id No INT64 CONCEPT This field represents the reason the person left the plan detailed in each payer_plan_period record, if known. We are not populating this in STARR OMOP currently. stop_reason_source_value No STRING This is the plan stop reason as it appears in the source data. We are not populating this in STARR OMOP currently. stop_reason_source_concept_id No INT64 CONCEPT This field represents the plan stop reason as mapped from the source data. We are not populating this in STARR OMOP currently. --- ## 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. Field Required Type References Description person_id Yes INT64 A unique identifier for each person in the person table. gender_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's sex. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. year_of_birth No INT64 Year of birth of the person, in the format YYYY. The year of birth is extracted from the person's date of birth. month_of_birth No INT64 Month of birth of the person, as an integer. The month of birth is extracted from the person's date of birth. day_of_birth No INT64 Day of birth of the person, as an integer. The day of birth is extracted from the person's date of birth. birth_datetime No DATETIME Date and time of birth of the person. Time defaults to 00:00:00 if unavailable. race_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's race. If multiple races are recorded in the source data for that patient, this field will be set to 0, as there is currently no standard concept for multiple races. See the race_source_value field to determine if the patient has multiple races. ethnicity_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's ethnicity (Hispanic/Latino or Non-Hispanic/Non-Latino). Additional ethnic background information is available in the observation table. location_id No INT64 LOCATION Foreign key to the location in the Location table representing the most recent known address for the patient. provider_id No INT64 PROVIDER Foreign key to the provider in the Provider table representing the patient's most recent primary care provider. care_site_id No INT64 CARE_SITE Foreign key to the care site in the Care Site table representing the patient's most recent known care site. person_source_value No STRING A unique identifier for each person as it appears in the source data. In identified STARR-OMOP, this field contains the patient's medical record number (MRN) and date of birth concatenated with a pipe, ex. "12345678 | 1900-01-01". gender_source_value No STRING The verbatim value for the patient's sex as it appears in the source data. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. gender_source_concept_id No INT64 Foreign key to the concept in the Concept table representing the patient's sex as it appears in the source data. The naming of this field as 'gender' is outdated; it should not be used to study the patient's gender identity. race_source_value No STRING The verbatim value for the patient's race as it appears in the source data. If multiple races are recorded in the source data for that patient, then this field will say 'Multiple'. race_source_concept_id No INT64 Foreign key to the concept in the Concept table representing the patient's race as it appears in the source data. ethnicity_source_value No STRING The verbatim value for the patient's ethnicty (Hispanic/Latino or Non-Hispanic/Non-Latino) as it appears in the source data. Additional ethnic background information is available in the observation table. ethnicity_source_concept_id No INT64 CONCEPT Foreign key to the concept in the Concept table representing the patient's ethnicity (Hispanic/Latino or Non-Hispanic/Non-Latino) as it appears in the source data. --- ## 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. Field Required Type References Description procedure_occurrence_id Yes INT64 The unique key given to a procedure record for a person. person_id No INT64 PERSON The person_id of the person for whom the procedure is recorded. This can be used to join to the person table to find more information about the person procedure_concept_id No INT64 CONCEPT The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure procedure_date No DATE This is the date when the procedure was performed or ordered on the patient. This is the start date of the procedure. procedure_datetime No DATETIME This is the date and time where the procedure was performed / ordered on the patient. procedure_end_date No DATE This is the date where the procedure ended. If not available is set to the same as procedure_date. procedure_end_datetime No DATETIME This is the date and time where the procedure ended. If not available is set to the same as procedure_datetime. procedure_type_concept_id No INT64 CONCEPT This field is used to determine the provenance of the Procedure record. modifier_concept_id No INT64 CONCEPT The modifiers are intended to give additional information about the procedure. In some cases up to 4 modifiers can be associated with a procedure in the source data. In this column we are selecting only the first modifier from the source data. quantity No INT64 This is the quantity of the procedure performed. If not available is set to 1. provider_id No INT64 PROVIDER The provider associated with the procedure record, e.g. the provider who ordered or performed the Procedure. visit_occurrence_id No INT64 VISIT_OCCURRENCE The visit during which the procedure occurred. visit_detail_id No INT64 VISIT_DETAIL The VISIT_DETAIL record during which the Procedure occurred. For example, if the Person was in the ICU at the time of the Procedure the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Currently it is not populated for this table procedure_source_value No STRING this is the source value as it appears in the source data. Includes a JSON string with the provenance of the data that includes names and codes. procedure_source_concept_id No INT64 This is the concept representing the procedure source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Procedure necessary for a given analytic use case. Consider using PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. modifier_source_value No STRING This field houses the four possible modifiers found in the source data. It is a JSON string with the values of the four possible modifiers --- ## 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. Field Required Type References Description provider_id Yes INT64 This is the primary key of the table. This is a unique identifier for every provider. It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. provider_name No STRING The name of the provider as it appears in the source data npi No STRING This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS). dea No STRING This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances. specialty_concept_id Yes INT64 This is the standardized specialty associated with the provider. For providers with multiple specialties, the first specialty that is listed in Clarity is selected. This field includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists. care_site_id No INT64 This is the CARE_SITE_ID for the location that the provider primarily practices in. year_of_birth No INT64 Year of birth of the provider gender_concept_id No INT64 This is the standardized representation for the provider's sex. 8532 for Female, 8507 for Male. provider_source_value No STRING This field contains a combination of the Clarity unique provider identifier and the source data (shc, lpch) (e.g. "12345678 | shc"). This is the field that is used to derive the primary key of this table specialty_source_value No STRING This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists. specialty_source_concept_id No INT64 The concept ID representing the source value, if available. This may be a custom concept (2,000,000,000 or higher) if the source value is not coded in an OMOP vocabulary. For now this is zero for all providers. gender_source_value No STRING This is an integer representing provider's sex as it appears in the source data. 1 for Female, 2 for Male gender_source_concept_id No INT64 The concept ID representing the source value, if available. This may be a custom concept (2,000,000,000 or higher) if the source value is not coded in an OMOP vocabulary. For now this is zero for all providers. --- ## 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. Field Required Type References Description relationship_id Yes STRING The type of relationship captured by the relationship record. relationship_name Yes STRING Relationship name. is_hierarchical Yes STRING Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not. defines_ancestry Yes STRING Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0. reverse_relationship_id Yes STRING The identifier for the relationship used to define the reverse relationship between two concepts. relationship_concept_id Yes INT64 CONCEPT A foreign key to the CONCEPT table for the unique relationship concept. --- ## 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. Field Required Type References Description source_code No STRING The source code being translated into a Standard Concept. source_concept_id No INT64 A foreign key to the Source Concept that is being translated into a Standard Concept. This is either 0 or should be a number above 2 billion, which are the Concepts reserved for site-specific codes and mappings. source_vocabulary_id No STRING A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept. source_code_description No STRING An optional description for the source code. This is included as a convenience to compare the description of the source code to the name of the Concept. target_concept_id No INT64 A foreign key to the Standard Concept that the source code is being mapped to. target_vocabulary_id No STRING A foreign key to the VOCABULARY table defining the vocabulary of the target Concept. valid_start_date No DATE The date when the mapping instance was first recorded. valid_end_date No DATE The date when the mapping instance became invalid because it was deleted or superseded (updated) by a new relationship. The default value is 31-Dec-2099, meaning the mapping is valid until it becomes deprecated. invalid_reason No STRING Reason the mapping instance was invalidated. Possible values are D (deleted), U (replaced with an update), or NULL (when the valid_end_date is the default value). --- ## 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. Field Required Type References Description specimen_id Yes INT64 A unique identifier for each specimen record. person_id No INT64 A foreign key identifier to the person table for each specimen record. specimen_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of specimen for the specimen record. specimen_type_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the provenance of the specimen record, such as it being a fact or observation from an EHR or survey. specimen_date No DATE The date when the specimen was collected from the Person. specimen_datetime No DATETIME The date and time when the specimen was collected from the Person. quantity No FLOAT64 Quantity of the specimen collected. unit_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the unit of measure for the specimen quantity. anatomic_site_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the anatomic site from which the specimen was obtained. disease_status_concept_id No INT64 A foreign key to the predefined concept identifier in the Standardized Vocabularies representing the disease status associated with the specimen. specimen_source_id No STRING The identifier for the specimen in the source data. specimen_source_value No STRING The source code for the specimen as it appears in the source data. unit_source_value No STRING The source code for the unit of measure of the specimen quantity as it appears in the source data. anatomic_site_source_value No STRING The source code for the anatomic site of the specimen as it appears in the source data. disease_status_source_value No STRING The source code for the disease status associated with the specimen as it appears in the source data. --- ## 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. Field Required Type References Description visit_detail_id Yes INT64 A unique identifier for each visit detail record. person_id No INT64 PERSON A foreign key identifier to the person who is the subject of care during the visit. visit_detail_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the type of visit detail. visit_detail_start_date No DATE The date when the visit detail event started. visit_detail_start_datetime No DATETIME The date and time when the visit detail event started. visit_detail_end_date No DATE The date when the visit detail event ended. visit_detail_end_datetime No DATETIME The date and time when the visit detail event ended. visit_detail_type_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the provenance of the visit detail record. For STARR-OMOP, this is always 'EHR Encounter Record' provider_id No INT64 PROVIDER A foreign key to the provider who is responsible for the visit detail event. care_site_id No INT64 CARE_SITE A foreign key to the care site where the visit detail event occurred. visit_detail_source_value No STRING The source value for the visit detail record. visit_detail_source_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the source of the visit detail record. For STARR-OMOP, this is 0 for all records. admitted_from_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the location of the patient prior to the current visit detail. In STARR-OMOP, this is populated based on the prior department within a given encounter. admitted_from_source_value No STRING The source value for the location of the patient prior to the current visit detail. discharged_to_source_value No STRING The source value for the location of the patient after the current visit detail. discharged_to_concept_id No INT64 CONCEPT A foreign key to the predefined concept in the Standardized Vocabularies reflecting the location of the patient after the current visit detail. In STARR-OMOP, this is populated based on the subsequent department within a given encounter. preceding_visit_detail_id No INT64 A foreign key to the visit detail record that immediately preceded the current visit detail record. parent_visit_detail_id No INT64 A foreign key to the visit detail record that is the parent of the current visit detail record. In STARR-OMOP, this is null for all records. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key to the visit occurrence record that subsumes the visit detail record. --- ## 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. Field Required Type References Description visit_occurrence_id Yes INT64 A unique identifier for each visit. This identifier is stable across STARR-OMOP releases. person_id No INT64 PERSON A foreign key identifier to the person in the person table who is the subject of the visit. visit_concept_id No INT64 CONCEPT A foreign key identifier to the concept in the concept table representing the visit type (such as inpatient, outpatient, telehealth, etc.). visit_start_date No DATE The date when the visit started. visit_start_datetime No DATETIME The date and time when the visit started. If no time information is available, the time is set to 00:00:00. visit_end_date No DATE The date when the visit ended. If no end date is available, the end date is assumed to be the same as the start date. visit_end_datetime No DATETIME The date and time when the visit ended. If no end datetime is available, the end datetime is assumed to be the same as the start datetime. If no time information is available, the time is set to 00:00:00. visit_type_concept_id No INT64 CONCEPT A foreign key identifier to the concept in the concept table representing the provenance of the visit record. For STARR-OMOP, this is always 'EHR encounter record'. provider_id No INT64 PROVIDER A foreign key identifier to the provider in the provider table who is the main care provider for the patient during the visit. care_site_id No INT64 CARE_SITE A foreign key identifier to the care site in the care site table where the visit occurred. visit_source_value No STRING Descriptors for the visit type as they appear in the source data stored in a JSON. The source fields are encounter type, ADT (admission/discharge/transfer) patient class, hospital admission type, and appointment procedure (aka visit type). Note that not all fields are populated for all visits. visit_source_concept_id No INT64 A foreign key identifier to the concept in the concept table representing the visit type as it appears in the source data. In STARR-OMOP, this is set to 0 as we derive the final visit type concept ID from the source information via an algorithm. admitted_from_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept in the concept table representing the admitting source. admitted_from_source_value No STRING The verbatim value for the admitting source as it appears in the source data. discharged_to_concept_id No INT64 CONCEPT A foreign key identifier to the standard concept in the concept table representing the discharge destination. discharged_to_source_value No STRING The verbatim value for the discharge destination as it appears in the source data. preceding_visit_occurrence_id No INT64 A foreign key identifier to the visit in the visit table that immediately preceded the current visit for that patient. --- ## 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. Field Required Type References Description vocabulary_id Yes STRING A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. vocabulary_name Yes STRING The name describing the vocabulary, for example, International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS) etc. vocabulary_reference No STRING External reference to documentation or available download of the about the vocabulary. vocabulary_version No STRING Version of the Vocabulary as indicated in the source. vocabulary_concept_id Yes INT64 An identifier for the vocabulary that the VOCABULARY record belongs to. The vocabulary_concept_id is a foreign key to the CONCEPT table. --- ## \_EXTERNAL_DEATH_RECORDS *Stanford extension — not part of the standard OMOP CDM v5.4.* 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. Field Required Type References Description external_death_record_id Yes INT64 Surrogate primary key — sequential integer assigned via ROW_NUMBER(). person_id Yes INT64 PERSON A foreign key to the Person table identifying the person for whom this external death record exists. death_date No DATE The death date reported by the external source. death_datetime No DATETIME The death datetime reported by the external source, if time information is available. NULL when the source only provides a date or the time is 00:00:00. external_death_record_source No STRING Provenance label identifying the external source of this death record. Known values in production data: - 'Match on California Decedent Registry': CDPH data - 'LADMF': Limited Access Death Master File - 'DMF': Death Master File (tokenized match from DMF data) - 'External Organization': third-party org reports --- ## \_VARIANT_OCCURRENCE *Stanford extension — not part of the standard OMOP CDM v5.4.* 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. Field Required Type References Description variant_occurrence_id Yes INT64 This is the primary key of the table. This is a unique identifier for every variant occurrence. It is assumed that every variant occurrence with a different unique identifier is in fact a different event and should be treated independently. person_id No INT64 PERSON A foreign key identifier to the person_id in the person table for whom the condition is recorded. visit_occurrence_id No INT64 VISIT_OCCURRENCE A foreign key identifier to the visit_occurrence_id in the visit_occurrence table for the visit associated with the ordered test. procedure_occurrence_id No INT64 PROCEDURE_OCCURRENCE A foreign key identifier to the OMOP procedure_occurrence table for the procedure order for the variant test. provider_id No INT64 PROVIDER A foreign key identifier to the provider in the provider table who authorized the order for the variant test. order_datetime No DATETIME The datetime when the test was ordered. test_name No STRING The name of the test associated with the variant record. variant_name No STRING The name of the genetic variant identified in the test. variant_type No STRING The variant type, such as 'Simple', 'Pharmacogenomic genotype', 'Negative', etc. assessment No STRING The assessment of the variant, such as 'Detected', 'Not Detected', 'Negative', etc. genome_assembly No STRING The genome assembly used for the variant, such as 'GRCh37', 'GRCh38', 'hg38', etc. chromosome No STRING The chromosome on which the variant is located, such as '1', '2', 'X', 'Y', etc. transcript_ref_seq No STRING The external identifier defining the Transcript Reference Sequence. dna_change No STRING The change at the DNA level relative to the Transcript Reference Sequence. dna_var_type No STRING The descriptive name for the DNA sequence variation type, such as 'Substitution', 'Copy number gain', 'Deletion', etc. amino_acid_change No STRING The change at the amino acid (protein) level caused by the DNA change. variant_molecular_consequence No STRING The descriptive name for the molecular consequence of the variant, such as 'Missense Variant', 'Nonsense', 'Frameshift Variant', etc. genomic_dna_change No STRING The change at the DNA level relative to the Genomic Reference Sequence. allelic_frequency No NUMERIC(18,5) The percentage of all of the reads at this genomic location that were represented by the given allele. For homozygotes it will be close to 100%; for heterozygotes it will be close to 50%. It can be a smaller number when there are mosaics or multiple chromosomes, or mixtures of tumor cells and normal cells. It is stored in the system as a decimal between 0 and 1 - this is calculated by dividing the percentage by 100. copy_number_lower No NUMERIC(9,2) The lower bound of the copy number range for the variant. copy_number_upper No NUMERIC(9,2) The upper bound of the copy number range for the variant. gene_name No STRING The name of the gene associated with the variant record, such as 'POLE', 'TP53', 'CYP2D6', etc. phenotype_spec_var_class No STRING The descriptive name for the phenotype variant class, such as 'Pathogenic', 'Likely Pathogenic', 'Uncertain Significance', etc. interpretation No STRING The full text interpretation associated with the variant record, aggregated from individual interpretation lines. accession_number No STRING The specimen accession numbers associated with the ordered test, stored as a comma-separated string if multiple accession numbers are present. stamp_pipeline_version No STRING The version of the STAMP pipeline used for the test associated with the variant record. specimen_type No STRING The specimen type associated with the order for the variant record, such as 'Blood', 'Tissue/Bone - Biopsy', 'Existing Patient Material', etc. specimen_source No STRING The specimen source associated with the order for the variant record, such as 'Blood, from Venipuncture', 'Saliva', 'Liver', etc. --- ## \_WHOLE_SLIDE_IMAGING *Stanford extension — not part of the standard OMOP CDM v5.4.* 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. Field Required Type References Description whole_slide_imaging_id Yes INT64 Unique identifier for the whole slide imaging record accession_number Yes STRING Specimen accession number specimen No STRING Specimen identifier block No STRING Block identifier slide No STRING Slide identifier person_id Yes INT64 Reference to the person in the OMOP CDM acquisition_date No DATETIME Date and time when the slide was scanned from the wsi file metadata. This field is null for Aperio Leica slides as these were manually scanned after slides had been created. procedure_start_time No DATETIME Date and time when the associated procedure started. specimen_received_date No DATETIME Date and time when the specimen was received by the lab. Closest date to acquisition_date for the Aperio Leica slides. brand No STRING WSI scanner brand (Philips or Aperio Leica) scanner No STRING Scanner model name mpp No FLOAT64 Microns per pixel - spatial resolution of the scan json_uri No STRING GCP URI to the deidentified JSON metadata file tiff_uri No STRING GCP URI to the deidentified TIFF file specimen_source_category_value No INT64 Specimen source category value specimen_source No STRING Specimen source description specimen_type_category_value No INT64 Specimen type category value specimen_type No STRING Specimen type description spec_task_list No array<struct<task_c int64, task_name string>> List of specimen tasks note_id No INT64 Note_id for associated pathology report. It is possible that a slide link to more than one note when this happens we bring in one line per note. ---