mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #718 from lawrenceadams/lawrenceadams-fix-54-docs-links 

Fix dead 5.3.1 CDM links
This commit is contained in:
clairblacketer 2025-03-06 08:41:52 -05:00 committed by GitHub
parent 9b5f756648 720b5480e9
commit 033253f49a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
5 changed files with 80 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
docs/cdm54.html
View File

@ -715,7 +715,7 @@ 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 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 that it is the biological sex at birth. If the source data captures
gender identity it should be stored in the <a gender identity it should be stored in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation">OBSERVATION</a>
table. <a table. <a
href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted href="http://athena.ohdsi.org/search-terms/terms?domain=Gender&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
gender concepts</a>. Please refer to the <a gender concepts</a>. Please refer to the <a
@ -939,7 +939,7 @@ should capture the last known location of the person.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
Put the location_id from the <a Put the location_id from the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#location">LOCATION</a>
table here that represents the most granular location information for table here that represents the most granular location information for
the person. For additional information on how to populate this field, the person. For additional information on how to populate this field,
please refer to the <a please refer to the <a
@ -974,7 +974,7 @@ Practitioner).
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
Put the provider_id from the <a Put the provider_id from the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#provider">PROVIDER</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#provider">PROVIDER</a>
table of the last known general practitioner of the person. If there are 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. multiple providers, it is up to the ETL to decide which to put here.
</td> </td>
@ -1379,7 +1379,7 @@ insurance claim data, the Observation Period can be considered as the
time period the Person is enrolled with a payer. If a Person switches 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 plans but stays with the same payer, and therefore capturing of data
continues, that change would be captured in <a continues, that change would be captured in <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">PAYER_PLAN_PERIOD</a>. href="https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period">PAYER_PLAN_PERIOD</a>.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
date date
@ -1879,7 +1879,7 @@ PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.
If there are multiple providers associated with a visit, you will need 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 to choose which one to put here. The additional providers can be stored
in the <a in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail">VISIT_DETAIL</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#visit_detail">VISIT_DETAIL</a>
table. table.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
@ -2858,21 +2858,21 @@ identifying Persons who should suffer from the recorded Condition.
Record all conditions as they exist in the source data. Any decisions Record all conditions as they exist in the source data. Any decisions
about diagnosis/phenotype definitions would be done through cohort about diagnosis/phenotype definitions would be done through cohort
specifications. These cohorts can be housed in the <a specifications. These cohorts can be housed in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period">COHORT</a>
table. Conditions span a time interval from start to end, but are table. Conditions span a time interval from start to end, but are
typically recorded as single snapshot records with no end date. The 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 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 known and later not recorded, and (ii) the Persons typically cease
interacting with the healthcare system when they feel better, which interacting with the healthcare system when they feel better, which
leads to incomplete capture of resolved Conditions. The <a leads to incomplete capture of resolved Conditions. The <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#condition_era">CONDITION_ERA</a>
table addresses this issue. Family history and past diagnoses (‘history table addresses this issue. Family history and past diagnoses (‘history
of’) are not recorded in this table. Instead, they are listed in the <a of’) are not recorded in this table. Instead, they are listed in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation">OBSERVATION</a>
table. Codes written in the process of establishing the diagnosis, such table. Codes written in the process of establishing the diagnosis, such
as ‘question of’ of and ‘rule out’, should not represented here. as ‘question of’ of and ‘rule out’, should not represented here.
Instead, they should be recorded in the <a Instead, they should be recorded in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation">OBSERVATION</a>
table, if they are used for analyses. However, this information is not table, if they are used for analyses. However, this information is not
always available.</p> always available.</p>
<p><strong>ETL Conventions</strong></p> <p><strong>ETL Conventions</strong></p>
@ -13163,7 +13163,7 @@ domain_id
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
A foreign key to the <a A foreign key to the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#domain">DOMAIN</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#domain">DOMAIN</a>
table the Concept belongs to. table the Concept belongs to.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
@ -13192,7 +13192,7 @@ vocabulary_id
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
A foreign key to the <a A foreign key to the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary">VOCABULARY</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#vocabulary">VOCABULARY</a>
table indicating from which source the Concept has been adapted. table indicating from which source the Concept has been adapted.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
@ -14241,7 +14241,7 @@ relationship_concept_id
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">
A foreign key that refers to an identifier in the <a A foreign key that refers to an identifier in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept">CONCEPT</a>
table for the unique relationship concept. table for the unique relationship concept.
</td> </td>
<td style="text-align:left;"> <td style="text-align:left;">

