Notifications
Clear all
Topic starter
Hi,
We are having an issue with a custom form we are using to enter services (Superbill) where the user can attach Dx codes to services that they check off of listboxes. That part works appropriately where the Dx code(s) attach to the particular services. The Authorizing Provider either gets attached via selecting them from a listbox or will just default based on the user who is currently logged on.
The problem occurs when the user clicks a button on the form to send a flag to an MA or provider, that lists all of the services provided or that need to be provided. Once the MEL_SEND_FLAG functionality is used the Authorizing provider for all other patients, updates, etc... is someone random. The only way to correct is by completely exiting out of EMR.
Has anyone else seen this before?
Thanks
Dave Montgomery
Crozer-Keystone Health System
Posted : October 13, 2014 8:28 am
My first guess would be that you have a duplicate variable name in your code and when you invoke the MEL_SEND_FLAG, it is resetting a variable that is used elsewhere in your form.
Posted : October 13, 2014 10:21 am
Topic starter
There are no variables named the same thing, which is what I thought could be the issue at first. Even sending a flag in the same update using MEL_SEND_FLAG on one form, does not allow you to commit orders correctly via another form using MEL_ADD_ORDER.
It's definitely not something I have seen before. Completely exiting out of EMR is the only thing that corrects this.
Posted : October 15, 2014 3:58 am
Dave,
I have an active SR with GE about this issue (SR #1-363522911), which has been going on for 2 years. The problem happens in both Centricity EMR and CPS. I provided GE a video of it happening with quicktext and they have escalated it to their developers. They hope to have news for me this Wednesday.
The exact issue is once a user utilizes content that invokes the MEL_SEND_FLAG function, it corrupts the session where the MEL_ADD_ORDER function will ignore what you pass into the authorizing provider field (parameter 10) and utilizes a completely different authorizing provider. If you run an SQL trace in conjunction with a MELtrace, you will discover it does have the proper login name, but it uses that other person's PVID (for us it is consistently one PA.) Once you completely exit Centricity, the corruption is alleviated and the MEL_ADD_ORDER function will work properly again until you use the MEL_SEND_FLAG function again.
To alleviate this issue until GE has a resolution, you can either not use the MEL_SEND_FLAG function or leave the authorizing provider login name field (parameter 10) empty when invoking the MEL_ADD_ORDER function.
Hopefully I will have good news for you later this week. Please let me know if you have any questions.
Thanks,
Mike Baeske
Software Applications Specialist - Team Leader
Ortho NorthEast (ONE)
Posted : February 2, 2015 10:47 am
Topic starter
Thanks for the reply and information Mike.
I ended up simply removing the ability to enter the Authorizing Provider via the form.
If the MA starts the visit we just needed to make sure they were choosing the provider up front therefore the MEL_ADD_ORDER chose the provider and not themselves (MA etc..)
Thanks
Dave Montgomery
Posted : February 2, 2015 10:53 am
Dave,
We have taken a similar approach with 90% of our content, there are just a few workflows where passing in the authorizing provider is a necessity. Hopefully you can add that functionality back in the future.
Posted : February 2, 2015 11:01 am
Topic starter
Hey Mike,
Have you ever heard of a resolution from GE on this? I did log a defect ticket with GE as well just to see if there was any movement on this issue.
Dave
Posted : April 22, 2015 8:53 am
