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

Any problem with this? Docment variables turned into Obs terms...

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

6 Posts

4 Users

0 Reactions

85 Views

RSS

Amanda.Harris

(@amanda-harris)

Posts: 10

Active Member

Topic starter

Hi. Our organization is taking some forms and doing a mass transformation of document variables to obs terms for future reporting purposes. I'm familiar, but not proficient in this and am wondering if the transformation of something like this (example of a function in an assessment/plan form) will have any unintended consequences.

Document variable version:

{fnProbDropdown_AP(PROB_AFTER("delimited"),DOCUMENT.AP_1_LC,DOCUMENT.AP_2_LC,DOCUMENT.AP_3_LC, DOCUMENT.AP_4_LC,DOCUMENT.AP_5_LC,DOCUMENT.AP_6_LC, DOCUMENT.AP_7_LC,DOCUMENT.AP_8_LC,DOCUMENT.AP_9_LC, DOCUMENT.AP_10_LC, DOCUMENT.AP_11_LC, DOCUMENT.AP_12_LC,"1") + "," + gOtherDxs}

Obs version:

{fnProbDropdown_AP(PROB_AFTER("delimited"),OBSNOW("A&P#1"),OBSNOW("Ass2AP1-2"),OBSNOW("Ass1AP3-4"),OBSNOW("Ass2AP3-4"),OBSNOW("Ass1AP5-6"),OBSNOW("Ass2AP5-6"),OBSNOW("Ass1AP7-8"),OBSNOW("Ass2AP7-8"),OBSNOW("Ass1AP9-10"),OBSNOW("Ass2AP9-10"),OBSNOW("Ass1AP11-12"),OBSNOW("Ass2AP11-12"),"1") + "," + gOtherDxs}

Posted : August 23, 2019 8:19 am

DavidShower

(@davidshower)

Posts: 1255

Noble Member

On the face of it, that should be find and everything in the function should work the same way, regardless of the parameters being document variables or observation terms. The function code itself will only care about the values they contain, not where they originate.

Posted : August 26, 2019 4:49 am

bhoover

(@bhoover)

Posts: 360

Honorable Member

One thing you might want to test for is speed. If you have a lot of data points and you are going from document variables to obs terms you might see the form run a bit slower. There are ways around this by keeping your document variables and calling a function whenever the document variable is updated to push to the needed obs term. Another user shared this idea with me when I was looking for ways to speed things up on our forms. Take a look at this thread for discussion/code:

https://forum.centricityusers.com/forum/unit-testing-for-speed/

Posted : August 27, 2019 1:28 am

Lee

(@lee-cooper)

Posts: 348

Reputable Member

Hi Amanda,

The main issue will be in recursive execution. When obsterms are initialized in function calls, only one obsterm is 'triggered' at a time, meaning that for each instance that the function call is initiated, it will be triggered multiple times. In your example, that could be up to 14 times (12 obsterms, 1 prob after, and 1 gVar). Given that it appears you are using 12 fields, that is potentially 168 executions of the code just to initialize it on form load. While it might not be that heavy, you will want to evaluate it against all of the other forms in an update to ensure the performance hit is not undesirable. Should it prove to be too much, you could retain the document variables and assign them to obsterms directly in the MEL window of VFE (i.e. {! OBSNOW("A&P#1", DOCUMENT.AP_1_LC)}. In this manner, you maintain the efficiency of the doc vars whilst storing the values as desired in obsterms.

Posted : August 27, 2019 4:43 am

Amanda.Harris

(@amanda-harris)

Posts: 10

Active Member

Topic starter

Thanks everyone. Very helpful. I will pass this info along.

Posted : August 28, 2019 9:14 am

Amanda.Harris

(@amanda-harris)

Posts: 10

Active Member

Topic starter

Thanks very much for the replies. Very helpful.

Posted : September 6, 2019 5:59 am

Share:

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

Powered by wpForo Powered by wpForo version 2.4.0