When the Technology Fails: Crisis Protocols and Operational Continuity

There’s a category of risk in technology-mediated practice that most practices treat as an afterthought: what happens when the technology fails during a clinical encounter, particularly with a high-risk patient.

The scenario is not exotic. The video freezes during a session in which the patient was approaching disclosure of suicidal ideation. The platform goes down five minutes before a scheduled session with a patient in active crisis. The audio drops mid-sentence during a child welfare disclosure. These are not edge cases. They are operational realities. And from a systems design perspective, failure modes always matter more than happy-path performance.

The clinical and ethical framework

The APA’s “Guidelines for the Practice of Telepsychology” set the foundational standard: the clinician retains the same ethical and clinical obligations in a telepsychology context as in an in-person context, and is responsible for ensuring that the technology, the location, and the protocol support those obligations. State licensing board guidance generally aligns with this framing.

In practice, this means the clinician is responsible for: confirming the patient’s physical location at session start; having the patient’s emergency contact information current and accessible; knowing the local emergency services in the patient’s location; having a documented plan for technology failure; and documenting all of the above. This is unglamorous infrastructure. It is also, in a crisis, the difference between a protocol-managed situation and one the clinician is improvising through.

The technology-failure protocol

A defensible protocol for technology failure during a session typically includes several elements.

• A primary backup channel - typically a phone line - that both clinician and patient have confirmed at session start. The patient’s number is in front of the clinician. The clinician’s number is known to the patient. If video drops, the call moves to phone immediately.
• A secondary backup channel for catastrophic failure of the primary platform. Practices vary: some use a HIPAA-compliant secondary video platform; some use phone only; some have documented contingencies including emergency contact outreach if the patient is non-responsive after a failure during a high-risk session.
• A documented post-failure procedure. After the session is salvaged or terminated, the clinician documents what happened, what was said before the failure, what was done after the failure, and the patient’s status at the time the encounter concluded. This documentation supports both clinical continuity and audit defense.

Why this is more important now than five years ago

Two changes since 2020 have made the technology-failure question more operationally salient.

First is volume. Teletherapy is no longer a small percentage of behavioral health encounters; in many practices it is the majority. The exposure to technology-failure events scales with the volume.

Second is the increasing complexity of the technology stack itself. Practices relying on multiple integrated systems - EHR, video platform, secure messaging, patient-reported outcomes, RTM data flow - have more potential failure points than practices using a single platform for a single function. Integrated stacks reduce some failure modes (data fragmentation) and introduce others (cascading outages affecting multiple workflows simultaneously). Knowing which failure modes the architecture is exposed to is a systems design question practices should be asking.

What practices should also document

• A vendor-status log. Which platforms have been down, when, for how long, and what the practice’s response was. Over time, this becomes a basis for evaluating vendor reliability against contract SLAs.
• A patient-acknowledged technology agreement at intake. The patient knows what the practice’s protocol is for technology failure. This is part of informed consent.
• A periodic protocol drill. Once or twice a year, the practice walks through the technology-failure protocol with all clinical staff. The drill is brief; the value is that the protocol is fresh when it actually matters.

Where the integrated stack helps and doesn’t

An integrated technology stack reduces some failure modes - the patient’s PHQ-9 trajectory, current safety plan, emergency contact, and licensure verification all live in the same system, retrievable in one place during a crisis. It also concentrates other risk: a single vendor outage can disrupt multiple workflows simultaneously.

The defensible posture is neither full integration nor full fragmentation. It is integration with explicit attention to single points of failure, contractually committed uptime, vendor incident communication, and the practice’s own backup channels and protocols.

The honest version of the argument

Technology-failure protocols are unglamorous, infrequently used, and disproportionately consequential when they are needed. Practices that take them seriously (through written protocol, drilled response, vendor scrutiny, and patient-level safety planning) operate at materially lower risk than practices that treat the question as exceptional. Closing this gap does not require new technology. It requires explicit attention to the failure modes the existing technology already has.

Sources & References

• American Psychological Association. Guidelines for the Practice of Telepsychology.
• U.S. Department of Health & Human Services. HIPAA and Health Information Technology.
• Office of the National Coordinator for Health IT.
• SAMHSA. Suicide Prevention Resources for Healthcare Providers.
• 988 Suicide and Crisis Lifeline.
• Center for Connected Health Policy. Telehealth Policy and Resource Center.

#TelehealthSafety #CrisisProtocol #BehavioralHealth #PracticeManagement #ClinicalOperations #ReliefAI