diff --git a/docs/cdm53.html b/docs/cdm53.html
index bfdf165f..8004b984 100644
--- a/docs/cdm53.html
+++ b/docs/cdm53.html
@@ -1335,7 +1335,10 @@
observation_period
Choose the observation_period_type_concept_id that best represents how
the period was determined. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
integer
@@ -1722,7 +1725,10 @@ visit_occurrence
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.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
Integer
@@ -1880,10 +1886,11 @@ visit_occurrence
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.
+Concepts. If a person was admitted from home or was self-referred,
+set this to 0.
|
integer
@@ -2332,7 +2339,10 @@ visit_detail
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.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -2517,10 +2527,11 @@ visit_detail
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.
+Concepts. If a person was admitted from home or was self-referred,
+set this to 0.
|
Integer
@@ -2997,7 +3008,10 @@ condition_occurrence
Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance
of the record. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -3644,7 +3658,10 @@ drug_exposure
the record, for example whether it came from a record of a prescription
written or physician administered drug. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -4341,7 +4358,10 @@ procedure_occurrence
claim. If a procedure is recorded as an EHR encounter, the
PROCEDURE_TYPE_CONCEPT would be ‘EHR encounter record’. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -4885,7 +4905,10 @@ device_exposure
the record, for example whether it came from a record of a prescription
written or physician administered drug. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -5387,7 +5410,10 @@ measurement
provenance of the record, for example whether it came from an EHR record
or billing claim. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -6068,7 +6094,10 @@ observation
provenance of the record, for example whether it came from an EHR record
or billing claim. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -6603,7 +6632,8 @@ death
|
|
-If not available set time to midnight (00:00:00)
+If you have date and time of death, populate death_datetime, otherwise
+leave NULL
|
datetime
@@ -6633,9 +6663,12 @@ death
the same as the Visit Type, etc.
|
-Use the type concept that be reflects the source of the death record. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -6928,7 +6961,10 @@ note
|
Put the source system of the note, as in EHR record. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -7772,7 +7808,10 @@ specimen
|
Put the source of the specimen record, as in an EHR system. Accepted
-Concepts.
+Concepts. A more detailed explanation of each Type Concept can be
+found on the vocabulary
+wiki.
|
integer
@@ -8861,11 +8900,12 @@ provider
provider_name
|
+This field contains information that describes a healthcare provider.
|
-This field is not necessary as it is not necessary to have the actual
-identity of the Provider. Rather, the idea is to uniquely and
-anonymously identify providers of care across the database.
+This field is not required for identifying the Provider’s actual
+identity. Instead, its purpose is to uniquely and/or anonymously
+identify providers of care across the database.
|
varchar(255)
@@ -9099,15 +9139,18 @@ provider
specialty_source_value
|
-This is the kind of provider or specialty as it appears in the source
-data. This includes physician specialties such as internal medicine,
-emergency medicine, etc. and allied health professionals such as nurses,
-midwives, and pharmacists.
+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.”
|
-Put the kind of provider as it appears in the source data. This field is
-up to the discretion of the ETL-er as to whether this should be the
-coded value from the source or the text description of the lookup value.
+The type of provider and their specialty should be entered as they
+appear in the source data. The decision to use either the coded value or
+the text description is left to the discretion of the ETL-er.
|
varchar(50)
@@ -9392,13 +9435,13 @@ payer_plan_period
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.
+Map the payer directly to a standard CONCEPT_ID with the domain_id of
+‘Payer’ (Accepted
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -9481,13 +9524,13 @@ payer_plan_period
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.
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -9572,13 +9615,13 @@ payer_plan_period
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.
+Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
+‘Sponsor’ (Accepted
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -9689,11 +9732,12 @@ payer_plan_period
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.
+Concepts). If one does not exist visit the Custom
+Concepts pate for more information.
|
integer
diff --git a/docs/cdm54.html b/docs/cdm54.html
index e0c5ede6..5ea1b2dd 100644
--- a/docs/cdm54.html
+++ b/docs/cdm54.html
@@ -2003,7 +2003,8 @@ visit_occurrence
If available, map the admitted_from_source_value to a standard concept
in the visit domain. Accepted
-Concepts. If a person was admitted from home, set this to 0.
+Concepts. If a person was admitted from home or was self-referred,
+set this to 0.
|
integer
@@ -2622,7 +2623,8 @@ visit_detail
If available, map the admitted_from_source_value to a standard concept
in the visit domain. Accepted
-Concepts. If the person was admitted from home, set this to 0.
+Concepts. If a person was admitted from home or was self-referred,
+set this to 0.
|
Integer
@@ -7132,7 +7134,8 @@ death
|
|
-If not available set time to midnight (00:00:00)
+If you have date and time of death, populate death_datetime, otherwise
+leave NULL
|
datetime
@@ -7162,7 +7165,7 @@ death
the same as the Visit Type, etc.
|
-Use the type concept that be reflects the source of the death record. Accepted
Concepts. A more detailed explanation of each Type Concept can be
found on the provider
provider_name
|
+This field contains information that describes a healthcare provider.
|
-This field is not necessary as it is not necessary to have the actual
-identity of the Provider. Rather, the idea is to uniquely and
-anonymously identify providers of care across the database.
+This field is not required for identifying the Provider’s actual
+identity. Instead, its purpose is to uniquely and/or anonymously
+identify providers of care across the database.
|
varchar(255)
@@ -9808,15 +9812,18 @@ provider
specialty_source_value
|
-This is the kind of provider or specialty as it appears in the source
-data. This includes physician specialties such as internal medicine,
-emergency medicine, etc. and allied health professionals such as nurses,
-midwives, and pharmacists.
+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.”
|
-Put the kind of provider as it appears in the source data. This field is
-up to the discretion of the ETL-er as to whether this should be the
-coded value from the source or the text description of the lookup value.
+The type of provider and their specialty should be entered as they
+appear in the source data. The decision to use either the coded value or
+the text description is left to the discretion of the ETL-er.
|
varchar(50)
@@ -10101,13 +10108,13 @@ payer_plan_period
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.
+Map the payer directly to a standard CONCEPT_ID with the domain_id of
+‘Payer’ (Accepted
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -10190,13 +10197,13 @@ payer_plan_period
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.
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -10281,13 +10288,13 @@ payer_plan_period
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.
+Map the sponsor directly to a standard CONCEPT_ID with the domain_id of
+‘Sponsor’ (Accepted
+Concepts). This vocabulary is not exhaustive so if there is a value
+missing, please see the custom
+concepts page.
|
integer
@@ -10398,11 +10405,12 @@ payer_plan_period
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.
+Concepts). If one does not exist visit the Custom
+Concepts pate for more information.
|
integer
diff --git a/docs/index.html b/docs/index.html
index d53e0d2b..2e8d9687 100644
--- a/docs/index.html
+++ b/docs/index.html
@@ -490,7 +490,7 @@ Calendar
-
+
|