Most radiology departments size their PACS storage requirements once, at purchase, and do not revisit the math until the archive hits 90 percent and someone has to justify an emergency hardware order. Imaging volume does not grow in a straight line. A new mammography protocol, a switch to thinner CT slices, or a change in your state’s retention rule can each push storage consumption up by a factor the original spreadsheet never accounted for. Getting the estimate right, and rebuilding it every year, keeps a growing imaging program ahead of its infrastructure instead of chasing it.
This is a planning problem with three moving parts: how much storage you need, how much network bandwidth moves that data around, and how much compute capacity you need to render and process it. Most teams size for storage and stop there. The other two catch up with them later, usually during a remote-reading rollout or an AI pilot nobody budgeted capacity for.
Estimating PACS Storage Requirements by Modality
Start with two numbers per modality: annual study count and average study size. Multiply the two, and you have a raw annual footprint before compression and retention math.
Study size varies more than most planning spreadsheets assume, and not just by modality. A plain film X-ray still runs a few megabytes. A CT or MRI study can be ten to a hundred times larger, and the exact number depends heavily on protocol choices your imaging team controls, not just the equipment. A 2025 study of CT staging exams found the acquired axial series alone had a median size of 290 MB at thin-slice protocols, versus 130 MB for a comparable exam on thicker slices, and that routinely stored reformats and reconstructions nearly tripled the total study size to a median of 787 MB.
Two facilities running the same CT scanner on different protocols can generate meaningfully different annual storage totals from identical study volume. If your facility is adding a modality like digital breast tomosynthesis, model that jump on its own rather than folding it into a blended growth rate. OmniPACS implementation teams see this gap most often during a DBT rollout, where the mammography line gets undersized because it was averaged in rather than modeled separately. See Mammography PACS and DBT workflows for the storage implications specific to that modality that an average will not catch.
Annual Growth Drivers Beyond Study Count
Total study volume rising is the obvious growth driver, and the easiest to plan for since most departments already track procedure counts. The harder drivers are the ones that increase the size of each study without necessarily increasing how many you do.
New Modalities and Protocol Upgrades
Every time a team adopts thinner slices, adds a new protocol, or brings on a new modality, the per-study average changes, not just the total count. A healthcare storage provider working with imaging departments has described the shift from 2D to 3D mammography as a jump from roughly 50 MB per study to over 1 GB on average, a more than twenty-fold increase carried almost entirely by the switch to tomosynthesis. A study-count forecast alone will miss that.
Retention Rules
Extending retention from five to seven years, or adding a permanent-retention rule for pediatric studies, does not change annual generation, but it changes how much you carry at any given time, since older studies stop rolling off the archive. See HIPAA-compliant medical imaging storage for what those obligations require at the infrastructure level. For planning, treat the retention window as a multiplier on annual volume, not a number you can set and forget.
PACS Bandwidth Planning for Daily Transfers and Remote Reads
Storage capacity gets the attention because it shows up as a monthly bill or a hardware order. PACS bandwidth planning gets skipped because it stays invisible until it fails, usually as a radiologist watching a study load slowly mid-read.
Three patterns drive bandwidth demand that a pure storage estimate will not capture. Daily transfer windows matter because acquisition is not evenly distributed: a busy outpatient center front-loads studies into a few morning hours, so the network needs to handle peak throughput, not the daily average. Prior-study retrieval adds a second layer, since a radiologist comparing a current CT to two or three priors is pulling several hundred megabytes to several gigabytes of historical data for a single read.
Remote and off-site reading adds a third layer, because bandwidth now has to cover the path to wherever the radiologist is working, not just modality to archive. See Bandwidth, latency, and display requirements for remote radiology reading for what that connection needs to support a real-time read instead of a slow one.
From Buy-Ahead Provisioning to Elastic Cloud Consumption
Traditional on-premise PACS forces a buy-ahead decision: you purchase storage, network, and compute hardware sized for volume you expect three to five years out, because a mid-cycle upgrade is disruptive and expensive. That means you are either overpaying for capacity you will not use for years, or underprovisioning toward the emergency purchase this article opened with.
Cloud-based PACS platforms change that math by decoupling the sizing decision from the purchase decision. Instead of provisioning for a five-year forecast, you provision close to current usage and adjust as volume actually changes. OmniPACS is built on this model, with cloud infrastructure that scales with study volume rather than a fixed hardware footprint that has to be re-justified every few years. OmniPACS Delivers Scalable Monthly Plans that size to actual imaging volume, so the capacity conversation shifts from a five-year capital forecast to an operating decision a team can revisit annually instead of once a decade.
That shift does not remove the need for the estimates in this article. Elastic infrastructure still needs a forecast to manage costs predictably, and a facility with no sense of whether its annual growth is 5 percent or 25 percent will struggle to budget for either a subscription or a hardware refresh. What changes is the cost of getting the estimate wrong. A conservative on-premise purchase that turns out too small means a disruptive mid-cycle upgrade; a conservative cloud estimate that turns out too small means adjusting a subscription tier.
Compute Considerations: Rendering and AI on the Horizon
Compute capacity is the piece most sizing exercises skip entirely, mostly because it has historically been a smaller line item than storage or network. That is changing on two fronts.
Rendering load is the more established one. Thin-slice CT and MRI studies increasingly get read with 3D reconstruction, multiplanar reformatting, and volume rendering rather than as a stack of 2D images, and that processing happens somewhere, whether on a local workstation GPU or a server-side rendering pipeline. The more a radiology group leans on these tools, the more that demand needs to be planned for rather than assumed to be free capacity on whatever hardware is already in place.
AI-assisted workflows are the newer, less predictable driver. Worklist triage tools and other imaging AI applications each add their own processing load on top of whatever rendering the reading workflow already requires. Most departments evaluating an AI tool price the software license and skip the compute question entirely, then discover the gap once a pilot moves past a handful of studies a day. A rough compute estimate alongside the storage and bandwidth plan, even a directional one, avoids that surprise.
What This Means for Your Capacity Plan
Pull these pieces into one working model instead of three separate spreadsheets. Start with current annual study volume by modality, apply the protocol and retention adjustments that matter for your site, layer in a bandwidth estimate based on actual reading patterns, whether on-site, remote, or both, and add a directional compute line for any AI tools on the roadmap. That combined view is what imaging storage capacity planning actually means in practice: matching infrastructure to how the program is really changing, not to how it looked at the last PACS purchase.
Revisit the model annually, not once at implementation. The facilities that get caught by a capacity crunch are almost always the ones that built a sizing estimate once, during a purchase or migration, and never updated it as protocols, retention rules, or reading patterns shifted underneath it. OmniPACS works with imaging teams to build that capacity model as part of onboarding, rather than treating it as a one-time exercise at purchase.
Building the Plan Into Your Roadmap
If your facility is also managing imaging data across multiple sites, the sizing math above is an input, not the full picture. See PACS storage at scale for multi-site health systems for the tiering, vendor-neutral archive, and federation decisions that come after you know your growth numbers. It is the better starting point once more than one facility’s imaging data is involved.
For a single-site or early-stage capacity plan, the goal is simpler: build the estimate, build in a growth buffer, and choose infrastructure that lets that estimate change without a disruptive re-platforming project. Explore OmniPACS Solutions to see how a cloud-native architecture supports that kind of ongoing planning instead of a one-time sizing exercise.
Frequently Asked Questions
How large is a CT scan file size?
CT scan file size varies by protocol more than by equipment. A 2025 study of CT staging exams found a median size of 290 MB for thin-slice acquisitions versus 130 MB on thicker slices, and stored reformats and reconstructions nearly tripled the total to a median of 787 MB per study.
How long are radiology records kept?
Retention periods vary by facility and state, but many imaging programs work from a five-to-seven-year baseline, with permanent retention sometimes applied to pediatric studies. Extending that window does not change how much you generate annually, only how much you carry at once, so treat retention as a multiplier on annual volume, not a fixed number.
How do you calculate PACS storage needs?
Start with two numbers per modality: annual study count and average study size, then multiply them for a raw annual footprint. From there, layer in protocol changes, new modalities, and retention rules as multipliers, since study count alone routinely underestimates how storage actually grows.