PACS/RIS Replacement: Cheating the Big Bang

Replacing technology is always nerve-wracking, but it is particularly volatile when the systems being replaced are a PACS and a RIS, systems at the heart of daily function for radiology departments and hospitals. Anthony Jones, PACS administrator for the University of Utah Health Sciences Center (UHSC), knows the changeover terrain well, and on May 16, 2008, at the Society for Imaging Informatics in Medicine’s annual conference in Seattle, he detailed for seminar attendees how his hospital is getting its PACS/RIS changeover done. Jones says that the Salt Lake City facility is licensed for 425 beds, with a dozen affiliated clinics in outlying spots. It conducts roughly 250,000 radiology exams per year, he says. UHSC also operates a teleradiology system through which it reads for smaller regional hospitals and clinics. UHSC installed its old PACS in 1998. It had installed its RIS earlier, in 1990. The PACS has 3,500 users and the RIS has 1,000, Jones says. The Big-bang Approach Lead time in a changeover is important. To get started on the system conversion, the UHSC teams laid out a 12-month transition timeline for the RIS replacement. Contract constraints limited the PACS-replacement timeline to eight months, Jones says. Originally, UHSC did not intend to roll out both new applications simultaneously, Jones says, “but the more we thought about it, the more it made sense to roll out both at the same time.” To put a tag on the simultaneous rollout, Jones and his colleagues chose the name Big Bang. Everything would be happening at once; administrators and staff would have to plan well and stay on their toes. The advantages of Big Bang are many. Interfaces need to be built only once instead of twice. If the RIS were installed first, then it would have to be interfaced first with the old PACS and then with the new PACS. “Even worse,” Jones says, “you’d have to make the new RIS talk to the new PACS in the same way it talked to the old PACS.” This would be way too much interface work. Both systems go live at the same time, so if there are glitches during offline testing, it is simple to stay with the old system until they are fixed. Training is also streamlined with Big Bang. Staff only have to be trained on the new systems once, avoiding training fatigue. Jones says, “We can have one big, concentrated teaching session and be able to get back to business as usual.” The simultaneous rollout also avoids issues of legacy compliance (adapting new systems to old ones) throughout the installation process. While the advantages are too great to ignore, there is one large disadvantage of Big Bang: chaos. “That’s you in the center there, with images and reports and equipment all flying in every direction, and you’re sitting in the middle in a big crater,” Jones says. With chaos as one outcome, Jones says, the UHSC teams looked at ways to “cheat the Big Bang.” The central idea was preadaptation, both on the human side and with the technology. Jones stresses the importance of getting clinicians, modality support teams, voice recognition, emergency medicine, and hospital information system personnel prepared for the day of conversion. Training teams and data-center staff also had to be involved. Planners had to calibrate needs for space, power, cooling, connectivity, and other infrastructure to support the PACS/RIS installation. Jones advises installing this back-end infrastructure, much of it in the form of system servers, as soon as possible, starting to use it immediately. Preloading data is another way to cheat the Big Bang, Jones says. This involves dual sending from the modalities, with data going to both the old PACS and the new PACS, so that by rollout, the new PACS has some prior data in place. “When you go live on your new system, your studies are there,” Jones says. If modalities don’t support dual sending, you could try sending to the old PACS and configure the old PACS to send data on to the new PACS, Jones says. It may also be necessary—as at UHSC, for its teleradiology system—to configure an intermediary device to capture information from the modalities and send it on to the old and new PACS, Jones says. The same sort of preloading and routing of data need to be done with the RIS. Yet another way to cheat Big Bang, Jones says, is to perform user simulations. “At least a month before you go live, both systems should be completely up and running.” He stresses the importance of solving workflow and integration issues at the simulation stage. Data Migration and Systems Integration Data migration is another thorny issue. Data do have to be manipulated in the migration process. To expect a perfect migration may not be realistic, according to Jones, but generally, data migration does work. You have to keep testing as you go, he says. “Our goal is to have 12 months of priors on the new PACS when we go live, with a combination of data migration and preloading,” he says. “This is a pretty big deal, from a clinical standpoint.” In fact, without a year of prior studies, the conversion to the new PACS will be put off, Jones adds. Within 18 months of conversion, UHSC expects to have all its data migrated, with no more than 10% of studies needing manual intervention, Jones says. “We’re hoping for less than 5% data loss. In addressing another problem of PACS/RIS conversion, Jones notes, “Systems integration is really where DR has replaced film.” Systems integration is, in fact, the most difficult and time consuming of all the conversion steps, he adds. Systems integration is built on information systems that generate, receive, send, and store data—and on interface engines that receive, translate, remap, and send data, Jones says. All systems want the same data, but they need them in different forms, such as DICOM for the PACS and HL7 for the RIS. Systems integration just for a RIS can employ more than a dozen interface engines and servers, Jones says. Using interface engines, it is possible to convert file types, he says, meaning that, for patients and providers, all the data will be accessible. Applications Integration and Fault Tolerance Integrating applications, as opposed to systems, takes place on the front end, where the user accesses the PACS or RIS. Either the RIS or the PACS can be configured to act as the primary user interface and the driver of both the PACS and the RIS, Jones says. If the RIS is the driver, it can, through its worklist, tell the PACS and the voice-recognition system which studies to find, and for what dictation to prepare. “You have to make a decision on what is going to be your primary user interface,” Jones says. At UHSC, the decision was to drive the system through PACS. Once the driver is chosen, then user interfaces can be integrated with that driver. Fault tolerance involves creating a parallel data-processing and storage system, so if the primary system goes down, the backup system takes over for it. “The good news is that computer hardware is very cheap,” Jones says. A key part of any such system is having it switch over to the backup automatically, he adds. He also says that having a test system for upgrades and implementations, and for making adjustments through the backup system, is worthwhile protection. “You don’t want to fail on your live PACS,” he says.