10 tips help analyze pricing of systems across vendors

You have just received request for proposal responses from five PACS vendors, each binder thicker than the last. The first section you instinctively locate is, of course, the pricing; but what is behind each of these enormous bottom-line numbers? Are the vendors quoting comparable packages? Are there hidden costs, or have critical components been omitted? How can these quotes be effectively compared?

The adage about comparing apples to oranges accurately describes the challenge you face. PACS quotes can be complicated and cryptic, with vendors providing pricing in their own proprietary formats that make it difficult to compare across categories, components, or specific line items. Some vendors provide bottom-line pricing with little detail, while others bundle hardware and software components separately. Additionally, there may be future cost implications depending on the licensing model utilized by each vendor or on the structure of the extended maintenance agreement. Let's also not forget about "options" that are truly not optional for your organization.

To achieve an apples to apples comparison and decipher PACS price quotes, consider the following 10 tips:

• Standardize the pricing format. The most important step in the process occurs before the quotes are solicited. Evaluating vendor pricing will be much more efficient and effective if you start by creating a standardized pricing format that all vendors must use in responding to the RFP. Vendors should still be invited to provide a quote in their own format as well, as it may provide additional clarification and act as a cross-reference source for verification.

In developing the standardized pricing form, create separate sections for hardware, software, and options and request pricing to the line-item level. A well-written RFP should include a definition and functional specification for each line item. Also, be sure to specify required quantities for each line item, as you do not want to allow the vendors to make guesses on quantities in the quote. For example, the RFP should identify the number of workstations, including type and location; modalities to be connected to PACS; projected exam volume; and storage requirements.

