Merge pull request #685 from OHDSI/olympians_week4

Olympians week4
This commit is contained in:
clairblacketer 2024-04-29 09:55:49 -04:00 committed by GitHub
commit e2370317da
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
7 changed files with 211 additions and 152 deletions

View File

@ -1335,7 +1335,10 @@ enrollment file, EHR healthcare encounters, or other sources.
Choose the observation_period_type_concept_id that best represents how
the period was determined. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -1722,7 +1725,10 @@ where the record comes from.
Populate this field based on the provenance of the visit record, as in
whether it came from an EHR record or billing claim. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
Integer
@ -1880,10 +1886,11 @@ concept is part of the visit domain and can indicate if a patient was
admitted to the hospital from a long-term care facility, for example.
</td>
<td style="text-align:left;">
If available, map the admitted_from_source_value to a standard concept
in the visit domain. <a
If available, map the admitting_source_value to a standard concept in
the visit domain. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. If a person was admitted from home or was self-referred,
set this to 0.
</td>
<td style="text-align:left;">
integer
@ -2332,7 +2339,10 @@ or where the record comes from.
Populate this field based on the provenance of the visit detail record,
as in whether it came from an EHR record or billing claim. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -2517,10 +2527,11 @@ concept is part of the visit domain and can indicate if a patient was
admitted to the hospital from a long-term care facility, for example.
</td>
<td style="text-align:left;">
If available, map the admitted_from_source_value to a standard concept
in the visit domain. <a
If available, map the admitting_source_value to a standard concept in
the visit domain. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. If a person was admitted from home or was self-referred,
set this to 0.
</td>
<td style="text-align:left;">
Integer
@ -2997,7 +3008,10 @@ claim, registry, or other sources.
Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance
of the record. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -3644,7 +3658,10 @@ Choose the drug_type_concept_id that best represents the provenance of
the record, for example whether it came from a record of a prescription
written or physician administered drug. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -4341,7 +4358,10 @@ of the record, for example whether it came from an EHR record or billing
claim. If a procedure is recorded as an EHR encounter, the
PROCEDURE_TYPE_CONCEPT would be EHR encounter record. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -4885,7 +4905,10 @@ Choose the drug_type_concept_id that best represents the provenance of
the record, for example whether it came from a record of a prescription
written or physician administered drug. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -5387,7 +5410,10 @@ Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the
provenance of the record, for example whether it came from an EHR record
or billing claim. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -6068,7 +6094,10 @@ Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the
provenance of the record, for example whether it came from an EHR record
or billing claim. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -6603,7 +6632,8 @@ death_datetime
<td style="text-align:left;">
</td>
<td style="text-align:left;">
If not available set time to midnight (00:00:00)
If you have date and time of death, populate death_datetime, otherwise
leave NULL
</td>
<td style="text-align:left;">
datetime
@ -6633,9 +6663,12 @@ information from a government file so do not assume the Death Type is
the same as the Visit Type, etc.
</td>
<td style="text-align:left;">
Use the type concept that be reflects the source of the death record. <a
Use the type concept that reflects the source of the death record. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -6928,7 +6961,10 @@ The provenance of the note. Most likely this will be EHR.
<td style="text-align:left;">
Put the source system of the note, as in EHR record. <a
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -7772,7 +7808,10 @@ specimen_type_concept_id
<td style="text-align:left;">
Put the source of the specimen record, as in an EHR system. <a
href="https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&amp;domain=Type+Concept&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
href="https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT">vocabulary
wiki</a>.
</td>
<td style="text-align:left;">
integer
@ -8861,11 +8900,12 @@ No
provider_name
</td>
<td style="text-align:left;">
This field contains information that describes a healthcare provider.
</td>
<td style="text-align:left;">
This field is not necessary as it is not necessary to have the actual
identity of the Provider. Rather, the idea is to uniquely and
anonymously identify providers of care across the database.
This field is not required for identifying the Providers actual
identity. Instead, its purpose is to uniquely and/or anonymously
identify providers of care across the database.
</td>
<td style="text-align:left;">
varchar(255)
@ -9099,15 +9139,18 @@ No
specialty_source_value
</td>
<td style="text-align:left;">
This is the kind of provider or specialty as it appears in the source
data. This includes physician specialties such as internal medicine,
emergency medicine, etc. and allied health professionals such as nurses,
midwives, and pharmacists.
This refers to the specific type of healthcare provider or field of
expertise listed in the source data, encompassing physician specialties
like internal medicine, emergency medicine, etc., as well as allied
health professionals such as nurses, midwives, and pharmacists. It
covers medical specialties like surgery, internal medicine, and
radiology, while other services like prosthetics, acupuncture, and
physical therapy fall under the domain of “Service.”
</td>
<td style="text-align:left;">
Put the kind of provider as it appears in the source data. This field is
up to the discretion of the ETL-er as to whether this should be the
coded value from the source or the text description of the lookup value.
The type of provider and their specialty should be entered as they
appear in the source data. The decision to use either the coded value or
the text description is left to the discretion of the ETL-er.
</td>
<td style="text-align:left;">
varchar(50)
@ -9392,13 +9435,13 @@ This field represents the organization who reimburses the provider which
administers care to the Person.
</td>
<td style="text-align:left;">
Map the Payer directly to a standard CONCEPT_ID. If one does not exists
please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same payer, though the
name of the Payer is not necessary. <a
href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Map the payer directly to a standard CONCEPT_ID with the domain_id of
Payer (<a
href="https://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -9481,13 +9524,13 @@ This field represents the specific health benefit Plan the Person is
enrolled in.
</td>
<td style="text-align:left;">
Map the Plan directly to a standard CONCEPT_ID. If one does not exists
please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same health benefit
Plan though the name of the Plan is not necessary. <a
Map the Plan directly to a standard CONCEPT_ID in the Plan vocabulary
(<a
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -9572,13 +9615,13 @@ This includes self-insured, small group health plan and large group
health plan.
</td>
<td style="text-align:left;">
Map the sponsor directly to a standard CONCEPT_ID. If one does not
exists please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same sponsor though
the name of the sponsor is not necessary. <a
href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
Sponsor (<a
href="https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -9689,11 +9732,12 @@ stop_reason_concept_id
This field represents the reason the Person left the Plan, if known.
</td>
<td style="text-align:left;">
Map the stop reason directly to a standard CONCEPT_ID. If one does not
exists please contact the vocabulary team. There is no global controlled
vocabulary available for this information. <a
Map the stop reason directly to a standard CONCEPT_ID with a domain of
Plan Stop Reason (<a
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>). If one does not exist visit the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">Custom
Concepts</a> pate for more information.
</td>
<td style="text-align:left;">
integer

View File

@ -2003,7 +2003,8 @@ admitted to the hospital from a long-term care facility, for example.
If available, map the admitted_from_source_value to a standard concept
in the visit domain. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>. If a person was admitted from home, set this to 0.
Concepts</a>. If a person was admitted from home or was self-referred,
set this to 0.
</td>
<td style="text-align:left;">
integer
@ -2622,7 +2623,8 @@ admitted to the hospital from a long-term care facility, for example.
If available, map the admitted_from_source_value to a standard concept
in the visit domain. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Visit&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>. If the person was admitted from home, set this to 0.
Concepts</a>. If a person was admitted from home or was self-referred,
set this to 0.
</td>
<td style="text-align:left;">
Integer
@ -7132,7 +7134,8 @@ death_datetime
<td style="text-align:left;">
</td>
<td style="text-align:left;">
If not available set time to midnight (00:00:00)
If you have date and time of death, populate death_datetime, otherwise
leave NULL
</td>
<td style="text-align:left;">
datetime
@ -7162,7 +7165,7 @@ information from a government file so do not assume the Death Type is
the same as the Visit Type, etc.
</td>
<td style="text-align:left;">
Use the type concept that be reflects the source of the death record. <a
Use the type concept that reflects the source of the death record. <a
href="https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>. A more detailed explanation of each Type Concept can be
found on the <a
@ -9570,11 +9573,12 @@ No
provider_name
</td>
<td style="text-align:left;">
This field contains information that describes a healthcare provider.
</td>
<td style="text-align:left;">
This field is not necessary as it is not necessary to have the actual
identity of the Provider. Rather, the idea is to uniquely and
anonymously identify providers of care across the database.
This field is not required for identifying the Providers actual
identity. Instead, its purpose is to uniquely and/or anonymously
identify providers of care across the database.
</td>
<td style="text-align:left;">
varchar(255)
@ -9808,15 +9812,18 @@ No
specialty_source_value
</td>
<td style="text-align:left;">
This is the kind of provider or specialty as it appears in the source
data. This includes physician specialties such as internal medicine,
emergency medicine, etc. and allied health professionals such as nurses,
midwives, and pharmacists.
This refers to the specific type of healthcare provider or field of
expertise listed in the source data, encompassing physician specialties
like internal medicine, emergency medicine, etc., as well as allied
health professionals such as nurses, midwives, and pharmacists. It
covers medical specialties like surgery, internal medicine, and
radiology, while other services like prosthetics, acupuncture, and
physical therapy fall under the domain of “Service.”
</td>
<td style="text-align:left;">
Put the kind of provider as it appears in the source data. This field is
up to the discretion of the ETL-er as to whether this should be the
coded value from the source or the text description of the lookup value.
The type of provider and their specialty should be entered as they
appear in the source data. The decision to use either the coded value or
the text description is left to the discretion of the ETL-er.
</td>
<td style="text-align:left;">
varchar(50)
@ -10101,13 +10108,13 @@ This field represents the organization who reimburses the provider which
administers care to the Person.
</td>
<td style="text-align:left;">
Map the Payer directly to a standard CONCEPT_ID. If one does not exists
please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same payer, though the
name of the Payer is not necessary. <a
href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Map the payer directly to a standard CONCEPT_ID with the domain_id of
Payer (<a
href="https://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -10190,13 +10197,13 @@ This field represents the specific health benefit Plan the Person is
enrolled in.
</td>
<td style="text-align:left;">
Map the Plan directly to a standard CONCEPT_ID. If one does not exists
please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same health benefit
Plan though the name of the Plan is not necessary. <a
Map the Plan directly to a standard CONCEPT_ID in the Plan vocabulary
(<a
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -10281,13 +10288,13 @@ This includes self-insured, small group health plan and large group
health plan.
</td>
<td style="text-align:left;">
Map the sponsor directly to a standard CONCEPT_ID. If one does not
exists please contact the vocabulary team. There is no global controlled
vocabulary available for this information. The point is to stratify on
this information and identify if Persons have the same sponsor though
the name of the sponsor is not necessary. <a
href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
Sponsor (<a
href="https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>). This vocabulary is not exhaustive so if there is a value
missing, please see the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
concepts</a> page.
</td>
<td style="text-align:left;">
integer
@ -10398,11 +10405,12 @@ stop_reason_concept_id
This field represents the reason the Person left the Plan, if known.
</td>
<td style="text-align:left;">
Map the stop reason directly to a standard CONCEPT_ID. If one does not
exists please contact the vocabulary team. There is no global controlled
vocabulary available for this information. <a
Map the stop reason directly to a standard CONCEPT_ID with a domain of
Plan Stop Reason (<a
href="http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
Concepts</a>.
Concepts</a>). If one does not exist visit the <a
href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">Custom
Concepts</a> pate for more information.
</td>
<td style="text-align:left;">
integer

View File

@ -526,34 +526,40 @@ to represent your data in the common data model. Members are usually
very responsive!</p>
<p><strong>3. Are any tables or fields optional?</strong></p>
<p>It is expected that all tables will be present in a CDM though it is
not a requirement that they are all populated. The two mandatory tables
are:</p>
not a requirement that they are all populated. The three mandatory
tables are:</p>
<ul>
<li><a
href="https://github.com/OHDSI/CommonDataModel/wiki/person">Person</a>:
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#person">Person</a>:
Contains records that uniquely identify each patient in the source data
who is at-risk to have clinical observations recorded within the source
systems.</li>
<li><a
href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a>:
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period">Observation_period</a>:
Contains records which uniquely define the spans of time for which a
Person is at-risk to have clinical events recorded within the source
systems.</li>
<li><a
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#cdm_source">CDM_Source</a>:
Contains information on the CDM instance including the vocabulary
version used, the date the native data were released and the date the
CDM was released.</li>
</ul>
<p>It is then up to you which tables to populate, though the core event
tables are generally agreed upon to be <a
href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE">Condition_occurrence</a>,
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURRENCE">Condition_occurrence</a>,
<a
href="https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE">Procedure_occurrence</a>,
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#PROCEDURE_OCCURRENCE">Procedure_occurrence</a>,
<a
href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a>,
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE">Drug_exposure</a>,
<a
href="https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT">Measurement</a>,
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#MEASUREMENT">Measurement</a>,
and <a
href="https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION">Observation</a>.
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#OBSERVATION">Observation</a>.
Each table has certain required fields, a full list of which can be
found on the Common Data Model <a
href="https://github.com/OHDSI/CommonDataModel/wiki/">wiki page</a>.</p>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#">wiki
page</a>.</p>
<p><strong>4. Does the data model include any derived information? Which
tables or values are derived?</strong></p>
<p>The common data model stores verbatim data from the source across
@ -561,15 +567,15 @@ various clinical domains, such as records for conditions, drugs,
procedures, and measurements. In addition, to assist the analyst, the
common data model also provides some derived tables, based on commonly
used analytic procedures. For example, the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA">Condition_era</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_ERA">Condition_era</a>
table is derived from the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURENCE">Condition_occurrence</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURENCE">Condition_occurrence</a>
table and both the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA">Drug_era</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_ERA">Drug_era</a>
and <a
href="https://github.com/OHDSI/CommonDataModel/wiki/DOSE_ERA">Dose_era</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DOSE_ERA">Dose_era</a>
tables are derived from the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE">Drug_exposure</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE">Drug_exposure</a>
table. An era is defined as a span of time when a patient is assumed to
have a given condition or exposure to a particular active ingredient.
Members of the community have written code to create these tables and it
@ -630,7 +636,7 @@ further.</p>
Persons information is valid?</strong></p>
<p>The OMOP Common Data Model uses something called observation periods
(stored in the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/observation_period">Observation_period</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period">Observation_period</a>
table) as a way to define the time span during which a patient is
at-risk to have a clinical event recorded. In administrative claims
databases, for example, these observation periods are often analogous to
@ -638,7 +644,7 @@ the notion of enrollment.</p>
<p><strong>10. How does the model capture start and stop dates for
insurance coverage? What if a persons coverage changes?</strong></p>
<p>The <a
href="https://github.com/OHDSI/CommonDataModel/wiki/payer_plan_period">Payer_plan_period</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period">Payer_plan_period</a>
table captures details of the period of time that a Person is
continuously enrolled under a specific health Plan benefit structure
from a given Payer. Payer plan periods, as opposed to observation
@ -664,7 +670,7 @@ supported, the mappings have been done for you. The full list is
available from the open-source <a
href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a> tool under
the download tab (see below). You can choose to download the ten <a
href="https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Vocabularies">vocabulary
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#Standardized-Vocabularies">vocabulary
tables</a> from there as well you will need a copy in your environment
if you plan on building a CDM.</p>
<p><img src="images/Athena_download_box.png" /></p>
@ -677,7 +683,7 @@ searching.</p>
<p><strong>13. If I want to apply the mappings myself, can I do so? Are
they transparent to all users?</strong></p>
<p>Yes, all mappings are available in the <a
href="https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP">Concept_relationship</a>
href="https://ohdsi.github.io/CommonDataModel/cdm54.html#CONCEPT_RELATIONSHIP">Concept_relationship</a>
table (which can be downloaded from <a
href="http://athena.ohdsi.org/search-terms/terms">ATHENA</a>). Each
value in a supported source terminology is assigned a Concept_id (which

File diff suppressed because one or more lines are too long

View File

@ -21,7 +21,7 @@ observation_period,observation_period_id,Yes,integer,A Person can have multiple
observation_period,person_id,Yes,integer,The Person ID of the PERSON record for which the Observation Period is recorded.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
observation_period,observation_period_start_date,Yes,date,Use this date to determine the start date of the Observation Period.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period).",No,No,NA,NA,NA,NA,NA
observation_period,observation_period_end_date,Yes,date,Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded.,"It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer.",No,No,NA,NA,NA,NA,NA
observation_period,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
observation_period,period_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources.",Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_occurrence,visit_occurrence_id,Yes,integer,Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit.,This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.,Yes,No,NA,NA,NA,NA,NA
visit_occurrence,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
visit_occurrence,visit_concept_id,Yes,integer,"This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain.","Populate this field based on the kind of visit that took place for the person. For example this could be ""Inpatient Visit"", ""Outpatient Visit"", ""Ambulatory Visit"", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
@ -35,12 +35,12 @@ visit_occurrence,visit_end_date,Yes,date,For inpatient visits the end date is ty
For Inpatient Visits ongoing at the date of ETL, put date of processing the data into visit_end_datetime and visit_type_concept_id with 32220 ""Still patient"" to identify the visit as incomplete.
- All other Visits: visit_end_datetime = visit_start_datetime. If this is a one-day visit the end date should match the start date.",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_end_datetime,No,datetime,NA,"If no time is given for the end date of a visit, set it to midnight (00:00:0000).",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_type_concept_id,Yes,Integer,"Use this field to understand the provenance of the visit record, or where the record comes from.","Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_occurrence,visit_type_concept_id,Yes,Integer,"Use this field to understand the provenance of the visit record, or where the record comes from.","Populate this field based on the provenance of the visit record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_occurrence,provider_id,No,integer,"There will only be one provider per visit record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). If there are multiple providers associated with a visit in the source, this can be reflected in the event tables (CONDITION_OCCURRENCE, PROCEDURE_OCCURRENCE, etc.) or in the VISIT_DETAIL table.","If there are multiple providers associated with a visit, you will need to choose which one to put here. The additional providers can be stored in the [VISIT_DETAIL](https://ohdsi.github.io/CommonDataModel/cdm531.html#visit_detail) table.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
visit_occurrence,care_site_id,No,integer,This field provides information about the Care Site where the Visit took place.,There should only be one Care Site associated with a Visit.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
visit_occurrence,visit_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_source_concept_id,No,integer,NA,If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
visit_occurrence,admitting_source_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,admitting_source_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitting_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,admitting_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,NA,NA,NA,NA,NA
visit_occurrence,discharge_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the discharge_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,discharge_to_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,NA,NA,NA,NA,NA
@ -58,13 +58,13 @@ visit_detail,visit_detail_end_date,Yes,date,This the end date of the patient-pro
For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 ""Still patient"" to identify the visit as incomplete.
All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime.",No,No,NA,NA,NA,NA,NA
visit_detail,visit_detail_end_datetime,No,datetime,NA,"If no time is given for the end date of a visit, set it to midnight (00:00:0000).",No,No,NA,NA,NA,NA,NA
visit_detail,visit_detail_type_concept_id,Yes,integer,"Use this field to understand the provenance of the visit detail record, or where the record comes from.","Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_detail,visit_detail_type_concept_id,Yes,integer,"Use this field to understand the provenance of the visit detail record, or where the record comes from.","Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
visit_detail,provider_id,No,integer,"There will only be one provider per **visit** record and the ETL document should clearly state how they were chosen (attending, admitting, etc.). This is a typical reason for leveraging the VISIT_DETAIL table as even though each VISIT_DETAIL record can only have one provider, there is no limit to the number of VISIT_DETAIL records that can be associated to a VISIT_OCCURRENCE record.",The additional providers associated to a Visit can be stored in this table where each VISIT_DETAIL record represents a different provider.,No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
visit_detail,care_site_id,No,integer,This field provides information about the Care Site where the Visit Detail took place.,There should only be one Care Site associated with a Visit Detail.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
visit_detail,visit_detail_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA
visit_detail,visit_detail_source_concept_id,No,Integer,NA,If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
visit_detail,admitting_source_value,No,Varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,NA,NA,NA,NA,NA
visit_detail,admitting_source_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_detail,admitting_source_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitting_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_detail,discharge_to_source_value,No,Varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,NA,NA,NA,NA,NA
visit_detail,discharge_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit detail record. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_detail,preceding_visit_detail_id,No,integer,Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.,"The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a ""following_visit_id"".",No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,NA,NA,NA
@ -77,7 +77,7 @@ condition_occurrence,condition_start_date,Yes,date,Use this date to determine th
condition_occurrence,condition_start_datetime,No,datetime,NA,If a source does not specify datetime the convention is to set the time to midnight (00:00:0000),No,No,NA,NA,NA,NA,NA
condition_occurrence,condition_end_date,No,date,Use this date to determine the end date of the condition,"Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE.",No,No,NA,NA,NA,NA,NA
condition_occurrence,condition_end_datetime,No,datetime,NA,If a source does not specify datetime the convention is to set the time to midnight (00:00:0000),No,No,NA,NA,NA,NA,NA
condition_occurrence,condition_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.",Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
condition_occurrence,condition_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources.",Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
condition_occurrence,condition_status_concept_id,No,integer,"This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others.","Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Condition Status,NA,NA
condition_occurrence,stop_reason,No,varchar(20),The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring.,This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.,No,No,NA,NA,NA,NA,NA
condition_occurrence,provider_id,No,integer,"The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom.","The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.",No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
@ -94,7 +94,7 @@ drug_exposure,drug_exposure_start_datetime,No,datetime,NA,"This is not required,
drug_exposure,drug_exposure_end_date,Yes,date,The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient.,"If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. [Examples by dose form](https://ohdsi.github.io/CommonDataModel/drug_dose.html)<br><br>For detailed conventions for how to populate this field, please see the [THEMIS repository](https://ohdsi.github.io/Themis/tag_drug_exposure.html).",No,No,NA,NA,NA,NA,NA
drug_exposure,drug_exposure_end_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
drug_exposure,verbatim_end_date,No,date,"This is the end date of the drug exposure as it appears in the source data, if it is given",Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.,No,No,NA,NA,NA,NA,NA
drug_exposure,drug_type_concept_id,Yes,integer,"You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.","Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
drug_exposure,drug_type_concept_id,Yes,integer,"You can use the TYPE_CONCEPT_ID to delineate between prescriptions written vs. prescriptions dispensed vs. medication history vs. patient-reported exposure, etc.","Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
drug_exposure,stop_reason,No,varchar(20),"The reason a person stopped a medication as it is represented in the source. Reasons include regimen completed, changed, removed, etc. This field will be retired in v6.0.",This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist.,No,No,NA,NA,NA,NA,NA
drug_exposure,refills,No,integer,This is only filled in when the record is coming from a prescription written this field is meant to represent intended refills at time of the prescription.,NA,No,No,NA,NA,NA,NA,NA
drug_exposure,quantity,No,float,NA,"To find the dose form of a drug the RELATIONSHIP table can be used where the relationship_id is 'Has dose form'. If liquid, quantity stands for the total amount dispensed or ordered of ingredient in the units given by the drug_strength table. If the unit from the source data does not align with the unit in the DRUG_STRENGTH table the quantity should be converted to the correct unit given in DRUG_STRENGTH. For clinical drugs with fixed dose forms (tablets etc.) the quantity is the number of units/tablets/capsules prescribed or dispensed (can be partial, but then only 1/2 or 1/3, not 0.01). Clinical drugs with divisible dose forms (injections) the quantity is the amount of ingredient the patient got. For example, if the injection is 2mg/mL but the patient got 80mL then quantity is reported as 160.
@ -116,7 +116,7 @@ procedure_occurrence,person_id,Yes,integer,The PERSON_ID of the PERSON for whom
procedure_occurrence,procedure_concept_id,Yes,integer,"The PROCEDURE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a procedure","The CONCEPT_ID that the PROCEDURE_SOURCE_VALUE maps to. Only records whose source values map to standard concepts with a domain of ""Procedure"" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Procedure&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Procedure,NA,NA
procedure_occurrence,procedure_date,Yes,date,Use this date to determine the date the procedure occurred.,"If a procedure lasts more than a day, then it should be recorded as a separate record for each day the procedure occurred, this logic is in lieu of the procedure_end_date, which will be added in a future version of the CDM.",No,No,NA,NA,NA,NA,NA
procedure_occurrence,procedure_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
procedure_occurrence,procedure_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.","Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be 'EHR encounter record'. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
procedure_occurrence,procedure_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Procedure record, as in whether the procedure was from an EHR system, insurance claim, registry, or other sources.","Choose the PROCEDURE_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. If a procedure is recorded as an EHR encounter, the PROCEDURE_TYPE_CONCEPT would be 'EHR encounter record'. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
procedure_occurrence,modifier_concept_id,No,integer,The modifiers are intended to give additional information about the procedure but as of now the vocabulary is under review.,"It is up to the ETL to choose how to map modifiers if they exist in source data. These concepts are typically distinguished by 'Modifier' concept classes (e.g., 'CPT4 Modifier' as part of the 'CPT4' vocabulary). If there is more than one modifier on a record, one should be chosen that pertains to the procedure rather than provider. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?conceptClass=CPT4+Modifier&conceptClass=HCPCS+Modifier&vocabulary=CPT4&vocabulary=HCPCS&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
procedure_occurrence,quantity,No,integer,"If the quantity value is omitted, a single procedure is assumed.","If a Procedure has a quantity of '0' in the source, this should default to '1' in the ETL. If there is a record in the source it can be assumed the exposure occurred at least once",No,No,NA,NA,NA,NA,NA
procedure_occurrence,provider_id,No,integer,"The provider associated with the procedure record, e.g. the provider who performed the Procedure.","The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record.",No,No,PROVIDER,PROVIDER_ID,NA,NA,NA
@ -132,7 +132,7 @@ device_exposure,device_exposure_start_date,Yes,date,Use this date to determine t
device_exposure,device_exposure_start_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
device_exposure,device_exposure_end_date,No,date,"The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given.",Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable.,No,No,NA,NA,NA,NA,NA
device_exposure,device_exposure_end_datetime,No,datetime,NA,If a source does not specify datetime the convention is to set the time to midnight (00:00:0000),No,No,NA,NA,NA,NA,NA
device_exposure,device_type_concept_id,Yes,integer,"You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR.","Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
device_exposure,device_type_concept_id,Yes,integer,"You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR.","Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
device_exposure,unique_device_id,No,varchar(50),"This is the Unique Device Identification number for devices regulated by the FDA, if given.","For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field.",No,No,NA,NA,NA,NA,NA
device_exposure,quantity,No,integer,NA,NA,No,No,NA,NA,NA,NA,NA
device_exposure,provider_id,No,integer,"The Provider associated with device record, e.g. the provider who wrote the prescription or the provider who implanted the device.",The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record.,No,Yes,PROVIDER,PROVIDER_ID,NA,NA,NA
@ -146,7 +146,7 @@ measurement,measurement_concept_id,Yes,integer,"The MEASUREMENT_CONCEPT_ID field
measurement,measurement_date,Yes,date,Use this date to determine the date of the measurement.,"If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient.",No,No,NA,NA,NA,NA,NA
measurement,measurement_datetime,No,datetime,NA,"This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)",No,No,NA,NA,NA,NA,NA
measurement,measurement_time,No,varchar(10),NA,This is present for backwards compatibility and will be deprecated in an upcoming version.,No,No,NA,NA,NA,NA,NA
measurement,measurement_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.","Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
measurement,measurement_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.","Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
measurement,operator_concept_id,No,integer,"The meaning of Concept [4172703](https://athena.ohdsi.org/search-terms/terms/4172703) for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =.","Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&standardConcept=Standard&page=1&pageSize=15&query=). Leave it NULL if there's an exact numeric value given (instead of putting '=') or there's no numeric value at all.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
measurement,value_as_number,No,float,"This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic.",[Convention for negative values](https://ohdsi.github.io/Themis/negative_value_as_number.html),No,No,NA,NA,NA,NA,NA
measurement,value_as_concept_id,No,integer,If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the 'Meas Value' domain.,"If there is no categorial result in the source data, set VALUE_AS_CONCEPT_ID to NULL, if there is a categorial result in a source data but without mapping, set VALUE_AS_CONCEPT_ID to 0, else map to a CONCEPT_ID.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -165,7 +165,7 @@ observation,person_id,Yes,integer,The PERSON_ID of the Person for whom the Obser
observation,observation_concept_id,Yes,integer,"The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.","The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
observation,observation_date,Yes,date,"The date of when the Observation was obtained. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient's family history was taken.",For some observations the ETL may need to make a choice as to which date to choose.,No,No,NA,NA,NA,NA,NA
observation,observation_datetime,No,datetime,NA,If no time is given set to midnight (00:00:00).,No,No,NA,NA,NA,NA,NA
observation,observation_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.","Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
observation,observation_type_concept_id,Yes,integer,"This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.","Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
observation,value_as_number,No,float,"This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist.",NA,No,No,NA,NA,NA,NA,NA
observation,value_as_string,No,varchar(60),"This is the categorical value of the Result of the Observation, if applicable and available.",NA,No,No,NA,NA,NA,NA,NA
observation,value_as_concept_id,No,Integer,"It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information.","Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. For example, ICD10 [Z82.4](https://athena.ohdsi.org/search-terms/terms/45581076) 'Family history of ischaemic heart disease and other diseases of the circulatory system' has a 'Maps to' relationship to [4167217](https://athena.ohdsi.org/search-terms/terms/4167217) 'Family history of clinical finding' as well as a 'Maps to value' record to [134057](https://athena.ohdsi.org/search-terms/terms/134057) 'Disorder of cardiovascular system'. If there's no categorial result in a source_data, set value_as_concept_id to NULL, if there is a categorial result in a source_data but without mapping, set value_as_concept_id to 0.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -180,8 +180,8 @@ observation,unit_source_value,No,varchar(50),This field houses the verbatim valu
observation,qualifier_source_value,No,varchar(50),This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred.,This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.,No,No,NA,NA,NA,NA,NA
death,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
death,death_date,Yes,date,The date the person was deceased.,"If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. For additional conventions related to this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_death_date.html). ",No,No,NA,NA,NA,NA,NA
death,death_datetime,No,datetime,NA,If not available set time to midnight (00:00:00),No,No,NA,NA,NA,NA,NA
death,death_type_concept_id,No,integer,"This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.",Use the type concept that be reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
death,death_datetime,No,datetime,NA,"If you have date and time of death, populate death_datetime, otherwise leave NULL",No,No,NA,NA,NA,NA,NA
death,death_type_concept_id,No,integer,"This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.",Use the type concept that reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
death,cause_concept_id,No,integer,"This is the Standard Concept representing the Person's cause of death, if available.","There is no specified domain for this concept, just choose the Standard Concept Id that best represents the person's cause of death.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
death,cause_source_value,No,varchar(50),NA,"If available, put the source code representing the cause of death here.",No,No,NA,NA,NA,NA,NA
death,cause_source_concept_id,No,integer,NA,If the cause of death was coded using a Vocabulary present in the OMOP Vocabularies (not necessarily a standard concept) put the CONCEPT_ID representing the cause of death here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -189,7 +189,7 @@ note,note_id,Yes,integer,A unique identifier for each note.,NA,Yes,No,NA,NA,NA,N
note,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
note,note_date,Yes,date,The date the note was recorded.,NA,No,No,NA,NA,NA,NA,NA
note,note_datetime,No,datetime,NA,If time is not given set the time to midnight.,No,No,NA,NA,NA,NA,NA
note,note_type_concept_id,Yes,integer,The provenance of the note. Most likely this will be EHR.,"Put the source system of the note, as in EHR record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
note,note_type_concept_id,Yes,integer,The provenance of the note. Most likely this will be EHR.,"Put the source system of the note, as in EHR record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
note,note_class_concept_id,Yes,integer,"A Standard Concept Id representing the HL7 LOINC
Document Type Vocabulary classification of the note.",Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. [Accepted Concepts](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=). This Concept can alternatively be represented by concepts with the relationship 'Kind of (LOINC)' to [706391](https://athena.ohdsi.org/search-terms/terms/706391) (Note).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
note,note_title,No,varchar(250),The title of the note.,NA,No,No,NA,NA,NA,NA,NA
@ -231,7 +231,7 @@ note_nlp,term_modifiers,No,varchar(2000),NA,"For the modifiers that are there, t
specimen,specimen_id,Yes,integer,Unique identifier for each specimen.,NA,Yes,No,NA,NA,NA,NA,NA
specimen,person_id,Yes,integer,The person from whom the specimen is collected.,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
specimen,specimen_concept_id,Yes,integer,NA,The standard CONCEPT_ID that the SPECIMEN_SOURCE_VALUE maps to in the specimen domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Specimen&standardConcept=Standard&page=1&pageSize=15&query=),No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
specimen,specimen_type_concept_id,Yes,integer,NA,"Put the source of the specimen record, as in an EHR system. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
specimen,specimen_type_concept_id,Yes,integer,NA,"Put the source of the specimen record, as in an EHR system. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).",No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
specimen,specimen_date,Yes,date,The date the specimen was collected.,NA,No,No,NA,NA,NA,NA,NA
specimen,specimen_datetime,No,datetime,NA,NA,No,No,NA,NA,NA,NA,NA
specimen,quantity,No,float,The amount of specimen collected from the person.,NA,No,No,NA,NA,NA,NA,NA
@ -263,7 +263,7 @@ care_site,location_id,No,integer,The location_id from the LOCATION table represe
care_site,care_site_source_value,No,varchar(50),The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.,NA,No,No,NA,NA,NA,NA,NA
care_site,place_of_service_source_value,No,varchar(50),NA,Put the place of service of the care_site as it appears in the source data.,No,No,NA,NA,NA,NA,NA
provider,provider_id,Yes,integer,It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.,"This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.",Yes,No,NA,NA,NA,NA,NA
provider,provider_name,No,varchar(255),NA,"This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database.",No,No,NA,NA,NA,NA,NA
provider,provider_name,No,varchar(255),This field contains information that describes a healthcare provider.,"This field is not required for identifying the Provider's actual identity. Instead, its purpose is to uniquely and/or anonymously identify providers of care across the database.",No,No,NA,NA,NA,NA,NA
provider,npi,No,varchar(20),This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).,NA,No,No,NA,NA,NA,NA,NA
provider,dea,No,varchar(20),"This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.",NA,No,No,NA,NA,NA,NA,NA
provider,specialty_concept_id,No,integer,"This field either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.","If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Provider&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -271,7 +271,7 @@ provider,care_site_id,No,integer,This is the CARE_SITE_ID for the location that
provider,year_of_birth,No,integer,NA,NA,No,No,NA,NA,NA,NA,NA
provider,gender_concept_id,No,integer,This field represents the recorded gender of the provider in the source data.,"If given, put a concept from the gender domain representing the recorded gender of the provider. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA
provider,provider_source_value,No,varchar(50),Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.,Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_value,No,varchar(50),"This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.",Put the kind of provider as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_value,No,varchar(50),"This refers to the specific type of healthcare provider or field of expertise listed in the source data, encompassing physician specialties like internal medicine, emergency medicine, etc., as well as allied health professionals such as nurses, midwives, and pharmacists. It covers medical specialties like surgery, internal medicine, and radiology, while other services like prosthetics, acupuncture, and physical therapy fall under the domain of ""Service.""",The type of provider and their specialty should be entered as they appear in the source data. The decision to use either the coded value or the text description is left to the discretion of the ETL-er.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_concept_id,No,integer,This is often zero as many sites use proprietary codes to store physician speciality.,If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
provider,gender_source_value,No,varchar(50),This is provider's gender as it appears in the source data.,Put the provider's gender as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.,No,No,NA,NA,NA,NA,NA
provider,gender_source_concept_id,No,integer,This is often zero as many sites use proprietary codes to store provider gender.,If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -279,17 +279,17 @@ payer_plan_period,payer_plan_period_id,Yes,integer,"A unique identifier for each
payer_plan_period,person_id,Yes,integer,The Person covered by the Plan.,"A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records",No,Yes,PERSON,PERSON_ID,NA,NA,NA
payer_plan_period,payer_plan_period_start_date,Yes,date,Start date of Plan coverage.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_plan_period_end_date,Yes,date,End date of Plan coverage.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_concept_id,No,integer,This field represents the organization who reimburses the provider which administers care to the Person.,"Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,payer_concept_id,No,integer,This field represents the organization who reimburses the provider which administers care to the Person.,"Map the payer directly to a standard CONCEPT_ID with the domain_id of 'Payer' ([Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,payer_source_value,No,varchar(50),This is the Payer as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_source_concept_id,No,integer,NA,If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_concept_id,No,integer,This field represents the specific health benefit Plan the Person is enrolled in.,Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_concept_id,No,integer,This field represents the specific health benefit Plan the Person is enrolled in.,"Map the Plan directly to a standard CONCEPT_ID in the 'Plan' vocabulary ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_source_value,No,varchar(50),This is the health benefit Plan of the Person as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,plan_source_concept_id,No,integer,NA,If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_concept_id,No,integer,"This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.",Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_concept_id,No,integer,"This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.","Map the sponsor directly to a standard CONCEPT_ID with the domain_id of 'Sponsor' ([Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_source_value,No,varchar(50),The Plan sponsor as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,sponsor_source_concept_id,No,integer,NA,If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,family_source_value,No,varchar(50),The common identifier for all people (often a family) that covered by the same policy.,Often these are the common digits of the enrollment id of the policy members.,No,No,NA,NA,NA,NA,NA
payer_plan_period,stop_reason_concept_id,No,integer,"This field represents the reason the Person left the Plan, if known.",Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,stop_reason_concept_id,No,integer,"This field represents the reason the Person left the Plan, if known.",Map the stop reason directly to a standard CONCEPT_ID with a domain of 'Plan Stop Reason' ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=)). If one does not exist visit the [Custom Concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) pate for more information.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,stop_reason_source_value,No,varchar(50),The Plan stop reason as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,stop_reason_source_concept_id,No,integer,NA,If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
cost,cost_id,Yes,integer,NA,NA,Yes,No,NA,NA,NA,NA,NA

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
21 observation_period person_id Yes integer The Person ID of the PERSON record for which the Observation Period is recorded. NA No Yes PERSON PERSON_ID NA NA NA
22 observation_period observation_period_start_date Yes date Use this date to determine the start date of the Observation Period. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_start_date can be inferred as the earliest Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. If a Person switches plans but stays with the same payer, and therefore capturing of data continues, that change would be captured in [PAYER_PLAN_PERIOD](https://ohdsi.github.io/CommonDataModel/cdm531.html#payer_plan_period). No No NA NA NA NA NA
23 observation_period observation_period_end_date Yes date Use this date to determine the end date of the period for which we can assume that all events for a Person are recorded. It is often the case that the idea of Observation Periods does not exist in source data. In those cases, the observation_period_end_date can be inferred as the last Event date available for the Person. In insurance claim data, the Observation Period can be considered as the time period the Person is enrolled with a payer. No No NA NA NA NA NA
24 observation_period period_type_concept_id Yes integer This field can be used to determine the provenance of the Observation Period as in whether the period was determined from an insurance enrollment file, EHR healthcare encounters, or other sources. Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). Choose the observation_period_type_concept_id that best represents how the period was determined. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
25 visit_occurrence visit_occurrence_id Yes integer Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. Yes No NA NA NA NA NA
26 visit_occurrence person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
27 visit_occurrence visit_concept_id Yes integer This field contains a concept id representing the kind of visit, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain. Populate this field based on the kind of visit that took place for the person. For example this could be "Inpatient Visit", "Outpatient Visit", "Ambulatory Visit", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit NA NA
35 visit_occurrence visit_source_value No varchar(50) This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.) If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created. No No NA NA NA NA NA
36 visit_occurrence visit_source_concept_id No integer NA If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. No Yes CONCEPT CONCEPT_ID NA NA NA
37 visit_occurrence admitting_source_concept_id No integer Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example. If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If available, map the admitting_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0. No Yes CONCEPT CONCEPT_ID Visit NA NA
38 visit_occurrence admitting_source_value No varchar(50) NA This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits. No No NA NA NA NA NA
39 visit_occurrence discharge_to_concept_id No integer Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example. If available, map the discharge_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit NA NA
40 visit_occurrence discharge_to_source_value No varchar(50) NA This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more. No No NA NA NA NA NA
41 visit_occurrence preceding_visit_occurrence_id No integer Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between. This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a "following_visit_id". No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
42 visit_detail visit_detail_id Yes integer Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. Yes No NA NA NA NA NA
43 visit_detail person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
44 visit_detail visit_detail_concept_id Yes integer This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain. Populate this field based on the kind of visit that took place for the person. For example this could be "Inpatient Visit", "Outpatient Visit", "Ambulatory Visit", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit NA NA
45 visit_detail visit_detail_start_date Yes date This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with. When populating VISIT_DETAIL_START_DATE, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction. No No NA NA NA NA NA
46 visit_detail visit_detail_start_datetime No datetime NA If no time is given for the start date of a visit, set it to midnight (00:00:0000). No No NA NA NA NA NA
58 visit_detail preceding_visit_detail_id No integer Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between. The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a "following_visit_id". No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
59 visit_detail visit_detail_parent_id No integer Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship. If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship. No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
60 visit_detail visit_occurrence_id Yes integer 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. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
61 condition_occurrence condition_occurrence_id Yes integer The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled. Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. Yes No NA NA NA NA NA
62 condition_occurrence person_id Yes integer The PERSON_ID of the PERSON for whom the condition is recorded. NA No Yes PERSON PERSON_ID NA NA NA
63 condition_occurrence condition_concept_id Yes integer The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of "Condition" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition NA NA
64 condition_occurrence condition_start_date Yes date Use this date to determine the start date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No NA NA NA NA NA
65 condition_occurrence condition_start_datetime No datetime NA If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
66 condition_occurrence condition_end_date No date Use this date to determine the end date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No NA NA NA NA NA
67 condition_occurrence condition_end_datetime No datetime NA If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
68 condition_occurrence condition_type_concept_id Yes integer This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources. Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
69 condition_occurrence condition_status_concept_id No integer This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others. Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition Status NA NA
70 condition_occurrence stop_reason No varchar(20) The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring. This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist. No No NA NA NA NA NA
77 drug_exposure drug_exposure_id Yes integer The unique key given to records of drug dispensings or administrations for a person. Refer to the ETL for how duplicate drugs during the same visit were handled. Each instance of a drug dispensing or administration present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same drug within the same visit. It is valid to keep these duplicates and assign them individual, unique, DRUG_EXPOSURE_IDs, though it is up to the ETL how they should be handled. Yes No NA NA NA NA NA
78 drug_exposure person_id Yes integer The PERSON_ID of the PERSON for whom the drug dispensing or administration is recorded. This may be a system generated code. NA No Yes PERSON PERSON_ID NA NA NA
79 drug_exposure drug_concept_id Yes integer The DRUG_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a drug product or molecule otherwise introduced to the body. The drug concepts can have a varying degree of information about drug strength and dose. This information is relevant in the context of quantity and administration information in the subsequent fields plus strength information from the DRUG_STRENGTH table, provided as part of the standard vocabulary download. The CONCEPT_ID that the DRUG_SOURCE_VALUE maps to. The concept id should be derived either from mapping from the source concept id or by picking the drug concept representing the most amount of detail you have. Records whose source values map to standard concepts with a domain of Drug should go in this table. When the Drug Source Value of the code cannot be translated into Standard Drug Concept IDs, a Drug exposure entry is stored with only the corresponding SOURCE_CONCEPT_ID and DRUG_SOURCE_VALUE and a DRUG_CONCEPT_ID of 0. The Drug Concept with the most detailed content of information is preferred during the mapping process. These are indicated in the CONCEPT_CLASS_ID field of the Concept and are recorded in the following order of precedence: Marketed Product, Branded Pack, Clinical Pack, Branded Drug, Clinical Drug, Branded Drug Component, Clinical Drug Component, Branded Drug Form, Clinical Drug Form, and only if no other information is available Ingredient. Note: If only the drug class is known, the DRUG_CONCEPT_ID field should contain 0. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Drug&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Drug NA NA
80 drug_exposure drug_exposure_start_date Yes date Use this date to determine the start date of the drug record. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration was recorded. It is a valid ETL choice to use the date the drug was ordered as the DRUG_EXPOSURE_START_DATE. No No NA NA NA NA NA
81 drug_exposure drug_exposure_start_datetime No datetime NA This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
82 drug_exposure drug_exposure_end_date Yes date The DRUG_EXPOSURE_END_DATE denotes the day the drug exposure ended for the patient. If this information is not explicitly available in the data, infer the end date using the following methods:<br><br> 1. Start first with duration or days supply using the calculation drug start date + days supply -1 day. 2. Use quantity divided by daily dose that you may obtain from the sig or a source field (or assumed daily dose of 1) for solid, indivisibile, drug products. If quantity represents ingredient amount, quantity divided by daily dose * concentration (from drug_strength) drug concept id tells you the dose form. 3. If it is an administration record, set drug end date equal to drug start date. If the record is a written prescription then set end date to start date + 29. If the record is a mail-order prescription set end date to start date + 89. The end date must be equal to or greater than the start date. Ibuprofen 20mg/mL oral solution concept tells us this is oral solution. Calculate duration as quantity (200 example) * daily dose (5mL) /concentration (20mg/mL) 200*5/20 = 50 days. [Examples by dose form](https://ohdsi.github.io/CommonDataModel/drug_dose.html)<br><br>For detailed conventions for how to populate this field, please see the [THEMIS repository](https://ohdsi.github.io/Themis/tag_drug_exposure.html). No No NA NA NA NA NA
83 drug_exposure drug_exposure_end_datetime No datetime NA This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
94 drug_exposure visit_occurrence_id No integer The Visit during which the drug was prescribed, administered or dispensed. To populate this field drug exposures must be explicitly initiated in the visit. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
95 drug_exposure visit_detail_id No integer The VISIT_DETAIL record during which the drug exposure occurred. For example, if the person was in the ICU at the time of the drug administration the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Same rules apply as for the VISIT_OCCURRENCE_ID. No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
96 drug_exposure drug_source_value No varchar(50) This field houses the verbatim value from the source data representing the drug exposure that occurred. For example, this could be an NDC or Gemscript code. This code is mapped to a Standard Drug Concept in the Standardized Vocabularies and the original code is stored here for reference. No No NA NA NA NA NA
97 drug_exposure drug_source_concept_id No integer This is the concept representing the drug source value and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Drug necessary for a given analytic use case. Consider using DRUG_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. If the DRUG_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. No Yes CONCEPT CONCEPT_ID NA NA NA
98 drug_exposure route_source_value No varchar(50) This field houses the verbatim value from the source data representing the drug route. This information may be called something different in the source data but the field is meant to contain a value indicating when and how a drug was given to a patient. This source value is mapped to a standard concept which is stored in the ROUTE_CONCEPT_ID field. No No NA NA NA NA NA
99 drug_exposure dose_unit_source_value No varchar(50) This field houses the verbatim value from the source data representing the dose unit of the drug given. This information may be called something different in the source data but the field is meant to contain a value indicating the unit of dosage of drug given to the patient. This is an older column and will be deprecated in an upcoming version. No No NA NA NA NA NA
100 procedure_occurrence procedure_occurrence_id Yes integer The unique key given to a procedure record for a person. Refer to the ETL for how duplicate procedures during the same visit were handled. Each instance of a procedure occurrence in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same procedure within the same visit. It is valid to keep these duplicates and assign them individual, unique, PROCEDURE_OCCURRENCE_IDs, though it is up to the ETL how they should be handled. Yes No NA NA NA NA NA
116 device_exposure device_concept_id Yes integer The DEVICE_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source concept id which represents a foreign object or instrument the person was exposed to. The CONCEPT_ID that the DEVICE_SOURCE_VALUE maps to. No Yes CONCEPT CONCEPT_ID Device NA NA
117 device_exposure device_exposure_start_date Yes date Use this date to determine the start date of the device record. Valid entries include a start date of a procedure to implant a device, the date of a prescription for a device, or the date of device administration. No No NA NA NA NA NA
118 device_exposure device_exposure_start_datetime No datetime NA This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
119 device_exposure device_exposure_end_date No date The DEVICE_EXPOSURE_END_DATE denotes the day the device exposure ended for the patient, if given. Put the end date or discontinuation date as it appears from the source data or leave blank if unavailable. No No NA NA NA NA NA
120 device_exposure device_exposure_end_datetime No datetime NA If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
121 device_exposure device_type_concept_id Yes integer You can use the TYPE_CONCEPT_ID to denote the provenance of the record, as in whether the record is from administrative claims or EHR. Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). Choose the drug_type_concept_id that best represents the provenance of the record, for example whether it came from a record of a prescription written or physician administered drug. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
122 device_exposure unique_device_id No varchar(50) This is the Unique Device Identification number for devices regulated by the FDA, if given. For medical devices that are regulated by the FDA, a Unique Device Identification (UDI) is provided if available in the data source and is recorded in the UNIQUE_DEVICE_ID field. No No NA NA NA NA NA
132 measurement measurement_date Yes date Use this date to determine the date of the measurement. If there are multiple dates in the source data associated with a record such as order_date, draw_date, and result_date, choose the one that is closest to the date the sample was drawn from the patient. No No NA NA NA NA NA
133 measurement measurement_datetime No datetime NA This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
134 measurement measurement_time No varchar(10) NA This is present for backwards compatibility and will be deprecated in an upcoming version. No No NA NA NA NA NA
135 measurement measurement_type_concept_id Yes integer This field can be used to determine the provenance of the Measurement record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources. Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). Choose the MEASUREMENT_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
136 measurement operator_concept_id No integer The meaning of Concept [4172703](https://athena.ohdsi.org/search-terms/terms/4172703) for '=' is identical to omission of a OPERATOR_CONCEPT_ID value. Since the use of this field is rare, it's important when devising analyses to not to forget testing for the content of this field for values different from =. Operators are <, <=, =, >=, > and these concepts belong to the 'Meas Value Operator' domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Meas+Value+Operator&standardConcept=Standard&page=1&pageSize=15&query=). Leave it NULL if there's an exact numeric value given (instead of putting '=') or there's no numeric value at all. No Yes CONCEPT CONCEPT_ID NA NA NA
137 measurement value_as_number No float This is the numerical value of the Result of the Measurement, if available. Note that measurements such as blood pressures will be split into their component parts i.e. one record for systolic, one record for diastolic. [Convention for negative values](https://ohdsi.github.io/Themis/negative_value_as_number.html) No No NA NA NA NA NA
138 measurement value_as_concept_id No integer If the raw data gives a categorial result for measurements those values are captured and mapped to standard concepts in the 'Meas Value' domain. If there is no categorial result in the source data, set VALUE_AS_CONCEPT_ID to NULL, if there is a categorial result in a source data but without mapping, set VALUE_AS_CONCEPT_ID to 0, else map to a CONCEPT_ID. No Yes CONCEPT CONCEPT_ID NA NA NA
146 measurement measurement_source_concept_id No integer This is the concept representing the MEASUREMENT_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Measurement necessary for a given analytic use case. Consider using MEASUREMENT_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. If the MEASUREMENT_SOURCE_VALUE is coded in the source data using a vocabulary supported by OMOP Standardized Vocabularies, insert the CONCEPT_ID representing the source value here. No Yes CONCEPT CONCEPT_ID NA NA NA
147 measurement unit_source_value No varchar(50) This field contains the exact value from the source data that represents the unit of measurement used. This value corresponds to a standardized CONCEPT_ID found in UNIT_CONCEPT_ID and in the 'Unit' domain within the Standardized Vocabularies. The original code is retained here for reference purposes. No No NA NA NA NA NA
148 measurement value_source_value No varchar(50) This field houses the verbatim result value of the Measurement from the source data . If both a continuous and categorical result are given in the source data such that both VALUE_AS_NUMBER and VALUE_AS_CONCEPT_ID are both included, store the verbatim value that was mapped to VALUE_AS_CONCEPT_ID here. No No NA NA NA NA NA
149 observation observation_id Yes integer The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled. Each instance of an observation present in the source data should be assigned this unique key. Yes No NA NA NA NA NA
150 observation person_id Yes integer The PERSON_ID of the Person for whom the Observation is recorded. This may be a system generated code. NA No Yes PERSON PERSON_ID NA NA NA
151 observation observation_concept_id Yes integer The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table. No Yes CONCEPT CONCEPT_ID NA NA NA
152 observation observation_date Yes date The date of when the Observation was obtained. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient's family history was taken. For some observations the ETL may need to make a choice as to which date to choose. No No NA NA NA NA NA
165 observation unit_source_value No varchar(50) This field houses the verbatim value from the source data representing the unit of the Observation that occurred. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. No No NA NA NA NA NA
166 observation qualifier_source_value No varchar(50) This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. No No NA NA NA NA NA
167 death person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
168 death death_date Yes date The date the person was deceased. If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. For additional conventions related to this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_death_date.html). No No NA NA NA NA NA
169 death death_datetime No datetime NA If not available set time to midnight (00:00:00) If you have date and time of death, populate death_datetime, otherwise leave NULL No No NA NA NA NA NA
170 death death_type_concept_id No integer This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc. Use the type concept that be reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). Use the type concept that reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
171 death cause_concept_id No integer This is the Standard Concept representing the Person's cause of death, if available. There is no specified domain for this concept, just choose the Standard Concept Id that best represents the person's cause of death. No Yes CONCEPT CONCEPT_ID NA NA NA
180 note note_title No varchar(250) The title of the note. NA No No NA NA NA NA NA
181 note note_text Yes varchar(MAX) The content of the note. NA No No NA NA NA NA NA
182 note encoding_concept_id Yes integer This is the Concept representing the character encoding type. Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 ([32678](https://athena.ohdsi.org/search-terms/terms/32678)). It the note is encoded in any other type, like ASCII then put 0. No Yes CONCEPT CONCEPT_ID NA NA NA
183 note language_concept_id Yes integer The language of the note. Use Concepts that are descendants of the concept [4182347](https://athena.ohdsi.org/search-terms/terms/4182347) (World Languages). No Yes CONCEPT CONCEPT_ID NA NA NA
184 note provider_id No integer The Provider who wrote the note. The ETL may need to make a determination on which provider to put here. No Yes PROVIDER PROVIDER_ID NA NA NA
185 note visit_occurrence_id No integer The Visit during which the note was written. NA No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
186 note visit_detail_id No integer The Visit Detail during which the note was written. NA No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
187 note note_source_value No varchar(50) NA The source value mapped to the NOTE_CLASS_CONCEPT_ID. No No NA NA NA NA NA
189 note_nlp note_id Yes integer This is the NOTE_ID for the NOTE record the NLP record is associated to. NA No No NA NA NA NA NA
190 note_nlp section_concept_id No integer NA The SECTION_CONCEPT_ID should be used to represent the note section contained in the NOTE_NLP record. These concepts can be found as parts of document panels and are based on the type of note written, i.e. a discharge summary. These panels can be found as concepts with the relationship 'Subsumes' to CONCEPT_ID [45875957](https://athena.ohdsi.org/search-terms/terms/45875957). No Yes CONCEPT CONCEPT_ID NA NA NA
191 note_nlp snippet No varchar(250) A small window of text surrounding the term NA No No NA NA NA NA NA
192 note_nlp "offset" No varchar(50) Character offset of the extracted term in the input note NA No No NA NA NA NA NA
193 note_nlp lexical_variant Yes varchar(250) Raw text extracted from the NLP tool. NA No No NA NA NA NA NA
194 note_nlp note_nlp_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
195 note_nlp note_nlp_source_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
231 care_site care_site_name No varchar(255) The name of the care_site as it appears in the source data NA No No NA NA NA NA NA
232 care_site place_of_service_concept_id No integer This is a high-level way of characterizing a Care Site. Typically, however, Care Sites can provide care in multiple settings (inpatient, outpatient, etc.) and this granularity should be reflected in the visit. Choose the concept in the visit domain that best represents the setting in which healthcare is provided in the Care Site. If most visits in a Care Site are Inpatient, then the place_of_service_concept_id should represent Inpatient. If information is present about a unique Care Site (e.g. Pharmacy) then a Care Site record should be created. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=2&pageSize=15&query=). For information about how to populate this field please see the [THEMIS Conventions](https://ohdsi.github.io/Themis/tag_place_of_service.html). No Yes CONCEPT CONCEPT_ID NA NA NA
233 care_site location_id No integer The location_id from the LOCATION table representing the physical location of the care_site. NA No Yes LOCATION LOCATION_ID NA NA NA
234 care_site care_site_source_value No varchar(50) The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site. NA No No NA NA NA NA NA
235 care_site place_of_service_source_value No varchar(50) NA Put the place of service of the care_site as it appears in the source data. No No NA NA NA NA NA
236 provider provider_id Yes integer It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently. This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number. Yes No NA NA NA NA NA
237 provider provider_name No varchar(255) NA This field contains information that describes a healthcare provider. This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database. This field is not required for identifying the Provider's actual identity. Instead, its purpose is to uniquely and/or anonymously identify providers of care across the database. No No NA NA NA NA NA
263 payer_plan_period stop_reason_concept_id No integer This field represents the reason the Person left the Plan, if known. Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=). Map the stop reason directly to a standard CONCEPT_ID with a domain of 'Plan Stop Reason' ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=)). If one does not exist visit the [Custom Concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) pate for more information. No Yes CONCEPT CONCEPT_ID NA NA NA
264 payer_plan_period stop_reason_source_value No varchar(50) The Plan stop reason as it appears in the source data. NA No No NA NA NA NA NA
265 payer_plan_period stop_reason_source_concept_id No integer NA If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID NA NA NA
266 cost cost_id Yes integer NA NA Yes No NA NA NA NA NA
267 cost cost_event_id Yes integer NA NA No No NA NA NA NA NA
268 cost cost_domain_id Yes varchar(20) NA NA No Yes DOMAIN DOMAIN_ID NA NA NA
269 cost cost_type_concept_id Yes integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
271 cost total_charge No float NA NA No No NA NA NA NA NA
272 cost total_cost No float NA NA No No NA NA NA NA NA
273 cost total_paid No float NA NA No No NA NA NA NA NA
274 cost paid_by_payer No float NA NA No No NA NA NA NA NA
275 cost paid_by_patient No float NA NA No No NA NA NA NA NA
276 cost paid_patient_copay No float NA NA No No NA NA NA NA NA
277 cost paid_patient_coinsurance No float NA NA No No NA NA NA NA NA
279 cost paid_by_primary No float NA NA No No NA NA NA NA NA
280 cost paid_ingredient_cost No float NA NA No No NA NA NA NA NA
281 cost paid_dispensing_fee No float NA NA No No NA NA NA NA NA
282 cost payer_plan_period_id No integer NA NA No No NA NA NA NA NA
283 cost amount_allowed No float NA NA No No NA NA NA NA NA
284 cost revenue_code_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
285 cost revenue_code_source_value No varchar(50) Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. NA No No NA NA NA NA NA
286 cost drg_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
287 cost drg_source_value No varchar(3) Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. NA No No NA NA NA NA NA
288 drug_era drug_era_id Yes integer NA NA Yes No NA NA NA NA NA
289 drug_era person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
290 drug_era drug_concept_id Yes integer The drug_concept_id should conform to the concept class 'ingredient' as the drug_era is an era of time where a person is exposed to a particular drug ingredient. NA No Yes CONCEPT CONCEPT_ID Drug Ingredient NA
291 drug_era drug_era_start_date Yes date NA The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. No No NA NA NA NA NA
292 drug_era drug_era_end_date Yes date NA The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. No No NA NA NA NA NA
293 drug_era drug_exposure_count No integer The count of grouped DRUG_EXPOSURE records that were included in the DRUG_ERA row NA No No NA NA NA NA NA
294 drug_era gap_days No integer NA The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are "not stockpiled" by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling. No No NA NA NA NA NA
295 dose_era dose_era_id Yes integer NA NA Yes No NA NA NA NA NA

View File

@ -40,7 +40,7 @@ visit_occurrence,provider_id,No,integer,"There will only be one provider per vis
visit_occurrence,care_site_id,No,integer,This field provides information about the Care Site where the Visit took place.,There should only be one Care Site associated with a Visit.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
visit_occurrence,visit_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA
visit_occurrence,visit_source_concept_id,No,integer,NA,If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
visit_occurrence,admitted_from_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,admitted_from_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,admitted_from_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,NA,NA,NA,NA,NA
visit_occurrence,discharged_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for ""home"". Use concept id = 0 when a person is discharged to home.","If available, map the discharged_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). ",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_occurrence,discharged_to_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,NA,NA,NA,NA,NA
@ -63,7 +63,7 @@ visit_detail,provider_id,No,integer,"There will only be one provider per **visi
visit_detail,care_site_id,No,integer,This field provides information about the Care Site where the Visit Detail took place.,There should only be one Care Site associated with a Visit Detail.,No,Yes,CARE_SITE,CARE_SITE_ID,NA,NA,NA
visit_detail,visit_detail_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,NA,NA,NA,NA,NA
visit_detail,visit_detail_source_concept_id,No,Integer,NA,If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
visit_detail,admitted_from_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If the person was admitted from home, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_detail,admitted_from_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). If a person was admitted from home or was self-referred, set this to 0.",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
visit_detail,admitted_from_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,NA,NA,NA,NA,NA
visit_detail,discharged_to_source_value,No,varchar(50),NA,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,NA,NA,NA,NA,NA
visit_detail,discharged_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was transferred to another hospital or sent to a long-term care facility, for example. It is assumed that a person is discharged to home therefore there is not a standard concept id for ""home"". Use concept id = 0 when a person is discharged to home.","If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,NA,NA
@ -192,8 +192,8 @@ observation,observation_event_id,No,integer,"If the Observation record is relate
observation,obs_event_field_concept_id,No,integer,"If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.",Put the CONCEPT_ID that identifies which table and field the OBSERVATION_EVENT_ID came from.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
death,person_id,Yes,integer,NA,NA,No,Yes,PERSON,PERSON_ID,NA,NA,NA
death,death_date,Yes,date,The date the person was deceased.,"If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. For additional conventions related to this field, please refer to the [THEMIS repository](https://ohdsi.github.io/Themis/tag_death_date.html). ",No,No,NA,NA,NA,NA,NA
death,death_datetime,No,datetime,NA,If not available set time to midnight (00:00:00),No,No,NA,NA,NA,NA,NA
death,death_type_concept_id,No,integer,"This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.",Use the type concept that be reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
death,death_datetime,No,datetime,NA,"If you have date and time of death, populate death_datetime, otherwise leave NULL",No,No,NA,NA,NA,NA,NA
death,death_type_concept_id,No,integer,"This is the provenance of the death record, i.e., where it came from. It is possible that an administrative claims database would source death information from a government file so do not assume the Death Type is the same as the Visit Type, etc.",Use the type concept that reflects the source of the death record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT).,No,Yes,CONCEPT,CONCEPT_ID,Type Concept,NA,NA
death,cause_concept_id,No,integer,"This is the Standard Concept representing the Person's cause of death, if available.","There is no specified domain for this concept, just choose the Standard Concept Id that best represents the person's cause of death.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
death,cause_source_value,No,varchar(50),NA,"If available, put the source code representing the cause of death here.",No,No,NA,NA,NA,NA,NA
death,cause_source_concept_id,No,integer,NA,If the cause of death was coded using a Vocabulary present in the OMOP Vocabularies (not necessarily a standard concept) put the CONCEPT_ID representing the cause of death here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -281,7 +281,7 @@ care_site,location_id,No,integer,The location_id from the LOCATION table represe
care_site,care_site_source_value,No,varchar(50),The identifier of the care_site as it appears in the source data. This could be an identifier separate from the name of the care_site.,NA,No,No,NA,NA,NA,NA,NA
care_site,place_of_service_source_value,No,varchar(50),NA,Put the place of service of the care_site as it appears in the source data.,No,No,NA,NA,NA,NA,NA
provider,provider_id,Yes,integer,It is assumed that every provider with a different unique identifier is in fact a different person and should be treated independently.,"This identifier can be the original id from the source data provided it is an integer, otherwise it can be an autogenerated number.",Yes,No,NA,NA,NA,NA,NA
provider,provider_name,No,varchar(255),NA,"This field is not necessary as it is not necessary to have the actual identity of the Provider. Rather, the idea is to uniquely and anonymously identify providers of care across the database.",No,No,NA,NA,NA,NA,NA
provider,provider_name,No,varchar(255),This field contains information that describes a healthcare provider.,"This field is not required for identifying the Provider's actual identity. Instead, its purpose is to uniquely and/or anonymously identify providers of care across the database.",No,No,NA,NA,NA,NA,NA
provider,npi,No,varchar(20),This is the National Provider Number issued to health care providers in the US by the Centers for Medicare and Medicaid Services (CMS).,NA,No,No,NA,NA,NA,NA,NA
provider,dea,No,varchar(20),"This is the identifier issued by the DEA, a US federal agency, that allows a provider to write prescriptions for controlled substances.",NA,No,No,NA,NA,NA,NA,NA
provider,specialty_concept_id,No,integer,"This field either represents the most common specialty that occurs in the data or the most specific concept that represents all specialties listed, should the provider have more than one. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.","If a Provider has more than one Specialty, there are two options: 1. Choose a concept_id which is a common ancestor to the multiple specialties, or, 2. Choose the specialty that occurs most often for the provider. Concepts in this field should be Standard with a domain of Provider. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Provider&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -289,7 +289,7 @@ provider,care_site_id,No,integer,This is the CARE_SITE_ID for the location that
provider,year_of_birth,No,integer,NA,NA,No,No,NA,NA,NA,NA,NA
provider,gender_concept_id,No,integer,This field represents the recorded gender of the provider in the source data.,"If given, put a concept from the gender domain representing the recorded gender of the provider. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Gender&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Gender,NA,NA
provider,provider_source_value,No,varchar(50),Use this field to link back to providers in the source data. This is typically used for error checking of ETL logic.,Some use cases require the ability to link back to providers in the source data. This field allows for the storing of the provider identifier as it appears in the source.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_value,No,varchar(50),"This is the kind of provider or specialty as it appears in the source data. This includes physician specialties such as internal medicine, emergency medicine, etc. and allied health professionals such as nurses, midwives, and pharmacists.",Put the kind of provider as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_value,No,varchar(50),"This refers to the specific type of healthcare provider or field of expertise listed in the source data, encompassing physician specialties like internal medicine, emergency medicine, etc., as well as allied health professionals such as nurses, midwives, and pharmacists. It covers medical specialties like surgery, internal medicine, and radiology, while other services like prosthetics, acupuncture, and physical therapy fall under the domain of ""Service.""",The type of provider and their specialty should be entered as they appear in the source data. The decision to use either the coded value or the text description is left to the discretion of the ETL-er.,No,No,NA,NA,NA,NA,NA
provider,specialty_source_concept_id,No,integer,This is often zero as many sites use proprietary codes to store physician speciality.,If the source data codes provider specialty in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
provider,gender_source_value,No,varchar(50),This is provider's gender as it appears in the source data.,Put the provider's gender as it appears in the source data. This field is up to the discretion of the ETL-er as to whether this should be the coded value from the source or the text description of the lookup value.,No,No,NA,NA,NA,NA,NA
provider,gender_source_concept_id,No,integer,This is often zero as many sites use proprietary codes to store provider gender.,If the source data codes provider gender in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
@ -297,17 +297,17 @@ payer_plan_period,payer_plan_period_id,Yes,integer,"A unique identifier for each
payer_plan_period,person_id,Yes,integer,The Person covered by the Plan.,"A single Person can have multiple, overlapping, PAYER_PLAN_PERIOD records",No,Yes,PERSON,PERSON_ID,NA,NA,NA
payer_plan_period,payer_plan_period_start_date,Yes,date,Start date of Plan coverage.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_plan_period_end_date,Yes,date,End date of Plan coverage.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_concept_id,No,integer,This field represents the organization who reimburses the provider which administers care to the Person.,"Map the Payer directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same payer, though the name of the Payer is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,payer_concept_id,No,integer,This field represents the organization who reimburses the provider which administers care to the Person.,"Map the payer directly to a standard CONCEPT_ID with the domain_id of 'Payer' ([Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Payer&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,payer_source_value,No,varchar(50),This is the Payer as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,payer_source_concept_id,No,integer,NA,If the source data codes the Payer in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_concept_id,No,integer,This field represents the specific health benefit Plan the Person is enrolled in.,Map the Plan directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same health benefit Plan though the name of the Plan is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_concept_id,No,integer,This field represents the specific health benefit Plan the Person is enrolled in.,"Map the Plan directly to a standard CONCEPT_ID in the 'Plan' vocabulary ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,plan_source_value,No,varchar(50),This is the health benefit Plan of the Person as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,plan_source_concept_id,No,integer,NA,If the source data codes the Plan in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_concept_id,No,integer,"This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.",Map the sponsor directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. The point is to stratify on this information and identify if Persons have the same sponsor though the name of the sponsor is not necessary. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_concept_id,No,integer,"This field represents the sponsor of the Plan who finances the Plan. This includes self-insured, small group health plan and large group health plan.","Map the sponsor directly to a standard CONCEPT_ID with the domain_id of 'Sponsor' ([Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&standardConcept=Standard&page=1&pageSize=15&query=)). This vocabulary is not exhaustive so if there is a value missing, please see the [custom concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) page.",No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,sponsor_source_value,No,varchar(50),The Plan sponsor as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,sponsor_source_concept_id,No,integer,NA,If the source data codes the sponsor in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,family_source_value,No,varchar(50),The common identifier for all people (often a family) that covered by the same policy.,Often these are the common digits of the enrollment id of the policy members.,No,No,NA,NA,NA,NA,NA
payer_plan_period,stop_reason_concept_id,No,integer,"This field represents the reason the Person left the Plan, if known.",Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=).,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,stop_reason_concept_id,No,integer,"This field represents the reason the Person left the Plan, if known.",Map the stop reason directly to a standard CONCEPT_ID with a domain of 'Plan Stop Reason' ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=)). If one does not exist visit the [Custom Concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) pate for more information.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
payer_plan_period,stop_reason_source_value,No,varchar(50),The Plan stop reason as it appears in the source data.,NA,No,No,NA,NA,NA,NA,NA
payer_plan_period,stop_reason_source_concept_id,No,integer,NA,If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here.,No,Yes,CONCEPT,CONCEPT_ID,NA,NA,NA
cost,cost_id,Yes,integer,NA,NA,Yes,No,NA,NA,NA,NA,NA

1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
40 visit_occurrence discharged_to_source_value No varchar(50) NA This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more. No No NA NA NA NA NA
41 visit_occurrence preceding_visit_occurrence_id No integer Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between. This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a "following_visit_id". No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
42 visit_detail visit_detail_id Yes integer Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. Yes No NA NA NA NA NA
43 visit_detail person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
44 visit_detail visit_detail_concept_id Yes integer This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain. Populate this field based on the kind of visit that took place for the person. For example this could be "Inpatient Visit", "Outpatient Visit", "Ambulatory Visit", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit NA NA
45 visit_detail visit_detail_start_date Yes date This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with. When populating VISIT_DETAIL_START_DATE, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction. No No NA NA NA NA NA
46 visit_detail visit_detail_start_datetime No datetime NA If no time is given for the start date of a visit, set it to midnight (00:00:0000). No No NA NA NA NA NA
63 condition_occurrence condition_concept_id Yes integer The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of "Condition" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition NA NA
64 condition_occurrence condition_start_date Yes date Use this date to determine the start date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No NA NA NA NA NA
65 condition_occurrence condition_start_datetime No datetime NA If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
66 condition_occurrence condition_end_date No date Use this date to determine the end date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No NA NA NA NA NA
67 condition_occurrence condition_end_datetime No datetime NA If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No NA NA NA NA NA
68 condition_occurrence condition_type_concept_id Yes integer This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources. Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). A more detailed explanation of each Type Concept can be found on the [vocabulary wiki](https://github.com/OHDSI/Vocabulary-v5.0/wiki/Vocab.-TYPE_CONCEPT). No Yes CONCEPT CONCEPT_ID Type Concept NA NA
69 condition_occurrence condition_status_concept_id No integer This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others. Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition Status NA NA
192 note note_title No varchar(250) The title of the note. NA No No NA NA NA NA NA
193 note note_text Yes varchar(MAX) The content of the note. NA No No NA NA NA NA NA
194 note encoding_concept_id Yes integer This is the Concept representing the character encoding type. Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 ([32678](https://athena.ohdsi.org/search-terms/terms/32678)). It the note is encoded in any other type, like ASCII then put 0. No Yes CONCEPT CONCEPT_ID NA NA NA
195 note language_concept_id Yes integer The language of the note. Use Concepts that are descendants of the concept [4182347](https://athena.ohdsi.org/search-terms/terms/4182347) (World Languages). No Yes CONCEPT CONCEPT_ID NA NA NA
196 note provider_id No integer The Provider who wrote the note. The ETL may need to make a determination on which provider to put here. No Yes PROVIDER PROVIDER_ID NA NA NA
197 note visit_occurrence_id No integer The Visit during which the note was written. NA No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID NA NA NA
198 note visit_detail_id No integer The Visit Detail during which the note was written. NA No Yes VISIT_DETAIL VISIT_DETAIL_ID NA NA NA
199 note note_source_value No varchar(50) NA The source value mapped to the NOTE_CLASS_CONCEPT_ID. No No NA NA NA NA NA
281 payer_plan_period stop_reason_concept_id No integer This field represents the reason the Person left the Plan, if known. Map the stop reason directly to a standard CONCEPT_ID. If one does not exists please contact the vocabulary team. There is no global controlled vocabulary available for this information. [Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=). Map the stop reason directly to a standard CONCEPT_ID with a domain of 'Plan Stop Reason' ([Accepted Concepts](http://athena.ohdsi.org/search-terms/terms?domain=Plan+Stop+Reason&standardConcept=Standard&page=1&pageSize=15&query=)). If one does not exist visit the [Custom Concepts](https://ohdsi.github.io/CommonDataModel/customConcepts.html) pate for more information. No Yes CONCEPT CONCEPT_ID NA NA NA
282 payer_plan_period stop_reason_source_value No varchar(50) The Plan stop reason as it appears in the source data. NA No No NA NA NA NA NA
283 payer_plan_period stop_reason_source_concept_id No integer NA If the source data codes the stop reason in an OMOP supported vocabulary store the concept_id here. No Yes CONCEPT CONCEPT_ID NA NA NA
284 cost cost_id Yes integer NA NA Yes No NA NA NA NA NA
285 cost cost_event_id Yes integer NA NA No No NA NA NA NA NA
286 cost cost_domain_id Yes varchar(20) NA NA No Yes DOMAIN DOMAIN_ID NA NA NA
287 cost cost_type_concept_id Yes integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
289 cost total_charge No float NA NA No No NA NA NA NA NA
290 cost total_cost No float NA NA No No NA NA NA NA NA
291 cost total_paid No float NA NA No No NA NA NA NA NA
292 cost paid_by_payer No float NA NA No No NA NA NA NA NA
293 cost paid_by_patient No float NA NA No No NA NA NA NA NA
294 cost paid_patient_copay No float NA NA No No NA NA NA NA NA
295 cost paid_patient_coinsurance No float NA NA No No NA NA NA NA NA
297 cost paid_by_primary No float NA NA No No NA NA NA NA NA
298 cost paid_ingredient_cost No float NA NA No No NA NA NA NA NA
299 cost paid_dispensing_fee No float NA NA No No NA NA NA NA NA
300 cost payer_plan_period_id No integer NA NA No No NA NA NA NA NA
301 cost amount_allowed No float NA NA No No NA NA NA NA NA
302 cost revenue_code_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
303 cost revenue_code_source_value No varchar(50) Revenue codes are a method to charge for a class of procedures and conditions in the U.S. hospital system. NA No No NA NA NA NA NA
304 cost drg_concept_id No integer NA NA No Yes CONCEPT CONCEPT_ID NA NA NA
305 cost drg_source_value No varchar(3) Diagnosis Related Groups are US codes used to classify hospital cases into one of approximately 500 groups. NA No No NA NA NA NA NA
306 drug_era drug_era_id Yes integer NA NA Yes No NA NA NA NA NA
307 drug_era person_id Yes integer NA NA No Yes PERSON PERSON_ID NA NA NA
308 drug_era drug_concept_id Yes integer The drug_concept_id should conform to the concept class 'ingredient' as the drug_era is an era of time where a person is exposed to a particular drug ingredient. NA No Yes CONCEPT CONCEPT_ID Drug Ingredient NA
309 drug_era drug_era_start_date Yes date NA The Drug Era Start Date is the start date of the first Drug Exposure for a given ingredient, with at least 31 days since the previous exposure. No No NA NA NA NA NA
310 drug_era drug_era_end_date Yes date NA The Drug Era End Date is the end date of the last Drug Exposure. The End Date of each Drug Exposure is either taken from the field drug_exposure_end_date or, as it is typically not available, inferred using the following rules: For pharmacy prescription data, the date when the drug was dispensed plus the number of days of supply are used to extrapolate the End Date for the Drug Exposure. Depending on the country-specific healthcare system, this supply information is either explicitly provided in the day_supply field or inferred from package size or similar information. For Procedure Drugs, usually the drug is administered on a single date (i.e., the administration date). A standard Persistence Window of 30 days (gap, slack) is permitted between two subsequent such extrapolated DRUG_EXPOSURE records to be considered to be merged into a single Drug Era. No No NA NA NA NA NA
311 drug_era drug_exposure_count No integer The count of grouped DRUG_EXPOSURE records that were included in the DRUG_ERA row NA No No NA NA NA NA NA
312 drug_era gap_days No integer NA The Gap Days determine how many total drug-free days are observed between all Drug Exposure events that contribute to a DRUG_ERA record. It is assumed that the drugs are "not stockpiled" by the patient, i.e. that if a new drug prescription or refill is observed (a new DRUG_EXPOSURE record is written), the remaining supply from the previous events is abandoned. The difference between Persistence Window and Gap Days is that the former is the maximum drug-free time allowed between two subsequent DRUG_EXPOSURE records, while the latter is the sum of actual drug-free days for the given Drug Era under the above assumption of non-stockpiling. No No NA NA NA NA NA
313 dose_era dose_era_id Yes integer NA NA Yes No NA NA NA NA NA

View File

@ -19,16 +19,17 @@ The [community forums](http://forums.ohdsi.org/) are also a great place to ask q
**3. Are any tables or fields optional?**
It is expected that all tables will be present in a CDM though it is not a requirement that they are all populated. The two mandatory tables are:
It is expected that all tables will be present in a CDM though it is not a requirement that they are all populated. The three mandatory tables are:
* [Person](https://github.com/OHDSI/CommonDataModel/wiki/person): Contains records that uniquely identify each patient in the source data who is at-risk to have clinical observations recorded within the source systems.
* [Observation_period](https://github.com/OHDSI/CommonDataModel/wiki/observation_period): Contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems.
* [Person](https://ohdsi.github.io/CommonDataModel/cdm54.html#person): Contains records that uniquely identify each patient in the source data who is at-risk to have clinical observations recorded within the source systems.
* [Observation_period](https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period): Contains records which uniquely define the spans of time for which a Person is at-risk to have clinical events recorded within the source systems.
* [CDM_Source](https://ohdsi.github.io/CommonDataModel/cdm54.html#cdm_source): Contains information on the CDM instance including the vocabulary version used, the date the native data were released and the date the CDM was released.
It is then up to you which tables to populate, though the core event tables are generally agreed upon to be [Condition_occurrence](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE), [Procedure_occurrence](https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE), [Drug_exposure](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE), [Measurement](https://github.com/OHDSI/CommonDataModel/wiki/MEASUREMENT), and [Observation](https://github.com/OHDSI/CommonDataModel/wiki/OBSERVATION). Each table has certain required fields, a full list of which can be found on the Common Data Model [wiki page](https://github.com/OHDSI/CommonDataModel/wiki/).
It is then up to you which tables to populate, though the core event tables are generally agreed upon to be [Condition_occurrence](https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURRENCE), [Procedure_occurrence](https://ohdsi.github.io/CommonDataModel/cdm54.html#PROCEDURE_OCCURRENCE), [Drug_exposure](https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE), [Measurement](https://ohdsi.github.io/CommonDataModel/cdm54.html#MEASUREMENT), and [Observation](https://ohdsi.github.io/CommonDataModel/cdm54.html#OBSERVATION). Each table has certain required fields, a full list of which can be found on the Common Data Model [wiki page](https://ohdsi.github.io/CommonDataModel/cdm54.html#).
**4. Does the data model include any derived information? Which tables or values are derived?**
The common data model stores verbatim data from the source across various clinical domains, such as records for conditions, drugs, procedures, and measurements. In addition, to assist the analyst, the common data model also provides some derived tables, based on commonly used analytic procedures. For example, the [Condition_era](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA) table is derived from the [Condition_occurrence](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURENCE) table and both the [Drug_era](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_ERA) and [Dose_era](https://github.com/OHDSI/CommonDataModel/wiki/DOSE_ERA) tables are derived from the [Drug_exposure](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE) table. An era is defined as a span of time when a patient is assumed to have a given condition or exposure to a particular active ingredient. Members of the community have written code to create these tables and it is out on the [github](https://github.com/OHDSI/CommonDataModel/tree/master/CodeExcerpts/DerivedTables) if you choose to use it in your CDM build. It is important to reinforce, the analyst has the opportunity, but not the obligation, to use any of the derived tables and all of the source data is still available for direct use if the analysis calls for different assumptions.
The common data model stores verbatim data from the source across various clinical domains, such as records for conditions, drugs, procedures, and measurements. In addition, to assist the analyst, the common data model also provides some derived tables, based on commonly used analytic procedures. For example, the [Condition_era](https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_ERA) table is derived from the [Condition_occurrence](https://ohdsi.github.io/CommonDataModel/cdm54.html#CONDITION_OCCURENCE) table and both the [Drug_era](https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_ERA) and [Dose_era](https://ohdsi.github.io/CommonDataModel/cdm54.html#DOSE_ERA) tables are derived from the [Drug_exposure](https://ohdsi.github.io/CommonDataModel/cdm54.html#DRUG_EXPOSURE) table. An era is defined as a span of time when a patient is assumed to have a given condition or exposure to a particular active ingredient. Members of the community have written code to create these tables and it is out on the [github](https://github.com/OHDSI/CommonDataModel/tree/master/CodeExcerpts/DerivedTables) if you choose to use it in your CDM build. It is important to reinforce, the analyst has the opportunity, but not the obligation, to use any of the derived tables and all of the source data is still available for direct use if the analysis calls for different assumptions.
**5. How is age captured in the model?**
@ -52,11 +53,11 @@ If someone in the community had a use case for time-varying location of residenc
**9. How does the model denote the time period during which a Persons information is valid?**
The OMOP Common Data Model uses something called observation periods (stored in the [Observation_period](https://github.com/OHDSI/CommonDataModel/wiki/observation_period) table) as a way to define the time span during which a patient is at-risk to have a clinical event recorded. In administrative claims databases, for example, these observation periods are often analogous to the notion of enrollment.
The OMOP Common Data Model uses something called observation periods (stored in the [Observation_period](https://ohdsi.github.io/CommonDataModel/cdm54.html#observation_period) table) as a way to define the time span during which a patient is at-risk to have a clinical event recorded. In administrative claims databases, for example, these observation periods are often analogous to the notion of enrollment.
**10. How does the model capture start and stop dates for insurance coverage? What if a persons coverage changes?**
The [Payer_plan_period](https://github.com/OHDSI/CommonDataModel/wiki/payer_plan_period) table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Payer plan periods, as opposed to observation periods, can overlap so as to denote the time when a Person is enrolled in multiple plans at the same time such as Medicare Part A and Medicare Part D.
The [Payer_plan_period](https://ohdsi.github.io/CommonDataModel/cdm54.html#payer_plan_period) table captures details of the period of time that a Person is continuously enrolled under a specific health Plan benefit structure from a given Payer. Payer plan periods, as opposed to observation periods, can overlap so as to denote the time when a Person is enrolled in multiple plans at the same time such as Medicare Part A and Medicare Part D.
**11. What if I have EHR data? How would I create observation periods?**
@ -66,7 +67,7 @@ An observation period is considered as the time at which a patient is at-risk to
**12. Do I have to map my source codes to Standard Concepts myself? Are there vocabulary mappings that already exist for me to leverage?**
If your data use any of the 55 source vocabularies that are currently supported, the mappings have been done for you. The full list is available from the open-source [ATHENA](http://athena.ohdsi.org/search-terms/terms) tool under the download tab (see below). You can choose to download the ten [vocabulary tables](https://github.com/OHDSI/CommonDataModel/wiki/Standardized-Vocabularies) from there as well you will need a copy in your environment if you plan on building a CDM.
If your data use any of the 55 source vocabularies that are currently supported, the mappings have been done for you. The full list is available from the open-source [ATHENA](http://athena.ohdsi.org/search-terms/terms) tool under the download tab (see below). You can choose to download the ten [vocabulary tables](https://ohdsi.github.io/CommonDataModel/cdm54.html#Standardized-Vocabularies) from there as well you will need a copy in your environment if you plan on building a CDM.
![](images/Athena_download_box.png)
@ -74,7 +75,7 @@ The [ATHENA](http://athena.ohdsi.org/search-terms/terms) tool also allows you to
**13. If I want to apply the mappings myself, can I do so? Are they transparent to all users?**
Yes, all mappings are available in the [Concept_relationship](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP) table (which can be downloaded from [ATHENA](http://athena.ohdsi.org/search-terms/terms)). Each value in a supported source terminology is assigned a Concept_id (which is considered non-standard). Each Source_concept_id will have a mapping to a Standard_concept_id. For example:
Yes, all mappings are available in the [Concept_relationship](https://ohdsi.github.io/CommonDataModel/cdm54.html#CONCEPT_RELATIONSHIP) table (which can be downloaded from [ATHENA](http://athena.ohdsi.org/search-terms/terms)). Each value in a supported source terminology is assigned a Concept_id (which is considered non-standard). Each Source_concept_id will have a mapping to a Standard_concept_id. For example:
![](images/Sepsis_to_SNOMED.png)