A practice loses its server on a Friday afternoon. Nobody is worried, because there are backups. There have always been backups, a green status has been arriving in somebody's inbox for years, and the IT company confirms they are running. Then the restore starts, and by Saturday evening the picture has changed. The database came back. The image folder was never in the backup set, because it sat on a machine added two years after the backup was configured. The scanned documents were on a shared drive that also was not included. Nobody had ever asked what was in the backup, because the backup was running.
That is the shape of most backup failures in dentistry. Not an absent backup, an incomplete one nobody had tested. This last lesson covers the three things that protect the record once you understand what it is: proving the backup by restoring it, controlling who can reach the record and under whose name, and doing both again in a harder form on the day you change systems.
Safeguarding electronic patient information is regulated, breach obligations are set by federal rule and by state law that varies and changes, and nothing here states a required interval, retention period or notification deadline as settled fact. Use this as a working map, then build your actual program with a healthcare attorney and a qualified security professional. The regulatory framing is in the Security Rule lesson, and the practical threat picture is in dental office cybersecurity.
What you will learn
- Why a backup that has never been restored is a belief rather than a protection, and how to test one without risking live data.
- Everything that has to be in a backup set beyond the practice management database itself.
- What a hosted vendor is actually responsible for, and the parts of your record that remain yours regardless.
- Why one shared login destroys the audit trail the record depends on, and how to offboard someone properly.
- What converts cleanly when you change systems, what never does, and how long the changeover really takes.
A Backup Is a Restore You Have Not Performed Yet
The only property of a backup that matters is whether you can get your practice back from it. Everything else, the schedule, the retention, the green checkmarks, is a proxy for that question, and proxies fail quietly.
What a complete backup set actually contains
Start by listing what would have to come back for the practice to open on Monday. In almost every office the answer is larger than one database.
- The practice management database. The obvious one, and usually the only one anybody checks.
- The image store. Wherever Lesson 4 told you to look. This is frequently on a different machine and frequently outside the backup set.
- Scanned documents and signed forms, which in many practices live on a shared drive rather than inside any application.
- Anything held by a vendor: forms, message history, claims records. You cannot back these up yourself, which is a different problem covered below.
- Configuration and license information, including what it would take to reinstall and reactivate every program, on the assumption that the person who set it up is unavailable.
- The list of what exists at all. Your vendor register from Lesson 4 is part of your disaster plan, because a restore also means knowing what you are restoring into.
Where the copies live
The working principle is separation. A copy in the building is fast to restore from and useless against fire, theft or flood. A copy off site survives those and is slower to recover. The copy that matters most is one that cannot be reached and altered from the network it protects, because the dominant disaster in dentistry is no longer hardware failure.
Ransomware specifically targets backups, and a backup that is permanently connected and writable from the same network is on the list of things being encrypted. That is the entire argument for an isolated or immutable copy, and it is covered in detail in our ransomware article, which is worth reading before rather than after.
Testing the restore
Here is the part practices skip. A test restore means recovering to somewhere that is not your live system, opening it, and confirming that it is genuinely your practice.
Arrange it with whoever supports your systems, because it should never be done by pointing a restore at production. What you are looking for is specific: does the database open, is recent data actually in it, do images appear for patients who have them, do documents open, and how long did it take from the moment you asked to the moment someone could have worked in it. Write that duration down. It is the only honest answer you will have to how long a disaster costs you.
Do this on a schedule you set and record the result each time, including who performed it and what did not work. A restore test that finds a problem is the test working. A practice that has never run one has no known recovery time, whatever the service agreement says.
Send these to whoever handles your backups and keep the reply: exactly which locations are in the backup set, how far back you can restore, whether any copy is isolated from the network, and when a restore was last successfully tested. Four questions, one email. The answers, or the difficulty of getting them, will tell you more about your actual position than any status dashboard.
What a Hosted Vendor Is and Is Not Doing For You
If your system is vendor hosted, a great deal of this is genuinely handled. The database is backed up on infrastructure you do not maintain, and that is a real benefit that removes a real category of risk.
It removes less than most owners assume. Four things typically remain yours regardless of where the database lives.
First, anything still on your premises. Imaging is the usual example, and plenty of practices run a hosted core alongside an on site imaging store nobody is backing up. Second, scanned documents and working files on local machines and shared drives. Third, the information held by every other vendor in your register, each with its own arrangements. Fourth, and most important, what you can actually take with you. A vendor keeping your data safe and a vendor giving you a usable copy of it are two different commitments, and only one is usually in the contract.
The question worth answering in writing is narrow: if we terminate, what exactly do we receive, in what format, within what window, and at what cost. A complete structured database, an export a new system can convert, and a pile of static documents are three very different outcomes. Ask which one, and ask before you need it rather than during the month you are leaving.
Accounts, Permissions and the Shared Login
Lesson 2 made the point that the audit trail attributes every entry to whoever was signed in. This is where that becomes an operational rule rather than an observation.
What one shared login destroys
A single shared front desk account, or a shared clinical login on an operatory workstation, quietly removes four things at once.
- Attribution. Every entry made under that account belongs to a person who does not exist, so the trail proves nothing about anyone.
- Protection for the innocent. When something is questioned, the team member who did nothing wrong has no way to show it. Individual logins protect staff more often than they catch them.
- Offboarding. You cannot disable a shared account without disrupting everyone, so it survives every departure, and the credentials leave with each person who knew them.
- Permissions. A shared account has to carry the rights of the most privileged person who uses it, which means everyone who touches it has those rights.
The usual defense is that individual logins are slower. That is true, and it is worth the seconds. If switching users is genuinely painful, that is a configuration conversation with your vendor about session handling, not a reason to give up the record's integrity.
Permissions as design
Permission settings are not a statement about whether you trust people. They are a statement about which jobs need which powers, and the useful test is what an ordinary mistake could cost. The rights worth deliberate thought are usually the ones that change history or move money: deleting entries, editing or backdating completed transactions, creating and changing adjustment types, changing fee schedules, altering other users' accounts, and running the exports that pull data out of the system. Decide those by role, write the decision down, and review it when roles change.
Offboarding
When someone leaves, the record still points at everything they did, and it should. What has to stop is their ability to add to it. That is a checklist, and it belongs next to the vendor register rather than in someone's memory, because the practice management system is only the first item on it.
Disable rather than delete the user account, so the history stays attributed. Then work down the vendor register: the texting platform, the forms tool, the payment system, the clearinghouse, the phone system, remote access, email, and any shared credential that person knew, which needs changing rather than disabling. Collect the physical items and remove access to anywhere backups live. Practices routinely do the first item and skip the rest, which is how former staff keep access to patient information for years without anyone intending it.
Moving House
Everything above is also the test you face when you change systems, the largest project a practice undertakes that is not construction. Our article on switching practice management software covers the project side and the test conversion in depth. What follows is the record side of the same move.
What converts, what degrades, what gets rebuilt
| Usually converts cleanly | Usually degrades | Usually rebuilt by hand |
|---|---|---|
| Demographics and contact details | Clinical notes, often flattened out of their structure | Fee schedules and coverage setups |
| Coverage and subscriber information | Detailed ledger history, often arriving as balances forward | Appointment types and schedule templates |
| Completed procedure history with dates | Periodontal charting, which is highly system specific | Adjustment types and financial categories |
| Current balances | Treatment plans, especially phasing and sequencing | Note templates and canned text |
| Future appointments | Historical appointment detail and status history | User accounts and permissions |
| Attached documents and signed forms | Recall rules and report definitions |
Read the third column carefully, because it is the one that surprises people. Configuration does not convert. Everything your practice decided over a decade about how work is categorized, priced, scheduled and described is re-entered by a human being, and the quality of the new system depends heavily on who does it and how much time they are given.
The middle column is where the record is at risk, and two entries there deserve particular attention: attached documents and images. These are the pieces with legal weight from Lesson 2 and the pieces living outside the core from Lesson 4, which is exactly why they fall through. Ask specifically whether document migration and image migration are included in what you are being quoted, or whether they are separate projects with separate vendors, because the answer is often the latter and it is often discovered late.
Read only access to the old system
The thing to plan hardest is what you keep. Once the new system is live, the old one holds the detail that did not convert: the original notes, the full ledger history, the status of things, the documents. You will need it, and the need will be unpredictable.
Settle three things in advance. How you will still read the old data: a read only license, a preserved installation, an archive plus a documented way to open it, or a full export. How long you keep it, remembering that retention obligations attach to the record itself rather than to whichever software holds it, and that they come from your state rather than any vendor. And who is responsible for it, because a preserved system with no owner stops working quietly and nobody notices until the day it is needed.
How Long It Really Takes
The vendor timeline describes the technical work. The practice timeline is longer and has a different shape, and knowing the shape prevents most of the panic.
Before go live there is data cleanup, worth doing because converting duplicates and dead plans just moves the mess. There is a test conversion and an audit of it by your own people, using real patient records rather than a demonstration. There is configuration, the third column of that table, which is bigger than anyone expects. And there is training, which works far better before it is needed than during a full schedule.
Go live itself is usually a weekend and a lighter first week. Then comes the part nobody plans for: several weeks in which the team is slower, configuration gaps surface daily, and every report is untrustworthy because the history is split across two systems. That period ends when somebody keeps a running list and schedules time to work through it. Practices get hurt by treating go live as the finish line, because that is when the workarounds get invented, and workarounds invented in week two are still there in year three.
Where This Course Leaves You
Five lessons, and they reduce to one idea. The software is five modules with seams between them, the record inside it is a legal document assembled from more places than anyone thinks, the ledger and the schedule are data structures that repay discipline, the integrations around the core are where the failures live, and all of it depends on a backup somebody has actually restored and a login that belongs to one named person.
None of that requires buying anything. It requires four documents: the record map from Lesson 2, the adjustment and appointment type definitions from Lesson 3, the bridge sheet and vendor register from Lesson 4, and the backup answers from this one. A practice that has those four is in better shape than most, whatever software is on the screen.
Try this in your own office
- Send the four backup questions today. What is in the set, how far back it goes, whether a copy is isolated, and when a restore was last tested. Keep the written reply.
- Schedule a real restore test. With whoever supports your systems, to somewhere that is not production. Time it from request to usable, and record the number.
- Confirm the image store is in the backup set. By location, matched against what Lesson 4 had you find. Do the same for scanned documents.
- Count your shared logins. Every account used by more than one person, in the core system and in every vendor platform. That count is your starting position.
- Write the offboarding checklist. Work down the vendor register and list every access that has to be removed. Test it against the last person who left.
- Get the exit terms in writing. Ask your core vendor what you receive if you terminate, in what format and at what cost. File the answer with the contract.
THE CHAIRSIDE TAKE
Do two things this month and you will have done more than most practices ever do. Schedule a restore test to somewhere that is not your live system and time it honestly, because until you have, you do not have a backup, you have an assumption with a green checkmark on it. Then eliminate your shared logins, starting with the front desk, because every entry made under a shared account is an entry the record cannot attribute to anyone, including the person who did nothing wrong. Both are free. Neither is urgent until the morning it is the only thing that matters, and by then the choice was made years earlier by whoever did not do them.
Lesson 5 of 5 in The Practice Software and the Patient Record
This guide is educational content and does not constitute legal, financial, tax, or clinical advice. Laws and regulations vary by state and change over time. Consult your own dental-specific attorney, CPA, and state dental board before acting.