Even if you've built a fantastic piece of software, implementing it in the real world, is a huge challenge. I realised when interviewing GPs, that actually getting your product being used by a GP, for their day to day work is a huge challenge. This is for several reasons.
Healthcare software is distributed to entire institutions, not individuals. That means that if one doctor wants to use a different piece of software, every doctor needs to make the switch as well. The larger the organisation, the harder it is to find software which everybody is happy with. This makes it really hard to get early adopters - you're not trying to find beta users, you're trying to find beta institutions. One GP I interviewed, Paul, was a beta tester. He was in a good position to do that, as he was the sole GP at his practice - if he wanted to try a new piece of software, he only needed to make the change for himself.
Changing any system is a risk for a healthcare organisation, but switching out a piece of software as complicated as a patient management system, is a huge risk. There is the risk of patient records being incorrectly converted from the old system to the new. There is the risk they will make mistakes early on. What if the new system fails?
Where there are risks, there is cost. You will need to pay for patient record conversion and staff training, which is usually provided by the vendor. The new system could make your workers inefficient while they get used to it. The institution may have to pay the vendor or IT staff to help install, configure, and test their new system.
On top of the external costs, institutions also need to spend employee time to find and assess different vendors systems. The institution needs to feel confident that the new system will fit their requirements, and be an improvement over their old system.
The question an institution has to consider is, "Will the upsides of new software outweigh the cost, and risk?".
A well-discussed concept to consider is the socio-technical aspect of healthcare software (Coiera, 2004) (Beasley, Holden, & Sullivan, 2011).
The reality is that technical systems have social consequences. The way software works will affect how users, and institutions as a whole, use them. Likewise, technical systems are built based on social systems - how an organisation works will affect how a tool is built to that need.
Coiera concludes that we don't build technical systems - we build socio-technical systems. This requires an intimate understanding of how people and technology interact. They simply cannot be designed independently.
This can be considered as another explanation as to why healthcare software is hard to distribute. If a new piece of software has an effect on the existing social systems of an institution, it will be hard to distribute that software.
"Accelerating Innovation in Health IT", also touches on the topic of distribution (Rudin, Bates, & MacRae, 2016). Common methodologies in both design and software development use an iterative cycle of building and testing. This requires both the opportunity to fail, and fast distribution.
"Developers can serve users’ needs better when they have the freedom to experiment and fail quickly."
They suggest the creation of 'sandboxes', environments where it's easy to distribute new versions of software, and where failure doesn't have disastrous effects. This is one approach to reduce the challenges of risk and distribution during the development phase.
It's worth considering the value created in a healthcare system by better software. A doctor in NZ with the current industry standard software will see between 24-32 patients a day, depending on appointment length.
Would a doctor with improved software be able to see more patients per day? While better software can certainly create more efficient workflows, reduce mistakes, and provide better patient outcomes - how much effect would it really have on the bottom line?
The three reasons I've argued don't exist independent of each other. Arguably, the difficulties of distribution are actually caused by risk, and complexity.
The more complex an existing software system is, the harder it is to create a replacement - as it's workflow is ingrained in the institution. You can't just replace a portion of it, you have to replace the entire system. So the new software has to match all of the existing functionality.
The new system must provide more value than the existing system to make it worth upgrading - usually, this means more functionality. This creates an even more complex system. As the complexity of these systems grows, the risk of replacement increases.
Ultimately, it comes back to the question of potential value versus the risk + cost of upgrading.