Dental Office Network Requirements: Dentrix, Eaglesoft & Open Dental

A dental office network has to satisfy two sets of requirements at once: the server and hardware minimums published for Dentrix, Eaglesoft or Open Dental, and the design needed to carry imaging, phones, payment terminals, staff devices and guest Wi-Fi over the same cabling and switches.

All three vendors publish system requirements, and those documents are useful. They also describe one application at a time. Patterson's Eaglesoft documentation, for example, states that a Windows Server-based server must be wired rather than wireless — a requirement that rarely comes up until an unstable connection starts presenting as slow chart access or an intermittent disconnect rather than as an obvious network fault.

This guide separates three things that are often mixed together: the vendor's current minimum, a sensible planning baseline, and the network design needed when the rest of the practice is added. The planning guidance is not a vendor requirement or a claim about measured client deployments.

What you need to decide before anyone quotes hardware

Five answers shape almost every decision below. Establish them before anyone quotes equipment or labor.

Five scoping questions decide which sections apply to you: on-premises or cloud, single site or several, fewer than ten Eaglesoft workstations or ten-plus, 2D imaging only or CBCT, and existing certified cabling or a new buildout. If the practice is single-site, on-premises, under ten workstations and 2D-only, the server table and the operatory section cover most of what you need.

Dentrix, Eaglesoft and Open Dental server requirements compared

The vendor minimum gets the application supported; the planning baseline leaves room for imaging, backups, security tools and growth.

A technically faster server can still be unsupported because of its operating system, virtualization layer, chipset or peripheral drivers, which is why step 5 above is not a formality.

Sources: Dentrix System Requirements 2026, Patterson Eaglesoft and CAESY Hardware Requirements, Answer 5073, and Open Dental Computer Requirements. Patterson revises Answer 5073 several times a year.

RAID keeps a server running through some drive failures; it is not a backup. Deletion, ransomware, database corruption and a failed RAID controller can affect every disk in the array, so each platform still needs a separate backup with defined targets: an acceptable data-loss window (RPO) and recovery time (RTO), at least one offsite copy, one immutable or otherwise unalterable copy, a stated retention period, encryption at rest and in transit, and a restore that has actually been performed rather than merely scheduled. "Monitored backup" describes the alerting, not the recovery.

Version-specific notes that change the answer

What these sheets do not cover is operating-system lifecycle, and it constrains a 2026 purchase. General Windows 10 support ended October 14, 2025, Henry Schein One stops supporting Dentrix installations on it after June 30, 2026, and Windows Server 2016 extended support ends January 12, 2027. Specify Windows 11 workstations and a current supported server edition. The imaging vendors named in step 1 above — DEXIS, Sidexis, Romexis, Carestream and the CBCT manufacturers — publish separate matrices for the acquisition workstation and imaging server, and those are the ones that decide the imaging side of the build.

The wired-server rule and how a bad connection presents

Eaglesoft servers belong on wired Ethernet, and Dentrix specifies a 1Gbps network connection for both servers and workstations.

Patterson's hardware requirements document is precise on this point. Under Windows Server operating systems, it states the machine must be wired and cannot use a wireless connection. Its broader network section recommends wired Gigabit switches, Cat5e or better cabling and cabled connections wherever possible. Dentrix separately warns that wireless is used at the practice's risk, because X-ray machines and other equipment can interfere with it.

The same requirement applies to the server's physical home. It needs a UPS, cooling, labeled switch ports and a location where it will not be unplugged to free an outlet. Our server-room setup guide covers that layer in detail.

When the server is already wired, check the full path: server NIC, patch cable, switch port, horizontal cable and workstation link. A single damaged pair can make a nominally Gigabit system negotiate at 100 Mbps. Disabling inappropriate NIC power saving also matters; Dentrix specifically warns that it can produce disconnect errors on computers left inactive.

How much bandwidth dental imaging actually needs

Dental imaging creates short transfers that range from a few megabytes for 2D images to hundreds of megabytes or more for CBCT.

