PACS Archive Migration Strategies
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 components1: 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 on-line. Exams prior to that date might be available through pre-fetching, however, this assumes that all exams are scheduled, which is not the case for emergency cases. One should also realize that previous images are not only necessary for new exams for comparisons, but could also be needed by a physician for a follow-up visit. In one institution, appointments from the clinics were actually entered as dummy exams in their RIS to cause pre-fetching to occur and the images to be available. However, physicians tell us that having access to two years of priors is too short a timeframe. A migration of a good size institution with about five years' PACS investment that has to migrate about 50 percent of both the archive and database might take at least six months.
The complexity of the conversion depends on the input and output data formats. If the archive conversion, for example, is from a DICOM to DICOM format, and the database is just changing pointers, it is not that complex. However, if the input and/or output data formats are proprietary, it can take more effort. Remember, there is no standard on how a vendor stores its images on its archive. Most vendors leave the DICOM "packaging" intact and store them accordingly. Some vendors, however, convert the DICOM images to their own format at a PACS gateway or the archive. Some vendors choose to convert the images from DICOM into a proprietary, compressed format to make them more readily available for the workstations.
The effort of the endeavor also hinges on the quality of the input data. There are several reasons the input data might not be correct. In some cases, the data might be corrupted because of hardware issues, such as when retrieving from an old tape, or when read-errors appear. In some cases, there might be a back-up available that can be retrieved instead, or there might even be a film around that can be digitized. In addition, there might be conflicting or missing information in the image header, and the new image manager might have different criteria for accepting the data in its database than the original PACS database software had. In all these cases, manual intervention is required, which is what makes this whole exercise rather costly. A human being needs to monitor the conversion and take action when needed. It is not unusual to have thousands of records to be fixed during the migration process, which is still a relatively small percentage of all records if one considers the overall size. In general, here is where good quality control at the time of the original data generation really will pay-off. For example, did the technologist select/enter all the patient demographics correctly? Were any discrepancies flagged and corrected?
In most cases, migration is completed by the current or new vendor. Yet in some cases, especially when the cooperation of a previous vendor is not necessarily helpful and/or guaranteed (remember, you might not have divorced amicably), one could solicit the help of an independent, third-party that might be in a better position to work with both vendors to resolve any issues. Here is when a "pre-nuptial" agreement really pays off with your PACS vendor. Anyone buying a PACS today should agree on how the data should be migrated in case of a PACS divorce. Another critical item of this agreement is knowing the formats the information is stored in, not only for the images, but also for the overlays and other image-related information. Lastly, there should be a performance and pricing guarantee for the conversion of the data and database to another format. The performance guarantee is especially critical. For example, if a vendor stores its data in a proprietary format, requiring a conversion/gateway to get the data out in a DICOM format, it could take considerable time for the data to be migrated.
In conclusion, migrating your PACS archive is a major issue. It is a lengthy endeavor and can be quite costly. I've seen pricing ranging from $50,000 to $1 million, and therefore smart agreements with your current and budding vendors are critical, along with some solid planning.
Herman Oosterwijk is president of OTech Inc. (www.oteching.com), which provides PACS training in the form of books, classes and on-line learning. Send Standards Watch questions and comments to herman@otechimg.com.
- "PACS Fundamentals" chapter 2.4, available from www.otechimg.com