Recently a C/S site posted a question to the Meditech-L mailing list about writing an OE/POM rule that was probably too complex to do with the rule editor itself.
This month we will discuss a method to change the code in the macro generated by the rule editor to add functionality in a way that the changes you make can be easily restored if the rule is rebuilt or refilled in the rule editor.
You may not realize it, but when you create a rule in OE in MAGIC or C/S, the rule editor creates a macro in a Customer NPR Report that you can pull up in the NPR Report Writer “Enter/Edit Macro” routine and edit the rule to obtain the functionality you need.
If your rule mnemonic is “IATRIC.LT” the macro will be called:
If you edit the macro with the Enter/Edit Macro routine to add functionality, all the changes you make will be lost if the rule is rebuilt or refilled. Since there is a “Rebuild Rules” option that rebuilds all rules in an application, and since MEDITECH sometimes recommends this be run after an update (or decides to run it themselves), there is a good chance that your work will be over-written at some point (when you least expect it).
Some programmers change the macro and also save their customized code in a different/separate report that will not get stepped on by “rebuild rules.” Then they can cut and paste their saved code back into the “real” macro that the rule editor generates (as this is the program called by the rule when it is executed).
A better way is to create a rule in the editor that can be fixed with just a minor edit on the NPR Report Writer side, including a comment that alerts you that the rule is broken so that it can get fixed right away.
In the rule editor, we create a warning message, and a quoted call to our own report macro as a program. We cannot call our own macro directly because this is blocked by the rule editor’s syntax checker, so putting quotes around the call means you can file the rule and only a small edit will change the macro so your own macro really does get called. We also include instructions on how to fix the rule that a support person will see both in the rule text in the rule dictionary and over in the macro created by the rule.
Here is what the rule should look like over in the rule dictionary:
We return a 1 because we want the rule always to be TRUE and allow the order to file. We could change this if we need the rule to actually prevent filing. The comment with the leading semicolon appears in the rule editor text, but does not appear in the macro produced by the rule editor when you file the rule.
With the rule as is, the user will see this message when placing an order:
You should then edit OE.ORD,zcus.ord.rule.M.iatric.lt (MAGIC) or OE.ORD.zcus.ord.rule.z.iatric.lt.0 (C/S) from this:
Now we create the report OE.ORD.zcus.is.ord.rule and add a macro called “check” so it can be called from the original macro in OE.ORD.zcus.ord.rule.M.iatric.lt
We then write a “check” macro as a program in this report to apply whatever special rule logic is needed. For this demonstration, we will just check the patient’s age in years and warn the user if they are ordering a drug screen on a patient under 10 years old.
Here is the code:
Note that the patient’s admission urn is passed in as the “A” argument to your macro and by putting it back into the local variable “patient” we can then get the birthdate and computed birthdate from ADM and calculate age in years.
Putting a semi-colon on the last line of the macro makes it a program, so that it can stand alone and be invoked from the rule like this %OE.ORD.zcus.is.ord.rule.M.check(A).
Here is what the warning looks like when you try to file an order on a patient under 10 years old:
This rule is probably simple enough to write in the rule editor, next month we will show how to write a complex macro that checks the patient’s primary insurance and lab history across visits to alert you if the patient has a particular insurance and 3 or more drug screens in the past 365 days.