At 6:50 this morning I got a text from a radiologist. A PACS application was freezing. One patient, specifically, was consistently crashing it.
The PACS application in question isn’t one my team is directly responsible for. But once my phone buzzes before 7 AM, it’s my problem in the same way any 6:50 AM text from a radiologist is my problem — something is broken, someone is trying to read studies, and the day is just beginning.
A few minutes later I learned the rest. The patient had 90 exams in the record. Ninety. The vendor had already been notified.
I’m writing this down because apparently it needs to be said out loud. If you build a PACS or an EMR, your software should not fall over on a patient with a deep exam history. And 90 is not a deep exam history. In oncology and across any tertiary imaging center with a complex chronic patient population, 90 is not that unusual.
What “a lot” of priors actually looks like
I have routinely seen patients with more than 100 prior imaging studies. Oncology patients accumulate years of staging CTs and PET scans. Patients on pulmonary nodule follow-up return every three to six months. A single ICU admission can add 15 to 25 chest X-rays. Add screening mammograms, trauma films, follow-up MRIs, and surveillance imaging for chronic disease, and the count climbs faster than anyone naively expects.
Ninety exams on one patient is not an edge case. It’s a routine chart for any hospital inpatient.
If you’re a vendor in this space, please stop testing against 10 or 20 priors and calling the job done. Test against 1,000. If your software handles 1,000 priors gracefully, then 90 will never put a radiologist in the position of texting their IT director before the first coffee.
The sizes involved
Storage and I/O are part of why this gets hard. A modern imaging study is not a handful of pictures. Approximate 2025/2026 sizes per study:
| Modality | Typical size per study |
|---|---|
| Chest X-ray (DR) | 10–30 MB |
| Ultrasound | 50 MB – 1 GB with cine |
| CT, single region | 200 MB – 1 GB |
| MRI, multi-sequence | 300 MB – 1.5 GB |
| Digital breast tomosynthesis | 2–20 GB, compression dependent |
| PET/CT | 500 MB – 2 GB |
A patient with 90 mixed priors is plausibly sitting on 100 GB or more of imaging, more if the mix is weighted toward DBT or high-resolution cross-sectional studies. A patient with 1,000 priors is well into the terabytes. The failure mode in the morning text message, though, isn’t “we ran out of disk.” It’s the index lookup, the DICOM metadata parse, the viewer trying to render dozens of thumbnails at once, the worklist query written without a LIMIT clause, the hanging protocol engine trying to evaluate every available prior. Each of those is a software design decision, usually made years ago against a test dataset that looked nothing like production.
Hanging protocols need a count, not just a window
Most PACS load priors for comparison through hanging protocols. A hanging protocol knows the body part, the modality, the orientation, and — crucially — a time window. “Prior chest CTs from the last three years” is a typical rule.
To be fair, hanging protocols are usually configured by the customer, not the vendor — the health system or imaging center tunes the template for its radiologists. So the first-order fix is on the customer side: pair the time window with a max-exam-count constraint. “Up to the N most recent relevant priors within the last M years” handles both the long-tail patient and the short-burst patient. A time window alone fails when a patient gets an unusual amount of imaging in a short period — an oncology patient on an every-8-week staging protocol crosses a dozen priors in two years, and an ICU patient can add 20 chest X-rays in a single admission.
But vendors aren’t off the hook. Even if the customer misconfigures the hanging protocol — or never gets around to tuning it — the software itself should have a backstop that prevents the viewer from loading an unbounded number of priors into active memory. That guardrail belongs on the vendor’s side of the fence.
What I’m asking vendors to do
This is not a hard ask. Build a synthetic patient record with 1,000 exams. Load them into your QA environment. Open the chart. Launch the viewer. Apply a hanging protocol. Watch what breaks.
Whatever breaks first is exactly what your heaviest-utilization customers are already hitting in production. Except they’re hitting it at 6:50 on a Monday, on a radiologist’s workstation, while someone is waiting for a read — and their IT director is getting the text about it.
Your software doesn’t have to be elegant at 1,000 priors. It just has to not freeze. If it can clear that bar, 90 will be a non-event, which is what 90 should have been all along.