Get the Most from your RFP

In another one of those signs of the times, the volume of request for purchase (RFPs) forms being written for radiology PACS is in decline and the volume being written for cardiology PACS is on the rise. One reason might be as simple as the age of the two markets. The radiology PACS market is believed to be largely a replacement market, while the cardiology PACS market is swelling with first-time buyers. Is selecting the first cardiology PACS that much more challenging a process than selecting a first or second radiology PACS?
A growing number of first-time radiology PACS buyers are confident that they can select a “good” PACS by using market report classifications, site visits and peer advice. They believe they can make a “good” PACS work for their facility by making a genuine effort to re-engineer their department workflow to fit the system and executing the appropriate physician outreach programs. If they fall somewhat short of these goals, there is always outside help available from the vendor or consultants.
The right RFP process, in conjunction with market reports, site visits and peer advice, will identify a “good” PACS that will also be the “best” fit to their expectations and workflow requirements, therefore requiring a minimum change to department and physician workflow.
Worth your While
Using a succinct RFP in today’s radiology PACS selection process is well worth the time invested in writing it.
PACS are not commodities. They are more complicated and sophisticated than ever. Subtle differences can make a big impact on workflow for all types of users. A well-written RFP references current technologies and can easily differentiate today’s PACS solutions, making it much easier for users to identify the “best” solution for their environment.
The RFP process can assist users in the design of the system that will best meet their requirements. The RFP investigates the issues and infrastructure that simply cannot be seen in a product demo or a site visit. The responses to the RFP reveal issues that will need to be addressed in the contract negotiations and should be referenced in the contract.
Maximize ROI on an RFP
When executing the RFP, if you want to maximize your return on investment (ROI), there are three principal considerations to keep in mind throughout the process. First of all, create a list of questions that focus on issues, applications and features that are truly important to you. Get a committee of IT, clinical support, technologists and physicians involved.
Then think differentiation. The purpose of the RFP is to help differentiate the systems, not confirm the obvious. Go through your list and eliminate any questions that relate to an issue, application or feature that you know all of the vendors support in the same way. If you’re not sure that they support the feature or not sure about the way they support the feature, leave it on the list.
Last of all, think well-written. Go back through the list of surviving questions and rewrite every one of them with the most concise and unambiguous wording imaginable.
Ten key issues in today’s PACS
There are 10 key issues in today’s PACS that you should understand completely if you are going to select a “good” PACS that will be the “best” fit to your department.
1. DICOM and IHE - Translate the actual DICOM objects and SOP classes that you want the system to support, especially those that are inspired by IHE profiles, into real-world applications or functions that everyone can clearly understand. An example for DICOM Grayscale Softcopy Presentation States is the DICOM SOP Class inspired by the IHE (Year 3) Consistent Presentation of Images profile. Write a series of RFP questions asking if the system supports sharing overlays, W/L settings, custom processing results, etc., with all clinicians. Can multiple Presentation States be stored? Ask if the system archives this object as a DICOM object. Ask if the vendor can guarantee the ability to migrate this key object to the next PACS.
2. Tech QC stations - The system should support a multifeatured, Web-enabled Technologist QC application that would enable the Tech to perform all of the required study QC functions, including document scanning. Make sure to ask how the software is delivered to the QC station (PC) and whether it is available under an unlimited user license.
3. Display software - Ignore buzz words like “Web PACS.” State your expectations. A suite of display software based on a single, master, server-based display application from which all classes of display packages (diagnostic, clinical, technologist) are created through assignment of user privileges is usually the easiest to learn and support. Display software that runs on the display hardware (fat client) is usually faster and more richly featured than software that runs on a server and delivers the result to the display (thin client). If IT doesn’t want to have to load this software onto every display platform, ask if the display software is Web-delivered, Web-enabled or classified as zero-administration.
4. Single patient folder - If you are a multifacility enterprise and determine that local facility servers, each with their own Directory, is the best approach, make sure the system supports a combined virtual enterprise Directory and a unified single-patient folder.
5. Information lifecycle management - The system should feature a methodology for Media Migration (moving study data from media type to media type) and Purging (deleting studies from both the Directory and the Data Databases) based on multiple user-defined criteria located in Public DICOM Tags of the study header.
6. Advanced processing - Specifically request a list of all advanced applications supported by the system. Are they in-house developments or third-party licenses? Are they integrated into PACS Display or interfaced? Are they available as floating concurrent licenses or fixed seat licenses? Are they available to clinicians by assigned privilege or only on Diagnostic displays? Can they be accessed at home?
7. RIS- vs. PACS-driven work list. - In a sense, all PACS worklists are driven by the RIS, since orders, ADT, scheduling and study status information is used to create the lists. A RIS-driven worklist implies that the RIS application is actually embedded in the PACS workstation. This can be an advantage if the radiologists like working within the RIS as opposed to the PACS. It can also be an advantage if this means that the RIS and the PACS are sharing a single Directory (source of patient and study information).
8. Server architecture - How is the PACS server configured? Dedicated individual application servers vs. dual servers running in heartbeat (failover) mode vs. a multiserver cluster with at least two servers running each major software application (Directory Database, Display Applications and Workflow, Load Balancer). Most current generation PACS are based on clusters.
9. Data portability - What Data Storage methodology is featured? Is all of the study data stored as DICOM objects? Is the data stored according to DICOM Part 10? Does the system feature a DICOM transfer syntax like J-PEG 2000? Will the vendor disclose the Directory schema and dictionary? All of these issues have a significant impact on future data migration.
10. System optimization services - Does the vendor possess the programs and manpower to help you with workflow redesign and technology adoption among the referral community? You will need help determining how a “good” PACS will “best” fit your department. Shouldn’t the vendor be capable of providing this assistance?
Whether your RFP is for a radiology PACS or cardiology PACS, for a first-time buyer or replacement buyer, a well-thought-out and concise RFP can make all the difference when selecting a “good” PACS with maximum ROI.