Networking

Multi-Location Dental and Medical Practice Networks

Design connectivity for a dental or medical group around ePHI, imaging, practice software, voice, and outage tolerance. Standardize controls while qualifying every office on its own facts.

By InventiveHQ Team

A dental or medical group does not have one office network repeated at several addresses. It has a set of clinical endpoints with different imaging workloads, carrier options, cabling, inherited systems, and tolerance for disruption. A design that looks uniform on a diagram can behave very differently at the chairside or front desk.

The useful goal is a common operating model with site-specific access. Standardize how the group secures, monitors, and supports each office, while qualifying bandwidth and resilience from the applications and facilities at that address.

The current HIPAA Security Rule summary from HHS requires covered entities and business associates to use reasonable and appropriate safeguards for electronic protected health information, or ePHI. Its technical safeguards include access control, audit controls, integrity, authentication, and transmission security. The broader obligation is to protect the confidentiality, integrity, and availability of ePHI based on the organization's risk analysis.

That has direct network consequences. The practice needs to know where ePHI travels, which systems can reach it, how users and devices authenticate, how traffic is protected in transit, what gets logged, and how access survives or recovers from failures. Those decisions and the reasoning behind them need to be documented and revisited when the group adds a location, changes a vendor, or moves a server.

HIPAA does not prescribe a carrier product, private WAN, firewall brand, topology, or bandwidth tier. It does not say that offices must be joined by MPLS, or that an internet-based VPN is inherently noncompliant. HHS says ePHI may cross an open network when it is adequately protected. Encryption is an addressable implementation specification, which means the practice must evaluate it and document its treatment. “Addressable” does not mean “ignore it if inconvenient.”

Nor does buying a circuit marketed for healthcare make the network compliant. A dedicated circuit may improve predictability, but it does not supply identity controls, correct firewall rules, endpoint security, audit review, contingency procedures, or vendor governance. Conversely, a well-designed encrypted connection over business internet can be part of a compliant environment when it follows the documented risk-management decision.

Segmentation is useful even though HIPAA does not dictate a particular VLAN plan. Clinical workstations, imaging devices, phones, building systems, staff devices, and guest Wi-Fi do not need identical reachability. Limit each zone to its required destinations, especially when an older modality or embedded device cannot run current endpoint controls. Treat a vendor tunnel as a scoped exception with an owner and logs, not as a permanent doorway into the clinical LAN.

Imaging changes the bandwidth calculation

Headcount is a weak sizing method for an imaging practice. Dental radiographs, cone-beam studies, ultrasound, and other DICOM workflows can create large bursts that ordinary browsing and scheduling do not reveal. The important questions are where the images originate, where they are stored, who reads them, and how quickly they must arrive.

WorkflowTraffic patternNetwork implication
Modality to a local PACSMostly inside the office LANSwitching, cabling, storage, and local segmentation may matter more than WAN speed
Office to a cloud PACSSustained or bursty upstream trafficUpload capacity and congestion control become primary sizing inputs
Office to a PACS hosted at another practiceUpload at the sending site, download at the receiving siteBoth offices and the inter-site security path become dependencies
Central archive to a remote clinicianDownload to the reader, with possible retrieval burstsMeasure retrieval behavior and the effect of other site traffic
Backup or replication off siteOften scheduled upstream demandPrevent it from competing uncontrolled with clinical and voice traffic

Start with measurements from the firewall, PACS, and application owner. Record study sizes by modality, transfer frequency, concurrency, retransmissions, and observed completion time during a representative clinical load. Ask the vendor whether compression, caching, prefetching, and local buffering are supported and how they affect diagnostic workflow. Do not enable an optimization merely because it makes a speed test look better.

Symmetry matters when a site sends as much important data as it receives. A broadband plan may advertise ample download capacity while offering much less upstream capacity. That can be acceptable for a light satellite office, but it can be the wrong primary path for a location that uploads studies, hosts the practice server, replicates backups, or terminates remote desktop sessions. Compare the committed performance and service terms, not just the largest number in the offer.

Advertisement

Cloud software and the server in the closet create different risks

With cloud-hosted practice management or electronic health record software, each office reaches the vendor directly. The group no longer depends on a server room at a particular practice, but every office depends on its local internet, DNS, identity path, vendor availability, and supported browser or client. Local failover therefore protects clinical access instead of merely providing convenience.

Confirm what still lives locally. Imaging bridges, scanners, label printers, payment devices, directory services, and interface engines may rely on an on-site appliance even when the main application is called cloud based. Document what the office can do if either the internet or the vendor is unavailable, and make downtime procedures accessible without the failed system.

When software is hosted on a server at one practice, that site becomes a data center whether facilities intended it or not. Every other office depends on the host's circuit, upstream capacity, firewall, power, cooling, server, storage, backups, and remote-access design. Maintenance or an outage at the host has group-wide impact. The hub therefore needs stronger resilience and change control than a normal branch.

Before centralizing, have the software vendor validate the architecture. Some applications behave poorly across latency or packet loss, and some vendors support only specific remote-session or database arrangements. Never expose a database service directly between offices to avoid a slow client. Use a supported encrypted design, restrict source and destination access, and monitor the whole transaction path.

Front-desk voice needs predictable treatment

A front desk expects clean audio, immediate call setup, reliable transfers, working queues, and stable inbound routing while staff use the scheduling system. Those expectations are operational, not a promise that any circuit can deliver perfect calls.

