How to fix an underperforming or 'broken' PACS

"Our PACS sucks!" If I've heard that once, I've heard it 1,000 times. Yet when you start to ask more detailed questions around what sucks about the PACS, all you typically get is the same nonspecific statement -- "Our PACS sucks."

Over the past few years, I've become increasingly engaged in helping to "fix" an end user's "broken" PACS. In a similar role to a marriage counselor, I am typically brought in to assess the situation just before the movers are called, the furniture is loaded up, and the kids are put in the minivan for a trip to parts unknown.

Michael J. Cannavo.

When I show up, my first goal is to calm everyone down and convince them to postpone the movers until I've at least had a chance to hear from both sides. I listen closely, look at any documentation supporting their side of the story, and finally make sure the end user knows what is involved in getting a PACS divorce. Then we talk about a possible resolution.

Although we can usually come to a resolution that satisfies both parties, sometimes divorce is inevitable. The biggest variables are the willingness of both parties to work together toward a mutually satisfactory resolution and a determination that trust can be rebuilt between both parties once the situation is fixed.

I usually begin my evaluation by discussing the situation with both parties, separately at first and then together. After we talk a bit, I often find out that roughly half the issues are user-related and half are vendor-related. This usually doesn't go over very well with the end user who has engaged me and wants it to be entirely the vendor's fault. Yet the role of any good mediator is to remain neutral and bring the two parties together toward a common fix.

An objective third party

I've found it interesting that vendors have been highly receptive to having me act as a third party, especially since I've been hired by the client. I would have expected the opposite. The reality, though, is that all the vendor may have gotten from the client up until this point was negative vibes. It can make all the difference in the world when someone comes in, looks at the situation from an objective standpoint, and says, "Hey, I fully understand what the issues are from your perspective as well. Let's put together a plan of action and act on it."

It isn't easy -- and frankly borders on the impossible -- to get the vendor's attention when both parties have been unable to work things out on their own. Think of the movie "The War of the Roses," and you pretty much can envision what I walk into on a regular basis. Endless back-and-forth emails tend to go nowhere, and threats only make the situation worse.

