I recently wrote about how I always try to follow the vendors’ recommendations when implementing healthcare information technology (HIT). I’ll summarize my thoughts in case you missed them: I want to work with vendors who know what they’re doing and have done similar work before. I expect those vendors to understand my business needs and wants, and have solid best practices about how best to achieve those needs and wants with their technology. I try to follow those recommendations unless I or my team can articulate operational or clinical reasons negating the vendor’s directions.
I was working with a large hospital system recently, and I encountered a leader who expressed his frustration with information technology (IT) analysts who have adopted the vendor’s recommendations as gospel. We were discussing a problem that some users were having in finding documentation, and I noted that I didn’t believe the electronic health record (EHR) vendor had an adequate solution. Hence, I’ve used a third-party “bolt-on” to fill in a gap that the EHR had. While I don’t generally advocate bolt-ons, I think they make sense when they’re reasonably priced, fill a real need, and can be easily removed if/when the vendor ups their game and fixes the problem.
This suggestion was not met with joy by certain IT analysts: “Buying a third-party application is not best practice according to our vendor. They recommend just using their software. Leadership keeps talking about single source, and now you want to go back on that?”
While I don’t agree with the attitude, I fully understand it.
We don’t live in a black-and-white world; at least I don’t. There are grays all around us. Most of the time, this is the right answer, but under these conditions, that’s the right answer. I wish it wasn’t the case, but life and business are messy sometimes.
In the specific example mentioned above, I see no problem in looking outside of an EHR vendor for tools to push out documentation and make it easily accessible. This specific need is not in the sweet spot of these developers; surely, they’re smart enough to give us the tools that we need, but rightly so, they’re concentrating on creating tools to fight the opioid epidemic and easing physician burnout. I don’t expect them to work on objectively less important software that is not core to their mission.
Another facet to consider when tackling this “should we or shouldn’t we look for outside software” is the peculiar personality quirks of your IT staff. I’m going to go out on a limb here and say that most IT folks pine to live in a well-defined world. Alternatively, I could call it a zeros-and-ones world. Now, now, don’t become defensive. I have a Bachelor’s degree in computer science, so I’m not casting aspersions on anyone’s character. I’m simply saying that IT professionals often think in very precise terms, and while this is usually beneficial, it sometimes puts unnecessary obstacles in our paths.
Earlier I wrote that I can support a bolt-on if it’s reasonably priced, fills a real need, and can be easily removed. Allow me to add a few more requirements that are related:
The pendulum has rightfully swung from best-of-breed to single source, but it’s a mistake to take a good idea and make it gospel. Under certain defined circumstances, bolt-on software makes all the sense in the world.
Have any real-world examples that prove or disprove my point? Leave a comment!