diff --git a/docs/cdm53.html b/docs/cdm53.html index bfdf165..8004b98 100644 --- 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. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. -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 @@ 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. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. -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 @@ claim, registry, or other sources. 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 @@ 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. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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’. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. 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. Accepted -Concepts. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. integer @@ -6603,7 +6632,8 @@ death_datetime -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 @@ 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. +Concepts. A more detailed explanation of each Type Concept can be +found on the vocabulary +wiki. integer @@ -6928,7 +6961,10 @@ The provenance of the note. Most likely this will be EHR. 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_type_concept_id 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 @@ No 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 @@ No 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 @@ 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. +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 @@ 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. +Concepts). This vocabulary is not exhaustive so if there is a value +missing, please see the custom +concepts page. integer @@ -9572,13 +9615,13 @@ 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. +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 @@ stop_reason_concept_id 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 e0c5ede..5ea1b2d 100644 --- 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. 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 @@ 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. 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_datetime -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 @@ 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. A more detailed explanation of each Type Concept can be found on the +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 @@ No 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 @@ 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. +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 @@ 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. +Concepts). This vocabulary is not exhaustive so if there is a value +missing, please see the custom +concepts page. integer @@ -10281,13 +10288,13 @@ 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. +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 @@ stop_reason_concept_id 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 d53e0d2..2e8d968 100644 --- a/docs/index.html +++ b/docs/index.html @@ -490,7 +490,7 @@ form and check “Common Data Model”


- +