Michael Bannach
Tuesday, 2:40 in the afternoon. Operatory three has a crown prep underway, the patient is numb, and the hygienist in four is waiting on a set of bitewings to load. Then the images stop loading. The front desk cannot pull up the schedule. Someone walks to the back and finds the server sitting there with its lights on, doing nothing useful.
Nobody in the building is thinking about IT at that moment. They are thinking about the person in the chair whose anesthetic has about forty minutes left in it, the two patients in the waiting room, and the four more due before five o’clock.
It is one of the most common calls a dental or medical practice makes to its IT provider. What separates a practice that loses an hour from a practice that loses the day is almost never the quality of the hardware. It is whether anyone decided, in advance, what the next forty-five minutes should look like.
The first ten minutes belong to the practice, not the IT provider
Before anyone picks up the phone to your IT provider, two things need to happen inside the practice, and they need to happen without a meeting.
First, someone has to decide whether the clinical work in progress continues. For the crown prep, the answer is usually yes: the dentist has the tooth in front of them, the shade was taken, and the lab slip can be written by hand. For the hygiene appointment waiting on radiographs, the answer may be to flip the visit order and do the cleaning first. These are clinical calls, and they belong to the clinician. The mistake we see is the whole office freezing while someone reboots a server, because nobody has said out loud that patient care continues on paper for the next hour.
Second, the front desk needs a printed copy of today’s schedule and tomorrow’s. Not a report run when the system comes back. A copy that already exists, printed at the end of the previous day, sitting in a folder. It costs a sheet of paper a day and it means the person answering the phone can still say “yes, you are confirmed for 3:30” while everything else is dark. Yesterday’s copy goes in the shredder, not the recycling, because it is patient information on paper.
If your practice does neither of these things today, you do not have a downtime plan. You have a hope.
Minute ten: the call, and what the right answer sounds like
Now the call goes to whoever supports your systems. The answer you get in the first two minutes tells you most of what you need to know about your provider.
The wrong answer is a ticket number and a promise that someone will look at it. The right answer is a person who can see your server from where they sit, tell you whether it is a hardware failure, a software hang, or something on the network, and tell you what they are going to do about each case. That requires monitoring that was already in place before the failure, and remote access that was already configured. If your provider has to ask you to walk over and read them the error on the screen, the monitoring was not there.
From here, the path splits.
If the server is hung, a remote restart and a check of the practice management services usually has the schedule back inside fifteen minutes. Imaging often takes a few minutes longer because the imaging software and the sensor drivers need to be confirmed one operatory at a time.
If the server is dead, the question is whether your backup can be turned into a running system, and how quickly. This is the part most practices have never tested, and it is the part that decides whether the afternoon is lost.
A backup you have never restored is a theory
Almost every practice we meet has a backup. Far fewer have ever restored from it. The difference matters because a backup that copies files is not the same thing as a backup that can bring Dentrix or Eaglesoft back to life on different hardware in under an hour. The first is a safety net for a deleted file. The second is what keeps the chairs full.
The questions worth asking whoever runs your IT, this week, are simple:
- When was the last time you restored our practice management database from backup, as a test, and how long did it take?
- If the server fails at 2:40 on a Tuesday, where does the practice run from at 3:30? On a spare machine in the office? In a cloud copy? On the technician’s laptop?
- How often does the backup run during the day? A nightly-only backup on a practice server means a 2:40 failure costs the whole day’s entries.
- Is at least one copy of the backup somewhere ransomware on our network cannot reach?
If the answers are vague, the backup is a theory. If the answers include a date and a number of minutes, you are in good shape.
Someone has to show up
Remote support solves most problems, and it should be the first move. But a failed drive, a dead power supply or a sensor that stopped talking to its workstation needs hands in the building. The honest question for any practice is: when that happens, who is coming, and when?
This is the reason we built Stealth RX Complete around an on-site response that is included rather than billed by the hour. A practice within fifty miles of one of our technicians gets someone at the door when a covered system fails, within 48 hours and usually far sooner. We did that because a practice is not an office. When an accounting firm’s server goes down, the staff lose an afternoon of billing. When a dental server goes down, a room full of patients loses their appointments and some of them do not come back.
Whether you work with us or not, that is the standard to hold your provider to. Ask them in writing: when a covered system fails, is a technician coming, is that included, and how long will it take?
The forty-five minutes, written down
Here is what the afternoon can look like at a practice that has done the work. The server stops. The dentist finishes the crown prep, takes a conventional impression and writes the lab slip by hand. The front desk pulls yesterday’s printout and keeps checking people in. The office manager calls support and hears, within a few minutes, that the server’s main drive has failed and that the practice will be running from the cloud copy of the backup taken an hour earlier, in about twenty-five minutes. A technician is dispatched for the hardware. By 3:20 the schedule is back on screen, imaging is back by 3:35, and the only thing lost is the last hour of entries, which get re-entered before close from the printed schedule and the providers’ notes.
Nothing about that afternoon depended on luck. It depended on a printout, a tested backup, monitoring that was already watching, and a provider who had agreed in advance to show up.
Where to start
If you do one thing after reading this, ask your IT provider for the date of your last restore test. If you do two, print tomorrow’s schedule before you leave tonight. Everything else in a downtime plan builds on those two habits.
If you would rather have someone walk through your practice’s setup and tell you plainly where it would break, our three-minute IT and security scorecard turns your answers into a written roadmap, and the first conversation is free.