Planmeca's current Romexis system requirements estimate about 9 MB per 2D X-ray image and 50 MB to 1 GB per 3D X-ray image. A peer-reviewed comparison of six CBCT units reported uncompressed DICOM datasets from 27.9 MB to 382 MB — six specific devices and protocols rather than a distribution of what is installed in practices today, which is why a single universal “CBCT file size” is not a useful planning figure. Field of view, voxel size, bit depth, compression and export format all change the result.

The table below is transfer math, not a field benchmark. It divides file size by link rate and therefore represents a best-case floor before Ethernet/TCP overhead, disk writes, antivirus scanning, database work and image rendering.

Sources: Planmeca Romexis system requirements and the peer-reviewed study Variation in voxel value distribution and effect of time between exposures in six CBCT units.

“Imaging is bandwidth-heavy” is therefore an incomplete diagnosis. For a typical single-location practice, clean 1GbE to each operatory is enough. Before replacing it, check for a slow server disk, a nearly full image volume, a 100 Mbps negotiated link, real-time security scanning of the image directory or an acquisition PC tied to an old driver. A 2.5GbE or 10GbE server/core link is useful when multiple operatories read large studies simultaneously or the backup window collides with clinic hours; it does not justify replacing every chairside port.

Segmentation: what belongs on its own network

A dental practice should separate trust zones, but it should not create so many VLANs that clinical integrations become fragile.

If you need the fundamentals first, read what VLANs are and what to separate. The model below is the one we deploy in dental practices; treat it as a practical default subject to what the software vendors support, not as a standard:

The important nuance is vendor support. Eaglesoft recommends that computers share the same workgroup/domain and IP scheme. Imaging bridges and discovery tools can also assume that devices are on one local subnet. Do not separate the server, acquisition PC and operatory workstation for the sake of a tidier diagram. Build the firewall rules from documented application flows, test capture and retrieval, and keep unsupported legacy devices behind the narrowest rules the workflow permits.

That distinction matters: guest and personal-device separation is straightforward; clinical micro-segmentation is an integration project.

A voice VLAN is worth the same caution. Separating handsets makes traffic easier to identify, prioritize and troubleshoot, but the VLAN by itself does not produce call quality. Quality-of-service policy only changes anything where a link is actually congested — typically the WAN uplink during a large backup or cloud image sync, not a lightly loaded gigabit switch.

Payment terminals and PCI scope

We normally place payment terminals on their own network segment, but segmentation alone does not determine what PCI DSS requires of the practice.

What matters is the payment architecture. A validated, PCI SSC-listed point-to-point encryption (P2PE) solution can significantly reduce the PCI DSS requirements that apply to the practice, though it does not remove PCI DSS entirely. A terminal that merely supports encryption is not the same thing: the PCI Security Standards Council is explicit that an encrypting or PTS-approved device does not by itself reduce scope. Ask the processor or acquirer which validated solution the practice is using and which self-assessment questionnaire applies, then build the firewall rules to match that answer rather than the other way round. Note that a terminal integrated with the practice-management application is not fully isolated by segmentation: it needs a defined, tightly scoped path to that workstation or server, and that path has to be designed rather than discovered when payments stop working.

HIPAA: what the network can and cannot do

Network controls support HIPAA safeguards; they do not make a dental practice compliant.

Not every dental practice is automatically a HIPAA covered entity; that generally depends on whether the practice conducts covered electronic transactions. For a dental practice subject to HIPAA, the Security Rule requires administrative, physical and technical safeguards for ePHI. HHS identifies access control, audit controls, integrity, authentication and transmission security among the technical safeguards. A segmented network contributes to access control and risk reduction, while firewall and infrastructure logs can support investigation.

It cannot supply a risk analysis, workforce training, unique application accounts, vendor agreements, workstation-use policies, an incident-response process or a tested contingency plan. Those responsibilities exist beyond the switch configuration. HHS's Security Rule summary is a better baseline than any vendor promising a “HIPAA-compliant network.”

