Migrating Data to the New PACS

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,¹ 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² 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 as one can, into up-to-date DICOM form. DICOM standards do now exist for all the things you need, so system replacement is an appropriate time to gather this data into DICOM objects. The point here is that in addition to the image data, there is information about the data that will also need to be dealt with in the migration.


DATA MIGRATION SETUP

Figure 2 shows a general outline of a data migration setup. A migration appliance, usually comprising a small cluster of computers in a rack, is connected to the old and new PACS through network connections. A connection to the migration contractor, through a Virtual Private Network, is usually desirable, to enable remote monitoring of the migration process.

For many projects, the highest speed transfers will be available by transfer of data from off-line disk or tape media. A media reader is another rack with reconditioned drives and computers capable of reading the legacy PACS' off-line media. The number of drives, and hence the total speed of transfer, is an economic decision based on the needs of the site. Data thus captured will be buffered into a small repository that can provide the data as needed by the migration appliance and the destination PACS.


THREE BASIC SCENARIOS

Initial assessment of each migration project will generally identify one of three paths available. There are two easy cases, and if neither of these pieces of low-hanging fruit is in reach, then we have to apply the general solution.

1. There are some cases where one can do DICOM extraction from the old PACS. If the old system has adequate bandwidth, if there's not too much data to migrate, if you can afford to wait to get things migrated, this is the preferred path. In this case, the migration appliance just has to manage the data streams, follow scheduling constraints for the migration process (for example, faster transfers overnight and weekends and no transfers during morning peak load periods), and verify fidelity of transfer at the completion of the project.
2. Second, in cases where images are stored in complete and valid DICOM data objects, and/or the new PACS has the ability to validate the incoming data, we might be able to stream the DICOM objects right into the new PACS directly from the storage media.
3. If neither of these methods will work, then we will have to work the general transfer case. In general transfer case, one needs to know the internal organization of the legacy PACS. Image data is read directly from the storage medium - optical disks, tapes, mass storage arrays. Information is extracted from the PACS database and combined with the image data, processed, formatted and transmitted to the new PACS. It is assumed that all data will be input to the new PACS through a DICOM interface, but vendor-specific input methods may be used to speed transfer.

GETTING IT DONE

While it is theoretically possible to perform the migration yourself by using tools that you build, buy or rent, it has the disadvantages of clouding vendor responsibility, endangering the schedule, and consuming staff resources just when they are needed most for managing the transition from the old system to the new system.

So if you are considering a switch from one vendor's system to another, the most practical solution is to specify data migration services into the PACS Request for Proposal and insist that vendors include the cost for performing the data migration as part of system installation costs.

A note here about the politics of migration: The displaced vendor may be concerned about the new vendor gaining access to their system. The reason for the reluctance is that in the process of managing the data migration certain information about the database schema and the core applications will be exposed to the party managing the migration. It is understandable that the displaced vendor would not want the new vendor to be able to examine what they would consider their intellectual properties. Additionally, the terms and conditions of the original PACS vendor's contract may have clauses that prohibit reverse engineering and potentially the data migration may be considered as an attempt at reverse engineering. The involvement of a neutral third-party to perform the data migration services may avoid the potentially thorny and disruptive vendor issues.


CHOICES TO MAKE, REQUIREMENTS TO SPECIFY

When specifying data migration in a system replacement, getting the required set of images with correct identifying demographic data is a minimum requirement, but other characteristics or data items are options that you may or may not migrate depending on their cost, which will vary by legacy PACS and by new PACS vendor. The best procurement strategy will set minimum requirements in the RFP and identify other items as desirable features. Some characteristics to consider in writing your specification include:

• Changes to patient demographic data (required) Some systems make changes only to their database entries, and not to stored objects, when a correction to patient demographic data (name, patient ID, sex, birth date) is entered. Correction to demographic data should be applied when the data is migrated, and a record of the changes should be retained.
   
