There is a version of this conversation happening in healthcare IT departments across the country. An IT director raises the need for a dedicated downtime solution. A CFO or CEO asks why that investment is necessary when the organization already pays the EHR vendor a significant annual contract. The IT director does not have a crisp answer that lands. The budget request is deferred. And the organization continues operating with the assumption that the vendor relationship covers something it does not actually cover.
This misunderstanding is so common and so consequential that it deserves to be addressed directly. The EHR vendor is responsible for restoring the EHR when it fails. The healthcare organization is responsible for what happens to patients during the period before the EHR is restored. These are different problems with different solutions, and conflating them is one of the most expensive misperceptions in healthcare IT leadership.
What the EHR Vendor Actually Covers
Understanding where the vendor’s responsibility ends requires reading the service level agreement carefully rather than relying on assumptions about what a major software relationship includes. Most EHR vendor SLAs define the vendor’s obligations in terms of:
- System uptime targets, typically expressed as a percentage of available hours per month or year, which define the vendor’s commitment to keeping the system available
- Recovery time objectives for restoring the system after an outage, which define how quickly the vendor commits to bringing the system back online after a failure
- Support response time commitments, which define how quickly the vendor will engage with a reported outage and what escalation paths are available
- Data protection and backup obligations, which define how the vendor protects the underlying data from permanent loss
What is almost universally absent from EHR vendor SLAs is any commitment to maintaining the healthcare organization’s clinical operations during the period when the system is unavailable. The vendor’s obligation is to restore the system. What happens to patients between the system going down and the system coming back up is the healthcare organization’s problem to solve.
This is not a gap that vendors are hiding. It is a reasonable division of responsibility that most EHR contracts make explicit for anyone who reads them. The vendor sells and supports software. The healthcare organization delivers patient care. When the software is unavailable, the patient care must continue regardless, and that continuity is the organization’s responsibility.
The Specific Gap That Leadership Does Not See
The gap between what the EHR vendor covers and what the organization needs is most visible when it is described in clinical terms rather than technical ones. Walking leadership through a specific scenario tends to produce the moment of recognition that abstract arguments about vendor responsibility do not.
Consider a scenario where the EHR goes offline at 7 AM during a shift change. The vendor is immediately notified and begins working on restoration. The estimated recovery time is four hours. During those four hours:
- Nurses on every inpatient unit lose access to the medication administration record and cannot safely verify medication orders without access to the patient’s current medication list and allergy information
- The ED continues receiving patients who need to be registered, assigned encounter numbers, and issued barcoded wristbands, but the EHR-based registration system is unavailable
- Lab results that return during the four-hour period cannot be routed to ordering physicians through the EHR’s results management system
- Clinical documentation from the shift change period cannot be entered into the EHR, creating a gap in the patient record that has to be reconstructed after restoration
- Billing staff cannot process charges for services delivered during the outage period, creating a revenue cycle gap that adds to the post-event workload
The EHR vendor is working on restoring the system during all of this. They are not providing nurses with access to medication records. They are not registering patients. They are not printing wristbands. They are not routing lab results. The vendor is doing exactly what the contract says they will do, and the clinical and operational reality of what that means is the gap that the organization needs to fill.
Addressing the Specific Objections Leadership Raises
Once the gap is clearly described, leadership typically raises a set of predictable objections. Having specific responses to each is the difference between a conversation that produces action and one that produces a deferral.
“The EHR rarely goes down.” This objection underestimates both the frequency and the cost of downtime events. The right response is specific data from the organization’s own incident history, including both planned maintenance windows and unplanned events. Most healthcare organizations experience more downtime than leadership realizes because the events are managed at the IT level without consistent upward reporting. Adding the financial cost of each event using the methodology described in our post on how to calculate the true ROI of a downtime solution converts a frequency argument into a financial argument.
“We have paper backup procedures for when it happens.” Paper backup procedures address the information access problem partially and the patient safety and revenue cycle problems poorly. The specific failure modes of paper backup, including the labor cost of post-outage manual re-entry, the documentation quality problems that lead to billing denials, and the patient identification risks created by handwritten wristbands, give this response its teeth. Paper is a workaround, not a solution.
“This seems like an IT problem, not a leadership problem.” The reframe that most effectively addresses this objection is the patient safety and regulatory framing described in our post on the case for treating downtime preparedness as a clinical quality initiative rather than an IT function. CMS Conditions of Participation require documented downtime preparedness. Joint Commission surveyors evaluate it. Patient safety events during inadequately managed downtime create organizational liability. These are not IT problems. They are leadership problems that happen to involve IT infrastructure.
“What does this cost?” This is the question that signals genuine engagement rather than deflection. The answer should present dbtech’s tiered pricing model alongside the organization’s estimated annual cost of unprotected downtime. The comparison almost always makes the investment decision straightforward.
Framing the Investment as Risk Management, Not Technology
The most effective framing for the budget conversation with healthcare leadership is risk management rather than technology procurement. Technology procurement conversations invite feature comparisons and budget scrutiny. Risk management conversations invite a different kind of analysis: what is the expected cost of the risk, what is the cost of mitigating it, and what is the residual exposure after mitigation?
A risk management framing of downtime preparedness presents the expected annual cost of inadequately managed downtime events based on the organization’s history and risk profile, the investment required to implement a solution like dbtech’s Downtime Solution that reduces that cost significantly, and the residual risk that remains even with the solution in place. This framing is familiar to healthcare executives who manage risk regularly and positions the investment decision in terms they are equipped to evaluate.
To build the financial risk analysis for your organization that supports this conversation, schedule a dbtech Downtime Audit Assessment or contact our team to discuss the investment case development process.