This practice brief web extra is made available for historical purposes only. The content has been updated.

RFI/RFP Template

The RFI/RFP process is vital to procuring a system that meets organizational and user needs. Because of this, it is imperative that adequate time be allotted for the process.

This template is provided as a tool to assist healthcare providers as they issue a request for information or a request for proposal for electronic health record or component systems. It is meant to be used in conjunction with the June 2007 practice brief titled “The RFP Process for EHR Systems.“

Healthcare providers should utilize the components of this template that are applicable for their needs, deleting those that are not.

Sections 1 and 2 should be completed by the facility.

  1. Introduction (introducing the facility to the vendor)
    1. Brief Description of the Facility
    2. Facility Information
      1. Complete Address
      2. Market (acute, ambulatory, long-term care, home health)
      3. Enterprise Information
        The organizations should provide all relevant information including if the facility is a part of a healthcare delivery system and the facilities that are included in the project.
      4. Size
        The organization should provide any information that will be relevant to the product such as the number of discharges, visits, beds, etc.
      5. General Description of Current Systems Environment
        he organization should provide general information regarding current information systems structure (i.e., hardware and operating systems).
    3. Scope
      The organization should provide a brief narrative description of the project that the RFP covers and the environment sought (e.g., total EHR, phased approach, hybrid support).
  2. Statement of Purpose

    1. Overall Business Objectives/Drivers
      The organization should list high-level business goals it is looking to achieve by implementing the software.
    2. Key Desired Functionality;
      When requesting information for the facility-wide solution (e.g., EHR), the organization should list the various features and functions of the system it is looking for, as well as any pertinent details.
      1. Document Imaging
      2. Clinical Repository
      3. Clinical Documentation
      4. Computerized Physician Order Entry (CPOE)
      5. Ancillary Support (e.g., lab, radiology, pharmacy, etc.)
      6. Picture Archiving Communication System (PACS)
      7. Other
    3. e-HIM Process Support
      When requesting information for the HIM solution (e.g., document imaging system), the organization should list the various processes and functions of the system it is looking for, as well as any pertinent details.
      1. Chart Analysis/Deficiency Management
      2. Coding/Abstracting
      3. Release of Information
      4. Disclosure Management
      5. Forms Management
      6. Support for Mandated Reportable Data Sets
      7. Other
    4. System Administration and Management
      This functionality is applicable or used for all components or modules of an application. Facility requirements for this functionality should be specified in the detailed system requirements.
      1. User Administration
      2. Access Privilege Control Management
      3. Logging Capabilities
      4. Auditing Functions
      5. Digital Signature Functions
      6. Archiving Functions
      7. Support for Back-up/Recovery
      8. Customizable Workflow Management
    5. Future Plans
      General description of long-term plans, including identified future systems environment and projected timetables.

Sections 3 and 4 should be completed by the vendor,

  1. Requirements
    Vendors should provide availability and timelines for development of software to fulfill requirements not available at this time.
    1. User Requirements

Sample questions related to HIM functional user requirements and features are provided below. This table is a sample only. Organizations must customize this to meet their needs. Each functional area is expected to have its own set of user requirements.

