Building Better PACS RFPs

Twitter icon
Facebook icon
LinkedIn icon
e-mail icon
Google icon

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