Voice is sensitive to delay variation, packet loss, congestion, and brief path changes. Put managed phones on an appropriate voice segment, keep guest and imaging traffic from exhausting the uplink, and use quality-of-service controls where the practice controls the queue. Local QoS cannot repair congestion deep in a provider network, so carrier path quality and monitoring still matter.

Test calling during real office load. Include inbound and outbound calls, transfers, holds, queues, voicemail, remote users, and failover. A WAN change can alter NAT behavior or source addresses and cause registrations or inbound routing to fail. Confirm emergency calling location records for each office and for devices that can move. Expect an active call or application session to drop during some failovers even when new sessions recover quickly.

Redundancy for an office that cannot lose a business day

Redundancy begins with a business decision: which workflows must continue in degraded mode? Protect those first. A secondary connection does not need to carry guest Wi-Fi, bulk image replication, backups, and updates if schedules, records, phones, and essential clinical services can be preserved by restricting noncritical traffic.

The secondary path should avoid as many primary failure domains as practical. Different carrier logos are not enough if both services use the same street conduit, building entrance, riser, power source, or wholesale fiber. A wired primary paired with fixed wireless or cellular may improve physical diversity, but only after an on-site signal and capacity test. A diverse wired route may be stronger where the building can support it.

Include the firewall, switching, power, DNS, identity, and phone configuration in the failover plan. Use supported dual-WAN behavior, secure the backup to the same standard, and monitor data consumption or policy limitations. Test by removing the primary path, exercising the approved clinical workload, and restoring service. Record which sessions break, how staff recognize failover, who escalates, and when noncritical traffic is disabled.

Standardize controls, optimize the site

Acquisitions reward a clear baseline, but immediate uniformity can break an inherited workflow. Discover first: circuits and terms, demarcation points, subnets, wireless, servers, modalities, vendor tunnels, phone numbers, alarms, public IP dependencies, and undocumented equipment. Map those findings to a target design and a risk-ranked migration plan.

Standardize across the groupDecide from each site's facts
Security policy and segmentation intentAvailable carriers, access medium, and physical path
Firewall management, logging, and configuration backupPrimary and secondary circuit pairing
Identity, administrative access, and vendor-access processCabling, wireless placement, and telecom-room conditions
Network naming, documentation, and monitoringImaging volume, local cache, and host-site role
Voice configuration standards and escalation recordsLandlord access, construction, and demarc extension
Acceptance tests and change controlMigration sequence around clinical operations

Qualify every acquired address rather than extending the incumbent carrier by default. A provider that is strong at the parent practice may be off-net or dependent on construction at the next office. Submit several practice addresses in one request; checking several sites takes no longer than checking one at this stage, although engineering and installation remain site-specific.

Check every practice address against the design

Use the results when you check which carriers report service at several practice addresses to build a per-site shortlist, then require the carrier to confirm the exact suite, handoff, construction assumptions, and service terms. InventiveHQ sources quotes through carrier channel agreements; the selected carrier still installs and bills the service, and sourcing costs the buyer nothing because carriers fund the channel from the same budget as their own sales teams.

The network standard should tell the team what each practice must achieve; the address-level work determines how that outcome can actually be delivered.

Frequently Asked Questions

Does HIPAA require a private network between practice locations?

No. The HIPAA Security Rule requires regulated entities to protect electronic protected health information with reasonable and appropriate administrative, physical, and technical safeguards. It requires transmission security, but it does not prescribe MPLS, a private circuit, a particular carrier, or a specific topology. A practice can transmit ePHI over the internet when it assesses the risk, protects the traffic appropriately, controls access, and documents its decisions. The network design must support the practice's risk analysis rather than rely on a product being called HIPAA compliant.

Why can medical imaging make upload speed more important?

An office sending studies to a cloud PACS, a radiologist, or a central server is uploading large, bursty files. An access plan with strong download capacity but constrained upload can leave studies queued even when ordinary web applications feel normal. Measure actual study sizes, acquisition patterns, concurrent users, destination paths, and acceptable transfer time. Then size upstream capacity and test during a representative clinical period. The relevant requirement comes from the workflow, not from a generic bandwidth-per-employee formula.

Should a practice host its management software at one office?

Only after accounting for the dependencies that creates. Every remote office then relies on its own access, the host office's access and power, the inter-site tunnel, the server, and the host firewall. A failure at the host can affect the whole group. Cloud hosting removes that office as the hub, but makes each location's internet path more important. Confirm the software vendor's supported architecture, latency sensitivity, backup method, recovery plan, and imaging integrations before choosing either model.

What should a backup connection keep running at a clinic?

Define a degraded-mode list before buying the backup. It often includes access to schedules and charts, identity services, prescribing or clinical portals, payment processing, critical calling, and secure messaging. Imaging transfer, backups, guest Wi-Fi, and software updates may be restricted during failover. Size and secure the backup for that approved workload, verify that phones and VPNs recover, and test it by disconnecting the primary path. A backup circuit that has never carried a clinic session is only an assumption.

How much of the network should be standardized after an acquisition?

Standardize the controls that make sites supportable: identity, firewall policy, segmentation intent, wireless names, logging, monitoring, configuration backups, documentation, and change control. Adapt the physical design to each office's carriers, cabling, floor plan, imaging workflow, and landlord constraints. Start with discovery rather than immediately replacing equipment. The acquired practice may have an undocumented server, modality, phone route, or vendor tunnel whose removal would interrupt care.

business internethealthcare networkingdental practice networkmedical practice networkhipaa securitypacs bandwidthmulti-site networking