OMOP/docs/inst/csv/OMOP_CDMv5.3.1_Field_Level.csv

56 KiB
Raw Blame History

1cdmTableNamecdmFieldNameisRequiredisRequiredThresholdcdmDatatypecdmDatatypeThresholduserGuidanceetlConventionsisPrimaryKeyisPrimaryKeyThresholdisForeignKeyisForeignKeyThresholdfkTableNamefkFieldNamefkDomainfkDomainThresholdfkClassfkClassThresholdisStandardValidConceptisStandardValidConceptThresholdmeasureValueCompletenessmeasureValueCompletenessThresholdstandardConceptRecordCompletenessstandardConceptRecordCompletenessThresholdsourceConceptRecordCompletenesssourceConceptRecordCompletenessThresholdsourceValueCompletenesssourceValueCompletenessThresholdstandardConceptFieldNameplausibleValueLowplausibleValueLowThresholdplausibleValueHighplausibleValueHighThresholdplausibleTemporalAfterTableNameplausibleTemporalAfterFieldNameplausibleTemporalAfterThresholdplausibleDuringLifeplausibleDuringLifeThreshold
2PERSONperson_idYes0integer0It 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 identify unique persons should be done prior to ETL.Yes0NoNoYes100NoNoNoNo
3PERSONgender_concept_idYes0integer0This 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.NoYes0CONCEPTCONCEPT_IDGender0Yes0Yes100Yes0NoNoNo
4PERSONyear_of_birthYes0integer0For data sources with date of birth, the year is extracted. For data sources where the year of birth is not available, the approximate year of birth is derived based on any age group categorization available.NoNoNoYes100NoNoNo18500YEAR(GETDATE())+10No
5PERSONmonth_of_birthNointeger0For data sources that provide the precise date of birth, the month is extracted and stored in this field.NoNoNoYes100NoNoNo10120No
6PERSONday_of_birthNointeger0For data sources that provide the precise date of birth, the day is extracted and stored in this field.NoNoNoYes100NoNoNo10310No
7PERSONbirth_datetimeNodatetime0Compute age using birth_datetime.For data sources that provide the precise datetime of birth, store that value 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 month/1/year. If month_of_birth is null then use 1/day/year, if day_of_birth is null and month_of_birth is null then 1/1/year. If time of birth is not given use midnight (00:00:0000).NoNoNoYes100NoNoNo'1850-01-01'0DATEADD(dd,1,GETDATE())0No
8PERSONrace_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDRace0Yes0Yes100Yes0NoNoNo
9PERSONethnicity_concept_idYes0integer0Ethnic backgrounds as subsets of race. The OMOP CDM adheres to the OMB standards so only Concepts that represent "Hispanic" and "Not Hispanic" are stored here. If a source has more granular ethnicity information it can be found in the field ethnicity_source_value.Ethnicity in the OMOP CDM follows the OMB Standards for Data on Race and Ethnicity: Only distinctions between Hispanics and Non-Hispanics are made. If a source provides more granular ethnicity information it should be stored in the field ethnicity_source_value.NoYes0CONCEPTCONCEPT_IDEthnicity0Yes0Yes100Yes0NoNoNo
10PERSONlocation_idNointeger0The location refers to the physical address of the person.Put the location_id from the LOCATION table here that represents the most granular location information for the person. This could be zip code, state, or county for example.NoYes0LOCATIONLOCATION_IDNoYes100NoNoNoNo
11PERSONprovider_idNointeger0The 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.NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
12PERSONcare_site_idNointeger0The Care Site refers to where the Provider typically provides the primary care.NoYes0CARE_SITECARE_SITE_IDNoYes100NoNoNoNo
13PERSONperson_source_valueNovarchar(50)0Use 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.NoNoNoYes100NoNoNoNo
14PERSONgender_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0GENDER_CONCEPT_IDNo
15PERSONgender_source_concept_idNoInteger0If the source data codes biological sex in a non-standard vocabulary, store the concept_id here.NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
16PERSONrace_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0RACE_CONCEPT_IDNo
17PERSONrace_source_concept_idNoInteger0If the source data codes race in an OMOP supported vocabulary store the concept_id here.NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
18PERSONethnicity_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0ETHNICITY_CONCEPT_IDNo
19PERSONethnicity_source_concept_idNoInteger0If the source data codes ethnicity in an OMOP supported vocabulary, store the concept_id here.NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
20OBSERVATION_PERIODobservation_period_idYes0integer0A Person can have multiple discrete observations periods which are identified by the Observation_Period_Id. It is assumed that the observation period covers the period of time for which we know events occurred for the Person. In the context of the Common Data Model the absence of events during an observation period implies that the event did not occur.Assign a unique observation_period_id to each discrete observation period for a Person. An observation period should the length of time for which we know events occurred for the Person. It may take some logic to define an observation period, especially when working with EHR or registry data. Often if no enrollment or coverage information is given an observation period is defined as the time between the earliest record and the latest record available for a person.Yes0NoNoYes100NoNoNoNo
21OBSERVATION_PERIODperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
22OBSERVATION_PERIODobservation_period_start_dateYes0date0Use this date to determine the start date of the period for which we can assume that all events for a Person are recorded and any absense of records indicates an absence of events.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 US claims, the observation period can be considered as the time period the person is enrolled with an insurer. If a Person switches plans but stays with the same insurer, that change would be captured in payer_plan_period.NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
23OBSERVATION_PERIODobservation_period_end_dateYes0date0Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded and any absense of records indicates an absence of events.It is often the case that the idea of observation periods does not exist in source data. In those cases the observation_period_start_end_date can be inferred as the latest event date available for the Person. The event dates include insurance enrollment dates.NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0OBSERVATION_PERIODOBSERVATION_PERIOD_START_DATE0Yes0
24OBSERVATION_PERIODperiod_type_concept_idYes0Integer0This field can be used to determine the provenance of the observation period as in whether the period was determined from an insurance enrollment file or if it was determined from EHR healthcare encounters.Choose the observation_period_type_concept_id that best represents how the period was determined.NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
25VISIT_OCCURRENCEvisit_occurrence_idYes0integer0Use 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.Yes0NoNoYes100NoNoNoNo
26VISIT_OCCURRENCEperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
27VISIT_OCCURRENCEvisit_concept_idYes0integer0This field contains a concept id representing the kind of visit, like inpatient or outpatient.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. It is often the case that some logic should be written for how to define visits and how to assign Visit_Concept_Id. In US claims outpatient visits that appear to occur within the time period of an inpatient visit can be rolled into one with the same Visit_Occurrence_Id. In EHR data inpatient visits that are within one day of each other may be strung together to create one visit. It will all depend on the source data and how encounter records should be translated to visit occurrences.NoYes0CONCEPTCONCEPT_IDVisit0Yes0Yes100Yes0NoNoNo
28VISIT_OCCURRENCEvisit_start_dateYes0date0For 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 will first have to make decisions on how to define visits. In some cases visits in the source data can be strung together if there are one or fewer days between them.NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
29VISIT_OCCURRENCEvisit_start_datetimeNodatetime0If no time is given for the start date of a visit, set it to midnight (00:00:0000).NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
30VISIT_OCCURRENCEvisit_end_dateYes0date0For 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.NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0VISIT_OCCURRENCEVISIT_START_DATE0Yes0
31VISIT_OCCURRENCEvisit_end_datetimeNodatetime0If no time is given for the end date of a visit, set it to midnight (00:00:0000).NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0VISIT_OCCURRENCEVISIT_START_DATETIME0Yes0
32VISIT_OCCURRENCEvisit_type_concept_idYes0Integer0Use 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.NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
33VISIT_OCCURRENCEprovider_idNointeger0There will only be one provider per visit. If multiple providers are associated with a visit that information can be found 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.NoNoPROVIDERPROVIDER_IDNoYes100NoNoNoNo
34VISIT_OCCURRENCEcare_site_idNointeger0This field provides information about the care site where the visit took place.There should only be one care site associated with a visit.NoNoCARE_SITECARE_SITE_IDNoYes100NoNoNoNo
35VISIT_OCCURRENCEvisit_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0VISIT_CONCEPT_IDNo
36VISIT_OCCURRENCEvisit_source_concept_idNointeger0If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
37VISIT_OCCURRENCEadmitting_source_concept_idNointeger0Use 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.NoYes0CONCEPTCONCEPT_IDVisit0Yes0Yes100Yes0NoNoNo
38VISIT_OCCURRENCEadmitting_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0ADMITTING_SOURCE_CONCEPT_IDNo
39VISIT_OCCURRENCEdischarge_to_concept_idNointeger0Use 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.NoYes0CONCEPTCONCEPT_IDVisit0Yes0Yes100Yes0NoNoNo
40VISIT_OCCURRENCEdischarge_to_source_valueNovarchar(50)0This 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.NoNoNoYes100NoNoYes0DISCHARGE_TO_CONCEPT_IDNo
41VISIT_OCCURRENCEpreceding_visit_occurrence_idNointeger0Use this field to find the visit that occured for the person prior to the given visit. There could be a few days or a few years in between.The preceding_visit_id 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".NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
42CONDITION_OCCURRENCEcondition_occurrence_idYes0bigint0Yes0NoNoYes100NoNoNoNo
43CONDITION_OCCURRENCEperson_idYes0bigint0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
44CONDITION_OCCURRENCEcondition_concept_idYes0integer0The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studiesNoYes0CONCEPTCONCEPT_IDCondition0Yes0Yes100Yes0NoNoNo
45CONDITION_OCCURRENCEcondition_start_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
46CONDITION_OCCURRENCEcondition_start_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
47CONDITION_OCCURRENCEcondition_end_dateNodate0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0CONDITION_OCCURRENCECONDITION_START_DATE0Yes0
48CONDITION_OCCURRENCEcondition_end_datetimeNodatetime0should not be inferredNoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0CONDITION_OCCURRENCECONDITION_START_DATETIME0Yes0
49CONDITION_OCCURRENCEcondition_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
50CONDITION_OCCURRENCEcondition_status_concept_idNointeger0Presently, there is no designated vocabulary, domain, or class that represents condition status. The following concepts from SNOMED are recommended: Admitting diagnosis: 4203942 Final diagnosis: 4230359 (should also be used for discharge diagnosis Preliminary diagnosis: 4033240NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
51CONDITION_OCCURRENCEstop_reasonNovarchar(20)0The 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.NoNoNoYes100NoNoNoNo
52CONDITION_OCCURRENCEprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
53CONDITION_OCCURRENCEvisit_occurrence_idNointeger0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
54CONDITION_OCCURRENCEvisit_detail_idNointeger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
55CONDITION_OCCURRENCEcondition_source_valueNovarchar(50)0This 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. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.NoNoNoYes100NoNoYes0CONDITION_CONCEPT_IDNo
56CONDITION_OCCURRENCEcondition_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
57CONDITION_OCCURRENCEcondition_status_source_valueNovarchar(50)0This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.NoNoNoYes100NoNoYes0CONDITION_STATUS_CONCEPT_IDNo
58DRUG_EXPOSUREdrug_exposure_idYes0bigint0YesNoNoYes100NoNoNoNo
59DRUG_EXPOSUREperson_idYes0bigint0NoYesPERSONPERSON_IDNoYes100NoNoNoNo
60DRUG_EXPOSUREdrug_concept_idYes0integer0NoYesCONCEPTCONCEPT_IDDrugYesYes100Yes0NoNoNo
61DRUG_EXPOSUREdrug_exposure_start_dateYes0date0Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded.NoNoNoYes100NoNoNo'1950-01-01'DATEADD(dd,1,GETDATE())PERSONBIRTH_DATETIMEYes0
62DRUG_EXPOSUREdrug_exposure_start_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'DATEADD(dd,1,GETDATE())PERSONBIRTH_DATETIMEYes0
63DRUG_EXPOSUREdrug_exposure_end_dateYes0date0The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. This could be that the duration of DRUG_SUPPLY was reached (in which case DRUG_EXPOSURE_END_DATETIME = DRUG_EXPOSURE_START_DATETIME + DAYS_SUPPLY -1 day), or because the exposure was stopped (medication changed, medication discontinued, etc.) When the native data suggests a drug exposure has a days supply less than 0, drop the record as unknown if a person has received the drug or not (THEMIS issue #24). If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate (THEMIS issue #14). Depending on different sources, it could be a known or an inferred date and denotes the last day at which the patient was still exposed to Drug.NoNoNoYes100NoNoNo'1950-01-01'DATEADD(dd,1,GETDATE())DRUG_EXPOSUREDRUG_EXPOSURE_START_DATEYes0
64DRUG_EXPOSUREdrug_exposure_end_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'DATEADD(dd,1,GETDATE())DRUG_EXPOSUREDRUG_EXPOSURE_START_DATETIMEYes0
65DRUG_EXPOSUREverbatim_end_dateNodate0You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposureNoNoNoYes100NoNoNo'1950-01-01'DATEADD(dd,1,GETDATE())DRUG_EXPOSUREDRUG_EXPOSURE_START_DATEYes0
66DRUG_EXPOSUREdrug_type_concept_idYes0integer0NoYesCONCEPTCONCEPT_IDType ConceptYesYes100Yes0NoNoNo
67DRUG_EXPOSUREstop_reasonNovarchar(20)0 Reasons include regimen completed, changed, removed, etc.NoNoNoYes100NoNoNoNo
68DRUG_EXPOSURErefillsNointeger0The content of the refills field determines the current number of refills, not the number of remaining refills. For example, for a drug prescription with 2 refills, the content of this field for the 3 Drug Exposure events are null, 1 and 2.NoNoNoYes100NoNoNo012No
69DRUG_EXPOSUREquantityNofloat0NoNoNoYes100NoNoNo01095No
70DRUG_EXPOSUREdays_supplyNointeger0NoNoNoYes100NoNoNo0365No
71DRUG_EXPOSUREsigNovarchar(MAX)0(and printed on the container)NoNoNoYes100NoNoNoNo
72DRUG_EXPOSUREroute_concept_idNointeger0Route information can also be inferred from the Drug product itself by determining the Drug Form of the Concept, creating some partial overlap of the same type of information. Therefore, route information should be stored in DRUG_CONCEPT_ID (as a drug with corresponding Dose Form). The ROUTE_CONCEPT_ID could be used for storing more granular forms e.g. 'Intraventricular cardiac'.NoYesCONCEPTCONCEPT_IDRouteYesYes100Yes0NoNoNo
73DRUG_EXPOSURElot_numberNovarchar(50)0NoNoNoYes100NoNoNoNo
74DRUG_EXPOSUREprovider_idNointeger0NoYesPROVIDERPROVIDER_IDNoYes100NoNoNoNo
75DRUG_EXPOSUREvisit_occurrence_idNointeger0NoYesVISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
76DRUG_EXPOSUREvisit_detail_idNointeger0NoYesVISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
77DRUG_EXPOSUREdrug_source_valueNovarchar(50)0This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference.NoNoNoYes100NoNoYesDRUG_CONCEPT_IDNo
78DRUG_EXPOSUREdrug_source_concept_idNointeger0NoYesCONCEPTCONCEPT_IDNoYes100NoYesNoNo
79DRUG_EXPOSUREroute_source_valueNovarchar(50)0NoNoNoYes100NoNoYesROUTE_CONCEPT_IDNo
80DRUG_EXPOSUREdose_unit_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
81PROCEDURE_OCCURRENCEprocedure_occurrence_idYes0integer0Yes0NoNoYes100NoNoNoNo
82PROCEDURE_OCCURRENCEperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
83PROCEDURE_OCCURRENCEprocedure_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDProcedure0Yes0Yes100Yes0NoNoNo
84PROCEDURE_OCCURRENCEprocedure_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
85PROCEDURE_OCCURRENCEprocedure_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
86PROCEDURE_OCCURRENCEprocedure_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
87PROCEDURE_OCCURRENCEmodifier_concept_idNointeger0These concepts are typically distinguished by 'Modifier' concept classes (e.g., 'CPT4 Modifier' as part of the 'CPT4' vocabulary).NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
88PROCEDURE_OCCURRENCEquantityNointeger0If 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 (THEMIS issue #26).NoNoNoYes100NoNoNo10No
89PROCEDURE_OCCURRENCEprovider_idNointeger0NoNoPROVIDERPROVIDER_IDNoYes100NoNoNoNo
90PROCEDURE_OCCURRENCEvisit_occurrence_idNointeger0NoNoVISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
91PROCEDURE_OCCURRENCEvisit_detail_idNointeger0NoNoVISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
92PROCEDURE_OCCURRENCEprocedure_source_valueNovarchar(50)0This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference. Procedure source codes are typically ICD-9-Proc, CPT-4, HCPCS or OPCS-4 codes.NoNoNoYes100NoNoYes0PROCEDURE_CONCEPT_IDNo
93PROCEDURE_OCCURRENCEprocedure_source_concept_idNointeger0NoNoCONCEPTCONCEPT_IDNoYes100NoYes0NoNo
94PROCEDURE_OCCURRENCEmodifier_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0MODIFIER_CONCEPT_IDNo
95DEVICE_EXPOSUREdevice_exposure_idYes0bigint0Yes0NoNoYes100NoNoNoNo
96DEVICE_EXPOSUREperson_idYes0bigint0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
97DEVICE_EXPOSUREdevice_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDDevice0Yes0Yes100Yes0NoNoNo
98DEVICE_EXPOSUREdevice_exposure_start_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
99DEVICE_EXPOSUREdevice_exposure_start_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
100DEVICE_EXPOSUREdevice_exposure_end_dateNodate0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0DEVICE_EXPOSUREDEVICE_EXPOSURE_START_DATE0Yes0
101DEVICE_EXPOSUREdevice_exposure_end_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0DEVICE_EXPOSUREDEVICE_EXPOSURE_START_DATETIME0Yes0
102DEVICE_EXPOSUREdevice_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
103DEVICE_EXPOSUREunique_device_idNovarchar(50)0For 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.NoNoNoYes100NoNoNoNo
104DEVICE_EXPOSUREquantityNointeger0NoNoNoYes100NoNoNo10No
105DEVICE_EXPOSUREprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
106DEVICE_EXPOSUREvisit_occurrence_idNointeger0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
107DEVICE_EXPOSUREvisit_detail_idNointeger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
108DEVICE_EXPOSUREdevice_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0DEVICE_CONCEPT_IDNo
109DEVICE_EXPOSUREdevice_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
110MEASUREMENTmeasurement_idYes0integer0Yes0NoNoYes100NoNoNoNo
111MEASUREMENTperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
112MEASUREMENTmeasurement_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDMeasurement0Yes0Yes100Yes0NoNoNo
113MEASUREMENTmeasurement_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
114MEASUREMENTmeasurement_datetimeNodatetime0NoNoNoYes100NoNoNoNo
115MEASUREMENTmeasurement_timeNovarchar(10)0This is present for backwards compatibility and will be deprecated in an upcoming versionNoNoNoYes100NoNoNoNo
116MEASUREMENTmeasurement_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
117MEASUREMENToperator_concept_idNointeger0The 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 =.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 Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. 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 THEMIS issue #16NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
118MEASUREMENTvalue_as_numberNofloat0NoNoNoYes100NoNoNoNo
119MEASUREMENTvalue_as_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
120MEASUREMENTunit_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDUnit0Yes0Yes100Yes0NoNoNo
121MEASUREMENTrange_lowNofloat0Ranges have the same unit as the VALUE_AS_NUMBER.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. Ranges have the same unit as the VALUE_AS_NUMBER.NoNoNoYes100NoNoNoNo
122MEASUREMENTrange_highNofloat0Ranges have the same unit as the VALUE_AS_NUMBER.NoNoNoYes100NoNoNoNo
123MEASUREMENTprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
124MEASUREMENTvisit_occurrence_idNointeger0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
125MEASUREMENTvisit_detail_idNointeger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
126MEASUREMENTmeasurement_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0MEASUREMENT_CONCEPT_IDNo
127MEASUREMENTmeasurement_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
128MEASUREMENTunit_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0UNIT_CONCEPT_IDNo
129MEASUREMENTvalue_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
130VISIT_DETAILvisit_detail_idYes0integer0Yes0NoNoYes100NoNoNoNo
131VISIT_DETAILperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
132VISIT_DETAILvisit_detail_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDVisit0Yes0Yes100Yes0NoNoNo
133VISIT_DETAILvisit_detail_start_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
134VISIT_DETAILvisit_detail_start_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
135VISIT_DETAILvisit_detail_end_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0VISIT_OCCURRENCEVISIT_DETAIL_START_DATE0Yes0
136VISIT_DETAILvisit_detail_end_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0VISIT_OCCURRENCEVISIT_DETAIL_START_DATETIME0Yes0
137VISIT_DETAILvisit_detail_type_concept_idYes0Integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
138VISIT_DETAILprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
139VISIT_DETAILcare_site_idNointeger0NoYes0CARE_SITECARE_SITE_IDNoYes100NoNoNoNo
140VISIT_DETAILvisit_detail_source_valueNostring(50)0NoNoNoYes100NoNoYes0VISIT_DETAIL_CONCEPT_IDNo
141VISIT_DETAILvisit_detail_source_concept_idNoInteger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
142VISIT_DETAILadmitting_source_valueNoVarchar(50)0NoNoNoYes100NoNoYes0ADMITTING_SOURCE_CONCEPT_IDNo
143VISIT_DETAILadmitting_source_concept_idNoInteger0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0Yes0NoNo
144VISIT_DETAILdischarge_to_source_valueNoVarchar(50)0NoNoNoYes100NoNoYes0DISCHARGE_TO_CONCEPT_IDNo
145VISIT_DETAILdischarge_to_concept_idNoInteger0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
146VISIT_DETAILpreceding_visit_detail_idNoInteger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
147VISIT_DETAILvisit_detail_parent_idNoInteger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
148VISIT_DETAILvisit_occurrence_idYes0Integer0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
149NOTEnote_idYes0integer0Yes0NoNoYes100NoNoNoNo
150NOTEperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
151NOTEnote_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
152NOTEnote_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
153NOTEnote_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100NoNoNoNo
154NOTEnote_class_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
155NOTEnote_titleNovarchar(250)0NoNoNoYes100NoNoNoNo
156NOTEnote_textYes0varchar(MAX)0NoNoNoYes100NoNoNoNo
157NOTEencoding_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
158NOTElanguage_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
159NOTEprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
160NOTEvisit_occurrence_idNointeger0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
161NOTEvisit_detail_idNointeger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
162NOTEnote_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
163NOTE_NLPnote_nlp_idYes0integer0Yes0NoNoYes100NoNoNoNo
164NOTE_NLPnote_idYes0integer0NoNoNoYes100NoNoNoNo
165NOTE_NLPsection_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
166NOTE_NLPsnippetNovarchar(250)0NoNoNoYes100NoNoNoNo
167NOTE_NLPoffsetNovarchar(50)0NoNoNoYes100NoNoNoNo
168NOTE_NLPlexical_variantYes0varchar(250)0NoNoNoYes100NoNoNoNo
169NOTE_NLPnote_nlp_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
170NOTE_NLPnote_nlp_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
171NOTE_NLPnlp_systemNovarchar(250)0NoNoNoYes100NoNoNoNo
172NOTE_NLPnlp_dateYes0date0NoNoNoYes100NoNoNoNo
173NOTE_NLPnlp_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0No
174NOTE_NLPterm_existsNovarchar(1)0Term_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. NoNoNoYes100NoNoNoNo
175NOTE_NLPterm_temporalNovarchar(50)0Term_temporal is to indicate if a condition is <20>present<6E> or just in the <20>past<73>. The following would be past: History = true Concept_date = anything before the time of the reportNoNoNoYes100NoNoNoNo
176NOTE_NLPterm_modifiersNovarchar(2000)0For 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. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later.NoNoNoYes100NoNoNoNo
177OBSERVATIONobservation_idYes0integer0Yes0NoNoYes100NoNoNoNo
178OBSERVATIONperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
179OBSERVATIONobservation_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
180OBSERVATIONobservation_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
181OBSERVATIONobservation_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
182OBSERVATIONobservation_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
183OBSERVATIONvalue_as_numberNofloat0NoNoNoYes100NoNoNoNo
184OBSERVATIONvalue_as_stringNovarchar(60)0NoNoNoYes100NoNoNoNo
185OBSERVATIONvalue_as_concept_idNoInteger0Note 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, ICD9CM V17.5 concept_id 44828510 'Family history of asthma' has a 'Maps to' relationship to 4167217 'Family history of clinical finding' as well as a 'Maps to value' record to 317009 'Asthma'.NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
186OBSERVATIONqualifier_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
187OBSERVATIONunit_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDUnit0Yes0Yes100Yes0NoNoNo
188OBSERVATIONprovider_idNointeger0NoYes0PROVIDERPROVIDER_IDNoYes100NoNoNoNo
189OBSERVATIONvisit_occurrence_idNointeger0NoYes0VISIT_OCCURRENCEVISIT_OCCURRENCE_IDNoYes100NoNoNoNo
190OBSERVATIONvisit_detail_idNointeger0NoYes0VISIT_DETAILVISIT_DETAIL_IDNoYes100NoNoNoNo
191OBSERVATIONobservation_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0OBSERVATION_CONCEPT_IDNo
192OBSERVATIONobservation_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
193OBSERVATIONunit_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0UNIT_CONCEPT_IDNo
194OBSERVATIONqualifier_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0QUALIFIER_CONCEPT_IDNo
195SPECIMENspecimen_idYes0integer0Yes0NoNoYes100NoNoNoNo
196SPECIMENperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
197SPECIMENspecimen_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
198SPECIMENspecimen_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDType Concept0Yes0Yes100Yes0NoNoNo
199SPECIMENspecimen_dateYes0date0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
200SPECIMENspecimen_datetimeNodatetime0NoNoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
201SPECIMENquantityNofloat0NoNoNoYes100NoNoNo10No
202SPECIMENunit_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
203SPECIMENanatomic_site_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
204SPECIMENdisease_status_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100NoNoNoNo
205SPECIMENspecimen_source_idNovarchar(50)0NoNoNoYes100NoNoNoNo
206SPECIMENspecimen_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0SPECIMEN_CONCEPT_IDNo
207SPECIMENunit_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0UNIT_CONCEPT_IDNo
208SPECIMENanatomic_site_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0ANATOMIC_SITE_CONCEPT_IDNo
209SPECIMENdisease_status_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0DISEASE_STATUS_CONCEPT_IDNo
210FACT_RELATIONSHIPdomain_concept_id_1Yes0integer0NoYes0CONCEPTCONCEPT_IDNoYes100Yes0NoNoNo
211FACT_RELATIONSHIPfact_id_1Yes0integer0NoNoNoYes100NoNoNoNo
212FACT_RELATIONSHIPdomain_concept_id_2Yes0integer0NoYes0CONCEPTCONCEPT_IDNoYes100Yes0NoNoNo
213FACT_RELATIONSHIPfact_id_2Yes0integer0NoNoNoYes100NoNoNoNo
214FACT_RELATIONSHIPrelationship_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDNoYes100Yes0NoNoNo
215LOCATIONlocation_idYes0integer0Yes0NoNoYes100NoNoNoNo
216LOCATIONaddress_1Novarchar(50)0NoNoNoYes100NoNoNoNo
217LOCATIONaddress_2Novarchar(50)0NoNoNoYes100NoNoNoNo
218LOCATIONcityNovarchar(50)0NoNoNoYes100NoNoNoNo
219LOCATIONstateNovarchar(2)0NoNoNoYes100NoNoNoNo
220LOCATIONzipNovarchar(9)0Zip 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.NoNoNoYes100NoNoNoNo
221LOCATIONcountyNovarchar(20)0NoNoNoYes100NoNoNoNo
222LOCATIONlocation_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
223CARE_SITEcare_site_idYes0integer0Yes0NoNoYes100NoNoNoNo
224CARE_SITEcare_site_nameNovarchar(255)0NoNoNoYes100NoNoNoNo
225CARE_SITEplace_of_service_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
226CARE_SITElocation_idNointeger0NoNoNoYes100NoNoNoNo
227CARE_SITEcare_site_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
228CARE_SITEplace_of_service_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
229PROVIDERprovider_idYes0integer0Yes0NoNoYes100NoNoNoNo
230PROVIDERprovider_nameNovarchar(255)0NoNoNoYes100NoNoNoNo
231PROVIDERnpiNovarchar(20)0NoNoNoYes100NoNoNoNo
232PROVIDERdeaNovarchar(20)0NoNoNoYes100NoNoNoNo
233PROVIDERspecialty_concept_idNointeger0If a Provider has more than one Specialty, the main or most often exerted specialty should be recorded.NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
234PROVIDERcare_site_idNointeger0NoYes0CARE_SITECARE_SITE_IDNoYes100NoNoNoNo
235PROVIDERyear_of_birthNointeger0NoNoNoYes100NoNoNoNo
236PROVIDERgender_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDGender0Yes0Yes100Yes0NoNoNo
237PROVIDERprovider_source_valueNovarchar(50)0NoNoNoYes100NoNoNoNo
238PROVIDERspecialty_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0SPECIALTY_CONCEPT_IDNo
239PROVIDERspecialty_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoYes0NoNo
240PROVIDERgender_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0GENDER_CONCEPT_IDNo
241PROVIDERgender_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
242PAYER_PLAN_PERIODpayer_plan_period_idYes0integer0Yes0Yes0PERSONPERSON_IDNoYes100NoNoNoNo
243PAYER_PLAN_PERIODperson_idYes0integer0NoYes0PERSONPERSON_IDNoYes100NoNoNoNo
244PAYER_PLAN_PERIODpayer_plan_period_start_dateYes0date0NoNoNoYes100NoNoNoNo
245PAYER_PLAN_PERIODpayer_plan_period_end_dateYes0date0NoNoNoYes100NoNoNoPAYER_PLAN_PERIODPAYER_PLAN_PERIOD_START_DATE0No
246PAYER_PLAN_PERIODpayer_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
247PAYER_PLAN_PERIODpayer_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0PAYER_CONCEPT_IDNo
248PAYER_PLAN_PERIODpayer_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
249PAYER_PLAN_PERIODplan_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
250PAYER_PLAN_PERIODplan_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0PLAN_CONCEPT_IDNo
251PAYER_PLAN_PERIODplan_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
252PAYER_PLAN_PERIODsponsor_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
253PAYER_PLAN_PERIODsponsor_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0SPONSOR_CONCEPT_IDNo
254PAYER_PLAN_PERIODsponsor_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
255PAYER_PLAN_PERIODfamily_source_valueNovarchar(50)0NoNoNoYes100NoNoNo0No
256PAYER_PLAN_PERIODstop_reason_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
257PAYER_PLAN_PERIODstop_reason_source_valueNovarchar(50)0NoNoNoYes100NoNoYes0STOP_REASON_CONCEPT_IDNo
258PAYER_PLAN_PERIODstop_reason_source_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
259COSTcost_idYes0INTEGER0Yes0NoNoYes100NoNoNoNo
260COSTcost_event_idYes0INTEGER0NoNoNoYes100NoNoNoNo
261COSTcost_domain_idYes0VARCHAR(20)0NoYes0DOMAINDOMAIN_IDNoYes100NoNoNoNo
262COSTcost_type_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDYes0Yes100Yes0NoNoNo
263COSTcurrency_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
264COSTtotal_chargeNoFLOAT0NoNoNoYes100NoNoNoNo
265COSTtotal_costNoFLOAT0NoNoNoYes100NoNoNoNo
266COSTtotal_paidNoFLOAT0NoNoNoYes100NoNoNoNo
267COSTpaid_by_payerNoFLOAT0NoNoNoYes100NoNoNoNo
268COSTpaid_by_patientNoFLOAT0NoNoNoYes100NoNoNoNo
269COSTpaid_patient_copayNoFLOAT0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
270COSTpaid_patient_coinsuranceNoFLOAT0NoNoNoYes100NoNoNoNo
271COSTpaid_patient_deductibleNoFLOAT0NoNoNoYes100NoNoNoNo
272COSTpaid_by_primaryNoFLOAT0NoNoNoYes100NoNoNoNo
273COSTpaid_ingredient_costNoFLOAT0NoNoNoYes100NoNoNoNo
274COSTpaid_dispensing_feeNoFLOAT0NoNoNoYes100NoNoNoNo
275COSTpayer_plan_period_idNoINTEGER0NoNoNoYes100NoNoNoNo
276COSTamount_allowedNoFLOAT0NoNoNoYes100NoNoNoNo
277COSTrevenue_code_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
278COSTrevenue_code_source_valueNoVARCHAR(50)0Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system.NoNoNoYes100NoNoNoNo
279COSTdrg_concept_idNointeger0NoYes0CONCEPTCONCEPT_IDNoYes100NoNoNoNo
280COSTdrg_source_valueNoVARCHAR(3)0Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. NoNoNoYes100NoNoNoNo
281DRUG_ERAdrug_era_idYes0integer0Yes0NoYes100NoNoNoNo
282DRUG_ERAperson_idYes0integer0NoYes0PERSONPERSON_IDYes100NoNoNoNo
283DRUG_ERAdrug_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDDrug0Ingredient0Yes0Yes100Yes0NoNoNo
284DRUG_ERAdrug_era_start_dateYes0datetime0The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient. (NOT RIGHT)NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
285DRUG_ERAdrug_era_end_dateYes0datetime0The 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. (ARENT WE REQUIRING TO USE DRUG_EXPOSURE_END_DATE NOW????)NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0DRUG_ERADRUG_ERA_START_DATE0No
286DRUG_ERAdrug_exposure_countNointeger0NoNoYes100NoNoNo10No
287DRUG_ERAgap_daysNointeger0The 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.NoNoYes100NoNoNo00No
288DOSE_ERAdose_era_idYes0integer0Yes0NoYes100NoNoNoNo
289DOSE_ERAperson_idYes0integer0NoYes0PERSONPERSON_IDYes100NoNoNoNo
290DOSE_ERAdrug_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDDrug0Ingredient0Yes0Yes100Yes0NoNoNo
291DOSE_ERAunit_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDUnit0Yes0Yes100Yes0NoNoNo
292DOSE_ERAdose_valueYes0float0NoNoYes100NoNoNo00No
293DOSE_ERAdose_era_start_dateYes0datetime0NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
294DOSE_ERAdose_era_end_dateYes0datetime0NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
295CONDITION_ERAcondition_era_idYes0integer0Yes0NoYes100NoNoNoNo
296CONDITION_ERAperson_idYes0integer0NoNoPERSONPERSON_IDYes100NoNoNoNo
297CONDITION_ERAcondition_concept_idYes0integer0NoYes0CONCEPTCONCEPT_IDCondition0Yes0Yes100Yes0NoNoNo
298CONDITION_ERAcondition_era_start_dateYes0datetime0NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0Yes0
299CONDITION_ERAcondition_era_end_dateYes0datetime0NoNoYes100NoNoNo'1950-01-01'0DATEADD(dd,1,GETDATE())0PERSONBIRTH_DATETIME0No
300CONDITION_ERAcondition_occurrence_countNointeger0NoNoYes100NoNoNo10No