Also separate current law from proposals. HHS proposed substantial Security Rule changes in 2025, but a proposed rule is not the current rule. Plan for stronger cybersecurity expectations without presenting proposals as already mandatory.

Cloud platforms move the risk to the internet connection

If the practice runs Dentrix Ascend, Open Dental Cloud or cloud imaging, the internet circuit becomes a clinical dependency rather than a convenience.

The design changes accordingly. We normally specify a second path — a different carrier or an LTE/5G failover on the gateway — configured to fail over automatically rather than by manual reconfiguration during clinic hours. Whether that is worth the recurring cost depends on how much of the clinical day stops when the circuit does. Keep DNS resilient, because a resolver failure looks identical to an outage from the operatory. Confirm what the software does during a short interruption: some workflows queue and recover, others drop the session. And test the failover on a schedule, because an untested failover path is an assumption. Our dual-WAN and failover guidance covers the mechanics.

Sources: Dentrix Ascend system requirements and Open Dental Cloud requirements.

On-premises practices are not exempt. Remote backup, imaging cloud sync, e-claims and cloud phone systems all keep working against the same circuit.

Remote vendor access and who patches what

Many dental practices grant remote access to software and imaging vendors, and that access is usually the least governed part of the network.

Set it up deliberately: named accounts rather than one shared credential the whole support desk knows, multi-factor authentication, access granted for the duration of a case and then withdrawn, and connection logging that survives the ticket. Persistent always-on remote tools installed years ago by a vendor who no longer supports the practice are worth auditing specifically.

Patching ownership needs the same clarity, written down before go-live: who applies Windows and firmware updates, who runs endpoint protection and owns the vendor-approved exclusions, who schedules reboots outside clinical hours, and who is called when an update breaks an imaging driver. "The IT company" and "the software vendor" each assuming the other owns it is a common and avoidable gap.

The operatory: drops, PoE and physical reality

Four home-run data cables per operatory is our planning baseline for a new buildout, not a vendor requirement — even when only two are active on opening day.

Count the endpoint roles rather than assuming every dental device has an Ethernet jack:

1. Chairside workstation: the primary wired connection for charts and image viewing.
2. Imaging or device bridge: only when the modality uses Ethernet; many intraoral sensors connect by USB to the acquisition PC.
3. Room display, VoIP handset or future device: use depends on the practice workflow.
4. Spare: cheap during construction and expensive after cabinetry, plumbing and clinical equipment are in place.

A ceiling access point is normally shared by several rooms; it is not one AP per operatory. Its cable should return directly to the communications rack, and placement should follow a survey that accounts for lead-lined walls, dense cabinetry and corridor geometry. Our guide to Wi-Fi access-point density in partitioned offices explains why square footage alone is a poor AP count.

Power over Ethernet (PoE) lets the switch power APs and compatible phones over their data cables. Size the switch from the actual model list: add each device's maximum draw, account for boot peaks and leave expansion headroom. Do not count an intraoral USB sensor or ordinary monitor as a PoE endpoint.

Cable routing has to be coordinated before millwork closes. Keep data pathways clear of high-voltage conductors and away from plumbing, vacuum and compressed-air service paths. Terminate, label and certify every run. The business network wiring guide covers testing and the current $150-$350 per-drop planning range; the office network blueprint covers the equipment layer.

Troubleshooting order: what to check before buying bandwidth

Troubleshoot dental software from the physical path upward before blaming bandwidth or replacing the server.

Without a ticket dataset, it would be misleading to call this a frequency ranking. This is the diagnostic priority order we use because each step is fast to test and can affect every platform:

