The Technical Debt of Others

The Technical Debt of Others

Technical Debt as defined on technopendia is:

a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

In the management of software development we have to make these types of easy-to-implement-and-we-need-to-ship versus need-to-do-it-right-but-it-will-take-longer decisions all of the time.

These decisions can lead to the dreaded working as designed answer to a bug report.

This is infuriating.

It’s even more infuriating when you are on the receiving end of this.

A recent feature enhancement in the EHR we use touted an

Alert to let proscribing providers know that a medication is a duplicate.

For anyone in the medical field you can know what a nightmare it can be to prescribe a duplicate medication from a patient safety perspective, so we’d obviously want to have this feature on.

During our testing we noticed that if a medication was prescribed in a dose, say 75mg, and stopped and then started again at a new dose, say 50mg, the Duplicate Medication Alert would be presented.

We dutifully submitted a bug report to the vendor and the responded

The Medication is considered a true duplicate as when a medication is stopped it is stopped for that day it is still considered active till (sic) the end of the day due to the current application logic, which cannot be altered or changed. What your providers/users may do is enter a DUR Reason and Acknowledge with something along the lines of "New Prescription". These DUR reasons can be added via Tools > Preferences > Medications > DUR > Override Reason tab – type in the desired DUR Override Reason > Select Add > OK to save.

If functionality and logic outside of this is desired this will need to be submitted as an Idea as well since this is currently functioning off of development's intended design.

Then the design is broken.

From a technical perspective I know exactly what is going on. This particular vendor stores date values as varchar(8) but stores datetime values as datetime. There may be some really good reasons for making this design decision.

However, when the medication tables were designed, the developers asked the question, "Will we EVER care about the time a medication is started or stopped?"

They answered no and decided to set up a start date (and by extension an end date) for medications to not respect the time that a prescription started or stopped and therefore set them as varchar(8) and not as DATETIME.

But now they’ve rolled out this awesome feature. A feature that would actually allow providers to recognize duplicate medications potentially saving lives. But because they don’t store the time of the stopped medication, their logic can only look at the date. When it sees the same medication (but in different doses) active on the same date a warning appears letting the provider know that they have a duplicate medication (even though they don’t).

Additionally, this warning serves no purpose other than to be one more damned click from a provider’s perspective because the vendor is not storing (ie ignoring) the time.

When clinicians complain about the impact of EHRs on their ability to deliver effective care … when they complain about EHRs not fulfilling their promise of increased patient safety, these are the types of things that they are complaining about.

I think this response from one of the clinicians sums up this issue

I don't see the logic with the current "intended design" in considering a medication that has just been inactivated STILL ACTIVE until the end of the day. A prescriber would stop current and start new meds all in one sitting (which includes changing doses of the same med), not wait until the next day to do the second step. It decreases workflow efficiency to have to enter a reason when no real reason exists (since there IS no active entry on med list). The whole point is to alert a prescriber to an existing entry of a medication and resolve it by inactivating the duplicate, if appropriate (otherwise, enter reason for having a duplicate), before sending out a new Rx.

While it's relatively easy to follow and resolve the duplication alert if the inactivation and new prescribing is done by the same prescriber, I can see a scenario where prescriber A stops an old ibuprofen 600mg Rx[^2] (say PCP) and patient then goes to see prescriber B (say IC[^3]) who then tries to Rx ibuprofen 800mg…. and end up getting this duplication alert. The second prescriber would almost be lost as to why that message is showing up.

The application logic should augment the processes the application was designed to faciliate, but right now it is a hindrance. (emphasis added)

I know that sometimes we need to build it fast so that we can ship, but developers need to remember, forever is a long freaking time.

When you make a forever decision, be prepared to have push back from users of your software when those decision are markedly ridiculous. And be prepared to be scoffed at when you answer their bug report with a Working-as–Designed response.

[^2]: Rx = prescription

[^3]: IC = Immediate Care


Struggle determines success

On Sundays mornings I wake up pretty early, make myself some coffee and read through all of the interesting articles I came across during the week (usually from Twitter).

Last weekend I came across an article, You probably know to ask yourself, “What do I want?” Here’s a way better question

I was struck by several passages in the article:

If you find yourself wanting something month after month, year after year, yet nothing happens and you never come any closer to it, then maybe what you actually want is a fantasy, an idealization, an image and a false promise. Maybe what you want isn’t what you want, you just enjoy wanting. Maybe you don’t actually want it at all.


I wanted the reward and not the struggle. I wanted the result and not the process. I was in love not with the fight but only the victory. And life doesn’t work that way.


This is the most simple and basic component of life: our struggles determine our successes. So choose your struggles wisely, my friend.

When I was younger I wanted to be many things, a Physicist, an Archtect, an Engineer, a Professor … but none of those things ever got any closer. I'd be really engaged in the ideas of one of these for weeks or months at a time.

I remember being so enamoured with the idea of Civil Engineering I convinced my parents to get me a drafting board that I had in my room and I used to 'design' a prototype of a Martian Habitat.

But, as soon as I got bored I would move onto something else. From Physics to Archtecture to Engineering and back to Physics. I would always stop when it either got too hard OR something else looked more interesting.

I was always awed by my peers that could stay laser focused on a single hobby or dream job and was amazed at the amount of sacrifice they would be willing to make in order to achieve their goals.

It wasn't until I got to college when I started to see what I needed to sacrifice in order to get ahead.

Parties on the weekend. Not for me … I had a full time job and was a full time student. I would hang with friends when I could, but I was mostly at the library studying, or at work studying or maybe getting a little bit of sleep.

I suddenly became laser focused like the people I knew in high school. I had a single goal and that was to graduate and go onto graduate school so I could get a PhD in economics.

The PhD didn't happen, and in the following years I felt like I did in high school … becoming very interested in a 'thing' and then moving on from it because I'd get bored.

Then I stumbled into the Healthcare Industry and it all came back. An ability to be laser focused on new and interesting things. Wanting (maybe needing) to learn everything I could about Healthcare.

It's been more than 8 years since I started on my journey, and I've struggled every time I've started to learn a new aspect of the industry, or just an aspect of a new job that I had started.

And that's when the final passage in the article really hit me like a ton of bricks:

This is the most simple and basic component of life: our struggles determine our successes. So choose your struggles wisely, my friend.

It truly is the struggle that determines the success. I've struggled mightily while working in healthcare, but those struggles have lead to the most fulfilling and successful career I could have hoped for.