Michael J. Cannavo

When you give a beagle the scent of something, he just takes off. He pursues the goal relentlessly and single-mindedly. When he finally gets to the end of his search, he looks up, and he does not have any idea where he is.

The preceding anecdote largely defines how many hospitals select their picture archiving and communications systems (PACS). Selecting a PACS vendor and even a PACS product involves more than just defining the right product for the application. It involves looking at the product, service infrastructure, research and development (R&D) arms, installed base, clinical systems integration experience, financial stability, product line stability, and various other factors, all of which should contribute to the final decision. Yet these items alone represent the tip of the iceberg of what is really important. More important than all of these combined is the relationship and comfort factor that has been established between the vendor and the hospital. Witness the decision in which 27 of the 29 evaluation criteria went to vendor A, yet vendor B won the sale. Why? The comfort factor with one vendor compared to the other.

Yet the question remains: Is this the right way to select a PACS vendor? Yes and no. Comfort must factor into the decision making process. Typically the comfort factor with the vendor being consideredor lack thereofcarries 51% of the weight of the final decision. Logic would say it is always a safe bet to choose from a major vendor. Yet is it? The case cited above where vendor B won hinged on a single negative service-related experience that was totally unrelated to the PACS being considered. Was that fair? No, but it is unfortunately the reality of how many PACS decisions are being made.

WHAT MATTERS MOST

When considering a PACS vendor, what matters most, in order of relative importance, are the client/vendor relationship, service, workstation design and operation, integration experience, and the overall value of the proposal.

Digital Imaging and Communications in Medicine (DICOM) standard support is critical, but as with the computer term WYSIWYG (what you see is what you get), the same holds true for DICOM. A PACS vendor can no more be held responsible for the level of DICOM support offered by the modality manufacturer than the modality manufacturer can be held accountable for the level of DICOM support offered by the PACS vendor. If the modality provides native DICOM and DICOM modality worklist, then you have two major pluses in your favor. Missing DICOM worklist from the modality? Factor in $15,000 to $25,000 per device to add this key item that makes data entry so much smoother. Is the modality non-native DICOM? In this instance, serious decisions need to be made about spending the money to make this device DICOM-compliant as the software upgrade cost alone can easily exceed the value of the modality, not to mention the fact that all the DICOM fields desired may not be provided. The pre windowed and leveled video data can be captured from the display console of the modality (called frame grabbing), but the value of this is limited in clinical applications and does not allow nearly the flexibility that data in a DICOM file format does.

HL-7 compatibility is handled by virtually all vendors the same way, using a gateway (or broker) to make the interface between the hospital or radiology information systems (HIS/RIS) and the PAC system or, longer term, between the PAC system and other clinical systems in those facilities that plan to develop a longitudinal clinical patient record (CPR). Only a few systems have truly "brokerless" interfaces, and these are usually interfaces to a specific version of a HIS or RIS. It is important here to focus on what clinical systems you have and what upgrades you may be planning to make in the near term. Pay little if any attention to the plethora of other interfaces the vendor might have to other systemswhat matters is experience in integrating to the particular clinical system you have.

So what do you look at in a PACS vendor? Relationships are critical. Trust is everything. PACS is a long-term sale. Relationships that are formed early on often extend to future phases as well.

SERVICE CONSIDERATIONS

Service can make or break a PAC system. While most vendors offer 99% uptime guarantees, make sure that it covers the entire system and not just a key component, like the server, relegating other crucial components, like workstations, interfaces (modality and clinical systems both) and even web servers and archives, to second or even third tier service levels. All are important. Vendors also have different ways of defining various service levels. Make sure that the service level covers all the key components and not just a single one like the main file server. Also, never accept an uptime guarantee of less than 98%, nor one that offers you the mythical five nines either (99.999%). Both are unrealistic. Keep in mind that even a 99% uptime level allows for 7.2 hours of allowable downtime per month, which is the maximum you should consider in most situations. Avoid vendors who only cover certain components or who offer percentages, as of the total number of workstations as a guarantee of uptime (example: if 7 out of 10 workstations are active then the system is not considered down). Also avoid uptime guarantees that are measured on a cumulative (ie quarterly basis) that would allows a system to be down for nearly a full 24 hour period and technically remain up.

With service, it is much more important to focus on response time than uptime guarantees. Logic dictates that the more service people you have in the region, the better chance you have of getting better service, yet surprisingly, the opposite generally holds true. If there are adequate service personnel in the area, there also are typically more PAC systems to service. At an average cost of 12-16% of the list price of components that make up the system being purchased, service contract costs tend to dramatically exceed their value, especially when compared with the actual downtime experienced and the fact that 90% of all repairs can done by phone. When evaluating vendors, see how many service people they have and where they are geographically located (including backup service). Also check that the time and materials (T&M) rates include minimum charges, and trip charges. A normal ,Monday through Friday 8 AM to 5 PM service call can range in price from $200 to over $1,200 per callout depending on the vendor, with $500 per call about average. Parts are typically additional, but not often required, Software-only support, where available, can easily reduce the service contract cost by half and can be used in conjunction with T&M rates to keep ongoing expenses at a minimum.

