Clinical Rules and Reminders - required/optional choices are reversed

hanksterr7 commented 4 years ago

The logic in clinical_rules.php is reversed in how it interprets the required_flag value in the rule_filter and rule_target tables

The tables indicate "0 is required and 1 is optional"

The rule display and editor php pages correctly interact with the tables. If you choose "optional: No" in the editor, the rule details display page will show "Characteristics: Required" and the table will contain required_flag: 0

However, the logic in clinical_rules.php does this in 3 places in database_check(), 1 place in procedure_check() and 1 place in lists_check()

          // If this is a required entry then return false
            if ($row['required_flag']) {
                return false;
            }

Since the filter/target are required if required_flag is zero, not one, the logic is incorrect

Negating the condition fixes the issue

This issue has apparently existed for years and is known to developers and users. They have been creating filters/targets that set required_flag=0 when they want "required", and 1 when they want "optional", as can be seen in the demographic filters for the Diabetes - Hemoglobin A1C reminder definition. These filters all show as "required", but they actually need to be treated as "optional", since the filter is checking to see if any of the listed ICD codes are applicable to the patient. Hence each of the filters needs to be treated as "optional", so that if any of listed ICD codes is found for the patient (and NOT all of the ICD codes), the rule is applicable to the patient.

If the code is changed as described above, all existing entries in the rule_filter and rule_target tables would need to have the state of the required_flag flipped (something that I imagine could be accomplished via sql_patch.php (but I don't now the process for causing a patch to include this db update step)

The alternative is to keep the above code in clinical_rules.php, and instead flip the meaning of the required_flag field in the tables, and change the UI so it flips what it writes to the tables in processing the "required: Yes/No" choice, and flips how it sets the state of the radio buttons on loading and how it displays the filter/target "characteristics". This would require touching many more places in the code.