Notifications
Clear all
Topic starter
I am thinking of ways to refactor the mel codes to make it more modular.
eg - i use meds_after very often to get some subset of the data. Some forms might require getting just coumadin meds and some require just diabetes while other require all meds. Whatever I need it is always 2 getfield and 2 for loops.
I can have multiple functions one for each requirement
or
one a huge if statement after the those 2 for loops.
Any suggestion of simplifying this.
Posted : June 8, 2017 10:01 am
You could use create a function in the USRLib.txt. You would enter the function with a generic med substring, GPI substring, or ICD10 substring, and return string of delimited text rows for the matches in whatever form meets your needs. Having suggested using the UsrLib.txt, this must be in all clients and is a pain in the neck when you perform upgrades as the UsrLib.txt must be copied.
As an alternative, just copy/paste the appropriate functions into the individual forms. The downside of this approach is that if there is a significant redefinition of the underlying function, think ICD9->10, you must make changes in all forms that use this code.
Delighted to talk to you as I have implemented this technique for evaluation of quality measure compliance: e.g. pts with CHF on ACE/ARB.
Posted : June 8, 2017 10:23 am
Topic starter
Most of my functions are in individual forms right now and I am planning to move them to function library after reading the downside of usrlib.txt in chug but both could accomplish similar result as long as i am in the encounter.
Function parses med_after into arrays and then there is a big if statement,
if gpi == ace/arb gpi
return ace/arb meds
else if gpi == coumadin gpi
return coumadin meds
else if ....
This function might get too big to manage as I continue adding more if statements and I cannot think of a way to simplify this function.
Posted : June 8, 2017 11:03 am
If you would like my thoughts, contact me directly, and I can show you how I approach this problem.
Posted : June 8, 2017 11:14 am
You could always switch to case statements so you don't have to deal with if...endifs everywhere. here is the format
{cond
case gpi == ace/arb gpi
return ace/arb meds
case gpi == coumadin gpi
return coumadin meds
....
else return all meds
endcond}
You can use as many cases as you want, and even run different functions based on the case that is true. I would make a function for each med type such as getAceArb(), getCoumadin(), etc...
hope this helps
Posted : June 9, 2017 4:36 am
Another strategy to improve efficiency would be to put your meds_after() call into a global variable that is called outside of and before all of your functions.
{! gMeds = meds_after()}
Then wherever you have meds_after() drop in the variable. I have had some good success doing this and the med list has stayed consistent throughout the visit. However, the functions that you have will behave different than mine so you will want to test this out.
Posted : June 9, 2017 5:23 am
Topic starter
@dcarpenter - a huge if or case statement would be the same right. it is considered bad design and i am trying to avoid that. I might have to do what you recommend.
@bhoover - i will test global call
Thank you all
Posted : June 9, 2017 7:03 am
Yeah shoving all the code into a huge case statement is bad design. but having a huge case statement that just calls the correct Getter function is totally fine, as the only code that runs is the case that is true. But for the actuall code that manipulates and returns data, you are going to want to build several smaller functions. I have some code that uses over 20 cases, but it only sorts what other function to call based on the case, and it is WAY cleaner than having 2 if, else endifs in my code.
Good luck!
Posted : June 9, 2017 7:09 am
Topic starter
Thank you
Posted : June 9, 2017 7:14 am
