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

Array creation is slow

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

8 Posts

4 Users

0 Reactions

70 Views

RSS

rtardif

(@rtardif)

Posts: 55

Trusted Member

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

bhoover

(@bhoover)

Posts: 360

Honorable Member

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

Lee

(@lee-cooper)

Posts: 348

Reputable Member

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

rtardif

(@rtardif)

Posts: 55

Trusted Member

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

mikeseale

(@mikeseale)

Posts: 344

Reputable Member

This is a very good point, and I will update my answer to that thread accordingly.

Posted : October 17, 2016 7:19 am

rtardif

(@rtardif)

Posts: 55

Trusted Member

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

Lee

(@lee-cooper)

Posts: 348

Reputable Member

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

rtardif

(@rtardif)

Posts: 55

Trusted Member

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

Share:

24 Forums
9,940 Topics
39.9 K Posts
4 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

Powered by wpForo Powered by wpForo version 2.4.0