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
One more point to make about this topic: For demographic filters, and rule targets, of type “custom table”, the rule system looks to see if “form_” is contained anywhere in the table name. Not just if the table name starts with “form_”. So you should avoid having “form_” anywhere in your custom table name, unless your are really working with the table associated with a true openEMR encounter-associated form, where the form’s php files live in a folder whose name matches what follows “form_” in the form’s table.
FYI I’m looking into this workflow in CDR. I’d like to see opening up scope on what custom table is and having actions such as allowing a form(Patient Document Template Forms) presentation to satisfy reminder action and so forth.
More or less in general adding capability to have free standing to patient Patient Document Template Forms. Much like