Campus or hub-and-spoke: the healthcare connectivity call.

The structural fact about multi-location healthcare connectivity is that the network is not really connecting buildings, it is connecting every exam room to a medical record, and the record has an address. If that address is a central data center the group operates, the whole network has to funnel toward it. If that address is a vendor's cloud, the network can spread out and let each site find its own way to the internet. Everything else about the design, the circuit types, the redundancy, the segmentation, the per-site bandwidth, follows from that one fact. Operators who start from the site count instead of the record's address tend to buy the wrong shape and pay for it twice.

This is the fourth piece in the Healthcare series. The anchor set out the constraints that govern healthcare sourcing, piece two covered EHR integration, and piece three audited the Business Associate Agreement. This piece moves from the contract to the wire. The connectivity decision looks like a networking problem and gets handed to whoever manages the routers, but it is a sourcing decision with a clinical availability requirement and a regulatory floor underneath it, and the architecture is chosen once and lived with for years.

Where the EHR is hosted decides the architecture, not the number of sites.

The first question is not how many locations you run, it is where the record lives, because that determines which way the traffic has to flow. A centrally hosted EHR, the classic on-premise deployment where the database sits in a data center the group owns or leases, means every clinician at every site is reaching back to that one place all day. The network has to give them a controlled, low-latency, redundant path to the hub, and that is the definition of a hub-and-spoke design. A cloud-hosted or SaaS EHR inverts it. When the record lives in the vendor's cloud, the shortest path from a site is out the front door to the internet, and forcing that traffic to detour through a central hub only adds latency and cost. That favors a distributed model where sites break out locally and behave as peers.

Most mid-market groups are not purely one or the other, and the honest answer is usually a hybrid. The cloud applications get local breakout, anything still centrally hosted gets a protected path to the hub, and an SD-WAN overlay makes the mix look like one network to the people running it. What matters for sourcing is that the hosting model is the input and the architecture is the output. A vendor that quotes a design before asking where your EHR, your imaging, and your PACS actually run is selling you a template, not an architecture. The site count belongs in the cost model and the management-overhead conversation. It does not belong in the decision about which way the network points.

The availability mandate rules out the single circuit, and it is not optional.

A clinic that cannot reach the record when the line goes down is not merely inconvenienced, it is out of compliance with the posture the Security Rule expects. The HIPAA Security Rule requires a contingency plan under 45 CFR 164.308(a)(7), including procedures for responding to an emergency or other occurrence that damages systems containing electronic PHI, and availability is one of the three properties, alongside confidentiality and integrity, that the rule exists to protect. A location running on a single circuit with no failover has built a single point of failure into access to the medical record. When that circuit drops, the chart is unreachable, and no contingency plan on paper changes the fact that the architecture did not provide for continuity.

This is why redundancy is not the line item to cut when the quote runs high. The practical standard for a clinical site is two diverse paths, meaning not just two circuits but two that do not share the same fiber, the same provider, and the same failure. A primary fiber connection with a cellular or fixed-wireless backup is a common and defensible pattern, because the two paths fail independently. The failover has to be automatic and fast enough that a dropped primary does not become a dropped appointment. An operator evaluating connectivity should treat the availability requirement as a design constraint set before price, in the same way the integration constraint is set before price, rather than as an upgrade a vendor talks them into.

Bandwidth is a function of what the site does, not its square footage.

The right bandwidth for a location is set by the clinical work performed there, so a group should size each site to its modality rather than apply one number across the board. A primary-care or behavioral-health office running a cloud EHR, voice, and routine web traffic has a modest, predictable profile. An imaging-heavy site moving radiology studies, a location running high-definition telehealth, or a surgical facility pushing large files to a central archive has a materially larger and burstier profile, and sizing it like a small office guarantees the studies crawl and the clinicians route around the system. The variable that drives the number is the data the site generates and retrieves, not the number of rooms in it.

Two properties matter as much as raw capacity. The first is symmetry: healthcare sites often push as much as they pull, sending images and records upstream, so an asymmetric consumer-grade connection that looks large on the download can choke on the upload. The second is latency and jitter, which govern whether real-time work, a video visit or a live voice call, holds together. A design that gets the headline megabit number right but ignores symmetry and latency will still fail the clinical test. The buyer-side move is to build a per-site bandwidth profile keyed to modality, with headroom for growth, and to make the circuit type match the profile rather than the price tier.

FCC Rural Health Care funding changes the redundancy math for eligible sites.

For a group with rural locations, a federal subsidy can turn a second circuit from a line the finance team cuts into a line it approves. The FCC Rural Health Care Program, administered through the Universal Service Administrative Company, runs the Healthcare Connect Fund, which provides a 65 percent discount on eligible broadband connectivity expenses for eligible rural health care providers. The program operates under an annual cap, set at roughly 744 million dollars for funding year 2026, and it is claimed through a competitive-bidding process on a defined sequence of FCC forms rather than granted automatically. A consortium structure lets a group that mixes rural and non-rural sites participate together.

