Skip to content

SYSTEM Cited by 1 source

PACS (Picture Archiving and Communication System)

PACS is the medical-imaging system category that hospitals use to store, retrieve, distribute, and display diagnostic images (CT, MRI, X-ray, mammography, ultrasound). It ingests DICOM objects from imaging modalities, indexes their metadata, archives the pixel data, and serves studies to radiologists and clinicians for reading and reporting. A closely related term, VNA (Vendor Neutral Archive), refers to the storage/normalization layer that can hold images from multiple imaging-system vendors in a standardized form.

Six core components

Every PACS — regardless of vendor or deployment model — decomposes into six building blocks. Cloud migration re-hosts and enhances these rather than replacing them. (Source: sources/2026-09-17-aws-building-cloud-native-pacs-on-aws)

Component Role
Web Server Serves the zero-footprint viewer UI, auth, sessions; renders DICOM in-browser (windowing/leveling/measurement)
VNA Server DICOM ingestion, multi-vendor format normalization, compression, image streaming; receives C-STORE from modalities on the LAN
Application server Worklist management, study routing by urgency/subspecialty, HIS/EMR integration via HL7 v2 or FHIR REST
Database Patient MPI, study-location tracking, sync state — everything except pixels; enables cross-facility patient lookup
Object Storage All DICOM pixel data, lifecycle-managed; replaces SAN/NAS with scalable pay-per-use storage
PACS Viewer Local + cloud dual viewer with transparent routing based on image availability

Traditional (on-prem) workflow

Clinician orders a study → RIS (Radiology Information System) fills the order and populates the modality worklist → technologist acquires the study → scanner sends DICOM objects to the PACS/VNA via C-STORE over the hospital LAN → PACS ingests images + HL7 orders, archives on local SAN/NAS, indexes metadata, notifies the radiologist worklist → radiologist reports → report flows back to the EMR via HL7.

Why the siloed on-prem model does not scale (per the 2026 AWS post): storage cost explosion (SAN/NAS refresh every 3–5 yr, maintenance 15–20% of hardware cost, over-provisioning years ahead); data silos (a patient scanned at Hospital A can't be viewed at Hospital B in the same chain); radiologist routing bottleneck (no way to route to available readers elsewhere); unbounded archive growth (7–10 yr retention, 50–200 TB/yr per chain).

Cloud-native PACS on AWS (hub-and-spoke)

The AWS reference architecture keeps a local PACS at each hospital (spoke) for LAN-speed daily reads, connected to a centralized cloud archive (hub) over Direct Connect or Site-to-Site VPN. A single PACS vendor is deployed consistently across every site AND the cloud, so all sites share a common metadata database and the hub can discover/retrieve any study created anywhere in the network — a unified enterprise imaging record.

  • New studies land on the local VNA at LAN speed, then replicate to S3 asynchronously so clinical workflow is never blocked. (concepts/asynchronous-replication)
  • Cloud tier runs across two AZs: EC2 web/VNA/app servers behind NLBs with automatic failover; Aurora PostgreSQL as the centralized metadata store; S3 holds pixel data under lifecycle policies.
  • Teleradiology viewer delivered via CloudFront
  • WAF with IP allow-listing and encryption.

Transparent dual viewer

On a study open, the PACS app checks the metadata DB for image location: locally cached studies (the majority of daily requests) serve from local disk at LAN speed; expired-cache studies stream from S3 via CloudFront with progressive loading. The clinician is unaware of the backend source. (concepts/cache-hit-rate)

Storage tiering by access age

Medical imaging has a predictable decay in access frequency, which makes it an ideal tiered-storage workload — mapped onto S3 storage classes:

Age band Access pattern S3 class
< 6–12 mo Active (reporting, follow-ups) S3 Standard (ms access ≈ local SAN)
6–12+ mo Occasional comparative reads S3 Glacier Instant Retrieval (systems/aws-s3-glacier) — ms retrieval, archive pricing
Unpredictable Research/teaching hospitals S3 Intelligent-Tiering (systems/aws-s3-intelligent-tiering) — auto-tier, no retrieval fee
> 5 yr Long-term retention S3 Glacier Deep Archive (systems/aws-s3-glacier) — 12–48 h retrieval

HA / DR

S3 replicates every object across multiple AZs; CRR adds a second-Region DR copy with no extra infra. Failure spectrum: local server down → route to cloud (recent data synced); cloud link down → local cache keeps serving; single AZ down → NLB failover within seconds. (concepts/regional-failover)

Cloud-only vs hybrid

Decided by connectivity + vendor capability, not imaging volume. Cloud-only fits redundant multi-carrier connectivity + a cloud-optimized vendor; hybrid fits limited/single-carrier connectivity or a local-cache-optimized vendor. Both use AWS as the durable archive; the difference is where the active working set lives.

Seen in

Last updated · 766 distilled / 2,225 read