• Data objects to be migrated In addition to the common image types, the legacy archive may contain retired image types, or other DICOM objects such as waveforms or Radiation Treatment Plans, or even images or other items that are not stored as DICOM objects, that you may not choose to migrate if the cost of their conversion exceeds their value and other methods of retention (such as printing hardcopy records for a small number of odd objects) are available.
   
• Speed of migration More rapid data migration may cost more for the services themselves, but also saves money elsewhere. Data migration can hold off the new system go-live until at least the minimum acceptable amount of data (typically the most recent six to 12 months) has been migrated. And of course, the whole migration has to be complete before the old system can be decommissioned and removed, and during this time, you have to pay support for the old system. This lengthening of the sales-and-installation cycle ties up money, people and equipment for the vendor, and prolongs the disruption of conversion for you. Rapid data migration almost always requires getting into the innards of the legacy system, to get at information not in the DICOM objects or to rapidly extract data in the order it was stored.
   
• Window/Level settings The legacy PACS may store presentation and gray scale settings used in interpretation, but in older systems these settings are usually stored in the (proprietary) PACS database, and not in the DICOM objects. On migration to the new system, these settings can be either inserted into the image objects or placed in DICOM Gray Scale Presentation State objects (a more recent addition to the DICOM standard). Gray scale settings used in interpretation show what the radiologist saw when looking at the images. These values may be important for medico-legal reasons, and you should plan on some method of extracting them from the old system before it is removed.
   
• Key image selections Radiologists may designate images of interest, such as those best illustrating the findings for the referring physician. These are now supported by DICOM Key Image Notes, but if supported in the legacy PACS, they will generally be stored as an entry in the PACS' internal (proprietary) database, and the migration should convert them to the DICOM form.
   
• Order and scheduled procedure numbers Order and procedure numbers link the images to the orders they fulfill and the reports created from them. These numbers, if present, may be stored in various DICOM attributes, such as the DICOM Accession Number or attributes in the Request Attributes Sequence, according to conventions that have been confused in the past and have evolved over time. It may be desirable to "clean up" these attributes in the migration process, to make them consistent with usage in the new PACS.
   
• Reports Diagnostic reports stored in PACS are usually copies mirrored from the radiology information system, stored for convenient review in the legacy PACS. More recently, it is common to access the radiology information system directly using Web protocols when reports are desired, so PACS-to-PACS transfers of reports may not be necessary. If the new system does keep copies of reports, it will generally have an HL7 feed from the radiology information system to keep it current, and preloading historical reports through that channel may be best.

CONCLUSIONS

Data migration is a problem that must be addressed in replacement of a PAC system. The alternative of keeping the legacy system for legacy data is rarely economically viable.

A lengthy migration period entails major costs for both you and the replacement system vendor. Accelerated methods of data migration require going inside the legacy PACS to extract data in the most efficient order, to gather information needed to update data to current formats. Involvement of a trusted third-party as the migration contractor may ease the barriers to cooperation with the legacy vendor.

Data migration is an intensive process that places high loads on the legacy system, which must still be in clinical service while migration is in progress, before the legacy system can be replaced. Managing the data migration project requires detailed assessment and planning to ensure that the migration schedules are met.

Fred Behlen, Ph.D., is president of LAI Technology, which provides research, development and technical services in medical imaging informatics. Jim Maughan is the principal of Maughan Consulting, which provides PACS and RIS consulting services for healthcare providers and industry vendors. Dr. Behlen and Mr. Maughan, as associates, provide a portfolio of consulting services including technology planning, workflow assessment, vendor selection, DICOM, and data migration planning and execution. Mr. Maughan can be contacted by email at jfmaughan@yahoo.com, and Dr. Behlen can be contacted at fbehlen@laitek.com

¹ F.M. Behlen, K. R. Hoffmann and H. MacMahon, "Long term strategies for PACS archive design", Proc SPIE, 2711, 2-8, 1996.

² F.M. Behlen, "A DICOM document-oriented approach to PACS infrastructure", J. Digital Imaging, 11:3 Suppl. 1, 35-38, 1998.