PACS divorcees learn lessons for their 'second time around'

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.

PARTING WAYS

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.

REMEDIAL ACTION

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.

OPTIMIZING FLEXIBILITY

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.

PACS PRENUPTIALS

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.

TRANSITION STRATEGY

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.