The procurement implication is specific. If a portion of your locations qualify as rural, the diverse second path that makes each of them compliant with the availability requirement may be substantially subsidized, which reshapes the whole redundancy budget. That does not mean the funding drives the architecture, and it should not: eligibility, competitive bidding, and documentation are real work, and the program's timing and caps introduce their own uncertainty. It means an operator who ignores the program may be paying full freight for redundancy the government would help fund, and an operator who assumes it is automatic may build a plan around money that is subject to a cap and a bidding process. Treat it as a sourcing lever to evaluate, with eyes open, not as a discount that arrives on its own.

Segmentation is an architecture decision to make now, not a retrofit.

The control that stops a compromise at one site or one device from becoming a group-wide event is network segmentation, and it is far cheaper to design in than to add later. HHS 405(d) Health Industry Cybersecurity Practices lists network segmentation as an enhanced practice, and it appears in the HHS Healthcare and Public Health Cybersecurity Performance Goals, released in January 2024 as ten essential and ten enhanced goals. The proposed HIPAA Security Rule update discussed in the previous piece would move segmentation from voluntary guidance toward a required implementation specification, so a network built without it today is building toward a remediation.

In a multi-location group the concrete version is straightforward to state and awkward to bolt on afterward. Guest and patient Wi-Fi is separated from clinical traffic. Medical devices and imaging systems, which are often unpatchable and long-lived, sit in isolated zones so a vulnerable device cannot be a pivot into the record. Lateral movement between sites is constrained, so a breach at one clinic does not traverse the WAN to the others. Each of those is a decision about how the network is carved up, and the carving is set when the WAN is designed. An operator sourcing connectivity should require the segmentation model in the design phase, because retrofitting it into a flat network already in production is disruptive, expensive, and frequently deferred until an incident forces it.

Choose the architecture against a fixed decision rubric.

The decision an operator faces is concrete: adopt a hub-and-spoke design that backhauls every site to a central point, a distributed design that breaks out locally, or the hybrid most groups actually need, and then set redundancy, bandwidth, and segmentation to match. The answer is driven by the inputs, not by a vendor's preferred product. The rubric below is the connectivity decision framework we run at the front of a healthcare engagement, before circuit pricing. Work it top to bottom, because each answer constrains the ones beneath it. Paste it into your RFP as the requirements the design has to satisfy.

What breaks is the architecture-to-workload fit, not the carrier.

The failure modes here are design mismatches, and none of them is the fault of a particular circuit provider. The first is backhauling cloud traffic through a central hub, a hub-and-spoke design imposed on a group that has moved to a cloud EHR, which adds latency and cost to reach an application the site could have touched directly. The second is the inverse, a flat distributed network with local breakout everywhere and no protected path to a centrally hosted record, so the sites that depend on the data center are the ones with the least reliable route to it. The third is the single-circuit clinic, where redundancy was value-engineered out and the availability requirement was met on paper but not in the architecture. The fourth is the flat network with no segmentation, which works fine until one compromised device has the run of every site.

Each of these is corrected by the same discipline rather than by switching vendors: start from where the record lives, set availability and segmentation as design constraints before price, and size each site to its clinical workload. The carrier and the equipment matter, but they are chosen to fit the architecture. They do not get to define it.

What this means for procurement.

What closes the connectivity decision is an architecture derived from where the record lives and what each site must do, specified before the circuit pricing rather than reverse-engineered from a carrier's quote. The prudent operator fixes the hosting model, the availability floor, the per-site bandwidth profile, and the segmentation design first, then sources circuits and equipment to satisfy that specification, and evaluates FCC Rural Health Care support as a lever on the redundancy budget where sites qualify. A cheaper design that points the network the wrong way, or that meets the availability requirement only on paper, is not cheaper. It is a clinical outage and a remediation with a discount attached.

The category mechanics of the wide-area network sit in our SD-WAN sourcing hub, the vertical view is in the Healthcare library, and the network-security framing is in our CISO briefing. The next piece in the series takes up the behavioral-health and telehealth backbone, where bandwidth, privacy, and session continuity meet. The constraint set does not change. The resolution of each constraint is where the work is.

How Cardinal handles a multi-site connectivity design.

When a buyer engages us on healthcare connectivity, we start by locating the EHR, imaging, and PACS, because the hosting model decides the architecture, and only then evaluate circuits. The Cardinal Method sets the availability floor and the segmentation model as design constraints before pricing, sizes each site to its clinical modality, and identifies where FCC Rural Health Care funding can subsidize the redundant path a compliant design requires. Carriers and equipment are sourced to fit the specification rather than allowed to define it, and a single overlay keeps failover and segmentation policy consistent across every site.

See the Cardinal Method →  ·  Healthcare coverage →  ·  SD-WAN sourcing →