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

Limit to number of stacked visibility regions?

Trading Post

Last Post by Anonymous 1 second ago

5 Posts

2 Users

0 Reactions

78 Views

RSS

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

Hi. I need to build buttons to add dx based on the patient's BMI. There are 30 different codes that I have to use. Is it possible to overlap/stack that many visibility regions? Just asking before I try to do it and fail, if it's not possible.

Thank you in advance.

Robin Tardif

Posted : April 25, 2019 1:41 pm

Lee

(@lee-cooper)

Posts: 348

Reputable Member

Rather than go that route and consume both code space and form items, consider using a single button with a dynamic label and code to support what you need to do? Being a specific value, the cond-case-endcond statement is a perfect fit and will produce a very lean workflow.

To answer, technically, there are no limits, but I suspect that it will struggle beyond 255 layers (the EMR has an issue with more than 255 parameters in a function). Understand that each layer carries a MEL statement which can add up quickly against the 64K size limit for encounter form files. Add in a suppression condition or two and the statements can get very 'wordy' extremely fast.

Posted : April 25, 2019 8:18 pm

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

Thank you very much, Lee. I didn't even think of that. That should work.

Robin

Posted : April 29, 2019 4:17 am

rtardif

(@rtardif)

Posts: 55

Trusted Member

Topic starter

I tried using the dynamic functions, and I can get the function of the button to work with no problems. However, I can't get the dynamic label to work. I put a small section of the form into its own form and have attached it. The dynamic label works off of the patient's age and BMI, which is automatically calculated after the height and weight are entered. Since I currently have only one case statement built while I'm testing, I'm using the height of 68 and a weight of 145 to trigger the functions.

Would someone please take a look at my dynamic label and see what I need to change? I've tried several different things, but I can't get the label to work. This is my most recent attempt.

Thank you.

Robin

Posted : April 29, 2019 5:56 pm

Lee

(@lee-cooper)

Posts: 348

Reputable Member

Just a bit off.

1) Remove the curly braces from the label name in the button.

2) If you are going to use a function, you will want use a 'trigger' to ensure it refreshes on the fly.

Change:

{!gbmilblvitls = fngetbmilblvit()}

to

{!gbmilblvitls = fngetbmilblvit(OBSNOW("BMI"))}

Consider changing to a local varaible workflow to ease pressure on the system:

Change:

{!global gbmilblvitls}

{!gbmilblvitls = fngetbmilblvit()}

{fn fngetbmilblvit()
{cond
case PATIENT._AGEINMONTHS >= 252 AND OBSNOW("BMI") >= 22 AND OBSNOW("BMI") < 23 return "BMI 22 - 22.9, adult"
else ""
endcond
}}

{fn fngetbmidxvit()
{cond
case PATIENT._AGEINMONTHS >= 252 AND OBSNOW("BMI") >= 22 AND OBSNOW("BMI") < 23 return fnaddbmidxvit("ICD10-Z68.22","BMI 22 - 22.9, adult")
else ""
endcond
}}

To:

{!gbmilblvitls = fngetbmilblvit(OBSNOW("BMI"))}
{!global gbmilblvitls}

{fn fngetbmilblvit(strBMI)
{cond
case PATIENT._AGEINMONTHS >= 252 AND strBMI >= 22 AND strBMI < 23 return "BMI 22 - 22.9, adult"
else ""
endcond
}}

{fn fngetbmidxvit()
{
cond
case gbmilblvitls == "BMI 22 - 22.9, adult" return fnaddbmidxvit("ICD10-Z68.22","BMI 22 - 22.9, adult")
else ""
endcond
}}

Each reference to the obsterm invokes a database call. By assigning the value to the function parameter, you save that call and network traffic. Likewise, by evaluating the label value, you save the call to the database again as well as the overhead associated with it for EACH case statement (adds up quickly).

Hope this helps.

Posted : April 30, 2019 12:46 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