diff --git a/mappings/ACEP_mappings/care_site.md b/mappings/ACEP_mappings/care_site.md new file mode 100644 index 0000000..eed82db --- /dev/null +++ b/mappings/ACEP_mappings/care_site.md @@ -0,0 +1,15 @@ +## Table name: care_site + +### Reading from location.csv + +![](md_files/image4.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| care_site_id | service_location_id | | service_location_id is is the unique identifier for the encounter place of service. If it is an integer it can be mapped to the care_site_id directly. If a string it has to be stored in care_site_source_value and then generated.
| +| care_site_name | service_location_name | | service_location_name is the text description of the encounter place of service. This will directly provide the care_site_name.
| +| place_of_service_concept_id | | | | +| location_id | | | This has to be auto generated for each of the care sites so that it can be linked to the location table and the location information can be mapped there. | +| care_site_source_value | service_location_id | | The original service_location_id has to be stored in the care_site_source_value.
| +| place_of_service_source_value | | | | + diff --git a/mappings/ACEP_mappings/condition_occurrence.md b/mappings/ACEP_mappings/condition_occurrence.md new file mode 100644 index 0000000..c0977ea --- /dev/null +++ b/mappings/ACEP_mappings/condition_occurrence.md @@ -0,0 +1,50 @@ +## Table name: condition_occurrence + +### Reading from encounter_diagnosis.csv + +![](md_files/image9.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| condition_occurrence_id | | | This will be generated for each unique condition occurrence if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table.
| +| condition_concept_id | encounter_diagnosis_code_description | | encounter_diagnosis_code_description is the textual description of the encounter diagnosis codes. This can be used to derive the condition_concept_id. Alternatively, if the condition_source_concept_id is a part of the OMOP vocabulary that can be used for mapping.
| +| condition_source_value | encounter_diagnosis_code_description | | encounter_diagnosis_code_description is the textual description of the encounter diagnosis codes. This can be directly stored in the condition_source_value.
| +| condition_source_concept_id | encounter_diagnosis_code | | encounter_diagnosis_code includes the primary and additional diagnosis codes related to the encounter, represented as ICD10, SNOMED, or CT codes. This can be directly stored in condition_source_concept_id.
| +| condition_status_concept_id | primary_diagnosis | | primary_diagnosis field states if the condition is the primary diagnosis. Based on the value it can be mapped to in condition_status_concept_id. This is data dependent, e.g. if only 'yes' and 'no' values are present then, 'yes' should map to concept id of 'primary diagnosis' whereas 'no' cannot be determined.
| +| condition_status_source_value | primary_diagnosis | | primary_diagnosis field states if the condition is the primary diagnosis. It can be stored in condition_status_source_value. In case of 'yes' and 'no' values, 'primary_diagnosis: yes' or 'primary_diagnosis: no' would be more descriptive values for the field.
| +| condition_start_date | onset_date_time | | onset_date_time is the date and time when the diagnosis was reported to begin or was first observed. The date element can be extracted and stored in condition_start_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| condition_start_datetime | onset_date_time | | onset_date_time is the date and time when the diagnosis was reported to begin or was first observed. It can be stored in condition_start_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| condition_end_datetime | resolution_date_time | | resolution_date_time is the date and time when the diagnosis was resolved. It can be stored in condition_end_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| condition_end_date | resolution_date_time | | resolution_date_time is the date and time when the diagnosis was resolved. The date element can be extracted and stored in condition_end_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the condition occurrence table. In the source data if npi is not unique, care_site_id can act as an additional identifier, this will be corresponding to the service_location_id.
provider_id is not given for the patient complaints at source, this could possibly mapped to the provider using a combination of the patient_is, encounter_id and service_location_id. | +| condition_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| stop_reason | | | | +| visit_detail_id | | | | + +### Reading from encounter_patient_complaint.csv + +The encounter_patient_complaint table contains the complaints which are the patient’s description of their reason for seeking care. Though it can be alternatively mapped to observation, it was mapped to condition occurrence because the OMOP documentation clearly specifies that "This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient." Observation table was ruled out because OMOP states "If the clinical fact observed determines a sign, symptom, diagnosis of a disease or other medical condition, it is recorded in the CONDITION_OCCURRENCE table." However, it would be ideal for patient_complaint_documentation_date_time to have mapability to observation_datetime. + +![](md_files/image10.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| condition_occurrence_id | | | This will be generated for each unique condition occurrence if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used.
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurrence table.
| +| condition_concept_id | patient_complaint_description | | patient_complaint_description is the text description of the complaints captured from patient encounter. It can be used to map the condition_concept_id. Alternatively, if the condition_source_concept_id follows OMOP accepted vocabulary it can be used for mapping.
| +| condition_source_value | patient_complaint_description | | patient_complaint_description is the text description of the complaints captured from patient encounter. This can be directly stored in the condition_source_value.
| +| condition_source_concept_id | patient_complaint_code | | patient_complaint_code is the standard code to document patient complaint. This can be directly stored in the condition_source_concept_id.
| +| condition_status_concept_id | patient_primary_complaint | | patient_primary_complaint documents whether the complaint is the primary complaint of the patient from the primary encounter. Based on the value it can be mapped to in condition_status_concept_id. This is data dependent, e.g. if only 'yes' and 'no' values are present then, 'yes' should map to concept id corresponding to primary patient complaint (unsure from the given vocabulary) whereas 'no' cannot be determined.
| +| condition_status_source_value | patient_primary_complaint | | patient_primary_complaint documents whether the complaint is the primary complaint of the patient from the primary encounter, this can be stored in condition_status_source_value. In case of 'yes' and 'no' values, 'patient_primary_complaint: yes' or 'patient_primary_complaint: no' would be more descriptive values for the field.
| +| condition_start_date | patient_complaint_documentation_date_time | | This should ideally be the onset time of the disease/condition however the data/time given here is the time of documentation of the complaint, which may better fit in observation_datetime field of observation table. The intermapability of the same can be investigated. As per OMOP ETL guidelines however, "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." If it is the only date available, the date element from the patient_complaint_documentation_date_time can be extracted and stored in condition_start_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| condition_start_datetime | patient_complaint_documentation_date_time | | This should ideally be the onset time of the disease/condition however the data/time given here is the time of documentation of the complaint, which may better fit in observation_datetime field of observation table. The intermapability of the same can be investigated. As per OMOP ETL guidelines however, "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." If it is the only date available, the patient_complaint_documentation_date_time can be stored in condition_start_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| condition_end_datetime | | | | +| condition_end_date | | | | +| provider_id | | | provider_id is not given for the patient complaints at source, this could possibly mapped to the provider using a combination of the patient_is, encounter_id and service_location_id. | +| condition_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| stop_reason | | | | +| visit_detail_id | | | | + diff --git a/mappings/ACEP_mappings/death.md b/mappings/ACEP_mappings/death.md new file mode 100644 index 0000000..b61aba2 --- /dev/null +++ b/mappings/ACEP_mappings/death.md @@ -0,0 +1,16 @@ +## Table name: death + +### Reading from patient.csv + +![](md_files/image2.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used.
| +| death_date | patient_date_of_death | | The format of patient_date_of_death is not provided in the dictionary and has to be checked.
| +| death_datetime | | | | +| death_type_concept_id | | | | +| cause_concept_id | | | | +| cause_source_value | | | | +| cause_source_concept_id | | | | + diff --git a/mappings/ACEP_mappings/index.md b/mappings/ACEP_mappings/index.md new file mode 100644 index 0000000..f4d9b80 --- /dev/null +++ b/mappings/ACEP_mappings/index.md @@ -0,0 +1,26 @@ +# Source Data Mapping Approach to CDMV5.4 + +![](md_files/image12.png) + +## Contents + +[person](person.md) + +[death](death.md) + +[location](location.md) + +[care_site](care_site.md) + +[observation](observation.md) + +[measurement](measurement.md) + +[visit_occurrence](visit_occurrence.md) + +[condition_occurrence](condition_occurrence.md) + +[procedure_occurrence](procedure_occurrence.md) + +[source_appendix](source_appendix.md) + diff --git a/mappings/ACEP_mappings/location.md b/mappings/ACEP_mappings/location.md new file mode 100644 index 0000000..c76c800 --- /dev/null +++ b/mappings/ACEP_mappings/location.md @@ -0,0 +1,21 @@ +## Table name: location + +### Reading from location.csv + +![](md_files/image3.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| location_id | | | This information has to be mapped from the care_site table. The service_location_id will act as care_site_source_value/care_site_id. If not provided this has to be autogenerated. | +| address_1 | service_location_street_address | | service_location_street_address contains the street address of the service location where services were provided. The first line of address will be stored in address_1
| +| address_2 | service_location_street_address | | service_location_street_address contains the street address of the service location where services were provided. The second line of address will be stored in address_2
| +| city | service_location_city | | service_location_city is the city of the service location where services were provided. This can be directly stored in city.
| +| state | service_location_state | | service_location_state is the state of the service location where services were provided. This can be directly stored in state.
| +| zip | service_location_zip_code | | service_location_zip_code is the zip code of the service location where services were provided. This can be directly stored in zip.
| +| county | | | | +| location_source_value | | | | +| country_concept_id | | | | +| country_source_value | | | | +| latitude | | | | +| longitude | | | | + diff --git a/mappings/ACEP_mappings/md_files/image1.png b/mappings/ACEP_mappings/md_files/image1.png new file mode 100644 index 0000000..5e4383e Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image1.png differ diff --git a/mappings/ACEP_mappings/md_files/image10.png b/mappings/ACEP_mappings/md_files/image10.png new file mode 100644 index 0000000..e18c2b3 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image10.png differ diff --git a/mappings/ACEP_mappings/md_files/image11.png b/mappings/ACEP_mappings/md_files/image11.png new file mode 100644 index 0000000..3c8d194 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image11.png differ diff --git a/mappings/ACEP_mappings/md_files/image12.png b/mappings/ACEP_mappings/md_files/image12.png new file mode 100644 index 0000000..3ab9263 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image12.png differ diff --git a/mappings/ACEP_mappings/md_files/image2.png b/mappings/ACEP_mappings/md_files/image2.png new file mode 100644 index 0000000..833a51f Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image2.png differ diff --git a/mappings/ACEP_mappings/md_files/image3.png b/mappings/ACEP_mappings/md_files/image3.png new file mode 100644 index 0000000..37bf741 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image3.png differ diff --git a/mappings/ACEP_mappings/md_files/image4.png b/mappings/ACEP_mappings/md_files/image4.png new file mode 100644 index 0000000..409f46e Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image4.png differ diff --git a/mappings/ACEP_mappings/md_files/image5.png b/mappings/ACEP_mappings/md_files/image5.png new file mode 100644 index 0000000..3ae72d3 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image5.png differ diff --git a/mappings/ACEP_mappings/md_files/image6.png b/mappings/ACEP_mappings/md_files/image6.png new file mode 100644 index 0000000..41dd3c5 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image6.png differ diff --git a/mappings/ACEP_mappings/md_files/image7.png b/mappings/ACEP_mappings/md_files/image7.png new file mode 100644 index 0000000..68cfe5b Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image7.png differ diff --git a/mappings/ACEP_mappings/md_files/image8.png b/mappings/ACEP_mappings/md_files/image8.png new file mode 100644 index 0000000..dec6956 Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image8.png differ diff --git a/mappings/ACEP_mappings/md_files/image9.png b/mappings/ACEP_mappings/md_files/image9.png new file mode 100644 index 0000000..096195a Binary files /dev/null and b/mappings/ACEP_mappings/md_files/image9.png differ diff --git a/mappings/ACEP_mappings/measurement.md b/mappings/ACEP_mappings/measurement.md new file mode 100644 index 0000000..eb9bdd8 --- /dev/null +++ b/mappings/ACEP_mappings/measurement.md @@ -0,0 +1,32 @@ +## Table name: measurement + +### Reading from result_observation.csv + +![](md_files/image7.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| measurement_id | | | This will be generated for each unique result of observatio/measurement if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used
| +| measurement_concept_id | observation_description | | The observation_description is the text description for Observation Code. This can used to derive the measurement_concept_id. Alternatively, if measurement_source_concept_id is a part of the OMOP vocabulary that can be used for mapping.
| +| measurement_date | result_date_time | | result_date_time is the date and time of the result/observation. The ETL convention specifies "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." Hence even though the date represents the result date it is the closest match for the measurement_date field. Date can be extracted from date time value. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| measurement_datetime | result_date_time | | result_date_time can be stored directly in measurement_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| measurement_time | result_date_time | | measurement_time can be extracted from result_date_time. The standard format is not specified in the dictionary this has to be checked when we get the data
| +| measurement_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| operator_concept_id | | | | +| value_as_number | result_value | | result_value is the documented value/result. It can be stored in value_as_number as the data type here seems to be float/integer. In case not a numeric value, this might need investigation.
| +| value_as_concept_id | result_flag_description | | result_flag_description is the text description of the Result Flag. As it is a description field it can be used to derive the value_as_concept_id.
| +| unit_concept_id | result_unit | | The result unit can be used to map the unit_concept_id.
| +| range_low | normal_range_low | | Lower limit of normal result range, can be directly stored as range_low. It should have same unit as value_as_number.
| +| range_high | normal_range_high | | Upper limit of normal result range, can be directly stored as range_high. It should have same unit as value_as_number.
| +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the measurement table.
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurrence table. This can be mapped back to the the visit_source_value/visit_occurrence_id of the person table depending on the logic used.
| +| visit_detail_id | | | | +| measurement_source_value | observation_description | | It is the text description for the observation Code. This can be stored directly as measurement_source_value.
| +| measurement_source_concept_id | observation_code | | It is the standard code that describe the observations of the results of laboratory orders, imaging procedures, and other studies. This can be directly mapped to measurement_source_concept_id.
| +| unit_source_value | result_unit | | The result unit can be directly stored as the unit_source_value.
| +| unit_source_concept_id | | | | +| value_source_value | result_flag_description | | result_flag_description is the text description of the Result Flag. As per ETL specification the field being used to generate the value_as_concept_id should be stored in the value_source_value.
value_source_value will always contain the field that is being used to generate the value_as_concept_id | +| measurement_event_id | order_id | | At source this order_id along with patient_id and encounter_id will be the keys for the Orders table, and hence a relationship is established. As per the OMOP guide "If the Measurement record is related to another record in the database, this field is the primary key of the linked record". Hence as there is no other field, this can be used to directly map to the target table for the "Orders" table from ACEP. (most likely the procedure_occurrence table on OMOP, hence this should contain corresponding procedure_id)
| +| meas_event_field_concept_id | | | It should record the concept_id for the table whose primary_key is being added to measurement_event_id (most likely procedure_occurrence table in this case) | + diff --git a/mappings/ACEP_mappings/observation.md b/mappings/ACEP_mappings/observation.md new file mode 100644 index 0000000..bceaffa --- /dev/null +++ b/mappings/ACEP_mappings/observation.md @@ -0,0 +1,58 @@ +## Table name: observation + +### Reading from family_history.csv + +![](md_files/image5.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| observation_id | | | This will be generated for each unique observation if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table. This can be mapped back to the the visit_source_value/visit_occurrence_id of the person table depending on the logic used.
| +| observation_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| observation_concept_id | family_history_observed_value | | family_history_observed_value is the unstructured/non-standard family history documentation. This can used to derive the observation_concept_id. Alternatively, if the observation_source_concept_id is a part of the OMOP vocabulary that can be used for mapping.
| +| observation_source_concept_id | family_history_type_code | | family_history_type_code has SNOMED CT code representing family medical history hierarchy. This can be directly mapped to observation_source_concept_id.
| +| observation_source_value | family_history_observed_value | | family_history_observed_value is the unstructured/non-standard family history documentation. This can be stored directly as observation_source_value.
| +| observation_date | family_history_documentation_date_time | | family_history_documentation_date_time is the date and time when the family history is recorded. The date element can be extracted and stored in observation_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| observation_datetime | family_history_documentation_date_time | | family_history_documentation_date_time is the date and time when the family history is recorded. This can be stored in observation_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data. | +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the observation table.
| +| value_as_string | | | | +| value_as_number | | | | +| value_as_concept_id | | | | +| qualifier_concept_id | | | | +| unit_concept_id | | | | +| visit_detail_id | | | | +| unit_source_value | | | | +| qualifier_source_value | | | | +| value_source_value | | | | +| observation_event_id | | | | +| obs_event_field_concept_id | | | | + +### Reading from social_history.csv + +![](md_files/image6.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| observation_id | | | This will be generated for each unique observation if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table. This can be mapped back to the the visit_source_value/visit_occurrence_id of the person table depending on the logic used.
| +| observation_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| observation_concept_id | social_history_observed_value | | social_history_observed_value is the unstructured/non-standard social history documentation. This can used to derive the observation_concept_id. Alternatively, if the observation_source_concept_id is a part of the OMOP vocabulary that can be used for mapping.
| +| observation_source_concept_id | social_history_type_code | | social_history_type_code has standard code representing social history. This can be directly mapped to observation_source_concept_id.
| +| observation_source_value | social_history_observed_value | | social_history_observed_value is the unstructured/non-standard social history documentation. This can be stored directly as observation_source_value.
| +| observation_date | social_history_documentation_date_time | | social_history_documentation_date_time is the date and time when the social history is recorded. The date element can be extracted and stored in observation_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| observation_datetime | social_history_documentation_date_time | | social_history_documentation_date_time is the date and time when the social history is recorded. This can be stored in observation_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
family_history_documentation_date_time is the date and time when the family history is recorded. This can be stored in observation_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data. | +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the observation table.
| +| value_as_string | | | | +| value_as_number | | | | +| value_as_concept_id | | | | +| qualifier_concept_id | | | | +| unit_concept_id | | | | +| visit_detail_id | | | | +| unit_source_value | | | | +| qualifier_source_value | | | | +| value_source_value | | | | +| observation_event_id | | | | +| obs_event_field_concept_id | | | | + diff --git a/mappings/ACEP_mappings/person.md b/mappings/ACEP_mappings/person.md new file mode 100644 index 0000000..5d007fb --- /dev/null +++ b/mappings/ACEP_mappings/person.md @@ -0,0 +1,27 @@ +## Table name: person + +### Reading from patient.csv + +![](md_files/image1.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| person_id | patient_id | | If all the patient_id are integers then it could directly be used as a person_id, but if they are strings, the patient_id would go to person_source_value and the person_id will have to be generated.
| +| gender_concept_id | patient_gender | | The gender_concept_id would have to be mapped from the concept table. The description to be mapped would be coming from patient_gender/gender_source_value. This logic can be derived once we have the data.
| +| year_of_birth | patient_date_of_birth | | year_of_birth will be extracted from patient_date_of_birth which is represented as yyyy-mm-dd
| +| month_of_birth | patient_date_of_birth | | month_of_birth will be extracted from patient_date_of_birth which is represented as yyyy-mm-dd
| +| day_of_birth | patient_date_of_birth | | day_of_birth will be extracted from patient_date_of_birth which is represented as yyyy-mm-dd
| +| birth_datetime | | | | +| race_concept_id | patient_race | | The race_concept_id would have to be mapped from the concept table. The description to be mapped would be coming from patient_race/race_source_value. This logic can be derived once we have the data.
| +| ethnicity_concept_id | patient_ethnicity | | The ethnicity_concept_id would have to be mapped from the concept table. The description to be mapped would be coming from patient_ethnicity/ethnicity_source_value. This logic can be derived once we have the data.
| +| location_id | | | | +| provider_id | | | | +| care_site_id | service_location_id | | service_location_id is is the unique identifier for the encounter place of service.It has to be mapped to the care_site_source_value/care_site_id in care_site_table.
| +| person_source_value | patient_id | | The original patient_id from the source would go to person_source_value.
| +| gender_source_value | patient_gender | | The patient_gender can be directly stored in gender_source_value
| +| gender_source_concept_id | | | | +| race_source_value | patient_race | | The patient_race can be directly stored in race_source_value
| +| race_source_concept_id | | | | +| ethnicity_source_value | patient_ethnicity | | The patient_ethnicity can be directly stored in ethnicity_source_value
| +| ethnicity_source_concept_id | | | | + diff --git a/mappings/ACEP_mappings/procedure_occurrence.md b/mappings/ACEP_mappings/procedure_occurrence.md new file mode 100644 index 0000000..d4e0fe2 --- /dev/null +++ b/mappings/ACEP_mappings/procedure_occurrence.md @@ -0,0 +1,25 @@ +## Table name: procedure_occurrence + +### Reading from encounter_procedure.csv + +![](md_files/image11.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| procedure_occurrence_id | | | This will be generated for each unique procedure if not given in the source table. | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used.
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table.
| +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the observation table. In the source data if npi is not unique, care_site_id can act as an additional identifier, this will be corresponding to the service_location_id.
| +| procedure_source_concept_id | procedure_code | | procedure_code represents the standard code for the procedure followed and can be directly mapped to procedure_source_concept_id.
| +| modifier_concept_id | procedure_code_modifier | | procedure_code_modifier contains any additional modifiers to the standard code for the procedure followed and can be used to derive the modifier_concept_id.
| +| modifier_source_value | procedure_code_modifier | | procedure_code_modifier contains any additional modifiers to the standard code for the procedure followed and can be directly mapped to modifier_source_value.
| +| procedure_concept_id | procedure_description | | procedure_description has the textual description for the procedure followed. It can be used to derive the procedure_concept_id. Alternatively, if the procedure_source_concept_id follows OMOP accepted standard vocabulary, it can be used for the mapping.
| +| procedure_source_value | procedure_description | | procedure_description has the textual description for the procedure followed. It can be stored as procedure_source_value.
| +| procedure_date | procedure_date_time | | procedure_date_time is the date and time for the procedure. The date element can be extracted and stored in procedure_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| procedure_datetime | procedure_date_time | | procedure_date_time is the date and time for the procedure and can stored in procedure_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| procedure_end_date | | | | +| procedure_end_datetime | | | | +| procedure_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| quantity | | | | +| visit_detail_id | | | | + diff --git a/mappings/ACEP_mappings/source_appendix.md b/mappings/ACEP_mappings/source_appendix.md new file mode 100644 index 0000000..423c626 --- /dev/null +++ b/mappings/ACEP_mappings/source_appendix.md @@ -0,0 +1,168 @@ +# Appendix: source tables + +### Table: patient.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | VARCHAR | SMH3467 | | +| patient_mrn | VARCHAR | SMH3467 | MRN refers to a medical record number, it can be used as the person_id if in the data the MRN is unique for all the individuals. | +| patient_ssn | VARCHAR | 8989-3456-787 | Should be NULL | +| patient_first_name | VARCHAR | Thomus | Should be NULL | +| patient_last_name | VARCHAR | Bogle | Should be NULL | +| patient_gender | VARCHAR | Male | | +| patient_date_of_birth | DATE | 1999-12-30 | | +| patient_date_of_death | VARCHAR | NULL | Mapped to death table | +| patient_race | VARCHAR | white | | +| patient_ethnicity | VARCHAR | Non-Hispanic | | +| patient_language | VARCHAR | English | There are no specific fields present in the CDM. This would have to be passed as NULL. | +| service_location_id | INT | 786353893 | | +| service_location_name | VARCHAR | City Hospital | The service_location_id corresponding to the care_site_id will map it to the care_site_table | +| payer_id | INT | 1112 | payer_id is the unique identifier number assigned to the insured person’s insurance company. Ideally it should have a corresponding field to map it to the billing data table, but this cannot be derivied from the information provided in the data dictionary. | + +### Table: location.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| service_location_id | INT | 848383005 | The location id has to be generated | +| service_location_name | VARCHAR | Smile Hospital | | +| service_location_street_address | VARCHAR | 100 Country Road | | +| service_location_city | VARCHAR | London | | +| service_location_state | VARCHAR | Texas | | +| service_location_zip_code | VARCHAR | 75261 | | + +### Table: family_history.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | VARCHAR | 121212 | | +| encounter_id | INT | 101 | | +| family_history_type_code | INT | 266919005 | | +| family_history_type_description | VARCHAR | no one in family ever had AIDs | family_history_type_description contains the text description for Family History Type Code. As this is directly mapping to the concept table through the concept_source_value_id, this description is not required additionally. However, the data needs to be inspected again to derive to this conclusion. | +| family_history_observed_value | VARCHAR | no_use_of_tobacco | | +| family_history_documentation_date_time | VARCHAR | 2014-11-17 9:20:00 | | +| service_provider_npi | INT | | | +| service_provider_first_name | VARCHAR | Ahmed | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | White | This has to be deidentified. Pass as NULL. | +| onset_date | DATE | 2006-09-14 | There is not specific mapping present for the field. Observation period does not accept values from family or clinical history. | +| service_location_id | INT | 848383005 | This will be the care_site_source_value/care_site_id (based on logic) linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | +| service_location_name | VARCHAR | Smile Hospital | This will be care_site_name mapping to the care_site_id linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | + +### Table: social_history.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | VARCHAR | 121212 | | +| encounter_id | INT | 101 | | +| social_history_type_code | INT | 266919005 | | +| social_history_type_description | VARCHAR | neved smoked | social_history_type_description contains the text description for Social History Type Code. As this is directly mapping to the concept table through the concept_source_value_id, this description is not required additionally. However, the data needs to be inspected again to derive to this conclusion. | +| social_history_observed_value | VARCHAR | no_use_of_tobacco | | +| social_history_documentation_date_time | VARCHAR | 2019-12-19 11:00:00 | | +| effective_start_date | DATE | 2019-12-17 | There is not specific mapping present for the field. Observation period does not accept values from family, social or clinical history. | +| effective_stop_date | DATE | 2019-12-18 | There is not specific mapping present for the field. Observation period does not accept values from family, social or clinical history. | +| service_provider_npi | INT | | | +| service_provider_first_name | VARCHAR | Ahmed | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | Mahmood | This has to be deidentified. Pass as NULL. | +| service_location_id | INT | 848383005 | This will be the care_site_source_value/care_site_id (based on logic) linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | +| service_location_name | VARCHAR | Smile Hospital | This will be care_site_name mapping to the care_site_id linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | + +### Table: result_observation.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | VARCHAR | SMH3467 | | +| encounter_id | INT | 105 | | +| observation_code | VARCHAR | 10466-1 | | +| observation_description | VARCHAR | Anion gap 3 in Serum or Plasma | | +| result_code_set | VARCHAR | LOINC | This is the code set which is used in column Observation Code. It can be used to map the measurement_source_concept_id to the measurement_concept_id if part of OMOP vocabulary. | +| result_date_time | VARCHAR | 2020-04-12 | | +| result_value | INT | 4 | | +| result_flag | VARCHAR | N | result_flag is the standard observation interpretation code of the result field. It is not providing intutive conversion to a concept, the result_flag_description is a more suitable field for the same. | +| result_flag_description | VARCHAR | Normal | | +| normal_range_low | INT | 3 | | +| normal_range_high | INT | 10 | | +| result_unit | VARCHAR | mEq/L | | +| order_id | INT | 2576 | | +| result_order_description | VARCHAR | Basic metabolic panel | Text description of the result order will be present in the target for the orders table. | +| service_provider_npi | INT | 5555555555 | | +| service_provider_first_name | VARCHAR | James | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | Smith | This has to be deidentified. Pass as NULL. | +| service_location_id | INT | 848383005 | This will be the care_site_source_value/care_site_id (based on logic) linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | +| service_location_name | VARCHAR | Smile Hospital | This will be care_site_name mapping to the care_site_id linked to the visit occurence table or the person table through the primary keys of visit_occurence_id and person_id respectively. | + +### Table: encounter.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | VARCHAR | SMH3467 | | +| encounter_id | INT | 101 | | +| encounter_type_code | INT | 99283 | | +| encounter_type_code_modifier | INT | 25 | Modifiers consist of two digits (letters/numbers) that are appended to the 5-digit CPT code. The modifier does not change the CPT code but calls attention to special circumstances associated with the service or procedure that the patient received. These are mainly used for preparation of accurate billings. This is housed in modifier_source_value in the procedure_occurence table, but not in encounter table. Should be mapped accordingly if possible. | +| encounter_type_description | VARCHAR | Emergency department visit for the evaluation and management of a patient | | +| service_provider_npi | INT | 5555555551 | | +| service_provider_first_name | VARCHAR | Sam | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | Jones | This has to be deidentified. Pass as NULL. | +| arrival_date_time | VARCHAR | 2021-05-02 17:00:00 | This has been marked as an optional field, hence capturing encounter_start_date_time would be more granular, and fits with the OMOP definition- "In the case of an inpatient visit this should be the date the patient was admitted to the hospital or institution. In all other cases this should be the date of the patient-provider interaction." | +| encounter_start_date_time | VARCHAR | 2021-05-02 17:10:00 | encounter_start_date_time is preferred over the arrival_date_time to represent the visit_start_date. This is because the former represents "the date of the patient-provider interaction." and the later is an optional field at source. Arrival time doesn't acccurately represent the beginning of the patient provider interaction especially for billing and other hospital management purposes. | +| encounter_end_date_time | VARCHAR | 2021-01-01 22:40:00 | encounter_end_date_time and discharge_date_time have the same values in the examples. Discharge would better represent the end of a service provider-patient interaction. The OMOP ETL guideline states- "For inpatient visits the end date is typically the discharge date." Hence, by this definition the discharge_date_time should be the preferred field. In patients where discharge date time is not available, then we can consider using encounter_end_date_time. | +| service_location_id | INT | 786353893 | | +| service_location_name | VARCHAR | City Hospital | The service_location_id corresponding to the care_site_id will map it to the care_site_table | +| service_location_role_type_code | VARCHAR | UC | Represents the same information as service_location_role_type_description in a coded non standard vocabulary. can be dropped | +| service_location_role_type_description | VARCHAR | Emergency Department | The service_location_role_type_description corresponding to the care_site_id can be mapped to the place_of_service_source_value in the care_site_table. The same can be used to generate the place_of_service_concept_id. At source only the encounter table contains this information, hence should ideally be mapped. | +| encounter_status | VARCHAR | Active | encounter_status contains the status of the encounter, e.g., active, completed, pending. Unable to find a suitable field in any table on OMOP to map this information to. | +| discharge_disposition_description | VARCHAR | Admitted | | +| discharge_disposition_code | VARCHAR | ADM | discharge_disposition_code contains the code corresponding to discharge_disposition_description. No standard vocabulary has been given for the same hence discharge_disposition_description would be more intiutive for mapping. | +| discharge_date_time | VARCHAR | 2021-01-01 22:40:00 | encounter_end_date_time and discharge_date_time have the same values in the examples. Discharge would better represent the end of a service provider-patient interaction. The OMOP ETL guideline states- "For inpatient visits the end date is typically the discharge date." Hence, by this definition the discharge_date_time should be the preferred field. In patients where discharge date time is not available, then we can consider using encounter_end_date_time. | +| departure_date_time | VARCHAR | 2021-05-02 19:50:00 | This has been marked as an optional field, hence capturing discharge_date_time (preferred) or encounter_end_date_time (when discharge unavailable) would be more granular, and fits with the OMOP definition- "For inpatient visits the end date is typically the discharge date.". Departure date may include additional time (e.g waiting for transportation or other processess) between the patient being discharged from the encounter and actually leaving the care site. | + +### Table: encounter_diagnosis.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | INT | 18394792 | | +| encounter_id | INT | 105 | | +| encounter_diagnosis_code | VARCHAR | S09.90 | | +| encounter_diagnosis_code_description | VARCHAR | Head Injury | | +| diagnosis_code_set | VARCHAR | ICD10 | This is the code set which is used in encounter diagnosis code. It can be used to map the condition_source_concept_id to the condition_concept_id if part of OMOP vocabulary. | +| encounter_documentation_date_time | VARCHAR | 2021-01-01 18:45:00 | encounter_documentation_date_time is the date and time that the encounter diagnosis was documented. onset_date_time would better represent the condition_start_date as this is the date to determine the start date of the condition. This can be used alternatively if the onset date time is not provided. Depending on the data, the encounter date can also be derived from the observation table and visit occurrence table from corresponding visit_occurrence_id and person_id. | +| onset_date_time | VARCHAR | 2021-01-01 18:40:00 | | +| resolution_date_time | VARCHAR | 2021-01-01 22:40:00 | | +| service_provider_npi | INT | 5555555555 | | +| service_provider_first_name | VARCHAR | Linda | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | Smith | This has to be deidentified. Pass as NULL. | +| service_provider_role_code | VARCHAR | N | service_provider_role_code contains the code of the role of the provider. It can be mapped to the specialty_source_concept_id in the provider tabl by service_provider_npi/npi and service_location_id/care_site_id, as it is not provided in any other source table. | +| service_provider_role_description | VARCHAR | Nurse | service_provider_role_description contains the textual description of the role of the provider. It can be mapped to the specialty_source_value in the provider table by service_provider_npi/npi and service_location_id/care_site_id, as it is not provided in any other source table. specialty_concept_id will be derived from the same. | +| primary_diagnosis | VARCHAR | No | | +| service_location_id | INT | 848383005 | The condition occurrence table does not have a corresponding field for care_site_id in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables. | +| service_location_name | VARCHAR | Smile Hospital | The condition occurrence table does not have a corresponding field for care_site in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables, and hence the care_site_name. | + +### Table: encounter_patient_complaint.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | INT | 12374389 | | +| encounter_id | INT | 105 | | +| patient_complaint_description | VARCHAR | Superficial cut needing stitches | | +| patient_complaint_code | INT | 262526004 | | +| patient_complaint_code_set | VARCHAR | SNOMED | patient_complaint_code_set reports the vocabulary used for patient_complaint_code. If it is OMOP accepted vocabulary, condition_source_concept_id can be used for mapping the condition_concept_id. | +| patient_primary_complaint | VARCHAR | Yes | | +| patient_complaint_documentation_date_time | VARCHAR | 2021-01-01 16:40:00 | | +| service_location_id | INT | 848383005 | The condition occurrence table does not have a corresponding field for care_site_id in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables. | +| service_location_name | VARCHAR | Smile Hospital | The condition occurrence table does not have a corresponding field for care_site_name in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables, hence the care_site_name. | + +### Table: encounter_procedure.csv + +| Field | Type | Most freq. value | Comment | +| --- | --- | --- | --- | +| patient_id | INT | 121212 | | +| encounter_id | INT | 105 | | +| service_provider_npi | INT | 5555555555 | | +| service_provider_first_name | VARCHAR | Linda | This has to be deidentified. Pass as NULL. | +| service_provider_last_name | VARCHAR | Smith | This has to be deidentified. Pass as NULL. | +| procedure_code | INT | 31500 | | +| procedure_code_modifier | INT | 51 | | +| procedure_description | VARCHAR | Endotracheal Intubation | | +| procedure_code_set | VARCHAR | CPT | procedure_code_set contains vocabulary followed for the procedure_code. If it follows OMOP accepted standard vocabulary, procedure_source_concept_id can be used for the mapping. | +| procedure_date_time | VARCHAR | 2022-01-01 18:35:00 | | +| service_location_id | INT | 848383005 | The procedure occurrence table does not have a corresponding field for care_site_id in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables | +| service_location_name | VARCHAR | Smile Hospital | The procedure occurrence table does not have a corresponding field for care_site in it. The person_id and visit_occurrence_id should ideally be able to link to the the care_site_id from person and visit_occurrence tables, and hence the care_site_name. | + diff --git a/mappings/ACEP_mappings/visit_occurrence.md b/mappings/ACEP_mappings/visit_occurrence.md new file mode 100644 index 0000000..1feb5f2 --- /dev/null +++ b/mappings/ACEP_mappings/visit_occurrence.md @@ -0,0 +1,26 @@ +## Table name: visit_occurrence + +### Reading from encounter.csv + +![](md_files/image8.png) + +| Destination Field | Source field | Logic | Comment field | +| --- | --- | --- | --- | +| person_id | patient_id | | The patient_id is the primary key linking all tables. This can be mapped back to the the person_source_value/person_id of the person table depending on the logic used
| +| visit_occurrence_id | encounter_id | | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table. If all the encounter_id are integers then it could directly be used as a visit_occurrence_id, but if they are strings, it will have to be generated. This should be consistent across all tables as it is used as a foreign key across tables.
| +| visit_source_concept_id | encounter_type_code | | encounter_type_code is the CPT code used to indicate the Evaluation and Management (E/M) or Critical Care services coded for the specific encounter. Can be stored directly as visit_source_concept_id
| +| visit_concept_id | encounter_type_description | | encounter_type_description contains the text description for the Encounter Type Code. It can be used to derive the visit_concept_id. Alternatively, if visit_source_concept_id is a part of the OMOP vocabulary that can be used for mapping.
| +| visit_source_value | encounter_type_description | | encounter_type_description contains the text description for the Encounter Type Code. It can be directly stored as the visit_source_value.
| +| provider_id | service_provider_npi | | The service_provider_npi is the unique NPI for the clinician providing the encounter services. This will map to npi in provider table, the provider_id is the primary key for it which can be added to the visit occurrence table.
| +| visit_start_date | encounter_start_date_time | | encounter_start_date_time contains the date and time when the clinician encounter with the patient begins. The date element can be extracted and stored in visit_start_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| visit_start_datetime | encounter_start_date_time | | encounter_start_date_time contains the date and time when the clinician encounter with the patient begins. This can be stored in visit_start_datetime. The standard format is not specified in the dictionary and has to be checked when we get the data.
| +| care_site_id | service_location_id | | service_location_id is is the unique identifier for the encounter place of service.It has to be mapped to the care_site_source_value/care_site_id in care_site_table.
| +| discharged_to_concept_id | discharge_disposition_description | | discharge_disposition_description contains text description of the disposition status of the patient following the particular encounter, e.g. if the patient was admitted after being discharged from the ER. This can be used to derive the discharged_to_concept_id.
| +| discharged_to_source_value | discharge_disposition_description | | discharge_disposition_description contains text description of the disposition status of the patient following the particular encounter, e.g. if the patient was admitted after being discharged from the ER. This can be directly stored as discharged_to_source_value.
| +| visit_end_date | discharge_date_time | | discharge_date_time contains the date and time when the patient was discharged from the encounter. The date element can be extracted and stored in visit_end_date. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| visit_end_datetime | discharge_date_time | | discharge_date_time contains the date and time when the patient was discharged from the encounter. This can bestored in visit_end_datetime. The standard format is not specified in the dictionary this has to be checked when we get the data.
| +| visit_type_concept_id | | | This has to be mapped to the respective Type Concept. Needs more investigation. | +| admitted_from_concept_id | | | | +| admitted_from_source_value | | | | +| preceding_visit_occurrence_id | | | This field can be used to link a visit immediately preceding the current visit, this can be calculated using the patient_id and visit_start_date. | +