• Build a model to normalize pricing. Using the standardized pricing form as the base, construct a spreadsheet that shows each vendor's pricing data on a single worksheet for a side-by-side comparison. Review responses to determine what is (and is not) provided with each line item. Clarify details with vendors and recategorize line items as appropriate. Be consistent in how options are included and/or separated from the hardware and software sections of the price quote. Finally, determine how the vendor has applied discounting. It may be calculated on a unit price, total line item, or grand total basis. Once the discounting scheme is deciphered, apply discounts consistently to each line item on a per-unit basis to determine the real price.
• Cross-reference. Despite reinforcing with vendors the importance of accurate quotes, it is likely that you will discover errors. If vendors typically quote in a bundle format, it may be difficult for them to break out the components of the bundle in a manner that easily maps to your standardized price form. It is a wise investment of time to carefully crosswalk each quote for accuracy (from the standardized format to each vendor's proprietary format).
• Analyze per-unit costs. In constructing the spreadsheet model, it can be helpful to include per-unit pricing for each line item to allow for analysis of individual components. Include all categories (hardware, software, and services/training) in this analysis. The primary goal of this exercise is to identify unit price variances between vendors that can be leveraged in negotiations. A second objective of unit cost analysis is to facilitate projection of the financial impact of changes to system configuration. Third, if your organization is considering self-purchase of hardware, unit cost analysis allows you to use the vendor's hardware unit pricing as a benchmark to calculate potential cost savings of self-purchase.
• Understand the software licensing model. There are several different models used by vendors to price their software, so it is important to clarify which model each vendor is using and understand the nuances of each. Software pricing models include annual exam volume, per-seat workstation, concurrent users, and application service provider.

The trend in the industry is toward the exam volume model, in which annual exam volume is projected over a five-year period and the vendor determines the software licensing price based on that volume, regardless of the number of workstations or concurrent users. If the volume exceeds a preset threshold, the vendor typically charges an incremental software licensing upgrade fee.

The per-seat model, in which every workstation has a software license, has fallen out of favor, replaced by the concurrent users model. In the latter, software pricing is dependent upon the peak number of simultaneous users logged into the system at any given time. The final model, ASP, involves an annual operating fee and does not require an upfront capital investment. With an ASP, the site does not technically own the system and instead pays an annual fee for its use.

• Identify common variances. While no set rules exist for where variances will surface among vendors, there are several areas where they commonly occur. First is the software licensing model. Careful examination of this component cannot be stressed enough. One common variance to be aware of occurs in concurrent user license schemes, particularly on the clinical viewing side, where vendors often quote different numbers of concurrent licenses depending on the size of the packs or bundles they offer (e.g., 25, 50, 100). Be sure to identify the number of concurrent user licenses the vendor has quoted and the cost of additional license packs. It is often difficult to accurately predict how many concurrent user licenses an organization will ultimately require. For this reason, you may wish to request the vendor quote a purely exam volume-based software license model, since this is more predictable.

Another area where variances are often observed is in system redundancy configurations. For example, one vendor may include a back-up server configuration as part of the base quote, while another vendor lists this as an option.

Variances in storage capacity are also typical. It is not uncommon for vendors to quote storage capacities that are different from the estimates provided in the RFP. In addition, even when you specify that preexisting storage infrastructure will be used (such as an enterprise SAN), vendors will often still include storage in their quotes. When variances like these are identified in the quotes, make sure they are not in the core quote price and move them to the optional items section of the spreadsheet model.

Two final areas that typically involve variances include specialty workstations and interfaces. Be aware that variances in the level, price, and deployment of workstations are a near certainty when comparing one vendor with another. Similarly, differences among vendors in interface solutions, such as modality, laser printer, radiology information systems, and electronic medical record, should also be anticipated and carefully reviewed.

• Evaluate the options. It can be challenging to evaluate the extensive list of options offered by each vendor and identify which are not truly optional for the organization. These required "options" should be incorporated into the total price for the system within the spreadsheet model. Correspondingly, items vendors included in their base system that actually are optional for the organization should be moved to the options section.

One example is redundancy configurations, including clustered servers, particularly for the database management application, and backup servers for either cold or hot backup. These configurations keep the system up and running and thus are not really an option for most enterprises. A second example is 3D image processing. With the continued evolution of cross-sectional imaging, 3D is becoming more of a necessity than an option.

• Compare services and training. Most organizations are so focused on analyzing hardware and software components that costs and levels of service and training are frequently overlooked. Creating an apples to apples comparison of services and training is challenging, but there are ways to minimize the differences.

The first category to examine is project management and staffing. In evaluating each vendor's RFP response, clarify the presence and level of onsite project management, length of time the project manager will be engaged, the number of clients he/she is supporting simultaneously, the budgeted number of project management hours, specialists who will be involved (e.g., service engineers, integration specialists, applications specialists), and hourly rates for time that exceeds budget.

The second category is support and troubleshooting. Examine each vendor's guaranteed response times. If these specifications are inadequate for your enterprise, determine the cost of purchasing premium coverage that provides the required levels. Look at onsite response versus phone response times, off-hours coverage, and whether onsite response times exclude nonbusiness hours. Uptime guarantees also vary from vendor to vendor. Be sure to document what each vendor is offering and how uptime is defined. Last but not least, be aware that obtaining a higher uptime guarantee will typically require greater redundancy options purchased from the vendor.

The final category is training. Each vendor provides a set amount of training in terms of number of days and people, broken down by type (onsite or offsite) and user (technologist, PACS administrator, or radiologist). The vendor should also provide the price for purchasing additional days/hours of training. This will allow you to adjust quantities and pricing in the spreadsheet model to normalize training services among vendors and achieve a comparable basis of costs.

The training strategy proposed by each vendor must also be understood, as it may include a combination of several alternatives including one-on-one training of end users; train-the-trainer sessions to create one or more superusers who in turn train others; or classroom training, which is typically offered only to PACS administrators and is almost always offsite.

• Decode extended maintenance and warranty packages. The principal objective in decoding extended maintenance and warranty packages is not to determine price but to understand what each vendor is offering. On the software maintenance side, determine what constitutes a minor versus major upgrade. Is the vendor willing to commit to a clear definition upfront? For example, when most vendors release what they deem to be a new generation of the product, they will sometimes not include it as a covered upgrade under the software maintenance agreement. Also, beware that for software upgrades that require an attendant hardware upgrade, the hardware will rarely be covered by the maintenance agreement. A final point of evaluation is in scheduling upgrades, specifically, how often the vendor anticipates releasing minor and major upgrades.

Hardware coverage is the second component of extended maintenance that requires decoding. Clarify whether the vendor has in-house technicians or if it outsources its hardware support, as the latter is becoming more typical. Make sure you clearly understand guaranteed response times, the proximity of each vendor's nearest field office to your site, and what personnel the vendor actually has in the area to provide onsite coverage. Off-hours coverage will typically involve phone support, and guaranteed response times will be longer. Don't forget to compare the fees charged for off-hours/weekend emergency on-site response coverage.

• Project additional costs. Variances exist in software license pricing models, extended warranty programs, and other areas. We strongly recommend that a five-year projection of additional software and hardware costs be calculated for each vendor. These calculations should include a scenario analysis to determine the impact of exam volume growth rates that exceed budget, the need for additional diagnostic workstations, or greater-than-anticipated numbers of concurrent users. The accompanying table presents an example of a spreadsheet model that calculates the impact of growth under an exam volume software license pricing model.

Two final considerations involve storage and hardware upgrades. The current trend is to make all images available in the online storage, which consequently increases the storage requirements as the size of the archive grows. But the cost of storage continues to decline rapidly, so avoid overbuying storage upfront. Instead, buy it as needed and include the cost in your five-year projection.

Deciphering the cryptic and varied language of PACS pricing is within your reach. Invest the time and effort in planning and defining the requirements of your organization prior to soliciting quotes, and you will be rewarded with a significantly more efficient and effective evaluation process.

Mr. Panzarella is manager and Mr. Schweitzer is chief technology officer at RCG Healthcare Consulting in Boston.