Most healthcare software RFPs are built around feature checklists. Does the system do X? Does it support Y? Can it integrate with Z? This approach produces adequate results when selecting software that supports normal operations, where the full feature set is exercised regularly and deficiencies become apparent quickly through daily use. For downtime solutions, the feature checklist approach is fundamentally inadequate.
A downtime solution does not get exercised every day. It sits ready in the background, continuously updating, waiting for the moment it is needed. And the moment it is needed is a moment of operational crisis when there is no time to discover that a critical capability does not actually work the way it was described in the RFP response. Downtime solution selection requires a different kind of evaluation framework: one that probes not just what the system does in ideal conditions but how it behaves under the specific conditions of a real outage.
Building a downtime solution RFP that produces a defensible vendor selection requires asking questions that most vendor evaluation processes do not include. Here is a framework for doing it right.
Section 1: Integration Architecture
The HL7 integration between the downtime solution and the EHR is the most technically critical component of the system. The RFP should probe this area in specific detail:
- Describe your integration architecture for receiving patient data from the EHR. Is the data feed continuous or scheduled? What is the maximum lag between EHR data and the data available on downtime workstations?
- Which HL7 message types does your integration support? Specifically, does it receive ADT messages for census updates, pharmacy messages for MAR data, and order messages for pending order visibility?
- Provide documentation of your integration with our specific EHR platform and version. How many implementations have you completed with this platform, and can you provide references from comparable facilities?
- What happens to the data feed if the HL7 interface experiences a connectivity issue before an outage? How is this monitored, and how are failures detected and resolved?
- Does your integration support bi-directional data flow for post-outage recovery? Describe how data collected during a downtime event is returned to the EHR after recovery.
The answers to these questions separate vendors who have a genuine, tested integration from those who have a theoretical integration capability that has not been proven in comparable environments.
Section 2: Architecture and Offline Capability
The most important architectural question for any downtime solution is whether it works when the internet is also unavailable. This is not a rare scenario. Ransomware containment, ISP failures, and severe weather events can all produce simultaneous EHR and internet outages. The RFP should ask:
- Is your solution hosted on-premise, in the cloud, or as a hybrid? Where is patient data stored: locally on the workstation, on a local server, or in a cloud environment?
- Can your solution function with complete loss of internet connectivity? Describe exactly what capabilities remain available when the internet is unavailable and what requires connectivity to function
- What is the minimum network infrastructure required for full downtime workstation functionality? Can individual workstations operate independently if the local network is segmented during a cybersecurity containment event?
- How does your solution handle a scenario where the internet outage precedes the EHR outage? Is there a risk that the local data store becomes stale if the HL7 feed is interrupted before the EHR goes offline?
dbtech’s on-premise architecture stores patient data locally and functions without internet connectivity, which is the answer these questions are designed to surface. Vendors whose solutions require cloud connectivity should be required to explain specifically how their system performs in a full internet outage scenario.
Section 3: Clinical Workflow Capability
A downtime solution that only allows staff to view patient data is not sufficient for maintaining clinical operations during an extended outage. The RFP should probe what staff can actually do, not just what they can see:
- Describe the patient registration capability during a downtime event. Can staff register new patients electronically, assign downtime encounter numbers, and print barcoded wristbands and labels without the EHR being online?
- What electronic documentation capability does the solution provide during a downtime event? Describe the forms management system, including how forms are configured, how they are updated, and whether they support conditional logic and required field enforcement
- Does the solution support electronic signature for consent forms and other documents that require patient or provider signature during a downtime event?
- Describe how documents scanned during a downtime event are stored, organized, and transferred to the EHR after recovery
- What medication administration record capability is available during a downtime event? How current is the MAR data, and can staff document medication administration electronically during the outage?
Section 4: Post-Outage Recovery
The recovery process is where many downtime solutions create more work than they save, and it is where the RFP should spend significant attention:
- Describe the post-outage data recovery process in detail. How does data collected during the downtime period return to the EHR? Is it a structured electronic export, a manual re-entry process, or something else?
- What is the typical reconciliation time for an organization of our size after a two to four hour outage? Can you provide reference data or case studies from comparable implementations?
- What staff resources are required on our side to complete the reconciliation process? Does the recovery require specialized technical knowledge or can clinical and administrative staff complete it?
- Are there any categories of downtime-collected data that cannot be automatically exported back into the EHR and require manual intervention? If so, describe what they are and how they are handled
Section 5: Compliance and Security
Downtime solutions that handle protected health information must meet the same security and compliance standards as any other clinical system. The RFP should include:
- What security certifications does the solution hold? Describe your HIPAA compliance posture, including how you satisfy the Security Rule’s requirements for access control, audit controls, and contingency planning
- Describe the access control architecture for the downtime workstations. How are authorized users authenticated, and how is access to patient data limited to authorized staff during a downtime event?
- What audit logging capability does the solution provide? Can the organization produce a log of which staff accessed which patient records through the downtime system during an outage period?
- How is patient data protected at rest and in transit within your system? Describe your encryption standards for locally stored downtime data
Section 6: Pricing, Implementation, and Support
The commercial and operational sections of the RFP should be specific enough to allow direct comparison across vendors:
- Describe your pricing model in detail. Is pricing per workstation, per bed, per user, or structured differently? Provide pricing for our specific deployment scope
- What are the implementation timeline and resource requirements? What is required from our internal IT team during implementation, and what does your team handle?
- Describe your ongoing support model. What is the response time for a critical issue during an actual downtime event? Is there 24/7 support availability?
- How are EHR upgrades managed? When our EHR vendor releases a major upgrade, what happens to the HL7 integration, and who is responsible for ensuring continued compatibility?
- Provide three to five customer references from healthcare organizations comparable to ours in size, EHR platform, and facility type
For IT directors who want to see how dbtech responds to each of these question areas before building a formal RFP, a product demonstration and technical review provides a working basis for informed RFP development. You can also contact our team to discuss your specific evaluation requirements.