A single-site clinic can get away with a flat network. A 10-site physician group cannot. As a multi-site practice grows, network design becomes one of the highest-leverage decisions in the entire IT stack. Get it right and security, performance, and compliance all benefit. Get it wrong and every new site compounds problems at the previous sites.
This article covers the practical network segmentation model for a multi-site physician group, the traffic patterns that matter, and the mistakes we see most often in acquired or rapidly grown groups.
The Four-Network Baseline
At minimum, every clinic site should have four separate networks — either as VLANs on a shared switch or as physically separate infrastructure:
- Clinical workstations: EHR, imaging, lab results. Highest trust, tightest controls.
- Administrative workstations: billing, reception, scheduling, back office.
- Medical devices: imaging equipment, EKG machines, vital sign monitors, networked point-of-care devices. Restricted to required vendor traffic only.
- Guest WiFi: patient and visitor traffic. Completely isolated from internal networks.
Inter-VLAN traffic is controlled by firewall rules. Guest WiFi cannot reach any internal network. Medical devices cannot reach administrative workstations. Administrative cannot directly access the medical device network.
Why Medical Device Segmentation Matters More Every Year
Medical devices are now primary attack surface. The 2024 FDA cybersecurity guidance and the Premarket Cybersecurity guidance for medical device manufacturers reflect years of vulnerabilities in imaging, infusion, and point-of-care equipment. Many fielded devices run end-of-support operating systems — Windows 7, Windows XP Embedded, unpatched Linux — because the device manufacturer's FDA clearance is tied to the software stack and upgrades require re-clearance.
The only sustainable control is network segmentation. A compromised medical device in a segmented network cannot reach clinical or administrative workstations. Without segmentation, one compromised imaging console can reach the whole practice.
Segmentation rules should enforce:
- Device-to-vendor-cloud traffic is allowed only to specific IPs/domains
- Device-to-PACS or EHR traffic is allowed only on required ports
- Device-to-administrative traffic is blocked
- No device initiates outbound traffic except to approved destinations
Inter-Site Connectivity Patterns
Most multi-site groups have a hub-and-spoke model: a data center or cloud hub, with sites as spokes. Alternatives include full-mesh (every site connects to every other site) and cloud-first (every site is a spoke to a cloud SD-WAN hub).
The traffic patterns that matter:
- EHR access: if the EHR is centrally hosted, every clinical workstation reaches back to the hub. Latency to the EHR drives clinician experience. Under ~50ms RTT is smooth; above ~150ms is painful.
- Imaging: large DICOM studies move between sites. Bandwidth planning based on study sizes and cross-site read patterns.
- Authentication: if AD or identity provider is centralized, every login reaches the hub. Authentication outages at the hub mean no logins anywhere.
- Voice: intercom, clinical phone, and on-call routing often flow over the same network. QoS markings on voice traffic are worth the configuration time.
SD-WAN platforms (Fortinet, Meraki, Versa, Prisma SD-WAN) make the hub-and-spoke pattern manageable at 10+ sites. Each site gets a small appliance, central policy pushes down, failover between circuits is automatic.
Redundancy: Not Every Site Needs Enterprise-Grade
A 500-provider group with a hub data center needs enterprise redundancy at the hub. A 5-provider satellite clinic does not need the same at the satellite. Right-size redundancy to clinical risk:
- Sites that perform procedures (infusion, imaging, in-office surgery) need higher uptime than urgent-care-style walk-in clinics
- Sites with larger patient volume during an outage window (high same-day volume) need faster failover
- Sites with embedded specialty services (pharmacy, lab draw, vaccination clinic) have outside dependencies on uptime
A practical minimum for every clinical site: cellular failover for the WAN, UPS on the network core, and a documented paper-downtime procedure. See our healthcare IT resources for downtime procedure templates.
Identity Architecture
Multi-site groups commonly run into one of two identity-architecture problems:
- Fragmented identity: each site has its own local accounts or domain. Acquisitions leave a patchwork. Result: users have multiple credentials, offboarding is slow, audit is a nightmare.
- Single identity without MFA: one central AD or Entra ID, but MFA not enforced. One phish at one site compromises access across every site.
The target state: single centralized identity (Entra ID or hybrid AD), MFA enforced on every user, conditional access policies that restrict by location and device compliance, and just-in-time elevation for administrative tasks.
Guest WiFi: The Test Most Practices Fail
Guest WiFi should be:
- On a dedicated VLAN with no path to internal networks
- Behind a firewall rule explicitly dropping traffic to RFC 1918 addresses (no lateral movement to internal)
- Rate-limited so a patient streaming video does not affect clinical traffic
- Using a captive portal with a click-through terms of use (for liability)
- Isolated from IoT devices (smart TVs in waiting rooms go on the IoT network, not guest)
A common-but-wrong pattern: guest WiFi uses a different SSID but the same VLAN as administrative. Not segmentation, just optics. Test by connecting to guest WiFi and trying to reach an internal IP. If you can, segmentation has failed.
The Acquired-Practice Problem
Multi-site groups that grew by acquisition inherit IT estates of wildly varying quality. A 30-day post-close assessment should cover:
- What network exists at the acquired site, what equipment, what vendor contracts
- Who has admin access — including former IT staff who may still have credentials
- What BAAs exist with which vendors, and whether they can be novated to the acquirer
- Endpoint inventory and security posture
- EHR migration plan and clinical continuity during cutover
- Any pending compliance findings or outstanding risk analysis items
Integration into the group's standard network design should happen within 90–180 days, with a documented cutover plan that preserves clinical operations.
Monitoring and Logging Across Sites
Centralized logging is what makes multi-site security tractable. Every site's firewall, switches, endpoints, and EHR access logs should flow to a central SIEM. Anomaly detection becomes cross-site — a login from an unusual country, impossible travel between sites, access patterns that diverge from peer practices.
SIEM options scale from open-source (Wazuh, Elastic) to mid-market (Huntress, Arctic Wolf) to enterprise (Splunk, Sentinel). Match the tool to the team that will run it. A SIEM no one reviews is worse than no SIEM at all.
Documentation That Scales
Network documentation for a multi-site group must be current and centralized. Minimum:
- Network diagram per site, with VLANs and firewall zones labeled
- IP address plan (don't let each site pick its own scheme)
- Change log for network changes, tied to ticket numbers
- Inventory of network equipment with model, firmware, support contract status
For a multi-site network assessment or SD-WAN planning engagement, see our healthcare services or schedule a consultation. We design for practices that plan to double in site count, not just today's footprint.
About the Author
Team Techvera
Techvera Team
Articles written collaboratively by the Techvera team, combining expertise across cybersecurity, managed services, and digital transformation.