1. Bad cable or negotiated link speed. Symptom: one operatory is consistently slower. Check the switch for 100 Mbps negotiation, errors or flapping; replace patch leads and certify the permanent run.
2. Power saving or unstable Wi-Fi. Symptom: disconnects after idle periods or intermittent freezes. Wire the endpoint where the vendor expects it and disable inappropriate NIC sleep settings.
3. Server name, DNS or static-address problems. Symptom: the application cannot find its database after router, server or ISP work. Restore correct local DNS and reservations; do not hard-code around a broken design without documenting it.
4. Storage contention or low free space. Symptom: everyone slows down during image imports or backup. Check disk latency, free capacity, backup timing and real-time scanning exclusions approved by the vendor.
5. Imaging driver or USB-chain failure. Symptom: charts work but capture does not. Check the vendor-supported operating system, device driver, powered USB requirements and acquisition software before changing the network.
6. Undocumented switch or firewall changes. Symptom: a vendor integration stops after “security improvements.” Compare the change log and required flows, then restore only the access the application needs.
7. Backup that completed but cannot restore. Symptom: none until the server fails. Test a real recovery into an isolated environment and document the result. The small-business disaster-recovery guide explains recovery objectives in more detail.

The ordering is deliberate: prove the wire, link and storage behavior before buying more internet bandwidth.

Planning a practice network: new buildout versus retrofit

A new buildout should over-install pathways and cable; a retrofit should prioritize the failures that interrupt patient care.

New buildout

Finalize the operatory device schedule before the electrician and low-voltage contractor start. Put four data cables at each operatory, dedicated runs at imaging stations, ceiling drops for surveyed AP locations and enough rack capacity for a UPS and spare switch ports. Photograph open walls and label both ends before cabinetry arrives.

The larger planning sequence — requirements, site survey, design, staging, migration and acceptance — is covered in our medium-office network project plan.

Retrofit

Start with a cable and switch audit during a nonclinical window. Reuse certified Cat5e/Cat6 runs that negotiate cleanly at 1GbE; replacing every cable to chase a category label is often wasted money. Add home runs to the rooms that depend on Wi-Fi, isolate guest access, move the server onto protected power and schedule clinical cutovers after the last patient.

Regional note — South Florida. Older Miami medical-office buildings often have hard ceilings, crowded pathways and limited telecommunications space, and hurricane planning means the server, switches, firewall and internet handoff need protected power and a documented shutdown and recovery procedure. Neither changes the design principles above; both change the labor estimate. Our Miami office network planning guide covers the local conditions.

What this costs and who should do it

Dental network projects can cost more than ordinary office refreshes because operatory cabling and clinical-vendor coordination add labor, not because the practice needs exotic switches.

These are planning allowances, not quotes or measured project averages. They are organized around the scope components below; replace them with your own drop count, equipment list and local quotes when budgeting a project.

Acceptance checklist

Whoever does the work, do not sign it off without these. Every line is a pass or fail, not an opinion.

• Every active endpoint link negotiates at its rated speed, with no errors or flapping under load.
• Permanent links are certified and the results are handed over.
• Imaging capture and retrieval tested at each operatory, on the actual acquisition hardware.
• A restore performed from backup into an isolated environment, with the result documented.
• UPS runtime measured, not estimated, with a tested graceful shutdown.
• Guest network confirmed to have no route to clinical or management networks.
• Practice-management and imaging compatibility confirmed in writing, with the applicable vendor ticket or case number retained.
• Rollback procedure documented, with the pre-change configuration retained.

If you are in Miami-Dade or Broward, the useful first engagement is a dental network assessment: cable certification, server and imaging dependency map, VLAN and firewall review, backup-restore evidence, UPS runtime and a phased scope that fits clinical hours.

A well-cabled 1GbE practice that matches its vendors' supported platforms and can prove a restore will generally outperform a 2.5GbE practice built on untested cabling and assumptions.

Related Resources

• Medium Office Network Project Plan — The full sequence from requirements and site survey through migration and acceptance.
• Business Network Wiring Installation Guide — Cabling methods, testing requirements and per-drop cost planning.
• VLANs Explained for Small Businesses — The network-segmentation fundamentals this dental design builds on.
• IT Server Room Setup Guide — Power, cooling, rack layout and physical protection for the practice server.
• Dual-WAN Business Network Guide — Failover design for practices that depend on a cloud platform or cloud imaging.
• Miami Office Network Planning Guide — South Florida buildout constraints, resilience and local planning considerations.