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

refactoring

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

10 Posts

4 Users

0 Reactions

74 Views

RSS

amaskey

(@amaskey)

Posts: 88

Estimable Member

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

one a huge if statement after the those 2 for loops.

Any suggestion of simplifying this.

Posted : June 8, 2017 10:01 am

jfitzmd

(@jfitzmd)

Posts: 419

Reputable Member

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

amaskey

(@amaskey)

Posts: 88

Estimable Member

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

jfitzmd

(@jfitzmd)

Posts: 419

Reputable Member

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

dcarpenter

(@dcarpenter)

Posts: 323

Reputable Member

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

bhoover

(@bhoover)

Posts: 360

Honorable Member

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

amaskey

(@amaskey)

Posts: 88

Estimable Member

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

dcarpenter

(@dcarpenter)

Posts: 323

Reputable Member

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

amaskey

(@amaskey)

Posts: 88

Estimable Member

Topic starter

Thank you

Posted : June 9, 2017 7:14 am

amaskey

(@amaskey)

Posts: 88

Estimable Member

Topic starter

@jfitzmd thank you for the great demo.

Posted : June 9, 2017 11:28 am

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