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 Next revision Both sides next revision | ||
|
documentation:cdm:details_of_the_model [2014/11/14 12:31] cgreich |
documentation:cdm:details_of_the_model [2014/12/06 17:34] cgreich [Details of the Model] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Details of the Model ====== | ||
| + | |||
| + | 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: | ||
| + | |||
| ^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.| | ||
| Line 24: | Line 30: | ||
| |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. Drug exposure is inferred from clinical events associated with orders, prescriptions written, pharmacy dispensings, procedural administrations, and other patient-reported information.| | ||
| |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 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_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|The CONDITION_OCCURRENCE table captures records of a disease or a medical condition based on evaluation by a provider or reported by a 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|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.| |
| - | |**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 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_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 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’.| | ||
| Line 40: | Line 46: | ||
| |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 amounts 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. 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_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 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 S~~age, BMI or comorbidity score.| |
| |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. 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_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.| | ||
documentation/cdm/details_of_the_model.txt · Last modified: 2017/09/25 14:56 by clairblacketer
Page Tools
