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 application should not fill a central role of your principal software vendor. For example, I’d be hard-pressed to support buying a patient portal or an e-prescribing tool from a third-party if my EHR vendor’s tools were even half-way acceptable. If the functionality is essential for the EHR to work, don’t farm out the tools.
- If the tools are more content-related than software-related, have no fear. Precious few software companies are good at content; the smart vendors know this and stay away from areas in which they are not strong. Further, I don’t worry about software tools that help manage content; often that functionality is best sought from the folks who make the content in the first place.
- Ideally, from a user experience perspective, it’s best if the add-on software looks and behaves like it “belongs” with the rest of the tools. However, I’m a big believer that if the problem that you’re trying to solve is irritating enough, users will gladly forgive the sub-optimal look and feel issues and thank you for fixing the problem.
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!