Description
Currently the Data Query builder allows restricting the data returned from certain tables. Having built the data pipeline of the SDE further, we have found that some of these tables have parent/child relationships. For example in the SDE currently, the schema hospital_events contains:
- a table
inpatient_encounter, primary key encntr_id
- a table
inpatient_encounter_slice, primary key encntr_slice_id, contains a foreign key reference to encntr_id on inpatient_encounter.
Similarly in the OMOP Common Data Model, there is:
- table
visit_occurence, primary key visit_occurrence_id
- table
visit_detail, primary key visit_detail_id, contains an FK to visit_occurence.visit_occurrence_id
Additional context
When a restriction is added on the inpatient_encounter table for example, it should also apply to inpatient_encounter_slice, by applying a new join/subquery. We should also think about how this is presented in the UI, e.g. could the child tables be listed indented under their parent tables in the browsing interface? Should some text appear in the query builder to inform the user of how the parent/child restriction is applied?
It may be that we will only ever have one layer of parent/child relationships, we should investigate if that's the case.
Description
Currently the Data Query builder allows restricting the data returned from certain tables. Having built the data pipeline of the SDE further, we have found that some of these tables have parent/child relationships. For example in the SDE currently, the schema
hospital_eventscontains:inpatient_encounter, primary keyencntr_idinpatient_encounter_slice, primary keyencntr_slice_id, contains a foreign key reference toencntr_idoninpatient_encounter.Similarly in the OMOP Common Data Model, there is:
visit_occurence, primary keyvisit_occurrence_idvisit_detail, primary keyvisit_detail_id, contains an FK tovisit_occurence.visit_occurrence_idAdditional context
When a restriction is added on the inpatient_encounter table for example, it should also apply to inpatient_encounter_slice, by applying a new join/subquery. We should also think about how this is presented in the UI, e.g. could the child tables be listed indented under their parent tables in the browsing interface? Should some text appear in the query builder to inform the user of how the parent/child restriction is applied?
It may be that we will only ever have one layer of parent/child relationships, we should investigate if that's the case.