PACS Fundamentals

The Picture Archiving and Communication System (PACS) was conceptualized in the early 1980s as a revolutionary mechanism to transition radiology departments from cumbersome physical film archives to accessible digital files. A traditional on-premises PACS is characterized by a localized, tightly coupled client/server architecture designed primarily to serve a single department, hospital facility, or localized health district.

To fully grasp the constraints of the monolithic approach and understand why cloud migration has become a strategic imperative, an AWS Solution Architect must first understand the interconnected elements that constitute the traditional imaging environment. The core architecture is built upon four foundational hardware and software components that facilitate the end-to-end clinical workflow.

View full size

Source: open-access review of imaging informatics conceptsLast verified: 2026-03-11

That broader flow is what makes PACS hard to modernize in isolation. Orders and demographics arrive from EMR and RIS, image objects flow through DICOM-centric services, and the interpreted result has to return to the clinical record. The picture is a better beginner mental model than treating PACS as a simple image bucket.

Modalities are the physical hardware devices and instrumentation utilized to scan patients and acquire diagnostic data. These represent the edge layer of the PACS architecture—the point where analog patient data is transformed into digital imaging objects.

Modality Types

Acquisition Gateway Function

Because historical imaging equipment often produced proprietary data formats incompatible with universal PACS standards, these modalities are traditionally connected to an acquisition gateway computer. This gateway acts as an intermediary compute node that receives the raw or proprietary data from the modality, standardizes the imagery into the universal DICOM format, applies orientation calibrations and patient demographic overlays, and routes the standardized object to the central PACS server.

The network forms the critical nervous system of the monolithic PACS. In a localized, on-premises setup, this architecture relies heavily on a high-speed Local Area Network (LAN) utilizing standard TCP/IP protocols to transmit massive binary image files between acquisition points, archives, and workstations.

LAN Infrastructure Requirements

Within this network layer, specialized DICOM routers and gateways act as traffic directors. These routers manage the flow of heavy imaging data based on predefined logic rules—such as routing specific modality types to specific specialized archives, balancing loads across network switches, and eliminating manual transmission bottlenecks.

The central repository consists of the primary PACS application server and its attached persistent storage, which is typically configured as a highly resilient Storage Area Network (SAN) or Network Attached Storage (NAS) array. This represents the largest capital expenditure in traditional PACS deployments.

SAN vs NAS Storage Architectures

Storage Tier Architecture

Traditional PACS storage infrastructure is bifurcated into two distinct tiers: short-term, rapid-access storage optimized for high Input/Output Operations Per Second (IOPS) to support current patient encounters, and a deep-archive tier utilized for long-term historical reference and regulatory retention compliance (typically 7-10 years depending on jurisdiction).

In this client/server-based monolithic model, newly acquired images are transmitted directly to this centralized archive, creating a definitive single source of truth for the enterprise. Consequently, this centralization also introduces a singular architectural bottleneck during peak diagnostic periods and a concentrated single point of failure.

The final node in the PACS architecture is the endpoint where clinical interpretation occurs. Radiologists rely on high-resolution, specialized diagnostic workstations equipped with heavy, proprietary PACS viewer software that must be installed and maintained on each individual machine.

These "thick client" workstations require substantial local computing power, including advanced Graphics Processing Units (GPUs) and high-memory capacities (often 32-64GB RAM), to process and render massive datasets locally. This local compute enables advanced image processing tasks, such as 3D spatial reconstructions, multi-planar reformation (MPR), image fusion, and the application of complex measurement tools required for accurate diagnosis.

Workstation Tiers

Secondary review workstations, utilized by referring physicians outside the radiology department, typically require fewer processing capabilities and may utilize web-based interfaces, but they remain an essential component for broader clinical collaboration. Administrative workstations handle scheduling, patient registration, and reporting functions with minimal image processing requirements.

The following diagram illustrates the complete data flow through a traditional monolithic PACS architecture, showing how images move from acquisition modalities through gateways, routers, archives, and finally to diagnostic workstations.

The following flowchart illustrates the complete PACS component architecture with integration points for RIS and HIS systems:

The following state machine diagram illustrates the complete lifecycle of a medical image from acquisition through eventual purging:

Understanding the fundamental differences between traditional monolithic PACS and modern cloud-native architectures is essential for making informed migration decisions. The following comparison highlights key architectural, operational, and financial distinctions.

Cloud-Native Architecture Diagram

The following table summarizes the four foundational components of traditional PACS architecture, their primary functions, and infrastructure dependencies.

For further reading on PACS fundamentals, DICOM standards, and industry best practices: