Migrating data and images from a legacy PACS to a new PACS product is not an easy and effortless task. A facility will need to maintain its clinical operations during the migration process: errors will need to be handled or mitigated; the DICOM interface may not export all the desired information from the legacy system such as grayscale window/level settings and proprietary image notations; and some data may need to be updated to current DICOM standards.

“Conventional migration methodology is that it will take approximately 25 to 33 percent of the time it took to acquire the data to migrate it,” said Fred M. Behlen, PhD.

Behlen, an officer and director of the Homewood, Ill.-based LAITEK and co-chair of the HL7 DICOM working group, recently shared his thoughts on PACS data migration at the 2008 Society for Imaging Informatics in Medicine (SIIM) conference in Seattle.

Keeping an old PACS archive is often not an option. In addition to the technical and administrative complexity of running two simultaneous archives on disparate systems, legacy system support costs, as well as power, space and cooling requirements can be prohibitive. Also, Behlen noted, the support of the legacy vendor for their archive can be uncertain.

For a small practice with a minimal amount of legacy data and limited resources, data migration may be accomplished using the send utility on the old archive and the import utility on the new archive. Open source tools, such as the OFFIS movescu.exe, can be employed to help automate the process, Behlen said.

For most facilities, however, data migration is a considerable task that may best be achieved by outsourcing the task. The group will need to specify its source system, including a history of versions and upgrade dates, as well as the modalities in use, the number of studies, series, images and the physical amount of storage space used. It  also will need to provide the migration vendor with the new system specifications, including the configuration of the hardware and storage system and its sustained data input rate.

The relationship of the RIS and PACS will need to be documented such as the history of modality worklist configuration and utilization and accession number mapping, such as how grouped procedures are handled, will need to be disclosed, Behlen said.

Optional migration features, such as proprietary grayscale settings, are available. These are usually inserted in individual images or included as grayscale presentation state objects that are stored with image data, he noted. In addition, data matching (patient- and/or exam-level reconciliation) and cleansing options should be considered. These resolve misidentified data, such as patient demographics or invalid accession numbers, filter out junk data, such as test images or discarded images, and delete bad data, such as corrupted or invalid DICOM objects or unsupported image types.

Behlen cautioned that a facility should be sure to protect its interests in working with third-party migration vendors, including: finding the right amount of flexibility in its data-migration requirements; scheduling incentives and penalties for migration completion timeframes; and enacting data confidentiality agreements with a selected vendor.

Most importantly, a facility should plan for data migration early on in the process of acquiring its new PACS. Behlen suggested that a group should require outbound migration specifications from a new PACS vendor prior to its implementation and deployment. In addition, a practice may want to consider maintaining a separate long-term or enterprise-level archive that stores images in DICOM media file format.

Lastly, good archive policies and procedures for a current PACS can help ease the transition to a new archive. These include understanding and maintaining the physical infrastructure as well as the logical structure of the data and resisting dependencies on proprietary features.

“Make today’s practices prepare for future system transitions,” he advised.