Technology has become an integral part of healthcare. When using software in healthcare, change is inevitable. Newer, better systems are always being developed. Eventually, the time will come to replace a software system. Some software, such as the EHR, touches all corners of a healthcare institution. Rolling out new software systems is a challenge for any industry, but healthcare presents some unique challenges. There are no breaks in healthcare. You can't just shut the operation down while implementing new software. How do you plan and execute a smooth rollout with the least amount of disruption?

There are a few ways to roll out new software that vary in risk. Like entering a pool for a swim, you can dive in, jump feet first, or walk down the steps. When you jump in do you need to be ready to swim? Or is there a ladder you can use to get to safety if you have trouble? Although there is no "right way", some methods are more ideal. Sometimes there is not a choice to roll out the software in the ideal way. Here are four methods to choose between for a rollout.

The least desirable case is a software rollout that must be done all at once where you have to cut the cord to the old system and keep moving. The new system may not be compatible with the old system and all of the data can only be transferred one way to the new system. This is sometimes unavoidable and requires careful planning and fallbacks for any critical failures, up to and including whole system failure. All scenarios need to be considered..."Is my data backed up and accessible from another source?"... "How long can we survive if the new system becomes inoperable?" For an irreversible software change, the maximum amount of planning and communication is required.

Sometimes it is possible to have a rollback plan for a system-wide change. This is obviously a better option than the previous one. Careful planning is still needed, especially around the steps to roll back, but with the safety of falling back to the old, familiar system, less coordination and communication is required. A series of checks are pre-determined so that if the new system fails the old system is used as the backup. Fixes can be made to the new system without the consequences of losing the functionality for an extended period of time.

Whenever possible, an even better option is to test an upcoming change with a small group within the organization. This can give the software a real-world trial before it is implemented system-wide. Bugs can be worked out and user issues resolved without major disruption. Once the system is thoroughly tested, it can be rolled out to everyone. This method can work if the new software can access data and operate alongside the system it will replace.

The ideal approach is a staggered rollout. In this method, the new software is introduced to a group at a time, with full support focused on each group, until everyone is on board. Like the previous approach, this gives the software a chance to have a real-world test run and resolve issues as the rollout proceeds. Like taking the steps into the pool instead of jumping, if there is a problem, there is a better chance to catch and address it early, to cause minimal disruption.

Institution-wide software rollouts can be tricky but, entering the transition process with a thorough plan can clear the waters for you. Have you experienced a major software rollout? If so, what are your thoughts on how it went?