Added cdm_source, metadata and death

OMOP_CDMv5.3.1_Field_Level.csv

@@ -402,3 +402,27 @@ ATTRIBUTE_DEFINITION,attribute_name,Yes,varchar(255),,,No,No,,,
 ATTRIBUTE_DEFINITION,attribute_description,No,varchar(MAX),,,No,No,,,
 ATTRIBUTE_DEFINITION,attribute_type_concept_id,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
 ATTRIBUTE_DEFINITION,attribute_syntax,No,varchar(MAX),,,No,No,,,
+METADATA,metadata_concept_id,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
+METADATA,metadata_type_concept_id,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
+METADATA,name,Yes,varchar(250),,,No,No,,,
+METADATA,value_as_string,No,nvarchar,,,No,No,,,
+METADATA,value_as_concept_id,No,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
+METADATA,metadata_date,No,date,,,No,No,,,
+METADATA,metadata_datetime,No,datetime,,,No,No,,,
+CDM_SOURCE,cdm_source_name,Yes,varchar(255),,,No,No,,,
+CDM_SOURCE,cdm_source_abbreviation,No,varchar(25),,,No,No,,,
+CDM_SOURCE,cdm_holder,No,varchar(255),,,No,No,,,
+CDM_SOURCE,source_description,No,CLOB,,,No,No,,,
+CDM_SOURCE,source_documentation_reference,No,varchar(255),,,No,No,,,
+CDM_SOURCE,cdm_etl_reference,No,varchar(255),,,No,No,,,
+CDM_SOURCE,source_release_date,No,date,,,No,No,,,
+CDM_SOURCE,cdm_release_date,No,date,,,No,No,,,
+CDM_SOURCE,cdm_version,No,varchar(10),,,No,No,,,
+CDM_SOURCE,vocabulary_version,No,varchar(20),,,No,No,,,
+DEATH,person_id,No,integer,,,No,No,,,
+DEATH,death_date,No,date,,,No,No,,,
+DEATH,death_datetime,No,datetime,,,No,No,,,
+DEATH,death_type_concept_id,No,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
+DEATH,cause_concept_id,No,integer,,,No,Yes,CONCEPT,CONCEPT_ID,
+DEATH,cause_source_value,No,varchar(50),,,No,No,,,
+DEATH,cause_source_concept_id,No,integer,,,No,Yes,CONCEPT,CONCEPT_ID,

OMOP_CDMv5.3.1_Table_Level.csv

@@ -119,27 +119,39 @@ For example, consider a Person who visits her Primary Care Physician (PCP) and w
 The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers.
 The Condition Era Start Date is the start date of the first Condition Occurrence.
 The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date."
-CONCEPT,VOCAB,Yes,,No,,,"The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated 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 belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.
+CONCEPT,CDM,Yes,,No,,,"The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated 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 belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.
 
 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. For a detailed description of these vocabularies, their use in the OMOP CDM and their relationships to each other please refer to the [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary).",,
-VOCABULARY,VOCAB,Yes,,No,,,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,VOCAB,Yes,,No,,,"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 the standardized fields in the CDM tables. For example, the ""Condition"" Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.",,
-CONCEPT_CLASS,VOCAB,Yes,,No,,,"The CONCEPT_CLASS table is a reference table, which 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.",,
-CONCEPT_RELATIONSHIP,VOCAB,Yes,,No,,,The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.,,
-RELATIONSHIP,VOCAB,Yes,,No,,,The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.,,
-CONCEPT_SYNONYM,VOCAB,Yes,,No,,,The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.,,
-CONCEPT_ANCESTOR,VOCAB,Yes,,No,,,"The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.
+VOCABULARY,CDM,Yes,,No,,,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,CDM,Yes,,No,,,"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 the standardized fields in the CDM tables. For example, the ""Condition"" Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the CONDITION_OCCURRENCE and CONDITION_ERA tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.",,
+CONCEPT_CLASS,CDM,Yes,,No,,,"The CONCEPT_CLASS table is a reference table, which 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.",,
+CONCEPT_RELATIONSHIP,CDM,Yes,,No,,,The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.,,
+RELATIONSHIP,CDM,Yes,,No,,,The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table.,,
+CONCEPT_SYNONYM,CDM,Yes,,No,,,The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.,,
+CONCEPT_ANCESTOR,CDM,Yes,,No,,,"The CONCEPT_ANCESTOR table is designed to simplify observational analysis by providing the complete hierarchical relationships between Concepts. Only direct parent-child relationships between Concepts are stored in the CONCEPT_RELATIONSHIP table. To determine higher level ancestry connections, all individual direct relationships would have to be navigated at analysis time. The CONCEPT_ANCESTOR table includes records for all parent-child relationships, as well as grandparent-grandchild relationships and those of any other level of lineage. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept. For example, drug ingredients and drug products are all descendants of a drug class ancestor.
 
 This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.",,
-SOURCE_TO_CONCEPT_MAP,VOCAB,Yes,,No,,,"The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in 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 as target_concept_ids 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_STRENGTH,VOCAB,Yes,,No,,,The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.,,
-COHORT_DEFINITION,VOCAB,Yes,,No,,,"The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination 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 the OMOP Common Data Model.",,
-ATTRIBUTE_DEFINITION,VOCAB,Yes,,No,,,"The ATTRIBUTE_DEFINITION table contains records to define each attribute
+SOURCE_TO_CONCEPT_MAP,CDM,Yes,,No,,,"The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in 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 as target_concept_ids 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_STRENGTH,CDM,Yes,,No,,,The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.,,
+COHORT_DEFINITION,CDM,Yes,,No,,,"The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination 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 the OMOP Common Data Model.",,
+ATTRIBUTE_DEFINITION,CDM,Yes,,No,,,"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.",,
+METADATA,CDM,No,,No,,,The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.,,
+CDM_SOURCE,CDM,No,,No,,,The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.,,
+DEATH,CDM,No,,No,,,"The death domain 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, such as:
+• Condition Code in the Header or Detail information of claims
+• Status of enrollment into a health plan
+• Explicit record in EHR data",,
+,,,,,,,,,
+,,,,,,,,,
+,,,,,,,,,
+,,,,,,,,,
+,,,,,,,,,