Notifications
Clear all
Topic starter
We have created a custom order for use in house. I used MEL_ADD_ORDER and attached it to a button, so when the button is clicked, it automatically places the order. Here is my code:
MEL_ADD_ORDER("S", "RCP", "Discharge", "", "", "", "", "", "", "otcccc", "")
When the button is clicked, "otcccc" isn't placed as the authorized provider. Instead, it defaults to "Support, HealthCo". We have no idea why this would be happening. Has anyone seen this before?
Another tangentially related question: Has anyone used the userok error handling? Centricity help for MEL_ADD_ORDER specifically mentions that you can use a userok with a specific error code, but not how to actually use it. Do you put the code in the parens, so if I wanted to check that the auth provider was a real person, I'd write: userok(-8)?
Posted : April 14, 2017 4:43 am
Yes, we found this issue back in 2015, sometimes when we use MEL_ADD_ORDER() it ignores the provider and adds a different one. It is always the same one that it is replaced with. I captured it on a MEL trace once before where you could see a valid username going in and a different one coming back in ORDERS_NEW().
For the error handling its best to set up a separate function with a case statement. For example do
{orderError(MEL_ADD_ORDER())}
{fn orderError(code){
cond
case (code >=0)
return "success"
case (code == -1)
return userok("Error Message for code -1 here")
case ....
//add all of them
endcond
}}
Posted : April 14, 2017 6:53 am
Topic starter
Thanks for the reply. Is there no known fix for the auth provider issue? When you saw this happen, what was your workaround? Did you just train users to go edit the added order?
Regarding the error handling, do you know how it determines what code to give the function? I'm really curious about how this functionality works...
Posted : April 14, 2017 7:55 am
Topic starter
I just got off the phone with HealthCo. They said that this specific bug has been fixed in the 12.2 update, which we are currently gearing up for. There doesn't seem to be another easy fix.
I also took another look at the error handling, and I think I understand what you were saying. The function itself always returns a number in the background. If that number is negative, it corresponds to a specific error. Building out case statements, we can use that code to return specific error messages. Thanks for the insight on that.
Posted : April 14, 2017 9:19 am
Our users are having this problem when they add lab codes right away in a new encounter, they usually discard the document and it works the second time. The timing of the error seems to correspond to the bug where the ORDERS_NEW() function displays all historical orders. I think it would also 'fix' the issue just to put the document on hold and re-open it, but I'm not positive. We are on 12.2 and as far as I know its still an issue but I can check with our staff.
The error handling, that's it, it also returns a value, most of the MEL_ADD_.... () do the same thing, the only difference is some have 0 for success, others return the row id from the database.
Posted : April 16, 2017 11:55 pm
Topic starter
That would be great if you could let me know if you're still having that issue. Do you have any idea what brings it on? I haven't had this problem with ADD_ORDER before, but with this specific form, it's consistent.
Thanks for the clarification on the error handling as well. I think that will prove useful in the future.
Posted : April 17, 2017 3:06 am
I think this is actually resolved in 12.2. I asked some staff and they said they haven't noticed it lately. So I ran some SQL queries comparing order providers and document providers, and turns out there is a sharp decline in mismatches the same weekend we applied 12.2.
I'm pretty sure its just a workflow/timing issue. If you are planning on upgrading soon just wait and see if that takes care of it.
Posted : April 19, 2017 7:58 am
Topic starter
Thanks for looking into that. We're going to be upgrading in the next month or so, so hopefully this will go away and hopefully other users will benefit from this conversation.
Posted : April 19, 2017 10:54 am
