User Guide
+The primary purpose of the CONCEPT table is to provide a standardized +representation of medical Concepts, allowing for consistent querying and +analysis across the healthcare databases. Users can join the CONCEPT +table with other tables in the CDM to enrich clinical data with +standardized Concept information or use the CONCEPT table as a reference +for mapping clinical data from source terminologies to Standard +Concepts.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id + | ++A unique identifier for each Concept across all domains. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +concept_name + | ++An unambiguous, meaningful and descriptive name for the Concept. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +domain_id + | ++A foreign key to the DOMAIN +table the Concept belongs to. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
| +vocabulary_id + | ++A foreign key to the VOCABULARY +table indicating from which source the Concept has been adapted. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
| +concept_class_id + | ++The attribute or concept class of the Concept. Examples are ‘Clinical +Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++CONCEPT_CLASS + | ++ | +
| +standard_concept + | ++This flag determines where a Concept is a Standard Concept, i.e. is used +in the data, a Classification Concept, or a non-standard Source Concept. +The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification +Concept), otherwise the content is NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +concept_code + | ++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. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_start_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. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_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. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++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. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+The VOCABULARY table includes a list of the Vocabularies integrated +from various sources or created de novo in OMOP CDM. This reference +table contains a single record for each Vocabulary and includes a +descriptive name and other associated attributes for the Vocabulary.
+User Guide
+The primary purpose of the VOCABULARY table is to provide explicit +information about specific vocabulary versions and the references to the +sources from which they are asserted. Users can identify the version of +a particular vocabulary used in the database, enabling consistency and +reproducibility in data analysis. Besides, users can check the +vocabulary release version in their CDM which refers to the +vocabulary_id = ‘None’.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +vocabulary_id + | ++A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +vocabulary_name + | ++The name describing the vocabulary, for example, International +Classification of Diseases, Ninth Revision, Clinical Modification, +Volume 1 and 2 (NCHS) etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_reference + | ++External reference to documentation or available download of the about +the vocabulary. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_version + | ++Version of the Vocabulary as indicated in the source. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_concept_id + | ++A Concept that represents the Vocabulary the VOCABULARY record belongs +to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The DOMAIN table includes a list of OMOP-defined Domains to which the +Concepts of the Standardized Vocabularies can belong. A Domain +represents a clinical definition whereby we assign matching Concepts for +the standardized fields in the CDM tables. For example, the Condition +Domain contains Concepts that describe a patient condition, and these +Concepts can only be used 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, including a Domain ID +and a descriptive name for every Domain.
+User Guide
+Users can leverage the DOMAIN table to explore the full spectrum of +health-related data Domains available in the Standardized Vocabularies. +Also, the information in the DOMAIN table may be used as a reference for +mapping source data to OMOP domains, facilitating data harmonization and +interoperability.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +domain_id + | ++A unique key for each domain. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +domain_name + | ++The name describing the Domain, e.g. Condition, Procedure, Measurement +etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +domain_concept_id + | ++A Concept representing the Domain Concept the DOMAIN record belongs to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_CLASS table includes semantic categories that reference +the source structure of each Vocabulary. Concept Classes represent +so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels +(e.g. SNOMED) of the vocabulary structure. Vocabularies without any +Concept Classes, such as HCPCS, use the vocabulary_id as the Concept +Class. This reference table is populated with a single record for each +Concept Class, which includes a Concept Class ID and a fully specified +Concept Class name.
+User Guide
+Users can utilize the CONCEPT_CLASS table to explore the different +classes or categories of concepts within the OHDSI vocabularies.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_class_id + | ++A unique key for each class. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +concept_class_name + | ++The name describing the Concept Class, e.g. Clinical Finding, +Ingredient, etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +concept_class_concept_id + | ++A Concept that represents the Concept Class. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_RELATIONSHIP table contains records that define +relationships between any two Concepts and the nature or type of the +relationship. This table captures various types of relationships, +including hierarchical, associative, and other semantic connections, +enabling comprehensive analysis and interpretation of clinical concepts. +Every kind of relationship is defined in the RELATIONSHIP table.
+User Guide
+The CONCEPT_RELATIONSHIP table can be used to explore hierarchical or +attribute relationships between concepts to understand the hierarchical +structure of clinical concepts and uncover implicit connections and +associations within healthcare data. For example, users can utilize +mapping relationships (‘Maps to’) to harmonize data from different +sources and terminologies, enabling interoperability and data +integration across disparate datasets.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +relationship_id + | ++The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the +Vocabulary +Conventions. for more information. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++RELATIONSHIP + | ++ | +
| +valid_start_date + | ++The date when the relationship is first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when the relationship is invalidated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++Reason the relationship was invalidated. Possible values are ‘D’ +(deleted), ‘U’ (updated) or NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +relationship_id + | ++The type of relationship captured by the relationship record. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +relationship_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +is_hierarchical + | ++Defines whether a relationship defines concepts into classes or +hierarchies. Values are 1 for hierarchical relationship or 0 if not. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +defines_ancestry + | ++Defines whether a hierarchical relationship contributes to the +concept_ancestor table. These are subsets of the hierarchical +relationships. Valid values are 1 or 0. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +reverse_relationship_id + | ++The identifier for the relationship used to define the reverse +relationship between two concepts. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +relationship_concept_id + | ++A foreign key that refers to an identifier in the CONCEPT +table for the unique relationship concept. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_SYNONYM table is used to store alternate names and +descriptions for Concepts.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +concept_synonym_name + | ++ | ++ | ++varchar(1000) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +language_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +ancestor_concept_id + | ++The Concept Id for the higher-level concept that forms the ancestor in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +descendant_concept_id + | ++The Concept Id for the lower-level concept that forms the descendant in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +min_levels_of_separation + | ++The minimum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +max_levels_of_separation + | ++The maximum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +source_code + | ++The source code being translated into a Standard Concept. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +source_concept_id + | ++A foreign key to the Source Concept that is being translated into a +Standard Concept. + | ++This is either 0 or should be a number above 2 billion, which are the +Concepts reserved for site-specific codes and mappings. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +source_vocabulary_id + | ++A foreign key to the VOCABULARY table defining the vocabulary of the +source code that is being translated to a Standard Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +source_code_description + | ++An optional description for the source code. This is included as a +convenience to compare the description of the source code to the name of +the concept. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +target_concept_id + | ++The target Concept to which the source code is being mapped. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +target_vocabulary_id + | ++The Vocabulary of the target Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
| +valid_start_date + | ++The date when the mapping instance was first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when the mapping instance became invalid because it was deleted +or superseded (updated) by a new relationship. Default value is +31-Dec-2099. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++Reason the mapping instance was invalidated. Possible values are D +(deleted), U (replaced with an update) or NULL when valid_end_date has +the default value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +drug_concept_id + | ++The Concept representing the Branded Drug or Clinical Drug Product. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +ingredient_concept_id + | ++The Concept representing the active ingredient contained within the drug +product. + | ++Combination Drugs will have more than one record in this table, one for +each active Ingredient. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +amount_value + | ++The numeric value or the amount of active ingredient contained within +the drug product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +amount_unit_concept_id + | ++The Concept representing the Unit of measure for the amount of active +ingredient contained within the drug product. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +numerator_value + | ++The concentration of the active ingredient contained within the drug +product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +numerator_unit_concept_id + | ++The Concept representing the Unit of measure for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +denominator_value + | ++The amount of total liquid (or other divisible product, such as +ointment, gel, spray, etc.). + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +denominator_unit_concept_id + | ++The Concept representing the denominator unit for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +box_size + | ++The number of units of Clinical Branded Drug or Quantified Clinical or +Branded Drug contained in a box as dispensed to the patient. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
| +valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when then Concept became invalid. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++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. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +cohort_definition_id + | ++This is the identifier given to the cohort, usually by the ATLAS +application + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_definition_name + | ++A short description of the cohort + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_definition_description + | ++A complete description of the cohort. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +definition_type_concept_id + | ++Type defining what kind of Cohort Definition the record represents and +how the syntax may be executed. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +cohort_definition_syntax + | ++Syntax or code to operationalize the Cohort Definition. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +subject_concept_id + | ++This field contains a Concept that represents the domain of the subjects +that are members of the cohort (e.g., Person, Provider, Visit). + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +cohort_initiation_date + | ++A date to indicate when the Cohort was initiated in the COHORT table. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +attribute_definition_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +attribute_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +attribute_description + | ++ | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +attribute_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +attribute_syntax + | ++ | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
User Guide
+The primary purpose of the CONCEPT table is to provide a standardized +representation of medical Concepts, allowing for consistent querying and +analysis across the healthcare databases. Users can join the CONCEPT +table with other tables in the CDM to enrich clinical data with +standardized Concept information or use the CONCEPT table as a reference +for mapping clinical data from source terminologies to Standard +Concepts.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id + | ++A unique identifier for each Concept across all domains. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +concept_name + | ++An unambiguous, meaningful and descriptive name for the Concept. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +domain_id + | ++A foreign key to the DOMAIN +table the Concept belongs to. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
| +vocabulary_id + | ++A foreign key to the VOCABULARY +table indicating from which source the Concept has been adapted. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
| +concept_class_id + | ++The attribute or concept class of the Concept. Examples are ‘Clinical +Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++CONCEPT_CLASS + | ++ | +
| +standard_concept + | ++This flag determines where a Concept is a Standard Concept, i.e. is used +in the data, a Classification Concept, or a non-standard Source Concept. +The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification +Concept), otherwise the content is NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +concept_code + | ++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. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_start_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. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_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. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++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. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+The VOCABULARY table includes a list of the Vocabularies integrated +from various sources or created de novo in OMOP CDM. This reference +table contains a single record for each Vocabulary and includes a +descriptive name and other associated attributes for the Vocabulary.
+User Guide
+The primary purpose of the VOCABULARY table is to provide explicit +information about specific vocabulary versions and the references to the +sources from which they are asserted. Users can identify the version of +a particular vocabulary used in the database, enabling consistency and +reproducibility in data analysis. Besides, users can check the +vocabulary release version in their CDM which refers to the +vocabulary_id = ‘None’.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +vocabulary_id + | ++A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +vocabulary_name + | ++The name describing the vocabulary, for example, International +Classification of Diseases, Ninth Revision, Clinical Modification, +Volume 1 and 2 (NCHS) etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_reference + | ++External reference to documentation or available download of the about +the vocabulary. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_version + | ++Version of the Vocabulary as indicated in the source. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +vocabulary_concept_id + | ++A Concept that represents the Vocabulary the VOCABULARY record belongs +to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The DOMAIN table includes a list of OMOP-defined Domains to which the +Concepts of the Standardized Vocabularies can belong. A Domain +represents a clinical definition whereby we assign matching Concepts for +the standardized fields in the CDM tables. For example, the Condition +Domain contains Concepts that describe a patient condition, and these +Concepts can only be used 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, including a Domain ID +and a descriptive name for every Domain.
+User Guide
+Users can leverage the DOMAIN table to explore the full spectrum of +health-related data Domains available in the Standardized Vocabularies. +Also, the information in the DOMAIN table may be used as a reference for +mapping source data to OMOP domains, facilitating data harmonization and +interoperability.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +domain_id + | ++A unique key for each domain. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +domain_name + | ++The name describing the Domain, e.g. Condition, Procedure, Measurement +etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +domain_concept_id + | ++A Concept representing the Domain Concept the DOMAIN record belongs to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_CLASS table includes semantic categories that reference +the source structure of each Vocabulary. Concept Classes represent +so-called horizontal (e.g. MedDRA, RxNorm) or vertical levels +(e.g. SNOMED) of the vocabulary structure. Vocabularies without any +Concept Classes, such as HCPCS, use the vocabulary_id as the Concept +Class. This reference table is populated with a single record for each +Concept Class, which includes a Concept Class ID and a fully specified +Concept Class name.
+User Guide
+Users can utilize the CONCEPT_CLASS table to explore the different +classes or categories of concepts within the OHDSI vocabularies.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_class_id + | ++A unique key for each class. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +concept_class_name + | ++The name describing the Concept Class, e.g. Clinical Finding, +Ingredient, etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +concept_class_concept_id + | ++A Concept that represents the Concept Class. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_RELATIONSHIP table contains records that define +relationships between any two Concepts and the nature or type of the +relationship. This table captures various types of relationships, +including hierarchical, associative, and other semantic connections, +enabling comprehensive analysis and interpretation of clinical concepts. +Every kind of relationship is defined in the RELATIONSHIP table.
+User Guide
+The CONCEPT_RELATIONSHIP table can be used to explore hierarchical or +attribute relationships between concepts to understand the hierarchical +structure of clinical concepts and uncover implicit connections and +associations within healthcare data. For example, users can utilize +mapping relationships (‘Maps to’) to harmonize data from different +sources and terminologies, enabling interoperability and data +integration across disparate datasets.
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +relationship_id + | ++The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the +Vocabulary +Conventions. for more information. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++RELATIONSHIP + | ++ | +
| +valid_start_date + | ++The date when the relationship is first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when the relationship is invalidated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++Reason the relationship was invalidated. Possible values are ‘D’ +(deleted), ‘U’ (updated) or NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +relationship_id + | ++The type of relationship captured by the relationship record. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
| +relationship_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +is_hierarchical + | ++Defines whether a relationship defines concepts into classes or +hierarchies. Values are 1 for hierarchical relationship or 0 if not. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +defines_ancestry + | ++Defines whether a hierarchical relationship contributes to the +concept_ancestor table. These are subsets of the hierarchical +relationships. Valid values are 1 or 0. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +reverse_relationship_id + | ++The identifier for the relationship used to define the reverse +relationship between two concepts. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +relationship_concept_id + | ++A foreign key that refers to an identifier in the CONCEPT +table for the unique relationship concept. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+The CONCEPT_SYNONYM table is used to store alternate names and +descriptions for Concepts.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +concept_synonym_name + | ++ | ++ | ++varchar(1000) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +language_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +ancestor_concept_id + | ++The Concept Id for the higher-level concept that forms the ancestor in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +descendant_concept_id + | ++The Concept Id for the lower-level concept that forms the descendant in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +min_levels_of_separation + | ++The minimum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +max_levels_of_separation + | ++The maximum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
Table Description
+The source to concept map table is 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. +There are OHDSI tools to help you populate this table; Usagi and Perseus. You can read more +about OMOP vocabulary mapping in The +Book of OHDSI Chapter 6.3.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +source_code + | ++The source code being translated into a Standard Concept. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +source_concept_id + | ++A foreign key to the Source Concept that is being translated into a +Standard Concept. + | ++This is either 0 or should be a number above 2 billion, which are the +Concepts reserved for site-specific codes and mappings. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +source_vocabulary_id + | ++A foreign key to the VOCABULARY table defining the vocabulary of the +source code that is being translated to a Standard Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +source_code_description + | ++An optional description for the source code. This is included as a +convenience to compare the description of the source code to the name of +the concept. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +target_concept_id + | ++The target Concept to which the source code is being mapped. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +target_vocabulary_id + | ++The Vocabulary of the target Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
| +valid_start_date + | ++The date when the mapping instance was first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when the mapping instance became invalid because it was deleted +or superseded (updated) by a new relationship. Default value is +31-Dec-2099. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++Reason the mapping instance was invalidated. Possible values are D +(deleted), U (replaced with an update) or NULL when valid_end_date has +the default value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +drug_concept_id + | ++The Concept representing the Branded Drug or Clinical Drug Product. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +ingredient_concept_id + | ++The Concept representing the active ingredient contained within the drug +product. + | ++Combination Drugs will have more than one record in this table, one for +each active Ingredient. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +amount_value + | ++The numeric value or the amount of active ingredient contained within +the drug product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +amount_unit_concept_id + | ++The Concept representing the Unit of measure for the amount of active +ingredient contained within the drug product. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +numerator_value + | ++The concentration of the active ingredient contained within the drug +product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +numerator_unit_concept_id + | ++The Concept representing the Unit of measure for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +denominator_value + | ++The amount of total liquid (or other divisible product, such as +ointment, gel, spray, etc.). + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
| +denominator_unit_concept_id + | ++The Concept representing the denominator unit for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +box_size + | ++The number of units of Clinical Branded Drug or Quantified Clinical or +Branded Drug contained in a box as dispensed to the patient. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
| +valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +valid_end_date + | ++The date when then Concept became invalid. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +invalid_reason + | ++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. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
Table Description
+The subject of a cohort can have multiple, discrete records in the +cohort table per cohort_definition_id, subject_id, and non-overlapping +time periods. The definition of the cohort is contained within the +COHORT_DEFINITION table. It is listed as part of the RESULTS schema +because it is a table that users of the database as well as tools such +as ATLAS need to be able to write to. The CDM and Vocabulary tables are +all read-only so it is suggested that the COHORT and COHORT_DEFINTION +tables are kept in a separate schema to alleviate confusion.
+User Guide
+NA
+ETL Conventions
+Cohorts typically include patients diagnosed with a specific +condition, patients exposed to a particular drug, but can also be +Providers who have performed a specific Procedure. Cohort records must +have a Start Date and an End Date, but the End Date may be set to Start +Date or could have an applied censor date using the Observation Period +Start Date. Cohort records must contain a Subject Id, which can refer to +the Person, Provider, Visit record or Care Site though they are most +often Person Ids. The Cohort Definition will define the type of subject +through the subject concept id. A subject can belong (or not belong) to +a cohort at any moment in time. A subject can only have one record in +the cohort table for any moment of time, i.e. it is not possible for a +person to contain multiple records indicating cohort membership that are +overlapping in time
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +cohort_definition_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +subject_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_start_date + | ++ | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_end_date + | ++ | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
Table Description
+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.
+User Guide
+NA
+ETL Conventions
+NA
+| +CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
|---|---|---|---|---|---|---|---|---|
| +cohort_definition_id + | ++This is the identifier given to the cohort, usually by the ATLAS +application + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_definition_name + | ++A short description of the cohort + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
| +cohort_definition_description + | ++A complete description of the cohort. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +definition_type_concept_id + | ++Type defining what kind of Cohort Definition the record represents and +how the syntax may be executed. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +cohort_definition_syntax + | ++Syntax or code to operationalize the Cohort Definition. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
| +subject_concept_id + | ++This field contains a Concept that represents the domain of the subjects +that are members of the cohort (e.g., Person, Provider, Visit). + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
| +cohort_initiation_date + | ++A date to indicate when the Cohort was initiated in the COHORT table. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +