I'm working through a very, very serious PACS software matter with a client of mine -- one that probably warrants getting the U.S. Food and Drug Administration (FDA) involved because it deals with patient safety issues -- and was going through his contract to see if he was covered for these software problems.
 |
| PACS consultant Michael J. Cannavo. |
This situation reminds me of the time I got a call from my then-wife that our van wouldn't start and it was my fault. Even though the van started fine prior to and since I had gone out of town, now it wouldn't -- and she needed to know what I was going to do about it.
Now, I had paid for AAA to make sure that if this and other inevitabilities were to happen, we were covered, but was it enough? Nooooooo -- I heard about it for months afterward.
I decided what I needed was a "life contract," like vendors have for PACS. It needs to say: "It's not my fault, never was my fault, and if it's proved to be my fault, it's still your fault because I'm absolved of any fault ..."
How many of you can honestly say you have read a vendor's PACS contract? I'd say less than 5%, and most of those 5% have never really paid attention to what's in it. Not only is it scary in what it doesn't say, but even more so in what it does say instead.
The two biggest areas of concern in PACS contracts are disclaimers for warranty and limitations of liability. Here are two disclaimers from the vendor in question that my client is dealing with. They are bad, mind you, but sadder still is that nearly every vendor's reads almost the same. So, without further adieu, read 'em and weep:
Limited Warranty; Disclaimer. Vendor warrants that the Vendor Software will perform substantially in accordance with its documentation and that any media on which the Vendor Software is provided will be free of material defects for a period of (x) days following its delivery to Customer. To the extent System Hardware warranties are provided by the manufacturers or suppliers of such System Hardware, and are assignable or transferable to Customer by Vendor according to the terms of such warranties, Vendor hereby assigns and transfers such warranties to Customer for the term of this Agreement. VENDOR MAKES NO OTHER WARRANTIES WHETHER EXPRESS OR IMPLIED, AND EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE OR MERCHANTABILITY. VENDOR DOES NOT WARRANT THAT THE VENDOR SOFTWARE OR THE THIRD-PARTY SOFTWARE OR THEIR OPERATION WILL BE FREE FROM BUGS, INTERRUPTIONS, ERRORS OR OTHER PROGRAM LIMITATIONS.
Limitation of Liability. IN NO EVENT SHALL VENDOR BE LIABLE FOR SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO DAMAGES FOR LOSS OF BUSINESS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION OR OTHER INDIRECT OR CONSEQUENTIAL LOSS) WHICH MAY ARISE UNDER THIS AGREEMENT, OR FROM USE OF THE SYSTEM(S), EVEN IF VENDOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES OR DAMAGES. CUSTOMER AGREES THAT VENDOR'S SOLE LIABILITY, IF ANY, INCLUDING, WITHOUT LIMITATION, LIABILITY ARISING OUT OF CONTRACT, NEGLIGENCE, STRICT LIABILITY IN TORT OR WARRANTY, SHALL NOT EXCEED THE SYSTEM FEES PAID BY CUSTOMER FOR THE CURRENT TERM. IN NO EVENT SHALL VENDOR BE LIABLE FOR MEDICAL MISDIAGNOSIS MADE WHILE USING THE SYSTEM.
OK, so what does this all mean? Let's look at it line by line:
"Vendor warrants that the Vendor Software will perform substantially in accordance with its documentation and that any media on which the Vendor Software is provided will be free of material defects for a period of (x) days following its delivery to Customer."
The key words here are "perform substantially." Substantial performance is a legal term that has many definitions. Basically, it says that if a good-faith attempt was made to perform the requirements of a contract, but the attempt failed to exactly meet the specifics, and if the essential aim of the contract has been met, the agreement will still be considered as having been completed. Usually you are only allowed slight variances from the exact terms and/or unimportant omissions or minor defects, but how one defines "slight" and "unimportant" remains to be seen.
With PACS, how things operate is as important -- if not more important -- than just having it operate. Requiring six keystrokes to do what should take two can have significant negative effects on radiologist productivity. Functionality often takes the back seat to ease of use.
That said, if you paid for a Rolls-Royce and you got a Kia, do they both perform substantially? In what areas? Do you have to prove that you bought a Rolls for luxury or just to get you from point A to point B?
You see the vagueness -- and absurdity -- of this. I did find one place where it said the owner has a right to recover whatever damages he has suffered by reason of the contractor's failure to render full and complete performance, but it also went on to say that what actually constitutes substantial performance depends on the circumstances.
The next part is "... and that any media on which the Vendor Software is provided will be free of material defects for a period of (x) days following its delivery to Customer."
Read closely -- it's not what is contained in the media (i.e., namely the applications software and associated source code), but the media itself. So what do you get if it's bad? Another 10¢ replacement DVD. Oh joy. Of course, most companies do provide you with the applications software, but still.
Moving on: "To the extent System Hardware warranties are provided by the manufacturers or suppliers of such System Hardware, and are assignable or transferable to Customer by Vendor according to the terms of such warranties, Vendor hereby assigns and transfers such warranties to Customer for the term of this Agreement."
This is kind of a joke. Basically, it says you paid for a warranty, so we're giving it to you at no charge. Now here's the catch-22. Say the hardware you bought has a three-year warranty. The warranty you get from the vendor on the entire system, including the hardware, is typically 90 days to one year.
If you have a three-year warranty, the only way the vendor will service the system beyond their warranty period is if you have a service agreement. So in essence you are paying 14%-16% of the hardware's list price to have the vendor call the hardware manufacturer for you -- period.
Sure, some degree of troubleshooting is required, but this would need to be done even if you had a software-only service agreement. Someone, somehow has to figure out if the problem is software- or hardware-related, so this means on a $50,000 list-price server, you would pay the vendor at least $15,000 additional ($7,500 per year) to make a phone call on your behalf to the hardware manufacturer -- and that is if you have a one-year warranty.
A six-month warranty would add $3,750 to that amount ($18,750) and a 90-day warranty an additional $5,625 (adding up to $20,625). This is the price to handle phone calls to the hardware vendor on your behalf over a three-year period -- a phone call, nothing else. And how often does the vendor make those calls with hardware in the 99.9% uptime range?
Umm, not often, and certainly not $15,000-$20,000 worth, even if they do pack up and ship the old box for you and unpack and reconfigure the new hardware for you. Most vendors charge $2,000-$2,500 per day for an onsite service tech. You do the math. Now you know why 70% of all net profits that PACS vendors generate come from service agreements.
Let's continue: "VENDOR MAKES NO OTHER WARRANTIES WHETHER EXPRESS OR IMPLIED, AND EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE OR MERCHANTABILITY."
I love this one, too. Restated, it says, "I know you bought it to do this, but if it doesn't do this and instead does that, then, oh well." It also states "... disclaims any and all warranties of fitness for a particular purpose or merchantability."
According to one source I referenced, "Before a court will imply a warranty of fitness (WOF), three requirements must be met: (1) the seller must have reason to know of the buyer's particular purpose for the goods; (2) the seller must have reason to know of the buyer's reliance on the seller's skill and knowledge in furnishing the appropriate goods; and (3) the buyer must, in fact, rely on the seller's skill and knowledge. Even when these requirements are met, courts will not imply a warranty of fitness under certain circumstances. A buyer who specifies a particular brand of goods is not entitled to an implied warranty of fitness. Also, a buyer who has greater expertise than the seller regarding the goods generally is precluded from asserting an implied warranty of fitness, as is a buyer who provides the seller with specifications, such as a blueprint or design plan, detailing the types of material to be used in the goods."
Say what? So if I know more about the product than the seller does, then I have no warranty? Amazing! It also states that knowing the buyer's purpose is reasonable, as is the buyer needing to rely on the seller's skill and knowledge. But if the buyer has "greater expertise" than the seller, then why is the WOF precluded? If we provide a request for proposal (RFP) that says the PACS needs to do A, B, C, and D -- otherwise known as specifications that detail the applications we are looking for (and after all, we are ostensibly buying software that runs on a standard hardware platform) -- then does that, too, preclude the WOF? Since when?
An implied warranty of merchantability is defined as "an unwritten and unspoken guarantee to the buyer that goods purchased conform to ordinary standards of care and that they are of the same average grade, quality, and value as similar goods sold under similar circumstances."
In other words, merchantable goods are goods fit for the ordinary purposes for which they are to be used. The Uniform Commercial Code (UCC), adopted by most states, provides that courts may imply a warranty of merchantability when (1) the seller is the merchant of such goods, and (2) the buyer uses the goods for the ordinary purposes for which such goods are sold (§ 2-314). Thus, a buyer can sue a seller for breaching the implied warranty by selling goods unfit for their ordinary purpose.
The policy behind the implied warranty of merchantability is basic. It states that sellers are generally better suited than buyers to determine whether a product will perform properly -- or so it says. With PACS, end users typically know the system a whole lot better than the seller, and stress and test the system to the max. This allows them to find problems that a vendor might never have found on their own, because end users tend to push the system a lot harder that developers ever would.
Holding the seller liable for a product that is not fit for its ordinary purpose shifts the costs of nonperformance from the buyer to the seller. To me, at least, this is how it should be. In theory, this also motivates the seller to ensure the product's proper performance before placing it on the market.
But what if it doesn't work? Or doesn't work well? Basically the only liability the seller has is to refund monies paid to the buyer. Interestingly enough, the seller absorbs the costs of a product's nonperformance by spreading the risk to consumers in the form of increased prices.
I wish it were all that simple, but with PACS you are often dealing not just with hardware and system software costs, but with implementation and integration costs as well. If you change vendors, you also have to deal with other costs, including data migration; database conversion; reinstalling hundreds, if not thousands, of Web server software; plus the time it takes to customize the system.
PACS and prophylactics
It is unfortunate that most PACS are treated contractually, like a package of prophylactics. It didn't work? Sorry about that. Here's your 42¢ back -- and a free three-pack thrown in for your inconvenience. What? You say your wife is pregnant now? Congratulations! You aren't happy about it? It obviously isn't our fault. Look -- read our limit of liability and warranty of merchantability, it says so, right here.
This is why I tell my teenage sons that you stand a 3X better chance of hitting the Florida Lottery than not getting a girl pregnant by using a condom. OK, so maybe that's stretching the truth a tiny bit (but not by much), but the prophylactic maker will no doubt say the odds were 40 million to 1 against you. If you were that serious about contraception, you should have taken additional precautions, especially because in the best-case scenarios you have a 12% failure rate.
Can the same be said for PACS? You hear about uptime guarantees all the time, yet anything realistically more than 99% is usually so couched in technical gobbledygook as to make it worthless. It's all due to the contract.
Now, I'm not naïve enough to think that all software doesn't have some bugs. Unlike my kids and my good friend the Dalai who live and die by the evil fruit from the Garden of Eden, I still contribute to the Bill Gates retirement fund. That said, even Windows performs the majority of functions without issue, and most of the bugs they find and fix don't affect my day-to-day performance.
Can the same be said for all PACS software? Not in my client's case. Does it impact patient safety as well? Again, at least perceptually, it does in my client's case. The stuff he is running looks like it was developed by the Not Ready for Prime-Time Players in the old Saturday Night Live shows, yet it has been commercially released and clinically used for years.
Fascinatingly, my clients are the only ones who seem to have any issues with the software, or, at least, that is what the vendor says. No other client has experienced anything like the problems they have, so, go figure.
The policy behind limiting the implied warranty of merchantability to the goods' ordinary use is also straightforward. A seller may not have sufficient expertise or control over a product to ensure that it will perform properly when used for nonstandard purposes. But what about someone who only uses it for standard purposes -- using it only as defined, not even having any other software residing on the hardware? Someone please call in Bill Murray and the Ghostbusters. My client's problems have been documented time and time again, but no one can seem to figure out the problem. "So read the contract -- it's not our fault ..."
Let's look at the last part of this: "VENDOR DOES NOT WARRANT THAT THE VENDOR SOFTWARE OR THE THIRD-PARTY SOFTWARE OR THEIR OPERATION WILL BE FREE FROM BUGS, INTERRUPTIONS, ERRORS OR OTHER PROGRAM LIMITATIONS."
This is yet another "it's always someone else's fault but ours" clause. When a vendor can't determine the problem, it's always easiest to blame the operating system, blame the add-on applications software that we sold you but can't or won't stand behind, blame the hardware (even though it doesn't specifically state the hardware in this case), and blame anyone but ourselves.
Restated, this clause says, "Expect it to break because it's software and software breaks." That, in itself, actually is OK because, realistically, when you are dealing with upward to a million lines of code or more, it is impossible to test under every scenario. That said, though, where is the line between software simply being buggy that can be fixed in the next release and errors that impact performance? And who decides which is which?
Liability limitations
We've spent a lot of time on limited warranty disclaimers. Now let's go over the Limitation of Liability. Here is the legalese, once again:
Limitation of Liability. IN NO EVENT SHALL VENDOR BE LIABLE FOR SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO DAMAGES FOR LOSS OF BUSINESS, BUSINESS INTERRUPTION, LOSS OF BUSINESS INFORMATION OR OTHER INDIRECT OR CONSEQUENTIAL LOSS) WHICH MAY ARISE UNDER THIS AGREEMENT, OR FROM USE OF THE SYSTEM(S), EVEN IF VENDOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES OR DAMAGES. CUSTOMER AGREES THAT VENDOR'S SOLE LIABILITY, IF ANY, INCLUDING, WITHOUT LIMITATION, LIABILITY ARISING OUT OF CONTRACT, NEGLIGENCE, STRICT LIABILITY IN TORT OR WARRANTY, SHALL NOT EXCEED THE SYSTEM FEES PAID BY CUSTOMER FOR THE CURRENT TERM. IN NO EVENT SHALL VENDOR BE LIABLE FOR MEDICAL MISDIAGNOSIS MADE WHILE USING THE SYSTEM.
Simply put, we owe you nothing except what you paid us for software, if that. Professional services, which typically make up 40% of more of the total system cost, are excluded, as is system hardware.
Buyers need to clearly define what constitutes "system fees" as well as "current term," as each vendor has its own definition. As I said before, with PACS, you are often dealing with implementation and integration costs, data migration, database conversion, reinstalling Web server software, plus the time it takes to customize the system.
The vendor is typically not liable for any of this, unless you can prove otherwise. What's interesting here is the statement, "EVEN IF VENDOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES OR DAMAGES."
If the buyer says, "My business is being substantially impacted by your software due to ..." the vendor gets to say, "Oh well. Sorry."
Here's the last part: "IN NO EVENT SHALL VENDOR BE LIABLE FOR MEDICAL MISDIAGNOSIS MADE WHILE USING THE SYSTEM."
Now, it's reasonable that the vendor shouldn't be held for medical misdiagnosis made by a user of its software. But what if the misdiagnosis was due to a software issue, having too high a compression ratio that obscures or changes a diagnosis, for example, or where one patient's name is matched with another's study, as happened in more than one case with my client. Shouldn't the software vendor be held accountable? Morally and ethically, yes; legally, no.
The vendor will come back and say that the American College of Radiology (ACR) only requires that the compression ratio be displayed, and it is the physician's responsibility to ensure the right ratio is set with the right image type. Technically, they are correct, but shouldn't there be safeguards in place to prevent any unauthorized changes?
How about a pop-up that says the compression has been changed since the last time you viewed it? True, the compression ratio is stated -- or is supposed to be stated (in 10-point type) on the image -- but if you don't expect a change, why would you even look at the ratio? Ditto with patient names.
You have to expect that the study and images will match up accurately, so the system doesn't put the wrong finding with the wrong patient. If it did it right 1,000 times, why would the 1,001st time be different? But it is, or, it can be.
Again, safeguards are key, but the buyer is ultimately responsible for how the software is used -- even if it creates problems. Wouldn't it be better stated as the following? "THE VENDOR WILL PROVIDE SOFTWARE THAT HAS SAFEGUARDS IN PLACE AND HAS TAKEN ALL APPROPRIATE STEPS TO MINIMIZE ANY ERRORS ON THE PART OF THE SOFTWARE. WHILE THE VENDOR CAN NOT BE LIABLE FOR ANY MEDICAL MISDIAGNOSIS MADE WHILE USING THE SYSTEM, THE VENDOR CERTIFIES THAT THE SOFTWARE HAS BEEN TESTED AND VALIDATED PER SECTION 820 OF THE FDA'S GOOD MANUFACTURING PROCESS."
So what is the takeaway here, besides, "it's not our fault?" Know that legally, you have little recourse as long as these clauses or ones similar to them exist, especially once you clinically accept the system. If you have reason not to clinically accept the system for any reason, bail on it as soon as possible so you don't incur extraneous costs associated with system implementation and operation.
You should also try and include these costs in the definition of system fees, as well -- actually, any cost that is vendor-specific and can't be reused by another system (with the exception of network installation, computer room redesign, etc.) should be included. That way, at least you can recoup most of your costs and not just a small fraction.
Lastly, try and see if you can delete or, at the very least, modify the above two sections from the contract so they are more buyer friendly. I seriously doubt you'll be able to delete them -- the legal beagles in each company will eat you alive if you so much as try -- but modifying them might be a viable option.
By Michael J. Cannavo
AuntMinnie.com contributing writer
September 15, 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
Building a Better PACS: Part 3 -- Look before you leap, July 2, 2009
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
Copyright © 2009 AuntMinnie.com
