The road to a successful PACS implementation cuts a swath of
potholes and deep chasms that can be avoided if you pave a smooth road
in the very beginning by adopting a few simple steps in the request for
proposal (RFP) process.
Stuart Gardner, president and CEO of SG&A Consultants in Arlington,
Texas, who is not a proponent of templated RFPs, suggests an
open-ended, up-front approach that states goals and objectives of the
system design as well as some specifics such as voice recognition,
single log-on, full integration into the rest of the IT infrastructure
to facilitate the most creative solutions from vendors.
"The usual RFP locks the client into what he has specified and he
doesn't get to discover what the vendor has in development," Gardner
asserts. He reports that according to a study released at a
recent SCAR meeting, 68 percent of PACS installed do not meet
expectations of the institutions that deployed them.
Michael J. Cannavo, president of Image Management Consultants in Winter
Springs, Fla., concurs. He says that 90 percent of the people who enter
the RFP process for PACS have not assessed their requirements, set
goals or explained the problems they intend to solve with a PACS that
could not be solved with a simple re-engineer of their current IT
network. They install a PACS that doesn't meet their needs because they
haven't defined them.
"The RFP needs to define functionality, operation and application,"
says Cannavo, who notes an imaging center that completes 10,000
procedures annually requires totally different parameters than a
multi-site hospital network with a 300,000 annual study volume. Since
no two PACS arrangements are the same, institutions must plan for them
individually.
Cannavo says that in three-fourths of the PACS implementations, many of
the problems the institution wants to solve can be accomplished simply
by making process changes in the existing network configuration.
However, if their goals were to make multiple images available to many
sites, or improve productivity, then a PACS would seem to be the best
option.
Considering that vendors spend between $20,000 and $50,000 responding
to each RFP, it can prove mutually advantageous for both the
customer-institution and the vendor to understand defined goals and
objectives from the earliest stages of the process, Cannavo asserts.
Jeff Miller, senior manager of digital imaging at First Consulting
Group in Long Beach, Calif., suggests including in the RFP the usual
specifications of what the vendor is responsible for providing right
up-front, considering not only current expectations as to what the
initial system will provide but anticipated increased functionality in
the future. Ideally an institution would want to be on the latest
platform at all times, and it is in the vendor's best interest to have
everyone on the same platform anyway.
"Don't expect that the RFP will represent a one-time transaction," says
Miller. When you get into PACS, you're talking about a five to 10
year partnership. "We always put in [specifications of] the IT
architecture, just to see what the vendor is capable of integrating and
supporting. You could already have a SAN [storage area network] and you
want the vendor to plug into that rather than trying to sell you their
storage."
Experience teaches Steven C Horii, MD, FACR, FSCAR, professor of
radiology and clinical director of medical informatics group in the
department of radiology at the University of Pennsylvania Medical
Center, offers advice based on experience.
His first recommendation is that the RFP should include a description
of expectations and responsibilities of each of the participants if you
must change PACS vendors. That scenario is not so farfetched in this
age of large healthcare delivery networks that may make the decision to
change PACS for every hospital throughout their system, or PACS vendors
that go out of business. Including specifics about data migration, who
owns the data, whether or not their software is proprietary and that
you cannot use it if you change vendors, are some of the issues that
should be addressed. (For more information on data migration, see "Data
Migration: Is Your PACS Running Naked?")
"You don't sign on with a PACS vendor expecting to change, but it
happens," says Horii. When that occurs, it can feel like a divorce and
become quite acrimonious, so it is important to figure out, from the
outset, what happens if you need to change PACS vendors.
Horii believes details of the maintenance agreement belong in the RFP,
too, including expected up-time as well as scheduled tests of
back-up functionality and downtime procedures.
"We had the situation of having lost portions of our database, trying
to recover them from our backup tapes only to discover that the tapes
were corrupted," says Horii. Incorporating expectations of methods to
manage in the eventuality that your institution loses access to the
long-term archive, failed modality interfaces or other potential crises
to the initial RFP will provide some peace of mind.
In their experience, Horii says they have found the major source of
problems for smooth PACS operation has resulted from imaging modality
vendors upgrading equipment and software and not informing the IT
department. Therefore, he suggests including language in your RFP to
all vendors that they cannot upgrade without notifying the PACS
administrator.
Finally, involving all hospital departments that require access to
images in the RFP process can help decrease eventual problems once the
system is deployed. For example, if radiology normally sends CDs from
the CT scanner to the OR, they need to be sure that those workstations
are integrated into the network. The other portion of that discussion
would include which items each budgetary department is responsible to
support. For example, many radiology departments cover all items that
reside in radiology, but other institutional departments such as
cardiology or the emergency department or OR purchase their own
components, such as monitors.
Conclusion Installing and maintaining a PACS is a
complicated activity for any institution. Some pitfalls can be avoided
through careful consideration at the RFP stage of the process. Clear
and concise explanation of goals, objectives and anticipated outcomes
serves as a platform to maximize effective PACS implementation.
The road to a successful PACS implementation cuts a swath of
potholes and deep chasms that can be avoided if you pave a smooth road
in the very beginning by adopting a few simple steps in the request for
proposal (RFP) process.