Hospital Network Design for Imaging Traffic: VLANs, Bandwidth, and QoS

Imaging is the most demanding traffic a hospital network carries, and it behaves nothing like the workloads most enterprise networks are designed around.

A single CT study can be several gigabytes, transferred in one burst by a machine that does not care what else is happening. A radiologist opening priors can pull a similar volume interactively while expecting sub-second response. Meanwhile the interface engine is moving HL7 messages that are trivially small but where a few seconds of delay stalls order flow across the hospital.

Design for the average and the bursts will find you.

---

Segmentation: Performance and Security in One Model

Segmentation is usually introduced as a security control, but it solves a performance problem at the same time. The two requirements point at the same architecture.

A workable model for a hospital carrying imaging:

The modality segment deserves specific attention. Imaging devices run embedded operating systems that are frequently years behind on patching and cannot be updated independently of the vendor. Network segmentation is often the only compensating control available — which makes it a security requirement as well as a traffic-shaping one.

Rules between segments should be explicit and documented per flow: source, destination, port, protocol, purpose. "Modality VLAN can reach clinical server VLAN" is not a rule; it is an absence of one. Every DICOM association has a known source AE, destination AE, and port. Write them down.

---

Sizing Bandwidth From Real Volumes

Bandwidth sizing for imaging is straightforward arithmetic once you have the inputs — and the inputs come from the same modality breakdown used for storage sizing.

The method:

1. Take annual study count per modality and average study size per modality
2. Convert to a peak-hour volume using your measured peak-to-average ratio
3. Convert to sustained throughput for that hour
4. Then apply a burst factor, because studies do not arrive smoothly

That last step is where most calculations under-deliver. A modality that sends a 4 GB study on completion sends it as fast as the link allows. The relevant question is not "can the link carry the hourly average" but "what happens when three scanners finish simultaneously".

Design guidance that holds up:

• The modality-to-PACS path should tolerate several simultaneous large study transfers without affecting interactive reads
• The PACS-to-diagnostic-workstation path should be sized for concurrent diagnostic sessions at peak, and treated as latency-sensitive rather than throughput-sensitive
• Replication and backup should have either dedicated capacity or a QoS class that yields to clinical traffic
• Inter-site links are usually the constraint. Measure actual utilisation over a full week before assuming there is headroom

---

QoS: What to Prioritise, and What That Means

QoS on a hospital network is often configured once, for voice, and never revisited for imaging. Worth revisiting.

A practical priority ordering:

1. Interface traffic (HL7/MLLP) — tiny bandwidth, high sensitivity. Prioritising it costs almost nothing and prevents order-flow delays.
2. Interactive image retrieval — the diagnostic read path. This is what clinicians judge the system by.
3. Modality-to-PACS sends — important but tolerant of a few seconds' variance.
4. Replication and backup — should be explicitly de-prioritised so it consumes only what is spare.

The most valuable single QoS decision in most hospitals is the last one. Bulk replication that opportunistically fills the link is the most common cause of "the PACS gets slow around 10 p.m." — and of the same complaint at 10 a.m. once a replication job overruns its window.

---

MTU, TCP Windows, and Latency

Three settings account for a large share of slow-transfer complaints where the network is not saturated.

MTU and jumbo frames. Jumbo frames reduce per-packet overhead on large transfers and can meaningfully improve DICOM throughput. The requirement is consistency: every device in the path must agree. A mismatch produces fragmentation or black-hole behaviour that presents as intermittent failures on large studies only — which is a genuinely painful thing to diagnose. If you enable jumbo frames, verify the full path, including virtual switches.

TCP window size and bandwidth-delay product. On high-latency links — inter-site, teleradiology, cloud — throughput is capped by window size divided by round-trip time, regardless of how much bandwidth you bought. A site that upgrades a WAN link and sees no improvement in transfer speed is usually window-limited, not bandwidth-limited. This is the single most common reason a bandwidth upgrade delivers nothing.

Latency itself. DICOM associations involve negotiation round-trips before data flows. On a high-latency path, per-association overhead becomes significant, and transfers made up of many small associations suffer disproportionately. Where possible, prefer configurations that reuse associations for bulk transfer.

---

Distinguishing Network Faults From PACS Faults

Most "the PACS is slow" tickets arrive without evidence, and the fastest route to resolution is deciding which layer to investigate before engaging a vendor.

Indicators pointing at the network:

• Slowness correlates with specific locations or segments rather than specific users
• Large transfers fail while small ones succeed (classic MTU signature)
• Throughput is flat regardless of load (window or shaping limit)
• Interface errors, discards, or CRC counters incrementing on relevant ports
• Problems appear or vanish on a schedule matching backup or replication windows

Indicators pointing at the application or storage:

• Slowness affects all users equally, everywhere
• Specific study types or ages are slow while others are fast (a tiering or prefetch signature)
• Server-side storage latency or CPU ready time is elevated at the same moments
• Database wait statistics spike in step with the complaints

The efficient first step is almost always a packet capture at the point of complaint plus concurrent server-side metrics. Ten minutes of evidence prevents a week of vendor ping-pong.

---

Design Review Checklist

• Modality devices are on a segment isolated from general hospital traffic
• Inter-segment rules are documented per flow, with AE titles and ports
• Bandwidth sized from measured study volumes and burst behaviour, not averages
• Replication and backup cannot contend with clinical traffic
• QoS policy explicitly covers HL7 and interactive image retrieval
• MTU consistent end-to-end wherever jumbo frames are enabled
• TCP window sizing checked against round-trip time on all WAN paths
• Interface error and discard counters monitored on clinical-path ports
• Network diagram current, versioned, and matching reality

---

Related Reading

• Healthcare IT Network Architecture Documentation — how to document the design
• Healthcare IT Server & VM Sizing — the compute side
• Medical Device Network Security — segmentation as a security control
• Healthcare IT Diagram Builder — free browser-based tool for drawing these segments

Need a network or data-flow model built from your actual device inventory? Send us the details.