The challenge i am having is about creating the reminder to search an OpenEMR table as a criteria is not working well. i set the table to form_encounter and the column to encounter category id.
Anyone done something similar in the past? Need suggestions.
Hi @kkappiah
CDRs are very very tricky, the logic of the rules is inconsistent and not clear at all.
Here’s a set of wiki pages that is the best I’ve seen at describing how to create rules. It was written for OpenEMR v5 but I’m pretty sure CDRs have not changed since then.
And here’s a search of the OpenEMR wiki for ‘reminder’ which will return some unwanted pages but the clinical reminders are in there also. Some useful info has been written on CDRs back in the v4.x days.
Hi Kofi @brady.miller and I recently completed an extensive update to the logic in the rules engine. First step for you is to make sure you have the latest clinical reminders code (especially library\clinical_rules.php) (but other files have been updated as well to get the required/optional labels to make sense). You will need to get this from github GitHub - openemr/openemr: The most popular open source electronic health records and medical practice management solution.
Re: using a “custom” filter or target that looks at the form_encounter table, that sounds like a plan that should work well. Please reply with your rule configuration and I’ll see if I can tell why it is not working
Thanks
– Hank
Hi @hanksterr7 It’s great news that the Reminders is being updated. Do you have any guesses when it will get into a demo to be played with, and/ or somebody writes up the new usage for non- devs?
Hopefully- Harley
@kkappiah , I do not see anything wrong with the way you are using a “custom table” - type filter. As a first step, please install the latest patch to openEMR, that has the updated Clinical Reminder logic. Note that the new code fixes the yes/no choce labeling for the Optional item. Now, optional: yes really does mean “optional”. Previously, the labels were reversed. “custom table” filters require the target table to have a “pid” column and a “date” column. I checked and form_encounter has these two fields. Please provide screenshots of the other parts of your rule (i.e. the intervals, the demographic filters if any, and the rule action (assumimg the rule you provided is the rule target). Thanks
Ok, I found the issue
For filters based on “custom table” for form_encounter, the code actually generates a query like this:
SELECT b.pc_catid
FROM forms a
LEFT JOIN form_encounter b
ON (a.form_id=b.id AND a.formdir LIKE ‘encounter’)
WHERE a.deleted != ‘1’
AND b.pc_catid=?
AND b.pid=?
AND (b.date BETWEEN DATE_SUB(‘2024-04-04 10:51:46’, INTERVAL 6 MONTH) AND ‘2024-06-04 10:51:46’)
It decides to build this complex sql based on finding ‘form_’ contained in the name of the custom table, and then uses what comes after ‘form_’ as the a.formdir value to be searched for (hence, for form_encounter, it expects formdir to be ‘encounter’)
It does this to determine whether a form instance has been deleted, and to know this, it has to look in the forms table
For the form created for a new encounter, its formdir is “newpatient” (as can be seen by looking in the forms table). So assuming formdir is the string following form_ can be problematic
The solution is to create a sql view that executes what you want, and making sure your view does not contain ‘form_’ in the view name
This is an example that worked for me
create view v_frm_encounter_hank AS
select a.pid,b.date,b.pc_catid
from forms a
join form_encounter b on a.form_id=b.id and a.formdir=‘newpatient’
where a.deleted != ‘1’;
Then, have your custom table-based filter reference v_frm_encounter_hank
btw, where id you find the encounter category defined? I did not see it in Lists
