Your practice management system is the one piece of software that stops everything when it fails. Reception cannot see the day. Clinicians cannot open a chart. Imaging will not attach. Within ten minutes, patients are waiting.
Most IT providers are competent with printers, Wi-Fi and Microsoft 365. Far fewer have opened Dental4Windows. That gap does not show up on a quiet Tuesday. It shows up mid-clinic, when something breaks and the person on the phone is guessing.
What Dental4Windows actually is
Dental4Windows — D4W — is made by Centaur Software, now part of Henry Schein One. It is the most widely used practice management system in Australian dentistry.
The important part for IT: it is a database application. Patient records, appointments, clinical notes and treatment plans live in a database on a server, and every workstation talks to that database continuously. Imaging usually lives beside it, in a separate file store that the database points to.
That architecture is why generic IT habits cause problems. A database in use behaves nothing like a folder of documents.
Five things generalists routinely get wrong
1. Backing up the database while it is running
A file-level backup that copies the database while D4W is open produces a file that looks fine and restores as a corrupted database. The backup job reports success every night. Nobody finds out until the day it is needed.
A correct backup either uses the database engine to produce a consistent copy, or takes an application-aware snapshot. The distinction is not academic. It decides whether you have a backup or a file.
2. Letting antivirus scan the database in real time
Real-time scanning of the D4W data directories makes the whole system crawl, and can lock files mid-write. Practices often describe this as "the software has got slower this year". It is usually a security product doing exactly what it was configured to do.
The fix is scoped exclusions for the database and imaging paths — not turning protection off. A provider who does not know which paths to exclude should not be the one configuring it.
3. Sizing the server for office work
A server specified for file sharing and email will struggle with a database serving six chairs plus imaging. The symptom is slowness that gets worse as the day fills, then clears overnight — which makes it easy to dismiss.
Disk performance matters more than raw processor speed here. Spinning disks under a busy practice database are a bottleneck no amount of memory will hide.
4. Treating imaging as ordinary file storage
OPG and intraoral images are large, and they are requested at the moment a clinician is with a patient. If imaging sits on a slow share, or crosses a saturated network link, the delay lands in chair time.
Imaging also has to stay linked to the right patient record. Moving image storage without understanding how D4W references it is one of the more painful ways to break a practice.
5. Never testing a restore
This is the one that matters most. A backup nobody has restored is a theory. The only evidence that your patient data is recoverable is a restore that someone has actually performed.
What competent D4W support looks like
A provider who understands the system will be able to tell you, without looking it up:
- Where the database lives, and how it is backed up consistently
- Which paths are excluded from real-time scanning, and why
- How imaging is stored and how D4W references it
- What the restore process is, and when it was last tested
- What happens to the practice if the server fails at 9am on a Monday
None of that requires the provider to be a dentist. It requires them to have supported dental practices before.
The same applies to EXACT and the others
D4W is the most common, not the only one. EXACT, also from Henry Schein One, is widely used and brings its own considerations — particularly around imaging integration and multi-site access. Cloud systems such as Praktika and Core Practice shift some of the burden to the vendor, but introduce a hard dependency on your internet connection that most practices have not planned for.
The principle does not change. Your IT provider should know the system your practice actually runs on. We cover this across dental IT support and, for practices running other clinical systems, medical IT support.
Why this is worth your attention now
Patient records are health information under the Privacy Act 1988. That raises the stakes on backups, access control and security well beyond ordinary business data — we cover the detail in what the Privacy Act actually requires.
It also matters because attackers have started targeting practices directly. If you have not read our security advisory on the phishing attack moving through Victorian practices, it is worth ten minutes.
The Australian Signals Directorate publishes practical baseline guidance at cyber.gov.au, and the Australian Dental Association maintains guidance for practices on records and privacy obligations.
Common questions
- Does my IT provider need to be a Dental4Windows specialist?
- They need to have supported practices running it. The specific knowledge that matters is how the database is backed up, which paths antivirus should skip, how imaging is stored, and what a restore involves. A provider who has never seen D4W will learn these on your practice, during an incident.
- Our backups run every night and report success. Is that enough?
- No. A file-level backup of a database that is open can complete successfully and still be unusable. The only proof is a restore that someone has performed and opened.
- Why has our practice management software got slower over time?
- Common causes are real-time antivirus scanning the database directories, disk performance that was marginal when the practice was smaller, and a database that has grown without maintenance. All three are fixable and none require replacing the software.
- Can Dental4Windows be moved to the cloud?
- Practices commonly host it on a server they access remotely, which is not the same as a cloud-native system. It can work well, but it moves your dependency onto the internet connection and the remote access setup. Both need to be planned rather than assumed.
- How long do we have to keep patient records?
- Retention is set by state health records legislation rather than by your software. In Victoria the general position for adults is seven years from the last entry, and for children until they turn 25. Confirm your own obligations with your adviser, then make sure the retention your IT setup actually delivers matches them.
- What should we do first if we are not confident in our current setup?
- Test a restore. Everything else — performance, security, hardware — can be improved over time. An untested backup is the only one of these problems that can end a practice.
Not sure where your practice stands?
We will review your setup and tell you what we find. Twenty minutes, no obligation, no disruption to clinic hours.