Notifications
Clear all
Topic starter
Hello and Happy Thanksgiving.
I'm troubleshooting a form that works as designed about 97% of the time. However, it occasionally hits a patient where the MEL programming pulls in incomplete data. I ran a MEL trace, and the trace shows things processing correctly until it gets to this error: ERROR: 32803 DATABASE NOT CHANGED. PLEASE TRY AGAIN
Does anyone know what this means?
The form builds some arrays and puts them into document variables so that they have to be run only once. Then further programming refers back to those document variables when extracting the data that needs to be displayed. But when this error happens only partial data is displayed.
I am working with very wordy HPI data, and am wondering if there is a limit to the data that can be saved to a document variable. But the error isn't very self-explanatory, and I can't find it on Google.
Any help would be greatly appreciated.
Thank you.
Robin Tardif
Posted : November 27, 2019 8:27 am
Hi Robin,
Document temp variables have a 2,000 character limit. I suspect, by your description, this may be your culprit.
Posted : December 2, 2019 5:47 am
Topic starter
Thank you, Lee. I thought that might be the case.
Do global variables have the same limitation? I just need a temporary place to hold the data while the function selects the appropriate data, based on the user and date.
I have a form that allows the user to scroll through previous HPIs to select a specific one. They have the option to scroll through only their own HPIs, or through any behavior health specialist (in case someone was covering for them), or through any provider's HPI.
It works great with short HPIs, but this form is specifically designed for psychiatrists, and they have very lengthy HPIs.
Robin
Posted : December 5, 2019 7:22 am
Global variables are not limited to 2K characters, but keep in mind that once the update is placed on hold, the variable is destroyed and the contents are lost forever. To store it in multiple doc temps, you will need to write a 'split' function and store it that way. This is always a tricky workflow to get right and with changes in EMR behavior from update to update, not the most reliable method.
What I typically do in this scenario is to estimate how many lines 1990 characters is then limit the display to just that number. I then create multiple fields, usually 10 or so in total, the same size and stack using visibility regions. The user can then 'scroll' using what ever method you create (radio button or action button) and move between the field layers. Lastly I add a message stating that when they are out of visible lines without scrolling, advance to the next field.
This approach will allow a seamless chart note with a bit of manipulation of the default CFMT statement and lends itself to a data display with the same for ease of review on the form (space permitting, of course).
While not 'pretty' and certainly not efficient, it is a fair compromise for when a 'novel' is required and it avoids the pitfalls associated with dynamically managing extended text.
Posted : December 5, 2019 12:28 pm
Topic starter
Thank you, again, Lee.
I'm going to try and see how using the global variable will work. It's okay if the data is reset every time the document is opened, since once the provider clicks the button to copy the specific historical HPI to the current HPI field, we don't care if the global variable resets when the document is put on hold again. The current HPI will stick and they can edit it. I can set the function to run only once each time the encounter is opened, so hopefully, it won't be too inefficient. I've also put a limit of going back only 10 HPI entries. They were fine with that, since they are aware of the limitations within Centricity.
If that doesn't work, I'll try the overlapping visibility regions, but I'm really limited on form real estate and the providers don't want to have to scroll. 🙁
Thank you again for your help. It's always appreciated.
Robin
Posted : December 5, 2019 1:53 pm
