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

fix: dead links for 5.4 docs source csvs

This commit is contained in:
Lawrence Adams 2024-10-02 08:13:13 +01:00
parent 17b2d139c7
commit c84042399c
2 changed files with 49 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
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
person,person_id,Yes,integer,It is assumed that every person with a different unique identifier is in fact a different person and should be treated independently.,"Any person linkage that needs to occur to uniquely identify Persons ought to be done prior to writing this table. This identifier can be the original id from the source data provided if it is an integer, otherwise it can be an autogenerated number.",Yes,No,NA,NA,NA,NA,NA
person,gender_concept_id,Yes,integer,This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.,Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the [OBSERVATION](https://ohdsi.github.io/CommonDataModel/cdm531.html#observation) table. [Accepted gender concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=). Please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_gender_concept_id.html) for detailed conventions on how to populate this field.,No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA
person,gender_concept_id,Yes,integer,This field is meant to capture the biological sex at birth of the Person. This field should not be used to study gender identity issues.,Use the gender or sex value present in the data under the assumption that it is the biological sex at birth. If the source data captures gender identity it should be stored in the [OBSERVATION](https://ohdsi.github.io/CommonDataModel/cdm54.html#observation) table. [Accepted gender concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=). Please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_gender_concept_id.html) for detailed conventions on how to populate this field.,No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA
person,year_of_birth,Yes,integer,Compute age using year_of_birth.,"For data sources with date of birth, the year should be extracted. If no year of birth is available all the person's data should be dropped from the CDM instance. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_year_of_birth.html).",No,No,NA,NA,NA,NA,NA
person,month_of_birth,No,integer,NA,"For data sources that provide the precise date of birth, the month should be extracted and stored in this field.",No,No,NA,NA,NA,NA,NA
person,day_of_birth,No,integer,NA,"For data sources that provide the precise date of birth, the day should be extracted and stored in this field.",No,No,NA,NA,NA,NA,NA
person,birth_datetime,No,datetime,NA,"This field is not required but highly encouraged. For data sources that provide the precise datetime of birth, that value should be stored in this field. For more information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/person.html).",No,No,NA,NA,NA,NA,NA
person,race_concept_id,Yes,integer,This field captures race or ethnic background of the person.,"Only use this field if you have information about race or ethnic background. The Vocabulary contains Concepts about the main races and ethnic backgrounds in a hierarchical system. Due to the imprecise nature of human races and ethnic backgrounds, this is not a perfect system. Mixed races are not supported. If a clear race or ethnic background cannot be established, use Concept_Id 0. [Accepted Race Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Race&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Race,NA,NA
person,ethnicity_concept_id,Yes,integer,"This field captures Ethnicity as defined by the Office of Management and Budget (OMB) of the US Government: it distinguishes only between ""Hispanic"" and ""Not Hispanic"". Races and ethnic backgrounds are not stored here.",Only use this field if you have US-based data and a source of this information. Do not attempt to infer Ethnicity from the race or ethnic background of the Person. [Accepted ethnicity concepts](http://athena.ohdsi.org/search-terms/terms?domain=Ethnicity&standardConcept=Standard&page=1&pageSize=15&query=),No,Yes,CONCEPT,CONCEPT_ID,Ethnicity,NA,NA
person,location_id,No,integer,The location refers to the physical address of the person. This field should capture the last known location of the person.,"Put the location_id from the [LOCATION](https://ohdsi.github.io/CommonDataModel/cdm531.html#location) table here that represents the most granular location information for the person. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/populate_person_location_id.html).",No,Yes,LOCATION,LOCATION_ID,NA,NA,NA
person,provider_id,No,integer,The Provider refers to the last known primary care provider (General Practitioner).,"Put the provider_id from the [PROVIDER](https://ohdsi.github.io/CommonDataModel/cdm531.html#provider) table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
person,location_id,No,integer,The location refers to the physical address of the person. This field should capture the last known location of the person.,"Put the location_id from the [LOCATION](https://ohdsi.github.io/CommonDataModel/cdm54.html#location) table here that represents the most granular location information for the person. For additional information on how to populate this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/populate_person_location_id.html).",No,Yes,LOCATION,LOCATION_ID,NA,NA,NA
person,provider_id,No,integer,The Provider refers to the last known primary care provider (General Practitioner).,"Put the provider_id from the [PROVIDER](https://ohdsi.github.io/CommonDataModel/cdm54.html#provider) table of the last known general practitioner of the person. If there are multiple providers, it is up to the ETL to decide which to put here.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
person,care_site_id,No,integer,The Care Site refers to where the Provider typically provides the primary care.,NA,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
person,person_source_value,No,varchar(50),Use this field to link back to persons in the source data. This is typically used for error checking of ETL logic.,Some use cases require the ability to link back to persons in the source data. This field allows for the storing of the person value as it appears in the source. This field is not required but strongly recommended.,No,No,NA,NA,NA,NA,NA
person,gender_source_value,No,varchar(50),This field is used to store the biological sex of the person from the source data. It is not intended for use in standard analytics but for reference only.,Put the assigned sex at birth of the person as it appears in the source data.,No,No,NA,NA,NA,NA,NA
@ -19,7 +19,7 @@ person,ethnicity_source_value,No,varchar(50),This field is used to store the eth
person,ethnicity_source_concept_id,No,integer,"Due to the small number of options, this tends to be zero.","If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
observation_period,observation_period_id,Yes,integer,A Person can have multiple discrete Observation Periods which are identified by the Observation_Period_Id.,Assign a unique observation_period_id to each discrete Observation Period for a Person.,Yes,No,NA,NA,NA,NA,NA
observation_period,person_id,Yes,integer,The Person ID of the PERSON record for which the Observation Period is recorded.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
observation_period,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period).",No,No,NA,NA,NA,NA,NA
observation_period,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period).",No,No,NA,NA,NA,NA,NA
observation_period,observation_period_end_date,Yes,date,Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.",No,No,NA,NA,NA,NA,NA
observation_period,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_occurrence,visit_occurrence_id,Yes,integer,Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.,This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.,Yes,No,NA,NA,NA,NA,NA
@ -36,7 +36,7 @@ For Inpatient Visits ongoing at the date of ETL, put date of processing the data
- All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_end_datetime,No,datetime,"If a Person is still an inpatient in the hospital at the time of the data extract and does not have a visit_end_datetime, then set the visit_end_datetime to the datetime of the data pull.","If no time is given for the end date of a visit, set it to midnight (00:00:0000).",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_type_concept_id,Yes,Integer,"Use this field to understand the provenance of the visit record, or where the record comes from.","Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_occurrence,provider_id,No,integer,"There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.","If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail) table.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
visit_occurrence,provider_id,No,integer,"There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.","If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm54.html#visit_detail) table.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
visit_occurrence,care_site_id,No,integer,This field provides information about the Care Site where the Visit took place.,There should only be one Care Site associated with a Visit.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
visit_occurrence,visit_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_source_concept_id,No,integer,NA,If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -88,7 +88,7 @@ condition_occurrence,condition_source_concept_id,No,integer,"This is the concept
condition_occurrence,condition_status_source_value,No,varchar(50),This field houses the verbatim value from the source data representing the condition status.,This information may be called something different in the source data but the field is meant to contain a value indicating when and how a diagnosis was given to a patient. This source value is mapped to a standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID field.,No,No,NA,NA,NA,NA,NA
drug_exposure,drug_exposure_id,Yes,integer,The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled.,"Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled.",Yes,No,NA,NA,NA,NA,NA
drug_exposure,person_id,Yes,integer,The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
drug_exposure,drug_concept_id,Yes,integer,"The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.","The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: ÒMarketed ProductÓ, ÒBranded PackÓ, ÒClinical PackÓ, ÒBranded DrugÓ, ÒClinical DrugÓ, ÒBranded Drug ComponentÓ, ÒClinical Drug ComponentÓ, ÒBranded Drug FormÓ, ÒClinical Drug FormÓ, and only if no other information is available ÒIngredientÓ. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Drug&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Drug,NA,NA
drug_exposure,drug_concept_id,Yes,integer,"The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download.","The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: <EFBFBD>Marketed Product<63>, <20>Branded Pack<63>, <20>Clinical Pack<63>, <20>Branded Drug<75>, <20>Clinical Drug<75>, <20>Branded Drug Component<6E>, <20>Clinical Drug Component<6E>, <20>Branded Drug Form<72>, <20>Clinical Drug Form<72>, and only if no other information is available <20>Ingredient<6E>. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Drug&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Drug,NA,NA
drug_exposure,drug_exposure_start_date,Yes,date,Use this date to determine the start date of the drug record.,"Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE.",No,No,NA,NA,NA,NA,NA
drug_exposure,drug_exposure_start_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
drug_exposure,drug_exposure_end_date,Yes,date,The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.,"If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. [Examples by dose form](https://ohdsi.github.io/CommonDataModel/drug_dose.html)<br><br>For detailed conventions for how to populate this field, please see the [THEMIS repository](https://ohdsi.github.io/Themis/tag_drug_exposure.html).",No,No,NA,NA,NA,NA,NA
@ -148,7 +148,7 @@ device_exposure,unit_source_value,No,varchar(50),"This field houses the verbatim
device_exposure,unit_source_concept_id,No,integer,"This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Unit necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.",If the UNIT_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
measurement,measurement_id,Yes,integer,The unique key given to a Measurement record for a Person. Refer to the ETL for how duplicate Measurements during the same Visit were handled.,"Each instance of a measurement present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same measurement within the same visit. It is valid to keep these duplicates and assign them individual, unique, MEASUREMENT_IDs, though it is up to the ETL how they should be handled.",Yes,No,NA,NA,NA,NA,NA
measurement,person_id,Yes,integer,The PERSON_ID of the Person for whom the Measurement is recorded. This may be a system generated code.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
measurement,measurement_concept_id,Yes,integer,"The MEASUREMENT_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a measurement.",The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of ÒMeasurementÓ should go in this table.,No,Yes,CONCEPT,CONCEPT_ID,Measurement,NA,NA
measurement,measurement_concept_id,Yes,integer,"The MEASUREMENT_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a measurement.",The CONCEPT_ID that the MEASUREMENT_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of <EFBFBD>Measurement<EFBFBD> should go in this table.,No,Yes,CONCEPT,CONCEPT_ID,Measurement,NA,NA
measurement,measurement_date,Yes,date,Use this date to determine the date of the measurement.,"If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient.",No,No,NA,NA,NA,NA,NA
measurement,measurement_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
measurement,measurement_time,No,varchar(10),NA,This is present for backwards compatibility and will be deprecated in an upcoming version.,No,No,NA,NA,NA,NA,NA
@ -405,8 +405,8 @@ cdm_source,cdm_version_concept_id,Yes,integer,The Concept Id representing the ve
cdm_source,vocabulary_version,Yes,varchar(20),Version of the OMOP standardised vocabularies loaded,You can find the version of your Vocabulary using the query: `SELECT vocabulary_version from vocabulary where vocabulary_id = 'None'`,No,No,NA,NA,NA,NA,NA
concept,concept_id,Yes,integer,A unique identifier for each Concept across all domains.,NA,Yes,No,NA,NA,NA,NA,NA
concept,concept_name,Yes,varchar(255),"An unambiguous, meaningful and descriptive name for the Concept.",NA,No,No,NA,NA,NA,NA,NA
concept,domain_id,Yes,varchar(20),A foreign key to the [DOMAIN](https://ohdsi.github.io/CommonDataModel/cdm531.html#domain) table the Concept belongs to.,NA,No,Yes,DOMAIN,DOMAIN_ID,NA,NA,NA
concept,vocabulary_id,Yes,varchar(20),"A foreign key to the [VOCABULARY](https://ohdsi.github.io/CommonDataModel/cdm531.html#vocabulary)
concept,domain_id,Yes,varchar(20),A foreign key to the [DOMAIN](https://ohdsi.github.io/CommonDataModel/cdm54.html#domain) table the Concept belongs to.,NA,No,Yes,DOMAIN,DOMAIN_ID,NA,NA,NA
concept,vocabulary_id,Yes,varchar(20),"A foreign key to the [VOCABULARY](https://ohdsi.github.io/CommonDataModel/cdm54.html#vocabulary)
table indicating from which source the
Concept has been adapted.",NA,No,Yes,VOCABULARY,VOCABULARY_ID,NA,NA,NA
concept,concept_class_id,Yes,varchar(20),"The attribute or concept class of the
@ -479,7 +479,7 @@ relationship,reverse_relationship_id,Yes,varchar(20),"The identifier for the rel
define the reverse relationship between two
concepts.",NA,No,No,NA,NA,NA,NA,NA
relationship,relationship_concept_id,Yes,integer,"A foreign key that refers to an identifier in
the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm531.html#concept) table for the unique
the [CONCEPT](https://ohdsi.github.io/CommonDataModel/cdm54.html#concept) table for the unique
relationship concept.",NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
concept_synonym,concept_id,Yes,integer,NA,NA,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
concept_synonym,concept_synonym_name,Yes,varchar(1000),NA,NA,No,No,NA,NA,NA,NA,NA

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
88 drug_exposure quantity No float NA To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is 'Has dose form'. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160. Quantified clinical drugs with divisible dose forms (prefilled syringes), the quantity is the amount of ingredient similar to clinical drugs. Please see [how to calculate drug dose](https://ohdsi.github.io/CommonDataModel/drug_dose.html) for more information. No No NA NA NA NA NA
89 drug_exposure days_supply No integer NA The number of days of supply of the medication as recorded in the original prescription or dispensing record. Days supply can differ from actual drug duration (i.e. prescribed days supply vs actual exposure).","The field should be left empty if the source data does not contain a verbatim days_supply, and should not be calculated from other fields.<br><br>Negative values are not allowed. If the source has negative days supply the record should be dropped as it is unknown if the patient actually took the drug. Several actions are possible: 1) record is not trustworthy and we remove the record entirely. 2) we trust the record and leave days_supply empty or 3) record needs to be combined with other record (e.g. reversal of prescription). High values (>365 days) should be investigated. If considered an error in the source data (e.g. typo), the value needs to be excluded to prevent creation of unrealistic long eras. No No NA NA NA NA NA
90 drug_exposure sig No varchar(MAX) This is the verbatim instruction for the drug as written by the provider. Put the written out instructions for the drug as it is verbatim in the source, if available. No No NA NA NA NA NA
91 drug_exposure route_concept_id No integer NA The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route domain. No Yes CONCEPT CONCEPT_ID Route NA NA
92 drug_exposure lot_number No varchar(50) NA NA No No NA NA NA NA NA
93 drug_exposure provider_id No integer The Provider associated with drug record, e.g. the provider who wrote the prescription or the provider who administered the drug. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the ordering vs administering physician on an EHR record. No Yes PROVIDER PROVIDER_ID NA NA NA
94 drug_exposure visit_occurrence_id No integer The Visit during which the drug was prescribed, administered or dispensed. To populate this field drug exposures must be explicitly initiated in the visit. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
148 measurement provider_id No integer The provider associated with measurement record, e.g. the provider who ordered the test or the provider who recorded the result. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record. For example the admitting vs attending physician on an EHR record. No Yes PROVIDER PROVIDER_ID NA NA NA
149 measurement visit_occurrence_id No integer The visit during which the Measurement occurred. Depending on the structure of the source data, this may have to be determined based on dates. If a MEASUREMENT_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the measurement record. If a measurement is related to a visit explicitly in the source data, it is possible that the result date of the Measurement falls outside of the bounds of the Visit dates. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
150 measurement visit_detail_id No integer The VISIT_DETAIL record during which the Measurement occurred. For example, if the Person was in the ICU at the time the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Same rules apply as for the VISIT_OCCURRENCE_ID. No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
151 measurement measurement_source_value No varchar(50) This field contains the exact value from the source data that represents the measurement that occurred. This value corresponds to a standardized CONCEPT_ID found in MEASUREMENT_CONCEPT_ID and in the 'Measurement' domain within the Standardized Vocabularies. The original code is retained here for reference purposes. No No NA NA NA NA NA
152 measurement measurement_source_concept_id No integer This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. If the MEASUREMENT_SOURCE_VALUE is coded in the source data using a vocabulary supported by OMOP Standardized Vocabularies, insert the CONCEPT_ID representing the source value here. No Yes CONCEPT CONCEPT_ID NA NA NA
153 measurement unit_source_value No varchar(50) This field contains the exact value from the source data that represents the unit of measurement used. This value corresponds to a standardized CONCEPT_ID found in UNIT_CONCEPT_ID and in the 'Unit' domain within the Standardized Vocabularies. The original code is retained here for reference purposes. No No NA NA NA NA NA
154 measurement unit_source_concept_id No integer "This is the concept representing the UNIT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using UNIT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network." If the UNIT_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 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."
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)."
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.

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.