Merge pull request #685 from OHDSI/olympians_week4

Olympians week4
2024-04-29 09:55:49 -04:00 · 2024-04-29 09:55:49 -04:00 · e2370317da
parent 803f4157d4 c92b9d7b90
commit e2370317da
7 changed files with 211 additions and 152 deletions
--- a/docs/cdm53.html
+++ b/docs/cdm53.html
@ -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
+If available, map the admitting_source_value to a standard concept in
-in the visit domain. <a
+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
+If available, map the admitting_source_value to a standard concept in
-in the visit domain. <a
+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
+This field is not required for identifying the Provider’s actual
-identity of the Provider. Rather, the idea is to uniquely and
+identity. Instead, its purpose is to uniquely and/or anonymously
-anonymously identify providers of care across the database.
+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
+This refers to the specific type of healthcare provider or field of
-data. This includes physician specialties such as internal medicine,
+expertise listed in the source data, encompassing physician specialties
-emergency medicine, etc. and allied health professionals such as nurses,
+like internal medicine, emergency medicine, etc., as well as allied
-midwives, and pharmacists.
+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
+The type of provider and their specialty should be entered as they
-up to the discretion of the ETL-er as to whether this should be the
+appear in the source data. The decision to use either the coded value or
-coded value from the source or the text description of the lookup value.
+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
+Map the payer directly to a standard CONCEPT_ID with the domain_id of
-please contact the vocabulary team. There is no global controlled
+‘Payer’ (<a
-vocabulary available for this information. The point is to stratify on
+href="https://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
-this information and identify if Persons have the same payer, though the
+Concepts</a>). This vocabulary is not exhaustive so if there is a value
-name of the Payer is not necessary. <a
+missing, please see the <a
-href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
-Concepts</a>.
+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
+Map the Plan directly to a standard CONCEPT_ID in the ‘Plan’ vocabulary
-please contact the vocabulary team. There is no global controlled
+(<a
 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
 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
+Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
-exists please contact the vocabulary team. There is no global controlled
+‘Sponsor’ (<a
-vocabulary available for this information. The point is to stratify on
+href="https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
-this information and identify if Persons have the same sponsor though
+Concepts</a>). This vocabulary is not exhaustive so if there is a value
-the name of the sponsor is not necessary. <a
+missing, please see the <a
-href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
-Concepts</a>.
+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
+Map the stop reason directly to a standard CONCEPT_ID with a domain of
-exists please contact the vocabulary team. There is no global controlled
+‘Plan Stop Reason’ (<a
 vocabulary available for this information. <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
--- a/docs/cdm54.html
+++ b/docs/cdm54.html
@ -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
+This field is not required for identifying the Provider’s actual
-identity of the Provider. Rather, the idea is to uniquely and
+identity. Instead, its purpose is to uniquely and/or anonymously
-anonymously identify providers of care across the database.
+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
+This refers to the specific type of healthcare provider or field of
-data. This includes physician specialties such as internal medicine,
+expertise listed in the source data, encompassing physician specialties
-emergency medicine, etc. and allied health professionals such as nurses,
+like internal medicine, emergency medicine, etc., as well as allied
-midwives, and pharmacists.
+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
+The type of provider and their specialty should be entered as they
-up to the discretion of the ETL-er as to whether this should be the
+appear in the source data. The decision to use either the coded value or
-coded value from the source or the text description of the lookup value.
+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
+Map the payer directly to a standard CONCEPT_ID with the domain_id of
-please contact the vocabulary team. There is no global controlled
+‘Payer’ (<a
-vocabulary available for this information. The point is to stratify on
+href="https://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
-this information and identify if Persons have the same payer, though the
+Concepts</a>). This vocabulary is not exhaustive so if there is a value
-name of the Payer is not necessary. <a
+missing, please see the <a
-href="http://athena.ohdsi.org/search-terms/terms?domain=Payer&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
-Concepts</a>.
+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
+Map the Plan directly to a standard CONCEPT_ID in the ‘Plan’ vocabulary
-please contact the vocabulary team. There is no global controlled
+(<a
 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
 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
+Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
-exists please contact the vocabulary team. There is no global controlled
+‘Sponsor’ (<a
-vocabulary available for this information. The point is to stratify on
+href="https://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
-this information and identify if Persons have the same sponsor though
+Concepts</a>). This vocabulary is not exhaustive so if there is a value
-the name of the sponsor is not necessary. <a
+missing, please see the <a
-href="http://athena.ohdsi.org/search-terms/terms?domain=Sponsor&amp;standardConcept=Standard&amp;page=1&amp;pageSize=15&amp;query=">Accepted
+href="https://ohdsi.github.io/CommonDataModel/customConcepts.html">custom
-Concepts</a>.
+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
+Map the stop reason directly to a standard CONCEPT_ID with a domain of
-exists please contact the vocabulary team. There is no global controlled
+‘Plan Stop Reason’ (<a
 vocabulary available for this information. <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
--- a/docs/faq.html
+++ b/docs/faq.html
@ -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
+not a requirement that they are all populated. The three mandatory
-are:</p>
+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>
 Person’s 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 person’s 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
--- a/docs/index.html
+++ b/docs/index.html
--- a/inst/csv/OMOP_CDMv5.3_Field_Level.csv
+++ b/inst/csv/OMOP_CDMv5.3_Field_Level.csv
@ -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_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 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_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
--- a/inst/csv/OMOP_CDMv5.4_Field_Level.csv
+++ b/inst/csv/OMOP_CDMv5.4_Field_Level.csv
@ -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_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 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_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
--- a/rmd/faq.Rmd
+++ b/rmd/faq.Rmd
@ -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.
+* [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://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.
+* [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 Person’s 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 person’s 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)