Storage sizing answers how much. Storage tiering answers where it lives, and that is the decision users actually feel.
A hospital can have ample total capacity and still have radiologists complaining that opening a prior study takes twelve seconds. That is not a capacity problem. It is a tiering problem: the study they want is on a tier designed for cheap retention, not for interactive reads.
The Four Tiers
Vendors name these differently, but the architecture is consistent.
| Tier | Typical media | Latency target | What belongs here |
|---|---|---|---|
| Hot | NVMe / high-end flash | Under 5 ms | Clinical databases, interface engine journals, in-flight studies |
| Warm | Flash / hybrid arrays | Under 10 ms | Online image cache — the studies users open interactively |
| Cold | High-capacity disk, object storage | Tens of ms | Older studies, retrieved on demand |
| Archive | Object storage, tape, cloud archive classes | Seconds to minutes | Long-tail retention, legal hold, disaster copies |
The important boundary is between warm and cold, because that is the line where a study stops being instantly available and starts being retrieved. Everything about perceived system speed comes down to how often a user crosses it.
The Cache Window Is the Real Design Decision
Ask a PACS administrator how big their archive is and they will know. Ask how many months of studies sit in the online cache and you often get an estimate. That second number is the one that determines whether the system feels fast.
The logic is simple. A radiologist reading a current study almost always wants the prior. If the prior is inside the cache window, it opens immediately. If it fell off the cache last month, the read stalls while it comes back from cold storage.
Set the cache window from comparison behaviour, not from a round number. Query your own data:
- For each modality, what is the median interval between a study and the prior the radiologist actually opened?
- What proportion of retrieved priors are older than your current cache window?
That second figure is your miss rate, and it maps directly onto user complaints. A general hospital typically needs 12–24 months to keep the miss rate low. Specialties with long clinical intervals — oncology surveillance, paediatric growth studies, screening mammography programmes with multi-year recall — need substantially longer, and it is usually cheaper to extend the window for those modalities specifically than to extend it for everything.
Modality-specific cache policy is underused and highly effective. Mammography priors are needed years later and are relatively small. Thin-slice CT is enormous and rarely opened after a few months. Treating those two the same is a waste in one direction and a service failure in the other.
Prefetch: The Other Half of the Answer
Tiering answers where data rests. Prefetch answers whether the user waits for it.
A well-configured prefetch rule watches the scheduled worklist and pulls priors from cold storage to cache before the radiologist opens the study. Done properly, users never experience cold-tier latency even when the study genuinely lives there.
Prefetch configuration mistakes worth checking:
- Triggering too late. Prefetching on study-open defeats the purpose. Trigger on scheduling or on arrival, so retrieval overlaps the wait the user is already having.
- Prefetching too much. Pulling every prior for every scheduled patient can saturate the retrieval path and evict useful cache entries. Bound it by relevance — same body part, same modality family, most recent n priors.
- No visibility. If prefetch silently fails, nobody notices until users complain. Monitor prefetch success rate and retrieval time as first-class metrics.
Object Storage and Immutability
Most modern archive tiers are object-based rather than file-based, and the difference matters operationally.
What object storage gives you: flat namespace with no directory-depth limits, metadata alongside the object, built-in replication and erasure coding, and cost that scales predictably.
What it costs you: higher per-request latency than block storage, and an access pattern your applications must actually support. Verify your PACS or VNA speaks the object API natively rather than through a gateway that becomes a bottleneck and a single point of failure.
Immutability (WORM) is worth understanding precisely. Object-lock or WORM policies prevent an object being modified or deleted before a retention date expires — including by an administrator, and including by ransomware operating with stolen credentials. That last point is the reason it has moved from a compliance checkbox to a core resilience control.
What immutability does not do:
- It does not prevent new encrypted copies being written alongside your data
- It does not protect systems that were never in scope of the policy
- It does not help if the retention period is shorter than your detection time
Set retention on the archive tier to exceed your realistic worst-case time-to-detection, not your best-case.
Five Tiering Mistakes
1. One pool for everything. Buying a single large array and putting database, cache, and archive on it means the database inherits archive-grade performance characteristics under load. Separate tiers, separate QoS.
2. Sizing the cache from capacity rather than behaviour. "10% of the archive" is not a policy. Cache size should come from the retrieval window you need, derived from comparison-study behaviour.
3. Migration jobs running during clinical hours. Tier migration is a bulk I/O operation. Scheduled against the reading day, it competes with exactly the traffic you are trying to protect.
4. No monitoring on the cold-tier retrieval path. When retrieval degrades, the symptom presents as "PACS is slow" — a complaint that gets routed to the PACS team and investigated everywhere except the storage layer. Instrument retrieval time explicitly.
5. Treating the archive copy as a backup. A tiered archive is part of the primary data path. Deletion, corruption, or a bad tag-morphing rule propagates to it. Archive tiering and backup are different controls solving different problems.
A Design Checklist
Before signing off a tiering design, confirm:
- Database, cache, and archive are on separate tiers with separate performance targets
- Cache window is derived from measured comparison-study intervals, per modality
- Prefetch triggers early enough to cover realistic retrieval time
- Retrieval time from cold and archive tiers is monitored and alerted
- Migration and backup jobs are scheduled outside peak clinical hours
- Archive tier has immutability with a retention period longer than worst-case detection time
- Backup exists as a separate control, not as a synonym for the archive tier
- Growth projections exist per tier, not just in aggregate
Related Reading
- How to Calculate PACS Storage Growth — the capacity math that feeds this design
- Healthcare IT Server & VM Sizing — the wider infrastructure picture
- Backup and Disaster Recovery for Clinical Systems — the control that tiering does not replace
Need tier-migration behaviour analysed against your own study data? Tell us what you're seeing — we build reporting tools against real PACS and VNA exports.