adds concept_ancestor description

closes #664

docs/cdm54.html

@@ -14410,18 +14410,26 @@ <h3 class="tabset tabset-pills">concept_ancestor</h3>
 <p>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
+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.</p>
+lineage for Standard or Classification concepts. Using the
+CONCEPT_ANCESTOR table allows for querying for all descendants of a
+hierarchical concept, and the other way around. For example, drug
+ingredients and drug products, beneath them in the hierarchy, are all
+descendants of a drug class ancestor. This table is entirely derived
+from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.</p>
 <p><strong>User Guide</strong></p>
-<p>NA</p>
+<p>The CONCEPT_ANCESTOR table can be used to explore the hierarchical
+relationships captured in the table to gain insights into the
+hierarchical structure of clinical concepts. Understanding the
+hierarchical relationships of concepts can facilitate accurate
+interpretation and analysis of healthcare data. Also, by incorporating
+hierarchical relationships from the CONCEPT_ANCESTOR table, users can
+create cohorts containing related concepts within a hierarchical
+structure, enabling more comprehensive cohort definitions.</p>
 <p><strong>ETL Conventions</strong></p>
 <p>NA</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">

docs/cdm60.html

@@ -13980,18 +13980,26 @@ <h3 class="tabset tabset-pills">concept_ancestor</h3>
 <p>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
+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.</p>
-<p>This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP
-and RELATIONSHIP tables.</p>
+lineage for Standard or Classification concepts. Using the
+CONCEPT_ANCESTOR table allows for querying for all descendants of a
+hierarchical concept, and the other way around. For example, drug
+ingredients and drug products, beneath them in the hierarchy, are all
+descendants of a drug class ancestor. This table is entirely derived
+from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.</p>
 <p><strong>User Guide</strong></p>
-<p>NA</p>
+<p>The CONCEPT_ANCESTOR table can be used to explore the hierarchical
+relationships captured in the table to gain insights into the
+hierarchical structure of clinical concepts. Understanding the
+hierarchical relationships of concepts can facilitate accurate
+interpretation and analysis of healthcare data. Also, by incorporating
+hierarchical relationships from the CONCEPT_ANCESTOR table, users can
+create cohorts containing related concepts within a hierarchical
+structure, enabling more comprehensive cohort definitions.</p>
 <p><strong>ETL Conventions</strong></p>
 <p>NA</p>
 <table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">

inst/csv/OMOP_CDMv5.4_Table_Level.csv

@@ -69,7 +69,7 @@ concept_class,VOCAB,No,NA,No,NA,NA,"The CONCEPT_CLASS table includes semantic ca
 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
 relationship,VOCAB,No,NA,No,NA,NA,"The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two Concepts in the CONCEPT_RELATIONSHIP table, the respective reverse relationships, and their hierarchical characteristics. Note, that Concepts representing relationships between the clinical facts, used for filling in the FACT_RELATIONSHIP table are stored in the CONCEPT table and belong to the Relationship Domain.","Users can leverage the RELATIONSHIP table to explore the full list of direct and reverse relationships within the OMOP vocabulary system. Also, users can get insight into how these relationships can be used in ETL, cohort creation, and other tasks according to their ancestral characteristics.",NA
 concept_synonym,VOCAB,No,NA,No,NA,NA,"The CONCEPT_SYNONYM table captures alternative terms, synonyms, and translations of Concept Name into various languages linked to specific concepts, providing users with a comprehensive view of how Concepts may be expressed or referenced.","Users can leverage the CONCEPT_SYNONYM table to expand search capabilities and improve query accuracy by incorporating synonymous terms into data analysis and retrieval processes. Also, users can enhance their mapping efforts between local terminologies and standardized concepts by identifying synonymous terms associated with concepts in the CONCEPT_SYNONYM table.",NA
