From 8fe01fa52cb7e49884d62527b6d9f5decd87d45a Mon Sep 17 00:00:00 2001 From: Clair Blacketer Date: Wed, 17 Apr 2024 20:19:32 -0400 Subject: [PATCH] Removing erroneous characters --- docs/cdm53.html | 2596 ++++++++++++++++++++++++- docs/cdm54.html | 2586 +++++++++++++++++++++++- inst/csv/OMOP_CDMv5.3_Table_Level.csv | 6 +- inst/csv/OMOP_CDMv5.4_Table_Level.csv | 6 +- 4 files changed, 5186 insertions(+), 8 deletions(-) diff --git a/docs/cdm53.html b/docs/cdm53.html index b59fa94..4b78d35 100644 --- a/docs/cdm53.html +++ b/docs/cdm53.html @@ -11680,7 +11680,2601 @@ clinical entity within the OMOP Common Data Model and standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the 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 OMOP +Concepts defined to cover various aspects of observational data +analysis.

+

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 + + +
+ +
+

vocabulary

+

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 + +
+
+
+

domain

+

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 + +
+
+
+

concept_class

+

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 + +
+
+
+

concept_relationship

+

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 + + +
+
+
+

relationship

+

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 + +
+
+
+

concept_synonym

+

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 + +
+
+
+

concept_ancestor

+

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 + + +
+
+
+

source_to_concept_map

+

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 + + +
+
+
+

drug_strength

+

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 + + +
+
+
+

cohort_definition

+

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 + + +
+
+
+

attribute_definition

+

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 + + +
diff --git a/docs/cdm54.html b/docs/cdm54.html index 7266369..73579f2 100644 --- a/docs/cdm54.html +++ b/docs/cdm54.html @@ -13061,7 +13061,2591 @@ clinical entity within the OMOP Common Data Model and standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the 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 OMOP +Concepts defined to cover various aspects of observational data +analysis.

+

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 + + +
+ +
+

vocabulary

+

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 + +
+
+
+

domain

+

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 + +
+
+
+

concept_class

+

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 + +
+
+
+

concept_relationship

+

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 + + +
+
+
+

relationship

+

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 + +
+
+
+

concept_synonym

+

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 + +
+
+
+

concept_ancestor

+

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 + + +
+
+
+

source_to_concept_map

+

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 + + +
+
+
+

drug_strength

+

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 + + +
+
+
+

cohort

+

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 + + +
+
+
+

cohort_definition

+

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 + + +
diff --git a/inst/csv/OMOP_CDMv5.3_Table_Level.csv b/inst/csv/OMOP_CDMv5.3_Table_Level.csv index 7ef0c4e..98492d6 100644 --- a/inst/csv/OMOP_CDMv5.3_Table_Level.csv +++ b/inst/csv/OMOP_CDMv5.3_Table_Level.csv @@ -59,11 +59,11 @@ 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." metadata,CDM,No,NA,No,NA,NA,The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.,NA,NA cdm_source,CDM,No,NA,No,NA,NA,The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.,NA,NA -concept,VOCAB,No,NA,No,NA,NA,"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 standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the 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 OMOP Concepts defined to cover various aspects of observational data analysis. +concept,VOCAB,No,NA,No,NA,NA,"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 standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the data tables of the CDM. Concepts can represent broad categories ('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 OMOP Concepts defined to cover various aspects of observational data analysis. ","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.",NA -vocabulary,VOCAB,No,NA,No,NA,NA,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.,"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Õ.",NA -domain,VOCAB,No,NA,No,NA,NA,"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.","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.",NA +vocabulary,VOCAB,No,NA,No,NA,NA,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.,"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'.",NA +domain,VOCAB,No,NA,No,NA,NA,"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.","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.",NA concept_class,VOCAB,No,NA,No,NA,NA,"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. ",Users can utilize the CONCEPT_CLASS table to explore the different classes or categories of concepts within the OHDSI vocabularies.,NA concept_relationship,VOCAB,No,NA,No,NA,NA,"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.","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.",NA diff --git a/inst/csv/OMOP_CDMv5.4_Table_Level.csv b/inst/csv/OMOP_CDMv5.4_Table_Level.csv index 13fcab3..9bbd9da 100644 --- a/inst/csv/OMOP_CDMv5.4_Table_Level.csv +++ b/inst/csv/OMOP_CDMv5.4_Table_Level.csv @@ -61,11 +61,11 @@ episode,CDM,No,NA,No,NA,NA,"The EPISODE table aggregates lower-level clinical ev episode_event,CDM,No,NA,No,NA,NA,"The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode.",This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes.,"Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated." metadata,CDM,No,NA,No,NA,NA,The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.,NA,NA cdm_source,CDM,No,NA,No,NA,NA,The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.,NA,NA -concept,VOCAB,No,NA,No,NA,NA,"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 standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the 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 OMOP Concepts defined to cover various aspects of observational data analysis. +concept,VOCAB,No,NA,No,NA,NA,"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 standardized analytics. Each Standard Concept belongs to one Domain, which defines the location where the Concept would be expected to occur within the data tables of the CDM. Concepts can represent broad categories ('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 OMOP Concepts defined to cover various aspects of observational data analysis. ","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.",NA -vocabulary,VOCAB,No,NA,No,NA,NA,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.,"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Õ.",NA -domain,VOCAB,No,NA,No,NA,NA,"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.","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.",NA +vocabulary,VOCAB,No,NA,No,NA,NA,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.,"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'.",NA +domain,VOCAB,No,NA,No,NA,NA,"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.","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.",NA concept_class,VOCAB,No,NA,No,NA,NA,"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. ",Users can utilize the CONCEPT_CLASS table to explore the different classes or categories of concepts within the OHDSI vocabularies.,NA concept_relationship,VOCAB,No,NA,No,NA,NA,"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.","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.",NA