So much energy has been focused on the development of standards, but we still allow PACS vendors to hold on to proprietary systems. I find this situation confounding.
One of my esteemed colleagues summed up the situation well:
There are numerous reasons why even the current PACS do not "play well" with standalone DICOM archives, and I don't believe for a minute that those reasons are technology challenges. I don't see the PACS vendors giving up the archive any time soon. Proprietary data objects or use of private tags simply locks the archive (and the data) to the PACS. Therefore, the more practical strategy for anyone wishing to pair a PACS from one vendor with an enterprise archive from another is to expect that the PACS will continue to store some key metadata objects as proprietary objects, or store them as DICOM objects in private tags, or use proprietary value representations (the text that describes the encoding of the tag).
 |
| PACS consultant Michael J. Cannavo. |
If end users would stand up and say, "No, I'm not going to buy your PACS until you make it completely DICOM neutral," more vendors would provide DICOM neutral archives. As I said in Building a Better PACS: Part 1, three of the top five PACS providers do not have a DICOM neutral archive, and the other two have archives that are closer but still far from ideal.
So what's the answer? Here's the specific language I proposed to several vendors; we found out their "DICOM archive" was not really a DICOM archive when they refused to include this language in the contract. Make sure the following is included in your final contract language:
(The vendor's) support of DICOM will allow the migration of data from (the vendor's) archive to a vendor-neutral DICOM archive without the use of data migration services. While the use of private tags is allowed, the information in these tags should not preclude nor take precedent over identical data stored in public tags.
Pretty simple and straightforward isn't it? I thought so, and my client thought so, but the vendor thought otherwise with six different iterations, including this doozie:
(The vendor) will allow the transfer of metadata from (the vendor's) archive to another DICOM archive to facilitate a migration that does not involve the movement of image data. While the use of DICOM private tags is allowed in this metadata, the information in these tags should not preclude nor take precedence over public tag data. It must be noted that while the metadata will provide pointers to the data files on the storage system that contain the DICOM images, another DICOM archive would need to be able to interpret the file format used by (the vendor's) archive to access the images directly from the storage system rather than via the DICOM interface of (the vendor's) DICOM archive server.
How does that saying go? "If you can't bedazzle them with brilliance then befuddle them with bull ... um ... hockey." Their answer begged a simple question from me: If the file format is DICOM, why does the other vendor need to be able to interpret it?
Long story short, the vendor ended up putting in their proprietary archive on a technicality because the client didn't specifically ask for a DICOM vendor-neutral archive, only a DICOM archive, which technically it was, albeit a proprietary one. I could only respond: "Gee, and you wonder why I say DICOM is the most nonstandard standard that ever existed?"
There is a joke that asks the question, "What do you call 1,000 attorneys at the bottom of the sea?" The answer is, "A good start." I'm beginning to believe this every time I have to deal with these fine individuals.
Few would argue there's a need for all the legal mumbo jumbo to protect the interests of both parties, even though 98% of what's in most contracts really protects the seller. That said, does every contract have to have one-off versions of the same thing -- just enough so that we keep someone on the clock at $200 per hour (or more) reviewing the contract?
Let's face it. A PACS contract is a contract, and things like severability, binding effect, force majeure, and the like should pretty much all be standardized. So here is my proposal: Let's make these sections templated for all vendors so that what's good for one is good for all.
Requirements and guarantees
Now let's get crazier still. Let's add sections that are missing from virtually all contracts, such as implementation requirements for both parties, uptime guarantees, and so on, and make them either fill-in-the-blank boxes or check boxes.
Take uptime guarantees as an example. The area would look as follows:
Our uptime guarantee is ___ minutes per month calculated on a 24/7 basis. This equates to a ___% uptime. If we don't meet the uptime guarantee, you get ___. Our exclusions include (list all the standard ones to which everyone agrees), as well as ___.
The same this would hold true for installation:
We agree to install the system by ___. If we don't install the system by ___ (usually two weeks hence), you get ___ for every day we are late. Our exclusions to this include (list all the standard ones to which everyone agrees), as well as ___.
Notice the simple, easy-to-understand language? Now, most standard PACS contracts eliminate areas like these, and this probably will be an entire topic in Building a Better PACS: Part 3. At a minimum, though, these items need to be included in this language or something at least very similar to it:
Downtime: Downtime hours shall be counted from the beginning of each month and are not cumulative. Downtime begins with the receipt of a call to (the vendor) by the PACS system administrator (PSA) that the system is inoperable and a determination is made that the problem can not be repaired remotely. Downtime shall continue until such time as the system is fully operational. This does not include scheduled downtime for routine service, preventative maintenance, and other items required to maintain this service requirement. Exceptions also include physical abuse, acts of nature, malfunctions not caused by or due to actions of (the vendor), and modification to the hardware or software applications and/or files associated therein that were not specifically authorized by (the vendor). Software updates (other than those providing additional functionality not specified herein) during the warranty period shall be included at no additional charge.
Note the words "not cumulative." Vendors are all over the board with downtime calculations, to the point where if your system is not considered down at all for six months, and then it is down for four days, the vendor can claim it met the uptime guarantee because its downtime "guarantee" is measured quarterly, semiannually, or annually. We need an industry standard for downtime, and it should be monthly and nonrecurring.
Underperforming systems
Now let's talk about dogs. Yes, there are systems that are true dogs out there and end users can and do pull their hair out waiting on systems to perform as they should. Worse yet is a system that never consistently performs to the end user's requirements. This next item is sure to be super controversial, but this is a clause I put in most of my contracts for clients:
Should the system either fall below 98% uptime for three (3) consecutive months or any five (5) months total in the initial twelve (12) month period, or not meet the defined system performance specification during this same period, the system shall be deemed unacceptable as not meeting the system performance criteria. At that time (the buyer) reserves the right to remove the system and have any and all monies paid for the system, less professional services incurred, refunded in full.
Obviously you need a very tight performance specification that both buyer and seller agree upon, but this should also be included in the contract as well. This should be placed in the "system description and operation section" that clearly outlines what is expected from the system and what the seller agrees the system will do, as well as how it will do it. The vendor should define this and have it made part of the standard contract.
List everything the system does or is capable of doing, and then check off what the customer is buying. This way there is no guesswork in either what the vendor claimed as the system's capabilities or what the end user bought. You can also have a few blanks for the one-off custom engineering requests, but these should be avoided if possible.
Warranty periods are something else that is all over the place in the industry. This one has a very easy answer -- the software warranty is one year from the date of clinical acceptance. Period. Not from the date of contract signing, product shipment, installation, or the plethora of other measurement criteria being offered. Once the buyer says, "OK, it works as we agreed upon," the warranty clock starts ticking.
Hardware warranties should all be passed through to the end user. I've seen so many systems that come with three-year hardware warranties bundled with one-year software warranties, leading to end users paying twice for the same warranty. That's just not right.
Sure, the vendor may need to call the hardware manufacturer on the customer's behalf, but the PACS system administrator could just as easily do this as well. If the hardware warranty from the hardware manufacturer is significantly cheaper than what is offered by the vendor, the buyer should be given the option to buy directly from the hardware provider.
Now I'm not asking for a free lunch here; if vendors prestage the system, they need to be compensated for that time and effort. So this needs to be added as a billable line item to the buyer.
In my experience, prestaged systems have significantly fewer problems then those assembled onsite, so maybe this should be a requirement, too. Have all systems built and tested, with all MAC and IP addresses entered at the factory, and then have the whole system disassembled before shipping.
Am I attempting to change the way companies do business? Only with so-called turnkey solutions. Nothing changes with software-only solutions, where customers do their own integration.
Flat-rate pricing
This leads me to my last point: flat-rate pricing. If you ever divide the cost of project management, installation, training, and support costs by the list (prediscounted) price, you'll find it almost always comes out to an even percentage.
Companies rarely take the time to discuss the client's needs in these areas. Instead, they plug in a percentage fee based on the needs of similar-sized accounts or, more likely, just use the same percentage number for everyone regardless of their requirements. Again, this is wrong.
If a customer already has a PACS, the radiologists don't need five days of training when one day will suffice. Implementation costs should be predicated on the availability and depth of resources a site has to offer and not assume the vendor will be doing it all.
And project management? Puhleeze ...
Service is the biggest money maker of all, but few people balk at service costs because, "We have to have service." The bottom line is that first-line software support (remote troubleshooting via the Internet) should cost between 5% and 7% of the system cost. Hardware should be supported by the hardware vendor, not the PACS vendor.
A radical approach? Of course. Vendors are no doubt up-in-arms, saying that this is where they make their profit, just as car makers offer you a great deal on a car and then tack on $1,500 in dealer fees at the end.
My solution for vendors? Stop discounting the system software so much, because that is where you really can make your margin and sell on the strengths of your product. Then be reasonable with the add-ons.
Talk to the end user and agree upon the amount of support needed, and then come up with a reasonable, yet profitable, cost per day for ancillary services. Either side might come out ahead financially, but the bottom line is both parties will benefit from giving the customer what they actually want and need, versus letting a formula determine it.
This will require vendors to ask pointed questions and end users to adequately determine what they can contribute. But this is definitely the best way to go about it.
The next Building a Better PACS installment will discuss how to get standardized quotes and will explore more contract issues. There may even be a few added surprises in other areas as well, so stay tuned.
By Michael J. Cannavo
AuntMinnie.com contributing writer
February 19, 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 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
Part XX: Exploring PACS Secrets -- Will PACS survive? July 22, 2008
Part XIX: Exploring PACS Secrets -- The truth about DRA and PACS, March 27, 2008
Copyright © 2009 AuntMinnie.com
