Notifications
Clear all
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
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
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
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
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
