At 8:37 on a Wednesday, a community health centre lost access to the hosted system it used for appointment reminders, consent records, and staff scheduling. The vendor status page showed a yellow symbol and the phrase “degraded performance.” That small phrase quickly created a very human problem. A receptionist wondered whether to write patient names in a shared notebook. A manager considered using a personal video account for urgent consultations. Someone else asked for a download of all records from the previous evening. None of those people was careless. They were trying to keep care moving with the tools they could see.
Single-vendor dependency becomes dangerous when an organization has no shared way to decide during disruption. The goal is not to eliminate every outside service or to promise uninterrupted technology. It is to make sure a temporary failure does not force workers to trade privacy, fairness, or professional judgment for speed. A collective response gives people bounded authority, a safe fallback, and a common account of what is happening.
Start with the decisions that the service cannot postpone#
An outage plan often begins with servers, backups, and recovery times. Those details matter, but they do not answer the question facing a person at a desk: what can I safely do for the individual in front of me? The health centre began its planning by listing decisions rather than applications. Which appointments need an immediate response? Which requests can wait until the system returns? What information is essential to make a temporary decision? What must never be copied into a convenience tool? The list transformed a technical dependency into visible responsibilities.
An outage plan often begins with servers, backups, and recovery times. Those details matter, but they do not answer the question facing a person at a desk: what can I safely do for the individual in front of me?
This approach also exposes hidden links. A scheduling platform may seem separate from a clinical system, but it can govern who receives a reminder, which interpreter is booked, and whether a missed appointment is followed up. When one provider handles identity, notifications, and records, the effect of a failure spreads across roles. Mapping that journey makes it possible to identify a minimum service instead of attempting to recreate the entire platform under pressure.
Facts and assumptions need separate labels. If the status page says that logins are failing, staff should not conclude that records have been lost. If the vendor estimates two hours, that estimate is not a guarantee. A good internal update says what has been confirmed, what is still unknown, what the current workaround is, and when the next update will be issued. Plain uncertainty is kinder than confident speculation that leaves staff and service users making plans around a promise no one controls.
Give each role a narrow, usable responsibility#
The centre formed a continuity group of four roles. The front-desk lead collected cases that could not wait and explained the temporary route to visitors. The privacy lead approved the minimum information that could be used outside the platform. The operations manager contacted the vendor through the contracted escalation channel and maintained a decision log. A clinical lead determined how to prioritize urgent needs. Each role had a deputy. The group did not need to solve the incident by itself; it needed to stop uncoordinated improvisation from becoming the default.
This arrangement counters the myth of the technical hero. An engineer may understand authentication, but not the consequences of cancelling an interpreter. A clinician may understand urgency, but not which communication channel creates a new disclosure risk. A collective response joins those forms of knowledge without turning every decision into a committee meeting. Clear thresholds help: a receptionist can offer the approved temporary option; a manager may authorize a limited exception; only the continuity group can create a new data store or change the public message.
The decision log can be short. Time, observed fact, action taken, owner, and next review point are usually enough. Its purpose is continuity across shifts, not surveillance of staff. During an outage, people hear partial information and remember it differently. A shared, factual record prevents the afternoon team from repeating a decision that the morning team has already tested, and it creates a basis for explaining later why a particular exception was allowed.
Design a fallback that can end#
The most common bad workaround is a shadow copy of the vendor system: a spreadsheet with more columns each hour, a personal inbox full of attachments, or a chat group used as an unofficial case file. It feels efficient because it creates immediate visibility. It becomes risky because no one knows who has access, what version is accurate, or when the material will be removed. A continuity tool should be deliberately smaller than the normal system.
For the health centre, the fallback recorded only a case reference, the urgent action requested, the responsible professional, and a review deadline. Full notes stayed in an approved repository that remained available; they were not pasted into the temporary register. The group could tell whether an action had been taken without gathering a second copy of a person’s history. Every field had to answer one question: do we need this to make a safe decision before the hosted platform returns? If the answer was no, it did not belong there.
An expiry date is part of the design, not an administrative afterthought. The temporary register had an owner who would reconcile entries when access returned, confirm any delayed notifications, and delete the working file after the reconciliation was reviewed. If something needed to be retained, it had to be entered into the authorized system with a reason. This makes the end of the workaround as intentional as its beginning. Otherwise, an emergency measure becomes a permanent and invisible source of personal data.
Public communication should set boundaries too. The centre told patients which services were delayed, which number to call for urgent changes, and when another update would appear. It also stated that it would not ask for passwords, scans of identity documents, or detailed health information through text messages during the incident. Outages attract opportunistic fraud because people expect unusual requests. Explaining what the organization will not do is a practical privacy control.
Test a small interruption before a real one tests you#
Plans that exist only as documents are often written from the viewpoint of the person who knows the system best. A short exercise reveals the missing steps. The centre chose an ordinary afternoon and ran a tabletop scenario: the vendor was unavailable for ninety minutes, three visitors needed changes, and one interpreter booking could not be confirmed. Staff used the proposed fallback while an observer noted where they stopped to ask for permission or guessed at a rule.
The exercise found an unexpected weakness. The public notice directed people to a phone line, but the line was not staffed after five. It also found that the temporary form asked for a full identifier when a booking reference would have been enough. Both fixes were inexpensive, and neither would have appeared in a technical recovery test. The people doing everyday work are especially good at locating the gap between a plausible plan and an executable one.
Exercises should include the recovery stage. Once the vendor returns, who checks whether the temporary appointments match the live calendar? Who calls people whose message was delayed? Who closes access to the contingency folder? Who reviews whether a workaround caused confusion or unfair treatment? These questions make recovery a service responsibility, not merely a green light on a dashboard. They also make it possible to learn without blaming the individual who followed an incomplete instruction.
Useful measures remain close to the experience of the service. How long did it take to identify the correct temporary route? How many cases needed a second explanation? Were all temporary records reconciled by the deadline? Did the same question arise from several sites? These signals point to a design issue. They should not become a scorecard for who was “good at outages.” A culture that punishes uncertainty encourages people to hide the very problems the plan needs to surface.
Use the vendor relationship to preserve agency#
Vendor contracts should include clear incident contacts, notification expectations, export options, and a realistic description of recovery support. The organization should still know how to use those provisions. It needs current administrative access, a record of integrations, and a route to obtain its data in a usable format. Asking these questions is not a demand for total self-sufficiency. It is preparation to make informed choices when a provider changes a service, has an outage, or ceases operating.
The centre also set a rule for emergency offers from the vendor. A new “rapid access” tool could not be switched on merely because it arrived in an urgent email. Someone had to check what data it collected, who could enter it, and how it would be turned off. A faster route is valuable only when the new risk is understood and proportionate. Urgency does not erase the duty to leave a decision trace or to protect people with less power to question it.
The practical next step is modest. Choose one external service on which a significant decision depends. Bring together a service worker, a privacy or data colleague, a contract owner, and a person who can prioritize care. In forty minutes, define the minimum service, the temporary record, the communication boundary, and the first exercise date. That conversation will not prevent every outage. It will ensure that the next one is met by a team able to act together rather than by isolated people carrying the risk alone.
