Advance Preparation Is Key to Smooth Migration
When John Mowry, digital imaging manager at Cook’s Children’s Health Care System, Fort Worth, Tex, decided to switch from his legacy PACS to a thin-client, Web-based model, he faced a particularly daunting migration situation. The servers in use by the legacy system were on their last legs; meanwhile, there were more than 10 million images across 450,000 studies to migrate. “The situation was dicey at best,” Mowry recalls. “It had come to the point where the system was so old and the support was so bad that we couldn’t even run the servers half the time.” 
John Mowry Dicey is probably the most generous thing that can be said about old PACS technology by the time most IT departments begin the migration process. In today’s cost-conscious health care marketplace, the switch to a state-of-the-art solution is often delayed until the legacy solution is demonstrating serious weaknesses. “The company operating the legacy system was in financial straits at the time we decided to switch,” Mowry says, “and their PACS wasn’t scalable to handle the load of exams we were doing at the time.” In addition to scalability, Mowry’s PACS shopping list included the following: he wanted the vendor to be an established, financially sound company, he wanted to be able to link the system to the hospital’s electronic medical record (EMR), and he wanted a Web-based solution. “No matter where you sit down, you’re able to access the PACS,” he says of the Synapse system from FUJIFILM USA Medical Systems, Stamford, Conn. “Anybody who uses our hospital information system (HIS) and has access to the EMR can pull up an image at any time.” Clearly, the switch was worth the trouble. As a veteran of the dreaded migration process, Mowry has some valuable advice for anyone in his situation: plan ahead. Assess how much data you have to migrate, look at what kind of data storage you’re currently using, and make sure you know the format in which your images are currently stored. “It was a very in-depth process for us,” he says of preparing for migration. “It took about two and a half months to migrate the data. We spent a year preparing and planning.” Preparing the Way Preparation shouldn’t involve just an assessment of the current system’s characteristics, which most IT personnel are all too familiar with anyway; it’s equally important to consider the system to which you’re going to be migrating your data. Mowry recommends ensuring that you have a minimum of three times your current storage in order to allow for future growth. He also suggests moving to spinning media if your current storage is DVD- or tape-based prior to migrating to the new PACS, with one caveat: know that this process may require the assistance of your current vendor. “We had cooperation from our existing vendor in moving data from the DVDs to spinning media,” Mowry says. “The company created some jobs for us that we ran a few at a time, every three nights, to move the data from the DVDs to the storage-area network.” The transfer dramatically shortened the PACS-to-PACS migration to less than three months. Migration costs are generally built into the contract with the new vendor, which plays a crucial role in the process by providing the migration server that queries the existing PACS for data. The querying process is followed by the migration itself, which occurs study by study and can be particularly rough on outdated, overworked servers. It’s the catch-22 of the migration process: The best justification for upgrading to new technology is the difficulty of making the change. “Our migration server started at day 1—July 15, 1999—and started pulling studies one by one into the new Fuji database,” Mowry says. “Our servers were getting old, and we weren’t sure they’d be able to handle the additional workload of this daily job and migrating all the new data, so we started slowly and gradually cranked it up until it was moving three or four studies at a time.” Though he was concerned about this process inhibiting access to prior studies during the migration period, in the end, there were no problems using the legacy PACS. Mowry recommends a slow, gradual testing process, using a test server, prior to beginning migration in earnest. The aspects to be tested include display of all studies transferred from the old PACS to the new PACS and the display of all images sent from each modality to the new PACS. All told, the migration took approximately two and a half months. “We know of other sites around here that had their archives on tape; it took them over a year to migrate, and they had far less data than we did,” he says. When transferring from tape, Mowry explains, data corruption is a much more prevalent concern. He says, “It was well worth the time to get everything onto spinning media prior to migration.” Another potential issue is database cleanup, as images merged with studies in the legacy system may need merging again if their DICOM headers don’t match patient demographics. To facilitate starting over with the Synapse system, Mowry and his team brought in their RIS vendor Medical Information Technology Inc (Meditech), Westwood, Mass, to populate a database with patient demographics based on the radiology reports. Synapse would then automatically match images with this newly acquired demographic information. “That way, it would look like a clean database when we started it up,” Mowry says. Enterprise Support He also enlisted the help of other departments within the hospital, in a step that he says is crucial to ensuring success. “A lot of times, departments in hospitals have bunker mentalities,” he says. “In a process like this, it really helps to have IT involvement. They can streamline the process. Having them involved let us plan and train for the system cutover, rather than having to worry about everything on both the back end and the front end at the same time.” Mowry points out that the PACS—much like the imaging department it supports—has something to offer just about every department in the hospital, meaning it isn’t unreasonable to expect interdepartmental support for a transition to a more robust system. “It’s a system that everyone uses, so it helps to have buy-in from everyone,” he says. This approach proved particularly prudent when it came to training. It’s hard enough to get a busy radiologist trained on a new PACS; how do you reach out to the multitude of users throughout the enterprise who are using the PACS in a more limited capacity? “We didn’t even require a Synapse trainer to come in,” Mowry recalls. “We’d had a test system up and running for some time, so our training department went in and was able to quickly learn the application.” The training department passed on its knowledge to power users, representatives from each department of the hospital endowed with an in-depth understanding of the system, who then passed on their acumen to their colleagues. “They came up with a basic curriculum that we used to train both imaging staff and power users,” Mowry says, “and the day we went live, we had a hotline number that anyone with questions could call.” The power users weren’t just valuable during the training process; they also fielded ongoing questions about the PACS. Cook’s training department introduced Mowry to another method for warding off user problems: cheat sheets. “They made quick-tip cards and posted them at all the PACS stations and PCs we were using throughout the EMR,” he says. “This was really beneficial in helping us roll out the application.” All told, the training process went relatively smoothly, again because of planning on the part of Mowry and his colleagues. He also credits the user-friendliness of the Fuji system. “It was really like learning to use any other Windows application,” he says. “Most people were launching from the EMR, so they didn’t have to learn search lists or things like that. We experienced very little pushback.” Now, all 60 of Cook’s PACS workstations and 2,000 of its PCs are capable of loading the application, either directly or through the EMR. “Prior to going live with the new PACS, we had very limited access to the PACS in the hospital: very few PACS stations and very limited access to viewing the images,” Mowry says. “The ability of everyone with access to the EMR to view the images gave us more flexibility in the types of PACS viewing stations that we rolled out, and the number of stations throughout the hospital grew exponentially. With Synapse being a Web-based product, we could roll it out all across the enterprise.” The aspect of being Web-based and the fact that Synapse is hardware agnostic have been major contributors to return on investment (ROI), Mowry notes. Three years ago, “For a lot of the legacy PACS vendors, you had to buy dedicated PACS workstations,” he says. “We could get three to four times as many boxes for what a single vendor box would cost.” ROI is hard to calculate in this case, he noted, because Cook went from a half-digital to an all-digital environment, and because Mowry and team had no choice but to upgrade to a new system. The change came just in time. “Since we switched, we’ve had massive volume growth,” Mowry says. “Now, we’re ready to handle it.”
John Mowry Dicey is probably the most generous thing that can be said about old PACS technology by the time most IT departments begin the migration process. In today’s cost-conscious health care marketplace, the switch to a state-of-the-art solution is often delayed until the legacy solution is demonstrating serious weaknesses. “The company operating the legacy system was in financial straits at the time we decided to switch,” Mowry says, “and their PACS wasn’t scalable to handle the load of exams we were doing at the time.” In addition to scalability, Mowry’s PACS shopping list included the following: he wanted the vendor to be an established, financially sound company, he wanted to be able to link the system to the hospital’s electronic medical record (EMR), and he wanted a Web-based solution. “No matter where you sit down, you’re able to access the PACS,” he says of the Synapse system from FUJIFILM USA Medical Systems, Stamford, Conn. “Anybody who uses our hospital information system (HIS) and has access to the EMR can pull up an image at any time.” Clearly, the switch was worth the trouble. As a veteran of the dreaded migration process, Mowry has some valuable advice for anyone in his situation: plan ahead. Assess how much data you have to migrate, look at what kind of data storage you’re currently using, and make sure you know the format in which your images are currently stored. “It was a very in-depth process for us,” he says of preparing for migration. “It took about two and a half months to migrate the data. We spent a year preparing and planning.” Preparing the Way Preparation shouldn’t involve just an assessment of the current system’s characteristics, which most IT personnel are all too familiar with anyway; it’s equally important to consider the system to which you’re going to be migrating your data. Mowry recommends ensuring that you have a minimum of three times your current storage in order to allow for future growth. He also suggests moving to spinning media if your current storage is DVD- or tape-based prior to migrating to the new PACS, with one caveat: know that this process may require the assistance of your current vendor. “We had cooperation from our existing vendor in moving data from the DVDs to spinning media,” Mowry says. “The company created some jobs for us that we ran a few at a time, every three nights, to move the data from the DVDs to the storage-area network.” The transfer dramatically shortened the PACS-to-PACS migration to less than three months. Migration costs are generally built into the contract with the new vendor, which plays a crucial role in the process by providing the migration server that queries the existing PACS for data. The querying process is followed by the migration itself, which occurs study by study and can be particularly rough on outdated, overworked servers. It’s the catch-22 of the migration process: The best justification for upgrading to new technology is the difficulty of making the change. “Our migration server started at day 1—July 15, 1999—and started pulling studies one by one into the new Fuji database,” Mowry says. “Our servers were getting old, and we weren’t sure they’d be able to handle the additional workload of this daily job and migrating all the new data, so we started slowly and gradually cranked it up until it was moving three or four studies at a time.” Though he was concerned about this process inhibiting access to prior studies during the migration period, in the end, there were no problems using the legacy PACS. Mowry recommends a slow, gradual testing process, using a test server, prior to beginning migration in earnest. The aspects to be tested include display of all studies transferred from the old PACS to the new PACS and the display of all images sent from each modality to the new PACS. All told, the migration took approximately two and a half months. “We know of other sites around here that had their archives on tape; it took them over a year to migrate, and they had far less data than we did,” he says. When transferring from tape, Mowry explains, data corruption is a much more prevalent concern. He says, “It was well worth the time to get everything onto spinning media prior to migration.” Another potential issue is database cleanup, as images merged with studies in the legacy system may need merging again if their DICOM headers don’t match patient demographics. To facilitate starting over with the Synapse system, Mowry and his team brought in their RIS vendor Medical Information Technology Inc (Meditech), Westwood, Mass, to populate a database with patient demographics based on the radiology reports. Synapse would then automatically match images with this newly acquired demographic information. “That way, it would look like a clean database when we started it up,” Mowry says. Enterprise Support He also enlisted the help of other departments within the hospital, in a step that he says is crucial to ensuring success. “A lot of times, departments in hospitals have bunker mentalities,” he says. “In a process like this, it really helps to have IT involvement. They can streamline the process. Having them involved let us plan and train for the system cutover, rather than having to worry about everything on both the back end and the front end at the same time.” Mowry points out that the PACS—much like the imaging department it supports—has something to offer just about every department in the hospital, meaning it isn’t unreasonable to expect interdepartmental support for a transition to a more robust system. “It’s a system that everyone uses, so it helps to have buy-in from everyone,” he says. This approach proved particularly prudent when it came to training. It’s hard enough to get a busy radiologist trained on a new PACS; how do you reach out to the multitude of users throughout the enterprise who are using the PACS in a more limited capacity? “We didn’t even require a Synapse trainer to come in,” Mowry recalls. “We’d had a test system up and running for some time, so our training department went in and was able to quickly learn the application.” The training department passed on its knowledge to power users, representatives from each department of the hospital endowed with an in-depth understanding of the system, who then passed on their acumen to their colleagues. “They came up with a basic curriculum that we used to train both imaging staff and power users,” Mowry says, “and the day we went live, we had a hotline number that anyone with questions could call.” The power users weren’t just valuable during the training process; they also fielded ongoing questions about the PACS. Cook’s training department introduced Mowry to another method for warding off user problems: cheat sheets. “They made quick-tip cards and posted them at all the PACS stations and PCs we were using throughout the EMR,” he says. “This was really beneficial in helping us roll out the application.” All told, the training process went relatively smoothly, again because of planning on the part of Mowry and his colleagues. He also credits the user-friendliness of the Fuji system. “It was really like learning to use any other Windows application,” he says. “Most people were launching from the EMR, so they didn’t have to learn search lists or things like that. We experienced very little pushback.” Now, all 60 of Cook’s PACS workstations and 2,000 of its PCs are capable of loading the application, either directly or through the EMR. “Prior to going live with the new PACS, we had very limited access to the PACS in the hospital: very few PACS stations and very limited access to viewing the images,” Mowry says. “The ability of everyone with access to the EMR to view the images gave us more flexibility in the types of PACS viewing stations that we rolled out, and the number of stations throughout the hospital grew exponentially. With Synapse being a Web-based product, we could roll it out all across the enterprise.” The aspect of being Web-based and the fact that Synapse is hardware agnostic have been major contributors to return on investment (ROI), Mowry notes. Three years ago, “For a lot of the legacy PACS vendors, you had to buy dedicated PACS workstations,” he says. “We could get three to four times as many boxes for what a single vendor box would cost.” ROI is hard to calculate in this case, he noted, because Cook went from a half-digital to an all-digital environment, and because Mowry and team had no choice but to upgrade to a new system. The change came just in time. “Since we switched, we’ve had massive volume growth,” Mowry says. “Now, we’re ready to handle it.”