Notifications
Clear all
Topic starter
Hi. I'm creating a different version of the OB Flowsheet form, and it is working, but it is exceptionally slow to open. For a pregnant patient with a lot of data, it can take up to 15 seconds for the form to open. I've tried a few different ways to pull in the data, but that's as fast as I can get the form to load. Does anyone have any suggestions for things to try?
I'd like to not have any external files, other than maybe a text document. I thought it might be feasible to build an array of all the applicable data that is needed in the form, and then just use that data in my functions, rather than the entire database. However, unless I can build the array somewhere else outside of the form, then this approach has proven to be a slower method.
Is there a way to have the MEL ignore visibility regions completely when they aren't visible? That might help. But when I run a MEL trace, that's not the case by default. Even if the visibility region isn't visible, the translations and functions are still evaluated.
Thank you for your help. I will gladly share the form when it's completed.
Robin
Posted : October 5, 2016 5:35 am
Hello Robin,
If I understand you correctly you are pulling a lot of obs terms and that is what is causing the slow down. If that is the case, others here have helped me with this issue:
https://centricityusers.com/forum/improving-performance-on-forms-with-many-obs-terms/
Brad
Posted : October 5, 2016 7:51 am
There is one caution related to the post linked to this one. While it is fine to delimit and store values in an obsterm, it is not 'wise' to use pipe or caret characters as the delimiter. Reason: When using list_obs, those characters will break the arrays when get field is invoked rendering the data stored in them unusable from a historical perspective (especially needed for 'flowsheet' building). 😉
Posted : October 5, 2016 8:02 am
Topic starter
Thank you both. I definitely wouldn't put the data array into another obsterm. I would like to put it into a global or document (temporary) variable that I can pull into the encounter. I attempted to get it into both of those by running the function in a text document, but I wasn't successful at pulling in the variable (data) to the specific form. Not sure if I'm doing something wrong with that or if that's even possible. This is the first time I've encountered this issue, so it's definitely a learning opportunity for me.
Robin
Posted : October 5, 2016 8:52 am
This is a very good point, and I will update my answer to that thread accordingly.
Posted : October 17, 2016 7:19 am
Topic starter
In case anyone is interested, I figured out the solution to my problem. I came across this update to the LIST_OBS data symbol, and it made all the difference in the world:
LIST_OBS("GEST AGE EST","signed","delimited","value",FALSE)
When set to FALSE, unnecessary reads to the Document table are eliminated; therefore, the following data from the Document table will not be returned: Location of Care, Document Type, Visible Document ID. This argument is used only for the delimited format.
Using this option cut down the form load time from 30 seconds to 2 seconds.
Robin
Posted : March 23, 2017 12:42 pm
CAUTION:
The 5th argument (FALSE) is a new addition that GE recently added to the system.
My last understanding is that it was applicable to specific versions of EMR/CPS.
It was said then that use by older versions would cause a hard crash.
You might want to verify if your current version of the EMR will support the additional argument prior to use.
Posted : March 24, 2017 1:32 am
Topic starter
Thanks, Lee. I stumbled across this in the help system in which it's being used. I didn't know it had been added prior to that. I figured there was probably a version limitation, but that's why we test, test, test, and test some more. 🙂
Robin
Posted : March 24, 2017 3:12 am
