When the time is right to change PACS vendors - be sure you've done your homework as to how to transition your patient images and data to the new system, and how much it's going to cost you in time and money.
The purpose of this article is to develop an understanding of the key issues that need to be addressed when faced with the need to migrate data from your current (old) PACS to a new PACS. The article will describe the choices available to specify the data that need to be migrated, the options that are available to do it and the implications of the chosen options on operations and costs.
The topic of PACS data migration, while noted years ago, 1 has recently been gathering more attention as early PACS adopters have opted - for technical or business reasons - to change from their current PACS vendor to another vendor or (without switching vendor) decided to upgrade from their current system to the current vendor's next-generation system. In both cases, the need exists to migrate data from the old system to the new system. The issue is not insignificant, especially in larger teaching institutions that may have amassed 50 to 75 Terabytes of data over the life of the system.
When the old PACS is replaced by a new system, access to historical images and related data must obviously be provided to maintain continuity of patient care. Users will expect that this access will be seamless, with no special procedures required to access images that were stored in the old PACS, but as always, tradeoffs must sometimes be made between cost and convenience. Most vendors have migration and upgrade paths in their product lines, and use seamless access to the legacy PACS data as a selling point for staying with them in a system replacement. But most of us do not like our shopping to be so constrained, and thus it is important to understand the practical issues in legacy data access and migration, and the options available to you when changing from one vendor to another.
It might at first seem attractive to keep your present archive and use it for access to the images it holds, but the economics of retaining the legacy archive are poor. Maintenance and support costs for operating the legacy archive in parallel with the new system will generally be greater than the cost of housing the historical data in the new PACS. Furthermore, such a hybrid arrangement may lower productivity, requiring the radiologist to query the old system for prior exams and use the new system for current exams. Therefore, in most cases, it will be best to migrate image data to the new PACS.
Well, isn't it easy to migrate data? "You just plug the old PACS and the new PACS together, and send it over with DICOM?" That is the concept, as shown in Figure 1, but the execution has a number of subtleties.
First of all, it can take a prohibitively long time to transfer the data through simple DICOM methods. Older PACS store data on robotic libraries of either tapes or optical disks, and there is a large time penalty for reading them out in an order other than that in which they were written, and that order is not available through the DICOM interface. Early estimates 2 that transfer would take about 30 percent of the time it took to acquire the data have been encountered in recent practice. That would be11/2 years for a five-year old system.
Depending on the chosen migration method; there may also be system performance issues resulting from the burden on attempting to transfer the studies from the old system to the new. It may be that the data transfer routines may simply occupy too much of the new system resources and thereby slow the system down. It may be required to run the migration tasks at off-peak hours to avoid the performance issues.
Also, many PAC systems offer features such as the retention of window and level settings, updates to patient demographics, and references to relevant order and procedure numbers, that are not in the stored DICOM data, but instead are retained in the system's proprietary database. The PACS vendor may insert some of these in the exported DICOM data objects, or they may not, either because the legacy system does not support the relevant DICOM standards, or because the legacy vendor reserved it as a proprietary feature. In general, the older the data and the older the legacy system, the farther it is from current representation and encoding standards, so it is desirable, at the time of migration, to transform these old images, as well