The airlines have a very nice way of retiring their pilots. I once witnessed the last flight of a senior pilot, which was an interesting experience. First of all, they treated it like a celebration, his spouse was included and given a special seat in first or business class, and was given a big bouquet of flowers upon boarding. Second, upon landing the plane gets a "wet" greeting by the airport fire brigade as it taxied through a spray from water hoses, which for passengers is similar to the spray when the plane is being de-iced. The co-pilot told us ahead of time what to expect to keep people from becoming anxious when they saw the fire engines roll up beside the plane.
When planning the retirement of a healthcare IT system, it also should be treated as a time for celebration, while recognizing the need to alert users to the potential struggles that such a transition involves, especially if the new system comes from a different vendor. Transitioning means in many cases migrating data, in almost all cases a vast retraining effort, and a new support staff. Such change typically triggers apprehension, but when people know what to expect, the anxiety level is reduced.
In many cases new systems impact productivity as well. People who have implemented an EMR have told me it took them three months to get to the same level of productivity as before implementing the system. Many make the mistake of switching without accommodating the workload, i.e. they expect to be able to treat the same number of patients as they did prior to the switch. Prudent IT managers try to ease the transition by either cutting production in half the first few days or by doubling the amount of support resources.
Planning for the retirement of a healthcare IT system should actually start when a new one is being purchased. Agreements about support during the retirement process should be negotiated into the contract. There should be clear expectations about the amount of support needed during the retirement process, which will help both the service provider and the user. Frustrations arise on both sides when expectations are not spelled out, for example, service providers can be surprised when they are converted to a month-by-month support agreement, and users can be frustrated to learn that continuing support during the transition phase wasn't included in the budget.
It is also important to have a disposal plan for the physical hardware. Everyone has probably seen obsolete computers stacked up in a basement closet. A well-known study by a professor from MIT who had his students buy computers from various used sources, found literally thousands of credit card numbers, pharmacy records and other private information on these systems. The US federal HIPAA regulation specifies that old hardware be disposed of in a manner that preserves the privacy and security of the information stored on these systems. In my city, there is a “computer crusher” that takes the hard drives and physically destroys them to prevent any possibility of data recovery later on.
One should also make sure that a retention policy is defined, i.e. when information and devices should be retired or eliminated, and that retention is possible from a technical perspective. Many systems build in redundancy to make sure information never gets lost, and are not designed to purge information, especially if it is part of a database or archive. Many systems, especially archive systems, delete a record by a flag in a database, which does not erase the actual data on an archive. Consequently, if the information on the old system is migrated to the new, deleted information often reappears.
In conclusion, one should plan for the retirement for a system when it is being purchased to ensure it can be done gracefully, and one should consider doing it like the airlines do with their pilots, i.e. make it a celebration for the new to come in and let go of the old.