Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

MEL_ADD_ORDER won't assign correct provider

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

8 Posts

2 Users

0 Reactions

65 Views

RSS

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

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

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

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

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

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

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

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

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

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

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

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

gibsonmi

(@gibsonmi)

Posts: 827

Prominent Member

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

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

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

24 Forums
9,940 Topics
39.9 K Posts
1 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed