The myth of the slow network
Ask any radiologist why studies load slowly and the answer is almost always "the network." It's a convenient villain — invisible, shared, someone else's department. But when we instrument a viewer end to end, the network rarely accounts for the wait a clinician actually feels. The real cost is in how the viewer asks for data and what it does with the data once it arrives.
A viewer that requests an entire series before painting a single pixel will feel slow on a fibre backbone and a home DSL line alike. The fix isn't more bandwidth — it's asking for less, sooner, and in the right order.
Stream the first slice, not the whole series
The number that matters to a radiologist is time-to-first-image: how long from clicking a study to seeing something diagnostic. We optimise for that single metric relentlessly. The first slice a reader needs — usually the middle of the stack — is fetched and decoded first, painted in well under a second, while the rest of the volume streams in the background.
Progressive loading changes the psychology of reading. Instead of staring at a spinner, the clinician is already scrolling, windowing and measuring while the tail of the series arrives. By the time they reach the edges of the stack, the data is there.
Decode where it's cheapest
Medical images are large because they're precise — 16-bit greyscale, thousands of slices, lossless compression. Decompressing that on a distant server and shipping pixels back is the slowest possible path. Modern browsers and GPUs can decode and render faster than a single server round-trip, so we push windowing, multiplanar reconstruction and volume rendering to the client.
Done well, the workstation stops being a thin terminal and becomes what it always was: a capable machine sitting idle. Windowing becomes instant because it's a shader, not a request. Scrolling becomes smooth because the slices are already in GPU memory.
Cache like the reading actually happens
Radiologists don't read randomly. They open priors alongside the current study, scroll the same ranges, compare the same series. A viewer that understands those patterns can prefetch intelligently — pulling the comparison study while the reader settles into the current one, warming the ranges they're most likely to visit next.
The result is a viewer that feels like it's anticipating the reader, because it is.
Measure like a clinician, not a developer
The most common performance mistake is benchmarking on a developer's new laptop over a wired connection. That machine is not the reading station. We measure time-to-first-image on the actual hardware clinics run — often five-year-old workstations — over the actual network, at the times of day when it's busiest.
Optimising for the slowest real machine in the building is the only benchmark that changes a clinician's day.
What good looks like
- Time-to-first-image under one second on existing reading stations
- Interactive windowing and scroll with no server round-trip
- Priors prefetched before the reader asks for them
- Full-fidelity, lossless pixels — speed never comes from throwing away data
Need this done right? Epica builds medical software end to end. Talk to us →