Home

Cover Story

Table of Contents

E-Newsletter

Article Archive

Editorial Calendar

Datebook

Writers' Guidelines

Orgs/Links

Opinion Polls

Reprints

Forum

For other articles and previous issues click here.

April 26, 2004

Protecting Your PACS Purchase
By Jeffrey T. Ganiban, JD, and Stephen S. Boochever
Vol. 5 No. 9 p. 8

Not long ago, PACS primarily focused on image storage, retrieval, and viewing within radiology departments. Today, it’s evolving into a mission-critical component of a broad enterprise system, including billing, management, and an electronic medical record.

Implementing a PACS remains expensive and complex. And the playing field certainly isn’t level between vendors and institutions, no matter how large or sophisticated the customer. To help level the field as you pursue PACS, heed the following 13 factors for making a decision you’re more likely to love over the long term.

1. Mandate from the executive leadership. PACS touches almost every clinical department within an imaging facility. It presents new demands on information technology (IT) resources and becomes one of the most significant points of contact between the customer and physicians. As a result, decisions regarding the selection and implementation affect different constituencies with different concerns, perspectives, and agendas. Successful PACS projects begin with a clear mandate from the customer’s executive leadership that PACS is a strategic priority and a critical component of a broader enterprise technology and patient safety initiative.

2. Strong executive participation. Without senior executive involvement, a vacuum often forms and the different stakeholders mire down the process and even cause it to spin out of control.

3. Firm, consistent project management. A strong project manager, especially for multiple-site implementations, cannot be overestimated. This person will evaluate as many as seven or eight initial proposals, manage the flow of information, and coordinate internal resources. This position presents substantial challenges and demands. In the absence of a dedicated project manager, a member of the PACS selection team (usually one with other significant departmental responsibilities) or an outside PACS consultant will assume responsibility for the project. Be careful in this phase because part-time project management with sufficient time dedicated to the PACS project may extend the vendor selection and contracting processes by several months, increasing costs accordingly.

4. Clearly defined specifications. Lengthy requests for proposal (RFP) that ask for voluminous information about functional and technical specifications are common but often fail to establish clear system specifications and service level requirements. As a result, the PACS team may find it difficult to compare competing proposals or reconcile them with their actual requirements. A more focused, concise RFP reduces the amount of time and effort required to obtain useful comparative information.

Financial Analysis
5. Understanding total cost of ownership. Many customers acquire PACS without understanding the system’s total cost of ownership over five, seven, or 10 years. The total cost of ownership analysis should drive final configuration determinations and contract terms. The model should include the amounts that will be paid to the PACS vendor for the acquisition, implementation, ongoing support and maintenance of the PACS, and software and hardware updates, as well as the customer’s projected costs to upgrade infrastructure, deploy peripheral products not purchased from the PACS vendor, and to train users.

One often overlooked element of ownership is the cost to expand the PACS to accommodate the customer’s projected exam volume growth and expansion of the PACS deployment to clinical areas throughout the enterprise.

6. System sizing. Each bidding company should be required to configure the proposed system to accommodate the customer’s projected exam volumes. From a software perspective, this means each vendor must allow for sufficient software licenses to support projected exam volumes—including anticipated growth. On the hardware side, vendors should warrant that the servers are configured with adequate size and processing speed to accommodate the current exam volume and projected growth.

Storage Issues
Projected exam volumes will also directly affect the sizing and configuration of the PACS back-end storage solution. Typically, PACS requires three levels of storage. Primary storage provides online storage for the quickest to current images. It is typically configured with the fastest, and thus most expensive, storage hardware. The size of primary storage must be included in the RFP.

Long-term storage includes a copy of all images (including those in primary storage). Because long-term images will be retrieved and displayed less frequently than those in primary storage, this backup is typically configured with less expensive hardware. In the 1990s, long-term storage solutions were typically configured using optical disks, DVD, jukeboxes, and tape libraries. In recent years, faster spinning disk storage for PACS combined with falling prices for spinning disk technology have pushed more users toward hard drive-based long-term storage.

Disaster recovery storage includes a backup copy of all images stored long term for use if both primary and long-term storage fail. It can be configured either with disk storage or less expensive (albeit slower-performing) storage hardware and media. Off-site Web-based disaster recovery storage is another option.

The PACS team will decide how much hardware, disk space, and storage media to include in the initial configuration, but expect to add storage later as needed. The purchase agreement should include a pricing metric for future hardware purchases and reserve the customer’s right to buy additional storage hardware from either the original equipment manufacturer or a third party.

7. Network integration. The project manager or team should investigate the details of integrating the PACS with a radiology information system and other facility information systems before purchasing. PACS customers often find themselves saddled with inefficient workflow, large unanticipated costs, and resource demands. Don’t skimp on the due diligence regarding the level of system integration and interoperability. Make sure the decision makers consult with your IT staff to understand how both your current system and the potential PACS support the appropriate Integrating the Healthcare Enterprise profiles. These industry-standard profiles document how images and data should flow throughout a healthcare enterprise and among various information systems.

