Alan Schweitzer

Like a marriage, a radiology department's relationship with its PACS vendor has its ups and downs. Part one in this two-part series discussed the challenges of an actual breakup, including strategies for maintaining access to prior images during and after the transition and options for migrating data from the old PACS to the new. Part two discusses key issues that may drive a site to look for a new PACS vendor, remedial actions that can be taken prior to a breakup, ways to optimize flexibility and develop an effective prenuptial agreement to avoid being locked in to your next PACS vendor, and steps to minimize the trauma experienced during such a transition.

Just as in a marriage, many factors can lead to a breakup, and a site's decision to part ways with its vendor is usually due to an accumulation of several of these. Many key drivers may lead a site to consider its options:

- System functionality and performance. The most compelling factor is typically a deficiency in system functionality and/or performance that compromises the site's productivity and its ability to make efficient use of the system. Other vendors may offer functionality that the current vendor either cannot provide or can provide only at significant cost to the site. The vendor may have failed either to deliver on promised functionality or to keep the system capabilities up to date with its competitors.

- System stability/reliability. Excessive PACS downtime can severely affect a site's productivity. Poor reliability adversely affects user acceptance of the system and may lead users to develop parallel processes to ensure business continuance when the system is unusable. Reliability problems can originate with either the hardware or the software. If the origin is hardware-related, remedies less drastic than a vendor switch may be available. When the software is chronically unstable, reviewing the site's software testing and update policies and procedures can sometimes be helpful.

- Service and support. A PACS vendor's support services should be an integral part of the total offering. Failure to adequately support the product can seriously affect a site's ability to make optimal use of the system and can fuel a level of frustration that leads to a complete breakdown in the customer-vendor relationship.

- Vendor responsiveness. Most customers will accept a vendor's failure to meet expectations as long as they believe the vendor is taking positive steps to remediate whatever deficiencies exist with the product and/or service. As with marriages, breakdown in a customer-vendor relationship is most often a result of breakdown in communication and lack of good faith in working to resolve problems. Once trust between customer and vendor has evaporated, it can be exceedingly difficult to rebuild.

- Vendor viability and commitment to PACS. The most serious concerns typically arise if a PACS vendor does not appear to be financially stable or is not making investments in continuing to develop its PACS product. In at least one case, a PACS vendor made an explicit decision to get out of the PACS business and stopped supporting its PACS product, forcing its customers to switch to a different vendor. Such decommitments are rare, but large layoffs and corporate acquisitions or mergers can signal challenging times ahead for a PACS site and may precipitate a reevaluation of the fitness or willingness of a vendor to serve its needs.

- System age. An aging system need not, in and of itself, be the deciding factor in switching vendors. Upgrading hardware is relatively inexpensive when compared with the potential disruption of productivity that can be incurred by radically switching software and vendor. Faced with a major financial investment in a system that is not working well, however, a site might wonder if it is throwing good money after bad and stimulate an organized due diligence regarding the alternatives.

- System architecture. An obsolete system architecture can make it challenging, costly, or potentially impossible for the vendor to provide needed functionality and performance. Software products have a life cycle, and products that are created using older software development tools become comparatively more difficult to enhance and maintain. They cannot offer features that products created using current development tools and software platforms include.

The fundamental architecture of a software product is often designed to solve a problem that advancements in technology render irrelevant. In the past, for example, slow networks dictated a distributed storage architecture with autorouting algorithms that attempted to anticipate where studies were most likely to be accessed. Advances in networking performance made this architecture virtually obsolete, and vendors that continued to base their architecture on this model were unable to provide some of the advantages of systems designed to provide ad hoc on-demand access from a centralized storage architecture.

- Opportunity. New opportunities will sometimes precipitate a reevaluation of a site's PACS vendor to ensure that it continues to be the best investment. A major system expansion such as the addition of a new facility or the migration from a departmental to an enterprise system, for example, may prompt a site to initiate such a reevaluation. The opportunity to include PACS as a part of a larger purchase, consolidating the number of vendors and interfaces the site has to deal with, can also be a significant driver.

Since switching PACS vendors can be costly and disruptive to the site, it is generally prudent to explore every avenue with the current vendor to remedy whatever is causing the site to be unsuccessful with its existing implementation. Key questions can guide this exploration:

- Have the major issues been well documented?

- Have the issues been presented to the legacy vendor at the appropriate level, and is the vendor aware of the gravity of the situation?

- Has the vendor been given adequate opportunity to respond?

- Has the site satisfied itself that the long-term strategy of the vendor is unlikely to lead to a satisfactory resolution to the issues?

- Has the site implemented all reasonable recommendations made by the vendor to remedy the issues?

As in a marriage, emotions and personality conflicts can often run deep after repeated disappointments and broken promises, and they can obscure the path to a meaningful resolution. It may be helpful to engage the services of a mediator to identify the most significant failure points and work out a reasonable compromise between vendor and site, including conditions to be met along with a timetable for key milestones to be satisfied. This consultant can be engaged to objectively and realistically articulate the pros and cons of switching vendors.

Both first-time PACS sites and divorcees will want to do whatever is prudent and reasonable to avoid becoming locked-in to a PACS vendor. If you ever need to either switch vendors again or upgrade major system components, you want to minimize the cost and disruption that this transition can incur. A few measures can help:

- Buy storage from a storage vendor. Historically, PACS vendors have lagged behind the storage industry in incorporating the latest technologies. Efficient management of storage resources is quickly becoming an enterprise initiative. While imaging applications such as radiology and cardiology have often driven these initiatives, storage for other applications may be managed more efficiently by centralizing this resource. Choosing the best storage option will require a separate initiative on the part of the IT department. This may lengthen the vendor selection and implementation process, but separating this costly component from the PACS should enable the site to negotiate the best cost-benefit results from both PACS and storage vendors. While this strategy alone does not guarantee that data can be easily migrated to another vendor's PACS, it does provide more flexibility in choosing a storage upgrade path and a degree of independence from the PACS vendor.

- Archive images in DICOM Part 10 format. DICOM Part 10 defines a standard file format for storage that permits multivendor access to image data via a common standard. The standard was created primarily to permit the exchange of image data from removable media such as a CD. Storage in DICOM Part 10 format can, however, facilitate access to these images directly from another vendor's PACS or for migration via file transfer protocols that are potentially much more efficient than DICOM. Alternatively, if the file format must be converted to another vendor's standard, it will ensure that the format of the source files is known.

Many vendors do not internally store images in DICOM Part 10 format, so this requirement may limit choice. The most common reasons vendors give for not adhering to the standard are generally related to optimization of performance and use of proprietary compression.

DICOM Part 10 format stores each image in a separate file with an image header. Many vendors store the header information separately, either in the database or in a separate file. Some vendors combine all images in a study in a single file to improve file handling performance. DICOM Part 10 also defines the allowed image compression standards, and although several standards are supported, some vendors also use a proprietary image compression algorithm.

Prenuptial agreements are drafted based on the collective wisdom of people who have been burned by experience in the past. The key to an effective PACS prenuptial is a clearly defined and workable exit strategy. Understanding the challenges other sites have faced in switching vendors will ultimately help in developing a more comprehensive prenuptial. Some guidelines for prenuptial requirements should be stipulated in any PACS contract:

- Require documentation from the vendor that fully describes the PACS database schema.

- Require documentation describing the formats for any other data stored separately (i.e., neither in the database nor the image files) in a proprietary format (e.g., overlays, annotation, comments, key images, presentation state information).

- Require tools to extract data from database to a flat file.

- Require the vendor to store images in DICOM Part 10 format.

- If data are not stored in DICOM Part 10 format, require the vendor to provide tools to convert files to DICOM Part 10. This should include conversion for any proprietary image compression.

When making the transition to a new PACS, it will be important to determine the phasing of the deployment. Managing such a project can be more complicated than the original deployment of a new PACS. It will require at least all the skills, care, and planning that the original deployment demanded.

Begin by making a clear decision regarding if and how the database and image data will be migrated. The impact on the users' workflow should be carefully evaluated for each scenario. It is important to determine how prior exams will be made available to the users.

If a full data migration is being considered, ask whether it will be completed before the new PACS is available to users. If a delay in the deployment of the new PACS is unacceptable, plan how the workflow will be managed during the time that not all priors are available on the new PACS. If the new PACS can prefetch prior exams from the legacy archive while the migration is in progress, this can help ease the transition. The new PACS vendor will need to provide a way for the new PACS to "know about" exams stored in the old PACS. Typically, this is done by doing a DICOM Query/Retrieve for all exams related to a current patient.

Determine if any hardware components from the legacy PACS can be used in the new PACS, considering how close these components are to obsolescence. Your migration strategy will determine which components of the old PACS must be kept operational either permanently or during the transition. The transition strategy needs to minimize the downtime required to reconfigure any components that will be used in the new PACS.

In addition to the deployment of the new PACS core and the data migration, the plan must also include transition of the imaging modalities, diagnostic workstations, clinical workstations, and enterprise Web viewing facilities, if these components are in place. You may want to partially deploy the new PACS to test its viability and provide a training platform, in which case you may have installed both old workstations associated with the legacy PACS and new workstations associated with the new PACS. Imaging modalities may need to transmit to both the legacy and the new PACS.

Plan carefully regarding how the transition is communicated and coordinated. Informing the old PACS vendor of your intentions can be politically charged, and timing your announcement to secure any needed cooperation can be critical. Prior to informing the vendor, your internal communication may need to be tightly controlled.

All users will need to be retrained to use the new PACS. Carefully plan how this training will be provided in conjunction with the deployment.

Transition to a new PACS vendor implies unique challenges, which should be kept in mind when considering a PACS divorce. While these challenges can be formidable and should inspire an attitude of caution, they are not insurmountable. Careful anticipation and planning can mitigate the impact to the radiology operation.

This is the time for a site to be honest in evaluating what went wrong with the first implementation. No one wants to repeat old mistakes. Minimize your dependence on your next PACS vendor. Approach the PACS divorce with the same care as a new installation, leveraging the wisdom and experience of your first implementation. Whether you are undergoing a PACS divorce or tying the knot for the first time, make sure you have included an adequate prenuptial agreement in your contract with your new PACS vendor.

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. Part one of this series appeared in the August issue of Diagnostic Imaging.

Articles

Part two of series asks if this marriage can be saved and tells how to prepare for future breakups with prenuptial agreement

PACS divorcees learn lessons for their 'second time around'

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.

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.

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.

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.

A radiology department's relationship with its PACS vendor has been likened to a marriage.

Alan Schweitzer

Articles

PACS divorcees learn lessons for their 'second time around'

Smart planning for PACS considers potential breakups