A small dental clinic can run on a four-part IT design: one practice-management server, one imaging server (a DICOM archive), a backup target with an offline copy, and a separate network segment for imaging units. Everything else is a client. This page is a reference design, not a product recommendation, and it is not verified on a clinic site: it joins the vendor and project documentation we checked into one layout. Facts were read from the official pages on 5 November 2026. Status: Not tested yet — we have not built this on a clinic network, so have a practising IT specialist review it before you buy hardware.
Nothing here is legal or compliance advice, and the dental software you run may dictate parts of the layout. Where your imaging or practice vendor says otherwise, follow the vendor.
The design at a glance
| Role | What runs there | Example software | Source of the facts |
|---|---|---|---|
| Practice server | Database and shared files of the practice-management software | Open Dental (shareware, conditionally free) | Open Dental computer requirements page |
| Imaging server | DICOM archive that CBCT and X-ray units send to | Orthanc (free, GPLv3+) | Orthanc Book, security and backup pages |
| Viewing stations | Browser or desktop DICOM viewers at the chairs and in the office | OHIF Viewer (free, MIT), Weasis (free, open source) | Our program pages |
| Backup target | Local copy on a separate device plus an encrypted off-site, offline copy | Any tool that fits the two server roles | Orthanc Book; our backup guides |
| Network | Office, imaging and guest segments; no inbound remote desktop | Firewall or router with VLAN support | CISA and HHS guidance in our ransomware checklist |
Small offices can combine roles. Open Dental says the database server may share a computer with the office server in a small office, though it recommends a dedicated server to protect data. The same logic applies to imaging: one machine can host both if you accept that a failure or a ransomware hit then takes out both.
Practice server
Open Dental stores its database in MySQL or MariaDB and keeps the images folder (A to Z) on the server. Its requirements page says a typical server install needs 1–2 GB plus the database size plus the A to Z folder, recommends SSD or NVMe drives (not required), and supports Windows Server 2016, 2019, 2022 and 2025, with Linux or macOS as an alternative host. Workstations are listed at 4–8 GB of RAM, 8 GB optimal, on Windows 11; Windows 10 support was suspended on 14 October 2025. The page says a UPS is optional but recommended because it can prevent data loss on the machine running the database. It also allows a Windows virtual machine, with a warning that other services on the same physical host may slow the database.
If you use a different practice system, ask its vendor for the same list in writing. Licence note: Open Dental is shareware (conditionally free) on our site; check its licence page before live use. Backup details are in our Open Dental backup guide.
Imaging server
A DICOM archive gives all imaging units one place to send studies and every viewer one place to find them. Orthanc is the lightest free option for a small clinic: it runs as a Windows service, on Linux or in Docker, and uses ports 8042 (web and REST) and 4242 (DICOM) by default, as described in our Orthanc setup guide. The Orthanc security page states its starting assumption: the web server is restricted to localhost by default. Once you allow remote access, authentication has to be on and users registered; HTTPS is recommended even on an intranet; and the DICOM side should not be exposed to the internet.
The same page explains how to restrict DICOM senders. By default Orthanc accepts C-ECHO and C-STORE from unknown devices. To tighten it, define your imaging units as known modalities, turn off the “always allow” settings and check the sender’s host. In practice that means every unit has a fixed IP address and a recorded AE title, which is why the design below puts them in their own segment.
Not every imaging system exports clean DICOM, and some keep studies in their own database. Check this with your imaging vendor before you plan around a vendor-neutral archive. Vendor hardware needs differ widely — see CBCT computer requirements by vendor. A heavier archive such as dcm4chee exists, but it runs with a separate database and directory service, which is more than one-chair practices usually want to maintain.
Viewing stations
Keep the viewers thin. OHIF is a browser application that talks to a DICOMweb archive, so chairside PCs need only a current browser. Weasis is a desktop viewer for Windows, macOS and Linux that connects to a PACS. The Weasis project states that its open-source build is not a certified medical device, so treat it as a review tool, not a replacement for your imaging vendor’s diagnostic software. For other options see the hub on free dental imaging software.
Backup target
Back up both servers to a device that is not permanently writable from the workstations, and keep one encrypted copy off-site and offline. For Orthanc with the default SQLite storage, the Orthanc Book names three things to copy — the configuration file, the DICOM files and the index files — and says to stop Orthanc during the copy. For databases such as PostgreSQL, hot backups are possible with the database’s own tools. A second always-on server is replication, not backup. The full procedure, including the restore test, is in the DICOM backup plan.
Network layout
The design uses three segments: office workstations and the practice server; imaging units and the imaging server; guest Wi-Fi with no access to either. Imaging units and the capture PCs attached to them are often stuck on older Windows versions, so treat them as untrusted: no email, no web browsing, only the traffic that must reach the archive. No remote desktop should be reachable from the internet; a support vendor gets a named account with multi-factor authentication through a VPN. The reasoning and sources are in our ransomware checklist for dental clinics. CISA’s own guide refused our automated check on the day of writing, so we rely on the wording we recorded from it on 29 October.
Who this suits, and who it does not
| Situation | Fit |
|---|---|
| One to five chairs, a clinic-owned practice system, imaging units that can send DICOM | Good starting point |
| Imaging stored only in a vendor’s closed database | Partial: keep the vendor server, apply the backup and network parts only |
| Cloud-based practice software, no local server | Not designed for this; only the network and backup parts apply |
| Several sites or high imaging volume | No: needs sizing by a specialist |
Limitations
- Not tested yet: we have not built or run this layout on a clinic network. It is a reference design.
- We give no sizing for disks or servers; sizes depend on your own study volumes and your vendors’ published requirements.
- HIPAA, UK GDPR and other legal duties depend on jurisdiction. NIST SP 800-66 Rev. 2 (February 2024) is a general implementation guide for the HIPAA Security Rule, not a checklist for this design.
- Vendor pages change without notice; re-check them before purchase.
FAQ
Does a dental office need a server?
Not always. Open Dental recommends a dedicated server to protect data, but also allows the database server to share a computer with the office server in a small office. Cloud-based systems need none.
What is a dental clinic server used for?
Usually two things: the practice-management database and shared files, and an image archive for CBCT and X-ray studies. They can run on one machine or two.
Do I need a UPS for the practice server?
Open Dental lists a UPS as optional but recommended, because it can prevent loss of data on the machine running its database.
Can I run Orthanc and the practice database on the same machine?
Technically yes, and small offices do share roles. The cost is that one failure or one attack affects both, and the backup jobs must handle two different systems.
Should imaging units sit on the office network?
Better in their own segment, with fixed addresses and only the connections they need. This follows the segmentation advice in our ransomware checklist.
Last updated: 5 November 2026 · DentIIT editorial team. Licence, version and platform details are checked against each developer's official documentation; none of the tools listed here should be treated as a certified medical device unless its vendor says so.
