Aaron Berdofe, MHI – Health Informatics

For those who have made the attempt to implement the Ambulatory Order Management (AOM) module within MEDITECH and LSS Data Systems’s Medical and Practice Management Suite (MPM), one of the many common frustrations is that the system does not have the ability to require a diagnosis on a Lab or Rad order as part of its standard design. The solution given is to write a rule. Easy, right? If you’d like it to be easy, please follow the link to where I have posted the successful result of some frustrating work.

Unfortunately, you cannot simply write a rule that states if there is no diagnosis on this order, please pop up a message asking the user to apply one and don’t let them proceed until they do. The data is stored in such a way that there can be multiple diagnoses attached to a single order. No, you cannot see this if you are actually ordering and applying them, but they are there. Check out the View Detail section of the order after it is placed. This means that if you wrote a rule to check if a diagnosis was on an order, the rule would also need to know what diagnosis storage “slot” you wanted to check in as well. Of course the answer is “Any of them!!” but it’s also just as effective to check the first spot in the sequence.

Another quirk to this is the potential presence of multiple procedures being submitted at the same time. Each rule is enacted on each order placed. Therefore, if you have a message pop up in your rule and you are submitting three procedures, the message will need to be acknowledged three times! While, this might provide a perverse incentive for the user to make sure they have a dx on their order in the future, it is just not good design. Hence, the rule should note which procedures do not have a diagnosis, but only display the message for a missing diagnoses once. It should also display the names of the procedures in question to make it easier for the user.

Nearly last, the rule shouldn’t bother checking office procedures or injections. The visit diagnoses cover that and the point of the rule is to make sure the hospital sees the diagnoses. And finally, there’s a bug in Magic 5.6 that you’ll want to open a task for (of course!). I haven’t tested this in C/S or any other versions yet, but it would be wise to do so since the rule should work in all platforms and versions. If you submit a referral and add a diagnosis, the system does not store the dx in the same temporary location as procedures. But, if you highlight the referral after you’ve entered it and it appears under the New Orders header, click Diagnosis and add one, it files correctly. This means that the rule will catch every referral that is submitted until the bug is fixed. You could modify the rule so it ignores referrals as well as office procedures, but that is up to you.

There are two parts to putting this rule in. First, you will have to go into the Custom Defined Data Fields dictionary in AOM and create a data field under the Order function. This data field will do a lot of the work in discovering if a dx exists on the procedure, determining if the item it is evaluating is the last one so it can pop up the message or not and storing the procedure name if no diagnosis is found. I called the data field zord diagnosis, which is referred to in the actual rule. Second, create the rule in the AOM Rule dictionary to evaluate when the orders are filed. The rule was written in straight NPR so on pg. 4 enter “NPR” under the table field and paste it in.

Here is the link again to my Google Document with the rule. Please pass this around!

Update: The rule editor in C/S 5.6 doesn’t allow you to push data into the message prompt (functionality regression?) so you can only have the rule pop up for every single diagnostic that does not have a diagnosis.  Annoying, but it gets the job done.  The custom data field can remain the same, but here is the rule after you enter your prompt text in the Message field:

[f zord diagnosis],
IF{MSGPOP&LIST [ord pom](“DXREQUIRED”,1);IF{LIST “”;1}};

Where it says “DXREQUIRED”, the editor pushes all of your message text into a variable with the same name of your rule.  In my case, I called it DXREQUIRED.  Substitute whatever your mnemonic is.