The Cardiovascular PACS RFP
Developing a cardiovascular Picture Archiving and Communications System (CPACS) Request for Proposal (RFP) is similar to efforts for radiology with the exception that cardiology can be far more extensive in terms of requirements. The purpose of any RFP is to secure consensus of the requirements for a system acquisition, and to solicit responses from vendors to determine who best meets those requirements.
Defining the RFP
I have found in my experience that there is a wide variation in the RFP process, and that it can be a daunting process for any organization. After all, most documents tend to follow similar outlines and content, and can result in multi-inch binder responses from the vendors. Who, in their right mind has the time to thoroughly review one of these documents, let alone multiple vendor responses! Ideally though, if one takes the time to prepare an extensive requirements document, and the vendor takes time to thoroughly respond to it, then shouldn’t the facility take the time to review the responses? After all, what is the point of the process if its objective is to aid in the selection of a vendor?
To begin with, the notion of a CPACS RFP can really be more extensive, as “CPACS” may be a misnomer.It may be more appropriate to speak to a Cardiovascular Information System, or CVIS application, or a combination of both (CPACS/CVIS). Any such implementation can also embrace ancillary information requirements in the form of a cardiac catheterization documentation (hemodynamic system), an electrophysiology documentation (EP) system, or an ECG system. When compared to radiology,cardiology can be much more extensive in terms of a complete system.
The general industry term is the RFP, but there are also variations depending on the developer’s objective. For example, there is the RFI, or Request for Inquiry, where the facility may simply want to test the waters as to what vendors might have to offer. Similarly there can be the RFQ, or Request for Quotation, where the facility is interested in a more extensive and uniform response from vendors. If a facility has done its homework and has a good idea of what it needs, the RFQ may be more appropriate as it may result in greater uniformity in vendor response, with less leeway on the part of the vendor in interpreting the customer’s requirements.
Structuring the RFP
There are many variations on the theme, but fundamentally, an RFP should cover some basic content. The following is the author’s thoughts on what constitutes effective content for an RFP.
Background and Introduction
In order for the vendor to respond effectively to a facility’s needs, it is important to convey to the vendor what one is trying to accomplish. Simply stating that you are in need of a CPACS is not an effective conveyance! A background section should convey what specifically you are looking for, why you are requesting it, and what you hope to achieve with it. It may also be helpful to the vendor to provide background information on your facility, department, and operations, including number of procedures and other operational parameters. Providing information on associated infrastructure such as the Information Systems the CPACS/CVIS will need to interoperate with may also be helpful.
RFP Instructions
Telling the vendor exactly what you are looking for includes telling them exactly what you want in the way of a response. This extends to the format of the response, and any federal, state, or local requirements that may impact a response, such as specific government requirements if you are some form of governmental institution.
Keep in mind that the uniformity of vendor response will be helpful in evaluating responses. I like to require that vendor responses are in the form of a Microsoft Excel spreadsheet, since it makes it easier to cut and paste responses into an evaluation document that can place vendor responses side by side for easy comparison. This has its limitations, since the cell size limitations of Excel are frequently exceeded by verbose vendor responses! This also tends to be a means of controlling the size of response that itself can enhance one’s review capability.
General Requirements
A general requirements section should address acquisition, implementation, and support requirements. This section should highlight all relevant areas that may be important to differentiating vendors based on their ability to support you the customer with the acquisition, implementation, and operation of the system. Vendors may differ in the way they deliver and support the technology, which may be important to the way a facility operates. For example, some vendors have extensive locally trained field engineers to support the system, whereas others may rely on remote telephone support. Depending on the sophistication of one’s information systems infrastructure, remote support may be fine – particularly if the facility is used to procuring its own hardware. In other cases such as with hemodynamic equipment that may be crucial to the procedure, the facility may be more comfortable with the local support model.
Support and maintenance requirements can also be significant differentiators. Warranty terms may vary significantly, as might contract terms. It is important to identify those areas that may be key to a facility’s operations, particularly if there is variability amongst prospective vendors.
Functional Requirement
Functional requirements usually relate to the way the system is intended to be used. It also relates to the interoperability requirements for the way a system is expected to interact within the facility’s environment. Another key aspect of functional operation is workflow. The functional requirements should identify how the facility intends to operate, and address both process and staff workflow. For example, should a cardiovascular physician desire to read right after the end of an exam near the control room, versus completing a report at some point later in the day will make a difference in how the system is configured.
Download Full copy.
If you have forgotten your UserName\E-mail or password, click here to retrieve it through your email address, If you are still unable to login, please contact us at : support@healthimaginghub.com