AuntMinnie.com presents the latest installment in a series by PACS consultant Michael J. Cannavo exploring commonly accepted PACS theories -- as well as industry secrets your PACS vendor might not want you to know.
Never before PACS has something so simple been rendered so complex by a group of vendors. Unlike revolutionary systems such as CT, MR, ultrasound, and PET that are entirely new technologies, PACS is, for the most part, nothing more than specialized applications software running on off-the-shelf computer hardware, all integrated with clinical information systems.
Why, then, is it so hard for a vendor to put together a system that meets a client's needs? Why are PACS networks so expensive? Why do vendors seemingly play so many games with clients, and why do clients, in turn, play so many games with vendors?
The first question is actually a little more complicated than it looks. The next two questions relate more to customer tolerance levels than anything else.
Unlike the modalities, which require only a detailed understanding of the technology and its application, designing a PACS to meet the demands of a hospital or imaging center requires at least a basic understanding of radiology workflow. Unfortunately, very few of the individuals directly involved in a PACS sale usually have any detailed radiology background.
This typically leads to systems that are either dramatically underengineered, creating performance nightmares, or dramatically overengineered, costing end users hundreds of thousands of dollars more than they probably should have. Even worse, very few of the people who help make the PACS purchasing decision understand or even care about radiology operations. As a result, they spend more time vying for project control than creating a workable system. This battleground was addressed in detail in Part II of the "Exploring PACS secrets" series.
Garbage in, garbage out
The computer adage, "garbage in, garbage out," most accurately reflects one of the biggest problems facing PACS today: getting the right information so a system can be designed properly. Bad information leads to bad system design.
But what happens when all the right information is given to a vendor and the system still fails to meet expectations? The vendor gets blamed.
It's important to understand that the majority of the people preparing RFP responses for the vendor have either never been in a radiology department, or at best have limited exposure to radiology operations. They simply don't understand radiology workflow issues, especially the importance of radiologic technologist workflow and its impact on PACS.
Many simply provide templated responses based on hospital size and imaging volume, plugging in catalog numbers to create a "custom" configuration. I have seen so many improperly configured systems that I'm beginning to question why it's happening. Is it confusion or a simple misunderstanding on the proposed system configuration? Or is it more?
Moreover, end users can't question a system design if they don't understand baseline parameters. The reality is that even the most educated end users rarely understand PACS configurations, especially in the confusing manner in which they're presented in a vendor quote.
What's funny (but really isn't) is when I find myself discussing components in a quote with vendors and even they don't understand the configuration they have presented. The job of the PACS product specialist is to ensure that the system is properly designed and meets the customer's expectations; unfortunately, many product specialists have only a slightly greater depth of knowledge of radiology operations than their RFP specialist counterparts, and are often focused more on making quota than ensuring a proper system design. There are exceptions, but not as many as one would hope.
Logic also seems to play a very small role in system configurations. Each vendor has its own reasoning with regard to system design. Two RIS interfaces sometimes require two completely different systems (not just interfaces). Why? Because that's the way we do it.
Want to use your own disaster recovery schema? Sorry, yours just won't work with ours. Why? Because that's the way we do it.
I find such answers fascinating in light of the stated goals of the Integrating the Healthcare Enterprise (IHE) initiative that the industry so heartily embraced more than five years ago. IHE's goal is "to stimulate integration of healthcare information resources by demonstrating that systems can operate efficiently in standards-based, multivendor environments with the functionality of real hospital information systems, providing increased functionality rather than redundant interfaces."
The goal is admirable, but we're a long way off from being anywhere close to it. Despite their comments to the contrary, vendors simply don't like to play with other vendors, and almost go out of their way not to play together. This is especially prevalent with RIS integration, and even extends to modality integration.
Should PACS vendors bear the blame for their failure to properly design a PACS system for a client? Not entirely. Fewer than one in five facilities provides the vendor with the necessary information about the facility that will allow the vendor to design a workable, cost-effective PACS, even if it could.
Even worse, half of the information provided is either woefully inaccurate or understated. End users often (but not always) have no more of a clue to what they are doing in defining and selecting a PACS or even a configuration than the vendors do.
I had one potential customer who recently sent me this statement in an e-mail: "... (we) did not detail what (we) really wanted so it was left up to the vendors to determine the true need of (our facility)."
By not defining their requirements, they set themselves up for failure. That was obviously not the right thing to tell them -- they went with a consultant who was much more politically astute than I was -- but if the kid is ugly, there is no changing that fact. And in this case, the kid (or project, rather) was just plain butt ugly.
Is integrity dead?
Is there a place for political correctness (PC) in PACS? Obviously there is, but to what end remains to be seen. Vendors configure and sell systems for sites that obviously are no more ready for PACS than two teens with raging hormones are ready to be parents.
Yet they are sold and bought daily. And just like the teens, the end users fumble through a PACS implementation, sometimes for years, wondering what on earth they really have done and how they got themselves into this mess. A PACS consultant could have told them they weren't ready for PACS, but like the example above, many facilities just don't want to hear that.
Worse, the majority of PACS consultants make vendors look good in terms of their integrity. Few, if any, will turn down a job because, as one consultant put it "if they are going to spend their money anyway, it might as well be spent with us." It's a sad but true reality of our industry.
A committee of one?
One of the biggest barriers to success in PACS implementations is often the committee. Put 15 members on a committee and you'll have one of two scenarios: at least 15 opinions all voiced strongly, or no opinions at all.
In all my years of doing PACS consulting, I've seen maybe a half dozen PACS evaluation committees that actually worked well. Those that did respected each person's area of expertise and worked as a team. Most important, the committee chair was given the authority to make a decision on behalf of the facility, basing the decision on everyone's feedback rather than the opinions of a few.
Nothing is worse than being rendered impotent by a radiologist or other individual on the committee who is hell-bent on having his or her way, even if it's at the expense of the facility. Unfortunately, I see this time and again, and the process goes out the window in favor of making a decision that is "PC."
Committees also love doing projects, from interviews to departmental workflow analysis. This makes sense with a new PACS implementation in which you can chart pre- and post-PACS process changes.
Where PACS already exists, however, it's like writing a book to guide you through raising your third child; you just don't need it. Still, built into nearly every major vendor's PACS contract are charges from the vendor to use its internal PACS consulting group to do process and workflow analysis, regardless if the facility had PACS before, had an outside consultant do the analysis, or did an internal analysis.
These charges can add $40,000 to $100,000 or more to the system price. Don't need it? It doesn't matter. It's almost always a non-negotiable part of the deal and factored in basically to increase margin.
Pressure? What pressure?
The games vendors play are many, and will be outlined further in subsequent articles. Uptime guarantees can go as high as 99.999%, but only if you have elected to have a fault-tolerant system that adds another $100,000 to the bottom line, and if you purchased a service agreement.
The kicker is that without fault tolerance but with a service contact, the vendor will typically give you 99.9%+ uptime, but fault tolerance without a service contract gets you absolutely no uptime guarantee at all, or at least no uptime guarantee if you don't negotiate one.
Is the added cost to gain an extra 0.09% or even 0.99% worth it? Categorically, undeniably not. So why do people spend the money? Fear, uncertainty, and, most of all, vendor pressure. (For an overview of service contracts myths and fallacies, see Part I of "Exploring PACS secrets.")
Only a few key components are included in the uptime guarantees, and they usually apply only during limited hours. And exclusions to coverage typically far exceed what one would expect, especially considering the asking price.
Finally, system failures, while they do occur, are infrequent and involve software -- not hardware -- 95% of the time. In the vast majority of the cases, a simple reboot solves the problem, and $300,000 a year or more for a service contract (on a $2 million system) pays for a whole lot of system reboots.
Who's No. 1?
PACS is also the only industry in which rankings change like the wind, and there are lies, damn lies, and statistics. Rankings from KLAS, Frost & Sullivan, ECRI, and others show the fickleness of industry and users themselves. Rarely was the same vendor No. 1 for more than one survey period, with almost every vendor in the industry being at or near the top (or bottom) at one time or another.
Vendors can plunge from top to bottom in a New York minute. Even more surprising is the sudden rise of previously unranked vendors to the head of the KLAS seemingly overnight. Fortunately the criteria to identify vendors have become somewhat more stabilized, and rankings somewhat easier to justify.
Also fascinating is seeing the winners of various industry awards. A vendor that got a scathing review for ongoing problems with its installed PACS software by one industry analyst was named Healthcare Information Technology Company of the Year by yet another a month later. How can that be? Welcome to PACS, where the only consistency is inconsistency.
Statistics in our industry also never cease to amaze. I recall looking at market projections in the early '90s that said PACS would be a $1 billion industry by 1992. A dozen years later we're finally there -- I think.
I also love the study from yet another industry analyst that had PACS pegged at a 93% adoption rate in 2002, including a 67% rate for 400- to 499-bed hospitals and 47% for 300- to 399-bed hospitals. I, and many others who have been in PACS since the mid-'80s, would just love to know just where these PACS networks are installed. But the fine print explains it all; these are "facilities using some sort of PACS."
Considering that electronic imaging systems have been around in one form or another since Colorado Video's slow-scan analog systems in the mid-'70s, one hopes 30+ years later that the technology has adopters, even if many were fairly late adopters.
What matters most
So how can things change in PACS? And is change necessary? The reality is that most vendors and their representatives are honest. You have to ask the right questions to get the right answers, though.
Few if any will offer to provide you with what you really need to know, even if it's a positive for them. As my kids have said to me once or twice: "I didn't lie to you, Dad. You just didn't ask me about that." And they're right. It's the same with PACS.
Unfortunately, you have the benefit of teaching your kids that leaving information out is as critical as what is actually said. Vendors are more like children who have never been disciplined, doing it because they can and never having been told they can't.
End users need to stop being like teens who think they know it all, and admit that maybe they need to learn a few things about PACS before making a multimillion-dollar, career-altering decision based on what often amounts to a flip of the coin.
I'd always felt that none of us is as smart as all of us, yet the worst consumer is an uneducated consumer. And the worst vendor is the one for which the bottom line isn't its customers' best interests, but the company's.
PACS is a part of the healthcare environment today. Like change, we can embrace it or fight it. More than anything else we need to play to win, and winning requires skills, talents, and a thorough understanding of how the game is played.
By Michael J. Cannavo
AuntMinnie.com contributing writer
December 16, 2004
Michael J. Cannavo is a leading PACS consultant and has authored nearly 300 articles on PACS technology in the past 15 years. He can be reached via e-mail at [email protected].
Cannavo's direct, straightforward approach may have caused him to lose the race for this year's Dale Carnegie "How to Win Friends and Influence People" award, but he hopes that this series has shown PACS in a different light, and provided him with a modicum of respect for honesty and integrity in an industry where these values seem to have become a rare commodity.
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
The 2004 PACSman Awards, December 1, 2004
Part IV: Exploring PACS secrets -- RSNA edition, November 18, 2004
Part III: Exploring PACS secrets, September 17, 2004
Part II: Exploring PACS secrets, July 6, 2004
Part I: Exploring PACS secrets, May 14, 2004
Copyright © 2004 AuntMinnie.com
