A 300-bed community hospital might generate 15–20 terabytes of imaging data per year. A regional health system with five campuses generates that every few months. Add in cardiology, orthopedics, and outpatient imaging centers, and you are looking at storage environments that grow by hundreds of terabytes annually with no natural ceiling in sight.
Managing PACS storage at that scale is a fundamentally different problem from single-facility deployments. The architecture decisions made at the start (how you tier data, where you centralize, how you federate across sites) determine whether your system scales cleanly for the next decade or requires expensive re-engineering in year three.
This guide covers the core architectural decisions for multi-site enterprise PACS environments: storage tier design, vendor-neutral archive placement, centralization versus federation trade-offs, study lifecycle management, and capacity planning at meaningful scale.
Why Single-Site Thinking Breaks at Enterprise Scale
A standalone PACS at one hospital works because the assumptions are simple: one modality pool, one radiologist group, one storage budget, one network. All those assumptions collapse when you add sites.
Data that was local is now distributed. A radiologist at your main campus needs sub-second access to a chest CT acquired at a satellite facility 40 miles away. The image is 800 MB. Your network connection to that facility is a 1 Gbps link shared with EHR traffic, VoIP, and administrative data. Without architecture designed for that reality, the workflow breaks.
The same pattern plays out for storage economics. A seven-year retention requirement applied across five sites, each with multiple imaging modalities, and compounds quickly. If your architecture does not systematically move older studies off high-performance storage and onto lower-cost tiers, your storage bill grows proportionally to your volume. Imaging volume at enterprise health systems roughly doubles every 5 to 7 years as modalities improve and procedure counts rise.
The architectural decisions below address these pressures directly.
PACS Storage Tier Architecture: Hot, Warm, and Cold
The core principle of tiered PACS storage is that data access patterns determine storage costs. Studies accessed frequently deserve fast, expensive storage. Studies that will never be statistically reopened do not.
Hot Tier: Recent and Active Studies
Hot storage holds studies that radiologists are actively working with or are likely to review within the next 30–90 days. This tier uses high-performance flash storage or NVMe-backed infrastructure because sub-second retrieval is a clinical requirement for active reading workflows.
A CT chest study with cardiac reformats might reach 2 GB. A multi-sequence MRI brain study typically ranges from 500 MB to 1.5 GB. A digital mammography with tomosynthesis can hit 1 GB per study. When multiplied across hundreds of daily studies in a multi-site system, the hot tier accumulates volume quickly. Most enterprise deployments size the hot tier to hold roughly 90 days of new study volume, with automated policies that move data to warm storage after that window.
This is where performance management matters most. Prefetching prior studies so radiologists have comparison images ready before they open a case is a function of hot-tier architecture and caching logic, not simply raw storage speed.
Warm Tier: Completed but Retrievable
Warm storage holds studies older than the active window, typically 90 days to 2–3 years, where retrieval is possible but not expected daily. The storage media here is typically high-density HDDs or cost-optimized SSD tiers that sacrifice some latency for dramatically better cost per TB.
The trade-off is measured in seconds, not milliseconds. Where a hot-tier retrieval might complete in under a second, a warm-tier pull might take 5–15 seconds, depending on study size and network path. For most recall or comparison scenarios, that is acceptable. For an emergency radiology read on a prior study, it may not be. System design needs to account for which study categories get recalled urgently and whether those categories stay in hot storage longer.
Cold Tier: Archival and Compliance Storage
Cold storage exists almost entirely to satisfy retention requirements, not clinical workflow. Studies older than three to five years are statistically assessed less than 10% of the time, and when they are assessed, the wait-time tolerance is much higher because the clinical context is historical rather than acute.
Object storage on cloud platforms (AWS S3 Glacier, Azure Archive, Google Archive) typically costs a fraction of hot SSD storage per terabyte. For enterprise health systems retaining seven or more years of studies, the cost difference is substantial. The trade-off is retrieval latency: cold-tier restores may take minutes to hours, depending on the selected storage class.
The cold tier also serves the HIPAA contingency planning requirement. A complete, accessible archive, geographically separated from primary storage, provides the disaster-recovery baseline mandated by the Security Rule. HIPAA-compliant storage for medical images requires controls at the data layer, not just at the network perimeter, and cold-tier architecture is where those controls get implemented for long-lived data.
Vendor-Neutral Archive (VNA) Architecture
A VNA sits between your imaging modalities and your consumption systems (radiologist viewers, EHRs, referring physician portals) and provides a standards-based repository that any authorized system can read from and write to, regardless of which PACS vendor originally acquired the data.
For single-site deployments, a VNA is a useful addition. For multi-site enterprise systems, it is an architectural infrastructure.
What a VNA Actually Does
At the technical level, a VNA receives DICOM studies from any source, normalizes metadata through tag morphing to resolve inconsistencies across sites, and stores data in a vendor-neutral format. It manages Information Lifecycle Management (ILM) rules that drive the hot-warm-cold tiering described above. It handles DICOM query-retrieve and DICOMweb for downstream viewers. Modern VNAs also support FHIR-based APIs for EHR integration, enabling imaging data to surface in clinical contexts beyond the radiology reading station.
Vendor neutrality matters primarily for migration scenarios. When a health system decides to replace its PACS viewer, upgrade its archive platform, or consolidate after an acquisition, a VNA ensures the image data is not locked to the outgoing vendor’s proprietary format. Without a VNA layer, PACS migrations entail expensive data conversion projects and transition windows during which historical data may be unavailable. The PACS migration checklist for any large-scale migration should account for VNA architecture decisions well before the cutover.
Enterprise VNA Placement
In a multi-site deployment, the VNA typically operates at the enterprise level rather than at each individual facility. Each site’s PACS connects to the enterprise VNA as both a source (sending newly acquired studies) and a consumer (retrieving prior studies for comparison).
This centralized model has two primary advantages: storage consolidation across sites and unified ILM policy enforcement. Instead of each facility managing its own tiering rules independently, a single enterprise VNA applies consistent lifecycle policies across the entire image archive.
The hub-and-spoke model is the most common deployment pattern. A central VNA with high-performance connectivity sits at the hub. Remote facilities connect as spokes, with local caching nodes that hold recent studies for fast local access while syncing to the central archive in the background. If the network link to the hub degrades, the local cache ensures radiologists at that facility can still read recent studies without interruption.
OmniPACS supports this architecture pattern natively, with VNA integration designed to work across distributed site deployments while maintaining consistent policy management from a central configuration plane.
Federation vs. Centralization: The Core Architectural Choice
Every multi-site health system eventually faces the same decision: do we centralize imaging across a single system, or federate distinct systems at each site while enabling shared access?
Centralized Architecture
A fully centralized architecture maintains one PACS database for the entire enterprise. Studies acquired anywhere in the system are immediately available everywhere. Radiologist worklists are pooled across sites. Comparison studies from any facility are accessible in the reading station without manual retrieval requests.
This model produces the cleanest workflow outcomes. Subspecialty routing (sending overnight abdominal reads to the on-call abdominal radiologist at a different campus) works natively because all studies and all radiologists exist in the same system context.
The cost is infrastructure complexity. A centralized architecture depends on network connectivity that is reliably low-latency across all sites. Acquisition workflows at remote facilities must tolerate the round-trip time to the central system. If the network path degrades, so does the modality workflow.
For health systems with reliable high-bandwidth connectivity between sites, centralization is typically the preferred end state. Medical imaging system integration that brings the EHR, RIS, and PACS into a unified workflow depends on a centralized data model to function without complex synchronization logic between disparate systems.
Federated Architecture
A federated architecture maintains distinct PACS instances at each site with a coordination layer that allows cross-site study access without full centralization. Each facility’s PACS operates independently for local acquisition and reading workflows. A federation layer handles cross-site queries, enabling a radiologist at Site A to retrieve and view a prior study from Site B without the study being stored locally.
The advantage is operational resilience. A network outage between sites does not take down local imaging workflows at either location. Each facility can be configured and managed independently, which is useful in organizations where acquired facilities come with their own operational models and IT teams.
The trade-off is complexity at the federation layer. Cross-site worklist management, prior-study prefetching, and STAT routing require explicit configuration and ongoing maintenance. As the number of federated sites grows, that complexity compounds.
Many large health systems operate in a hybrid model: a centralized enterprise VNA for long-term archiving and compliance, with distinct PACS instances per site for acquisition and active reading workflows. The RIS handles order management and links the imaging data across sites through HL7 messaging. If this is the direction your system is moving, reviewing how RIS and PACS system integration works at scale is an important design step before choosing your federation topology.
Study Lifecycle Management
Imaging data does not simply arrive and sit. Every study moves through a lifecycle from acquisition to active reading to historical archive to eventual deletion, and each stage carries different access requirements, storage costs, and compliance obligations.
Defining Lifecycle Stages
The typical enterprise PACS lifecycle has four stages:
Active: Studies within the reading workflow or recently completed. Stored in hot tier. Typical duration: 30–90 days.
Clinical reference: Studies used for comparison by treating clinicians. Stored in warm tier. Typical duration: 1–5 years, depending on specialty.
Legal retention: Studies retained for compliance. Stored in cold tier. Minimum of 7 years for most US facilities; pediatric imaging often requires retention to age 21, plus the applicable retention period.
Purge-eligible: Studies beyond all retention requirements that are cleared for deletion. Typically managed through ILM policy automation with audit logging for compliance documentation.
Automating Lifecycle Transitions
Manual lifecycle management does not scale. An enterprise system generating 150,000 studies per year cannot rely on IT staff to manually review and move files between tiers. ILM automation within the VNA is what makes tiering practical at scale.
Good ILM configuration includes rules that account for the modality type (cardiac studies may warrant longer warm retention than screening chest X-rays), the patient’s age at the time of the study, and whether a study has been flagged for legal hold. Exception handling for studies that are actively cited in open legal matters or IRB research protocols prevents automated deletion of data that must be retained.
OmniPACS enterprise deployments can be configured with ILM policies that align with your organization’s retention schedules and state-specific requirements, with audit trails that satisfy both HIPAA documentation requirements and potential discovery obligations.
Capacity Planning at Scale
Storage capacity planning for enterprise PACS is not a one-time exercise. It is a rolling forecast that needs to account for both volume growth and changes in modality mix.
Estimating Annual Storage Requirements
Start with your current annual study volume and your average study size by modality. A useful working range:
X-ray: 5–20 MB per study (varies significantly with DR vs. CR and image count) CT: 200 MB to 2+ GB per study (protocol-dependent; cardiac CT with reconstructions can reach 3 GB) MRI: 100 MB to 1 GB per study (multi-sequence protocols drive the higher end) Digital mammography with tomosynthesis: 500 MB to 1 GB per study Ultrasound: 50–300 MB per study depending on clip length
A 500-bed facility performing 120,000 studies per year with a typical modality mix will commonly generate 30–50 TB of new raw data annually. Before compression, tiering, and deduplication, that compounds quickly across multi-year retention periods.
For an enterprise system with five sites and a seven-year retention, the total managed archive can easily reach 500 TB to multiple petabytes, depending on modality volume and CT/MRI mix.
Planning for Growth
Study volume at most health systems grows 5–10% annually as procedures increase and modality upgrades generate larger files. 3D imaging protocols, spectral CT, and multi-echo MRI sequences routinely produce studies that are 3–5 times larger than those acquired on older equipment.
Capacity planning should build in a 15–20% annual growth buffer above projected volume and include a reassessment trigger when the total archive reaches 75% of provisioned capacity. Cloud-based PACS storage environments like those OmniPACS provides offer elastic provisioning, where capacity can be increased without hardware procurement cycles, but that flexibility still requires forecasting to manage costs.
Compression is a meaningful variable. Lossless JPEG2000 compression routinely reduces CT study sizes by 60–80% without compromising image quality. A system that achieves consistent 70% compression on its CT volume effectively extends its storage runway by a factor of three on that modality. Establishing compression policies at the VNA level, rather than at the individual modality level, produces more consistent results across the enterprise.
Putting the Architecture Together
Multi-site PACS architecture is not a single decision. It is a sequence of interdependent choices that need to be made in a consistent order. Storage tier definitions need to be set before VNA ILM policies can be written. The centralization vs. federation decision needs to be made before network infrastructure requirements can be specified. Lifecycle management automation needs to be designed before capacity plans can be finalized.
The most common implementation failure pattern is treating these decisions as independent and discovering the conflicts during deployment. A health system that sizes its centralized network for normal operations but not for migration-period traffic, or that defines retention policies without accounting for state-specific pediatric imaging requirements, typically discovers the gaps at the worst possible time.
OmniPACS works with health system IT and radiology operations teams to sequence these decisions correctly and configure the resulting architecture to match your operational and compliance environment. If you are assessing your current architecture or preparing for a multi-site expansion, explore OmniPACS Solutions to understand how to structure an enterprise PACS architecture for long-term scalability.
Frequently Asked Questions
How many terabytes of storage does a typical enterprise health system need for PACS?
A 500-bed facility with a standard modality mix commonly generates 30–50 TB of new imaging data per year. A five-site enterprise system with seven-year retention can manage an archive of 500 TB to multiple petabytes. The total depends heavily on CT and MRI volumes, since those modalities can produce studies that reach 2–3 GB each under modern protocols.
What is the difference between a VNA and a PACS for enterprise deployments?
A PACS manages the acquisition workflow, reading workflow, and active study storage at a site or department level. A VNA is a long-term, vendor-neutral archive that stores imaging data in a standardized format accessible by any system, regardless of which PACS vendor acquired it. In enterprise deployments, PACS and VNA typically co-exist: the PACS handles active workflows, and the VNA handles long-term archiving and cross-site access. Understanding vendor-neutral archive architecture and its role in multi-site imaging is a useful context for this design decision.
What retention period is required for medical imaging data under HIPAA?
HIPAA requires a minimum six-year retention period for policies, procedures, and documentation related to the HIPAA Security Rule. State law governs clinical record retention, and most US states require adult imaging data to be retained for at least seven years. Pediatric imaging is typically retained until the patient reaches adulthood, plus the standard retention period, which can extend to 21 years or more in some states. NIST guidance on securing the PACS ecosystem should be reviewed against your specific state requirements.
When does federation make more sense than full centralization for multi-site PACS?
Federation is the better fit when acquired facilities have distinct operational models, when network connectivity between sites cannot reliably support centralized acquisition workflows, or when a health system is still evaluating which facilities will be long-term parts of its network. Centralization is typically preferred when all sites share IT governance, network infrastructure is robust, and cross-site radiologist pooling and subspecialty routing are operational priorities. Many systems use a hybrid approach: federated PACS at each site connected to a centralized enterprise VNA for archiving.
How does cloud-based PACS storage handle capacity planning differently from on-premise?
Cloud PACS storage eliminates hardware procurement cycles and enables elastic capacity provisioning as volume grows. However, capacity planning remains necessary to forecast costs accurately and avoid unexpected spending when volume growth exceeds projections. Well-managed cloud PACS deployments set automated alerts at 75–80% of provisioned capacity and run annual forecasting reviews that account for changes in modality mix, compression ratios, and new site additions.