Functional User Requirements/Features (refer to CCHIT requirements and HL7’s EHR System Functional Model) Available Custom
Developed
Future Development Not Available
Chart Completion/Deficiency Analysis
Can the organization define the intervals for aging analysis (e.g., 7-days, 14-days, 21-days, etc.)?        
Does the system allow for standard and ad-hoc reporting for chart deficiency/delinquency analysis?        
Can delinquency reports be sent to physicians/clinicians in electronic (e.g., e-mail or fax) and in paper format (letters)?        
Does the system allow you to define or detail all deficiencies by provider, by area of deficiency, or other combinations (e.g., group practices, etc.)        
Does the system allow the organization to list all records (charts) by the deficiency type?        
Can deficiency analysis be conducted at the time the patient is prepared for discharge from the facility?        
Does the system support most industry standard dictation systems to allow transcribed reports to be easily and efficiently completed?        
Coding Completion/Analysis
Can the user assign cases based on special attributes (e.g., VIP, dollars, or by type of case such as cancer or trauma, etc.)?        
Can coders and supervisors communicate online?        
Does the system support most industry standard encoders/groupers?        
Does the system support both on-site and remote coding activities?        
Does the system support assignment of high-risk coding to supervisory staff or allow coding verification as staff complete cases?        
Can the system support ICD-10-CM and/or ICD-10-PCS?        
Disclosures and Release of Information
Does the system support HIPAA management of non-TPO disclosures?        
Does the system support accounting for disclosures to patients?        
Can users receive automatic alerts of disclosure limitations and potential HIPAA violations?        
Does the system generate invoices with user-defined pay scales?        
Does the system allow tracking of payments received?        
Does the system support requests for amendments or corrections by patients?        
Does the system generate template letters for standard correspondence (e.g., patient not found, date of service not valid, etc.)?        
Patient Financial Support
Is your proposed solution fully integrated, offering users an electronic form of the business office?        
Can patient information be placed in folders to easily identify those details that refer to the patient (guarantor) account(s)?        
Can you electronically capture, store, and retrieve computer-generated documents and reports, such as the UB-04 or the CMS 1500?        
Data Reporting
Does the system allow for real-time data collection and progress measurement against preset targets?        
Does the system produce reports on turnaround days, dollars pending, costs per chart by process, days to billing, and so on, as related to AR?        
Can your system interface with other disparate systems that collect quality measurement data (e.g., CMS quality measurement requirements, Joint Commission ORYX measurement, etc.)?        
    1. System Requirements
      Organizations should provide a list to vendors of what current technology needs to be supported. Vendors should then provide information on their system’s available requirements.

Sample questions related to system requirements and features are provided below. This table is a sample only. Organizations must customize this to meet their needs.