Depending on the severity of the problem, the end user can ask to escalate the problem resolution (this is typically done before I'm called in), involve higher corporate powers, or in a worst-case scenario, even stop making monthly payments for the system. What works and doesn't work depends on the vendor and how bad the problem really is. Just don't expect to get X months for free if you are still able to use the system despite poor performance. Yes, it might suck, but the reality is that it's still usable. That said, most vendors will be fair with you if you are fair with them, so keep that in mind.

No lemon law

It's important to understand that there is no lemon law for PACS. PACS is like buying a used car: you bought it, you own it. If you've ever read a PACS contract, you also realize the end user has no real protection -- despite the inclusion of performance and acceptance criteria. Few end users actually read the PACS contract before it's signed and instead relegate this to the hospital legal department. Most legal departments don't have a clue how a PACS is supposed to work, so they just give the go-ahead to sign the contract.

Standard clauses like the Limitations of Liability, Disclaimer of Damages, Indemnity, and others completely cover the vendor's interests like an invisible cloak of protection and do absolutely nothing for the end user. Sadly, you don't have much choice; you either sign the contract as is and get the PACS you want, or don't get the PACS you want and walk away after spending gobs of time evaluating the system that you felt was the right one for you.

This is why I recommend to my clients that they start with a contract review and discussion, and if the vendor is amenable to changes, then my clients can move forward. If not, then they can decide to accept the vendor contract language as is knowing they have next to zero protection if the system doesn't meet their expectation but technically and contractually still meets what the vendor delivered. Or my client can move on to the next vendor.

Once you sign the contract, the deal is done. This happens almost all the time without anyone having a clue exactly what they are signing. Having someone who knows what to look for is always the best solution, especially since the only other time a contract is looked at is when there are issues that desperately need to be addressed. Then you're at the vendor's mercy.

Limited protection

Most contracts offer a few "guarantees," but most of these give the end user limited protection at best. Performance criteria almost always involve how fast the images can be displayed from the server. They also usually have so many contingencies that make the guarantees all but worthless. This is a problem that is endemic to the entire industry.

Keep in mind that image display time shouldn't be equated with a negatively impacted workflow. Scenarios that impact workflow include, for example, receiving the current images but not the priors, or getting the current images and priors but not the reports. That said, if the image(s) come across fast enough, the vendor has then technically met its contractual obligation relating to performance. To resolve this issue, I have developed contract language for my clients that addresses workflow and provides objective ways to measure performance.

Sadly, most vendors' legal teams won't consider anything that impacts revenue recognition. The language I have proposed could indeed impact revenue recognition, but only if the vendor has installed a system that doesn't operate as it should. There are no penalties otherwise. Interestingly, this language says nothing about speeds or related items but instead focuses on how the system is used and the impact its overall performance has on both technologist and radiologist productivity.

It's important to understand that acceptance criteria can typically be customized based on the receptiveness of the vendor and the reasonableness of the proposed criteria. This relates to when the customer will begin paying for the system. Most standard acceptance criteria specify an arbitrary date, whether the system works as expected or not. Clinical acceptance can also be stated based on the number of studies the system has processed. In one such case, the language was written in a way that one of my clients unwittingly clinically accepted the system just over three hours after its very first use. I see this madness every day. Workflow is all that matters to the customer and the radiologist, and that is hardly ever addressed contractually.

Fixing systems

Even though it seems like I've just been bashing vendors, I want to point out that most vendors are amenable to fixing systems they have installed -- especially since the end user is paying the equivalent of 50% of the initial system cost in service fees annually. Unless a problem breaches the contract's terms and conditions, however, the vendor is not legally bound to fix it. Most vendors stand firmly behind their products, but how far they are willing to go largely depends on the end user's attitude.

Like a marriage, it's often not the big things in PACS that create the issues; it's the compilation of small things that drive you nuts. Sometimes the problem can be satisfactorily fixed in under a week with minimal time and expense. I have also seen vendors working on fixes for six months or longer and spending an ungodly amount of internal resources to fix a series of issues that were wrong with the system. In one case, the vendor cost was well over $500,000. Of course, the need for fixes should never have gotten anywhere near this point, but mistakes were made by both parties. Untangling the mess and putting together a go-forward plan to prevent this from happening again took a lot of time and effort, but it was worth it in the end. Everyone is happy, and now all that remains is to get a clause accepted that protects both parties in the event a situation like this ever happens again.

After reading this, you may be asking one question: Isn't divorce a better option? Not really. Unless you go through counseling first, it's inevitable you will make the same mistakes all over again with a new vendor. It's almost always better to consider trying to work things out through mediation before you decide to initiate divorce proceedings.

A PACS divorce isn't cheap, and it can have a significant impact on department operations, not to mention careers. Even if you have a vendor-neutral archive (VNA) -- which less than 5% of all PACS users have -- and all data is stored or available in a DICOM Part X file format, you still have to transfer that data and database over to the new vendor. This can easily take a year or longer and more money and resources than were ever imagined or budgeted for. It also requires vendor cooperation, something that is not as easily gained amid a divorce. It's tantamount to asking your soon-to-be ex-wife to cook dinner for you and your soon-to-be new wife.

You also need to have money budgeted for hardware replacement, unless you are already in a software-as-a-service (SaaS) model. Workstation hardware, network components, and even operating systems may all need to be upgraded. Factor in training, support, etc., and the words "cheaper to keep her" start to ring true.

Making it work

After finding out all that's required prior to initiating a move from an existing vendor, the end user will -- more often than not -- agree to try and make the existing system meet its initial expectations. If both parties are amenable to making changes, then the PACS marriage has a chance of being saved. That said, both parties also have to accept the fact that they both had a role in getting to where they are now, and both need to play a role in fixing it.

One of the biggest problems I find with hospitals is too many cooks spoiling the broth. You have to have one person from each entity who will act as the primary contact with the vendor. The problem is exacerbated when everyone wants to be in on the action.

On one past job I worked, a vendor got service tickets from everyone and couldn't prioritize what was and wasn't crucial. To solve this, we identified just three contacts from the facility: the PACS administrator, the administrator's backup, and the director of IT. These were the only people who were allowed to discuss the PACS with the vendor. If anyone else -- including the radiologists -- had an issue or any input, they had to go through the PACS administrator. This eliminated a lot of the confusion at the vendor's level over what was crucial and what was not. Importantly, we also developed an internal electronic service record that provided a much higher level of detail (including screenshots and more) on issues than was possible with the vendor's service ticket.

Each project plan to fix a situation is unique, depending on the severity of the problem and the receptivity and resources from both the vendor and end user to fix the problem in a timely fashion. Solving most technological problems is easy. Managing the process really isn't that hard either, as long as you get input from the key users and make sure their suggestions are included. Managing people's expectations about what the technology can and can't do is the ultimate challenge. That is how the PACS repair process starts, by addressing and managing expectations. How it ends is up to you.

Michael J. Cannavo is known industry-wide as the PACSman. After several decades as an independent PACS consultant, he worked as both a strategic accounts manager and solutions architect with two major PACS vendors. He has now made it back safely from the dark side and is sharing his observations.