AuntMinnie.com presents the first part 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.
PACS may have more hidden secrets than the U.S. government. And as is too often the case in politics, in the PACS market we are expected to believe all or most of what we are told; that the truth has been laid out and that there is nothing left to know. Unfortunately, that's not always the case.
One size fits all?
One of the biggest PACS fallacies is that all facilities of a similar size and shape can benefit from the same solution. Vendors are notorious for providing cookie-cutter responses to requests for proposals (RFPs) based on a facility's size, at times even forgetting to remove the previous facility’s name from the RFP -- this happens more often than you might expect.
In reality, two 250-bed facilities can have totally different requirements, totally different budgets, and above all, totally different buttons that need to be pushed to get approval for the PACS funds. This can be said even of facilities owned and operated by the same organization (Tenet Healthcare, HCA, Kaiser Permanente, etc).
System design is impacted not only by the needs of the facility, but by several other criteria as well. These include the age of modalities that will be connected to the PACS and their level of DICOM conformance, such as the availability of both DICOM modality worklist (MW) and modality performed procedure step (MPPS).
Other design considerations include the existing network infrastructure and the ability to create a separate virtual private network (VPN) for PACS, as well as clinical systems interfaces and requirements for hospital and radiology information systems (HIS and RIS), voice recognition (VR) systems, and others.
A facility must decide what existing clinical systems need to be interfaced (or integrated) and how these interfaces will be achieved. While going with a brokerless RIS/PACS interface might initially seem beneficial because it eliminates a piece of hardware (the broker), the costs can significantly outweigh the benefits if a RIS upgrade is required (unless such an upgrade were already planned). In addition, the costs associated with making changes with future upgrades of the RIS must also be weighed and factored in.
Some skeptics might say "How hard can selecting a PACS be?" They're right -- the PACS selection process is easy. Ninety percent of the facilities ready to employ PACS know what they want in a PACS as well as their preferred vendor, well before the first document about PACS hits the streets.
Unfortunately, 90% of these facilities will also deny they have either preselected a vendor or have a personal favorite. Even when the vendor has been preselected and a basic system design laid out, choosing the right system is a huge undertaking. It requires a thorough knowledge of both radiology and hospital operations from a pre- and post-PACS standpoint, as well as familiarity with the capabilities of PACS networks and overall facilities requirements.
PACS consultants and even the vendors can help here, but again, caution should be exercised to avoid cookie cutter or "PACS by the pound" approaches.
More is not necessarily better
Information overload is all too common with PACS, especially information that a consultant has deemed necessary for a PACS purchasing decision. Unfortunately, the more information you have, the less you typically really know about the system you're getting.
A 3,000-question RFP response on an Excel spreadsheet typically won’t give you any more necessary information than one that asks 50 correct questions responded to in a narrative form. What you do with the data you obtain is paramount.
Like it or not, a spreadsheet can’t possibly begin to tell you how a PACS will impact your facility, nor will it tell you how or if it will even meet the goals you set out for it. Asking thousands of questions only leads to information overload and the inability to make a decision.
When an RFP comes in to a vendor with hundreds or thousands of questions, the custom answers desired by the customer are often replaced with a templated response just to get the job done. This provides the customer with a virtually worthless response.
It may look impressive from a size standpoint, but the content is typically hollow, and if anything, makes the process more confusing. Every day, PACS RFPs are released asking the most inane questions that really don’t make a hill of beans worth of difference.
The same holds true for site visits. End-users feel they can glean information about how a PACS will work in their facility by going on site visits, so they go on as many as they can. With few exceptions, though, most hospitals are disappointed with the information they gain.
They expect to see a PACS similar to what has been proposed for them, utilized in much the same manner. Instead, they typically discover software one or two versions behind what has been proposed, a RIS that is totally disparate with what they have at their facility, and a PACS network that did or didn’t address most of the needs of the hosting institution.
On the positive side, though, a hospital can have the opportunity to chat with a facility about its implementation and see what was done right, what they’d do differently, and how the vendor worked through installation, training, service, and the like.
PACS takes bodies -- lots of them
Contrary to what most information technology (IT) people might feel, PACS hardware is, for the most part, virtually transparent to PACS operation. This is not to say that hardware doesn’t matter, as minimum standards must be met to ensure proper functionality, but rather that functionality must take precedent over form.
The transparency of hardware also does not mean that there aren’t important differences that must be considered. Storage-area networks (SAN) and upgrades to existing clinical workstations are two of several areas that IT must look at from a global perspective, even though much, if not all, of the funding for these components will come from the PACS budget.
PACS also requires a lot of support from IT. As highlighted in a poster presentation at the 2004 American Roentgen Ray Society (ARRS) meeting, nearly 25% of the unanticipated costs of PACS are related directly to unbudgeted IT costs. This excludes the costs from PACS planning (network and computer room upgrade plans) and implementation, which can easily add another 10%-20% to the quoted price.
Purchase price is just the beginning
The cheapest part of PACS is actually buying the hardware and software. Service-contract costs, which will be addressed in more detail later in this article, can easily double the cost of a system over the five-year return on investment (ROI) period.
PACS systems administration costs, ongoing training, and non-contract service-related costs all add to the total cost of ownership (TCO) of PACS. Infrastructure upgrade costs also need to be taken into account, addressing networking costs as well as system upgrades. This includes necessary PACS optimization upgrades/updates to the imaging modalities to support DICOM modality worklist and MPPS, additions that can easily tack another 10% or more to the PACS purchase price. Upgrades to other clinical systems (RIS, VR, etc.) also can add 10%-20% to the system cost.
A good benchmark for calculating the TCO is to double the costs on the PACS quote to find the approximate cost ownership over a three-year period. Use a factor of three over a five-year period if a service contract is enlisted. These costs can be reduced by roughly one-third if a service contract is not used, however.
Money for nothing
Deciding whether to purchase a service contract is often a hotly contested topic in discussions with our clients. Unlike modalities, where the device requires routine service and where downtime equals lost revenue, PACS typically shouldn’t require a service contract.
This flies in the face of traditional thought processes, though, as typically every device and piece of software used in the hospital has a service contract. Despite valid arguments against service contracts, 90% of hospitals still purchase service contracts for PACS, proving that old habits die hard.
The core components in PACS (servers, interfaces, etc,) typically are offered with greater than 99.5% uptime guarantees. High-availability and fault-tolerant systems offer 99.999% guarantees. Even with only a 99.5% uptime, the maximum allowable downtime will be less than three hours total per month, and typically is much less.
If you took an average of $500 per hour for service (including travel time) and multiplied the 36 hours allowable downtime per year by $500 per service call, you'd have a maximum cost of $18,000 in time and materials service. This would all be before the vendor would be in violation of their uptime guarantee and into a penalty phase. Most system hardware also carries a two- to three-year warranty from the manufacturer, so parts costs aren’t a factor either.
PACS service contracts are typically calculated based on a percentage of system list price, not what you actually paid for it. If a system carries a list price of $2 million and you get a 20% discount (paying $1.6 million), the 15% service-contract price is often calculated on a $2 million value, making the cost $300,000 rather than the $240,000 you would have expected.
This is a huge bonus for the vendor. Moreover, the price delta between the $300,000 service-contract costs and the $18,000 that is a maximum allowable cost for downtime is huge. This disparity can allow a facility to train biomedical personnel to perform second-tier service -- the first tier being the PACS systems administrator(s) -- and maintain spare parts kits as well.
That said, it would be foolish to recommend no PACS services from the vendor at all. Most PACS vendors will tell you that 95% of all problems can be solved remotely over the phone. For that reason we recommend a contract that provides software-only support.
This contract typically can be negotiated at one-half to one-third the cost of a standard "full-service" service contract and provides a level of support that makes both radiology and IT comfortable. Many vendors also include software upgrades (software releases that incorporate new functionality) in their software service-contract costs, although not all do. This can easily save you the cost of the software service contract alone and provide you with a level of comfort you need as a backup to that already provided by your facility.
It is also recommended that service contracts be maintained on computed radiography devices due to the nature of these devices. And at least one "cold spare" diagnostic workstation should be kept in reserve in case a workstation fails.
By Michael J. CannavoAuntMinnie.com contributing writer
May 14, 2004
In "Part II: Exploring PACS secrets," Mr. Cannavo will discuss what every IT manager needs to know about PACS, ROI facts and fallacies, and more hidden costs.
Michael J. Cannavo is a leading PACS consultant and has authored over 250 articles on PACS technology in the past 15 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. 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
PACS still a bridesmaid at HIMSS, February 27, 2004
The year of the Uni-PACS: A view from the RSNA floor, December 11, 2003
The PACSman’s opinionated view from RSNA 2003, December 4, 2003
The PACSman’s opinionated view from RSNA 2002, December 4, 2002
Stop me if you’ve heard this one about PACS, November 29, 2001
Copyright © 2004 AuntMinnie.com