-concept_ancestor,VOCAB,No,NA,No,NA,NA,"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.",NA,NA
+concept_ancestor,VOCAB,No,NA,No,NA,NA,"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 for Standard or Classification concepts. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept, and the other way around. For example, drug ingredients and drug products, beneath them in the hierarchy, are all descendants of a drug class ancestor. This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.","The CONCEPT_ANCESTOR table can be used to explore the hierarchical relationships captured in the table to gain insights into the hierarchical structure of clinical concepts. Understanding the hierarchical relationships of concepts can facilitate accurate interpretation and analysis of healthcare data. Also, by incorporating hierarchical relationships from the CONCEPT_ANCESTOR table, users can create cohorts containing related concepts within a hierarchical structure, enabling more comprehensive cohort definitions.",NA
 source_to_concept_map,VOCAB,No,NA,No,NA,NA,"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](https://github.com/OHDSI/Usagi) and [Perseus](https://github.com/ohdsi/Perseus). You can read more about OMOP vocabulary mapping in [The Book of OHDSI Chapter 6.3](https://ohdsi.github.io/TheBookOfOhdsi/ExtractTransformLoad.html#step-2-create-the-code-mappings).**",NA,NA
 drug_strength,VOCAB,No,NA,No,NA,NA,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.,NA,NA
 cohort,RESULTS,No,NA,No,NA,NA,"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.",NA,"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"

inst/csv/OMOP_CDMv6.0_Table_Level.csv

@@ -71,9 +71,7 @@ concept_class,VOCAB,No,NA,No,NA,NA,"The CONCEPT_CLASS table is a reference table
 concept_relationship,VOCAB,No,NA,No,NA,NA,The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the RELATIONSHIP table.,NA,NA
 relationship,VOCAB,No,NA,No,NA,NA,"The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two Concepts in the CONCEPT_RELATIONSHIP table, the respective reverse relationships, and their hierarchical characteristics. Note, that Concepts representing relationships between the clinical facts, used for filling in the FACT_RELATIONSHIP table are stored in the CONCEPT table and belong to the Relationship Domain.","Users can leverage the RELATIONSHIP table to explore the full list of direct and reverse relationships within the OMOP vocabulary system. Also, users can get insight into how these relationships can be used in ETL, cohort creation, and other tasks according to their ancestral characteristics.",NA
 concept_synonym,VOCAB,No,NA,No,NA,NA,"The CONCEPT_SYNONYM table captures alternative terms, synonyms, and translations of Concept Name into various languages linked to specific concepts, providing users with a comprehensive view of how Concepts may be expressed or referenced.","Users can leverage the CONCEPT_SYNONYM table to expand search capabilities and improve query accuracy by incorporating synonymous terms into data analysis and retrieval processes. Also, users can enhance their mapping efforts between local terminologies and standardized concepts by identifying synonymous terms associated with concepts in the CONCEPT_SYNONYM table.",NA
-concept_ancestor,VOCAB,No,NA,No,NA,NA,"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.",NA,NA
+concept_ancestor,VOCAB,No,NA,No,NA,NA,"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 for Standard or Classification concepts. Using the CONCEPT_ANCESTOR table allows for querying for all descendants of a hierarchical concept, and the other way around. For example, drug ingredients and drug products, beneath them in the hierarchy, are all descendants of a drug class ancestor. This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP, and RELATIONSHIP tables.","The CONCEPT_ANCESTOR table can be used to explore the hierarchical relationships captured in the table to gain insights into the hierarchical structure of clinical concepts. Understanding the hierarchical relationships of concepts can facilitate accurate interpretation and analysis of healthcare data. Also, by incorporating hierarchical relationships from the CONCEPT_ANCESTOR table, users can create cohorts containing related concepts within a hierarchical structure, enabling more comprehensive cohort definitions.",NA
 source_to_concept_map,VOCAB,No,NA,No,NA,NA,"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.",NA,NA
 drug_strength,VOCAB,No,NA,No,NA,NA,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.,NA,NA
 cohort,RESULTS,No,NA,No,NA,NA,The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. 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.,NA,"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"