documentation:cdm:details_of_the_model
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
documentation:cdm:details_of_the_model [2014/11/14 12:38] cgreich |
documentation:cdm:details_of_the_model [2017/09/25 14:56] (current) clairblacketer |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Details of the Model ====== | ====== Details of the Model ====== | ||
| + | **THIS IS OUTDATED. All documentation is now on the [[https://github.com/OHDSI/CommonDataModel/wiki|github wiki]]. Please refer there or to the [[projects:workgroups:cdm-wg|CDM working group]] for more information** | ||
| + | |||
| + | The CDM defines table structures in a person-centric way. At a minimum, the tables have a foreign key into the Person table and a date. This allows for a longitudinal view on all the healthcare-relevant events. The exceptions from this rule are the standardized health system data tables, which are linked directly to events of the various domains. | ||
| + | |||
| To represent the relevant domains, the CDM contains the following 39 tables: | To represent the relevant domains, the CDM contains the following 39 tables: | ||
| ^Table name^Description^ | ^Table name^Description^ | ||
| |**Standardized Vocabularies**|| | |**Standardized Vocabularies**|| | ||
| - | |CONCEPT|The 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.| | + | |CONCEPT|The 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. Some 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.| |
| - | |VOCABULARY|The 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.| | + | |VOCABULARY|The 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.| |
| - | |DOMAIN|The 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.| | + | |DOMAIN|The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. 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_CLASS|The 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_CLASS|The CONCEPT_CLASS table includes a list of the classifications used to differentiate concepts within a given vocabulary. Concept Classes are defined by the source Vocabulary, but might be slightly altered to fit OMOP CDM table constraints. This reference table is populated with a single record with a descriptive name for each Concept Class.| |
| - | |CONCEPT_RELATIONSHIP|The 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’.| | + | |CONCEPT_RELATIONSHIP|The 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.| |
| - | |RELATIONSHIP|The 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.| | + | |RELATIONSHIP|The 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.| |
| - | |CONCEPT_SYNONYM|The 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_SYNONYM|The CONCEPT_SYNONYM table is used to store alternate names and descriptions for a concept.| |
| - | |CONCEPT_ANCESTOR|The 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.| | + | |CONCEPT_ANCESTOR|The 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 and is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts.| |
| - | |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 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.| | + | |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 extract, transform, and load (ETL) processes to maintain local source codes which are not available as concepts in the Standardized Vocabularies.| |
| - | |DRUG_STRENGTH|The 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.| | + | |DRUG_STRENGTH|The 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.| |
| - | |COHORT_DEFINITION|The 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.| | + | |COHORT_DEFINITION|The COHORT_DEFINITION table contains records to define each derived Cohort through an associated description and syntax and can store operational programming code to instantiate the cohort within a OMOP common data model.| |
| - | |ATTRIBUTE_DEFINITION|The 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.| | + | |ATTRIBUTE_DEFINITION|The 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.| |
| |**Standardized meta-data**|| | |**Standardized meta-data**|| | ||
| |CDM_SOURCE|The 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.| | |CDM_SOURCE|The 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**|| | |**Standardized clinical data**|| | ||
| - | |PERSON|The 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.| | + | |PERSON|The 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.| |
| - | |OBSERVATION_PERIOD|The 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.| | + | |OBSERVATION_PERIOD|The 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, even if no events in fact are recorded (healthy patient with no healthcare interactions).| |
| |SPECIMEN|The SPECIMEN table contains the records identifying each biological sample from a person.| | |SPECIMEN|The SPECIMEN table contains the records identifying each biological sample from a person.| | ||
| - | |DEATH|The 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.| | + | |DEATH|The DEATH table contains the clinical event for how and when a Person dies. A person can have up to one record if the source system contains evidence about the Death.| |
| - | |VISIT_OCCURRENCE|The 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.| | + | |VISIT_OCCURRENCE|The 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.| |
| - | |PROCEDURE_OCCURRENCE|The 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.| | + | |PROCEDURE_OCCURRENCE|The PROCEDURE_OCCURRENCE table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient to have a diagnostic or therapeutic purpose.| |
| - | |DRUG_EXPOSURE|The 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.| | + | |DRUG_EXPOSURE|The 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.| |
| - | |DEVICE_EXPOSURE|The 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).| | + | |DEVICE_EXPOSURE|The device exposure domain captures information about a person’s exposure to a foreign physical object or instrument that which 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_OCCURRENCE|The CONDITION_OCCURRENCE table captures records of a disease or a medical condition based on evaluation by a provider or reported by a patient.| | + | |CONDITION_OCCURRENCE|Conditions are records of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign or a symptom, which is either observed by a Provider or reported by the patient.| |
| - | |MEASUREMENT|A 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.| | + | |MEASUREMENT|The MEASUREMENT table contains records of Measurement, i.e. structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person's sample. The MEASUREMENT table contains both orders and results of such Measurements as laboratory tests, vital signs, quantitative findings from pathology reports, etc| |
| - | |NOTE|The NOTE table captures unstructured information that was recorded by a provider or a patient in free text notes on a given date. | + | |NOTE|The NOTE table captures unstructured information that was recorded by a provider or a patient in free text notes on a given date.| |
| - | |OBSERVATION|The 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.| | + | |OBSERVATION|The OBSERVATION table captures clinical facts about a Person obtained in the context of examination, questioning or a procedure. Any data that cannot be represented by any other domains, such as social and lifestyle facts, medical history, family history, etc. are recorded here.| |
| - | |FACT_RELATIONSHIP|The 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’.| | + | |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 (table), or different domains. Examples of Fact Relationships include: Person relationships (parent-child), care site relationships (hierarchical organizational structure of facilities within a health system), indication relationship (between drug exposures and associated conditions), usage relationships (of devices during the course of an associated procedure), or facts derived from one another (measurements derived from an associated specimen).| |
| |**Standardized health system data**|| | |**Standardized health system data**|| | ||
| |LOCATION|The LOCATION table represents a generic way to capture physical location or address information. Locations are used to define the addresses for Persons and Care Sites. | |LOCATION|The LOCATION table represents a generic way to capture physical location or address information. Locations are used to define the addresses for Persons and Care Sites. | ||
| - | |CARE_SITE|The CARE_SITE table contains a list of uniquely identified physical or organizational units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.).| | + | |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.).| |
| - | |PROVIDER|The PROVIDER table contains a list of uniquely identified health care providers. These are typically physicians and nurses.| | + | |PROVIDER|The PROVIDER table contains a list of uniquely identified health care providers. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc.| |
| |**Standardized health economics**|| | |**Standardized health economics**|| | ||
| - | |PAYER_PLAN_PERIOD|The 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.| | + | |PAYER_PLAN_PERIOD|The PAYER_PLAN_PERIOD table captures the unique combination of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer as well as covered family members.| |
| - | |VISIT_COST|The 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.| | + | |VISIT_COST|The 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 Visit.| |
| - | |PROCEDURE_COST|The 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.| | + | |PROCEDURE_COST|The PROCEDURE_COST table captures the cost of a Procedure performed on a Person. The information about the cost is only derived from the amount of money paid for the Procedure.| |
| |DRUG_COST|The 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.| | |DRUG_COST|The 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_COST|The 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.| | + | |DEVICE_COST|The 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 amount of money paid for the device.| |
| |**Standardized derived elements**|| | |**Standardized derived elements**|| | ||
| - | |COHORT|The 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|The COHORT table contains records derived as a set of subjects that satisfy a given set of inclusion criteria for a duration of time COHORT_DEFINITION table. Cohorts can be constructed of patients (Persons), Providers or Visits.| |
| - | |COHORT_ATTRIBUTE|The 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.| | + | |COHORT_ATTRIBUTE|The COHORT_ATTRIBUTE table contains attributes associated with each subject within a cohort, as defined by a given set of criteria for a duration of time. The definition of the Cohort Attribute is contained in the ATTRIBUTE_DEFINITION table.| |
| - | |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.| | + | |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, i.e. successive periods of Drug Exposures combined under certain rules to produce continuous Drug Eras.| |
| |DOSE_ERA|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.| | |DOSE_ERA|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.| | ||
| |CONDITION_ERA|A Condition Era is defined as a span of time when the Person is assumed to have a given condition.| | |CONDITION_ERA|A Condition Era is defined as a span of time when the Person is assumed to have a given condition.| | ||
| - | The CDM defines table structures for each of the domains in a person-centric way. At a minimum, the tables have foreign keys into the Person table and a date. This allows for a longitudinal view on all the healthcare-relevant events. The exceptions from this rule are the standardized health system data tables. Providers carrying out health care are linked to many of the events as well. Both are linked to healthcare providers (hospitals, doctors, nurses), care sites (doctor's offices, hospital departments etc.) and physical locations (addresses or geographical areas). | + | |
documentation/cdm/details_of_the_model.1415968716.txt.gz · Last modified: 2014/11/14 12:38 by cgreich
Page Tools
