RFI/RFP Template (Updated)

Editor's Note: This update replaces the June 2007 RFI/RFP practice brief template.

The request for information/request for proposal (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 sample tool to assist healthcare providers as they issue an RFI or an RFP for electronic health record (EHR) or component systems. It is meant to be used in conjunction with the practice brief titled “The RFP Process for EHR Systems.“

Healthcare providers should customize this sample template by using the components that are applicable for their needs, adding components as necessary, and 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 whether the facility is a part of a healthcare delivery system, the facilities that are included in the project, and their locations.
      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
        The 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. 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 desired, as well as any pertinent details.
      1. Clinical Repository
      2. Clinical Documentation
      3. Computerized Physician Order Entry (CPOE)
      4. Ancillary Support (e.g., laboratory, radiology, pharmacy, etc.)
      5. Picture Archiving Communication System (PACS)
      6. Electronic Document Management/Document Imaging
      7. Customizable Workflow Management
      8. Interoperablity (e.g. for health information exchange)
      9. Patient Portals
      10. Other
    3. HIM Department Operations
      When requesting information for the HIM solution, 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. Patient Identity Management/Electronic Master Patient Index (e-MPI)
      4. Health Record Output and Disclosure Management
      5. Release of Information
      6. Screen Input Design
      7. Support for Mandated Reportable Data Sets
      8. Other
    4. System Administration -- Records Management and Evidentiary Support
      This functionality is applicable to 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/Auditing Function
      4. Digital Signature Functions
      5. Records Management Function
      6. Archiving Functions
      7. Continuity of Operations (e.g. support for backup, recovery)
      8. Maintenance of Standardized Vocabularies and Code Sets
    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
Each functional area is expected to have its own set of 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 RFP template to meet their needs.

Functional User Requirements/Features* 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 paper formats (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?        
Does the system allow for end-user notification when information identified as incomplete/missing is completed?        
Coding Completion/Analysis
Does the system support automation of coding work flow (e.g. computer-assisted coding)?        
Does the system support automated case assignment to work queues?        
Can the user assign cases based on special attributes (e.g. VIP, dollars, or case type such as cancer or trauma, etc.)?        
Does the system support online communication between employees and managers?        
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?        
Does the system contain tools for monitoring and evaluating the coding process?        
Does the system support electronic query capabilities?        
Coding/Transaction Standards (see also Section 4.k)
Does the system support ICD-10-CM and/or ICD-10-PCS in addition to ICD-9-CM?        
Does the system use General Equivalence Mappings (GEMs), such as between ICD-10-CM/PCS and ICD-9-CM or SNOMED CT and ICD-9-CM?        
Is the system compliant with the Version 5010 transaction standard?        
Health Record Output and Disclosure
Does the system allow a unified view of all component subsystems of the EHR at the individual patient level and at the date of service encounter level for purposes of disclosure management (including the ability to print and generate electronic output)?        
Does the system provide the ability to define the records or reports that are considered the formal health record for a specified disclosure or disclosure purposes?        
Does the system allow VIP patients to be flagged and listed confidentially on corresponding reports (i.e., census)?        
Does the system produce an accounting of disclosure, reporting at a minimum the date and time a disclosure took place, what was disclosed, to whom, by whom, and the reason for disclosure?        
Does the system provide the ability to create hard copy and electronic output of report summary information and to generate reports in both chronological and specified record elements order?        
Does the system provide the ability to include patient identifying information on each page of electronically generated reports and provide the ability to customize reports to match mandated formats?        
Does the system allow for redaction and recording the reason, in addition to the ability to redact patient information from larger reports?        
Release of Information (Note: Administrative release of information functionality may or may not be an integral component of an EHR system.)
Does the system support HIPAA management of non-TPO disclosures?        
Does the system track and report the date/time release of information requests are received and fulfilled?        
Does the system allow the ability to track whether the release of information consent/authorization was adequate, in addition to a corresponding disposition?        
Does the system generate invoices with user-defined pay scales?        
Does the system allow tracking of payments received?        
Does the system generate template letters for standard correspondence (e.g. patient not found, date of service not valid, etc.)?        
Does the system allow information to be released electronically?        
Authentication
Does the system authenticate principals (i.e., users, entities, applications, devices, etc.) before accessing the system and prevent access to all nonauthenticated principals?        
Does the system require authentication mechanisms and can the system securely store authentication data/information?        
If user names and passwords are used, does the system require password strength rules that allow for a minimum number of characters and inclusion of alphanumeric complexity, while preventing the reuse of previous passwords, without being transported or viewable in plain text?        
Does the system have the ability to terminate or lock a session after a period of inactivity or after a series of invalid log-in attempts?        
Access Controls
Does the system provide the ability to create and update sets of access-control permissions granted to principals (i.e., users, entities, applications, devices, etc.) based on the user's role and scope of practice?        
Does the system inactivate a user and remove the user's privileges without deleting the user's history?        
Does the system have the ability to record and report all authorization actions?        
Does the system allow only authorized users access to confidential information?        
Does the system prevent users with read and/or write privileges from printing or copying/writing to other media?        
Does the system define and enforce system and data access rules for all EHR system resources (at component, application, or user level, either local or remote)?        
Does the system restrict access to patient information based on location (e.g., nursing unit, clinic, etc.)?        
Does the system track restrictions?        
Does the system have the ability to track/audit viewed records without significant effect on system speed?        
Does the system allow for electronic access to specified patients/encounters for external reviewers?        
Emergency Access Controls
Does the system allow emergency access regardless of controls or established user levels, within a set time parameter?        
Does the system define the acceptable circumstances in which the user can override the controls for emergency access, as well as require the user to specify the circumstance?        
Does the system require a second level of validation before granting a user emergency access?        
Can a report be generated of all emergency access use?        
Does the system provide the ability to periodically review/renew a user's emergency access privileges?        
Does the system provide the ability to generate an after-action report to trigger follow-up of emergency access use?        
Information Attestation
Does the system provide the ability for attestation (verification) of EHR content by properly authenticated and authorized users different from the author (e.g., countersignature) as allowed by users' scope of practice, organizational policy, or jurisdictional law?        
If more than one author contributed to the EHR content, does the system provide the ability to associate and maintain all authors/contributors with their content?        
If the EHR content was attested to by someone other than the author, does the system maintain all authors and contributors?        
Does the system provide the ability to present (e.g., view, report, display, access) the credentials and the name of the author(s) and the attester, as well as the date and time of attestation?        
Data Retention, Availability, and Destruction
Does the system provide the ability to store and retrieve health record data and clinical documents for the legally prescribed time or according to organizational policy and to include unaltered inbound data?        
Does the system provide the ability to identify specific EHR data for destruction and allow for the review and confirmation of selected items before destruction occurs?        
Does the system provide the ability to destroy EHR data/records so that data are not retrievable in a reasonably accessible and usable format according to policy and legal retentions periods, and is a certificate of destruction generated?        
Record Preservation
Does the system provide the ability to identify records that must be preserved beyond normal retention practices and identify a reason for preserving the record?        
Does the system provide the ability to generate a legal hold notice identifying whom to contact for questions when a user attempts to alter a record on legal hold or an unauthorized user attempts to access a record on legal hold?        
Does the system provide the ability to secure data/records from unauditable alteration or unauthorized use for preservation purposes, such as a legal hold?        
Does the system provide the ability to merge and unmerge records?        
Does the system allow a record to be locked after a specified time so no more changes may be made?        
Minimum Metadata Set and Audit Capability for Record Actions
Does the system capture and retain the date, time stamp, and user for every object/data creation, modification, view, deletion, or printing/export of any part of the medical record?        
Does the system retain a record of the viewer?        
Does the system retain a record of the author of a change?        
Does the system retain a record of the change history?        
Does the system retain a record of the source of nonoriginated data?        
Does the system retain the medical record metadata for the legally prescribed time frame in accordance with the organizational policy?        
Does the system include the minimum metadata set for a record exchanged or released?        
Pending State
Does the system apply a date and time-stamp each time a note is updated (opened/signature event)?        
Does the system display and notify the author of pending notes?        
Does the system allow the ability to establish a time frame for pending documents before administrative closing?        
Does the system display pending notes in a way that clearly identifies them as pending?        
Does the system allow the author to complete, edit, or delete (if never viewed for patient care) the pending note?        
Amendments and Corrections
Does the system allow the author to correct, amend, or augment a note or entry?        
Does the system allow the author to indicate whether the change was a correction, amendment, or augmentation?        
Does the system record and display the date and time stamp of the change?        
Does the system provide a clear indicator of a changed record?        
Does the system provide a link or clear direction to the original entry/note?        
Does the system retain all versions?        
Does the system disseminate updated information to providers that were initially autofaxed?        
Documentation Succession Management and Version Control
Does the system manage the succession of documents?        
Does the system retain all versions when a change is made?        
Does the system provide an indicator that there are prior versions (when appropriate)?        
Does the system indicate the most recent version?        
Retracted State
Does the system allow for removing a record or note from view?        
Does the system allow for access of a retracted note or record?        
Does the system allow the user to record the reason for retraction?        
Does the system allow for notification of the viewers of the data to present correct information (if applicable)?        
Data Collection and 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?        
Does the system have the ability to track clinical decision-making alerts (e.g., when they were added to the system or discontinued, used, ignored, etc.)?        
Does the system comply with meaningful use reporting requirements?        
Patient Financial Support
Is your proposed solution fully integrated (or able to interface with the patient financial system), 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, which are HIPAA transaction standard compliant?        
Patient Portals
Does the system allow for electronic patient access (e.g., Web portal)?        
Health Information Exchange
Does the system enable participation in local health information exchange initiatives?        
    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 RFP template to meet their needs.

System Requirements/Features* Available Custom Developed Future Development Not Available
General System Requirements        
Is the system integrated or interfaced?        
Does the system provide the ability to archive via tape, CD, or DVD? Describe any other options.        
Are the COLD (computer output to laser disc) data streams available in ASCII (American Standard Code for Information Interchange)?        
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 to 800 workstations, concurrent users, etc.)?        
Does the system have the capability of recording change management logs related to platform upgrades and patches?        
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-S FM and EHR profiles? (Please provide us with your HL7 EHR-S FM and profile conformance statements.)        
System Security 
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 they change the database, and can they be managed through the audit trail/log?        
Does the system use encryption methods that render protected health information unreadable in compliance with the latest industry approaches and guidelines?        
Technical Requirements
Do communication components include TCP/IP (transmission control protocol/internet protocol)?        
Does the system use CCITT Group III, IV for compression schemes?        
Does the system support standard HL7 record formatting for all input and 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 Application Service Provider (ASP) hosted model?        
Does the system support browser-based options?        
Integration of Narrative Notes
Does the system support HL7's Clinical Document Architecture Release 2 (CDA-R2) standard for the encoding of narrative, text-based clinical information?        
Does the system receive, display, transform, and parse CDA-encoded clinical documents as described in the HL7 CDA-R2 Implementation Guides for document types, such as History and Physical Note, Consultation Note, Operative Note, and Diagnostic Imaging Report?        
Does the system receive, display, transform, and parse CDA-R2-compliant documents with encoded headers (Level 1 encoding)?        
Does the system process CDA-R2-compliant documents that include Level 2 encoding?        
Does the system process CDA-R2-compliant documents that include Level 3 encoding?        
    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 to assist with decision making.
    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 Sell-offs
      4. Whether the Vendor Is Public or Privately Owned
      5. Bankruptcy/Legal Issues (including under which name the bankruptcy was filed and when, or any pertinent lawsuits, closed or pending, filed against the company.)
      6. Research and Development Investment (expressed in a total amount or percentage of total sales)
      7. Status of Certification
    2. Statement of Key Differentiators
      The vendor should provide a statement describing what differentiates its products and services from those of 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 owing 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. Qualifications
      1. The vendor should provide a list of qualifications and resume, including a sample list of similar projects and clients.
    5. 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?
    6. Technology
      The vendor should provide technology specifications that support the product (e.g., database, architecture, operating system, ASP versus in-house, etc.).
    7. Services
      The vendor should describe the services offered and corresponding fees (if applicable).
      1. Project Management
      2. Consulting
      3. MPI Cleanup
      4. Integration
      5. Legal Health Record Definition
      6. Process Reengineering
      7. Other
    8. Training
      The vendor should outline the training provided during and after implementation.
    9. Product Documentation
      The vendor should specify the product documentation that is available and its formats.
    10. Implementation/Migration
      The vendor should provide detailed information about the implementation such as the timelines and resources required.
    11. Data Conversion
      1. If the system is not currently ICD-10-CM/PCS or Version 5010 compliant, describe plans for becoming compliant by regulatory required dates.
      2. How will the system handle both ICD-9-CM and ICD-10-CM/PCS data?
      3. How long will the system support both ICD-9-CM and ICD-10-CM/PCS codes?
      4. If the system uses General Equivalence Mappings (GEMs ), such as between ICD-10-CM/PCS and ICD-9-CM, describe how the integrity of the maps is maintained.
      5. Describe other data conversions (e.g., document imaging, platform conversions).
    12. Maintenance
      1. Updates/Upgrades
        The vendor should provide information on how the system is maintained, including how often the updates/upgrades are applied, methods used (e.g., remotely, on-site), and by whom.
      2. Compliance with Meaningful Use Incentive Requirements
        The vendor should provide its plan for addressing meaningful use on an ongoing basis, including plans for achieving corresponding certification requirements.
      3. Expected Product Lifetime
        The vendor should outline the expected time frame for the next version requiring a different platform or operating system upgrade
      4. Customer Support
        The vendor should outline the types of customer support packages offered (e.g., 24/7, weekday only), methods of support (e.g., help desk or tickets), and the tools used (e.g., 800 number, e-mail, Web-based, etc.).
      5. Expected Facility Support
        The vendor should outline the number of full-time employees expected to support the product at the facility.
    13. Pricing Structure
      1. Product Software Pricing
        1. Price
          The vendor should provide the price of the proposed solution, broken down by application/module, including licensing fees.
        2. Cost of Ownership (breakdown over a certain number of proposed contract years)
        3. Other Costs (maintenance, upgrades, consultation and support fees, post-implementation training and services, travel, etc.)
        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
    14. 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 provide the name and contact information of one person to whom all questions concerning the RFP should be directed. Generally, questions about the RFP must be submitted in writing within a given time frame, and the questions and answers are distributed to all vendors responding to the RFP. Provide the preferred method of contact, such as fax number or e-mail.
    2. Response Format, Deadline, and Delivery
    3. Contract Duration
      The facility should request that the vendor to disclose how long the returned information will be considered valid.
  1. Terms and Conditions
    1. Confidentiality
      State confidentiality rules in regard 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 facility should describe who will have access to the returned RFP and for what purpose.
    3. 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.
    4. Formal Presentation
      The facility should describe process and format requirements if the vendor is invited to present the software product suite.
    5. Acceptance or Rejection
      The facility should describe how the vendor will be notified regardless of whether the product is selected or not.
    6. Contract Provisions
      The facility should note the sections of the RFP response that can be included in the final contract.
    7. Type of Contract
      The facility should let the vendor know if this will be firm fixed price, cost plus fixed fee, a time and materials, or other type of contract.
* Also refer to certification requirements and Health Level Seven (HL7) EHR System Functional Model (EHR-S FM) for other key requirements/features.


Article citation:
American Health Information Management Association. "RFI/RFP Template (Updated)." (updated July 2010)