In HCBS and LTSS, technology is part of the care pathway. Scheduling, EVV, documentation, incident reporting, medication prompts, and on-call escalation often rely on platforms that can fail during cyber incidents, vendor outages, power disruption, or telecom loss. A credible COOP plan therefore includes “safe manual operations” as a designed mode, not an improvised workaround. This article supports Continuity of Operations Planning (COOP) for HCBS & LTSS and applies the discipline of Risk Management & Controls to downtime workflows, escalation, privacy, and recovery.
Why IT and communications outages create outsized risk in community-based care
When systems go down, care does not stop—but visibility and coordination often do. Supervisors may lose real-time coverage confirmation. Nurses and case managers may lose access to risk history or prior notes. Field teams may revert to informal texting that creates no defensible record and increases privacy exposure. The continuity objective is not to replicate your full system on paper; it is to prevent silent failure: missed visits, delayed escalation, duplicated tasks, medication-support errors, and post-event disputes about what was delivered and why decisions were made.
Two oversight expectations that shape downtime COOP
Expectation 1: You must maintain a defensible record during disruption
Funders, payers, and oversight partners generally accept that outages happen. They do not accept “we have no record” of visits, decisions, and risk responses. COOP must define a minimum viable record set (what must be captured during downtime), how it is secured, and how it is reconciled into formal systems after restoration with an auditable trail.
Expectation 2: Safety escalation cannot depend on one platform
Technology cannot be a single point of failure for safeguarding or clinical deterioration response. COOP must show how urgent concerns are raised, who receives them, how decisions are made, and where they are logged when standard systems (EHR, incident platform, call routing) are unavailable. This is a governance expectation as much as an operational one.
Design the “minimum viable operations” package for 24–72 hours
Downtime plans fail when they attempt to mirror everything your EHR or scheduling system does. Instead, define the minimum set of functions that must keep working to protect people and preserve payment defensibility. In HCBS and LTSS this typically includes: (1) visit coverage confirmation, (2) a safe method to communicate changes, (3) escalation and on-call decision capture, (4) medication support and critical care tasks, and (5) a controlled method to store and later reconcile records.
Operationally, this means having pre-built downtime packs (paper or offline digital templates) at the branch/region level and in supervisor kits, plus a defined “downtime lead” role to coordinate decisions and logging. It also means rehearsing the switch: who declares downtime, how staff are notified, and what the first-hour priorities are.
Operational Example 1: EVV and visit verification during an outage
What happens in day-to-day delivery. When EVV is unavailable, frontline staff use a downtime visit verification form that captures: participant name/ID, address, planned visit window, actual arrival/departure, services delivered, exceptions (late start, missed visit, refused entry), and supervisor contact. The supervisor maintains a live “coverage board” (spreadsheet or paper log) that tracks all scheduled visits and flags unfilled shifts. At the end of each day, the downtime lead collects forms into a controlled packet (by date and team), logs receipt, and stores them in a locked cabinet or secure scanned folder with restricted access.
Why the practice exists (failure mode it addresses). The core failure mode is invisible non-delivery: when the system is down, organizations can lose the ability to confirm that visits occurred, leading to missed support for high-risk individuals and later billing disputes. The downtime workflow creates a single source of truth for coverage and exceptions even when automated verification fails.
What goes wrong if it is absent. Without a defined EVV downtime method, agencies rely on ad hoc texts or verbal confirmations. Missed visits may not be discovered until a family calls, a participant deteriorates, or a payer audits claims. Supervisors can also unknowingly double-book staff, fail to prioritize high-acuity cases, or lose track of cancellations and refusals—creating both safety risk and over/under-billing exposure.
What observable outcome it produces. You can demonstrate continuity through: a complete visit coverage log, documented exceptions with supervisor actions, and a reconciliation report showing how downtime visits were entered post-restoration and which claims were held pending verification. The organization can also track missed-visit rates during downtime events and show that high-risk plans (e.g., medication support) were maintained.
Operational Example 2: Escalation, safeguarding, and clinical deterioration when systems are down
What happens in day-to-day delivery. COOP defines an alternate escalation route that does not rely on the usual call tree app or ticketing system: a dedicated phone line (or backup number) staffed by the on-call supervisor, with a paper/on-device escalation log template. Staff are trained to use a structured script (who, where, what changed, immediate risk, actions taken) and to record time-stamped decisions: advice given, emergency services contacted, family notified, and follow-up tasks assigned. The downtime lead also triggers a short “priority list” review twice daily for high-risk individuals so the team checks welfare and adjusts visit plans proactively.
Why the practice exists (failure mode it addresses). The failure mode is delayed recognition and fragmented decision-making: when notes and risk flags are unavailable, concerns can be minimized, routed late, or handled inconsistently. A structured escalation workflow preserves clinical reasoning and accountability, ensuring urgent risk is managed even without digital tools.
What goes wrong if it is absent. Staff may rely on personal numbers, unencrypted messaging, or informal advice with no record. This increases the likelihood of missed deterioration, inconsistent thresholds for calling 911, and gaps in safeguarding reporting. It also creates a governance problem later: leadership cannot evidence that decisions were made appropriately or that follow-up occurred, which undermines regulator and funder confidence.
What observable outcome it produces. You can evidence the escalation pathway through completed escalation logs, time-to-response metrics (even during downtime), documented follow-up completion, and audit samples showing that safeguarding concerns were routed and recorded consistently. Post-event review can quantify avoidable ED transfers or repeat incidents linked to escalation delays.
Operational Example 3: Secure documentation capture and audit-ready reconciliation after restoration
What happens in day-to-day delivery. COOP sets a reconciliation protocol that starts before systems return. Each downtime form packet is numbered, with a cover sheet listing included documents and the staff member responsible. Once systems restore, a designated “reconciliation team” enters records using a defined order (high-risk first), applies consistent tags (e.g., “downtime entry”), and records the source document ID for traceability. Supervisors complete a second-person check on a sample (or 100% for high-risk cases) to confirm that what was delivered is what was entered, and that exceptions are coded correctly.
Why the practice exists (failure mode it addresses). The key failure mode is post-restoration error: rushed data entry can introduce incorrect times, missing notes, duplicated visits, or incorrect billing codes. Without traceability, later audits cannot distinguish real delivery from reconstruction, increasing fraud/overpayment risk and undermining trust.
What goes wrong if it is absent. Teams often “catch up” by memory or incomplete notes. This leads to inconsistent documentation quality, billing denials, and increased complaint risk from families who see inaccurate records. In the worst cases, organizations cannot defend what happened during the outage, triggering paybacks, corrective action plans, or contract sanctions.
What observable outcome it produces. A strong reconciliation process yields measurable outcomes: reconciliation completion within defined timeframes (e.g., 72 hours), low error rates on second-person checks, a clear audit trail from paper/offline record to system entry, and a post-incident report summarizing impacts (missed visits, escalations, billing holds) and corrective actions.
Governance and assurance controls that make downtime credible
COOP for outages should be governed like any other high-risk process. Define a clear decision authority for declaring downtime and restoring normal operations, with criteria (e.g., EVV unavailable for X minutes, EHR outage confirmed, telecom routing failure). Maintain an incident log with start/end times, impacted systems, and operational mitigations. Build a simple assurance cadence: after each event, complete an after-action review that tests whether minimum viable operations worked, whether escalation timelines held, and whether reconciliation produced clean evidence.
Finally, ensure privacy and confidentiality are explicitly addressed. Downtime often increases the temptation to use personal phones, screenshots, or informal messaging. COOP should specify permitted channels, prohibited practices, and how paper/offline records are secured and destroyed per retention rules after scanning and validation.
What “good” looks like in an outage audit
In an audit or monitoring visit, “good” is not perfection—it is control. Reviewers should be able to see: (1) an outage declaration and notification record, (2) a visit coverage board showing prioritization of high-risk individuals, (3) escalation logs with time-stamped decisions, (4) secured downtime documentation packets, and (5) a reconciliation report that shows what was entered, what was held, and what exceptions were managed. The goal is to demonstrate that service continuity was safe, intentional, and accountable even when technology failed.