Clinical Rules and Reminders - improper calculation of demographic filters when applied to db lookups

[hanksterr7]

Demographic filters specify features a patient needs to have in order for the rule to be applicable to the patient.

A variety of types of features can be examined, including age, gender, entries from the "lists" tables such as allergies and medications, as well as entries from custom tables and the rule_patient_data table

Filter configuration does not offer a way to specify date intervals when looking at these features. They are instead considered present or absent, regardless of when there were deemed present in a patient. Gender is obviously present for life. But being a smoker is applicable over some portion of a patient's life

However, the logic for evaluating filters DOES include a check against a $dateTarget value. $dateTarget is compared against the timestamp of the feature, and if the feature is not prior to $dateTarget , the feature is deemed to not be present and the rule is deemed not applicable to the patient

The logic happens in clinical_rules.php, test_filter(), and is related to processing of rule targets

When both rule filters and rule targets are defined (as is frequently the case), processing occurs as follows:
-- determine three $dateTarget values: now + rule warning value, now, and now - past due value
-- for each $dateTarget, evaluate whether the filter criteria are satisfied. If they are:
-- -- evaluate the target criteria are satisfied to determine the target status (not due, due soon, due, past due)

Filter evaluation is affected by the $dateTarget value (and should NOT be)

The problem happens when all of these are true:
-- when $dateTarget is now - past due value
-- when the filter feature has a timestamp
-- when the feature timestamp for a patient is somewhere between (now - past due interval) and now

Example:
-- rule: warning: 1 month, past due: 4 months
-- filter: measurement - mammogram has been done at least once
-- target: education - smoking has been done at least once in the past 6 months, action: education - smoking
-- measurement - mammogram was last done on a patient 2 months ago
-- education - smoking was last done on a patient 12 months ago

The expected status for education - smoking would be "past due" since
-- the mammogram has been done, so the rule is applicable to the patient
-- the education - smoking was done more than 10 months ago

The observed status for eduction - smoking is "due" since
-- when evaluating $dateTarget = now + 1 month, there is a mammogram prior to this timestamp, and there is no eduction - smoking found between 5 months ago and 1 month from now -> status temporarily is "due soon"
-- when evaluating $dateTarget = now, there is a mammogram prior to this timestamp, and there is no eduction - smoking found between 6 months ago and now -> status temporarily is changed to "due"
-- when evaluating $dateTarget = now - 4 months, there is no mammogram prior to this timestamp. Evaluation of the target is skipped, since the rule is considered not applicable to the patient, and the previously established status of "due" is kept

If in the above example, the timestamp of the mammogram is changed to 5 months ago, the status of education - smoking becomes "past due". With this change, when $dateTarget is now - 4 months, the filter passes, and evaluation of the target is performed (and fails), so the status becomes "past due"

The solution to this is to use $dateTarget = now when evaluating filters, regardless of the $dateTarget value being used to evaluate targets.

This is done by replacing
// Set date to current if not set
dateTarget = ($dateTarget) ? $dateTarget : date('Y-m-d H:i:s');

with
dateTarget = date('Y-m-d H:i:s');
at the top of test_filter()

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[sjpadgett]

bump

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[stephenwaite]

looking forward to bringing this is soon

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[stephenwaite]

bump

[stale]

This issue has been automatically marked as stale because it has not had any recent activity within the past 90 days. It will be closed in 7 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity within the past 97 days.