22
docs/dataModelConventions.html
View File

@ -603,7 +603,7 @@ the same Concept between releases of the Standardized Vocabularies.</li>
<li>A descriptive name for each Concept is stored as the Concept Name as <li>A descriptive name for each Concept is stored as the Concept Name as
part of the CONCEPT table. Additional names and descriptions for the part of the CONCEPT table. Additional names and descriptions for the
Concept are stored as Synonyms in the <a Concept are stored as Synonyms in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM</a>
table.</li> table.</li>
<li>Each Concept is assigned to a Domain. For Standard Concepts, there <li>Each Concept is assigned to a Domain. For Standard Concepts, there
is always a single Domain. Source Concepts can be composite or 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 used to identify Descendants that may appear in the data. See
CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in CONCEPT_ANCESTOR table. Non-standard Concepts can only appear in
*_source_concept_id fields and are not used in <a *_source_concept_id fields and are not used in <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR</a>
table. Please refer to the Standardized Vocabularies specifications for table. Please refer to the Standardized Vocabularies specifications for
details of the Standard Concept designation.</li> details of the Standard Concept designation.</li>
<li>The lifespan of a Concept is recorded through its valid_start_date, <li>The lifespan of a Concept is recorded through its valid_start_date,
@ -760,12 +760,12 @@ concept_id_1 and concept_id_2 fields.</li>
<li>Concept Relationships define direct relationships between Concepts. <li>Concept Relationships define direct relationships between Concepts.
Indirect relationships through 3rd Concepts are not captured in this Indirect relationships through 3rd Concepts are not captured in this
table. However, the <a table. However, the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR</a>
table does this for hierarchical relationships over several table does this for hierarchical relationships over several
“generations” of direct relationships.</li> “generations” of direct relationships.</li>
<li>In previous versions of the CDM, the relationship_id used to be a <li>In previous versions of the CDM, the relationship_id used to be a
numerical identifier. See the <a numerical identifier. See the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#relationship">RELATIONSHIP</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#relationship">RELATIONSHIP</a>
table.</li> table.</li>
</ul> </ul>
</div> </div>
@ -790,7 +790,7 @@ purposes of creating a closed Information Model, where all entities in
the OMOP CDM are covered by unique Concepts.</li> the OMOP CDM are covered by unique Concepts.</li>
<li>Hierarchical Relationships are used to build a hierarchical tree out <li>Hierarchical Relationships are used to build a hierarchical tree out
of the Concepts, which is recorded in the <a of the Concepts, which is recorded in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR</a>
table. For example, “has_ingredient” is a Relationship between Concept table. For example, “has_ingredient” is a Relationship between Concept
of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all of the Concept Class ‘Clinical Drug’ and those of ‘Ingredient’, and all
Ingredients can be classified as the “parental” hierarchical Concepts Ingredients can be classified as the “parental” hierarchical Concepts
@ -806,16 +806,16 @@ same Vocabulary or those adopted from different Vocabulary sources.</li>
<li>The concept_synonym_name field contains a valid Synonym of a <li>The concept_synonym_name field contains a valid Synonym of a
concept, including the description in the concept_name itself. I.e. each concept, including the description in the concept_name itself. I.e. each
Concept has at least one Synonym in the <a Concept has at least one Synonym in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM</a>
table. As an example, for a SNOMED-CT Concept, if the fully specified table. As an example, for a SNOMED-CT Concept, if the fully specified
name is stored as the concept_name of the <a name is stored as the concept_name of the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept">CONCEPT</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept">CONCEPT</a>
table, then the Preferred Term and Synonyms associated with the Concept table, then the Preferred Term and Synonyms associated with the Concept
are stored in the <a are stored in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM</a>
table.</li> table.</li>
<li>Only Synonyms that are active and current are stored in the <a <li>Only Synonyms that are active and current are stored in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_synonym">CONCEPT_SYNONYM</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_synonym">CONCEPT_SYNONYM</a>
table. Tracking synonym/description history and mapping of obsolete table. Tracking synonym/description history and mapping of obsolete
synonyms to current Concepts/Synonyms is out of scope for the Standard synonyms to current Concepts/Synonyms is out of scope for the Standard
Vocabularies.</li> Vocabularies.</li>
@ -827,12 +827,12 @@ Vocabularies.</li>
<ul> <ul>
<li>Each concept is also recorded as an ancestor of itself.</li> <li>Each concept is also recorded as an ancestor of itself.</li>
<li>Only valid and Standard Concepts participate in the <a <li>Only valid and Standard Concepts participate in the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR</a>
table. It is not possible to find ancestors or descendants of deprecated table. It is not possible to find ancestors or descendants of deprecated
or Source Concepts.</li> or Source Concepts.</li>
<li>Usually, only Concepts of the same Domain are connected through <li>Usually, only Concepts of the same Domain are connected through
records of the <a records of the <a
href="https://ohdsi.github.io/CommonDataModel/cdm531.html#concept_ancestor">CONCEPT_ANCESTOR</a> href="https://ohdsi.github.io/CommonDataModel/cdm54.html#concept_ancestor">CONCEPT_ANCESTOR</a>
table, but there might be exceptions.</li> table, but there might be exceptions.</li>
</ul> </ul>
</div> </div>

