User Tools

Site Tools


documentation:cdm:details_of_the_model

This is an old revision of the document!


Table nameDescription
Standardized Vocabularies
CONCEPTThe CONCEPT table contains records that uniquely identify each fundamental unit of meaning used to express clinical information. Concepts are derived from source vocabularies, which represent clinical information across different domains (e.g. conditions, drugs, procedures) through the use of source codes and associated descriptions. Somte concepts are designated as standard concepts, meaning these concepts can be used within the OMOP Common Data Model and within standardized analytics. Each standard concept has a primary domain, which defines the location where the concept would be expected to be observed within OMOP Common Data Model.
VOCABULARYThe VOCABULARY table includes a list of the vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each vocabulary source and includes a descriptive name and other associated attributes for the vocabulary.
DOMAINThe DOMAIN table includes a list of the domains of data elements that are contained within the OMOP common data model. A domain defines the set of allowable concepts for each standardized field. This reference table is populated with a single record for each domain and includes a descriptive name for the Domain.
CONCEPT_CLASSThe CONCEPT_CLASS table includes a list of the classifications used to differentiate concepts within a given vocabulary. This reference table is populated with a single record for each concept class and includes a descriptive name for the concept class.
CONCEPT_RELATIONSHIPThe CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two concepts and the nature of the relationship. The type of relationship is defined in the Relationship table, and is generally classified as hierarchical (parent-child) or non-hierarchical (lateral). All relationships are directional, and each concept relationship is represented twice symmetrically within the concept relationship table. For example, the two SNOMED concepts of ‘Acute myocardial infarction of the anterior wall’ and ‘Acute myocardial infarction’ have two concept relationships: 1- ‘Acute myocardial infarction of the anterior wall’ ‘is a’ ‘Acute myocardial infarction’, and 2- ‘Acute myocardial infarction’ ‘subsumes’ ‘Acute myocardial infarction of the anterior wall’.
RELATIONSHIPThe RELATIONSHIP table provides a reference list of all allowable types of relationships that can be used to associate any two concepts in the concept relationship table. Relationships are classified as hierarchical (parent-child) or non-hierarchical, and are used to determine which concept relationship records should be included in the computation of the concept ancestor table.
CONCEPT_SYNONYMThe CONCEPT_SYNONYM table is used to store alternate names and descriptions for a concept. Each synonym is assigned its own unique identifier and contains the text of a description and the identifier of the concept that it represents.
CONCEPT_ANCESTORThe CONCEPT_ANCESTOR table contains records that define the inferred hierarchical relationships between all standard concepts. The concept ancestor table is fully derived from the concept, CONCEPT_RELATIONSHIP, and relationship tables, whereby all ancestor-descendant relationships can be inferred from traversing all parent-child relationships between standard concepts. The concept ancestor table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and additional levels of lineage. The concept ancestor table enables efficient identification of multi-step hierarchical relationships, such as branded drugs that fall within a therapeutic class or specific diagnosis that are classified within a particular system organ class.
SOURCE_TO_CONCEPT_MAPThe SOURCE_TO_CONCEPT_MAP table is a legacy data structure within the OMOP Common Data Model, recommended for use in extract, transform, and load (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 that can be used to populate the Common Data Model tables. The source to concept map table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.
DRUG_STRENGTHThe DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient within a particular drug product. The drug strength table is a supplemental file to support standardized analysis of drug utilization using concepts from the RxNorm vocabulary. A clinical drug concept which contains multiple active ingredients will result in one drug strength record for each active ingredient.
COHORT_DEFINITIONThe COHORT_DEFINITION table contains records to define each derived cohort through an associated description and syntax. Cohorts are derived elements of a set of subjects that satisfy a given set 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 a OMOP common data model.
ATTRIBUTE_DEFINITIONThe ATTRIBUTE_DEFINITION table contains records to define each attribute through an associated description and syntax. Attributes are derived elements that can be selected or calculated for a subject within a cohort. The ATTRIBUTE_DEFINITION table provides a standardized structure for maintaining the rules governing the calculation of covariates for a subject in a cohort, and can store operational programming code to instantiate the attributes for a given cohort within the OMOP Common Data Model.
Standardized meta-data
CDM_SOURCEThe CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP common data model. If a source database is derived from multiple data feeds, the integration of those disparate sources is expected to be documented in the ETL specifications.
Standardized clinical data
PERSONThe PERSON table contains records that uniquely identify each patient in the source data who has time at-risk to have clinical events recorded within the source systems. A person must have at least one observation period to defined the time-at-risk but may or may not have any clinical events recorded in the other data domains. Each person record has associated demographic attributes which are assumed to be constant for the patient throughout the course of their periods of observation. All other patient-level data domains have a foreign-key reference to the person domain.
OBSERVATION_PERIODThe OBSERVATION_PERIOD table contains records which uniquely define the spans of time for which a person is at-risk to have clinical events recorded within the source systems. One person may have one or more disjoint observation periods, during which times analyses may assume that clinical events would be captured if observed, and outside of which no clinical events may be recorded.
SPECIMENThe SPECIMEN table contains the records identifying each biological sample from a person.
DEATHThe DEATH table contains the clinical event for how and when a person dies. A person can have up to one record if the source systems contain evidence that s/he is deceased. All persons who were alive during all observation periods should not contain any information in the death table.
VISIT_OCCURRENCEThe VISIT_OCCURRENCE table contains the spans of time a person continuously receives medical services from one or more providers at a facility in a given setting within the health care system. Visits are classified into 4 settings: outpatient care, inpatient confinement, emergency room, and long-term care. Persons may transition between these settings over the course of an episode of care. Inpatient visits are defined by the span of time between admission and discharge from a specific hospital facility. Outpatient visits are defined as span of time within a specific provider’s office, which is expected to less than 1 day. Long-term care visits are defined as the span of time a person is treated within a specific long-term care facility.
PROCEDURE_OCCURRENCEThe PROCEDURE_OCCURRENCE table contains records of activities or processes ordered by and/or carried out by a healthcare provider on the patient to have a diagnostic and/or therapeutic purpose.
DRUG_EXPOSUREThe DRUG_EXPOSURE table captures records about the inferred utilization of a biochemical substance with a physiological therapeutic effect when ingested or otherwise introduced into the body. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Drug exposure is inferred from clinical events associated with orders, prescriptions written, pharmacy dispensings, procedural administrations, and other patient-reported information.
DEVICE_EXPOSUREThe DEVICE_EXPOSURE table captures records about a person’s inferred exposure to a foreign physical object or instrument that is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), durable medical equipment and supplies (e.g. bandages, crutches, syringes), and other instruments used in medical procedures (e.g. sutures, defibrillators).
CONDITION_OCCURRENCEThe CONDITION_OCCURRENCE table captures records of a disease or a medical condition based on evaluation by a provider or reported by a patient.
MEASUREMENTA measurement is the capture of a structured value (numerical or categorical) obtained through systematic examination of a person or sample. The MEASUREMENT table captures measurement orders and measurement results. The measurement domain can contain laboratory results, vital signs, or quantitative findings from pathology reports.
NOTE
OBSERVATIONThe OBSERVATION table captures any clinical facts about a patient obtained in the context of examination, questioning or a procedure. The observation domain supports capture of data not represented by other domains, including unstructured measurements, medical history and family history.
FACT_RELATIONSHIPThe FACT_RELATIONSHIP table contains records to detail the relationships between facts within one domain or across two domains, and the nature of the relationship. Examples of types of fact relationships include: person relationships (mother-child linkage), care site relationships (representing the hierarchical organization structure of facilities within health systems), drug exposures provided due to associated indicated condition, devices used during the course of an associated procedure, and measurements derived from an associated specimen. All relationships are directional, and each relationship is represented twice symmetrically within the fact relationship table. For example, two persons (PERSON_ID = 1 is the mother of PERSON_ID = 2) have two fact relationships: 1- ‘PERSON_ID 1’ ‘parent of’ ‘PERSON_ID 2’, and 2-‘PERSON_ID 2’ ‘child of’ ‘PERSON_ID 1’.
Standardized health system data
LOCATION
CARE_SITEThe CARE_SITE table contains a list of uniquely identified physical or organizational units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).
PROVIDERThe PROVIDER table contains a list of uniquely identified health care providers. These are typically physicians and nurses.
Standardized health economics
PAYER_PLAN_PERIODThe PAYER_PLAN_PERIOD table captures records that detail the period of time that a person is continuously enrolled under a specific health plan benefit structure from a given payer. Each Person receiving health care and covered by a health benefits is subject to a Plan defined by the Payer for the Person or her family. For a given benefit policy, there may be one or more Plans that are active for certain periods of time (e.g. before and after the deductible is reached), determining the cost of health services provided.
VISIT_COSTThe VISIT_COST table captures the costs of health visit of a patient which are not itemized to specific procedures, drugs, or devices used within the encounter.
PROCEDURE_COSTThe PROCEDURE_COST table captures the cost of a Procedure performed on a Person. The information about the cost is only derived from the amounts paid for the Procedure.
DRUG_COSTThe DRUG_COST table captures records indicating the cost of a Drug Exposure. The information about the cost is defined by the amount of money paid by the person and payer for the drug, as well as the charged cost of the drug.
DEVICE_COSTThe DEVICE_COST table captures the cost of a medical device or supply used on a Person. The information about the cost is only derived from the amounts paid for the device.
Standardized derived elements
COHORTThe COHORT table contains records derived as a set of subjects that satisfy a given set of inclusion criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. Example cohorts can include patients diagnosed with a specific condition, patients exposed to a particular drug, or providers who have performed a specific procedure.
COHORT_ATTRIBUTEThe COHORT_ATTRIBUTE table contains attributes associated with each subject within a cohort, as defined by a given set of inclusion criteria for a duration of time. The definition of the cohort attribute is contained within the ATTRIBUTE_DEFINITION table. Example cohort attributes can be age, BMI or comorbidity score.
DRUG_ERAA 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.
DOSE_ERAA 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.
CONDITION_ERAA Condition Era is defined as a span of time when the Person is assumed to have a given condition.
documentation/cdm/details_of_the_model.1415968430.txt.gz · Last modified: 2014/11/14 12:33 by cgreich