Technical Debt in Imaging | Imaging Technology News

Technical debt 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

Technical debt is a term that increasingly finds its way into discussions and presentations in the health IT town squares of webinars, conferences, blogs and white papers. Historically a software development term, it has caught on to express the situations many organizations face as they navigate roadmaps 5-10 years into the future.

There is no specific definition for technical debt. The websiteTechopediadefines it as, “Technical debt 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 a sense, you incur technical debt any time you prioritize the urgent solution over a better longer-term solution, or asCharles Hummelcoined the phrase (and wrote the book), “Tyranny of the Urgent”. And much like consumer debt, it comes at a cost. Buying on credit will cost more than paying cash. But also, as with consumer debt, it is not necessarily a bad thing.

Gaining Momentum

Where this term seems to be gaining momentum is in the space of evaluating technology platforms withinITinfrastructure and architecture. The complexity and strength of performance required to supportenterprise imagingrequires well-designed and deployed solutions that support integration,interoperability, data sharing, data management, security and other critical functions. In most cases organizations are looking at incumbent solutions that were selected, designed or deployed to meet real, near-term, urgent goals. Whether it was the burning platform of an end-of-life software or an opportunity to meet a revenue or performance goal, in most cases these systems were selected without significant consideration of how these systems might put the organization into technical debt.

The result of this is that many decisions being made to strengthen the ecosystem to support enterprise imaging are paying costs for deficient or under-performing systems that are not going to be replaced any time soon. This requires designing software stack solutions that incorporate peripheral technologies that fill the gaps and meet the requirements ofhealthcare deliveryanddata management. This additional cost is the price to be paid for prioritizing the urgent over the better solution. Consider it the high interest rate incurred in buying a used car. If you don’t have means of transportation for a new job, you don’t really have a choice, but the cost can be excessive in the long run.

The debt carries into other areas of an organization. This includes the impact to support teams may be laboring to sustain under-performing systems and taking an inordinate number of helpdesk tickets from dissatisfied users. Or system administrators who are manually managing data due to the lack of embedded, optimized tools that better designed solutions may have provided. And of course, as more infrastructure moves to the cloud there is the ongoing cost for systems that are only designed to run and perform well on-premises.

Managing Technical Debt

So what options are available for those who want to manage (as you can never eliminate) technical debt? There are several best practices that can be learned from the software development industry that carry well over to health IT.

Address and quantify your current technical debt and continue tracking long term. By cataloging your debt, you can begin to “pay down” that debt by funneling resources to better long term solutions and inform decision making based on data that will lead to greater efficiencies organizationally and stronger support systems within your landscape.

Improve processes to minimize the accumulation of new debt. This seems obvious, but if decisions continue to be made based on urgency over what is better the debt will continue to accrue. Implementing a roadmap can be a great exercise (although difficult and somewhat tedious) and when implemented can assist in guiding decisions by providing a framework for the future. Things will happen along the way that may redefine the roadmap with some detours or unplanned events, but the overall direction and prioritization of outcomes can support a path toward avoiding new technical debt. This also includes taking a careful look at what has prompted technical debt historically within the organization. Are there trigger events that should or could have been avoided, like not staying current on updates and upgrades, or underfunding important projects? Self-examination, while difficult, is important for building better models for selection, acquisition, design, and deployment of technologies.

I believe this topic will continue to expand into more conversations. It is a great model to evaluate where we are and where we want to go as organizations. As we are required to do more with less, a full accounting of the cost of any decision will be analyzed with greater scrutiny from different areas within the organization. And as the old adage goes, we pay now or we pay later.