16
inst/csv/OMOP_CDMv5.4_Field_Level.csv
View File

@ -1,14 +1,14 @@
cdmTableName,cdmFieldName,isRequired,cdmDatatype,userGuidance,etlConventions,isPrimaryKey,isForeignKey,fkTableName,fkFieldName,fkDomain,fkClass,unique DQ identifiers 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,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,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,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,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,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,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,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,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/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,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,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,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 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 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,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,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,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 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 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 - 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_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,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,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_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 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 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_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,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,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/cdm531.html#vocabulary) 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 table indicating from which source the
Concept has been adapted.",NA,No,Yes,VOCABULARY,VOCABULARY_ID,NA,NA,NA 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 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 define the reverse relationship between two
concepts.",NA,No,No,NA,NA,NA,NA,NA concepts.",NA,No,No,NA,NA,NA,NA,NA
relationship,relationship_concept_id,Yes,integer,"A foreign key that refers to an identifier in 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 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_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 concept_synonym,concept_synonym_name,Yes,varchar(1000),NA,NA,No,No,NA,NA,NA,NA,NA

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
2 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
3 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. 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
4 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
5 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
6 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
7 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
8 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
9 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
10 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). 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
11 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. 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
12 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
13 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
14 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 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
20 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
21 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
22 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). 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
23 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
24 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
25 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 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
37 visit_occurrence admitted_from_concept_id No integer Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example. If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0. No Yes CONCEPT CONCEPT_ID Visit NA NA
38 visit_occurrence admitted_from_source_value No varchar(50) NA This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits. No No NA NA NA NA NA
39 visit_occurrence discharged_to_concept_id No integer Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for "home". Use concept id = 0 when a person is discharged to home. If available, map the discharged_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit NA NA
40 visit_occurrence discharged_to_source_value No varchar(50) NA This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more. No No NA NA NA NA NA
41 visit_occurrence preceding_visit_occurrence_id No integer Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between. This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a "following_visit_id". No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
42 visit_detail visit_detail_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 detail. 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
405 source_to_concept_map source_code_description No varchar(255) 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. NA No No NA NA NA NA NA
406 source_to_concept_map target_concept_id Yes integer The target Concept to which the source code is being mapped. NA No Yes CONCEPT CONCEPT_ID NA NA NA
407 source_to_concept_map target_vocabulary_id Yes varchar(20) The Vocabulary of the target Concept. NA No Yes VOCABULARY VOCABULARY_ID NA NA NA
408 source_to_concept_map valid_start_date Yes date The date when the mapping instance was first recorded. NA No No NA NA NA NA NA
409 source_to_concept_map valid_end_date Yes 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. NA No No NA NA NA NA NA
410 source_to_concept_map invalid_reason No varchar(1) 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. NA No No NA NA NA NA NA
411 drug_strength drug_concept_id Yes integer The Concept representing the Branded Drug or Clinical Drug Product. NA No Yes CONCEPT CONCEPT_ID NA NA NA
412 drug_strength ingredient_concept_id Yes integer 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. No Yes CONCEPT CONCEPT_ID NA NA NA
479
480
481
482
483
484
485

