When I look at how buyers select a PACS vendor and how PACS vendors find a buyer, it reminds me of my own life and some of the decisions I made. Some were good, many weren't and, well, if I knew then what I know now ... let's just say many decisions -- and outcomes -- would probably have been different.
I am constantly imploring my clients to perform as much due diligence as they can before buying a PACS. That said, the reality of the PACS decision-making process is that no amount of due diligence can properly prepare you for the purchase of a PACS, just as no amount of reading books can prepare you for the realities of marriage or raising kids. It's just the nature of the beast.
 |
| PACS consultant Michael J. Cannavo. |
Yes, love at first sight does exist, and you hear about marriages that have lasted 50 or 60 years when someone has only known the other person for a very short time, but these are exceptions to the rule. Not so with PACS.
Once you make the decision and sign the contract, only a divorce can get you out of it, one that is neither cheap nor easy. Costly decisions that last at least five years and often longer should not be based on a short, canned "this is what we have to offer" workstation demo that really has minimal benefit to the purchaser, if any.
So would a longer demo help? Allowing a potential purchaser a week or more to evaluate the workstation versus the few hours typically afforded for most demos may be somewhat better, but it isn't the same as actually seeing the system operating in a clinical environment interfaced to the various systems used at your site.
The sad reality is that few, if any, vendors will do an onsite demo for longer than a day. The reason for that is -- just like with someone you are dating -- the longer you are with them the more you find out things you really don't like about them, or areas where you may consider them "deficient."
I recall at least three vendors who years ago would allow potential clients to use their systems gratis for 90 days, and if you didn't like it, then no hard feelings, they would pull it out. Fast forward to today and there is but one vendor that I am aware of that still offers 90-day demos, and their requirements for an evaluation are fairly onerous.
Interestingly enough, about 95% of clients who demoed systems this way ended up buying from the vendor. This may have to do more with the reality that any PACS is better than no PACS -- after all, a starving man doesn't ask for a menu -- and because they now have a PACS installed, changing horses midstream makes no sense.
There are also political sensitivities that need to be addressed as well, because someone obviously had to select the system to be demoed, and deinstalling it would not look good for them. Seeing a PACS working in a site like yours is a bonus of you can get it, but because 99% of the vendors don't do this, you have to look for substitutes. This is where a site visit may come in.
The site visit
I have never been a strong proponent of site visits, and for good reason. Most of the visits I've been on were more like congressional junkets than real learning experiences -- a reason to wine and dine a client who pretty much has made the decision to go with them already. Done properly, however, a site visit can be beneficial. Unfortunately, most people just don't do them properly.
It's crucial to do as much of the technical, functional, and operational due diligence ahead of time -- making calls, talking to the right people, asking the right questions, etc.-- and then following up with what you see on site.
By their very nature, site visits are not designed to answer questions you already should have had answered weeks beforehand. Instead, assign well-defined roles and responsibilities to various team members and let them bring this information back to the team for discussion.
Radiologists should be responsible for the diagnostic workstation review. As the users of the clinical workstations, you need to pay close attention to the graphical user interface (GUI) and how the various applications (RIS, dictation, speech recognition, etc.) interface on the radiologist's diagnostic workstation.
On a site visit you need to see how the workstation is being used by the radiologists at the host facility, working alongside them to see if you can relate to how they perform similar tasks at their site. Evaluate the number of mouse clicks and steps it takes to perform each task, and then see how well this fits with the current way you operate.
At both a site visit and an onsite demo, individuals need to work from a check-off script. This script needs to address features and functionality relative to the way you run your practice. Take the time to write down everything you do, because if you don't, when you go to implement the system you'll realize you forgot to assess something critical.
Because a vendor shows you a feature its system can do, it doesn't mean you'll actually use it. So what difference does seeing it make? Truth be told, few radiologists will change the way they currently practice -- after all, we are all creatures of habit -- and most want to keep the status quo even if there may be a better way of doing it.
Most facilities let the radiologists review the diagnostic workstation and largely base their decision on that feedback. Although radiologist productivity is unquestionably important, and buying a PACS the radiology group doesn't like isn't exactly the wisest move you can make, the workstation must be recognized as merely one part of the total system.
How the RIS interacts with the PACS is also key, especially if speech recognition is part of the overall solution. Ask direct, pointed questions and have the vendor show you how it works. Some examples:
- Load a large study (coronary CT angiography, for example). As the study is loading, try and bring up images. Now process the study using advanced visualization toolsets.
- Show me how the PACS viewer works for the referring clinicians -- what steps need to occur to send images, reports, etc. Is this manual or automated? What do they see? Can these be set up by a doctor or only by a PACS systems administrator?
The technical review needs to be separate from the workstation review, and it takes a lot of time. The IT department needs to take the lead here, just as the radiologists are handling the workstation review. A detailed technical review of PACS system design including the hardware, networks, interface strategies, and implementation plan should be the absolute minimum consideration.
This is typically done well before any site visit is made and involves a minimum three to four hour discussion with the vendor's technical support staff, not sales and marketing types. Preliminary discussions should also precede this meeting based on the vendor's response to the request for proposal (RFP), reserving more detailed technical discussions for the technical review. The chief information officer/chief technical officer should also be involved in these discussions.
With electronic health records the current rage and federal stimulus dollars being offered like beads at a Mardi Gras parade, many facilities have either implemented or are evaluating the use of a centralized vendor-neutral archive for clinical data storage. This needs to be addressed very carefully by IT, including provisions for what a facility is doing for disaster recovery.
Radiology administration should talk with other administrators about training approaches, service support, costs, and items of a similar ilk, and get an overall feel for the company: How responsive are they? What did you like? What didn't you like? And so on.
Prospective buyers need to show how their facility operates, and use this as the basis of the demo. If at all possible, make a flow chart of your current radiology process, take it with you on the site visit, and compare it with what you saw. How will the way the system works for them compare against your own workflow?
Canned demos of what the vendor feels you need to see simply don't cut it. Be prepared to explain how you want the system to operate and to see how it operates in a clinical environment, as well, even if that environment is substantially different than yours (but hopefully not too different). What is the same? What is different?
Focus on your needs versus wants -- what's crucial, what isn't -- and be open to seeing how someone else does a specific process versus accepting "the way we've always done it" as the de facto standard. Stay focused and ask very specific questions, while demanding very specific answers. Above all, avoid information you can get from a brochure or Web site and stick with what you can learn from seeing it in action.
So after all this, do you have enough to make a PACS decision? Maybe. After adding up everything you possibly read, saw, and heard, you are at about four dates ... yet you need to make a commitment that will cost you a small fortune and has to last at least five years and probably longer. Scary? You bet. That is where a solid, plain English contract comes into play.
Contracting
Vendor contracts primarily protect the interest of the vendor. Read them closely. Then make sure you add language that protects your interest as an end-user. I addressed some of the areas contract-wise that you need to look at in Part 2 of Building a Better PACS, and I will add more about this in future installments.
Understand that everything in the contract needs to be scrutinized. Most vendors will push you when you talk about changing the contract or including a General Addendum (GA). Push back. I did that with a vendor recently who said unequivocally, "We can't do that." The client, at my urging, said OK and started to walk away from the deal, and before you knew it, Moses showed up to part the Red Sea.
Everything that couldn't be done before suddenly could be, especially since we were mere hours from the close of the second quarter. Now admittedly, my client had to give a little as well -- that is what contract negotiations are all about -- but one thing I learned is the word "never" doesn't exist when it come to making a deal.
As for me, I waited 32 years to finally tie the knot, yet in hindsight I probably would have been better off if I waited a little bit longer and done better due diligence. I signed the standard vendor "contract" that offered me little protection in a state that redefines mom-centric and lost nearly everything I had except my pride.
The "system" I bought met my most basic needs for a few years -- not nearly long enough mind you -- but I had already clinically accepted the system and invested in significant upgrades as well -- two wonderful kids and a house, among other things. I kept the system alive as long as I could until the support costs exceeded the value. Then it was time to move on, making sure that the things that meant the most to me -- my kids -- didn't get lost in the transition and migration.
I have looked at several other "systems" in the past several years. I've yet to find one worth going beyond a simple assessment, let alone worth conducting a detailed evaluation or, heaven forbid, one I would go on a site visit for. Of course I now know what I really want in a system, instead of simply saying "It's time to get a PACS" and buying one that seemed pretty decent at the time.
Little did I know my "system" would be great in meeting my short-term desires but fell short of addressing my long-term needs. Maybe in a few years I'll be ready to enter contract negotiations again, but I'm not holding my breath. I'm more than content to simply pick up the literature and read about what the system has to offer. When it's time, I'll step up and do my due diligence, make a site visit, and enter into contract negotiations knowing I'll be prepared. I hope you will be too.
By Michael J. Cannavo
AuntMinnie.com contributing writer
July 2, 2009
Michael J. Cannavo is a leading PACS consultant and 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
The DRA and PACS: One hospital's story, April 14, 2009
Building a Better PACS: Part 2 -- Standards, guarantees, and flat-rate pricing, February 19, 2009
Building a Better PACS: Part 1 -- Making it work for end users, February 2, 2009
The 2008 PACSman Awards: I shaved my legs for this? December 4, 2008
The Anthology of PACS Secrets, September 9, 2008
Copyright © 2009 AuntMinnie.com
