Differences

This shows you the differences between two versions of the page.

--- documentation:cdm:cdm:concept [2014/11/14 14:14]
cgreich created
+++ — (current)
@@ Line 1: / Line 1: @@
-===== CONCEPT =====
-The Standardized Vocabularies contains records, or concepts, that uniquely identify each fundamental unit of meaning used to express clinical information. Concepts are derived from vocabularies, which represent clinical information across different domains (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some concepts are designated as standard concepts, meaning these concepts can be used as normative expressions of a clinical entity 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 occur within the OMOP Common Data Model.
-Concepts can represent broad categories (like “Cardiovascular disease”), detailed clinical elements (”Myocardial infarction of the anterolateral wall”) or modifying characteristics and attributes that define concepts at various levels of detail (severity of a disease, associated morphology, etc.).
-Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis.
-^Field^Required^Type^Description^
-|concept_id|Yes|integer|A unique identifier for each concept across all domains.|
-|concept_name|Yes|varchar(255)|An unambiguous, meaningful and descriptive name for the concept.|
-|domain_id|Yes|varchar(20)|The domain a concept belongs to.|
-|vocabulary_id|Yes|varchar(20)|A foreign key to the vocabulary table indicating from which source the concept has been adapted.|
-|concept_class_id|Yes|varchar(20)|The category or class of the concept along both the hierarchical tree as well as different domains within a vocabulary. Examples are “Clinical Drug”, “Ingredient”, “Clinical Finding” etc.|
-|standard_concept|No|varchar(1)|This flag determines where a concept is a Standard Concept, i.e. is used in the data, a class concept, or a non-standard concept. The allowables values for standard_concept are: 'S' for Standard Concept, 'C' for a Class Concept, otherwise the content is null for non-standard concepts, including source concepts. Standard Concepts (S) may appear in CDM tables in concept_id fields, whereas Class concepts (C) should not appear in the CDM data, but participate in the CONCEPT_ANCESTOR and can be used to identify descendants that may appear in the data. Non-standard concepts can only appear in source_concept_id fields and are not used in CONCEPT_ANCESTOR.|
-|concept_code|Yes|varchar(50)|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|varchar(1)|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.|
-==== Conventions ====
-Concepts in the Common Data Model are derived from a number of public or proprietary terminologies such as SNOMED-CT and RxNorm, or custom generated to standardize aspects of observational data. Both types of Concepts are integrated based on the following rules:
-  * All Concepts are maintained centrally by OMOP. Additional concepts can be added, as needed, upon request.
-  * For all Concepts, whether they are custom generated or adopted from published terminologies, a unique numeric identifier concept_id is assigned and used as the key to link all observational data to the corresponding Concept reference data.
-  * The concept_id of a Concept is persistent, i.e. stays the same for the same Concepts between releases of the Standardized Vocabularies.
-  * A descriptive name for each Concept is stored as the Concept name as part of the Concept table. Additional names and descriptions for the Concept are stored as Synonyms in the Concept_Synonym table.
-  * Each concept is assigned to one domain.
-  * For Concepts inherited from published terminologies, the source code is retained as part of the Concept reference data and used to reference the source vocabulary.
-  * All logical data elements associated with the various CDM tables, usually called Types, including defining characteristics, qualifying attributes etc. are also stored as Concepts. Since they are generated by OMOP, their source_code is omitted.
-  * The lifespan of concepts is recorded through their valid_start_date, valid_end_date and the invalid_reason. This allows concepts to correctly reflect at which point in time were in active clinical use. For example, drugs that are taken off the market might be dropped by the terminology vendor. However, since observational data are valid with respect to the time they are recorded, it is key for the Standardized Vocabularies to provide even obsolete codes and maintain their relationships to other Concepts and Classifications.
-  * Concepts without a known instantiated date are assigned VALID_START_DATE of ‘1970-01-01’
-  * Concepts that are not invalid are assigned VALID_END_DATE of ‘2099-12-31’
-  * Concepts generated as part of Standardized Vocabularies will be reserved as values from 0 to 2,000,000,000.
-====

Observational Health Data Sciences and Informatics

User Tools

Site Tools

Differences

Page Tools