System Requirements/Features (refer to CCHIT requirements and HL7’s EHR-S Functional Model) Met Fully Custom Developed Under Development Not Available
General System Requirements        
Is the system integrated or interfaced?        
Does the system provide the ability to archive via tape, CD, DVD? Describe any other options.        
Are the COLD data streams available in ASCII?        
Does the system support audit trails at the folder level for managing access, editing, and printing of documents?        
Does the system make audit trail logs available to the organization, including the date, time, user, and location?        
Does the system support an online help function/feature?        
Is the proposed solution scalable (e.g., can it support 50–800 workstations, etc.)?        
Can the system identify or distinguish the facility location in a multi-entity environment?        
Can the system support a centralized database across multiple facilities?        
How compliant is your product with the HL7’s EHR System Functional Model and EHR profiles? (Please provide us with your HL7 EHR System Functional Model and profile conformance statements.)        
System Security 
Does the system prevent users from accessing functions when they have not been granted user rights?        
Does the system monitor security attempts for those without user rights, and those logged in the audit trail/log?        
Does the system track all activity/functions, including where it changes the database, and can it be managed through the audit trail/log?        
Technical Requirements and Industry Standards
Is the operating system Window’s 2000 or NT based?        
Do the communication components include TCP/IP?        
Does the system utilize CCITT Group III, IV for compression schemes?        
Does the system support standard HL7 record formatting for all in/output?        
Does the system support SQL for communication?        
Does the system support thin–client PCs?        
Is the system sized for capacity to allow for planning? Describe your recommendations.        
Does the system support disk shadowing and system redundancy provisions? Please describe.        
Can your solution be supported as an ASP (hosted) model?        
Does the system support browser-based options?        
    1. Interfaces
      Organizations should provide a list of existing interfaces that will need to be supported, as well as new interfaces that will have to be created and supported, including any pertinent interoperability information that exists and will be needed in the future. Vendors should provide information regarding their system’s ability to meet the organization’s interface requirements.

  1. Vendor Questionnaire
    The organization should request information about the vendor and the product that will help it make a decision about the vendor and its product.
    1. Vendor Background and Financial Information
      1. Company Name and Geography
        The organization should request an address of a branch close to the facility as well as the headquarters. Staff may want to visit both.
      2. Company Goals
      3. Year the Company Was Established, Significant Company Merges, Acquisitions, and Sale-Offs
      4. Whether the Vendor Is Public or Privately Owned
      5. Bankruptcy/Legal Issues (including under which name the bankruptcy was filed and when. Organizations should also find out if there are there any pertinent lawsuits, closed or pending, filed against the company.)
      6. Research and Development Investment (expressed in a total amount or percentage of totals sales)
      7. Status of CCHIT Certification
    2. Statement of Key Differentiators
      The vendor should provide a statement describing what differentiates it products and services from its competitors.
    3. Customer Base and References
      1. Customer List (or total number of customers per feature or function, if a list of customers cannot be provided due to confidentiality/privacy concerns)
      2. References that Can Be Contacted
        The vendor should provide references the facility can contact/visit based on product features and functions most suitable to the facility as well as those using the latest versions of the software.
    4. User Participation
      1. User Groups
        Organizations should provide a list of the user groups and ask whether it can attend a meeting or a call for review purposes.
      2. Requirements Gathering
        The vendor should request information regarding customer participation in requirements gathering stages of system development. How is customer feedback, such as requests for new requirements, handled?
    5. Technology
      The vendor should describe the technology that supports the product. (e.g., database, architecture, operating system, ASP vs. in-house, etc.)
    6. Services
      The vendor should describe the services offered by the vendor
      1. MPI Clean-Up
      2. Legal Health Record Definition
      3. Process Re-engineering
      4. Other
    7. Training
      The vendor should outline the training provided during and after implementation
    8. Documentation
      The vendor should specify the documentation that is available and their formats
    9. Implementation/Migration
      The vendor should provide detailed information about the implementation such as the timelines and resources required.
    10. Data Conversion
    11. Maintenance
      1. Updates/Upgrades
        The vendor should provide information on how the system is maintained, including how often the updates/upgrades are applied and which methods are utilized.
      2. Expected Product Lifetime
        The vendor should outline the expected timeframe for the next version requiring a different platform or operating system upgrade
      3. Vendor Support
        The vendor should outline the methods of support offered, such as the help desk or tickets, and the tools used (e.g., 800 number, email, web-based, etc.)
      4. Expected Facility Support
        The vendor should outline the number of FTEs expected to support the product at the facility.
    12. Pricing Structure
      1. Product Software Pricing
        1. Price
          The vendor should provide the price of the proposed solution, broken down by the component, including licensing fees.
        2. Cost of Ownership (breakdown over ‘x’ number of proposed contract years)
        3. Other Costs (maintenance, upgrades, consultation and support fees, post-implementation training and services)
        4. Discounts (available discounts such as those based on participating as a beta site)
      2. Invoicing (fee schedule and terms)
      3. Return on Investment
      4. Acceptance Period
        The vendor should outline the terms for validating the product after implementation and the refund policy
    13. Warranty
      The organization should request a copy of the warranty as well as how it is affected by maintenance and support agreements after the implementation period

Sections 5 and 6 are to be completed by the facility.

  1. Vendor Requirements and Instructions
    1. RFP Questions
      The facility should list those staff members at the facility to contact with RFP questions. Generally, questions about the RFP must be submitted in writing within a given timeframe, and the questions and answers are distributed to all vendors responding the RFP. Provide the preferred method of contact such as fax number or e-mail.
    2. Response Format, Deadline, and Delivery
  1. Terms and Conditions
    1. Confidentiality (state confidentiality rules in regards to the information the facility disclosed in the RFP as well as the rules pertaining to the information provided by the vendor)
    2. Information Access
      The organization should describe who will have access to the returned RFP and for what purpose.
    3. General Conditions
      1. Contract Duration (how long the returned information will be considered valid)
    4. Bid Evaluation and Negotiation
      The facility should briefly describe the evaluation process and the deadlines and provide the appropriate information if vendors are allowed to negotiate after the evaluation is complete.
    5. Formal Presentation
      The facility should describe the process and format of presentation if the vendor is invited
    6. Acceptance or Rejection
      The facility should describe how the vendor will be notified regardless of whether the product is selected or not.
    7. Contract Provisions
      The facility should note the sections of the RFP response that can be included in the final contract

Article citation:
. "RFI/RFP Template." Journal of AHIMA 78, no.6 (June 2007): [web extra].