tested out the code, appears to have it fixed! thank you
Thanks!
Was what I found a known issue? The discussion above wasn’t really focused on the issue I found (i.e. the fact that, at least for rule logic applied to custom targets, the rule evaluation status calculation was not producing expected results).
I will do some more testing, with other types of targets and with multiple targets in a rule, to make sure everything is now behaving as expected.
Hi Stephen,
I read the contributing guide but I admit I am quite confused. I’m new to using github (although I’m a long time programmer)
I forked the openemr project (creating hanksterry/openemr) and edited clinical_rules.php in my fork, and click commit at the bottom of the page. I see my changes in the version in my fork, and they are not in the openemr/openemr version
(so I assume I didn’t do anything harmful to the main branch).
I don’t see a way to make additional edits to the file. The “edit” button is ghosted, and says “you must be on a branch to make or propose changes to this file”
I already had a local copy of the code, so I didn’t see a reason to do the Docker stuff. I just wanted to edit the verison of the file in my fork (which I did).
Wasn’t sure what to do after clicking “pull request”
Is there a simple set of steps I can follow to document my issue and share the patch code that has been generated so it can be reviewed/incorporated into the main branch?
Thanks for your assistance
– Hank
hello @hanksterr7, thanks for following through on this, did you checkout
https://www.open-emr.org/wiki/index.php/Git_for_dummies
Ok, will take a look
Hi Stephen,
I’m working my way through Git for dummies. Is quite good. Thanks
I’ve fixed a few other issues with rules, and it looks like you document work on bugs in Git, rather than in the openEMR community items
How do I start a new discussion, so I can post the issues, and fixes, I’m working on? (if that is covered in Git for dummies, you can tell me)
Additional things I’ve found and fixed:
– required/optional flag for rule targets is backwards (this has been known for years, per comments I’ve seen posted). I could fix this, but then all existing rules would need to be updated, changing switching 0 for 1 (and vice versa)
in the rule_target table. Not sure how to do that db update as part of a patch
– required/optional flag is ignored for demographic filters. All are treated as required (I don’t have a fix for this. Requires cloning code used for rule target processing into the rule filtering processing)
– Demog filters that do date calculations can be messed up (including age calculations). This is because test_filter() is called for each of the three $date_target values when processing every rule. Scenario:
Rule clinical criteria: warn – 1 month, past due – 3 months
Demog filter of type “custom” exists for Measurement – Mammogram completed at least once
Rule target of type “custom” exists for Education – Ophthalmic completed at least once in past 6 months
Suppose Measurement – Mammogram has been recorded as completed 2 months ago, and Education – Ophthalmic has been recorded as completed 10 months ago
Rule will show as “due” instead of “past due”
This is because:
– test_filter() is called 3 times, once for $date_target = (now + 1 month), once for now, and once for (now – 3 months)
On the first call, a check for existence of Measurement – Mammogram prior to (now + 1 month) is done and succeeds. Next, the check for Education – Ophthalmic completed between ((now + 1 month) – 3 months)
and (now + 1 month) is done and fails. Rule status so far is set to soon_due
On the second call, a check for existence of Measurement – Mammogram prior to (now) is done and succeeds. Next, the check for Education – Ophthalmic completed between ((now) – 3 months) and (now) is done
and fails. Rule status changed to “due”
On the third call, a check for existence of Measurement – Mammogram prior to (now – 3 months) is done and fails. This stops the rule processing, leaving the status as “due”, when really it should be past_due.
I can not think of a reason why the existing of Measurement – Mammogram prior to (now – 3 months) should have been checked, rather than the existence of Measurement – Mammogram prior to (now). Similarly, I can’t think of a reason why test_filter() should want
to know the three $date_target values, rather than just working against “now”. If there is a reason you can think of for this, please share.
I changed the code (my version) so all three passes through test_filter() use (now) rather than the three different $date_target values, and that caused the desired rule status to be generated. This change affected only the filter testing,
not the target testing (i.e. test_targets() ). The targets are still checked against each of the three $date_target values
Again, all of this needs to be documented so this can be discussed for agreement on the appropriate fix. Please advise how to do this
Thanks
- Hank
hi @hanksterr7, haven’t had a chance to review your full post but go ahead and create a new issue, Issues · openemr/openemr · GitHub, and you will get a lot of good advice there if not here.
For those who stumble onto this thread, I’ve posted four issues with Clinical Rules and Reminders on the openEMR git hub site (along with fixes to the issues, requiring mods to clinical_rules.php)
With these changes, I believe Rules behaves in a predictable and effective manner. Issues addressed: required/optional choices being flipped, errors calculating optional demographic filters, and errors calculating target status in general, and when past due interval is greater than target interval
Links to these entries are:
I hope to contribute mods to clinical_rules.php for a future patch. But in the meantime, you can fix the code yourself by following the info in the posts.
I have been asked about this feature. I seem to have gotten into it again.
@brady.miller
Is there a road map for the rules engine to be brought current? If there is could you share it please?
I am pleased to report that all of the issues I found with the clinical rules module in v5 and 6 seem to be fixed in openEMR v7 
3 Likes