2
inst/csv/OMOP_CDMv5.4_Table_Level.csv
View File

@ -17,7 +17,7 @@ visit_occurrence,CDM,No,VISIT_,Yes,0,NA,"This table contains Events where Person
The Visit duration, or 'length of stay', is defined as VISIT_END_DATE - VISIT_START_DATE. For all Visits this is <1 day, except Inpatient Visits and Non-hospital institution Visits. The CDM also contains the VISIT_DETAIL table where additional information about the Visit is stored, for example, transfers between units during an inpatient Visit.","Visits can be derived easily if the source data contain coding systems for Place of Service or Procedures, like CPT codes for well visits. In those cases, the codes can be looked up and mapped to a Standard Visit Concept. Otherwise, Visit Concepts have to be identified in the ETL process. This table will contain concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. Visits can be adjacent to each other, i.e. the end date of one can be identical with the start date of the other. As a consequence, more than one-day Visits or their descendants can be recorded for the same day. Multi-day visits must not overlap, i.e. share days other than start and end days. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. For example, in US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. Providers can be associated with a Visit through the PROVIDER_ID field, or indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT and PROVIDER tables." The Visit duration, or 'length of stay', is defined as VISIT_END_DATE - VISIT_START_DATE. For all Visits this is <1 day, except Inpatient Visits and Non-hospital institution Visits. The CDM also contains the VISIT_DETAIL table where additional information about the Visit is stored, for example, transfers between units during an inpatient Visit.","Visits can be derived easily if the source data contain coding systems for Place of Service or Procedures, like CPT codes for well visits. In those cases, the codes can be looked up and mapped to a Standard Visit Concept. Otherwise, Visit Concepts have to be identified in the ETL process. This table will contain concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. Visits can be adjacent to each other, i.e. the end date of one can be identical with the start date of the other. As a consequence, more than one-day Visits or their descendants can be recorded for the same day. Multi-day visits must not overlap, i.e. share days other than start and end days. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. For example, in US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences. Providers can be associated with a Visit through the PROVIDER_ID field, or indirectly through PROCEDURE_OCCURRENCE records linked both to the VISIT and PROVIDER tables."
visit_detail,CDM,No,VISIT_DETAIL_,Yes,0,NA,The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.,"The configuration defining the Visit Detail is described by Concepts in the Visit Domain, which form a hierarchical structure. The Visit Detail record will have an associated to the Visit Occurrence record in two ways: <br> 1. The Visit Detail record will have the VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID will be a descendant of the VISIT_CONCEPT_ID for the Visit.","It is not mandatory that the VISIT_DETAIL table be filled in, but if you find that the logic to create VISIT_OCCURRENCE records includes the roll-up of multiple smaller records to create one picture of a Visit then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to [9201](https://athena.ohdsi.org/search-terms/terms/9201) and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care." visit_detail,CDM,No,VISIT_DETAIL_,Yes,0,NA,The VISIT_DETAIL table is an optional table used to represents details of each record in the parent VISIT_OCCURRENCE table. A good example of this would be the movement between units in a hospital during an inpatient stay or claim lines associated with a one insurance claim. For every record in the VISIT_OCCURRENCE table there may be 0 or more records in the VISIT_DETAIL table with a 1:n relationship where n may be 0. The VISIT_DETAIL table is structurally very similar to VISIT_OCCURRENCE table and belongs to the visit domain.,"The configuration defining the Visit Detail is described by Concepts in the Visit Domain, which form a hierarchical structure. The Visit Detail record will have an associated to the Visit Occurrence record in two ways: <br> 1. The Visit Detail record will have the VISIT_OCCURRENCE_ID it is associated to 2. The VISIT_DETAIL_CONCEPT_ID will be a descendant of the VISIT_CONCEPT_ID for the Visit.","It is not mandatory that the VISIT_DETAIL table be filled in, but if you find that the logic to create VISIT_OCCURRENCE records includes the roll-up of multiple smaller records to create one picture of a Visit then it is a good idea to use VISIT_DETAIL. In EHR data, for example, a Person may be in the hospital but instead of one over-arching Visit their encounters are recorded as times they interacted with a health care provider. A Person in the hospital interacts with multiple providers multiple times a day so the encounters must be strung together using some heuristic (defined by the ETL) to identify the entire Visit. In this case the encounters would be considered Visit Details and the entire Visit would be the Visit Occurrence. In this example it is also possible to use the Vocabulary to distinguish Visit Details from a Visit Occurrence by setting the VISIT_CONCEPT_ID to [9201](https://athena.ohdsi.org/search-terms/terms/9201) and the VISIT_DETAIL_CONCEPT_IDs either to 9201 or its children to indicate where the patient was in the hospital at the time of care."
condition_occurrence,CDM,No,CONDITION_,Yes,0,NA,"This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.","Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when 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](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period) 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](https://ohdsi.github.io/CommonDataModel/cdm531.html#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](https://ohdsi.github.io/CommonDataModel/cdm531.html#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](https://ohdsi.github.io/CommonDataModel/cdm531.html#observation) table, if they are used for analyses. However, this information is not always available.",Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here. condition_occurrence,CDM,No,CONDITION_,Yes,0,NA,"This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.","Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when 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](https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period) 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](https://ohdsi.github.io/CommonDataModel/cdm54.html#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](https://ohdsi.github.io/CommonDataModel/cdm54.html#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](https://ohdsi.github.io/CommonDataModel/cdm54.html#observation) table, if they are used for analyses. However, this information is not always available.",Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.
drug_exposure,CDM,No,DRUG_,Yes,0,NA,"This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.","The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.","Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.<br><br>For detailed conventions on how to populate this table, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/drug_exposure.html)." drug_exposure,CDM,No,DRUG_,Yes,0,NA,"This table captures records about the exposure to a Drug ingested or otherwise introduced into the body. A Drug is a biochemical substance formulated in such a way that when administered to a Person it will exert a certain biochemical effect on the metabolism. Drugs include prescription and over-the-counter medicines, vaccines, and large-molecule biologic therapies. Radiological devices ingested or applied locally do not count as Drugs.","The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.","Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.<br><br>For detailed conventions on how to populate this table, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/drug_exposure.html)."
procedure_occurrence,CDM,No,PROCEDURE_,Yes,0,NA,"This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.","Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.","When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here." procedure_occurrence,CDM,No,PROCEDURE_,Yes,0,NA,"This table contains records of activities or processes ordered by, or carried out by, a healthcare provider on the patient with a diagnostic or therapeutic purpose.","Lab tests are not a procedure, if something is observed with an expected resulting amount and unit then it should be a measurement. Phlebotomy is a procedure but so trivial that it tends to be rarely captured. It can be assumed that there is a phlebotomy procedure associated with many lab tests, therefore it is unnecessary to add them as separate procedures. If the user finds the same procedure over concurrent days, it is assumed those records are part of a procedure lasting more than a day. This logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.","When dealing with duplicate records, the ETL must determine whether to sum them up into one record or keep them separate. Things to consider are: - Same Procedure - Same PROCEDURE_DATETIME - Same Visit Occurrence or Visit Detail - Same Provider - Same Modifier for Procedures. Source codes and source text fields mapped to Standard Concepts of the Procedure Domain have to be recorded here."
device_exposure,CDM,No,DEVICE_,Yes,0,NA,"The Device domain captures information about a person's exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).","The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.",Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here. device_exposure,CDM,No,DEVICE_,Yes,0,NA,"The Device domain captures information about a person's exposure to a foreign physical object or instrument which is used for diagnostic or therapeutic purposes through a mechanism beyond chemical action. Devices include implantable objects (e.g. pacemakers, stents, artificial joints), medical equipment and supplies (e.g. bandages, crutches, syringes), other instruments used in medical procedures (e.g. sutures, defibrillators) and material used in clinical care (e.g. adhesives, body material, dental material, surgical material).","The distinction between Devices or supplies and Procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.",Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.

