If a request for proposal (RFP) doesn't precisely express key requirements, a vendor will make its own assumptions regarding the customer's requirements. Without clearly defined performance requirements, vendors will often assume performance standards that fall below a customer's expectations and, as a result, propose an underconfigured PACS.
Finding that workstation counts and configurations, as well as software and hardware sizing and configurations, vary between vendor proposals is not uncommon. In fact, it's not unusual to see an RFP of 100 pages or more, to which vendors respond with stock materials and marketing sheets that can fill a 3-inch binder.
Accordingly, customers spend a great deal of time and effort wading through vendors' responses only to find that the proposals fail to meet their requirements and cannot be compared on a meaningful basis with competing vendor proposals.
Workstation requirements
Not all RFPs clearly state the number, type, and configuration of workstations to be included in each vendor's proposal. Because the different types of workstations (diagnostic, clinical, or Web clients) will differ drastically in both purchase price and service costs, it is impossible to evaluate and compare proposals unless they are all designed to satisfy the same workstation requirements.
That said, even if the RFP is precise with regard to workstation requirements, the customer may still receive responses that propose different workstation configurations to meet the customer's requirements. For example, a PACS for a thin-client, Internet-based architecture will require less robust and less expensive workstation hardware than a PACS that is designed for fat-client architecture.
In addition, certain PACS vendors will recommend more quality assurance or quality control workstations (sometimes referred to as tech workstations) on the basis of the workflow supported by the vendor's PACS. The RFP process must ensure that these differences, to the extent they exist, are the result of differences in the architecture of the vendors' PACS, and not a misunderstanding of the customer's workstation requirements.
Projecting exam volume growth
The sizing of a PACS, both from a hardware and software perspective, is an essential element in any successful PACS acquisition. No PACS administrator or information systems (IS) manager wants to request, sooner than expected, additional capital to purchase additional hardware or software licenses.
Accordingly, the RFP should include the current exam volume and number of concurrent users, along with projected volume and user growth over a specified number of years (for example, five to seven years following system acceptance). On the basis of the projected exam volumes, the RFP should specify the sizing requirements for all software licenses, server hardware, and all levels of storage.
Sizing software licenses and server hardware
From a software perspective, each vendor should be required to include in its proposal sufficient software licenses for the customer's current and projected exam volume, as well as licenses for concurrent users over a specified period of time (such as five or seven years following system acceptance).
With regard to server hardware, the RFP should specify that all servers be configured with adequate size and processing speed to accommodate the projected exam volumes and concurrent users for at least four to five years, which approximates the useful life of most servers. Sizing of the storage hardware presents other issues that must also be addressed in the RFP.
Storage solution requirements
Typically there are three levels of PACS storage. The first level, primary storage, provides radiologists and clinicians with the quickest access to the most current images (usually the most recent 18-24 months of images).
The second level, long-term storage, will store all images as they are acquired, including copies of images stored in the primary storage. The third level, disaster recovery storage, includes a copy of all images stored in the long-term storage for use in the event of a loss of both primary and long-term storage.
Storage hardware represents a substantial portion of the acquisition costs of all PACS, and the costs of expanding the storage capacity will be a significant expense during its lifetime. Accordingly, it is critical that the RFP specify the following:
- Type of storage hardware to be included in each vendor's proposal
- Sizing assumptions each vendor should make in configuring the storage hardware
- Amount of storage to be included as part of the initial acquisition
There can be substantial price differences between different types of storage hardware; therefore, the RFP must specify the type of hardware to be included in the vendor's proposal, such as storage-area network (SAN), direct-attached storage, or network-attached storage (NAS). The primary storage solution is typically configured with the fastest and thus most expensive storage hardware.
Long-term storage is typically configured with less expensive hardware that does not meet the same performance specifications for image retrieval time as the short-term storage. This is because images on the long-term storage will be retrieved and displayed less frequently than those on primary storage.
During the 1990s, PACS long-term storage solutions were typically configured using optical disks, DVD jukeboxes, and LTO tape libraries. In recent years, with the availability of less expensive spinning disk storage for use with PACS, there is an increasingly strong preference in favor of configuring long-term storage using the faster spinning disk hardware.
The disaster recovery storage will only be called on in the event that both primary and long-term storage is lost. This level of storage can be configured either with the same hardware as the long-term storage (such as a spinning disk storage device), or with the less expensive, albeit slower-performing, storage hardware and media such as DVD or LTO tapes. Accordingly, in setting the requirements for disaster recovery storage, the customer must weigh the cost of the different hardware options against the amount of business interruption, and the degradation in system performance that would be acceptable in the event of a disaster.
The RFP should set forth clearly the type of hardware the customer requires to be included for each level of storage. There are, however, some PACS vendors that have qualified their software on only one type of storage hardware.
For example, there are vendors that have only qualified their software on less expensive NAS hardware. The RFP must be designed to ensure that any such differences among the vendors' proposed storage hardware, to the extent they exist, are the result of differences in the architecture of the vendors' PACS, and not a misunderstanding of the customer's storage requirements.
In addition to specifying the type of storage hardware, the RFP must also specify the sizing requirements for all levels of storage. As noted above, primary storage, because of its high performance requirements, is usually the most expensive.
Customers often limit the size of primary storage to the amount necessary to accommodate exams that are most likely to be retrieved by radiologists and clinicians. For example, many customers will require that the primary storage be adequately sized to accommodate 18-24 months of the most current images, based on the assumption that this will cover the vast majority of the images that will be retrieved for display.
Long-term storage and disaster recovery storage hardware, on the other hand, will store and maintain a copy of all images generated during the life of the PACS. The RFP has to specify how much long-term storage and disaster recovery storage must be included in each vendor's proposal.
Because storage costs have historically fallen over time, most customers are not willing to include more than two to three years of storage as part of an initial purchase. Accordingly, customers will often require the long-term storage solution be configured to be expandable to accommodate the projected exam volume over a long period of time (such as seven years), but include disk drives sufficient to store two or three years of exams as part of the initial purchase.
Performance requirements
The customer's requirements and expectations regarding PACS performance will also affect the hardware configuration. For example, if the customer expects a high availability configuration (i.e., with guaranteed 99.99% uptime), the customer should require as part of the RFP that each vendor include a high availability, fully replicated, clustered server configuration that will achieve 99.9% uptime.
The added software and hardware costs can be significant. In the absence of clearly stated performance requirements, vendors may assume performance requirements that fall below the customer expectations, and as a result propose an underconfigured PACS.
The most effective RFPs clearly articulate the customer's specifications, and require that each vendor proposes a PACS that is designed to meet a common set of specifications and requirements. Otherwise, the customer may find itself expending a great deal of time, energy, and money comparing and evaluating the difference between an apple and an orange.
By Jeffrey Ganiban, J.D.
AuntMinnie.com contributing writer
November 24, 2004
Ganiban is vice president of Innovative Health Strategies, a strategic advisory company that assists healthcare organizations with procurement and outsourcing solutions, and provides a full range of consulting and legal services -- from technology needs assessment to contract documentation and project implementation. He can be contacted at 202-230-5150 or [email protected].
Related Reading
Part III: Exploring PACS secrets, September 17, 2004
PACS procurement: Three starting points for success, August 17, 2004
Part II: Exploring PACS secrets, July 6, 2004
Parsing PACS components can lower the price, May 22, 2004
Part I: Exploring PACS secrets, May 14, 2004
Copyright © 2004 Innovative Health Strategies
