diff --git a/docs/cdm54.html b/docs/cdm54.html index 5bb3a13..1d2a4d7 100644 --- a/docs/cdm54.html +++ b/docs/cdm54.html @@ -639,6 +639,7 @@ BIRTH_DAY, BIRTH_MONTH and BIRTH_YEAR.

For detailed conventions for how to populate this table, please refer to the THEMIS repository.

+

observation_period

@@ -837,21 +838,21 @@ identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the COHORT +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period">COHORT table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The CONDITION_ERA +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#condition_era">CONDITION_ERA table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the OBSERVATION +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation">OBSERVATION table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the OBSERVATION +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation">OBSERVATION table, if they are used for analyses. However, this information is not always available.

ETL Conventions

diff --git a/docs/dataModelConventions.html b/docs/dataModelConventions.html index bd6b1cd..613d1c4 100644 --- a/docs/dataModelConventions.html +++ b/docs/dataModelConventions.html @@ -603,7 +603,7 @@ the same Concept between releases of the Standardized Vocabularies.
  • A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional names and descriptions for the Concept are stored as Synonyms in the CONCEPT_SYNONYM +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM table.
  • Each Concept is assigned to a Domain. For Standard Concepts, there is always a single Domain. Source Concepts can be composite or @@ -631,7 +631,7 @@ participate in the construction of the CONCEPT_ANCESTOR table and can be used to identify Descendants that may appear in the data. See CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in *_source_concept_id fields and are not used in CONCEPT_ANCESTOR +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR table. Please refer to the Standardized Vocabularies specifications for details of the Standard Concept designation.
  • The lifespan of a Concept is recorded through its valid_start_date, @@ -760,12 +760,12 @@ concept_id_1 and concept_id_2 fields.
  • Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd Concepts are not captured in this table. However, the CONCEPT_ANCESTOR +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR table does this for hierarchical relationships over several “generations” of direct relationships.
  • In previous versions of the CDM, the relationship_id used to be a numerical identifier. See the RELATIONSHIP +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#relationship">RELATIONSHIP table.
    • @@ -790,7 +790,7 @@ purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concepts.
  • Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in the CONCEPT_ANCESTOR +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR table. For example, “has_ingredient” is a Relationship between Concept of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all Ingredients can be classified as the “parental” hierarchical Concepts @@ -806,16 +806,16 @@ same Vocabulary or those adopted from different Vocabulary sources.
  • The concept_synonym_name field contains a valid Synonym of a concept, including the description in the concept_name itself. I.e. each Concept has at least one Synonym in the CONCEPT_SYNONYM +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept">CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM table.
  • Only Synonyms that are active and current are stored in the CONCEPT_SYNONYM +href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies.
    • @@ -827,12 +827,12 @@ Vocabularies. diff --git a/inst/csv/OMOP_CDMv5.4_Field_Level.csv b/inst/csv/OMOP_CDMv5.4_Field_Level.csv index 0e7f9fa..fce5cce 100644 --- a/inst/csv/OMOP_CDMv5.4_Field_Level.csv +++ b/inst/csv/OMOP_CDMv5.4_Field_Level.csv @@ -1,14 +1,14 @@ cdmTableName,cdmFieldName,isRequired,cdmDatatype,userGuidance,etlConventions,isPrimaryKey,isForeignKey,fkTableName,fkFieldName,fkDomain,fkClass,unique DQ identifiers person,person_id,Yes,integer,It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.,"Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.",Yes,No,NA,NA,NA,NA,NA -person,gender_concept_id,Yes,integer,This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.,Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the [OBSERVATION](https://ohdsi.github.io/CommonDataModel/cdm531.html#observation) table. [Accepted gender concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=). Please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_gender_concept_id.html) for detailed conventions on how to populate this field.,No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA +person,gender_concept_id,Yes,integer,This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.,Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the [OBSERVATION](https://ohdsi.github.io/CommonDataModel/cdm54.html#observation) table. [Accepted gender concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=). Please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_gender_concept_id.html) for detailed conventions on how to populate this field.,No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA person,year_of_birth,Yes,integer,Compute age using year_of_birth.,"For data sources with date of birth, the year should be extracted. If no year of birth is available all the person's data should be dropped from the CDM instance. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_year_of_birth.html).",No,No,NA,NA,NA,NA,NA person,month_of_birth,No,integer,NA,"For data sources that provide the precise date of birth, the month should be extracted and stored in this field.",No,No,NA,NA,NA,NA,NA person,day_of_birth,No,integer,NA,"For data sources that provide the precise date of birth, the day should be extracted and stored in this field.",No,No,NA,NA,NA,NA,NA person,birth_datetime,No,datetime,NA,"This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. For more information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/person.html).",No,No,NA,NA,NA,NA,NA person,race_concept_id,Yes,integer,This field captures race or ethnic background of the person.,"Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. [Accepted Race Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Race&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Race,NA,NA person,ethnicity_concept_id,Yes,integer,"This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between ""Hispanic"" and ""Not Hispanic"". Races and ethnic backgrounds are not stored here.",Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. [Accepted ethnicity concepts](http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&standardConcept=Standard&page=1&pageSize=15&query=),No,Yes,CONCEPT,CONCEPT_ID,Ethnicity,NA,NA -person,location_id,No,integer,The location refers to the physical address of the person. This field should capture the last known location of the person.,"Put the location_id from the [LOCATION](https://ohdsi.github.io/CommonDataModel/cdm531.html#location) table here that represents the most granular location information for the person. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/populate_person_location_id.html).",No,Yes,LOCATION,LOCATION_ID,NA,NA,NA -person,provider_id,No,integer,The Provider refers to the last known primary care provider (General Practitioner).,"Put the provider_id from the [PROVIDER](https://ohdsi.github.io/CommonDataModel/cdm531.html#provider) table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA +person,location_id,No,integer,The location refers to the physical address of the person. This field should capture the last known location of the person.,"Put the location_id from the [LOCATION](https://ohdsi.github.io/CommonDataModel/cdm54.html#location) table here that represents the most granular location information for the person. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/populate_person_location_id.html).",No,Yes,LOCATION,LOCATION_ID,NA,NA,NA +person,provider_id,No,integer,The Provider refers to the last known primary care provider (General Practitioner).,"Put the provider_id from the [PROVIDER](https://ohdsi.github.io/CommonDataModel/cdm54.html#provider) table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA person,care_site_id,No,integer,The Care Site refers to where the Provider typically provides the primary care.,NA,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA person,person_source_value,No,varchar(50),Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.,Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.,No,No,NA,NA,NA,NA,NA person,gender_source_value,No,varchar(50),This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.,Put the assigned sex at birth of the person as it appears in the source data.,No,No,NA,NA,NA,NA,NA @@ -19,7 +19,7 @@ person,ethnicity_source_value,No,varchar(50),This field is used to store the eth person,ethnicity_source_concept_id,No,integer,"Due to the small number of options, this tends to be zero.","If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA observation_period,observation_period_id,Yes,integer,A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.,Assign a unique observation_period_id to each discrete Observation Period for a Person.,Yes,No,NA,NA,NA,NA,NA observation_period,person_id,Yes,integer,The Person ID of the PERSON record for which the Observation Period is recorded.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA -observation_period,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period).",No,No,NA,NA,NA,NA,NA +observation_period,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period).",No,No,NA,NA,NA,NA,NA observation_period,observation_period_end_date,Yes,date,Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.",No,No,NA,NA,NA,NA,NA observation_period,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA visit_occurrence,visit_occurrence_id,Yes,integer,Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.,This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.,Yes,No,NA,NA,NA,NA,NA @@ -36,7 +36,7 @@ For Inpatient Visits ongoing at the date of ETL, put date of processing the data - All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.",No,No,NA,NA,NA,NA,NA visit_occurrence,visit_end_datetime,No,datetime,"If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.","If no time is given for the end date of a visit, set it to midnight (00:00:0000).",No,No,NA,NA,NA,NA,NA visit_occurrence,visit_type_concept_id,Yes,Integer,"Use this field to understand the provenance of the visit record, or where the record comes from.","Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA -visit_occurrence,provider_id,No,integer,"There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.","If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail) table.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA +visit_occurrence,provider_id,No,integer,"There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.","If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm54.html#visit_detail) table.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA visit_occurrence,care_site_id,No,integer,This field provides information about the Care Site where the Visit took place.,There should only be one Care Site associated with a Visit.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA visit_occurrence,visit_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA visit_occurrence,visit_source_concept_id,No,integer,NA,If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA @@ -405,8 +405,8 @@ cdm_source,cdm_version_concept_id,Yes,integer,The Concept Id representing the ve cdm_source,vocabulary_version,Yes,varchar(20),Version of the OMOP standardised vocabularies loaded,You can find the version of your Vocabulary using the query: `SELECT vocabulary_version from vocabulary where vocabulary_id = 'None'`,No,No,NA,NA,NA,NA,NA concept,concept_id,Yes,integer,A unique identifier for each Concept across all domains.,NA,Yes,No,NA,NA,NA,NA,NA concept,concept_name,Yes,varchar(255),"An unambiguous, meaningful and descriptive name for the Concept.",NA,No,No,NA,NA,NA,NA,NA -concept,domain_id,Yes,varchar(20),A foreign key to the [DOMAIN](https://ohdsi.github.io/CommonDataModel/cdm531.html#domain) table the Concept belongs to.,NA,No,Yes,DOMAIN,DOMAIN_ID,NA,NA,NA -concept,vocabulary_id,Yes,varchar(20),"A foreign key to the [VOCABULARY](https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary) +concept,domain_id,Yes,varchar(20),A foreign key to the [DOMAIN](https://ohdsi.github.io/CommonDataModel/cdm54.html#domain) table the Concept belongs to.,NA,No,Yes,DOMAIN,DOMAIN_ID,NA,NA,NA +concept,vocabulary_id,Yes,varchar(20),"A foreign key to the [VOCABULARY](https://ohdsi.github.io/CommonDataModel/cdm54.html#vocabulary) table indicating from which source the Concept has been adapted.",NA,No,Yes,VOCABULARY,VOCABULARY_ID,NA,NA,NA concept,concept_class_id,Yes,varchar(20),"The attribute or concept class of the @@ -479,7 +479,7 @@ relationship,reverse_relationship_id,Yes,varchar(20),"The identifier for the rel define the reverse relationship between two concepts.",NA,No,No,NA,NA,NA,NA,NA relationship,relationship_concept_id,Yes,integer,"A foreign key that refers to an identifier in -the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept) table for the unique +the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept) table for the unique relationship concept.",NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA concept_synonym,concept_id,Yes,integer,NA,NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA concept_synonym,concept_synonym_name,Yes,varchar(1000),NA,NA,No,No,NA,NA,NA,NA,NA diff --git a/rmd/dataModelConventions.Rmd b/rmd/dataModelConventions.Rmd index 6bd2542..59d686b 100644 --- a/rmd/dataModelConventions.Rmd +++ b/rmd/dataModelConventions.Rmd @@ -42,7 +42,7 @@ corresponding Concept reference data. - The concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of the Standardized Vocabularies. - A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional -names and descriptions for the Concept are stored as Synonyms in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym) +names and descriptions for the Concept are stored as Synonyms in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym) table. - Each Concept is assigned to a Domain. For Standard Concepts, there is always a single Domain. Source Concepts can be composite or coordinated entities, and therefore can belong to more than one Domain. @@ -61,7 +61,7 @@ field and can be used to reference the source vocabulary. in all *_concept_id fields, whereas Classification Concepts (‘C’) should not appear in the CDM data, but participate in the construction of the CONCEPT_ANCESTOR table and can be used to identify Descendants that may appear in the data. See CONCEPT_ANCESTOR table. Non-standard -Concepts can only appear in *_source_concept_id fields and are not used in [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor) +Concepts can only appear in *_source_concept_id fields and are not used in [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor) table. Please refer to the Standardized Vocabularies specifications for details of the Standard Concept designation. - The lifespan of a Concept is recorded through its valid_start_date, valid_end_date and the invalid_ @@ -144,10 +144,10 @@ and the relationship_id replaced by the reverse_relationship_id from the RELATIO not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2 fields. - Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd -Concepts are not captured in this table. However, the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor) table does this for +Concepts are not captured in this table. However, the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor) table does this for hierarchical relationships over several “generations” of direct relationships. - In previous versions of the CDM, the relationship_id used to be a numerical identifier. See the -[RELATIONSHIP](https://ohdsi.github.io/CommonDataModel/cdm531.html#relationship) table. +[RELATIONSHIP](https://ohdsi.github.io/CommonDataModel/cdm54.html#relationship) table. ### Relationship Table - There is one record for each Relationship. @@ -163,7 +163,7 @@ Relationship is provided in the reverse_relationship_id field. concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concepts. - Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in -the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor) table. For example, “has_ingredient” is a Relationship between Concept +the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor) table. For example, “has_ingredient” is a Relationship between Concept of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all Ingredients can be classified as the “parental” hierarchical Concepts for the drug products they are part of. All ‘Is a’ Relationships are hierarchical. @@ -172,19 +172,19 @@ from different Vocabulary sources. ### Concept Synonyms - The concept_synonym_name field contains a valid Synonym of a concept, including the description in -the concept_name itself. I.e. each Concept has at least one Synonym in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym) +the concept_name itself. I.e. each Concept has at least one Synonym in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym) table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the -concept_name of the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept) table, then the Preferred Term and Synonyms associated with the Concept are stored in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym) table. -- Only Synonyms that are active and current are stored in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym) table. Tracking +concept_name of the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept) table, then the Preferred Term and Synonyms associated with the Concept are stored in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym) table. +- Only Synonyms that are active and current are stored in the [CONCEPT_SYNONYM](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym) table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies. - Currently, only English Synonyms are included. ### Concept Ancestor - Each concept is also recorded as an ancestor of itself. -- Only valid and Standard Concepts participate in the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor) table. It is not possible +- Only valid and Standard Concepts participate in the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor) table. It is not possible to find ancestors or descendants of deprecated or Source Concepts. -- Usually, only Concepts of the same Domain are connected through records of the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor) table, but there might be exceptions. +- Usually, only Concepts of the same Domain are connected through records of the [CONCEPT_ANCESTOR](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor) table, but there might be exceptions. ### Source to Concept Map - This table is no longer used to distribute mapping information between source codes and Standard