A rhetorical question is a figure of speech in the form of a question posed for its persuasive effect, without the expectation of a reply -- for example, "Why me, Lord?" Rhetorical questions encourage the listener to reflect on what the implied answer to the question must be; it is a device to assert or deny something.
Now, I'm neither asserting nor denying that PACS will survive, yet I often get asked rhetorical questions about its future.
I think everyone can fairly confidently say that PACS will survive, but not in its current form. Most vendors are reacting to the state of the current economy with knee-jerk reactions, some to remain profitable, while others just to stay alive. Unfortunately, this is neither good for the companies nor the marketplace.
PACS has become a 2X market. Sales take twice as long to close as they should, vendors spend twice as much as they should to close a sale, PACS cost twice as much as they should, and twice as many vendors are in the market than it can support. Vendors also make at least half the net margins they should. So how did we get into this conundrum and how do we get out of it?
Let's start with the first issue: sales lead time. The FUD factor -- fear, uncertainty, and doubt -- has played an incredible role in end users hesitating to pull the trigger. Uncertainty about the impact of the Deficit Reduction Act, Medicare reimbursements, and the like has affected the decision-making process, with many facilities waiting and watching instead of acting.
Some vendors have responded by pulling out all the stops to generate sales, while other vendors have begun to panic, especially those public companies who have publicized their quarterly sales predictions. Those who panic do the first thing that comes to mind: drop the sale price as an incentive to speed up the sales process.
Discount levels as high as 75% to 80% aren't uncommon in multimillion dollar sales, with 20% to 25% discounts from list price the normal starting point for most companies, even in sub-$100K sales. The problem with this is that except for the smallest of companies with low overhead, most companies can't survive making gross margins of less than 40%. Anything less translates to negative net margins and companies just can't survive on net margins.
PACS has basically become a commodity sale. Seventy-five percent of the net margin now comes from the software portion of a sale; 15% to 20% from installation, training, and related support services; and 5% to 10% from hardware sales, if that.
Indeed, with the exception of many of the majors that require (at a minimum) that they provide the server hardware to ensure uptime "guarantees" (which for the most part aren't worth the paper they're written on due to numerous exclusions), most companies now either allow end users to buy their own hardware or pass the hardware through at, or slightly above, cost.
Because most PACS vendors make most of their money through software and services (and many end users are getting smart to the service contract game that provides the vendors with the vast majority of their profits), this leaves almost nothing for the company to survive on. Even though a company might show a 40% margin on a $400,000 software sale, a $160,000 net margin doesn't go very far.
The average PACS sale, at least from the majors, still costs $25,000 to $40,000 just to get in the game, especially if a request for proposal (RFP) is involved. With the best companies winning one in three or one in four sales, that brings net margins to anywhere from $85,000 down to nothing. Now factor in the cost overruns that every single PACS implementation has (and if a vendor says they don't have cost overruns, they lie about other things, too) and suddenly the net margins are negative.
So how do you rectify this situation? For one, sales costs must be reduced. Too many of the majors and many of the independents, as well, continue to treat a PACS sale like a modality sale. Frankly, it's not.
As stated before, PACS, for all intents and purposes, has become a commodities sale, much as any other application software. Sending a warm body to answer a question that can just as easily be handled by phone doesn't make any sense, any more than sending six suits to attend a meeting when one will suffice.
Site visits?
Paying for five or six clients to go on a site visit also makes very little sense, especially given the costs associated with the visit and, most important, the time away. Most of the due diligence obtained from a site visit can be done by phone.
Seeing a PACS in action does help some, but how much? Seeing a functioning PACS that may not be the same software version that you are getting, may not interface to the same RIS, may not travel on the same network with the same load, and may not be supported by the same depth of IT resources, etc., is tantamount to having an engaged couple spend a weekend with a married couple so they can really see what married life is all about.
Sure, you can see some of the interpersonal skills needed to make a marriage work, but the individual variables and dynamics are so disparate that you really can't understand the situation with enough depth to make an informed, objective opinion. And so it also goes with PACS site visits.
I'm even starting to question the merits of onsite demos, although it is certainly easier to get a group of radiologists together when they know a workstation will only be there for a day or so than getting them to do an online, Web-based demo at their convenience.
End users have to be willing to make certain sacrifices, too. Whether recognized or not, PACS is largely a relationship-based decision, although price is becoming more of a factor than it ever was. That said, the business relationship can be sustained without daily or even weekly personal contact.
Yes, customers want answers, but they also want systems that are competitively priced and the comfort of knowing that a company will be around in years to come. Companies losing money don't instill any confidence at all. While only a handful of dedicated PACS companies are publicly traded, their stock performance in recent months would give any investor nightmares.
The major companies are no better off, either. The majors can, and often do, hide their PACS losses under their corporate umbrellas, offsetting PACS losses with gains in other areas (while recent workforce reductions from the majors tell the story like it really is). So who is making money in PACS? Only the smart companies ... and those companies are few and far between.
Why do PACS cost so much? A lot of the end cost is related to supporting the organizational infrastructure. Typically, the bigger the organization, the higher the infrastructure costs that support the product.
This in turn leads to higher (in some cases, much higher) product prices. This doesn't mean that the higher-priced products don't have additional features that justify their increased prices, but rather that the pricing differential between higher-priced and lower-priced products usually isn't anywhere near linear in nature.
Conversely, lower price doesn't necessarily mean that a product is lacking in features. Software cost, while a major part of the financial equation, is one of several parts of the total end-user system cost equation. The level of support relating to systems integration, project management, training, systems implementation, contracting, service, etc., provided by the vendor all contribute to the final quoted cost, in addition to the aforementioned sales-related costs.
This leads to the question: Is there a correlation between system cost and performance? More often than not, the answer is no.
PACS differentiators
The basic differentiators between most PACS are their workstation feature sets, although the server application has differentiators as well. Unfortunately, not every site needs every feature. Every PACS offers the same dozen or so basic workstation feature sets and most also include advanced features such as maximum intensity projection (MIP), multiplanar reformatting (MPR), and 3D, either in the package or as options.
A lot of the product differentiators, though, are included feature sets that either may not appeal to or be needed by all radiologists. This is one reason why radiologists need to do a thorough assessment of the diagnostic workstation software, making sure that it has most of the features they want and figuring out how to address those they don't want.
That said, at least in a production reading environment (e.g., nonacademic), the reality is that radiologists have virtually all they need in the basic tool set and will use the advanced tool sets maybe 20% of the time, if that. How easy the basic tool set is to use is paramount; the rest is important but nowhere near as important as the basics. Some radiologists would have me burned at the stake for making the blasphemous statement that they don't need every bell and whistle. But sometimes reality can hurt.
What about system implementation cost or system support (service) and cost? Most companies charge a percentage of system costs for project management, implementation, and training, typically around 15% to 20% of the quoted system costs. Unfortunately, there is rarely any direct correlation between actual customer requirements and what is ultimately charged for costs related to support services.
Some customers require more services than what are quoted, while the majority requires fewer services (and most, much less). All are often charged the same flat percentage, though. In an organization in which the PACS needs to be completely turnkey and there is limited IT support, the flat-rate approach probably benefits the customer.
A new approach is needed, though, for most hospital environments and in multisite outpatient imaging centers where IT plays a central role in the implementation and training process; this significantly reduces the need for vendor support (or at least not to the level that is typically quoted).
A $400,000 implementation can include $60,000 to $80,000 in support services. At a billable rate of $2,000 per day, that means 30 to 40 days of support services are included. Is this required? Probably not.
A $2 million sale at those same percentages could easy reflect $300,000 to $400,000 in support services. In an initial PACS implementation, maybe half of this fee would be required, with a large chunk of the costs dedicated to items such as PACS workflow redesign. With a replacement system (currently about one in four PACS sales today), this clearly defines overkill.
Individual requirements
So what's the answer? Negotiate a fixed rate for each area required and clearly define your individual requirements.
PACS system administrator training needs to be done both onsite and off, so don't skimp on this. Project management also is a requirement, but this needs to be done on both sides, not just from the vendor; make sure you factor this in as well.
Software implementation also should be done by the vendor, so factor in those costs. If the vendor offers prestaging services, in which the system is set up and fully operational before it ships to you (right down to having IP addresses programmed in), you should opt for it. Generally, this cost should not exceed 5% of the net system cost and is worth every penny.
Whatever you choose, clearly define the roles and responsibilities of each party and agree on the projected time required to do the implementation. Add a 20% "fudge factor" and agree upon a fixed price for implementation or a daily rate with a "not-to-exceed" cap. Make sure you also factor in travel costs (which typically add 15% to 20% to the already negotiated fees) and cap these as well.
Workstation training requirements really should be minimal -- a day or two, maximum -- as most software is fairly intuitive (besides, the radiologists will learn on their own anyway).
What about postwarranty service? Service costs again have no correlation to the actual amount of service provided. Almost every PACS sale includes service, but when you look at a PACS design, you have to wonder why. After all, the hardware is often covered by the hardware provider directly at a fee that is a fraction of what the PACS vendor will charge (usually 3% to 4% per year if purchased in advance, about 25% of what a vendor charges).
So why do 99% of all PACS include a service contract? The answer, pure and simple, is habit. Every imaging modality is covered by a service contract, and rightfully so. After all, you can't run down to the computer store and pick up parts for a CT or MRI. Even if you did, the repairs might be well outside the scope of what the hospital biomedical department can address.
PACS, on the other hand, consists primarily of off-the-shelf computer components and application software. Most PACS service contracts price out at 14% to 20% of system list price, not the actual discounted costs. This translates to 17% to 25% of system cost (depending on discount level), or basically the end user spending as much as it would cost to buy a full replacement PACS after four to five years.
Of course, after five years or so you will need to do a full hardware and software refresh anyway, so it's like buying two full PACS over the return-on-investment period, not one. Does this make sense? Not to me, but then 99% of all PACS buyers buy service contracts, so what do I know?
A service contract is only mandatory for one reason: Most companies will not provide you with software updates unless you have it. Updates are a fancy word for software bug fixes. They do not provide added functionality like upgrades do; they basically fix what you have already bought and paid for. Most software companies in the commercial world provide you with upgrades at no charge when you buy their software products -- Microsoft Windows operating systems are a perfect example of this. Most even provide you with upgrades to the firmware (hardware instructions) as well, at no charge.
After all, as the theory goes, you bought a product that is supposed to work properly, so if they find problems with it, they should fix it at no charge. And PACS? The only way you get updates to the software product you paid tens of thousands, if not hundreds of thousands, of dollars for is to buy a service contract at an additional annual fee.
Is this fair? Is this logical? Is this ... well, you get my drift. It's not all that and more. It's PACS. Most end users would gladly pay 5% of the software cost to get telephone support and software updates (which, incidentally, should be free), but a flat 15% to 20% of list price without any reasonable justification just doesn't cut it anymore, at least not in my opinion. If the vendors are more reasonable, then the end users will also be more reasonable.
PACS has outgrown its "Field of Dreams" phase. The "If you build it, they will come" times are gone, and many vendors, even the majors, are finding out that just being in the game or being considered a leader in the marketplace is not enough to sustain ongoing sales. In addition, many end users have "been to the game" already and aren't willing to pay the high ticket prices to see the same thing over and over again.
There is no question that PACS will survive, but changes need to be made -- and made fairly quickly. Vendors need to change their entire approach to the marketplace.
The flat-rate approach needs to go out the window, with customers offered customized solutions from pricing to service to support services. End users, in turn, need to stop their hemming and hawing and take the Nike approach and "Just do it." They also need to stop wasting vendor money, making vendors respond to RFPs that already have a fairly certain outcome, and end the costly and often fruitless game playing that has plagued this industry for years.
Once these changes finally happen, the future of PACS, while never in question, will find the market overcoming its current challenges and thriving once again.
By Michael J. Cannavo
AuntMinnie.com contributing writer
July 22, 2008
Michael J. Cannavo is a leading PACS consultant who has authored nearly 300 articles on PACS technology in the past 16 years. He can be reached via e-mail at [email protected].
The comments and observations expressed herein do not necessarily reflect the opinions of AuntMinnie.com, nor should they be construed as an endorsement or admonishment of any particular vendor, analyst, industry consultant, or consulting group. Rather, they should be taken as the personal observations of a guy who has, by his own account, been in this industry way too long.
Related Reading
Part XIX: Exploring PACS Secrets -- The truth about DRA and PACS, March 27, 2008
Part XVIII: Exploring PACS Secrets -- Hiding out in plain view: PACS at HIMSS, March 10, 2008
Part XVII: Exploring PACS Secrets -- The state of the PACS market, 2008, February 7, 2008
The 2007 PACSman Awards: Great expectations, November 29, 2007
Copyright © 2008 AuntMinnie.com
