From 2188e7e014b2e9f39de1883d5ba2ef31dad9224b Mon Sep 17 00:00:00 2001
From: Clair Blacketer
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+person_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+gender_concept_id + | ++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 +table. Accepted +gender concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Gender + | +
+year_of_birth + | ++Compute age using year_of_birth. + | ++For data sources with date of birth, the year should be extracted. For +data sources where the year of birth is not available, the approximate +year of birth could be derived based on age group categorization, if +available. + | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+month_of_birth + | ++ | ++For data sources that provide the precise date of birth, the month +should be extracted and stored in this field. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+day_of_birth + | ++ | ++For data sources that provide the precise date of birth, the day should +be extracted and stored in this field. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+birth_datetime + | ++ | ++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. If birth_datetime is not provided in the source, use the +following logic to infer the date: If day_of_birth is null and +month_of_birth is not null then use the first of the month in that year. +If month_of_birth is null or if day_of_birth AND month_of_birth are both +null and the person has records during their year of birth then use the +date of the earliest record, otherwise use the 15th of June of that +year. If time of birth is not given use midnight (00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+race_concept_id + | ++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. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Race + | +
+ethnicity_concept_id + | ++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 + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Ethnicity + | +
+location_id + | ++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 +table here that represents the most granular location information for +the person. This could represent anything from postal code or parts +thereof, state, or county for example. Since many databases contain +deidentified data, it is common that the precision of the location is +reduced to prevent re-identification. This field should capture the last +known location. + | ++integer + | ++No + | ++No + | ++Yes + | ++LOCATION + | ++ | +
+provider_id + | ++The Provider refers to the last known primary care provider (General +Practitioner). + | ++Put the provider_id from the 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++The Care Site refers to where the Provider typically provides the +primary care. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+person_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_value + | ++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 biological sex of the person as it appears in the source data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_concept_id + | ++Due to the small number of options, this tends to be zero. + | ++If the source data codes biological sex in a non-standard vocabulary, +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+race_source_value + | ++This field is used to store the race of the person from the source data. +It is not intended for use in standard analytics but for reference only. + | ++Put the race of the person as it appears in the source data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+race_source_concept_id + | ++Due to the small number of options, this tends to be zero. + | ++If the source data codes race in an OMOP supported vocabulary store the +concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+ethnicity_source_value + | ++This field is used to store the ethnicity of the person from the source +data. It is not intended for use in standard analytics but for reference +only. + | ++If the person has an ethnicity other than the OMB standard of “Hispanic” +or “Not Hispanic” store that value from the source data here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+ethnicity_source_concept_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+observation_period_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The Person ID of the PERSON record for which the Observation Period is +recorded. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+observation_period_start_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+observation_period_end_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+period_type_concept_id + | ++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. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+visit_occurrence_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+visit_concept_id + | ++This field contains a concept id representing the kind of visit, like +inpatient or outpatient. All concepts in this field should be standard +and belong to the Visit domain. + | ++Populate this field based on the kind of visit that took place for the +person. For example this could be “Inpatient Visit”, “Outpatient Visit”, +“Ambulatory Visit”, etc. This table will contain standard 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. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+visit_start_date + | ++For inpatient visits, the start date is typically the admission date. +For outpatient visits the start date and end date will be the same. + | ++When populating VISIT_START_DATE, you should think about the patient +experience to make decisions on how to define visits. In the case of an +inpatient visit this should be the date the patient was admitted to the +hospital or institution. In all other cases this should be the date of +the patient-provider interaction. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_start_datetime + | ++ | ++If no time is given for the start date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_end_date + | ++For inpatient visits the end date is typically the discharge date. + | ++Visit end dates are mandatory. If end dates are not provided in the +source there are three ways in which to derive them: - Outpatient Visit: +visit_end_datetime = visit_start_datetime - Emergency Room Visit: +visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually +there is information about discharge. If not, you should be able to +derive the end date from the sudden decline of activity or from the +absence of inpatient procedures/drugs. - Non-hospital institution +Visits: Particularly for claims data, if end dates are not provided +assume the visit is for the duration of month that it occurs. For +Inpatient Visits ongoing at the date of ETL, put date of processing the +data into visit_end_datetime and visit_type_concept_id with 32220 “Still +patient” to identify the visit as incomplete. - All other Visits: +visit_end_datetime = visit_start_datetime. If this is a one-day visit +the end date should match the start date. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_end_datetime + | ++ | ++If no time is given for the end date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_type_concept_id + | ++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. + | ++Integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+provider_id + | ++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 +table. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++This field provides information about the Care Site where the Visit took +place. + | ++There should only be one Care Site associated with a Visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+visit_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_source_concept_id + | ++ | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+admitting_source_concept_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+admitting_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+discharge_to_concept_id + | ++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 discharged to home or sent to a long-term care facility, for +example. + | ++If available, map the discharge_to_source_value to a standard concept in +the visit domain. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+discharge_to_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+preceding_visit_occurrence_id + | ++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”. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+visit_detail_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+visit_detail_concept_id + | ++This field contains a concept id representing the kind of visit detail, +like inpatient or outpatient. All concepts in this field should be +standard and belong to the Visit domain. + | ++Populate this field based on the kind of visit that took place for the +person. For example this could be “Inpatient Visit”, “Outpatient Visit”, +“Ambulatory Visit”, etc. This table will contain standard 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. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+visit_detail_start_date + | ++This is the date of the start of the encounter. This may or may not be +equal to the date of the Visit the Visit Detail is associated with. + | ++When populating VISIT_DETAIL_START_DATE, you should think about the +patient experience to make decisions on how to define visits. Most +likely this should be the date of the patient-provider interaction. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_detail_start_datetime + | ++ | ++If no time is given for the start date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_end_date + | ++This the end date of the patient-provider interaction. + | +
+Visit Detail end dates are mandatory. If end dates are not provided in
+the source there are three ways in which to derive them: - +Outpatient Visit Detail: visit_detail_end_datetime = +visit_detail_start_datetime - Emergency Room Visit Detail: +visit_detail_end_datetime = visit_detail_start_datetime - Inpatient +Visit Detail: Usually there is information about discharge. If not, you +should be able to derive the end date from the sudden decline of +activity or from the absence of inpatient procedures/drugs. - +Non-hospital institution Visit Details: Particularly for claims data, if +end dates are not provided assume the visit is for the duration of month +that it occurs. For Inpatient Visit Details ongoing at the date of +ETL, put date of processing the data into visit_detai_end_datetime and +visit_detail_type_concept_id with 32220 “Still patient” to identify the +visit as incomplete. All other Visits Details: visit_detail_end_datetime += visit_detail_start_datetime. + |
++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_detail_end_datetime + | ++ | ++If no time is given for the end date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_type_concept_id + | ++Use this field to understand the provenance of the visit detail record, +or where the record comes from. + | ++Populate this field based on the provenance of the visit detail record, +as in whether it came from an EHR record or billing claim. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+provider_id + | ++There will only be one provider per visit record and +the ETL document should clearly state how they were chosen (attending, +admitting, etc.). This is a typical reason for leveraging the +VISIT_DETAIL table as even though each VISIT_DETAIL record can only have +one provider, there is no limit to the number of VISIT_DETAIL records +that can be associated to a VISIT_OCCURRENCE record. + | ++The additional providers associated to a Visit can be stored in this +table where each VISIT_DETAIL record represents a different provider. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++This field provides information about the Care Site where the Visit +Detail took place. + | ++There should only be one Care Site associated with a Visit Detail. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+visit_detail_source_value + | ++This field houses the verbatim value from the source data representing +the kind of visit detail that took place (inpatient, outpatient, +emergency, etc.) + | ++If there is information about the kind of visit detail 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_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line +up with the logic chosen to determine how visits are created. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_source_concept_id + | ++ | ++If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+admitting_source_value + | ++ | ++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. + | ++Varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+admitting_source_concept_id + | ++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. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+discharge_to_source_value + | ++ | ++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. + | ++Varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+discharge_to_concept_id + | ++Use this field to determine where the patient was discharged to after a +visit detail record. This concept is part of the visit domain and can +indicate if a patient was discharged to home or sent to a long-term care +facility, for example. + | ++If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in +the Visit domain. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+preceding_visit_detail_id + | ++Use this field to find the visit detail that occurred for the person +prior to the given visit detail record. There could be a few days or a +few years in between. + | ++The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately +preceding the current Visit Detail. Note this is not symmetrical, and +there is no such thing as a “following_visit_id”. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+visit_detail_parent_id + | ++Use this field to find the visit detail that subsumes the given visit +detail record. This is used in the case that a visit detail record needs +to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship. + | ++If there are multiple nested levels to how Visits are represented in the +source, the VISIT_DETAIL_PARENT_ID can be used to record this +relationship. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+visit_occurrence_id + | ++Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE. + | ++Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
ETL Conventions
Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+condition_occurrence_id + | ++The unique key given to a condition record for a person. Refer to the +ETL for how duplicate conditions during the same visit were handled. + | ++Each instance of a condition present in the source data should be +assigned this unique key. In some cases, a person can have multiple +records of the same condition within the same visit. It is valid to keep +these duplicates and assign them individual, unique, +CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be +handled. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the condition is recorded. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+condition_concept_id + | ++The CONDITION_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 condition + | ++The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records +whose source values map to concepts with a domain of “Condition” should +go in this table. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Condition + | +
+condition_start_date + | ++Use this date to determine the start date of the condition + | ++Most often data sources do not have the idea of a start date for a +condition. Rather, if a source only has one date associated with a +condition record it is acceptable to use that date for both the +CONDITION_START_DATE and the CONDITION_END_DATE. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_start_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_end_date + | ++Use this date to determine the end date of the condition + | ++Most often data sources do not have the idea of a start date for a +condition. Rather, if a source only has one date associated with a +condition record it is acceptable to use that date for both the +CONDITION_START_DATE and the CONDITION_END_DATE. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_end_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_type_concept_id + | ++This field can be used to determine the provenance of the Condition +record, as in whether the condition was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance +of the record. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+condition_status_concept_id + | ++This concept represents the point during the visit the diagnosis was +given (admitting diagnosis, final diagnosis), whether the diagnosis was +determined due to laboratory findings, if the diagnosis was +exclusionary, or if it was a preliminary diagnosis, among others. + | ++Choose the Concept in the Condition Status domain that best represents +the point during the visit when the diagnosis was given. These can +include admitting diagnosis, principal diagnosis, and secondary +diagnosis. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Condition Status + | +
+stop_reason + | ++The Stop Reason indicates why a Condition is no longer valid with +respect to the purpose within the source data. Note that a Stop Reason +does not necessarily imply that the condition is no longer occurring. + | ++This information is often not populated in source data and it is a valid +etl choice to leave it blank if the information does not exist. + | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The provider associated with condition record, e.g. the provider who +made the diagnosis or the provider who recorded the symptom. + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the condition occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If a CONDITION_START_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 CONDITION_OCCURRENCE +record. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the condition occurred. For +example, if the person was in the ICU at the time of the diagnosis 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+condition_source_value + | ++This field houses the verbatim value from the source data representing +the condition that occurred. For example, this could be an ICD10 or Read +code. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_source_concept_id + | ++This is the concept representing the condition 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 Condition +necessary for a given analytic use case. Consider using +CONDITION_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+condition_status_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_exposure_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the drug dispensing or +administration is recorded. This may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++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: ‘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. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+drug_exposure_start_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_start_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_end_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: 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 + |
++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_end_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+verbatim_end_date + | ++This is the end date of the drug exposure as it appears in the source +data, if it is given + | ++Put the end date or discontinuation date as it appears from the source +data or leave blank if unavailable. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_type_concept_id + | ++You can use the TYPE_CONCEPT_ID to delineate between prescriptions +written vs. prescriptions dispensed vs. medication history +vs. patient-reported exposure, etc. + | ++Choose the drug_type_concept_id that best represents the provenance of +the record, for example whether it came from a record of a prescription +written or physician administered drug. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+stop_reason + | ++The reason a person stopped a medication as it is represented in the +source. Reasons include regimen completed, changed, removed, etc. This +field will be retired in v6.0. + | ++This information is often not populated in source data and it is a valid +etl choice to leave it blank if the information does not exist. + | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+refills + | ++This is only filled in when the record is coming from a prescription +written this field is meant to represent intended refills at time of the +prescription. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++ | ++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 for more information. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+days_supply + | ++ | ++Days supply of the drug. This should be the verbatim days_supply as +given on the prescription. If the drug is physician administered use +duration end date if given or set to 1 as default if duration is not +available. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+sig + | ++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. + | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+route_concept_id + | ++ | ++The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route +domain. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Route + | +
+lot_number + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the drug was prescribed, administered or +dispensed. + | ++To populate this field drug exposures must be explicitly initiated in +the visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the drug exposure occurred. For +example, if the person was in the ICU at the time of the drug +administration 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+drug_source_value + | ++This field houses the verbatim value from the source data representing +the drug exposure that occurred. For example, this could be an NDC or +Gemscript code. + | ++This code is mapped to a Standard Drug Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_source_concept_id + | ++This is the concept representing the drug 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 Drug +necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID +instead to enable standardized analytics that can be consistent across +the network. + | ++If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+route_source_value + | ++This field houses the verbatim value from the source data representing +the drug route. + | ++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 drug +was given to a patient. This source value is mapped to a standard +concept which is stored in the ROUTE_CONCEPT_ID field. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+dose_unit_source_value + | ++This field houses the verbatim value from the source data representing +the dose unit of the drug given. + | ++This information may be called something different in the source data +but the field is meant to contain a value indicating the unit of dosage +of drug given to the patient. This is an older column and will be +deprecated in an upcoming version. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+procedure_occurrence_id + | ++The unique key given to a procedure record for a person. Refer to the +ETL for how duplicate procedures during the same visit were handled. + | ++Each instance of a procedure occurrence in the source data should be +assigned this unique key. In some cases, a person can have multiple +records of the same procedure within the same visit. It is valid to keep +these duplicates and assign them individual, unique, +PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be +handled. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the procedure is recorded. This may +be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+procedure_concept_id + | ++The PROCEDURE_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 procedure + | ++The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records +whose source values map to standard concepts with a domain of +“Procedure” should go in this table. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Procedure + | +
+procedure_date + | ++Use this date to determine the date the procedure occurred. + | ++If a procedure lasts more than a day, then it should be recorded as a +separate record for each day the procedure occurred, this logic is in +lieu of the procedure_end_date, which will be added in a future version +of the CDM. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+procedure_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_type_concept_id + | ++This field can be used to determine the provenance of the Procedure +record, as in whether the procedure was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance +of the record, for example whether it came from an EHR record or billing +claim. If a procedure is recorded as an EHR encounter, the +PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+modifier_concept_id + | ++The modifiers are intended to give additional information about the +procedure but as of now the vocabulary is under review. + | ++It is up to the ETL to choose how to map modifiers if they exist in +source data. These concepts are typically distinguished by ‘Modifier’ +concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ +vocabulary). If there is more than one modifier on a record, one should +be chosen that pertains to the procedure rather than provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+quantity + | ++If the quantity value is omitted, a single procedure is assumed. + | ++If a Procedure has a quantity of ‘0’ in the source, this should default +to ‘1’ in the ETL. If there is a record in the source it can be assumed +the exposure occurred at least once + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The provider associated with the procedure record, e.g. the provider who +performed the Procedure. + | ++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. + | ++integer + | ++No + | ++No + | ++No + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the procedure occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If a PROCEDURE_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 PROCEDURE_OCCURRENCE +record. + | ++integer + | ++No + | ++No + | ++No + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the Procedure occurred. For +example, if the Person was in the ICU at the time of the Procedure 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. + | ++integer + | ++No + | ++No + | ++No + | ++VISIT_DETAIL + | ++ | +
+procedure_source_value + | ++This field houses the verbatim value from the source data representing +the procedure that occurred. For example, this could be an CPT4 or OPCS4 +code. + | ++Use this value to look up the source concept id and then map the source +concept id to a standard concept id. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_source_concept_id + | ++This is the concept representing the procedure 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 Procedure +necessary for a given analytic use case. Consider using +PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++No + | ++CONCEPT + | ++ | +
+modifier_source_value + | ++ | ++The original modifier code from the source is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+device_exposure_id + | ++The unique key given to records a person’s exposure to a foreign +physical object or instrument. + | ++Each instance of an exposure to a foreign object or device present in +the source data should be assigned this unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+device_concept_id + | ++The DEVICE_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 foreign object or +instrument the person was exposed to. + | ++The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Device + | +
+device_exposure_start_date + | ++Use this date to determine the start date of the device record. + | ++Valid entries include a start date of a procedure to implant a device, +the date of a prescription for a device, or the date of device +administration. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+device_exposure_start_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_exposure_end_date + | ++The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended +for the patient, if given. + | ++Put the end date or discontinuation date as it appears from the source +data or leave blank if unavailable. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_exposure_end_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_type_concept_id + | ++You can use the TYPE_CONCEPT_ID to denote the provenance of the record, +as in whether the record is from administrative claims or EHR. + | ++Choose the drug_type_concept_id that best represents the provenance of +the record, for example whether it came from a record of a prescription +written or physician administered drug. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+unique_device_id + | ++This is the Unique Device Identification number for devices regulated by +the FDA, if given. + | ++For medical devices that are regulated by the FDA, a Unique Device +Identification (UDI) is provided if available in the data source and is +recorded in the UNIQUE_DEVICE_ID field. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The Provider associated with device record, e.g. the provider who wrote +the prescription or the provider who implanted the device. + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the device was prescribed or given. + | ++To populate this field device exposures must be explicitly initiated in +the visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The Visit Detail during which the device was prescribed or given. + | ++To populate this field device exposures must be explicitly initiated in +the visit detail record. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+device_source_value + | ++This field houses the verbatim value from the source data representing +the device exposure that occurred. For example, this could be an NDC or +Gemscript code. + | ++This code is mapped to a Standard Device Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_source_concept_id + | ++This is the concept representing the device 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 Device +necessary for a given analytic use case. Consider using +DEVICE_CONCEPT_ID instead to enable standardized analytics that can be +consistent across the network. + | ++If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+measurement_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the Person for whom the Measurement is recorded. This +may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+measurement_concept_id + | ++The MEASUREMENT_CONCEPT_ID field is recommended for primary use in +analyses, and must be used for network studies. + | ++The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only +records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain +of “Measurement” should go in this table. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Measurement + | +
+measurement_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+measurement_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_time + | ++ | ++This is present for backwards compatibility and will be deprecated in an +upcoming version. + | ++varchar(10) + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_type_concept_id + | ++This field can be used to determine the provenance of the Measurement +record, as in whether the measurement was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the +provenance of the record, for example whether it came from an EHR record +or billing claim. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+operator_concept_id + | ++The meaning of Concept 4172703 +for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since +the use of this field is rare, it’s important when devising analyses to +not to forget testing for the content of this field for values different +from =. + | ++Operators are =, > and these concepts belong to the ‘Meas Value +Operator’ domain. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+value_as_number + | ++This is the numerical value of the Result of the Measurement, if +available. Note that measurements such as blood pressures will be split +into their component parts i.e. one record for systolic, one record for +diastolic. + | +
+If there is a negative value coming from the source, set the
+VALUE_AS_NUMBER to NULL, with the exception of the following
+Measurements (listed as LOINC codes): - 1925-7 +Base excess in Arterial blood by calculation - 1927-3 +Base excess in Venous blood by calculation - 8632-2 +QRS-Axis - 11555-0 +Base excess in Blood by calculation - 1926-5 +Base excess in Capillary blood by calculation - 28638-5 +Base excess in Arterial cord blood by calculation 28639-3 +Base excess in Venous cord blood by calculation + |
++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++If the raw data gives a categorial result for measurements those values +are captured and mapped to standard concepts in the ‘Meas Value’ domain. + | ++If the raw data provides categorial results as well as continuous +results for measurements, it is a valid ETL choice to preserve both +values. The continuous value should go in the VALUE_AS_NUMBER field and +the categorical value should be mapped to a standard concept in the +‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is +also the destination for the ‘Maps to value’ relationship. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_concept_id + | ++There is currently no recommended unit for individual measurements, +i.e. it is not mandatory to represent Hemoglobin a1C measurements as a +percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in +the Unit domain that best represents the unit as given in the source +data. + | ++There is no standardization requirement for units associated with +MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to +choose the most plausible unit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+range_low + | ++Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are +provided by the source and should remain NULL if not given. + | ++If reference ranges for upper and lower limit of normal as provided +(typically by a laboratory) these are stored in the RANGE_HIGH and +RANGE_LOW fields. This should be set to NULL if not provided. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+range_high + | ++Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are +provided by the source and should remain NULL if not given. + | ++If reference ranges for upper and lower limit of normal as provided +(typically by a laboratory) these are stored in the RANGE_HIGH and +RANGE_LOW fields. This should be set to NULL if not provided. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+measurement_source_value + | ++This field houses the verbatim value from the source data representing +the Measurement that occurred. For example, this could be an ICD10 or +Read code. + | ++This code is mapped to a Standard Measurement Concept in the +Standardized Vocabularies and the original code is stored here for +reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_source_concept_id + | ++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 an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_source_value + | ++This field houses the verbatim value from the source data representing +the unit of the Measurement that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_source_value + | ++This field houses the verbatim result value of the Measurement from the +source data . + | ++If both a continuous and categorical result are given in the source data +such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both +included, store the verbatim value that was mapped to +VALUE_AS_CONCEPT_ID here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+observation_id + | ++The unique key given to an Observation record for a Person. Refer to the +ETL for how duplicate Observations during the same Visit were handled. + | ++Each instance of an observation present in the source data should be +assigned this unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the Person for whom the Observation is recorded. This +may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+observation_concept_id + | ++The OBSERVATION_CONCEPT_ID field is recommended for primary use in +analyses, and must be used for network studies. + | ++The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is +no specified domain that the Concepts in this table must adhere to. The +only rule is that records with Concepts in the Condition, Procedure, +Drug, Measurement, or Device domains MUST go to the corresponding table. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+observation_date + | ++The date of the Observation. Depending on what the Observation +represents this could be the date of a lab test, the date of a survey, +or the date a patient’s family history was taken. + | ++For some observations the ETL may need to make a choice as to which date +to choose. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+observation_datetime + | ++ | ++If no time is given set to midnight (00:00:00). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+observation_type_concept_id + | ++This field can be used to determine the provenance of the Observation +record, as in whether the measurement was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the +provenance of the record, for example whether it came from an EHR record +or billing claim. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+value_as_number + | ++This is the numerical value of the Result of the Observation, if +applicable and available. It is not expected that all Observations will +have numeric results, rather, this field is here to house values should +they exist. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_string + | ++This is the categorical value of the Result of the Observation, if +applicable and available. + | ++ | ++varchar(60) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++It is possible that some records destined for the Observation table have +two clinical ideas represented in one source code. This is common with +ICD10 codes that describe a family history of some Condition, for +example. In OMOP the Vocabulary breaks these two clinical ideas into two +codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the +VALUE_AS_CONCEPT_ID. It is important when using the Observation table to +keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID +field for relevant information. + | ++Note that the value of VALUE_AS_CONCEPT_ID may be provided through +mapping from a source Concept which contains the content of the +Observation. In those situations, the CONCEPT_RELATIONSHIP table in +addition to the ‘Maps to’ record contains a second record with the +relationship_id set to ‘Maps to value’. For example, ICD10 Z82.4 +‘Family history of ischaemic heart disease and other diseases of the +circulatory system’ has a ‘Maps to’ relationship to 4167217 +‘Family history of clinical finding’ as well as a ‘Maps to value’ record +to 134057 +‘Disorder of cardiovascular system’. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+qualifier_concept_id + | ++This field contains all attributes specifying the clinical fact further, +such as as degrees, severities, drug-drug interaction alerts etc. + | ++Use your best judgement as to what Concepts to use here and if they are +necessary to accurately represent the clinical record. There is no +restriction on the domain of these Concepts, they just need to be +Standard. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_concept_id + | ++There is currently no recommended unit for individual observation +concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in +the Unit domain that best represents the unit as given in the source +data. + | ++There is no standardization requirement for units associated with +OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to +choose the most plausible unit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+provider_id + | ++The provider associated with the observation 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the Observation occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If an OBSERVATION_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 observation record. If an +observation is related to a visit explicitly in the source data, it is +possible that the result date of the Observation falls outside of the +bounds of the Visit dates. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the Observation 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+observation_source_value + | ++This field houses the verbatim value from the source data representing +the Observation that occurred. For example, this could be an ICD10 or +Read code. + | ++This code is mapped to a Standard Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+observation_source_concept_id + | ++This is the concept representing the OBSERVATION_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 +Observation necessary for a given analytic use case. Consider using +OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the OBSERVATION_SOURCE_VALUE is coded in the source data using an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_source_value + | ++This field houses the verbatim value from the source data representing +the unit of the Observation that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+qualifier_source_value + | ++This field houses the verbatim value from the source data representing +the qualifier of the Observation that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+death_date + | ++The date the person was deceased. + | ++If the precise date include day or month is not known or not allowed, +December is used as the default month, and the last day of the month the +default day. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+death_datetime + | ++ | ++If not available set time to midnight (00:00:00) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+death_type_concept_id + | ++This is the provenance of the death record, i.e., where it came from. It +is possible that an administrative claims database would source death +information from a government file so do not assume the Death Type is +the same as the Visit Type, etc. + | ++Use the type concept that be reflects the source of the death record. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+cause_concept_id + | ++This is the Standard Concept representing the Person’s cause of death, +if available. + | ++There is no specified domain for this concept, just choose the Standard +Concept Id that best represents the person’s cause of death. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cause_source_value + | ++ | ++If available, put the source code representing the cause of death here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cause_source_concept_id + | ++ | ++If the cause of death was coded using a Vocabulary present in the OMOP +Vocabularies put the CONCEPT_ID representing the cause of death here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+note_id + | ++A unique identifier for each note. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+note_date + | ++The date the note was recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+note_datetime + | ++ | ++If time is not given set the time to midnight. + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_type_concept_id + | ++The provenance of the note. Most likely this will be EHR. + | ++Put the source system of the note, as in EHR record. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+note_class_concept_id + | ++A Standard Concept Id representing the HL7 LOINC Document Type +Vocabulary classification of the note. + | ++Map the note classification to a Standard Concept. For more information +see the ETL Conventions in the description of the NOTE table. Accepted +Concepts. This Concept can alternatively be represented by concepts +with the relationship ‘Kind of (LOINC)’ to 706391 +(Note). + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+note_title + | ++The title of the note. + | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_text + | ++The content of the note. + | ++ | ++varchar(MAX) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+encoding_concept_id + | ++This is the Concept representing the character encoding type. + | ++Put the Concept Id that represents the encoding character type here. +Currently the only option is UTF-8 (32678). It +the note is encoded in any other type, like ASCII then put 0. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+language_concept_id + | ++The language of the note. + | ++Use Concepts that are descendants of the concept 4182347 +(World Languages). + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+provider_id + | ++The Provider who wrote the note. + | ++The ETL may need to make a determination on which provider to put here. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the note was written. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The Visit Detail during which the note was written. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+note_source_value + | ++ | ++The source value mapped to the NOTE_CLASS_CONCEPT_ID. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+note_nlp_id + | ++A unique identifier for the NLP record. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+note_id + | ++This is the NOTE_ID for the NOTE record the NLP record is associated to. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+section_concept_id + | ++ | ++The SECTION_CONCEPT_ID should be used to represent the note section +contained in the NOTE_NLP record. These concepts can be found as parts +of document panels and are based on the type of note written, i.e. a +discharge summary. These panels can be found as concepts with the +relationship ‘Subsumes’ to CONCEPT_ID 45875957. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+snippet + | ++A small window of text surrounding the term + | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+“offset” + | ++Character offset of the extracted term in the input note + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+lexical_variant + | ++Raw text extracted from the NLP tool. + | ++ | ++varchar(250) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+note_nlp_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+note_nlp_source_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+nlp_system + | ++ | ++Name and version of the NLP system that extracted the term. Useful for +data provenance. + | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+nlp_date + | ++The date of the note processing. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+nlp_datetime + | ++The date and time of the note processing. + | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_exists + | ++ | ++Term_exists is defined as a flag that indicates if the patient actually +has or had the condition. Any of the following modifiers would make +Term_exists false: Negation = true Subject = [anything other than the +patient] Conditional = true/li> Rule_out = true Uncertain = very low +certainty or any lower certainties A complete lack of modifiers would +make Term_exists true. + | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_temporal + | ++ | +
+Term_temporal is to indicate if a condition is present or just in the
+past. The following would be past: - History = true - +Concept_date = anything before the time of the report + |
++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_modifiers + | ++ | +
+For the modifiers that are there, they would have to have these
+values: - Negation = false - Subject = patient - Conditional = +false - Rule_out = false - Uncertain = true or high or moderate or even +low (could argue about low). Term_modifiers will concatenate all +modifiers for different types of entities (conditions, drugs, labs etc) +into one string. Lab values will be saved as one of the modifiers. + |
++varchar(2000) + | ++No + | ++No + | ++No + | ++ | ++ | +
Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+specimen_id + | ++Unique identifier for each specimen. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The person from whom the specimen is collected. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+specimen_concept_id + | ++ | ++The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the +specimen domain. Accepted +Concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+specimen_type_concept_id + | ++ | ++Put the source of the specimen record, as in an EHR system. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+specimen_date + | ++The date the specimen was collected. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+specimen_datetime + | ++ | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++The amount of specimen collected from the person. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_concept_id + | ++The unit for the quantity of the specimen. + | ++Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. Accepted +Concepts + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+anatomic_site_concept_id + | ++This is the site on the body where the specimen is from. + | ++Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec +Anatomic Site domain. This should be coded at the lowest level of +granularity Accepted +Concepts + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+disease_status_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+specimen_source_id + | ++This is the identifier for the specimen from the source system. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specimen_source_value + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_source_value + | ++ | ++This unit for the quantity of the specimen, as represented in the +source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+anatomic_site_source_value + | ++ | ++This is the site on the body where the specimen was taken from, as +represented in the source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+disease_status_source_value + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+domain_concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+fact_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+fact_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+relationship_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+location_id + | ++The unique key given to a unique Location. + | ++Each instance of a Location in the source data should be assigned this +unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+address_1 + | ++This is the first line of the address. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+address_2 + | ++This is the second line of the address + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+city + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+state + | ++ | ++ | ++varchar(2) + | ++No + | ++No + | ++No + | ++ | ++ | +
+zip + | ++ | ++Zip codes are handled as strings of up to 9 characters length. For US +addresses, these represent either a 3-digit abbreviated Zip code as +provided by many sources for patient protection reasons, the full +5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons +analytical methods should expect and utilize only the first 3 digits. +For international addresses, different rules apply. + | ++varchar(9) + | ++No + | ++No + | ++No + | ++ | ++ | +
+county + | ++ | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+location_source_value + | ++ | ++Put the verbatim value for the location here, as it shows up in the +source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+care_site_id + | ++ | ++Assign an id to each unique combination of location_id and +place_of_service_source_value + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+care_site_name + | ++The name of the care_site as it appears in the source data + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+place_of_service_concept_id + | ++This is a high-level way of characterizing a Care Site. Typically, +however, Care Sites can provide care in multiple settings (inpatient, +outpatient, etc.) and this granularity should be reflected in the visit. + | ++Choose the concept in the visit domain that best represents the setting +in which healthcare is provided in the Care Site. If most visits in a +Care Site are Inpatient, then the place_of_service_concept_id should +represent Inpatient. If information is present about a unique Care Site +(e.g. Pharmacy) then a Care Site record should be created. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+location_id + | ++The location_id from the LOCATION table representing the physical +location of the care_site. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++LOCATION + | ++ | +
+care_site_source_value + | ++The identifier of the care_site as it appears in the source data. This +could be an identifier separate from the name of the care_site. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+place_of_service_source_value + | ++ | ++Put the place of service of the care_site as it appears in the source +data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+provider_id + | ++It is assumed that every provider with a different unique identifier is +in fact a different person and should be treated independently. + | ++This identifier can be the original id from the source data provided it +is an integer, otherwise it can be an autogenerated number. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+provider_name + | ++ | ++This field is not necessary as it is not necessary to have the actual +identity of the Provider. Rather, the idea is to uniquely and +anonymously identify providers of care across the database. + | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+npi + | ++This is the National Provider Number issued to health care providers in +the US by the Centers for Medicare and Medicaid Services (CMS). + | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+dea + | ++This is the identifier issued by the DEA, a US federal agency, that +allows a provider to write prescriptions for controlled substances. + | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_concept_id + | ++This field either represents the most common specialty that occurs in +the data or the most specific concept that represents all specialties +listed, should the provider have more than one. This includes physician +specialties such as internal medicine, emergency medicine, etc. and +allied health professionals such as nurses, midwives, and pharmacists. + | ++If a Provider has more than one Specialty, there are two options: 1. +Choose a concept_id which is a common ancestor to the multiple +specialties, or, 2. Choose the specialty that occurs most often for the +provider. Concepts in this field should be Standard with a domain of +Provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+care_site_id + | ++This is the CARE_SITE_ID for the location that the provider primarily +practices in. + | ++If a Provider has more than one Care Site, the main or most often +exerted CARE_SITE_ID should be recorded. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+year_of_birth + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_concept_id + | ++This field represents the recorded gender of the provider in the source +data. + | ++If given, put a concept from the gender domain representing the recorded +gender of the provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Gender + | +
+provider_source_value + | ++Use this field to link back to providers in the source data. This is +typically used for error checking of ETL logic. + | ++Some use cases require the ability to link back to providers in the +source data. This field allows for the storing of the provider +identifier as it appears in the source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_source_value + | ++This is the kind of provider or specialty as it appears in the source +data. This includes physician specialties such as internal medicine, +emergency medicine, etc. and allied health professionals such as nurses, +midwives, and pharmacists. + | ++Put the kind of provider as it appears in the source data. This field is +up to the discretion of the ETL-er as to whether this should be the +coded value from the source or the text description of the lookup value. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_source_concept_id + | ++This is often zero as many sites use proprietary codes to store +physician speciality. + | ++If the source data codes provider specialty in an OMOP supported +vocabulary store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+gender_source_value + | ++This is provider’s gender as it appears in the source data. + | ++Put the provider’s gender as it appears in the source data. This field +is up to the discretion of the ETL-er as to whether this should be the +coded value from the source or the text description of the lookup value. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_concept_id + | ++This is often zero as many sites use proprietary codes to store provider +gender. + | ++If the source data codes provider gender in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+payer_plan_period_id + | ++A unique identifier for each unique combination of a Person, Payer, +Plan, and Period of time. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The Person covered by the Plan. + | ++A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD +records + | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+payer_plan_period_start_date + | ++Start date of Plan coverage. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+payer_plan_period_end_date + | ++End date of Plan coverage. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+payer_concept_id + | ++This field represents the organization who reimburses the provider which +administers care to the Person. + | ++Map the Payer directly to a standard CONCEPT_ID. If one does not exists +please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same payer, though the +name of the Payer is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+payer_source_value + | ++This is the Payer as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+payer_source_concept_id + | ++ | ++If the source data codes the Payer in an OMOP supported vocabulary store +the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+plan_concept_id + | ++This field represents the specific health benefit Plan the Person is +enrolled in. + | ++Map the Plan directly to a standard CONCEPT_ID. If one does not exists +please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same health benefit +Plan though the name of the Plan is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+plan_source_value + | ++This is the health benefit Plan of the Person as it appears in the +source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+plan_source_concept_id + | ++ | ++If the source data codes the Plan in an OMOP supported vocabulary store +the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+sponsor_concept_id + | ++This field represents the sponsor of the Plan who finances the Plan. +This includes self-insured, small group health plan and large group +health plan. + | ++Map the sponsor directly to a standard CONCEPT_ID. If one does not +exists please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same sponsor though +the name of the sponsor is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+sponsor_source_value + | ++The Plan sponsor as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+sponsor_source_concept_id + | ++ | ++If the source data codes the sponsor in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+family_source_value + | ++The common identifier for all people (often a family) that covered by +the same policy. + | ++Often these are the common digits of the enrollment id of the policy +members. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+stop_reason_concept_id + | ++This field represents the reason the Person left the Plan, if known. + | ++Map the stop reason directly to a standard CONCEPT_ID. If one does not +exists please contact the vocabulary team. There is no global controlled +vocabulary available for this information. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+stop_reason_source_value + | ++The Plan stop reason as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+stop_reason_source_concept_id + | ++ | ++If the source data codes the stop reason in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cost_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+cost_event_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cost_domain_id + | ++ | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
+cost_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+currency_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+total_charge + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+total_cost + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+total_paid + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_payer + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_patient + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_copay + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_coinsurance + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_deductible + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_primary + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_ingredient_cost + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_dispensing_fee + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+payer_plan_period_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+amount_allowed + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+revenue_code_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+revenue_code_source_value + | ++Revenue codes are a method to charge for a class of procedures and +conditions in the U.S. hospital system. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+drg_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+drg_source_value + | ++Diagnosis Related Groups are US codes used to classify hospital cases +into one of approximately 500 groups. + | ++ | ++varchar(3) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
The SQL script for generating DRUG_ERA records can be found here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++The Concept Id representing the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+drug_era_start_date + | ++ | ++The Drug Era Start Date is the start date of the first Drug Exposure for +a given ingredient, with at least 31 days since the previous exposure. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_era_end_date + | ++ | ++The Drug Era End Date is the end date of the last Drug Exposure. The End +Date of each Drug Exposure is either taken from the field +drug_exposure_end_date or, as it is typically not available, inferred +using the following rules: For pharmacy prescription data, the date when +the drug was dispensed plus the number of days of supply are used to +extrapolate the End Date for the Drug Exposure. Depending on the +country-specific healthcare system, this supply information is either +explicitly provided in the day_supply field or inferred from package +size or similar information. For Procedure Drugs, usually the drug is +administered on a single date (i.e., the administration date). A +standard Persistence Window of 30 days (gap, slack) is permitted between +two subsequent such extrapolated DRUG_EXPOSURE records to be considered +to be merged into a single Drug Era. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_count + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+gap_days + | ++ | ++The Gap Days determine how many total drug-free days are observed +between all Drug Exposure events that contribute to a DRUG_ERA record. +It is assumed that the drugs are “not stockpiled” by the patient, +i.e. that if a new drug prescription or refill is observed (a new +DRUG_EXPOSURE record is written), the remaining supply from the previous +events is abandoned. The difference between Persistence Window and Gap +Days is that the former is the maximum drug-free time allowed between +two subsequent DRUG_EXPOSURE records, while the latter is the sum of +actual drug-free days for the given Drug Era under the above assumption +of non-stockpiling. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+dose_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++The Concept Id representing the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+unit_concept_id + | ++The Concept Id representing the unit of the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+dose_value + | ++The numeric value of the dosage of the drug_ingredient. + | ++ | ++float + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+dose_era_start_date + | ++The date the Person started on the specific dosage, with at least 31 +days since any prior exposure. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+dose_era_end_date + | ++ | ++The date the Person was no longer exposed to the dosage of the specific +drug ingredient. An era is ended if there are 31 days or more between +dosage records. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+condition_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++PERSON + | ++ | +
+condition_concept_id + | ++The Concept Id representing the Condition. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Condition + | +
+condition_era_start_date + | ++The start date for the Condition Era constructed from the individual +instances of Condition Occurrences. It is the start date of the very +first chronologically recorded instance of the condition with at least +31 days since any prior record of the same Condition. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_era_end_date + | ++The end date for the Condition Era constructed from the individual +instances of Condition Occurrences. It is the end date of the final +continuously recorded instance of the Condition. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_occurrence_count + | ++The number of individual Condition Occurrences used to construct the +condition era. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+metadata_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+metadata_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+name + | ++ | ++ | ++varchar(250) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+value_as_string + | ++ | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+metadata_date + | ++ | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+metadata_datetime + | ++ | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cdm_source_name + | ++The name of the CDM instance. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cdm_source_abbreviation + | ++The abbreviation of the CDM instance. + | ++ | ++varchar(25) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_holder + | ++The holder of the CDM instance. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+source_description + | ++The description of the CDM instance. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+source_documentation_reference + | ++ | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_etl_reference + | ++ | ++Put the link to the CDM version used. + | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+source_release_date + | ++The release date of the source data. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_release_date + | ++The release data of the CDM instance. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_version + | ++ | ++ | ++varchar(10) + | ++No + | ++No + | ++No + | ++ | ++ | +
+vocabulary_version + | ++ | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id + | ++A unique identifier for each Concept across all domains. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+concept_name + | ++An unambiguous, meaningful and descriptive name for the Concept. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_id + | ++A foreign key to the DOMAIN +table the Concept belongs to. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
+vocabulary_id + | ++A foreign key to the VOCABULARY +table indicating from which source the Concept has been adapted. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
+concept_class_id + | ++The attribute or concept class of the Concept. Examples are ‘Clinical +Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++CONCEPT_CLASS + | ++ | +
+standard_concept + | ++This flag determines where a Concept is a Standard Concept, i.e. is used +in the data, a Classification Concept, or a non-standard Source Concept. +The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification +Concept), otherwise the content is NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
+concept_code + | ++The concept code represents the identifier of the Concept in the source +vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that +concept codes are not unique across vocabularies. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970, meaning, the Concept has no (known) date of inception. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the Concept became invalid because it was deleted or +superseded (updated) by a new concept. The default value is 31-Dec-2099, +meaning, the Concept is valid until it becomes deprecated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the Concept was invalidated. Possible values are D (deleted), U +(replaced with an update) or NULL when valid_end_date has the default +value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+vocabulary_id + | ++A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+vocabulary_name + | ++The name describing the vocabulary, for example, International +Classification of Diseases, Ninth Revision, Clinical Modification, +Volume 1 and 2 (NCHS) etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+vocabulary_reference + | ++External reference to documentation or available download of the about +the vocabulary. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+vocabulary_version + | ++Version of the Vocabulary as indicated in the source. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+vocabulary_concept_id + | ++A Concept that represents the Vocabulary the VOCABULARY record belongs +to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+domain_id + | ++A unique key for each domain. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+domain_name + | ++The name describing the Domain, e.g. Condition, Procedure, Measurement +etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_concept_id + | ++A Concept representing the Domain Concept the DOMAIN record belongs to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_class_id + | ++A unique key for each class. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+concept_class_name + | ++The name describing the Concept Class, e.g. Clinical Finding, +Ingredient, etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+concept_class_concept_id + | ++A Concept that represents the Concept Class. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+relationship_id + | ++The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the +Vocabulary +Conventions. for more information. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++RELATIONSHIP + | ++ | +
+valid_start_date + | ++The date when the relationship is first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the relationship is invalidated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the relationship was invalidated. Possible values are ‘D’ +(deleted), ‘U’ (updated) or NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+relationship_id + | ++The type of relationship captured by the relationship record. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+relationship_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+is_hierarchical + | ++Defines whether a relationship defines concepts into classes or +hierarchies. Values are 1 for hierarchical relationship or 0 if not. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+defines_ancestry + | ++Defines whether a hierarchical relationship contributes to the +concept_ancestor table. These are subsets of the hierarchical +relationships. Valid values are 1 or 0. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+reverse_relationship_id + | ++The identifier for the relationship used to define the reverse +relationship between two concepts. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+relationship_concept_id + | ++A foreign key that refers to an identifier in the CONCEPT +table for the unique relationship concept. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+concept_synonym_name + | ++ | ++ | ++varchar(1000) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+language_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+ancestor_concept_id + | ++The Concept Id for the higher-level concept that forms the ancestor in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+descendant_concept_id + | ++The Concept Id for the lower-level concept that forms the descendant in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+min_levels_of_separation + | ++The minimum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+max_levels_of_separation + | ++The maximum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+source_code + | ++The source code being translated into a Standard Concept. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+source_concept_id + | ++A foreign key to the Source Concept that is being translated into a +Standard Concept. + | ++This is either 0 or should be a number above 2 billion, which are the +Concepts reserved for site-specific codes and mappings. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+source_vocabulary_id + | ++A foreign key to the VOCABULARY table defining the vocabulary of the +source code that is being translated to a Standard Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+source_code_description + | ++An optional description for the source code. This is included as a +convenience to compare the description of the source code to the name of +the concept. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+target_concept_id + | ++The target Concept to which the source code is being mapped. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+target_vocabulary_id + | ++The Vocabulary of the target Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
+valid_start_date + | ++The date when the mapping instance was first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the mapping instance became invalid because it was deleted +or superseded (updated) by a new relationship. Default value is +31-Dec-2099. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the mapping instance was invalidated. Possible values are D +(deleted), U (replaced with an update) or NULL when valid_end_date has +the default value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_concept_id + | ++The Concept representing the Branded Drug or Clinical Drug Product. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+ingredient_concept_id + | ++The Concept representing the active ingredient contained within the drug +product. + | ++Combination Drugs will have more than one record in this table, one for +each active Ingredient. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+amount_value + | ++The numeric value or the amount of active ingredient contained within +the drug product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+amount_unit_concept_id + | ++The Concept representing the Unit of measure for the amount of active +ingredient contained within the drug product. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+numerator_value + | ++The concentration of the active ingredient contained within the drug +product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+numerator_unit_concept_id + | ++The Concept representing the Unit of measure for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+denominator_value + | ++The amount of total liquid (or other divisible product, such as +ointment, gel, spray, etc.). + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+denominator_unit_concept_id + | ++The Concept representing the denominator unit for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+box_size + | ++The number of units of Clinical Branded Drug or Quantified Clinical or +Branded Drug contained in a box as dispensed to the patient. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when then Concept became invalid. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the concept was invalidated. Possible values are D (deleted), U +(replaced with an update) or NULL when valid_end_date has the default +value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cohort_definition_id + | ++This is the identifier given to the cohort, usually by the ATLAS +application + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_definition_name + | ++A short description of the cohort + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_definition_description + | ++A complete description of the cohort. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+definition_type_concept_id + | ++Type defining what kind of Cohort Definition the record represents and +how the syntax may be executed. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cohort_definition_syntax + | ++Syntax or code to operationalize the Cohort Definition. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+subject_concept_id + | ++This field contains a Concept that represents the domain of the subjects +that are members of the cohort (e.g., Person, Provider, Visit). + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cohort_initiation_date + | ++A date to indicate when the Cohort was initiated in the COHORT table. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+attribute_definition_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+attribute_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+attribute_description + | ++ | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+attribute_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+attribute_syntax + | ++ | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
✅ | -✅ | +✔️ | +✔️ | ||
Data Quality Dashboard | @@ -545,8 +545,8 @@ href="https://github.com/OHDSI/DataQualityDashboard">https://github.com/OHDSI/Da It runs a set of > 3500 data quality checks against an OMOP CDM instance and is required to be run on all databases prior to participating in an OHDSI network research study. -✅ | -⚠️ | +✔️ | +❗ | |
Achilles | @@ -554,8 +554,8 @@ participating in an OHDSI network research study. href="https://github.com/OHDSI/Achilles">https://github.com/OHDSI/Achilles, performing a set of broad database characterizations agains an OMOP CDM instance. -✅ | -⚠️ | +✔️ | +❗ | |
ARES | @@ -564,16 +564,16 @@ href="https://github.com/OHDSI/Ares">https://github.com/OHDSI/Ares and is designed to display the results from both the ACHILLES and DataQualityDashboard packages to support data quality and characterization research. -✅ | -⚠️ | +✔️ | +❗ | |
ATLAS | ATLAS is an open source software tool for researchers to conduct scientific analyses on standardized observational data. Demo | -✅ | -⚠️ | +✔️ | +❗ |
Rabbit-In-A-Hat | @@ -582,8 +582,8 @@ href="https://github.com/OHDSI/WhiteRabbit">https://github.com/OHDSI/WhiteRabbit and is an application for interactive design of an ETL to the OMOP Common Data Model with the help of the the scan report generated by White Rabbit. -✅ | -✅ | +✔️ | +✔️ | |
Feature Extraction | @@ -591,16 +591,16 @@ White Rabbit. href="https://github.com/OHDSI/FeatureExtraction">https://github.com/OHDSI/FeatureExtraction. It is designed to generate features (covariates) for a cohort generated using the OMOP CDM. -✅ | -✅* | +✔️ | +✔️* | |
Cohort Diagnostics | This package can be downloaded from https://github.com/OHDSI/CohortDiagnostics and is used to critically evaluate cohort phenotypes. | -✅ | -⚠️ | +✔️ | +❗ |
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+person_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+gender_concept_id + | ++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 +table. Accepted +gender concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Gender + | +
+year_of_birth + | ++Compute age using year_of_birth. + | ++For data sources with date of birth, the year should be extracted. For +data sources where the year of birth is not available, the approximate +year of birth could be derived based on age group categorization, if +available. + | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+month_of_birth + | ++ | ++For data sources that provide the precise date of birth, the month +should be extracted and stored in this field. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+day_of_birth + | ++ | ++For data sources that provide the precise date of birth, the day should +be extracted and stored in this field. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+birth_datetime + | ++ | ++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. If birth_datetime is not provided in the source, use the +following logic to infer the date: If day_of_birth is null and +month_of_birth is not null then use the first of the month in that year. +If month_of_birth is null or if day_of_birth AND month_of_birth are both +null and the person has records during their year of birth then use the +date of the earliest record, otherwise use the 15th of June of that +year. If time of birth is not given use midnight (00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+race_concept_id + | ++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. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Race + | +
+ethnicity_concept_id + | ++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 + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Ethnicity + | +
+location_id + | ++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 +table here that represents the most granular location information for +the person. This could represent anything from postal code or parts +thereof, state, or county for example. Since many databases contain +deidentified data, it is common that the precision of the location is +reduced to prevent re-identification. This field should capture the last +known location. + | ++integer + | ++No + | ++No + | ++Yes + | ++LOCATION + | ++ | +
+provider_id + | ++The Provider refers to the last known primary care provider (General +Practitioner). + | ++Put the provider_id from the 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++The Care Site refers to where the Provider typically provides the +primary care. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+person_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_value + | ++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 biological sex of the person as it appears in the source data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_concept_id + | ++Due to the small number of options, this tends to be zero. + | ++If the source data codes biological sex in a non-standard vocabulary, +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+race_source_value + | ++This field is used to store the race of the person from the source data. +It is not intended for use in standard analytics but for reference only. + | ++Put the race of the person as it appears in the source data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+race_source_concept_id + | ++Due to the small number of options, this tends to be zero. + | ++If the source data codes race in an OMOP supported vocabulary store the +concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+ethnicity_source_value + | ++This field is used to store the ethnicity of the person from the source +data. It is not intended for use in standard analytics but for reference +only. + | ++If the person has an ethnicity other than the OMB standard of “Hispanic” +or “Not Hispanic” store that value from the source data here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+ethnicity_source_concept_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+observation_period_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The Person ID of the PERSON record for which the Observation Period is +recorded. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+observation_period_start_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+observation_period_end_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+period_type_concept_id + | ++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. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+visit_occurrence_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+visit_concept_id + | ++This field contains a concept id representing the kind of visit, like +inpatient or outpatient. All concepts in this field should be standard +and belong to the Visit domain. + | ++Populate this field based on the kind of visit that took place for the +person. For example this could be “Inpatient Visit”, “Outpatient Visit”, +“Ambulatory Visit”, etc. This table will contain standard 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. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+visit_start_date + | ++For inpatient visits, the start date is typically the admission date. +For outpatient visits the start date and end date will be the same. + | ++When populating VISIT_START_DATE, you should think about the patient +experience to make decisions on how to define visits. In the case of an +inpatient visit this should be the date the patient was admitted to the +hospital or institution. In all other cases this should be the date of +the patient-provider interaction. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_start_datetime + | ++ | ++If no time is given for the start date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_end_date + | ++For inpatient visits the end date is typically the discharge date. If a +Person is still an inpatient in the hospital at the time of the data +extract and does not have a visit_end_date, then set the visit_end_date +to the date of the data pull. + | ++Visit end dates are mandatory. If end dates are not provided in the +source there are three ways in which to derive them: - Outpatient Visit: +visit_end_datetime = visit_start_datetime - Emergency Room Visit: +visit_end_datetime = visit_start_datetime - Inpatient Visit: Usually +there is information about discharge. If not, you should be able to +derive the end date from the sudden decline of activity or from the +absence of inpatient procedures/drugs. - Non-hospital institution +Visits: Particularly for claims data, if end dates are not provided +assume the visit is for the duration of month that it occurs. For +Inpatient Visits ongoing at the date of ETL, put date of processing the +data into visit_end_datetime and visit_type_concept_id with 32220 “Still +patient” to identify the visit as incomplete. - All other Visits: +visit_end_datetime = visit_start_datetime. If this is a one-day visit +the end date should match the start date. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_end_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). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_type_concept_id + | ++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. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++Integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+provider_id + | ++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 +table. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++This field provides information about the Care Site where the Visit took +place. + | ++There should only be one Care Site associated with a Visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+visit_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_source_concept_id + | ++ | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+admitted_from_concept_id + | ++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. If a person was admitted from home, set this to 0. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+admitted_from_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+discharged_to_concept_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+discharged_to_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+preceding_visit_occurrence_id + | ++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”. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+visit_detail_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+visit_detail_concept_id + | ++This field contains a concept id representing the kind of visit detail, +like inpatient or outpatient. All concepts in this field should be +standard and belong to the Visit domain. + | ++Populate this field based on the kind of visit that took place for the +person. For example this could be “Inpatient Visit”, “Outpatient Visit”, +“Ambulatory Visit”, etc. This table will contain standard 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. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+visit_detail_start_date + | ++This is the date of the start of the encounter. This may or may not be +equal to the date of the Visit the Visit Detail is associated with. + | ++When populating VISIT_DETAIL_START_DATE, you should think about the +patient experience to make decisions on how to define visits. Most +likely this should be the date of the patient-provider interaction. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_detail_start_datetime + | ++ | ++If no time is given for the start date of a visit, set it to midnight +(00:00:0000). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_end_date + | ++This the end date of the patient-provider interaction. If a Person is +still an inpatient in the hospital at the time of the data extract and +does not have a visit_end_date, then set the visit_end_date to the date +of the data pull. + | +
+Visit Detail end dates are mandatory. If end dates are not provided in
+the source there are three ways in which to derive them: - +Outpatient Visit Detail: visit_detail_end_datetime = +visit_detail_start_datetime - Emergency Room Visit Detail: +visit_detail_end_datetime = visit_detail_start_datetime - Inpatient +Visit Detail: Usually there is information about discharge. If not, you +should be able to derive the end date from the sudden decline of +activity or from the absence of inpatient procedures/drugs. - +Non-hospital institution Visit Details: Particularly for claims data, if +end dates are not provided assume the visit is for the duration of month +that it occurs. For Inpatient Visit Details ongoing at the date of +ETL, put date of processing the data into visit_detai_end_datetime and +visit_detail_type_concept_id with 32220 “Still patient” to identify the +visit as incomplete. All other Visits Details: visit_detail_end_datetime += visit_detail_start_datetime. + |
++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+visit_detail_end_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). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_type_concept_id + | ++Use this field to understand the provenance of the visit detail record, +or where the record comes from. + | ++Populate this field based on the provenance of the visit detail record, +as in whether it came from an EHR record or billing claim. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+provider_id + | ++There will only be one provider per visit record and +the ETL document should clearly state how they were chosen (attending, +admitting, etc.). This is a typical reason for leveraging the +VISIT_DETAIL table as even though each VISIT_DETAIL record can only have +one provider, there is no limit to the number of VISIT_DETAIL records +that can be associated to a VISIT_OCCURRENCE record. + | ++The additional providers associated to a Visit can be stored in this +table where each VISIT_DETAIL record represents a different provider. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+care_site_id + | ++This field provides information about the Care Site where the Visit +Detail took place. + | ++There should only be one Care Site associated with a Visit Detail. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+visit_detail_source_value + | ++This field houses the verbatim value from the source data representing +the kind of visit detail that took place (inpatient, outpatient, +emergency, etc.) + | ++If there is information about the kind of visit detail 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_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line +up with the logic chosen to determine how visits are created. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+visit_detail_source_concept_id + | ++ | ++If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+admitted_from_concept_id + | ++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. If the person was admitted from home, set this to 0. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+admitted_from_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+discharged_to_source_value + | ++ | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+discharged_to_concept_id + | ++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 DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in +the Visit domain. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Visit + | +
+preceding_visit_detail_id + | ++Use this field to find the visit detail that occurred for the person +prior to the given visit detail record. There could be a few days or a +few years in between. + | ++The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately +preceding the current Visit Detail. Note this is not symmetrical, and +there is no such thing as a “following_visit_id”. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+parent_visit_detail_id + | ++Use this field to find the visit detail that subsumes the given visit +detail record. This is used in the case that a visit detail record needs +to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship. + | ++If there are multiple nested levels to how Visits are represented in the +source, the VISIT_DETAIL_PARENT_ID can be used to record this +relationship. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+visit_occurrence_id + | ++Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE. + | ++Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
ETL Conventions
Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+condition_occurrence_id + | ++The unique key given to a condition record for a person. Refer to the +ETL for how duplicate conditions during the same visit were handled. + | ++Each instance of a condition present in the source data should be +assigned this unique key. In some cases, a person can have multiple +records of the same condition within the same visit. It is valid to keep +these duplicates and assign them individual, unique, +CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be +handled. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the condition is recorded. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+condition_concept_id + | ++The CONDITION_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 condition + | ++The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records +whose source values map to concepts with a domain of “Condition” should +go in this table. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Condition + | +
+condition_start_date + | ++Use this date to determine the start date of the condition + | ++Most often data sources do not have the idea of a start date for a +condition. Rather, if a source only has one date associated with a +condition record it is acceptable to use that date for both the +CONDITION_START_DATE and the CONDITION_END_DATE. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_start_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_end_date + | ++Use this date to determine the end date of the condition + | ++Most often data sources do not have the idea of a start date for a +condition. Rather, if a source only has one date associated with a +condition record it is acceptable to use that date for both the +CONDITION_START_DATE and the CONDITION_END_DATE. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_end_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_type_concept_id + | ++This field can be used to determine the provenance of the Condition +record, as in whether the condition was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance +of the record. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+condition_status_concept_id + | ++This concept represents the point during the visit the diagnosis was +given (admitting diagnosis, final diagnosis), whether the diagnosis was +determined due to laboratory findings, if the diagnosis was +exclusionary, or if it was a preliminary diagnosis, among others. + | ++Choose the Concept in the Condition Status domain that best represents +the point during the visit when the diagnosis was given. These can +include admitting diagnosis, principal diagnosis, and secondary +diagnosis. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Condition Status + | +
+stop_reason + | ++The Stop Reason indicates why a Condition is no longer valid with +respect to the purpose within the source data. Note that a Stop Reason +does not necessarily imply that the condition is no longer occurring. + | ++This information is often not populated in source data and it is a valid +etl choice to leave it blank if the information does not exist. + | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The provider associated with condition record, e.g. the provider who +made the diagnosis or the provider who recorded the symptom. + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the condition occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If a CONDITION_START_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 CONDITION_OCCURRENCE +record. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the condition occurred. For +example, if the person was in the ICU at the time of the diagnosis 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+condition_source_value + | ++This field houses the verbatim value from the source data representing +the condition that occurred. For example, this could be an ICD10 or Read +code. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+condition_source_concept_id + | ++This is the concept representing the condition 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 Condition +necessary for a given analytic use case. Consider using +CONDITION_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+condition_status_source_value + | ++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. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_exposure_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the drug dispensing or +administration is recorded. This may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++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: ‘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. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+drug_exposure_start_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_start_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_end_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: 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 + |
++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_end_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+verbatim_end_date + | ++This is the end date of the drug exposure as it appears in the source +data, if it is given + | ++Put the end date or discontinuation date as it appears from the source +data or leave blank if unavailable. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_type_concept_id + | ++You can use the TYPE_CONCEPT_ID to delineate between prescriptions +written vs. prescriptions dispensed vs. medication history +vs. patient-reported exposure, etc. + | ++Choose the drug_type_concept_id that best represents the provenance of +the record, for example whether it came from a record of a prescription +written or physician administered drug. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+stop_reason + | ++The reason a person stopped a medication as it is represented in the +source. Reasons include regimen completed, changed, removed, etc. This +field will be retired in v6.0. + | ++This information is often not populated in source data and it is a valid +etl choice to leave it blank if the information does not exist. + | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+refills + | ++This is only filled in when the record is coming from a prescription +written this field is meant to represent intended refills at time of the +prescription. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++ | ++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 for more information. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+days_supply + | ++ | ++Days supply of the drug. This should be the verbatim days_supply as +given on the prescription. If the drug is physician administered use +duration end date if given or set to 1 as default if duration is not +available. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+sig + | ++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. + | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+route_concept_id + | ++ | ++The standard CONCEPT_ID that the ROUTE_SOURCE_VALUE maps to in the route +domain. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Route + | +
+lot_number + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the drug was prescribed, administered or +dispensed. + | ++To populate this field drug exposures must be explicitly initiated in +the visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the drug exposure occurred. For +example, if the person was in the ICU at the time of the drug +administration 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+drug_source_value + | ++This field houses the verbatim value from the source data representing +the drug exposure that occurred. For example, this could be an NDC or +Gemscript code. + | ++This code is mapped to a Standard Drug Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+drug_source_concept_id + | ++This is the concept representing the drug 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 Drug +necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID +instead to enable standardized analytics that can be consistent across +the network. + | ++If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+route_source_value + | ++This field houses the verbatim value from the source data representing +the drug route. + | ++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 drug +was given to a patient. This source value is mapped to a standard +concept which is stored in the ROUTE_CONCEPT_ID field. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+dose_unit_source_value + | ++This field houses the verbatim value from the source data representing +the dose unit of the drug given. + | ++This information may be called something different in the source data +but the field is meant to contain a value indicating the unit of dosage +of drug given to the patient. This is an older column and will +be deprecated in an upcoming version. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+procedure_occurrence_id + | ++The unique key given to a procedure record for a person. Refer to the +ETL for how duplicate procedures during the same visit were handled. + | ++Each instance of a procedure occurrence in the source data should be +assigned this unique key. In some cases, a person can have multiple +records of the same procedure within the same visit. It is valid to keep +these duplicates and assign them individual, unique, +PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be +handled. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the procedure is recorded. This may +be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+procedure_concept_id + | ++The PROCEDURE_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 procedure + | ++The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records +whose source values map to standard concepts with a domain of +“Procedure” should go in this table. Accepted +Concepts. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Procedure + | +
+procedure_date + | ++Use this date to determine the date the procedure started. + | ++This is meant to be the start date of the procedure. It +will be renamed in a future version to +PROCEDURE_START_DATE. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+procedure_datetime + | ++ | ++If the procedure has a start time in the native date, use this field to +house that information. This will be renamed in a future version to +PROCEDURE_START_DATETIME. + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_end_date + | ++Use this field to house the date that the procedure ended. + | ++This is meant to be the end date of the procedure. It is not required +and for most cases will be the same as the PROCEDURE_START_DATE. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_end_datetime + | ++Use this field to house the datetime that the procedure ended. + | ++This is meant to house the end datetime of the procedure and will most +often be used in conjunction with the procedure_start_datetime to +determine the length of the procedure. + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_type_concept_id + | ++This field can be used to determine the provenance of the Procedure +record, as in whether the procedure was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance +of the record, for example whether it came from an EHR record or billing +claim. If a procedure is recorded as an EHR encounter, the +PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+modifier_concept_id + | ++The modifiers are intended to give additional information about the +procedure but as of now the vocabulary is under review. + | ++It is up to the ETL to choose how to map modifiers if they exist in +source data. These concepts are typically distinguished by ‘Modifier’ +concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ +vocabulary). If there is more than one modifier on a record, one should +be chosen that pertains to the procedure rather than provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+quantity + | ++If the quantity value is omitted, a single procedure is assumed. + | ++If a Procedure has a quantity of ‘0’ in the source, this should default +to ‘1’ in the ETL. If there is a record in the source it can be assumed +the exposure occurred at least once + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The provider associated with the procedure record, e.g. the provider who +performed the Procedure. + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the procedure occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If a PROCEDURE_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 PROCEDURE_OCCURRENCE +record. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the Procedure occurred. For +example, if the Person was in the ICU at the time of the Procedure 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+procedure_source_value + | ++This field houses the verbatim value from the source data representing +the procedure that occurred. For example, this could be an CPT4 or OPCS4 +code. + | ++Use this value to look up the source concept id and then map the source +concept id to a standard concept id. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+procedure_source_concept_id + | ++This is the concept representing the procedure 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 Procedure +necessary for a given analytic use case. Consider using +PROCEDURE_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the PROCEDURE_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+modifier_source_value + | ++ | ++The original modifier code from the source is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
Source codes and source text fields mapped to Standard Concepts of the Device Domain have to be recorded here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+device_exposure_id + | ++The unique key given to records a person’s exposure to a foreign +physical object or instrument. + | ++Each instance of an exposure to a foreign object or device present in +the source data should be assigned this unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+device_concept_id + | ++The DEVICE_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 foreign object or +instrument the person was exposed to. + | ++The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Device + | +
+device_exposure_start_date + | ++Use this date to determine the start date of the device record. + | ++Valid entries include a start date of a procedure to implant a device, +the date of a prescription for a device, or the date of device +administration. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+device_exposure_start_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_exposure_end_date + | ++The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended +for the patient, if given. + | ++Put the end date or discontinuation date as it appears from the source +data or leave blank if unavailable. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_exposure_end_datetime + | ++ | ++If a source does not specify datetime the convention is to set the time +to midnight (00:00:0000) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_type_concept_id + | ++You can use the TYPE_CONCEPT_ID to denote the provenance of the record, +as in whether the record is from administrative claims or EHR. + | ++Choose the drug_type_concept_id that best represents the provenance of +the record, for example whether it came from a record of a prescription +written or physician administered drug. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+unique_device_id + | ++This is the Unique Device Identification (UDI-DI) number for devices +regulated by the FDA, if given. + | ++For medical devices that are regulated by the FDA, a Unique Device +Identification (UDI) is provided if available in the data source and is +recorded in the UNIQUE_DEVICE_ID field. + | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+production_id + | ++This is the Production Identifier (UDI-PI) portion of the Unique Device +Identification. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++The Provider associated with device record, e.g. the provider who wrote +the prescription or the provider who implanted the device. + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the device was prescribed or given. + | ++To populate this field device exposures must be explicitly initiated in +the visit. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The Visit Detail during which the device was prescribed or given. + | ++To populate this field device exposures must be explicitly initiated in +the visit detail record. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+device_source_value + | ++This field houses the verbatim value from the source data representing +the device exposure that occurred. For example, this could be an NDC or +Gemscript code. + | ++This code is mapped to a Standard Device Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+device_source_concept_id + | ++This is the concept representing the device 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 Device +necessary for a given analytic use case. Consider using +DEVICE_CONCEPT_ID instead to enable standardized analytics that can be +consistent across the network. + | ++If the DEVICE_SOURCE_VALUE is coded in the source data using an OMOP +supported vocabulary put the concept id representing the source value +here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_concept_id + | ++UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit +domain that best represents the unit as given in the source data. + | ++There is no standardization requirement for units associated with +DEVICE_CONCEPT_IDs, however, it is the responsibility of the ETL to +choose the most plausible unit. If there is no unit associated with a +Device record, set to NULL. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+unit_source_value + | ++This field houses the verbatim value from the source data representing +the unit of the Device. For example, blood transfusions are considered +devices and can be given in mL quantities. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. Using +the blood transfusion example, blood transfusion is represented by the +DEVICE_CONCEPT_ID and the unit (mL) would be housed in the +UNIT_SOURCE_VALUE and mapped to a standard concept in the unit domain. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_source_concept_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+measurement_id + | ++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. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the Person for whom the Measurement is recorded. This +may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+measurement_concept_id + | ++The MEASUREMENT_CONCEPT_ID field is recommended for primary use in +analyses, and must be used for network studies. + | ++The CONCEPT_ID that the MEASUREMENT_SOURCE_CONCEPT_ID maps to. Only +records whose SOURCE_CONCEPT_IDs map to Standard Concepts with a domain +of “Measurement” should go in this table. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Measurement + | +
+measurement_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. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+measurement_datetime + | ++ | ++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) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_time + | ++ | ++This is present for backwards compatibility and will be deprecated in an +upcoming version. + | ++varchar(10) + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_type_concept_id + | ++This field can be used to determine the provenance of the Measurement +record, as in whether the measurement was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the +provenance of the record, for example whether it came from an EHR record +or billing claim. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+operator_concept_id + | ++The meaning of Concept 4172703 +for ‘=’ is identical to omission of a OPERATOR_CONCEPT_ID value. Since +the use of this field is rare, it’s important when devising analyses to +not to forget testing for the content of this field for values different +from =. + | ++Operators are =, > and these concepts belong to the ‘Meas Value +Operator’ domain. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+value_as_number + | ++This is the numerical value of the Result of the Measurement, if +available. Note that measurements such as blood pressures will be split +into their component parts i.e. one record for systolic, one record for +diastolic. + | +
+If there is a negative value coming from the source, set the
+VALUE_AS_NUMBER to NULL, with the exception of the following
+Measurements (listed as LOINC codes): - 1925-7 +Base excess in Arterial blood by calculation - 1927-3 +Base excess in Venous blood by calculation - 8632-2 +QRS-Axis - 11555-0 +Base excess in Blood by calculation - 1926-5 +Base excess in Capillary blood by calculation - 28638-5 +Base excess in Arterial cord blood by calculation 28639-3 +Base excess in Venous cord blood by calculation + |
++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++If the raw data gives a categorial result for measurements those values +are captured and mapped to standard concepts in the ‘Meas Value’ domain. + | ++If the raw data provides categorial results as well as continuous +results for measurements, it is a valid ETL choice to preserve both +values. The continuous value should go in the VALUE_AS_NUMBER field and +the categorical value should be mapped to a standard concept in the +‘Meas Value’ domain and put in the VALUE_AS_CONCEPT_ID field. This is +also the destination for the ‘Maps to value’ relationship. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_concept_id + | ++There is currently no recommended unit for individual measurements, +i.e. it is not mandatory to represent Hemoglobin a1C measurements as a +percentage. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in +the Unit domain that best represents the unit as given in the source +data. + | ++There is no standardization requirement for units associated with +MEASUREMENT_CONCEPT_IDs, however, it is the responsibility of the ETL to +choose the most plausible unit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+range_low + | ++Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are +provided by the source and should remain NULL if not given. + | ++If reference ranges for upper and lower limit of normal as provided +(typically by a laboratory) these are stored in the RANGE_HIGH and +RANGE_LOW fields. This should be set to NULL if not provided. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+range_high + | ++Ranges have the same unit as the VALUE_AS_NUMBER. These ranges are +provided by the source and should remain NULL if not given. + | ++If reference ranges for upper and lower limit of normal as provided +(typically by a laboratory) these are stored in the RANGE_HIGH and +RANGE_LOW fields. This should be set to NULL if not provided. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+provider_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+measurement_source_value + | ++This field houses the verbatim value from the source data representing +the Measurement that occurred. For example, this could be an ICD10 or +Read code. + | ++This code is mapped to a Standard Measurement Concept in the +Standardized Vocabularies and the original code is stored here for +reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_source_concept_id + | ++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 an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_source_value + | ++This field houses the verbatim value from the source data representing +the unit of the Measurement that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_source_concept_id + | ++“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. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+value_source_value + | ++This field houses the verbatim result value of the Measurement from the +source data . + | ++If both a continuous and categorical result are given in the source data +such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both +included, store the verbatim value that was mapped to +VALUE_AS_CONCEPT_ID here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+measurement_event_id + | ++If the Measurement record is related to another record in the database, +this field is the primary key of the linked record. + | ++Put the primary key of the linked record, if applicable, here. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+meas_event_field_concept_id + | ++If the Measurement record is related to another record in the database, +this field is the CONCEPT_ID that identifies which table the primary key +of the linked record came from. + | ++Put the CONCEPT_ID that identifies which table and field the +MEASUREMENT_EVENT_ID came from. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+observation_id + | ++The unique key given to an Observation record for a Person. Refer to the +ETL for how duplicate Observations during the same Visit were handled. + | ++Each instance of an observation present in the source data should be +assigned this unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the Person for whom the Observation is recorded. This +may be a system generated code. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+observation_concept_id + | ++The OBSERVATION_CONCEPT_ID field is recommended for primary use in +analyses, and must be used for network studies. + | ++The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is +no specified domain that the Concepts in this table must adhere to. The +only rule is that records with Concepts in the Condition, Procedure, +Drug, Measurement, or Device domains MUST go to the corresponding table. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+observation_date + | ++The date of the Observation. Depending on what the Observation +represents this could be the date of a lab test, the date of a survey, +or the date a patient’s family history was taken. + | ++For some observations the ETL may need to make a choice as to which date +to choose. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+observation_datetime + | ++ | ++If no time is given set to midnight (00:00:00). + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+observation_type_concept_id + | ++This field can be used to determine the provenance of the Observation +record, as in whether the measurement was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the +provenance of the record, for example whether it came from an EHR record +or billing claim. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+value_as_number + | ++This is the numerical value of the Result of the Observation, if +applicable and available. It is not expected that all Observations will +have numeric results, rather, this field is here to house values should +they exist. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_string + | ++This is the categorical value of the Result of the Observation, if +applicable and available. + | ++ | ++varchar(60) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++It is possible that some records destined for the Observation table have +two clinical ideas represented in one source code. This is common with +ICD10 codes that describe a family history of some Condition, for +example. In OMOP the Vocabulary breaks these two clinical ideas into two +codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the +VALUE_AS_CONCEPT_ID. It is important when using the Observation table to +keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID +field for relevant information. + | ++Note that the value of VALUE_AS_CONCEPT_ID may be provided through +mapping from a source Concept which contains the content of the +Observation. In those situations, the CONCEPT_RELATIONSHIP table in +addition to the ‘Maps to’ record contains a second record with the +relationship_id set to ‘Maps to value’. For example, ICD10 Z82.4 +‘Family history of ischaemic heart disease and other diseases of the +circulatory system’ has a ‘Maps to’ relationship to 4167217 +‘Family history of clinical finding’ as well as a ‘Maps to value’ record +to 134057 +‘Disorder of cardiovascular system’. + | ++Integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+qualifier_concept_id + | ++This field contains all attributes specifying the clinical fact further, +such as as degrees, severities, drug-drug interaction alerts etc. + | ++Use your best judgement as to what Concepts to use here and if they are +necessary to accurately represent the clinical record. There is no +restriction on the domain of these Concepts, they just need to be +Standard. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_concept_id + | ++There is currently no recommended unit for individual observation +concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in +the Unit domain that best represents the unit as given in the source +data. + | ++There is no standardization requirement for units associated with +OBSERVATION_CONCEPT_IDs, however, it is the responsibility of the ETL to +choose the most plausible unit. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+provider_id + | ++The provider associated with the observation 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The visit during which the Observation occurred. + | ++Depending on the structure of the source data, this may have to be +determined based on dates. If an OBSERVATION_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 observation record. If an +observation is related to a visit explicitly in the source data, it is +possible that the result date of the Observation falls outside of the +bounds of the Visit dates. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The VISIT_DETAIL record during which the Observation 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. + | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+observation_source_value + | ++This field houses the verbatim value from the source data representing +the Observation that occurred. For example, this could be an ICD10 or +Read code. + | ++This code is mapped to a Standard Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+observation_source_concept_id + | ++This is the concept representing the OBSERVATION_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 +Observation necessary for a given analytic use case. Consider using +OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can +be consistent across the network. + | ++If the OBSERVATION_SOURCE_VALUE is coded in the source data using an +OMOP supported vocabulary put the concept id representing the source +value here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+unit_source_value + | ++This field houses the verbatim value from the source data representing +the unit of the Observation that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+qualifier_source_value + | ++This field houses the verbatim value from the source data representing +the qualifier of the Observation that occurred. + | ++This code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_source_value + | ++This field houses the verbatim result value of the Observation from the +source data. Do not get confused with the Observation_source_value which +captures source value of the observation mapped to +observation_concept_id. This field is the observation result value from +the source. + | ++If the observation_source_value was a question, for example, or an +observation that requires a result then this field is the answer/ result +from the source data. Store the verbatim value that represents the +result of the observation_source_value. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+observation_event_id + | ++If the Observation record is related to another record in the database, +this field is the primary key of the linked record. + | ++Put the primary key of the linked record, if applicable, here. See the +ETL +Conventions for the OBSERVATION table for more details. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+obs_event_field_concept_id + | ++If the Observation record is related to another record in the database, +this field is the CONCEPT_ID that identifies which table the primary key +of the linked record came from. + | ++Put the CONCEPT_ID that identifies which table and field the +OBSERVATION_EVENT_ID came from. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+death_date + | ++The date the person was deceased. + | ++If the precise date include day or month is not known or not allowed, +December is used as the default month, and the last day of the month the +default day. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+death_datetime + | ++ | ++If not available set time to midnight (00:00:00) + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+death_type_concept_id + | ++This is the provenance of the death record, i.e., where it came from. It +is possible that an administrative claims database would source death +information from a government file so do not assume the Death Type is +the same as the Visit Type, etc. + | ++Use the type concept that be reflects the source of the death record. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+cause_concept_id + | ++This is the Standard Concept representing the Person’s cause of death, +if available. + | ++There is no specified domain for this concept, just choose the Standard +Concept Id that best represents the person’s cause of death. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cause_source_value + | ++ | ++If available, put the source code representing the cause of death here. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cause_source_concept_id + | ++ | ++If the cause of death was coded using a Vocabulary present in the OMOP +Vocabularies put the CONCEPT_ID representing the cause of death here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+note_id + | ++A unique identifier for each note. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+note_date + | ++The date the note was recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+note_datetime + | ++ | ++If time is not given set the time to midnight. + | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_type_concept_id + | ++The provenance of the note. Most likely this will be EHR. + | ++Put the source system of the note, as in EHR record. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+note_class_concept_id + | ++A Standard Concept Id representing the HL7 LOINC Document Type +Vocabulary classification of the note. + | ++Map the note classification to a Standard Concept. For more information +see the ETL Conventions in the description of the NOTE table. Accepted +Concepts. This Concept can alternatively be represented by concepts +with the relationship ‘Kind of (LOINC)’ to 706391 +(Note). + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+note_title + | ++The title of the note. + | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_text + | ++The content of the note. + | ++ | ++varchar(MAX) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+encoding_concept_id + | ++This is the Concept representing the character encoding type. + | ++Put the Concept Id that represents the encoding character type here. +Currently the only option is UTF-8 (32678). It +the note is encoded in any other type, like ASCII then put 0. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+language_concept_id + | ++The language of the note. + | ++Use Concepts that are descendants of the concept 4182347 +(World Languages). + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+provider_id + | ++The Provider who wrote the note. + | ++The ETL may need to make a determination on which provider to put here. + | ++integer + | ++No + | ++No + | ++Yes + | ++PROVIDER + | ++ | +
+visit_occurrence_id + | ++The Visit during which the note was written. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_OCCURRENCE + | ++ | +
+visit_detail_id + | ++The Visit Detail during which the note was written. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++VISIT_DETAIL + | ++ | +
+note_source_value + | ++ | ++The source value mapped to the NOTE_CLASS_CONCEPT_ID. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_event_id + | ++If the Note record is related to another record in the database, this +field is the primary key of the linked record. + | ++Put the primary key of the linked record, if applicable, here. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+note_event_field_concept_id + | ++If the Note record is related to another record in the database, this +field is the CONCEPT_ID that identifies which table the primary key of +the linked record came from. + | ++Put the CONCEPT_ID that identifies which table and field the +NOTE_EVENT_ID came from. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+note_nlp_id + | ++A unique identifier for the NLP record. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+note_id + | ++This is the NOTE_ID for the NOTE record the NLP record is associated to. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+section_concept_id + | ++ | ++The SECTION_CONCEPT_ID should be used to represent the note section +contained in the NOTE_NLP record. These concepts can be found as parts +of document panels and are based on the type of note written, i.e. a +discharge summary. These panels can be found as concepts with the +relationship ‘Subsumes’ to CONCEPT_ID 45875957. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+snippet + | ++A small window of text surrounding the term + | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+“offset” + | ++Character offset of the extracted term in the input note + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+lexical_variant + | ++Raw text extracted from the NLP tool. + | ++ | ++varchar(250) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+note_nlp_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+note_nlp_source_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+nlp_system + | ++ | ++Name and version of the NLP system that extracted the term. Useful for +data provenance. + | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+nlp_date + | ++The date of the note processing. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+nlp_datetime + | ++The date and time of the note processing. + | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_exists + | ++ | ++Term_exists is defined as a flag that indicates if the patient actually +has or had the condition. Any of the following modifiers would make +Term_exists false: Negation = true Subject = [anything other than the +patient] Conditional = true/li> Rule_out = true Uncertain = very low +certainty or any lower certainties A complete lack of modifiers would +make Term_exists true. + | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_temporal + | ++ | +
+Term_temporal is to indicate if a condition is present or just in the
+past. The following would be past: - History = true - +Concept_date = anything before the time of the report + |
++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+term_modifiers + | ++ | +
+For the modifiers that are there, they would have to have these
+values: - Negation = false - Subject = patient - Conditional = +false - Rule_out = false - Uncertain = true or high or moderate or even +low (could argue about low). Term_modifiers will concatenate all +modifiers for different types of entities (conditions, drugs, labs etc) +into one string. Lab values will be saved as one of the modifiers. + |
++varchar(2000) + | ++No + | ++No + | ++No + | ++ | ++ | +
Anatomic site is coded at the most specific level of granularity possible, such that higher level classifications can be derived using the Standardized Vocabularies.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+specimen_id + | ++Unique identifier for each specimen. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The person from whom the specimen is collected. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+specimen_concept_id + | ++ | ++The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the +specimen domain. Accepted +Concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+specimen_type_concept_id + | ++ | ++Put the source of the specimen record, as in an EHR system. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+specimen_date + | ++The date the specimen was collected. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+specimen_datetime + | ++ | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+quantity + | ++The amount of specimen collected from the person. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_concept_id + | ++The unit for the quantity of the specimen. + | ++Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. Accepted +Concepts + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+anatomic_site_concept_id + | ++This is the site on the body where the specimen is from. + | ++Map the ANATOMIC_SITE_SOURCE_VALUE to a Standard Concept in the Spec +Anatomic Site domain. This should be coded at the lowest level of +granularity Accepted +Concepts + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+disease_status_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+specimen_source_id + | ++This is the identifier for the specimen from the source system. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specimen_source_value + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+unit_source_value + | ++ | ++This unit for the quantity of the specimen, as represented in the +source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+anatomic_site_source_value + | ++ | ++This is the site on the body where the specimen was taken from, as +represented in the source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+disease_status_source_value + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+domain_concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+fact_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+fact_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+relationship_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+location_id + | ++The unique key given to a unique Location. + | ++Each instance of a Location in the source data should be assigned this +unique key. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+address_1 + | ++This is the first line of the address. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+address_2 + | ++This is the second line of the address + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+city + | ++ | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+state + | ++ | ++ | ++varchar(2) + | ++No + | ++No + | ++No + | ++ | ++ | +
+zip + | ++ | ++Zip codes are handled as strings of up to 9 characters length. For US +addresses, these represent either a 3-digit abbreviated Zip code as +provided by many sources for patient protection reasons, the full +5-digit Zip or the 9-digit (ZIP + 4) codes. Unless for specific reasons +analytical methods should expect and utilize only the first 3 digits. +For international addresses, different rules apply. + | ++varchar(9) + | ++No + | ++No + | ++No + | ++ | ++ | +
+county + | ++ | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+location_source_value + | ++ | ++Put the verbatim value for the location here, as it shows up in the +source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+country_concept_id + | ++The Concept Id representing the country. Values should conform to the Geography +domain. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+country_source_value + | ++The name of the country. + | ++ | ++varchar(80) + | ++No + | ++No + | ++No + | ++ | ++ | +
+latitude + | ++ | ++Must be between -90 and 90. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+longitude + | ++ | ++Must be between -180 and 180. + | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+care_site_id + | ++ | ++Assign an ID to each combination of a location and nature of the site - +the latter could be the Place of Service, name or another characteristic +in your source data. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+care_site_name + | ++The name of the care_site as it appears in the source data + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+place_of_service_concept_id + | ++This is a high-level way of characterizing a Care Site. Typically, +however, Care Sites can provide care in multiple settings (inpatient, +outpatient, etc.) and this granularity should be reflected in the visit. + | ++Choose the concept in the visit domain that best represents the setting +in which healthcare is provided in the Care Site. If most visits in a +Care Site are Inpatient, then the place_of_service_concept_id should +represent Inpatient. If information is present about a unique Care Site +(e.g. Pharmacy) then a Care Site record should be created. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+location_id + | ++The location_id from the LOCATION table representing the physical +location of the care_site. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++LOCATION + | ++ | +
+care_site_source_value + | ++The identifier of the care_site as it appears in the source data. This +could be an identifier separate from the name of the care_site. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+place_of_service_source_value + | ++ | ++Put the place of service of the care_site as it appears in the source +data. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+provider_id + | ++It is assumed that every provider with a different unique identifier is +in fact a different person and should be treated independently. + | ++This identifier can be the original id from the source data provided it +is an integer, otherwise it can be an autogenerated number. + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+provider_name + | ++ | ++This field is not necessary as it is not necessary to have the actual +identity of the Provider. Rather, the idea is to uniquely and +anonymously identify providers of care across the database. + | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+npi + | ++This is the National Provider Number issued to health care providers in +the US by the Centers for Medicare and Medicaid Services (CMS). + | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+dea + | ++This is the identifier issued by the DEA, a US federal agency, that +allows a provider to write prescriptions for controlled substances. + | ++ | ++varchar(20) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_concept_id + | ++This field either represents the most common specialty that occurs in +the data or the most specific concept that represents all specialties +listed, should the provider have more than one. This includes physician +specialties such as internal medicine, emergency medicine, etc. and +allied health professionals such as nurses, midwives, and pharmacists. + | ++If a Provider has more than one Specialty, there are two options: 1. +Choose a concept_id which is a common ancestor to the multiple +specialties, or, 2. Choose the specialty that occurs most often for the +provider. Concepts in this field should be Standard with a domain of +Provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+care_site_id + | ++This is the CARE_SITE_ID for the location that the provider primarily +practices in. + | ++If a Provider has more than one Care Site, the main or most often +exerted CARE_SITE_ID should be recorded. + | ++integer + | ++No + | ++No + | ++Yes + | ++CARE_SITE + | ++ | +
+year_of_birth + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_concept_id + | ++This field represents the recorded gender of the provider in the source +data. + | ++If given, put a concept from the gender domain representing the recorded +gender of the provider. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++Gender + | +
+provider_source_value + | ++Use this field to link back to providers in the source data. This is +typically used for error checking of ETL logic. + | ++Some use cases require the ability to link back to providers in the +source data. This field allows for the storing of the provider +identifier as it appears in the source. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_source_value + | ++This is the kind of provider or specialty as it appears in the source +data. This includes physician specialties such as internal medicine, +emergency medicine, etc. and allied health professionals such as nurses, +midwives, and pharmacists. + | ++Put the kind of provider as it appears in the source data. This field is +up to the discretion of the ETL-er as to whether this should be the +coded value from the source or the text description of the lookup value. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+specialty_source_concept_id + | ++This is often zero as many sites use proprietary codes to store +physician speciality. + | ++If the source data codes provider specialty in an OMOP supported +vocabulary store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+gender_source_value + | ++This is provider’s gender as it appears in the source data. + | ++Put the provider’s gender as it appears in the source data. This field +is up to the discretion of the ETL-er as to whether this should be the +coded value from the source or the text description of the lookup value. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+gender_source_concept_id + | ++This is often zero as many sites use proprietary codes to store provider +gender. + | ++If the source data codes provider gender in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+payer_plan_period_id + | ++A unique identifier for each unique combination of a Person, Payer, +Plan, and Period of time. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The Person covered by the Plan. + | ++A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD +records + | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+payer_plan_period_start_date + | ++Start date of Plan coverage. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+payer_plan_period_end_date + | ++End date of Plan coverage. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+payer_concept_id + | ++This field represents the organization who reimburses the provider which +administers care to the Person. + | ++Map the Payer directly to a standard CONCEPT_ID. If one does not exists +please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same payer, though the +name of the Payer is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+payer_source_value + | ++This is the Payer as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+payer_source_concept_id + | ++ | ++If the source data codes the Payer in an OMOP supported vocabulary store +the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+plan_concept_id + | ++This field represents the specific health benefit Plan the Person is +enrolled in. + | ++Map the Plan directly to a standard CONCEPT_ID. If one does not exists +please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same health benefit +Plan though the name of the Plan is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+plan_source_value + | ++This is the health benefit Plan of the Person as it appears in the +source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+plan_source_concept_id + | ++ | ++If the source data codes the Plan in an OMOP supported vocabulary store +the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+sponsor_concept_id + | ++This field represents the sponsor of the Plan who finances the Plan. +This includes self-insured, small group health plan and large group +health plan. + | ++Map the sponsor directly to a standard CONCEPT_ID. If one does not +exists please contact the vocabulary team. There is no global controlled +vocabulary available for this information. The point is to stratify on +this information and identify if Persons have the same sponsor though +the name of the sponsor is not necessary. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+sponsor_source_value + | ++The Plan sponsor as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+sponsor_source_concept_id + | ++ | ++If the source data codes the sponsor in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+family_source_value + | ++The common identifier for all people (often a family) that covered by +the same policy. + | ++Often these are the common digits of the enrollment id of the policy +members. + | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+stop_reason_concept_id + | ++This field represents the reason the Person left the Plan, if known. + | ++Map the stop reason directly to a standard CONCEPT_ID. If one does not +exists please contact the vocabulary team. There is no global controlled +vocabulary available for this information. Accepted +Concepts. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+stop_reason_source_value + | ++The Plan stop reason as it appears in the source data. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+stop_reason_source_concept_id + | ++ | ++If the source data codes the stop reason in an OMOP supported vocabulary +store the concept_id here. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cost_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+cost_event_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cost_domain_id + | ++ | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
+cost_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+currency_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+total_charge + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+total_cost + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+total_paid + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_payer + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_patient + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_copay + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_coinsurance + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_patient_deductible + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_by_primary + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_ingredient_cost + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+paid_dispensing_fee + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+payer_plan_period_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+amount_allowed + | ++ | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+revenue_code_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+revenue_code_source_value + | ++Revenue codes are a method to charge for a class of procedures and +conditions in the U.S. hospital system. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+drg_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+drg_source_value + | ++Diagnosis Related Groups are US codes used to classify hospital cases +into one of approximately 500 groups. + | ++ | ++varchar(3) + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
The SQL script for generating DRUG_ERA records can be found here.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++The Concept Id representing the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+drug_era_start_date + | ++ | ++The Drug Era Start Date is the start date of the first Drug Exposure for +a given ingredient, with at least 31 days since the previous exposure. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_era_end_date + | ++ | ++The Drug Era End Date is the end date of the last Drug Exposure. The End +Date of each Drug Exposure is either taken from the field +drug_exposure_end_date or, as it is typically not available, inferred +using the following rules: For pharmacy prescription data, the date when +the drug was dispensed plus the number of days of supply are used to +extrapolate the End Date for the Drug Exposure. Depending on the +country-specific healthcare system, this supply information is either +explicitly provided in the day_supply field or inferred from package +size or similar information. For Procedure Drugs, usually the drug is +administered on a single date (i.e., the administration date). A +standard Persistence Window of 30 days (gap, slack) is permitted between +two subsequent such extrapolated DRUG_EXPOSURE records to be considered +to be merged into a single Drug Era. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+drug_exposure_count + | ++ | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+gap_days + | ++ | ++The Gap Days determine how many total drug-free days are observed +between all Drug Exposure events that contribute to a DRUG_ERA record. +It is assumed that the drugs are “not stockpiled” by the patient, +i.e. that if a new drug prescription or refill is observed (a new +DRUG_EXPOSURE record is written), the remaining supply from the previous +events is abandoned. The difference between Persistence Window and Gap +Days is that the former is the maximum drug-free time allowed between +two subsequent DRUG_EXPOSURE records, while the latter is the sum of +actual drug-free days for the given Drug Era under the above assumption +of non-stockpiling. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+dose_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+drug_concept_id + | ++The Concept Id representing the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Drug + | +
+unit_concept_id + | ++The Concept Id representing the unit of the specific drug ingredient. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Unit + | +
+dose_value + | ++The numeric value of the dosage of the drug_ingredient. + | ++ | ++float + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+dose_era_start_date + | ++The date the Person started on the specific dosage, with at least 31 +days since any prior exposure. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+dose_era_end_date + | ++ | ++The date the Person was no longer exposed to the dosage of the specific +drug ingredient. An era is ended if there are 31 days or more between +dosage records. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+condition_era_id + | ++ | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+condition_concept_id + | ++The Concept Id representing the Condition. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Condition + | +
+condition_era_start_date + | ++The start date for the Condition Era constructed from the individual +instances of Condition Occurrences. It is the start date of the very +first chronologically recorded instance of the condition with at least +31 days since any prior record of the same Condition. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_era_end_date + | ++The end date for the Condition Era constructed from the individual +instances of Condition Occurrences. It is the end date of the final +continuously recorded instance of the Condition. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+condition_occurrence_count + | ++The number of individual Condition Occurrences used to construct the +condition era. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+episode_id + | ++A unique identifier for each Episode. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+person_id + | ++The PERSON_ID of the PERSON for whom the episode is recorded. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++PERSON + | ++ | +
+episode_concept_id + | ++The EPISODE_CONCEPT_ID represents the kind abstraction related to the +disease phase, outcome or treatment. + | ++Choose a concept in the Episode domain that best represents the ongoing +disease phase, outcome, or treatment. Please see [article] for cancers +and [article] for non-cancers describing how these are defined. Accepted +Concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Episode + | +
+episode_start_date + | ++The date when the Episode beings. + | ++Please see [article] for how to define an Episode start date. + | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+episode_start_datetime + | ++The date and time when the Episode begins. + | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_end_date + | ++The date when the instance of the Episode is considered to have ended. + | ++Please see [article] for how to define an Episode end date. + | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_end_datetime + | ++The date when the instance of the Episode is considered to have ended. + | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_parent_id + | ++Use this field to find the Episode that subsumes the given Episode +record. This is used in the case that an Episode are nested into each +other. + | ++If there are multiple nested levels to how Episodes are represented, the +EPISODE_PARENT_ID can be used to record this relationship. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_number + | ++For sequences of episodes, this is used to indicate the order the +episodes occurred. For example, lines of treatment could be indicated +here. + | ++Please see [article] for the details of how to count episodes. + | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_object_concept_id + | ++A Standard Concept representing the disease phase, outcome, or other +abstraction of which the episode consists. For example, if the +EPISODE_CONCEPT_ID is treatment +regimen then the EPISODE_OBJECT_CONCEPT_ID should contain the +chemotherapy regimen concept, like Afatinib +monotherapy. + | ++Episode entries from the ‘Disease Episode’ concept class should have an +episode_object_concept_id that comes from the Condition domain. Episode +entries from the ‘Treatment Episode’ concept class should have an +episode_object_concept_id that scome from the ‘Procedure’ domain or +‘Regimen’ concept class. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Procedure, Regimen + | +
+episode_type_concept_id + | ++This field can be used to determine the provenance of the Episode +record, as in whether the episode was from an EHR system, insurance +claim, registry, or other sources. + | ++Choose the EPISODE_TYPE_CONCEPT_ID that best represents the provenance +of the record. Accepted +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Type Concept + | +
+episode_source_value + | ++The source code for the Episdoe as it appears in the source data. This +code is mapped to a Standard Condition Concept in the Standardized +Vocabularies and the original code is stored here for reference. + | ++ | ++varchar(50) + | ++No + | ++No + | ++No + | ++ | ++ | +
+episode_source_concept_id + | ++A foreign key to a Episode Concept that refers to the code used in the +source. + | ++Given that the Episodes are user-defined it is unlikely that there will +be a Source Concept available. If that is the case then set this field +to zero. + | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
ETL Conventions
Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated.
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+episode_id + | ++Use this field to link the EPISODE_EVENT record to its EPISODE. + | ++Put the EPISODE_ID that subsumes the EPISODE_EVENT record here. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++EPISODE + | ++ | +
+event_id + | ++This field is the primary key of the linked record in the database. For +example, if the Episode Event is a Condition Occurrence, then the +CONDITION_OCCURRENCE_ID of the linked record goes in this field. + | ++Put the primary key of the linked record here. + | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+episode_event_field_concept_id + | ++This field is the CONCEPT_ID that identifies which table the primary key +of the linked record came from. + | ++Put the CONCEPT_ID that identifies which table and field the EVENT_ID +came from. Accepted +Concepts + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++Metadata + | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+metadata_id + | ++The unique key given to a Metadata record. + | ++Attribute value is auto-generated + | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+metadata_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+metadata_type_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+name + | ++ | ++ | ++varchar(250) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+value_as_string + | ++ | ++ | ++varchar(250) + | ++No + | ++No + | ++No + | ++ | ++ | +
+value_as_concept_id + | ++ | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+value_as_number + | ++This is the numerical value of the result of the Metadata, if applicable +and available. It is not expected that all Metadata will have numeric +results, rather, this field is here to house values should they exist. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+metadata_date + | ++ | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +
+metadata_datetime + | ++ | ++ | ++datetime + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cdm_source_name + | ++The name of the CDM instance. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cdm_source_abbreviation + | ++The abbreviation of the CDM instance. + | ++ | ++varchar(25) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cdm_holder + | ++The holder of the CDM instance. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+source_description + | ++The description of the CDM instance. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+source_documentation_reference + | ++ | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_etl_reference + | ++ | ++Put the link to the CDM version used. + | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+source_release_date + | ++The release date of the source data. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cdm_release_date + | ++The release data of the CDM instance. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cdm_version + | ++ | ++ | ++varchar(10) + | ++No + | ++No + | ++No + | ++ | ++ | +
+cdm_version_concept_id + | ++The Concept Id representing the version of the CDM. + | ++You can find all concepts that represent the CDM versions using the +query: SELECT * FROM CONCEPT WHERE VOCABULARY_ID = ‘CDM’ AND +CONCEPT_CLASS = ‘CDM’ + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+vocabulary_version + | ++ | ++You can find the version of your Vocabulary using the query: SELECT +vocabulary_version from vocabulary where vocabulary_id = ‘None’ + | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id + | ++A unique identifier for each Concept across all domains. + | ++ | ++integer + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+concept_name + | ++An unambiguous, meaningful and descriptive name for the Concept. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_id + | ++A foreign key to the DOMAIN +table the Concept belongs to. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++DOMAIN + | ++ | +
+vocabulary_id + | ++A foreign key to the VOCABULARY +table indicating from which source the Concept has been adapted. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
+concept_class_id + | ++The attribute or concept class of the Concept. Examples are ‘Clinical +Drug’, ‘Ingredient’, ‘Clinical Finding’ etc. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++CONCEPT_CLASS + | ++ | +
+standard_concept + | ++This flag determines where a Concept is a Standard Concept, i.e. is used +in the data, a Classification Concept, or a non-standard Source Concept. +The allowable values are ‘S’ (Standard Concept) and ‘C’ (Classification +Concept), otherwise the content is NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
+concept_code + | ++The concept code represents the identifier of the Concept in the source +vocabulary, such as SNOMED-CT concept IDs, RxNorm RXCUIs etc. Note that +concept codes are not unique across vocabularies. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970, meaning, the Concept has no (known) date of inception. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the Concept became invalid because it was deleted or +superseded (updated) by a new concept. The default value is 31-Dec-2099, +meaning, the Concept is valid until it becomes deprecated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the Concept was invalidated. Possible values are D (deleted), U +(replaced with an update) or NULL when valid_end_date has the default +value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+vocabulary_id + | ++A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+vocabulary_name + | ++The name describing the vocabulary, for example, International +Classification of Diseases, Ninth Revision, Clinical Modification, +Volume 1 and 2 (NCHS) etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+vocabulary_reference + | ++External reference to documentation or available download of the about +the vocabulary. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+vocabulary_version + | ++Version of the Vocabulary as indicated in the source. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+vocabulary_concept_id + | ++A Concept that represents the Vocabulary the VOCABULARY record belongs +to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+domain_id + | ++A unique key for each domain. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+domain_name + | ++The name describing the Domain, e.g. Condition, Procedure, Measurement +etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+domain_concept_id + | ++A Concept representing the Domain Concept the DOMAIN record belongs to. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_class_id + | ++A unique key for each class. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+concept_class_name + | ++The name describing the Concept Class, e.g. Clinical Finding, +Ingredient, etc. + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+concept_class_concept_id + | ++A Concept that represents the Concept Class. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id_1 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+concept_id_2 + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+relationship_id + | ++The relationship between CONCEPT_ID_1 and CONCEPT_ID_2. Please see the +Vocabulary +Conventions. for more information. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++RELATIONSHIP + | ++ | +
+valid_start_date + | ++The date when the relationship is first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the relationship is invalidated. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the relationship was invalidated. Possible values are ‘D’ +(deleted), ‘U’ (updated) or NULL. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+relationship_id + | ++The type of relationship captured by the relationship record. + | ++ | ++varchar(20) + | ++Yes + | ++Yes + | ++No + | ++ | ++ | +
+relationship_name + | ++ | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+is_hierarchical + | ++Defines whether a relationship defines concepts into classes or +hierarchies. Values are 1 for hierarchical relationship or 0 if not. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+defines_ancestry + | ++Defines whether a hierarchical relationship contributes to the +concept_ancestor table. These are subsets of the hierarchical +relationships. Valid values are 1 or 0. + | ++ | ++varchar(1) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+reverse_relationship_id + | ++The identifier for the relationship used to define the reverse +relationship between two concepts. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+relationship_concept_id + | ++A foreign key that refers to an identifier in the CONCEPT +table for the unique relationship concept. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+concept_synonym_name + | ++ | ++ | ++varchar(1000) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+language_concept_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+ancestor_concept_id + | ++The Concept Id for the higher-level concept that forms the ancestor in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+descendant_concept_id + | ++The Concept Id for the lower-level concept that forms the descendant in +the relationship. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+min_levels_of_separation + | ++The minimum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+max_levels_of_separation + | ++The maximum separation in number of levels of hierarchy between ancestor +and descendant concepts. This is an attribute that is used to simplify +hierarchic analysis. + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+source_code + | ++The source code being translated into a Standard Concept. + | ++ | ++varchar(50) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+source_concept_id + | ++A foreign key to the Source Concept that is being translated into a +Standard Concept. + | ++This is either 0 or should be a number above 2 billion, which are the +Concepts reserved for site-specific codes and mappings. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+source_vocabulary_id + | ++A foreign key to the VOCABULARY table defining the vocabulary of the +source code that is being translated to a Standard Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+source_code_description + | ++An optional description for the source code. This is included as a +convenience to compare the description of the source code to the name of +the concept. + | ++ | ++varchar(255) + | ++No + | ++No + | ++No + | ++ | ++ | +
+target_concept_id + | ++The target Concept to which the source code is being mapped. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+target_vocabulary_id + | ++The Vocabulary of the target Concept. + | ++ | ++varchar(20) + | ++Yes + | ++No + | ++Yes + | ++VOCABULARY + | ++ | +
+valid_start_date + | ++The date when the mapping instance was first recorded. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when the mapping instance became invalid because it was deleted +or superseded (updated) by a new relationship. Default value is +31-Dec-2099. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the mapping instance was invalidated. Possible values are D +(deleted), U (replaced with an update) or NULL when valid_end_date has +the default value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+drug_concept_id + | ++The Concept representing the Branded Drug or Clinical Drug Product. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+ingredient_concept_id + | ++The Concept representing the active ingredient contained within the drug +product. + | ++Combination Drugs will have more than one record in this table, one for +each active Ingredient. + | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+amount_value + | ++The numeric value or the amount of active ingredient contained within +the drug product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+amount_unit_concept_id + | ++The Concept representing the Unit of measure for the amount of active +ingredient contained within the drug product. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+numerator_value + | ++The concentration of the active ingredient contained within the drug +product. + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+numerator_unit_concept_id + | ++The Concept representing the Unit of measure for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+denominator_value + | ++The amount of total liquid (or other divisible product, such as +ointment, gel, spray, etc.). + | ++ | ++float + | ++No + | ++No + | ++No + | ++ | ++ | +
+denominator_unit_concept_id + | ++The Concept representing the denominator unit for the concentration of +active ingredient. + | ++ | ++integer + | ++No + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+box_size + | ++The number of units of Clinical Branded Drug or Quantified Clinical or +Branded Drug contained in a box as dispensed to the patient. + | ++ | ++integer + | ++No + | ++No + | ++No + | ++ | ++ | +
+valid_start_date + | ++The date when the Concept was first recorded. The default value is +1-Jan-1970. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+valid_end_date + | ++The date when then Concept became invalid. + | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+invalid_reason + | ++Reason the concept was invalidated. Possible values are D (deleted), U +(replaced with an update) or NULL when valid_end_date has the default +value. + | ++ | ++varchar(1) + | ++No + | ++No + | ++No + | ++ | ++ | +
+CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cohort_definition_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+subject_id + | ++ | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_start_date + | ++ | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_end_date + | ++ | ++ | ++date + | ++Yes + | ++No + | ++No + | ++ | ++ | +
NA
ETL Conventions
NA
++CDM Field + | ++User Guide + | ++ETL Conventions + | ++Datatype + | ++Required + | ++Primary Key + | ++Foreign Key + | ++FK Table + | ++FK Domain + | +
---|---|---|---|---|---|---|---|---|
+cohort_definition_id + | ++This is the identifier given to the cohort, usually by the ATLAS +application + | ++ | ++integer + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_definition_name + | ++A short description of the cohort + | ++ | ++varchar(255) + | ++Yes + | ++No + | ++No + | ++ | ++ | +
+cohort_definition_description + | ++A complete description of the cohort. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+definition_type_concept_id + | ++Type defining what kind of Cohort Definition the record represents and +how the syntax may be executed. + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cohort_definition_syntax + | ++Syntax or code to operationalize the Cohort Definition. + | ++ | ++varchar(MAX) + | ++No + | ++No + | ++No + | ++ | ++ | +
+subject_concept_id + | ++This field contains a Concept that represents the domain of the subjects +that are members of the cohort (e.g., Person, Provider, Visit). + | ++ | ++integer + | ++Yes + | ++No + | ++Yes + | ++CONCEPT + | ++ | +
+cohort_initiation_date + | ++A date to indicate when the Cohort was initiated in the COHORT table. + | ++ | ++date + | ++No + | ++No + | ++No + | ++ | ++ | +