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/15 02:22] cgreich |
documentation:cdm:details_of_the_model [2014/12/06 17:34] cgreich [Details of the Model] |
||
|---|---|---|---|
| Line 7: | Line 7: | ||
| ^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 52: | Line 52: | ||
| |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.| | ||
| - | ~~DISQUS~~ | ||
documentation/cdm/details_of_the_model.txt · Last modified: 2017/09/25 14:56 by clairblacketer
Page Tools
