Storage sizing is the most consequential technical decision in a PACS implementation, and it's the one most frequently done wrong.
The typical approach: ask the vendor what storage you need, accept their estimate, add 20% buffer. The typical result: you're back at procurement 18 months later because the buffer is gone and growth has outpaced the projection.
The correct approach is to build the calculation yourself from first principles, using your own modality data. Here's the exact method.
The Core Formula
Annual new storage (TB) =
Σ (studies per modality per year × average study size per modality)
× (1 ÷ compression ratio)
× growth factor
This sounds simple. The challenge is getting accurate inputs for each variable.
Variable 1: Studies Per Modality Per Year
Pull this from your RIS or current PACS. You want a 12-month rolling count, broken down by modality type. Do not use your total study count — the distribution matters because study sizes vary by an order of magnitude between modality types.
A typical mid-size hospital breakdown (500 beds, busy ED):
| Modality | Annual Studies |
|---|---|
| CT | 28,000 |
| MRI | 12,000 |
| CR (Chest, MSK) | 45,000 |
| DX (Direct Digital) | 18,000 |
| US (Ultrasound) | 22,000 |
| NM (Nuclear Medicine) | 2,500 |
| MG (Mammography) | 8,000 |
| FL (Fluoroscopy) | 3,000 |
| Total | 138,500 |
If you cannot get this breakdown, you are estimating blind. Make getting this data a prerequisite for any storage sizing exercise.
Variable 2: Average Study Size Per Modality
This is where vendor estimates diverge most from reality. The published benchmarks are medians — your actual values depend on your specific scanner configurations, protocol complexity, and clinical specialty mix.
Published benchmark ranges:
| Modality | Conservative | Typical | Complex |
|---|---|---|---|
| CT (general) | 200 MB | 500 MB | 2 GB |
| CT (cardiac) | 1 GB | 3 GB | 8 GB |
| MRI (general) | 150 MB | 400 MB | 1.2 GB |
| MRI (brain, neuro) | 300 MB | 700 MB | 2 GB |
| CR | 8 MB | 15 MB | 25 MB |
| DX (DR) | 10 MB | 20 MB | 35 MB |
| Ultrasound (static) | 5 MB | 12 MB | 30 MB |
| Ultrasound (cine) | 200 MB | 600 MB | 2 GB |
| Mammography FFDM | 50 MB | 120 MB | 250 MB |
| Mammography DBT | 500 MB | 1.5 GB | 4 GB |
| Nuclear Medicine | 20 MB | 50 MB | 150 MB |
| PET-CT | 800 MB | 2 GB | 5 GB |
| Fluoroscopy | 150 MB | 400 MB | 1.2 GB |
The right way to get your numbers: Pull 90 days of study size data from your current PACS for each modality. Export the study size field from your DICOM database. Calculate the mean and 90th percentile. Use the 90th percentile for planning, not the mean.
If you're sizing for a new facility where you don't have historical data, use the "Typical" column from the table above as a starting point, then apply a 1.3× safety factor.
Variable 3: Compression Ratio
Lossless compression reduces storage requirements without any image quality impact. The achievable compression ratio depends on modality type:
| Modality | Lossless JPEG 2000 Ratio | Notes |
|---|---|---|
| CT | 1.5:1 to 2.5:1 | Higher for soft tissue series |
| MRI | 2:1 to 3:1 | Varies by sequence type |
| CR/DX | 2:1 to 3:1 | Plain films compress well |
| Ultrasound | 1.2:1 to 1.8:1 | Cine sequences compress less |
| Mammography | 1.5:1 to 2:1 | Tomosynthesis compresses less |
Important caveats:
- Lossy compression is generally not acceptable for primary diagnostic images in radiology. Some sites use lossy for specific non-diagnostic applications (e.g., patient facing apps), but this decision must be made with clinical stakeholder input.
- Compression is applied at write time. If you go live without compression and add it later, existing studies won't be retroactively compressed without a migration process.
- Some older modalities generate DICOM objects that compress poorly or not at all due to proprietary pixel encoding.
In the worked example below, we'll use a conservative 2:1 compression ratio for CT and MRI, and 2.5:1 for CR/DX.
Variable 4: Growth Factor
Study volume growth in healthcare is rarely zero. Drivers include population growth, expanded clinical programmes, new modalities, and increasing utilisation rates.
Typical annual growth rates:
- Mature, stable hospital: 3–5%
- Growing facility or expanding programme: 8–12%
- New facility (first 3–5 years): 15–25%
For planning purposes, compound the growth factor over your storage lifecycle. If you're purchasing storage for a 5-year period and expect 7% annual growth:
Year 1: 1.07×
Year 2: 1.07² = 1.145×
Year 3: 1.07³ = 1.225×
Year 4: 1.07⁴ = 1.311×
Year 5: 1.07⁵ = 1.403×
Size for Year 5 (or whatever your lifecycle is), not Year 1.
Worked Example: 500-Bed Hospital
Using the modality breakdown from earlier, here's the full calculation:
Step 1: Calculate raw annual storage before compression
| Modality | Studies/yr | Avg Size | Raw Annual (TB) |
|---|---|---|---|
| CT | 28,000 | 500 MB | 14.0 TB |
| MRI | 12,000 | 400 MB | 4.8 TB |
| CR | 45,000 | 15 MB | 0.68 TB |
| DX | 18,000 | 20 MB | 0.36 TB |
| US | 22,000 | 12 MB | 0.26 TB |
| NM | 2,500 | 50 MB | 0.13 TB |
| MG | 8,000 | 120 MB | 0.96 TB |
| FL | 3,000 | 400 MB | 1.2 TB |
| Total | 22.4 TB/yr |
Step 2: Apply compression
CT and MRI (19.6 TB raw) at 2:1 compression → 9.4 TB
CR/DX/US/other (2.8 TB raw) at 2.5:1 compression → 1.1 TB
Mammography (0.96 TB raw) at 1.8:1 compression → 0.5 TB
Fluoroscopy (1.2 TB raw) at 1.5:1 compression → 0.8 TB
Compressed annual storage: ~11.8 TB/year
Step 3: Apply 5-year growth at 7%/year
Year 5 requirement = 11.8 × 1.403 = 16.6 TB/year by Year 5
Step 4: Calculate tiered storage requirements
For a 5-year archive lifecycle with a typical access pattern:
| Tier | Definition | Requirement |
|---|---|---|
| Fast/Cache (SSD) | Studies 0–90 days | ~3 TB |
| Near-line (SAS) | Studies 90 days–3 years | ~40 TB |
| Archive | Studies 3–7+ years | ~80 TB |
| Total | ~123 TB usable |
Add RAID overhead (typically 20–25% for RAID 6) and you're looking at ~150 TB raw for this facility profile.
What the Vendor Estimate Usually Misses
When comparing your calculation to a vendor-provided storage estimate, watch for these common gaps:
Database storage — the PACS database (study metadata, worklist, reporting) can consume 5–20 TB depending on study count and history. Often quoted separately or not at all.
Index and transaction logs — database transaction logs should never reside on the same volume as application data. Budget for separate database log storage.
Operating system and application footprint — each server needs local storage for OS, application binaries, and temp files. Budget 500 GB per server minimum.
Backup storage — if you're doing local backup before replication, you need backup storage equal to at least 1× your fast-tier capacity.
Test/UAT environment — a realistic test environment requires 10–20% of production storage capacity.
The Practical Takeaway
Run this calculation before you request quotes. When vendor estimates come in, you'll be able to evaluate them critically rather than accepting them at face value.
If a vendor's storage estimate is significantly lower than yours, ask them to walk through their assumptions. The discrepancy usually comes from using mean study sizes instead of 90th percentile values, and from underestimating growth.
The PACS Storage Growth Calculator in the Majware catalogue automates this entire calculation — enter your modality study counts and the tool handles compression ratios, growth compounding, tiered storage modelling, and a 5-year projection with sensitivity analysis.