With each new project, every organization has the potential to improve itself, to make itself better. An organization does not invest hundreds of thousands or millions of dollars every year to be the same or be worse. At the beginning of each project, a cost/benefit analysis is always done, but how many organizations go back and prove that those benefits were actualized?
I have worked in the IT field for almost 30 years and most of those years have been in healthcare. However, I have worked in other industries like retail, manufacturing, and warehousing. I can say that healthcare is probably the most negligent on this topic, and I place the responsibility on the IT Steering Committee.
How do we know that each project is transforming the organization to be better? I have seen cost/benefit analysis many, many times. The IT Steering Committee will usually justify the cost by the analysis, but did that project actually produce those benefits? From what I have seen, a success is measured in continuity of clinical care and/or revenue. In other words, there was no disruption of care of revenue. Don’t get me wrong! These are important, but if we are just continuing clinical care or revenue, where is the improvement?
I was recently on contract with an organization to integrate a new application into the organization’s EMR. The software was purchase and installed, and now it was time to create the interfaces. The department was not fully engaged which was a yellow flag in the project. However, the Systems Analyst assign to the project did his best and was able to get many of the answers from the department. We built the interfaces and tested them to everyone’s satisfaction including user acceptance testing. It was time to move this all into production which we did. It wasn’t until we waited for the first case did, we find out they only do 2-3 cases a month! My immediate reaction was how much did they spend for 24-36 cases a year? These were not large revenue producing procedures nor did they produce critical medical information.
Let me progress with this story as it did get worse. The department now had to enter an order for it to cross into the new application, and the result had to be attached to the order to send back across successfully. Once this was done, the result would show in the EMR. The process was documented, the staff trained, and given multiple demonstrations; however, they would not comply. They would not enter the order. It was escalated to the VP level, but nothing was enforced. Now you have disparate information in a stand-alone application. What a waste of time, money, and resources. The organization went backwards.
How can an organization actualize the benefit post implementation? I think the answer is pretty simple. The IT Steering Committee needs to build into the process a post cost/benefit analysis. Take the pre-implementation cost/benefit analysis and prove that it was gained. For example, I have seen multiple times that the organization is going to save 1 FTE (Full Time Employee). The question is, “Will that job title/code be removed from the budget?” Most times, the department gives the employee something else to do. That is not a reduction and should not be included in the cost/benefit unless the employee literally changed job codes.
I would encourage organizations to document any benefit gained that wasn’t outlined in the beginning. Many times, there are more benefits discovered during the implementation because the knowledge of the product has increased. I also encourage organizations to document unmeasured gains like patient convenience or physician keystrokes. These are simply bullet points that do not have a dollar amount associated with them.
I do think it is vital that any Steering Committee that is going to change the process to include a post-implementation cost/benefit analysis educate the department heads on how to write a realistic analysis before submitting it to the committee. It should never be over-inflated, and it should contain measured and unmeasured benefits.
If the benefit is not gained, the IT Steering Committee needs to meet to discuss what happened. It should not be a blame game, but a quality review with all parties to discuss the what went right, where can we grow, and how do we prevent this from happening again. This will create an environment that will foster change and help an organization to improve through every project.
Written by Kevin Frederick, Founder and CEO of D288 IT Solutions, LLC. ©2019 D288 IT Solutions, LLC All Rights Reserved.
D288 IT Solutions is built on the success of helping organizations transform through the process of implementing systems, processes and technology.
Visit our Website: www.d288itsolutions.com
Kevin L Frederick
Founder & CEO
Welcome to our blog! Our purpose at D288 IT Solutions is to support the advancement of healthcare IT. Our hope is to create an environment through sharing of topics aimed to help the healthcare IT professional in their careers. We hope you find the information useful and practical, so enjoy and check back often!