Migrating your PACS archive and database is a non-trivial event; it can be costly, laborious and is in most instances un-anticipated. Careful planning, even if it is a couple years away, is critical to avoid surprises.
The good news is there are strategies to maintain your investment, not unlike the early days of PACS when an archive provider might go out of business and the hospital would be unable to migrate the information. In many cases, the user could only wait until the archive graciously died due to old age, without any support to speak of.
Why migration? There are several reasons for migrating the data:
- Your archive hardware might become obsolete, too costly to support, or the access time has become a big issue. The initial optical disks that we used were 14 inches in diameter, contained in large jukeboxes. These jukeboxes are definitely starting to show wear and tear, and manufacturers are not even maintaining them anymore. Other examples are long-term archives that are stored on tape, which might not be as reliable as some newer storage media. Even MOD data. One institution replaced its three MOD storage towers with a small rack containing all the data on RAID for immediate, fast access.
- A user might go through a PACS "divorce"—changing PACS vendors. A recent poll among PACS professionals showed that 8 percent of the respondents were definitely unhappy with their current PACS vendor. It appears that many are either considering another vendor or actually taking the steps to change.
- A vendor might change its architecture. One, for example, changed its architecture five times since entering into the PACS business (because the vendor keeps sourcing its PACS from different OEM vendors). Another reason might be that a PACS vendor changes its hardware/software architecture regardless, leaving a user no choice than to follow along. The latter is a given and not unusual in the IT world.
What does the data migration include? One should consider that what people typically consider part of their archive, actually consists of different components 1: An image manager/database, image storage/archive, system administration component, workflow manager and security provision. The image storage/archive does not only contain the images but any other image-related information, such as key images, annotations such as measurements, shutters, and image presentation states such as rotate, zoom factors and new window width/levels. When migrating the hardware of the storage/archive, in most cases only the image pointers in the database need to be updated. In some cases, the image archive can actually be preserved by migration just the database, especially if the images are stored in a native DICOM format. I have seen one institution that migrated its PACS database, because it changed vendors, while the new vendor could accommodate the storage/archive. This whole process took only three months, populating the new database with records and the pointers to the existing archive. In most cases though, when changing vendors, both the image manager/database and archive need to be migrated.
Migrating the non-image data is an issue by itself because the annotations and identification of key images historically are being stored in a proprietary format, often in the database or as private, company specific objects. To transfer these to the new format, either in a DICOM standard format (obviously preferred), or yet another proprietary format, might require custom programming and/or a very close cooperation of both vendors.
The system administration component is typically not migrated because that is very vendor-specific. This could include the capability to run specialized reports on broken studies, study statistics or reject analysis. Several institutions have invested considerable effort in developing their own database scripts and/or other utilities because this is traditionally an area where vendors provide relatively little functionality. This has to be re-created and one might expect that the institution has to put in a non-trivial effort to provide continuity in their reporting and being able to continue to manage their system.
When is it best to start migrating data? This depends on the amount of data to be migrated, the complexity and speed of conversion, the requirement from the clinical staff about what they need as priors, and the quality of the data to be migrated. A typical requirement might be to have two years of priors available