A query should be able to run if it contains at least an analyte

[WiseIndian]

• The user currently has to drag and drop the term from the ontology (e.g.: Height) both in the Analytes section and the Criteria selection. For Swiss BioRef: Including the “analyte” (e.g. sodium) in the cohort definition should not be required.

• The “run” button only turns blue (= available) if both an analyte and criteria are selected. As previously discussed, there needs to be preloaded (and “empty”) cohort criteria of AdministrativeSex, Age and other predetermined conditions for an easier UX. These concepts should be set to “any” or “all” by default. The user then only has to drag and drop the analyte (e.g. sodium) from the ontology for an analysis.

For the moment a user needs to specify at least one element in both sections (cohort definition and analytes sections) for the query to be the run. We could change the rule specifying when a query can be run to: a least an analyte has been selected.

This requires changes on the backend. For the moment when a query is created a first step is to select the patients identifiers which are parts of the population defined by the cohort definition. In the case where no cohort definition is present within one query:

• We would need to skip the calls made to i2b2 to retrieve the patients corresponding to the cohort defintion
• We would need to add a new condition which would remove the sql clause filtering the query results on the cohort defintion: const sqlCohortFilter = AND patient_num = ANY($3::integer[]) ``

Some changes need to be applied on the front-end:

• Remove the condition stating that at least one element has to be added to the list of element defining a cohort definition.

[WiseIndian]

Another solution could be to fill by default the cohort definition with the root concept. The advantage is that it simplifies the development (no need to modify the back end). The disadvantage is that it might run slowly. Normally the statistics query executes two queries on the backend side: the i2b2 query fetching patients conforming to the cohort definition and a second query fetching observations matching the analytes and the patients fetched from the i2b2 query. If we send the root concept to the backend as the cohort definition the patient list linked to the cohort definition might be enormous. This would make the query unoptimal as the where clause of the query fetching observations would filter based on the patient num list corresponding to all patients in the database.

[Fasjul]

What about filling by default the cohort definition with the analyte itself? i2b2 will in any case only fetch results for patients who have such a result.

[WiseIndian]

That's a great idea. Maybe not the most optimal one, but that will greatly reduce development time and satisfy everyone.

[Fasjul]

Update: after discussion we believe that the analyte should be added to the cohort definition with the following options:

1. The Analytes are bound to each other with an OR. This forms the Analyte group.

   Motivation: If we have two analytes, using an OR is the only way to have the Analytes in the query definition without having them interacting negatively with each other.

2. The Analytes group is bound to the rest of the query with an AND.

   Motivation: speeding up the "fetching patients conforming to the cohort definition" step by restricting it to patients that have a result to bring.

3. Each analyte is bound with an AND with option "same instance" on elements that are related to the same Concept as the analyte is.

   Motivation: Allows to filter on the other options such as test kit. Alternative 1: Change the i2b2/GB logic so the "same instance" is smarter and never yields 0 for heterogeneous concept selection. Use "same instance" by default. Alternative 2: distribute the analytes to the cohort selection panels. Potentially duplicate the panels... To investigate.