Added article on how to download the ddls.
This commit is contained in:
clairblacketer
parent
32d0cb9a0a
commit
ccea723163
|
|
@ -1,7 +1,7 @@
|
|||
Common Data Model v6.0
|
||||
=================
|
||||
|
||||
See full CDM specification file on our github [wiki](https://github.com/OHDSI/CommonDataModel/wiki) or in the [CDM V6.0 PDF](https://github.com/OHDSI/CommonDataModel/blob/master/OMOP_CDM_v6_0.pdf)
|
||||
See full CDM specifications on our [website](https://ohdsi.github.io/CommonDataModel/index.html).
|
||||
|
||||
|
||||
Release Notes for v6.0
|
||||
|
|
|
|||
139
docs/cdm531.html
139
docs/cdm531.html
|
|
@ -474,8 +474,8 @@ div.tocify {
|
|||
</div>
|
||||
|
||||
|
||||
<div id="cdm-v5.3.1" class="section level1">
|
||||
<h1><strong>CDM v5.3.1</strong></h1>
|
||||
<div id="omop-cdm-v5.3.1" class="section level1">
|
||||
<h1><strong>OMOP CDM v5.3.1</strong></h1>
|
||||
<p>Below is the specification document for the OMOP Common Data Model, v5.3.1. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
|
||||
<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
|
||||
<div id="clinical-data-tables" class="section level2">
|
||||
|
|
@ -748,7 +748,7 @@ location_id
|
|||
The location refers to the physical address of the person. This field should capture the last known location of the person.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> 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 deindentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location.
|
||||
Put the location_id from the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#location">LOCATION</a> 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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -1025,7 +1025,7 @@ CONCEPT
|
|||
<p><strong>User Guide</strong></p>
|
||||
<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should be represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrolment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
|
||||
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
<thead>
|
||||
<tr>
|
||||
|
|
@ -1208,7 +1208,7 @@ Type Concept
|
|||
<ul>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER follwed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
|
||||
|
|
@ -1696,7 +1696,7 @@ No
|
|||
preceding_visit_occurrence_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Use 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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”.
|
||||
|
|
@ -1962,7 +1962,7 @@ Use this field to understand the provenance of the visit detail record, or where
|
|||
Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Integer
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -2182,7 +2182,7 @@ Use this field to determine where the patient was discharged to after a visit de
|
|||
If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Integer
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -2205,13 +2205,13 @@ Visit
|
|||
preceding_visit_detail_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Use this field to find the visit detail that occured for the person prior to the given visit detail record. There could be a few days or a few years in between.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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”.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Integer
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -2239,7 +2239,7 @@ Use this field to find the visit detail that subsumes the given visit detail rec
|
|||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Integer
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -2267,7 +2267,7 @@ 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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Integer
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -2292,7 +2292,7 @@ VISIT_OCCURRENCE
|
|||
<p><strong>Table Description</strong></p>
|
||||
<p>This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.</p>
|
||||
<p><strong>User Guide</strong></p>
|
||||
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype defintions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
|
||||
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
|
|
@ -2638,7 +2638,7 @@ visit_occurrence_id
|
|||
The visit during which the condition occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -2778,7 +2778,7 @@ No
|
|||
<p><strong>User Guide</strong></p>
|
||||
<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs adminstered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
|
||||
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
<thead>
|
||||
<tr>
|
||||
|
|
@ -2823,7 +2823,7 @@ The unique key given to records of drug dispensings or administrations for a per
|
|||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -2849,7 +2849,7 @@ The PERSON_ID of the PERSON for whom the drug dispensing or administration is re
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -2956,7 +2956,7 @@ drug_exposure_end_date
|
|||
The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentation (20mg/mL) 200*5/20 = 50 days. SHOW EXAMPLES BY DOSE FORM
|
||||
If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
date
|
||||
|
|
@ -3117,7 +3117,7 @@ quantity
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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. 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 similiar to clinical drugs.
|
||||
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 <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
float
|
||||
|
|
@ -3253,7 +3253,7 @@ The Provider associated with drug record, e.g. the provider who wrote the presc
|
|||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -3281,7 +3281,7 @@ The Visit during which the drug was prescribed, administered or dispensed.
|
|||
To populate this field drug exposures must be explicitly initiated in the visit.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -3309,7 +3309,7 @@ The VISIT_DETAIL record during which the drug exposure occurred. For example, if
|
|||
Same rules apply as for the VISIT_OCCURRENCE_ID.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -3735,7 +3735,7 @@ visit_occurrence_id
|
|||
The visit during which the procedure occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -3919,7 +3919,7 @@ The unique key given to records a person’s exposure to a foreign physical obje
|
|||
Each instance of an exposure to a foreign object or device present in the source data should be assigned this unique key.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -3944,7 +3944,7 @@ person_id
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -4188,7 +4188,7 @@ The Provider associated with device record, e.g. the provider who wrote the pre
|
|||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -4216,7 +4216,7 @@ The Visit during which the device was prescribed or given.
|
|||
To populate this field device exposures must be explicitly initiated in the visit.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -4244,7 +4244,7 @@ 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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -4753,7 +4753,7 @@ visit_occurrence_id
|
|||
The visit during which the Measurement occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5016,7 +5016,7 @@ observation_concept_id
|
|||
The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 domans MUST go to the corresponding table.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5291,7 +5291,7 @@ visit_occurrence_id
|
|||
The visit during which the Observation occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5868,7 +5868,7 @@ note_class_concept_id
|
|||
A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=">Accepte Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
|
||||
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=">Accepted Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5976,7 +5976,7 @@ language_concept_id
|
|||
The language of the note.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Use Concepts that are decendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
|
||||
Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6149,6 +6149,7 @@ FK Domain
|
|||
note_nlp_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
A unique identifier for the NLP record.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6174,6 +6175,7 @@ No
|
|||
note_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the NOTE_ID for the NOTE record the NLP record is associated to.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6201,6 +6203,7 @@ section_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6225,6 +6228,7 @@ CONCEPT
|
|||
snippet
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
A small window of text surrounding the term
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6250,6 +6254,7 @@ No
|
|||
offset
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Character offset of the extracted term in the input note
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6275,6 +6280,7 @@ No
|
|||
lexical_variant
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Raw text extracted from the NLP tool.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6354,6 +6360,7 @@ nlp_system
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Name and version of the NLP system that extracted the term. Useful for data provenance.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(250)
|
||||
|
|
@ -6377,6 +6384,7 @@ No
|
|||
nlp_date
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date of the note processing.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6402,6 +6410,7 @@ No
|
|||
nlp_datetime
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date and time of the note processing.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6455,7 +6464,7 @@ term_temporal
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Term_temporal is to indicate if a condition is <EFBFBD>present<EFBFBD> or just in the <EFBFBD>past<EFBFBD>. The following would be past: History = true Concept_date = anything before the time of the report
|
||||
Term_temporal is to indicate if a condition is present or just in the past. The following would be past:<br><br> - History = true - Concept_date = anything before the time of the report
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -6481,7 +6490,7 @@ term_modifiers
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later.
|
||||
For the modifiers that are there, they would have to have these values:<br><br> - 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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(2000)
|
||||
|
|
@ -6547,6 +6556,7 @@ FK Domain
|
|||
specimen_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Unique identifier for each specimen.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6572,6 +6582,7 @@ No
|
|||
person_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The person from whom the specimen is collected.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6600,6 +6611,7 @@ specimen_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6626,6 +6638,7 @@ specimen_type_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=">Accepted Concepts</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6651,6 +6664,7 @@ Type Concept
|
|||
specimen_date
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date the specimen was collected.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6701,6 +6715,7 @@ No
|
|||
quantity
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The amount of specimen collected from the person.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6726,8 +6741,10 @@ No
|
|||
unit_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The unit for the quantity of the specimen.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6752,8 +6769,10 @@ CONCEPT
|
|||
anatomic_site_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the site on the body where the specimen is from.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Spec+Anatomic+Site&conceptClass=Body+Structure&page=4&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6804,6 +6823,7 @@ CONCEPT
|
|||
specimen_source_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the identifier for the specimen from the source system.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6856,6 +6876,7 @@ unit_source_value
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
This unit for the quantity of the specimen, as represented in the source.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -6881,6 +6902,7 @@ anatomic_site_source_value
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
This is the site on the body where the specimen was taken from, as represented in the source.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -7862,7 +7884,7 @@ No
|
|||
specialty_source_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is often zero as many sites use propietary codes to store physician speciality.
|
||||
This is often zero as many sites use proprietary codes to store physician speciality.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.
|
||||
|
|
@ -7917,7 +7939,7 @@ No
|
|||
gender_source_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is often zero as many sites use propietary codes to store provider gender.
|
||||
This is often zero as many sites use proprietary codes to store provider gender.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.
|
||||
|
|
@ -8497,7 +8519,7 @@ cost_id
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
INTEGER
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -8522,7 +8544,7 @@ cost_event_id
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
INTEGER
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -8547,7 +8569,7 @@ cost_domain_id
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
VARCHAR(20)
|
||||
varchar(20)
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
|
|
@ -8625,7 +8647,7 @@ total_charge
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8650,7 +8672,7 @@ total_cost
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8675,7 +8697,7 @@ total_paid
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8700,7 +8722,7 @@ paid_by_payer
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8725,7 +8747,7 @@ paid_by_patient
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8750,7 +8772,7 @@ paid_patient_copay
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8759,10 +8781,9 @@ No
|
|||
No
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
No
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
CONCEPT
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
</td>
|
||||
|
|
@ -8776,7 +8797,7 @@ paid_patient_coinsurance
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8801,7 +8822,7 @@ paid_patient_deductible
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8826,7 +8847,7 @@ paid_by_primary
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8851,7 +8872,7 @@ paid_ingredient_cost
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8876,7 +8897,7 @@ paid_dispensing_fee
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8901,7 +8922,7 @@ payer_plan_period_id
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
INTEGER
|
||||
integer
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8926,7 +8947,7 @@ amount_allowed
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
FLOAT
|
||||
float
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -8978,7 +8999,7 @@ Revenue codes are a method to charge for a class of procedures and conditions in
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
VARCHAR(50)
|
||||
varchar(50)
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -9030,7 +9051,7 @@ Diagnosis Related Groups are US codes used to classify hospital cases into one o
|
|||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
VARCHAR(3)
|
||||
varchar(3)
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
No
|
||||
|
|
@ -10404,7 +10425,7 @@ CONCEPT_CLASS
|
|||
standard_concept
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
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 allowables values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -12132,7 +12153,7 @@ CONCEPT
|
|||
box_size
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The number of units of Clinical Branded Drug or Quanitified Clinical or Branded Drug contained in a box as dispensed to the patient.
|
||||
The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
|
|||
Binary file not shown.
|
|
@ -474,8 +474,8 @@ div.tocify {
|
|||
</div>
|
||||
|
||||
|
||||
<div id="cdm-v6.0" class="section level1">
|
||||
<h1><strong>CDM v6.0</strong></h1>
|
||||
<div id="omop-cdm-v6.0" class="section level1">
|
||||
<h1><strong>OMOP CDM v6.0</strong></h1>
|
||||
<p>Below is the specification document for the OMOP Common Data Model, v6.0. Each table is represented with a high-level description and ETL conventions that should be followed. This is continued with a discussion of each field in each table, any conventions related to the field, and constraints that should be followed (like primary key, foreign key, etc). Should you have questions please feel free to visit the <a href="https://forums.ohdsi.org/">forums</a> or the <a href="https://github.com/ohdsi/CommonDataModel/issues">github issue</a> page.</p>
|
||||
<p>–after regeneration of DDLs link to csv of cdm link to pdf of cdm documentation link to forum on doc page</p>
|
||||
<div id="changes-in-v6.0" class="section level2">
|
||||
|
|
@ -785,7 +785,7 @@ location_id
|
|||
The location refers to the physical address of the person. This field should capture the last known location of the person. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 deindentified data, it is common that the precision of the location is reduced to prevent re-identification. This field should capture the last known location. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
|
||||
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. Any prior locations are captured in the <a href="https://ohdsi.github.io/CommonDataModel/cdm60.html#location_history">LOCATION_HISTORY</a> table.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
|
|
@ -1062,7 +1062,7 @@ CONCEPT
|
|||
<p><strong>User Guide</strong></p>
|
||||
<p>For each Person, one or more OBSERVATION_PERIOD records may be present, but they will not overlap or be back to back to each other. Events may exist outside all of the time spans of the OBSERVATION_PERIOD records for a patient, however, absence of an Event outside these time spans cannot be construed as evidence of absence of an Event. Incidence or prevalence rates should only be calculated for the time of active OBSERVATION_PERIOD records. When constructing cohorts, outside Events can be used for inclusion criteria definition, but without any guarantee for the performance of these criteria. Also, OBSERVATION_PERIOD records can be as short as a single day, greatly disturbing the denominator of any rate calculation as part of cohort characterizations. To avoid that, apply minimal observation time as a requirement for any cohort definition.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should be represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrolment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
|
||||
<p>Each Person needs to have at least one OBSERVATION_PERIOD record, which should represent time intervals with a high capture rate of Clinical Events. Some source data have very similar concepts, such as enrollment periods in insurance claims data. In other source data such as most EHR systems these time spans need to be inferred under a set of assumptions. It is the discretion of the ETL developer to define these assumptions. In many ETL solutions the start date of the first occurrence or the first high quality occurrence of a Clinical Event (Condition, Drug, Procedure, Device, Measurement, Visit) is defined as the start of the OBSERVATION_PERIOD record, and the end date of the last occurrence of last high quality occurrence of a Clinical Event, or the end of the database period becomes the end of the OBSERVATOIN_PERIOD for each Person. If a Person only has a single Clinical Event the OBSERVATION_PERIOD record can be as short as one day. Depending on these definitions it is possible that Clinical Events fall outside the time spans defined by OBSERVATION_PERIOD records. Family history or history of Clinical Events generally are not used to generate OBSERVATION_PERIOD records around the time they are referring to. Any two overlapping or adjacent OBSERVATION_PERIOD records have to be merged into one.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
<thead>
|
||||
<tr>
|
||||
|
|
@ -1245,7 +1245,7 @@ Type Concept
|
|||
<ul>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9201">Inpatient Visit</a>: Person visiting hospital, at a Care Site, in bed, for duration of more than one day, with physicians and other Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9203">Emergency Room Visit</a>: Person visiting dedicated healthcare institution for treating emergencies, at a Care Site, within one day, with physicians and Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER follwed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/262">Emergency Room and Inpatient Visit</a>: Person visiting ER followed by a subsequent Inpatient Visit, where Emergency department is part of hospital, and transition from the ER to other hospital departments is undefined</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/42898160">Non-hospital institution Visit</a>: Person visiting dedicated institution for reasons of poor health, at a Care Site, long-term or permanently, with no physician but possibly other Providers permanently available to deliver service around the clock</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/9202">Outpatient Visit</a>: Person visiting dedicated ambulatory healthcare institution, at a Care Site, within one day, without bed, with physicians or medical Providers delivering service during Visit</li>
|
||||
<li><a href="https://athena.ohdsi.org/search-terms/terms/581476">Home Visit</a>: Provider visiting Person, without a Care Site, within one day, delivering service</li>
|
||||
|
|
@ -1733,7 +1733,7 @@ No
|
|||
preceding_visit_occurrence_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Use 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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”.
|
||||
|
|
@ -2242,7 +2242,7 @@ Visit
|
|||
preceding_visit_detail_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Use this field to find the visit detail that occured for the person prior to the given visit detail record. There could be a few days or a few years in between.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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”.
|
||||
|
|
@ -2329,7 +2329,7 @@ VISIT_OCCURRENCE
|
|||
<p><strong>Table Description</strong></p>
|
||||
<p>This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.</p>
|
||||
<p><strong>User Guide</strong></p>
|
||||
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype defintions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
|
||||
<p>Conditions are defined by Concepts from the Condition domain, which form a complex hierarchy. As a result, the same Person with the same disease may have multiple Condition records, which belong to the same hierarchical family. Most Condition records are mapped from diagnostic codes, but recorded signs, symptoms and summary descriptions also contribute to this table. Rule out diagnoses should not be recorded in this table, but in reality their negating nature is not always captured in the source data, and other precautions must be taken when when identifying Persons who should suffer from the recorded Condition. Record all conditions as they exist in the source data. Any decisions about diagnosis/phenotype definitions would be done through cohort specifications. These cohorts can be housed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period">COHORT</a> table. Conditions span a time interval from start to end, but are typically recorded as single snapshot records with no end date. The reason is twofold: (i) At the time of the recording the duration is not known and later not recorded, and (ii) the Persons typically cease interacting with the healthcare system when they feel better, which leads to incomplete capture of resolved Conditions. The <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#condition_era">CONDITION_ERA</a> table addresses this issue. Family history and past diagnoses (‘history of’) are not recorded in this table. Instead, they are listed in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table. Codes written in the process of establishing the diagnosis, such as ‘question of’ of and ‘rule out’, should not represented here. Instead, they should be recorded in the <a href="https://ohdsi.github.io/CommonDataModel/cdm531.html#observation">OBSERVATION</a> table, if they are used for analyses. However, this information is not always available.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Source codes and source text fields mapped to Standard Concepts of the Condition Domain have to be recorded here.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
|
|
@ -2674,7 +2674,7 @@ visit_occurrence_id
|
|||
The visit during which the condition occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
|
|
@ -2814,7 +2814,7 @@ No
|
|||
<p><strong>User Guide</strong></p>
|
||||
<p>The purpose of records in this table is to indicate an exposure to a certain drug as best as possible. In this context a drug is defined as an active ingredient. Drug Exposures are defined by Concepts from the Drug domain, which form a complex hierarchy. As a result, one DRUG_SOURCE_CONCEPT_ID may map to multiple standard concept ids if it is a combination product. Records in this table represent prescriptions written, prescriptions dispensed, and drugs administered by a provider to name a few. The DRUG_TYPE_CONCEPT_ID can be used to find and filter on these types. This table includes additional information about the drug products, the quantity given, and route of administration.</p>
|
||||
<p><strong>ETL Conventions</strong></p>
|
||||
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs adminstered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
|
||||
<p>Information about quantity and dose is provided in a variety of different ways and it is important for the ETL to provide as much information as possible from the data. Depending on the provenance of the data fields may be captured differently i.e. quantity for drugs administered may have a separate meaning from quantity for prescriptions dispensed. If a patient has multiple records on the same day for the same drug or procedures the ETL should not de-dupe them unless there is probable reason to believe the item is a true data duplicate. Take note on how to handle refills for prescriptions written.</p>
|
||||
<table class="table table-condensed table-hover" style="font-size: 13px; margin-left: auto; margin-right: auto;">
|
||||
<thead>
|
||||
<tr>
|
||||
|
|
@ -2992,7 +2992,7 @@ drug_exposure_end_date
|
|||
The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If this information is not explicitly available in the data, infer the end date using the following methods:/n/n 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) /concentation (20mg/mL) 200*5/20 = 50 days. SHOW EXAMPLES BY DOSE FORM
|
||||
If this information is not explicitly available in the data, infer the end date using the following methods:/n/n 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. <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">Examples by dose form</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
date
|
||||
|
|
@ -3153,7 +3153,7 @@ quantity
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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. 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 similiar to clinical drugs.
|
||||
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 <a href="https://ohdsi.github.io/CommonDataModel/drug_dose.html">how to calculate drug dose</a> for more information.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
float
|
||||
|
|
@ -3771,7 +3771,7 @@ visit_occurrence_id
|
|||
The visit during which the procedure occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the PROCEDURE_OCCURRENCE record.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
|
|
@ -4789,7 +4789,7 @@ visit_occurrence_id
|
|||
The visit during which the Measurement occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
|
|
@ -5052,7 +5052,7 @@ observation_concept_id
|
|||
The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 domans MUST go to the corresponding table.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5327,7 +5327,7 @@ visit_occurrence_id
|
|||
The visit during which the Observation occurred.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 explictly 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.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
bigint
|
||||
|
|
@ -5756,7 +5756,7 @@ note_class_concept_id
|
|||
A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=">Accepte Concepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
|
||||
Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=">AcceptedConcepts</a>. This Concept can alternatively be represented by concepts with the relationship ‘Kind of (LOINC)’ to <a href="https://athena.ohdsi.org/search-terms/terms/706391">706391</a> (Note).
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -5864,7 +5864,7 @@ language_concept_id
|
|||
The language of the note.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Use Concepts that are decendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
|
||||
Use Concepts that are descendants of the concept <a href="https://athena.ohdsi.org/search-terms/terms/4182347">4182347</a> (World Languages).
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6037,6 +6037,7 @@ FK Domain
|
|||
note_nlp_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
A unique identifier for the NLP record.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6062,6 +6063,7 @@ No
|
|||
note_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the NOTE_ID for the NOTE record the NLP record is associated to.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6089,6 +6091,7 @@ section_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 <a href="https://athena.ohdsi.org/search-terms/terms/45875957">45875957</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6113,6 +6116,7 @@ CONCEPT
|
|||
snippet
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
A small window of text surrounding the term
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6138,6 +6142,7 @@ No
|
|||
offset
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Character offset of the extracted term in the input note
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6163,6 +6168,7 @@ No
|
|||
lexical_variant
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Raw text extracted from the NLP tool.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6242,6 +6248,7 @@ nlp_system
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Name and version of the NLP system that extracted the term. Useful for data provenance.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(250)
|
||||
|
|
@ -6265,6 +6272,7 @@ No
|
|||
nlp_date
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date of the note processing.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6290,6 +6298,7 @@ No
|
|||
nlp_datetime
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date and time of the note processing.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6343,7 +6352,7 @@ term_temporal
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Term_temporal is to indicate if a condition ispresent or just in the past. The following would be past: History = true Concept_date = anything before the time of the report
|
||||
Term_temporal is to indicate if a condition is present or just in the past. The following would be past:<br><br> - History = true - Concept_date = anything before the time of the report
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -6369,7 +6378,7 @@ term_modifiers
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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. A list of allowable modifiers (e.g., signature for medications) and their possible values will be standardized later.
|
||||
For the modifiers that are there, they would have to have these values:<br><br> - 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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(2000)
|
||||
|
|
@ -6435,6 +6444,7 @@ FK Domain
|
|||
specimen_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
Unique identifier for each specimen.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6460,6 +6470,7 @@ No
|
|||
person_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The person from whom the specimen is collected.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6488,6 +6499,7 @@ specimen_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Specimen&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6514,6 +6526,7 @@ specimen_type_concept_id
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Put the source of the specimen record, as in an EHR system. <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=">Accepted Concepts</a>.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6539,6 +6552,7 @@ Type Concept
|
|||
specimen_date
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The date the specimen was collected.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6589,6 +6603,7 @@ No
|
|||
quantity
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The amount of specimen collected from the person.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6614,8 +6629,10 @@ No
|
|||
unit_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The unit for the quantity of the specimen.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
Map the UNIT_SOURCE_VALUE to a Standard Concept in the Unit domain. <a href="https://athena.ohdsi.org/search-terms/terms?domain=Unit&standardConcept=Standard&page=1&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6640,8 +6657,10 @@ CONCEPT
|
|||
anatomic_site_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the site on the body where the specimen is from.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
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 <a href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Spec+Anatomic+Site&conceptClass=Body+Structure&page=4&pageSize=15&query=">Accepted Concepts</a>
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
integer
|
||||
|
|
@ -6692,6 +6711,7 @@ CONCEPT
|
|||
specimen_source_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is the identifier for the specimen from the source system.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -6744,6 +6764,7 @@ unit_source_value
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
This unit for the quantity of the specimen, as represented in the source.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -6769,6 +6790,7 @@ anatomic_site_source_value
|
|||
<td style="text-align:left;width: 3in; ">
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
This is the site on the body where the specimen was taken from, as represented in the source.
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
varchar(50)
|
||||
|
|
@ -8686,7 +8708,7 @@ No
|
|||
specialty_source_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is often zero as many sites use propietary codes to store physician speciality.
|
||||
This is often zero as many sites use proprietary codes to store physician speciality.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
|
||||
|
|
@ -8741,7 +8763,7 @@ No
|
|||
gender_source_concept_id
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
This is often zero as many sites use propietary codes to store provider gender.
|
||||
This is often zero as many sites use proprietary codes to store provider gender.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here. If not available, set to 0.
|
||||
|
|
@ -9690,10 +9712,9 @@ No
|
|||
No
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
Yes
|
||||
No
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
CONCEPT
|
||||
</td>
|
||||
<td style="text-align:left;width: 1in; ">
|
||||
</td>
|
||||
|
|
@ -11335,7 +11356,7 @@ CONCEPT_CLASS
|
|||
standard_concept
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
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 allowables values are ‘S’ (Standard Concept) and ‘C’ (Classification Concept), otherwise the content is NULL.
|
||||
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.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
@ -13058,7 +13079,7 @@ CONCEPT
|
|||
box_size
|
||||
</td>
|
||||
<td style="text-align:left;width: 3in; ">
|
||||
The number of units of Clinical Branded Drug or Quanitified Clinical or Branded Drug contained in a box as dispensed to the patient.
|
||||
The number of units of Clinical Branded Drug or Quantified Clinical or Branded Drug contained in a box as dispensed to the patient.
|
||||
</td>
|
||||
<td style="text-align:left;width: 4in; ">
|
||||
</td>
|
||||
|
|
|
|||
|
|
@ -475,7 +475,8 @@ div.tocify {
|
|||
</div>
|
||||
|
||||
|
||||
<p>This article is currently under development. Please check back later for updates.</p>
|
||||
<p>All code for the ddls, constraints and indices are available on our <a href="https://github.com/OHDSI/CommonDataModel">github</a>. Each version of the Common Data Model is denoted by a <a href="https://github.com/OHDSI/CommonDataModel/tags">release</a>. The OHDSI community supports the database management systems (dbms) Sql Server, Postgresql, Oracle, Redshift, Parallel Data Warehouse, BigQuery, Impala, and Netezza. Included in each release is a folder for each dbms. After downloading, choose the folder for your specific system and you will see all necessary files. For example the Sql Server folder has the ddl, primary key constraints, indices, and foreign key constraints. In contrast, the redshift folder only has a ddl.</p>
|
||||
<p>These sql scripts have been fully tested on Oracle, Sql Server, and Postgresql and the rest are generated using the <a href="https://ohdsi.github.io/SqlRender/">SqlRender package</a>. If run into any problems please let us know by creating an issue on our github.</p>
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue