Streamlining PACS Data Migration

The market for PACS implementation services was earmarked to reach $273 million in 2005, representing more than twenty percent of the total PACS market, according to the 2004 North American Turnkey PACS Markets report by Frost & Sullivan. Numbers like these testify that PACS is becoming more of a services industry, in which PACS is no longer seen as a product but rather as a solution that incorporates the related services. Among these services is data migration, or the transfer of data from one archive system to another. Before undertaking a PACS migration project, healthcare facilities can utilize PACS consulting services to assess their situation, explore different options and estimate the time and cost required for the data migration project. Some PACS companies now specialize in data migration, and established PACS vendors are starting to compete in this niche as well.

Replacement PACS
PACS have been in use for more than 10 years now, with an estimated installed base of more than 1,700 systems in North America alone. A PACS that is more than five years old might have become too slow to support the facility’s current workflow, have limited connectivity to other information systems in place or might not provide the desired enterprise scope supported by newer systems. It might not handle the newly acquired multislice CT, or its service plan might simply have expired. An estimated 136 sites required replacement PACS in 2005, and the demand for replacement PACS is expected to grow at a compound annual rate of twenty-four percent through 2010. On the vendor side, replacements are expected to account for an increasing part of the business. Replacement sales were estimated at $179 million in 2005, or 13 percent of the total market, including only forklift upgrades and migrations. As healthcare facilities contemplate migrating to a second- or third-generation PACS, a major issue they face relates to the terabytes of patient data that have accumulated over the years since the data needs to be migrated from the legacy PACS to the new PACS. This applies primarily to facilities that wish to change PACS vendors, but could also apply to those that will be upgrading to the current vendor’s next-generation PACS, as it is common for vendors to change their system’s architecture over time.
Compliance with the recent HIPAA Security Rule might also necessitate a data migration project. As facilities develop a disaster recovery strategy in order to ensure PACS business continuity, they may need to migrate the archive data to a secondary depository. Similarly, switching to an ASP for disaster recovery storage and long-term archiving, a major trend in the PACS market today, requires migrating the data to a remote archive.

Know Your Options
As with any long-term project, it usually pays to first spend some time assessing the requirements. Consulting services can provide an approximate count of imaging studies to be migrated, evaluate the quality of the data by sampling studies across the archive and provide a detailed road map for the entire process. A straightforward approach to data migration is to use the DICOM query/retrieve interface of the legacy PACS archive, whereby DICOM studies are retrieved, one by one. The benefit is a standard connection to the legacy archive, but the process can be slow. Several sites reported a timeframe of more than a year. With the increasing number of data migration projects, a rule of thumb is that the process would require one-third of the time it took to acquire the data. That is, for an archive that holds six years worth of data, it would take two years to migrate the data. However, some strategies can be used to accelerate the process. (See sidebar “Data migration from a DLT jukebox: Do the math!”)

Avoid Bottlenecks
When using DICOM query/retrieve to migrate the data, the bottleneck might occur in the network bandwidth or in the throughput of the legacy archive DICOM interface. So, one might think, since the data consist of files, why not copy those files directly off the archive storage medium, hence bypassing any processors, networks and DICOM interfaces that would slow down the process?
There are in fact several challenges involved with this technique. Media formats, data structures of a file system for example, may be physical-media specific, proprietary or may depend on the operating system that was used. The DICOM protocol is built above the physical and data link network layers and ensures media format and physical media independence, a task that would need to be replicated. In any case, one would still need to determine the location of the files on the storage medium, which would require obtaining the database schema from the legacy PACS vendor.

Check the PACS Database
DICOM files alone will not be sufficient for the new PACS system. The database must also be populated with patient information, the type of study and the acquisition date – data that is also contained in the legacy PACS database. Another reason to look into the PACS database pertains to data integrity: Images are sometimes acquired and archived under incorrect patient information. Corrections made afterwards appear in the PACS database, but are not reflected in the actual DICOM files, since storage is in a write-once format. The DICOM Q/R command, however, takes into account the PACS database and updates the files as it sends them over. A tight RIS/PACS integration can also help with this matter, as changes made to any of those systems are propagated in both systems’ databases. What’s more, image data may have been compressed in a proprietary format other than those supported by DICOM. Therefore, copying data directly from the storage medium requires custom engineering of an interface between the legacy and new archive, in addition to specialized migration hardware, often incurring elevated costs. The major benefit is time savings, as the migration can attain up to a terabyte of data per day.
Requesting proprietary or PACS database information from the legacy PACS vendor also raises the question of intellectual property protection, as it might be perceived as an attempt at reverse engineering. The need to ‘break into’ the PACS database places the legacy PACS vendor in a suitable position to provide a fast migration service, or to cooperate with a third-party vendor who would be perceived as neutral with respect to intellectual property clauses. The services of these companies are typically more expensive than those of OEM vendors, but the expertise may save a substantial amount of time.

Minimize Workflow Disruption
Perhaps the most significant challenge associated with a data migration project is to minimize the disruption of clinical workflow during the rather long timeframe involved. One way to achieve this is to perform the migration during off-peak hours. However, this is not an option when users expect 24/7 access to the system and tolerate no downtime. Algorithms in recent data migration software products feature optimization algorithms, which, by using RIS information such as patient scheduling or users’ session, proactively utilize the archive server’s time. Another option would be to migrate the data from the disaster recovery archive, which should be in place as of last year’s April 20th HIPAA deadline.
Besides employing strategies to minimize disruption of the ongoing clinical work, it is important to make the data migration as seamless as possible from the user perspective. This raises the question of what can and cannot be migrated. The answer varies according to the type of archive. Generally, any information that is packed into a DICOM file can be migrated. This, of course, applies to imaging data, but may also apply to radiologist work product such as: identified key images; custom windowing and leveling; annotations; and custom hanging protocols. A DICOM file can store information provided that the legacy system supports the corresponding DICOM objects described in DICOM Key Object Selection Information Object, DICOM GSPS (Grayscale softcopy Presentation States) and DICOM Supplement 60 (Hanging Protocols), respectively. Unfortunately, this is unlikely for older systems.

Cleaning House
While generally lengthy and disruptive, a data migration project can actually allow a healthcare facility to get on a fresh start with respect to its archived data. Indeed, it presents a good opportunity to upgrade DICOM files to DICOM’s third and latest version, which requires morphing the DICOM tags from version 1.0 and 2.0. A feature of advanced data migration software products on the market today is data cleansing, whereby DICOM fields are corrected, filled out or verified. The PACS migration project should also motivate the facility to adopt strategies to simplify data migration in the future.
One of the hardest lessons to learn is the value of planning. It is mainly at the time of migration that one deplores using proprietary databases and formats, not using DICOM objects systematically, and, perhaps most importantly, not planning ahead and discussing earlier a potential breakup scenario with the legacy vendor. It has become essential nowadays to include the PACS migration task in the request for proposal for a new system, and associate its costs with the implementation services. Not only would that make it the responsibility of the future vendor, it would also help streamline the next PACS installation process and place more guarantee on the go-live date. Also, since it is typically faster to migrate data out of magnetic disks, this is an additional motivation not to use tapes anymore (except for disaster recovery) and use online storage instead, such as large, expandable RAID disks. Following IHE guidelines, in particular the Consistent Presentation of Images (CPI), Key Image Notes (KIN), Enterprise User Authentication (EUA) modules, to which newer PACS solution increasingly comply, will pay off when the time comes for the next migration.