8. Implementation. The resources and costs involved in implementation should be detailed in the final PACS contract. Many customers discover that the PACS company based its quoted implementation costs on assumptions that differ greatly from the customer’s assumptions; that difference can be costly. Avoid such surprises by requiring rigorous project planning from vendors before executing the PACS contract. For example, before the PACS contract is signed, the vendor and customer should prepare a preliminary, but very detailed, project plan. This plan should be part of the PACS contract and define the vendor’s responsibilities regarding how the implementation project will be staffed by both the vendor and customer.

Change Order Process
In addition, the PACS contract should provide a clear change order process. As part of this process, the vendor should be required to notify the customer in advance that the vendor believes a particular service represents a change in the scope of the implementation and therefore would be subject to additional fees. The customer’s approval of such additional charges would be required before the service is rendered. The vendor should not be able to retroactively characterize a service as an “out-of-scope” service subject to additional fees.

Finally, the PACS contract should clearly specify whether or not travel and lodging costs are included in the quoted implementation costs. This is an often overlooked detail that can end up costing the customer a substantial amount of money.

9. Performance-based payments. PACS companies typically propose payment terms that are front-loaded with few performance contingencies. Often, the customer will have paid 80% to 90% of the purchase price and all the vendor will have done is signed the contract and delivered the hardware and software. Customers should insist upon substantial back-end payments tied to final clinical acceptance and delivery of agreed-upon features and functionality.

10. Data migration. While owning the data and images stored in its PACS, a customer is completely reliant upon the PACS vendor for access to those data and images. There is no industry standard for storing DICOM images. Customers can only access and display images using its vendor’s proprietary software. A future migration to a new platform requires the incumbent vendor’s support and data conversion/migration tools. Negotiate future access to those tools and support into your original PACS contract.

11. Protecting future pricing. No matter how good a deal a customer negotiates when it acquires a PACS, those savings and discounts can prove illusory without aggressive price protections on future software license and hardware purchases. Without such protections, the PACS company can simply recoup initial discounts and price concessions when the customer needs to add software or hardware from the vendor. To avoid the trap of paying “wholesale” for the acquisition of the PACS and “retail” for all future purchases, negotiate up-front future pricing commitments from their PACS vendor.

12. Performance standards. Once the PACS has been successfully installed and accepted, the customer still needs a mechanism for measuring the PACS’s performance. The two most common performance measures are system uptime and system response time.

During RFP negotiations, most PACS vendors will guarantee 99.9% uptime. Customers often find, however, that the vendor’s definition of what constitutes downtime is so narrow that the guarantee has little value. Clearly define “downtime” in the PACS contract. Downtime should cover both software and hardware failures. More importantly, the contract should include substantial financial penalties if uptime standard is not met. Such a clause ensures that resolving downtime remains a priority for the vendor.

Response Time Standards
The contract should also include specific response time standards. The standard should measure, for example, the time it takes to display a single image and to display the first and last image from a series of images, as well as the time it takes before the user is able to manipulate the image. Response times should be measured across the customer’s fully loaded network during both peak and nonpeak activity times. The response times should also be measured for images retrieved by various different workstations (diagnostic, clinical, and Web clients) from the different levels of storage (primary and long-term storage). If the system fails to comply with the system response time standards, the vendor must be responsible for providing additional hardware or software required to bring the PACS into compliance with the agreement.

13. The contract. PACS contracts are almost always based upon the vendors’ contract forms, which—not surprisingly—strongly favor the vendor over the customer. The vendor’s attorneys have the benefit of having prepared dozens of PACS contracts, while the customer’s attorney usually has had limited experience with them. A PACS contract, if prepared properly to protect the customer’s interests, isn’t just another equipment contract. The buyer’s counsel should be knowledgeable about the technology and critical customer protections to be negotiated and documented. The RFP responses, demonstrations, and the dialogue in the sales process mean little if they’re not written into the final contract. A winning PACS contract needs to be a team effort from the beginning. The customer’s counsel should evaluate key contract provisions throughout the selection/negotiation process. Involve counsel from the beginning—don’t just hand them a contract at the end of the process.

PACS implementation poses pitfalls for both first-time buyers and institutions replacing legacy systems. Following the guidelines of the procurement process described in this article not only better protects the customer from unanticipated costs, performance deficiencies, and suboptimal productivity, but also enhances the benefits of PACS.

— Jeffrey T. Ganiban, JD, is a partner with Akin Gump Health Strategies, LLC, Washington, D.C.

— Stephen S. Boochever, JD, is director and partner of Akin Gump Health Strategies, LLC, Albany, N.Y.

Subscribe to Radiology Today Magazine!