Mappings for patient, family history, social history and location

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.<br> |
+| 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.<br> |
+| 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.<br> |
+| place_of_service_source_value |  |  |  |
+

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<br> |
+| visit_occurrence_id | encounter_id |  | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurence table.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br>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.<br> |
+| visit_occurrence_id | encounter_id |  | encounter_id is an identifier unique to the encounter. It is the primary key for the visit occurrence table.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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 |  |  |  |
+

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.<br> |
+| death_date | patient_date_of_death |  | The format of patient_date_of_death is not provided in the dictionary and has to be checked.<br> |
+| death_datetime |  |  |  |
+| death_type_concept_id |  |  |  |
+| cause_concept_id |  |  |  |
+| cause_source_value |  |  |  |
+| cause_source_concept_id |  |  |  |
+

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)
+

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<br> |
+| 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<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| county |  |  |  |
+| location_source_value |  |  |  |
+| country_concept_id |  |  |  |
+| country_source_value |  |  |  |
+| latitude |  |  |  |
+| longitude |  |  |  |
+

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<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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<br> |
+| 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.<br> |
+| 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.<br> |
+| unit_concept_id | result_unit |  | The result unit can be used to map the unit_concept_id.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| 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.<br> |
+| unit_source_value | result_unit |  | The result unit can be directly stored as the unit_source_value.<br> |
+| 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.<br>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)<br> |
+| 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) |
+