The graphical user interface (GUI) of the workstation has the greatest impact on radiologist productivity. While there are differences in the workstation design and components that go into the workstation, the GUI can make or break a PAC system's acceptance. Some systems have a wonderful GUI for radiologists yet require significant technologist intervention. Others have a wonderful interface for technologists, yet a less friendly GUI for the radiologist. A balance needs to be struck between what is good for both entities, although often the radiologist's decision relating to the GUI typically wins out in the end. Keep in mind that the ability of a PAC system to improve technologist productivity, and with it increase profitability without increasing costs, is often championed as a key selling point behind PACS, so this too needs to be considered very closely. When push comes to shove, a PAC system is only as good as the ability of a radiologist to interpret the studies in soft copy form and only as profitable as the technologists ability to direct studies to their destination quickly and completely.

THE STABILITY ISSUE

Product line stability, for all intents and purposes, plainly does not exist, and for good reason. PACS is a constantly evolving and constantly changing product, so asking for a stable product line is asking for a product that will not meet any future growth demands. Most of the leading PACS vendors are currently migrating from a Windows NT® to a Windows 2000® platform for their workstations. One vendor is migrating from a Sun Microsystems operating system to Windows 2000, while others are even planning migration from a Unix® to Linux® operating system platform for their server software. How this impacts performance needs to be clearly evaluated.

It is also important to note that while all products evolve, the stability of the company has no correlation to the stability of a particular product line. One of the leading PACS vendors today has had no fewer than eight different PACS offerings over the past dozen years, and none of them have been backwards compatible with the other. Still, this vendor commands a leading posture in the marketplace because of a perceived corporate stability. The truth is that many of the smaller independent vendors have much more stable product lines than the majors because they cannot afford to go out and buy a new product. If corporate stability is a major concern with a vendor, a software source escrow account can always be drafted and signed.

In an age in which all financial statements are subject to scrutiny, the financial stability of any company is always considered suspect. Unfortunately the financial stability of a company provides neither any indication of how long they will be in the PACS market nor how long they will continue to support certain PACS products they offer. Because large multi-entity enterprises do not have to break out financial records by division, any losses that a division had do not have to be shown, and more often than not are not shown. Even if a particular division has done well (like PACS), in large enterprises this often reflects worldwide sales and not just US sales. Small companies do not have the same benefit as the multi-entity enterprises and because of that can be better evaluated from a financial standpoint.

Corporate stability runs along the same lines as financial and product stability. Again, in larger enterprises, one division may be entirely unrelated to the other even if product lines within  PACS seem to intersect (RIS, networking services, and PACS are one example of this).

Technology is nearly always looked at closely in PACS, yet has no real place in the evaluation process. Many now are probably saying, "Excuse me, but isn't PACS all about technology?" The answer is no. Technology is the means by which PACS solves problems, yet with the exception of various archive offerings, the technology from all vendors is pretty much equal. Most vendors use the same basic hardware and networking options, with product differentiation shown primarily in software, from the workstation GUI to the type of compression used on the web servers. Evaluate the software components and minimize the time spent evaluating CPU speed or disk size. Operational functionality far outweighs technological superiority, especially considering that, from the time a decision has been made on a particular vendor's system to the time it is installed, the technology will be two generations behind the state of the art.

THE VALUE PROPOSITION

The last point to consider is overall value. Notice the word price is not used, but value. Price is the one-time cost; value factors into ongoing cost, service costs, operational costs (including costs associated with FTE's (fulltime equivalents), and the full gamut of costs and benefits associated with a system.

With all this said, it would be easy to develop a matrix with different weigh factors to easily determine who wins, right? Wrong. In virtually every comparative matrix we have developed the difference between one vendor and the next was so infinitesimally small that it rendered the matrix virtually worthless.

The reality of a PACS decision is that most hospitals already know the vendor they want to work with when they begin the evaluation process, or, at the very least, have it narrowed down to a couple of vendors whom they have a high degree of interest in. What is most interesting is that many of these same facilities know the vendors they want to work with yet have no idea how the system will be either cost justified or phased in. A good vendor will ask the site representative a series of questions and listen to their answers before proposing a solution. These include: What problems do you want PACS to solve? What budget have you identified (and how did you come by those numbers)? What features in a PAC systems are important to you (and why)?

A dialogue needs to exist before a solution is developed for a problem that may not even exist or that does not rank high enough on the priority list.

I would venture to say that 90% of the facilities we work with know what they want already in a PACS vendor; putting a vendor name to that is pretty easy if you eliminate the superfluous and often extraneous details that can bog down the vendor selection process and take a closer look at what matters most: client/vendor relationship, service, workstation design and operation, integration experience, and the overall value of the proposal.

Michael J. Cannavo is president, Image Management Consultants, Winter Springs, Fla, pacsman@ix.netcom.com.