1 cdmTableName schema isRequired conceptPrefix measurePersonCompleteness measurePersonCompletenessThreshold validation tableDescription userGuidance etlConventions
17 location CDM No NA No NA NA The LOCATION table represents a generic way to capture physical location or address information of Persons and Care Sites. The current iteration of the LOCATION table is US centric. Until a major release to correct this, certain fields can be used to represent different international values. <br><br> - STATE can also be used for province or district<br>- ZIP is also the postal code or postcode <br>- COUNTY can also be used to represent region Each address or Location is unique and is present only once in the table. Locations do not contain names, such as the name of a hospital. In order to construct a full address that can be used in the postal service, the address information from the Location needs to be combined with information from the Care Site.
18 care_site CDM No NA No NA NA The CARE_SITE table contains a list of uniquely identified institutional (physical or organizational) units where healthcare delivery is practiced (offices, wards, hospitals, clinics, etc.). NA Care site is a unique combination of location_id and nature of the site - the latter could be the place of service, name, or another characteristic in your source data. Care site does not take into account the provider (human) information such a specialty. Many source data do not make a distinction between individual and institutional providers. The CARE_SITE table contains the institutional providers. If the source, instead of uniquely identifying individual Care Sites, only provides limited information such as Place of Service, generic or "pooled" Care Site records are listed in the CARE_SITE table. There can be hierarchical and business relationships between Care Sites. For example, wards can belong to clinics or departments, which can in turn belong to hospitals, which in turn can belong to hospital systems, which in turn can belong to HMOs.The relationships between Care Sites are defined in the FACT_RELATIONSHIP table.<br><br>For additional detailed conventions on how to populate this table, please refer to [THEMIS repository](https://ohdsi.github.io/Themis/care_site.html).
19 provider CDM No NA No NA NA The PROVIDER table contains a list of uniquely identified healthcare providers; duplication is not allowed. These are individuals providing hands-on healthcare to patients, such as physicians, nurses, midwives, physical therapists etc. Many sources do not make a distinction between individual and institutional providers. The PROVIDER table contains the individual providers. If the source only provides limited information such as specialty instead of uniquely identifying individual providers, generic or 'pooled' Provider records are listed in the PROVIDER table. NA
20 payer_plan_period CDM No NA Yes 0 NA The PAYER_PLAN_PERIOD table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Each Person receiving healthcare is typically covered by a health benefit plan, which pays for (fully or partially), or directly provides, the care. These benefit plans are provided by payers, such as health insurances or state or government agencies. In each plan the details of the health benefits are defined for the Person or her family, and the health benefit Plan might change over time typically with increasing utilization (reaching certain cost thresholds such as deductibles), plan availability and purchasing choices of the Person. The unique combinations of Payer organizations, health benefit Plans and time periods in which they are valid for a Person are recorded in this table. A Person can have multiple, overlapping, Payer_Plan_Periods in this table. For example, medical and drug coverage in the US can be represented by two Payer_Plan_Periods. The details of the benefit structure of the Plan is rarely known, the idea is just to identify that the Plans are different. NA
21 cost CDM No NA No NA NA The COST table captures records containing the cost of any medical event recorded in one of the OMOP clinical event tables such as DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, VISIT_OCCURRENCE, VISIT_DETAIL, DEVICE_OCCURRENCE, OBSERVATION or MEASUREMENT. Each record in the cost table account for the amount of money transacted for the clinical event. So, the COST table may be used to represent both receivables (charges) and payments (paid), each transaction type represented by its COST_CONCEPT_ID. The COST_TYPE_CONCEPT_ID field will use concepts in the Standardized Vocabularies to designate the source (provenance) of the cost data. A reference to the health plan information in the PAYER_PLAN_PERIOD table is stored in the record for information used for the adjudication system to determine the persons benefit for the clinical event. When dealing with summary costs, the cost of the goods or services the provider provides is often not known directly, but derived from the hospital charges multiplied by an average cost-to-charge ratio. One cost record is generated for each response by a payer. In a claims databases, the payment and payment terms reported by the payer for the goods or services billed will generate one cost record. If the source data has payment information for more than one payer (i.e. primary insurance and secondary insurance payment for one entity), then a cost record is created for each reporting payer. Therefore, it is possible for one procedure to have multiple cost records for each payer, but typically it contains one or no record per entity. Payer reimbursement cost records will be identified by using the PAYER_PLAN_ID field. Drug costs are composed of ingredient cost (the amount charged by the wholesale distributor or manufacturer), the dispensing fee (the amount charged by the pharmacy and the sales tax).
22 drug_era CDM No NA Yes 0 NA A Drug Era is defined as a span of time when the Person is assumed to be exposed to a particular active ingredient. A Drug Era is not the same as a Drug Exposure: Exposures are individual records corresponding to the source when Drug was delivered to the Person, while successive periods of Drug Exposures are combined under certain rules to produce continuous Drug Eras. Every record in the DRUG_EXPOSURE table should be part of a drug era based on the dates of exposure. NA The SQL script for generating DRUG_ERA records can be found [here](https://ohdsi.github.io/CommonDataModel/sqlScripts.html#drug_eras).
23 dose_era CDM No NA Yes 0 NA A Dose Era is defined as a span of time when the Person is assumed to be exposed to a constant dose of a specific active ingredient. NA Dose Eras will be derived from records in the DRUG_EXPOSURE table and the Dose information from the DRUG_STRENGTH table using a standardized algorithm. Dose Form information is not taken into account. So, if the patient changes between different formulations, or different manufacturers with the same formulation, the Dose Era is still spanning the entire time of exposure to the Ingredient.

20
rmd/dataModelConventions.Rmd
View File

@ -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 concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of
the Standardized Vocabularies. the Standardized Vocabularies.
- A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional - 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. table.
- Each Concept is assigned to a Domain. For Standard Concepts, there is always a single Domain. Source - 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. 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 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 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 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 table. Please refer to the Standardized Vocabularies specifications for details of the Standard Concept
designation. designation.
- The lifespan of a Concept is recorded through its valid_start_date, valid_end_date and the invalid_ - 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 not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2
fields. fields.
- Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd - 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. 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 - 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 ### Relationship Table
- There is one record for each Relationship. - 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 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. 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 - 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 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 the “parental” hierarchical Concepts for the drug products they are part of. All ‘Is a’ Relationships are
hierarchical. hierarchical.
@ -172,19 +172,19 @@ from different Vocabulary sources.
### Concept Synonyms ### Concept Synonyms
- The concept_synonym_name field contains a valid Synonym of a concept, including the description in - 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 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. 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/cdm531.html#concept_synonym) table. Tracking - 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 synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out
of scope for the Standard Vocabularies. of scope for the Standard Vocabularies.
- Currently, only English Synonyms are included. - Currently, only English Synonyms are included.
### Concept Ancestor ### Concept Ancestor
- Each concept is also recorded as an ancestor of itself. - 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. 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 ### Source to Concept Map
- This table is no longer used to distribute mapping information between source codes and Standard - This table is no longer used to distribute mapping information between source codes and Standard