It is 8:40 on a Monday morning. Eleven patients are due before lunch. The scheduling program shows a spinning wheel, and the receptionist cannot see who is coming, with which practitioner, or for what. Someone says "it'll be back in a minute". Twenty minutes later, nobody knows how long it will take, and patients are starting to queue.
Most practices that depend on software will eventually face a day like this. The difference between a bad morning and a lost day is not luck. It is whether you decided in advance what to do. I won't quote outage statistics here, because they vary too much to mean anything for your practice. The question is simply: what happens in yours?
Two separate problems: keep working, and get back
When software goes down, people often mix up two goals.
Keeping working is about the next few hours. Can the practice still see patients safely and record what happens?
Getting back is about restoring the system and its data properly afterwards. This is where backups come in.
Both need a plan, written down, that someone other than the person who wrote it could follow.
Downtime procedures: the paper-and-printout plan
The most useful downtime plan is usually humble. It answers questions like:
- What do we print or keep offline? A read-only copy of today's schedule, refreshed every few hours or at least each morning, so reception knows who is coming even if the system is dark. For patients with critical information your clinicians have decided matters in an emergency, an equally accessible copy on a device that doesn't need the network.
- Where do we write things down? Pre-printed forms for new patients, notes and payments, so information is captured in a consistent way and can be entered later.
- Who decides we are "in downtime"? One named person, and a way of telling everyone, so people don't each improvise.
- Who do we call? Your vendor's support number, your IT person, written on the wall, not saved only in a phone that can't be reached.
- How do we catch up? An order for re-entering paper records afterwards, with a check that nothing was missed or entered twice.
A custom system can help here by making the offline copy a feature. A button that produces tomorrow's schedule as a printable sheet, or a lightweight read-only view that works without the main system, costs very little compared with its value on the day.
Backups: a backup you've never restored is unproven
Many owners believe they have backups. Fewer have ever checked that those backups work.
A backup that has never been restored is an assumption, not a safeguard. Files can be incomplete, the backup job can have been failing silently for months, or the person who knows how to restore left a year ago. The only proof is to restore it, into a separate test environment, and check that the data is there and usable.
For the shape of a good backup, I'd point you to the US CISA's ransomware guide, which advises keeping offline, encrypted backups of critical data, backing up often, and regularly testing the availability and integrity of backups in a disaster-recovery scenario. The offline part is important: if a backup sits permanently connected to the same network as the system, anything that damages the system can damage the backup too.
Ask three plain questions. Where are the copies kept, and is at least one of them somewhere else? When was a restore last tested, and by whom? How long did it take?
Recovery time and recovery point, in plain words
Two terms come up in any serious conversation about this. They sound technical, but the ideas are simple.
Recovery time objective (RTO) is how long you can afford to be without the system. "We can manage on paper for half a day, but not for three." That is an RTO.
Recovery point objective (RPO) is how far back in time you can afford to lose data. NIST defines it as the point in time to which data must be recovered after an outage. If the system is restored to last night's backup, everything entered today is gone. Can you live with that, or do you need copies every hour?
These are business decisions, not technical ones. A practice with online bookings and card payments will answer them differently from a practice that sees ten patients a day. Shorter times and smaller losses cost more, so deciding what you really need avoids paying for what you don't.
Questions for your vendor or developer
- Where is our data stored, and how often is it copied? Is any copy kept somewhere separate?
- When did you last test restoring it, and how long did it take?
- What are the recovery time and data-loss figures in our agreement, in hours?
- Can we get a read-only copy of the schedule that works offline?
- How will we be told if there is a problem, and how quickly?
- If we need to leave, can we get a full copy of our data in a usable form?
If the answers are vague, that is the answer.
A first step
This week, hold a fifteen-minute rehearsal. Pretend the system is down at 8:40 on Monday. Give the receptionist only what you have today, and see what they can find out. Write down every gap, and fix the first one: a printed schedule often helps turn a crisis into an inconvenience. Keep printouts and offline copies as protected as the system itself, and destroy them afterwards.