A radiology department's relationship with its PACS vendor has been likened to a marriage. Both the vendor and the site have usually invested a great deal of time, energy, and resources in choosing the right partner and in attempting to make the PACS work.
What happens when that relationship breaks down? Parting with your PACS vendor can be disruptive and painful. But a site does have options in calling it quits and seeking out another partner. Protecting yourself during the prenuptuals can ensure that you are not locked in to your vendor and can minimize the trauma experienced during such a transition. But several issues remain of great concern in managing a transition to a new PACS.
As in marriage, prior to taking such a drastic step, it is useful to understand how much you are joined at the hip to your partner. This helps you to either gain an appreciation for whether it might be worth trying to remediate the relationship or plan for the disruption and costs associated with a breakup. The elephant in the room in a PACS breakup is the need to plan a strategy for maintaining access to images stored on the legacy PACS during and after the transition.The most daunting task facing the potential PACS divorcee is determining the best way to ensure that images stored on the existing PACS are available for prior comparisons and retrievable for legal requirements. Most IT conversions face the challenge of providing access to historical data, and there are several options to consider. Migrating the data to the new system is usually the most desirable from the perspective of the end user. PACS presents the unique challenge of having very large data sets.
Depending upon how long the PACS has been deployed and the annual exam volume acquired by a site, migration of image data can take months or even years. Providing access to prior exams while the data migration is in progress and deciding when and how to make the transition to the new PACS take careful planning and execution.
MIGRATION CHALLENGES
Before deciding on the proper course of action, it is helpful to understand some of the challenges that a PACS data migration can present. The data in PACS include both the image data files and a database, the latter typically implemented using an off-the-shelf database manager such as Oracle, Sybase, or MS/SQL.
Image data files contain the image pixel data preceded by an image header, which includes patient demographic and exam data, and information that describes the image. The database contains textual information about the patients and exams, sometimes called metadata, and pointers to the associated image data files. While virtually all PACS vendors conform to the DICOM standard when transmitting data over a network between vendors (e.g., from an imaging modality to PACS, or from PACS to another vendor's workstation or PACS), no standard exists for the structure of a PACS database.
Data migration therefore requires either transmitting all image data from the old PACS to the new PACS via DICOM or exporting patient, exam, and image pointer data from the old PACS database and importing them to the new database. While the latter method would in theory shorten the data migration time to hours instead of months or years, it is fraught with challenges that make it unworkable for most conversions.
Many vendors do not archive the images in a standardized format. DICOM Part 10 specifies a standard file format for storage of images to facilitate their exchange among different products, but many vendors, sometimes for legitimate reasons such as performance optimization, do not adhere to this format internally. Vendors may also apply a proprietary compression algorithm to the images. To make matters worse, some of the earlier PACS long-term (tape or optical) archival subsystems used proprietary device drivers and file systems.
Changes made to the data after the images are acquired, such as corrections to patient demographic or exam records, are typically stored on the database and not included in the image data. Annotations, such as left and right marker corrections, are also typically stored in the database and not with the image data. It is therefore necessary not only to import pointers to the old image data in the new PACS database, but to import the patient demographic and exam data and any other data not stored in the image files from the old PACS database.
Additional challenges frequently present themselves independent of the data migration methodology used. Although DICOM includes a standard for image annotations, some vendors do not comply with this standard, and it is quite common for annotations not to be interpreted properly when sent from one PACS to another. The loss of left/right marker corrections is typically the most clinically significant consequence of this incompatibility.
An additional complication for many sites occurs if the image data in the legacy PACS were not acquired using DICOM Modality Worklist or RIS validation typical for most modern PACS implementations. The image data should therefore be validated against RIS patient and exam data when they are migrated to the new PACS to ensure that these historical exams can be identified properly as relevant priors.
Even when active RIS validation has been in effect, the migration process will often uncover anomalies due to data entry errors, corrections that are not fully propagated, or software bugs. RIS validation is therefore recommended during all migrations. The migration process needs to incorporate an algorithm to perform this validation and generate an exceptions list, which will require human intervention to determine the proper disposition for each exam that does not pass validation.
Accessing Priors
Many options are available to provide access to prior exams during and after the transition to a new PACS vendor:
- Dump the electronic images and revert to film. The most draconian approach is to simply start over and revert to film during the transition. This, of course, is practical only for sites that have continued to print and archive film. This option will generally have limited appeal but may be the simplest approach for a site whose PACS implementation never really got off the ground.
- Preserve the legacy PACS core. Most PACS, including older implementations, provide DICOM Query/Retrieve services to their image archive. Many newer PACS vendors can perform a DICOM Query/Retrieve to a legacy PACS archive whenever a new exam is acquired and import the appropriate patient's prior exams. In this scenario, prior exams are migrated on demand. This method does not circumvent image annotation incompatibility or RIS validation issues, but it avoids the creation of an explicit data migration process. The transition can appear to the end user to be relatively seamless, since priors are automatically retrieved in the background.
A disadvantage of this strategy is that, unless a separate method is used to migrate the legacy exam data either from the RIS or the legacy PACS, patients who have not had imaging exams after the new PACS was implemented will not show up at all in the new PACS. The site must continue to rely on the old PACS vendor for support of the old PACS core until the images are no longer needed for either clinical or legal requirements. This can take five to seven years for adult exams and up to 23 years for pediatric exams. Typically, the components that must be kept operational are not only the long-term archive, but the database manager, RAID storage, and image management components-essentially the entire PACS core.
- Use DICOM migration. The most common transition strategy is to migrate the data in the background via DICOM transmission from the old to the new system. This is generally done by developing an automated procedure, or software program, for performing DICOM Query/Retrieve requests to retrieve all exams from the legacy archive. This process is typically run in the background, and, if combined with an on-demand process that retrieves priors related to current exams, the transition to the new PACS can be made before all (or any) exams are migrated.
Since the migration process can take months or years, it is important to have the ability to track its progress and automatically restart the process at the appropriate point when it is interrupted, which will inevitably happen. The procedure should also include RIS validation and exceptions handling and appropriate resolution to any incompatibilities related to annotations. Typically, the new PACS vendor can assist with the migration process or can propose a third party to provide the expertise, software tools, and hardware necessary to support the migration.
The disadvantages of this method stem from the fact that DICOM is not a terribly efficient protocol. Transmission at one site was measured at 7000 to 8000 exams per 24-hour day from an online (RAID) cache on the legacy system. Retrieval from a tape archive can be significantly slower. Because the migration process can take months or even years, depending on the volume of data to be migrated, it must be actively monitored and restarted when interrupted. If migration is started before the transition to the new PACS, the additional demand that the migration process puts on the legacy system can affect normal operations, especially if data are being migrated from tape. Migration may need to be confined to off-hours, prolonging the process even further.
- Preserve legacy storage component. If the storage component of the system has a computer industry standard file system such as NFS or NTFS, and images are stored in DICOM Part 10 format or a format that the new PACS vendor can directly incorporate, it may be possible to avoid having to physically migrate the image files from the old PACS storage device.
This strategy requires exporting the patient and exam metadata and pointers to the images (file and path names) from the old PACS database and importing them to the new PACS. It requires close cooperation from the old PACS vendor or someone who has access to the database schema, technical assistance from the new PACS vendor, and the development of software tools to facilitate the database migration. It also assumes that the file and path names to the files on the legacy storage component are compatible with the new PACS.
These are a lot of conditions that need to be met, and this is therefore the least likely alternative. But if it can be done, it offers the quickest migration path, with conversion time measured in hours rather than months or years. Generally, the storage subsystem can be supported by a storage vendor, eliminating dependence on the legacy PACS vendor.
NEXT MONTH
In Part 2, we will discuss some of the key issues that may drive a site to look for a new PACS vendor, the kinds of remedial actions can be taken prior to a breakup, how to optimize flexibility and develop an effective prenuptial so you are not locked-in to your next PACS vendor, and techniques and strategies for minimizing trauma experienced during such a transition.
Mr. Schweitzer is chief technical officer with RCG HealthCare in Boston. He provides consultation services for the planning, procurement, vendor selection, and implementation of PACS and RIS.
