Faced with rapid growth and an obsolete PACS, a large hospital in Saudi Arabia decided to replace its nearly 10-year-old PACS with a new network from another vendor. The job was easier said than done, but it did get done thanks to a proactive team that planned for technical glitches and human roadblocks at every turn.
A presentation earlier this month at the 2014 Arab Health meeting covered the challenges faced by the group at King Abdulaziz University Hospital in Jeddah, Saudi Arabia. There were a number of issues, said healthcare IT consultant Nabeel Mishah: The old PACS, in place since 2001, was completely inadequate, but it was functional and integrated with the hospital's RIS. Moreover, the busy 870-bed hospital and sprawling radiology department couldn't afford any downtime or major glitches.
"Technology is changing rapidly, and at the same time demand is much higher; that's why many centers across the region decided to replace or upgrade their legacy systems installed since 2000," Mishah said. "But the problem is that once you get a PACS from a vendor ... you will stay with that vendor for the next 30 years. We used to teach our students that it's like a Catholic marriage -- there's no divorce."
But by 2008, Mishah and colleagues were ready for a divorce, come what may. They were willing to take the risk of going with a new vendor "with better technology and better options and functionality," he said.
Piecemeal growth
In 2000, when the hospital installed the first large-scale PACS network in the region, it had just 250 beds and a single radiologist, Mishah said. Soon after, the facility increased its capacity to 400 beds, adding workstations and some functionality and a second radiologist.
In 2006, a second major upgrade included a new operating system and additional system functionality. By 2009, the hospital had grown again, this time to 870 beds, and the burgeoning radiology department housed four MRI scanners, three CT scanners, 10 ultrasound systems, three gamma cameras, and three interventional radiology suites, along with x-ray and fluoroscopy equipment.
"The PACS that we installed in early 2000 became obsolete and unable to respond to our needs," he said. "That's why we started to plan for total PACS replacement by another vendor."
Breaking down the job
First on the list was a road map to replacement. The team would have to justify to management why it needed to replace not only its current PACS, but also its vendor. Then it would have to choose the right time to make the transition.
"The right time is actually whenever you have the money," Mishah quipped. With funding secured in 2009, planning began in earnest as the group attended every meeting, workshop, and congress it could find that had usable information on PACS replacement. The team started looking at the features and functionality the new PACS would need, determined to plan for an orderly transition.
Healthcare IT consultant Nabeel Mishah.Even so, Mishah confided, the IT department declined to participate when it found out the group would be booting the old PACS vendor.
"This is too risky, and we will not be involved in such a decision," he recounted being told by IT. "So we built our own team and built our own RFP [request for proposal]," he said. "We concentrated on a few PACS companies, shortlisted potential future partners, and decided on critical features."
From the new vendor, the group wanted new technologies, SMS functionality, and solid after-sale support -- a key component for avoiding future headaches. "In the past, most of the frustrated users [came] from vendors who are not well-dedicated to quick and reliable after-sales services," Mishah said.
Price was actually less important to the group, so the formula for deciding on a new firm allocated just 20% of the weight to price, leaving 80% for features, technology, and after-sales service, he said.
When the new vendor was selected, the group settled on a few guidelines for moving forward. The old PACS would be kept operational for three years to provide backup. Integration would be critical; with a very busy emergency department, there was no room for failure. They drew up a plan to deal with the 50 TB of data amassed over 10 years of operation.
Network operation was just as critical, Mishah said. Every network and hardware issue needed to be checked and rechecked, including the "cables and the switches, how the department is running, and how the network is running," he said. The group would check for bottlenecks, server load balances, and viruses along the way.
More resistance
"The next biggest struggle is internal politics," Mishah said. "When you want to change your PACS, make sure that all of the departments, all of your staff members, and senior administrators are on your side. Internal politics caused a lot of panic for us and [almost caused] the failure of our project."
The old vendor, outwardly cooperative, nevertheless went out of its way in attempts to save its account. "They will never let go," Mishah said. Once PACS vendors get word that they're on the way out, "they will contact higher management, middle management, and everyone else" to block the project from going forward.
To sidestep integration problems before they started, the group drew up clear, comprehensive, and highly detailed documentation of the PACS workflow. They planned to create a test environment using live data for dummy patients. Before going live, the team would test all integrated systems based on the detailed workflow documentation.
And you need a plan B in case something should happen during implementation. "That's why in the planning phase we signed a contract with the old vendor, so the old PACS would be running for the next three years," Mishah said.
In the end, it was reassuring to know that if the new system were to blow up on day 1, the hospital could have the old system up and running in two hours or less. Also, data from the new PACS would now be stored at a different facility a half-mile away in case of fire or another disaster onsite, he said.
Data migration was another tricky issue, one that would be organized in accordance with the maxim "Do not make your new PACS old," Mishah said. That meant transferring data from the old PACS to the new one in a way that would not overwhelm the new system. The existing data would need to be sorted and prioritized; the most recent data would be transferred to the new PACS first, while keeping the old PACS as a modality in the new system.
The group began by transferring all patient data from the previous year to the new system, but even this was done three months at a time, with the newest data first, Mishah said. Data were also categorized as active or nonactive and as normal or abnormal results, with abnormal results being stored longer.
In February 2011, the first RIS migration was followed by pushing data over to the PACS as HL7 messages, followed by the first PACS migration, he said. The process was subsequently repeated several times for successively older and lower-priority data using tape libraries to transfer the data.
The legacy PACS was used as a modality on the new PACS, just like CT or MR -- a "smart choice" that has made life a lot easier, according to Mishah. "In our new PACS, we can delete images from the new modality and send from the old PACS to the new PCs, freeing up our RAID [archive]," he said. "Then we can start uploading again to the RAID."
In the final analysis, the project was completed on time and under budget, Mishah said.
"We did not compromise patient care or workflow, and the good news is we did all these things under budget," he said. Of course, nothing is perfect, he added. Even now, there are small glitches here and there that are still being sorted out, but overall the transition has been extremely successful.
"So replacement is not easy, but it is possible with proper planning and resources -- material and human," Mishah said. "If PACS replacement is your goal, don't make it your nightmare."
