Chapter 4: PACS and Storage Systems

4.1 Introduction to PACS

Picture Archiving and Communication Systems (PACS) are the backbone of modern radiology departments. They provide digital storage, retrieval, and display of medical images, eliminating the need for film-based workflows.

4.2 PACS Architecture Components

A comprehensive PACS consists of several integrated components:

Component	Function	Key Features
Acquisition Gateways	Receive images from modalities	Protocol conversion, routing rules
Archive Server	Long-term image storage	Database management, storage tiering
Image Database	Metadata indexing	Fast query, study tracking
Web Server	Browser-based access	Zero-footprint viewing
Diagnostic Workstations	Image interpretation	High-resolution displays, specialized tools
Integration Engine	External system connectivity	HL7 interfaces, RIS/HIS integration

4.3 Storage Architecture

Modern PACS employ tiered storage to balance performance and cost:

Storage Tiers

Tier	Technology	Access Time	Use Case
Tier 0 (Hot)	NVMe SSD	Milliseconds	Current studies, active reading
Tier 1 (Warm)	SSD/Fast HDD	Seconds	Recent studies (30-90 days)
Tier 2 (Cold)	HDD Arrays	Seconds-Minutes	Historical archive (1-5 years)
Tier 3 (Archive)	Tape/Object Storage	Minutes-Hours	Long-term retention (7+ years)

4.4 Vendor Neutral Archive (VNA)

VNA provides vendor-independent long-term storage, separating archive from viewing applications:

VNA Benefits

• Vendor Independence: Store data without proprietary formats
• Data Consolidation: Unified archive across departments
• Migration Flexibility: Change PACS without data conversion
• Cost Optimization: Shared infrastructure reduces expenses
• Standards-Based: Pure DICOM and non-DICOM support

Enterprise Imaging Strategy

VNA enables enterprise imaging by consolidating images from multiple sources:

Source	Content Type	Integration Method
Radiology PACS	CT, MR, X-ray, US	DICOM
Cardiology	Echo, cath, ECG	DICOM, HL7
Pathology	Whole slide images	DICOM WSI
Ophthalmology	Fundus, OCT	DICOM
Point-of-Care	Smartphone images	DICOM encapsulation
Documents	Scanned records	PDF, XDS

4.5 Cloud PACS

Cloud-based PACS solutions offer scalability and reduced infrastructure burden:

Cloud PACS Deployment Models

Model	Description	Considerations
Full Cloud	All components hosted in cloud	Network dependency, latency for large studies
Hybrid	Local cache + cloud archive	Balance of performance and scale
Cloud Archive Only	Local PACS, cloud long-term storage	Disaster recovery, compliance
Multi-Cloud	Distributed across providers	Vendor diversification, complexity

4.6 System Integration

PACS must integrate with multiple healthcare systems:

Key Integrations

• RIS (Radiology Information System): Orders, scheduling, reporting
• HIS/EHR: Patient demographics, clinical context
• Billing Systems: Procedure codes, charge capture
• Voice Recognition: Dictation and report generation
• AI Platforms: CAD algorithms, automated analysis

4.7 Disaster Recovery

PACS disaster recovery ensures imaging continuity during system failures:

DR Strategies

Strategy	RTO	RPO	Cost
Backup/Restore	Hours-Days	Hours-Days	Low
Active-Passive	Minutes-Hours	Minutes	Medium
Active-Active	Minutes	Near-zero	High
Cloud DR	Minutes-Hours	Minutes	Variable

4.8 Performance Optimization

PACS performance impacts radiologist productivity and patient care:

Performance Metrics

• Study Load Time: Time from selection to display (<5 seconds goal)
• Image Streaming: Progressive loading for large studies
• Concurrent Users: System capacity under load
• Query Response: Search result speed (<2 seconds)

4.8 Simulator ENUM and Threshold Mapping (PACS and Protocol)

The PACS components and communication protocols introduced in this chapter map directly onto two ENUM clusters in the simulator: PACS_NODE (system topology) and PROTOCOL (communication standard). A modern PACS is not a single server but a distributed ecosystem of PACS, VNA, RIS, HIS, EMR, and EHR systems, connected through DIMSE or DICOMweb protocols.

Table 4.8.1 — PACS Topology ENUM

ENUM	Full Name	Primary Role
PACS	Picture Archiving and Communication System	Image storage, distribution, and viewing
VNA	Vendor Neutral Archive	Vendor-independent long-term archive
RIS	Radiology Information System	Radiology workflow management
HIS	Hospital Information System	Hospital-wide information system
CIS	Clinical Information System	Clinical information system
EMR	Electronic Medical Record	Electronic medical record system
EHR	Electronic Health Record	Cross-enterprise health record
DICOM_NODE	DICOM Node	DICOM communication endpoint
DICOM_PROXY	DICOM Proxy	DICOM routing and transformation
AE_TITLE	Application Entity Title	DICOM application identifier

The Vendor Neutral Archive (VNA) is a strategically important component conceptually distinct from PACS. Whereas PACS typically uses vendor-proprietary internal data structures and embeds workflow logic in storage decisions, a VNA stores images in vendor-neutral DICOM format with vendor-agnostic metadata. When a hospital replaces its PACS, the imaging assets stored in a VNA can be migrated to the new PACS without lossy transcoding, breaking the vendor lock-in pattern that plagued early PACS deployments.

Table 4.8.2 — DICOM Protocol ENUM Mapping

ENUM	Full Name	Transport
DICOMWEB	DICOMweb umbrella standard	HTTP / REST
QIDO_RS	Query based on ID for DICOM Objects (RESTful)	HTTP GET
STOW_RS	Store Over the Web (RESTful)	HTTP POST
WADO_RS	Web Access to DICOM Objects (RESTful)	HTTP GET
WADO_URI	Web Access to DICOM Objects (URI)	HTTP GET (simple)
DIMSE	DICOM Message Service Element	TCP/IP DICOM Upper Layer
STORE_SCP	Storage Service Class Provider	DIMSE C-STORE
QUERY_RETRIEVE_SCP	Query/Retrieve Service Class Provider	DIMSE C-FIND / C-MOVE / C-GET
MWL_SCP	Modality Worklist SCP	DIMSE C-FIND (Worklist)
PERFORMED_PROCEDURE_STEP	Modality Performed Procedure Step	DIMSE N-CREATE / N-SET

4.9 DICOMweb — Web-Native PACS Communication

DICOMweb (DICOM PS3.18) is the modern HTTP/REST reformulation of DICOM communication, designed to overcome the limitations of the legacy DIMSE protocol in cloud-native and mobile-first environments. The three primary services — QIDO-RS for query, STOW-RS for store, and WADO-RS for retrieval — together provide a comprehensive RESTful surface for image management.

QIDO-RS — RESTful Query

QIDO-RS exposes a RESTful API for querying DICOM objects at the patient, study, series, and instance levels. A query as simple as GET /studies?PatientID=12345&StudyDate=20240101-20241231 returns a list of studies for a specific patient over a date range. Responses are returned as JSON arrays of DICOM metadata, immediately usable by web and mobile clients without specialised DICOM toolkits.

STOW-RS — RESTful Store

STOW-RS stores images in PACS via POST /studies or POST /studies/{StudyInstanceUID}. The multipart/related content type permits packaging multiple DICOM files within a single HTTP request, optimising bulk upload for study-level transfers.

WADO-RS — RESTful Retrieval

WADO-RS retrieves image data in multiple representations (application/dicom, image/jpeg, image/png, video/mp4). The pattern GET /studies/{StudyInstanceUID}/series/{SeriesInstanceUID}/instances/{SOPInstanceUID}/rendered returns a pre-rendered image, eliminating the need for client-side DICOM decoding and enabling thin viewers to operate on commodity devices.

"DICOMweb preserves the essential object model and service class semantics of the DICOM standard while leveraging the simplicity of HTTP and the toolchain of the modern web. It is the foundation of next-generation cloud PACS and mobile image viewers." — DICOM PS3.18 DICOMweb Specification, 2024.

OHIF, Orthanc, and dcm4che — Open-Source DICOMweb Implementations

The OHIF Viewer (Open Health Imaging Foundation), a React-based full-stack DICOMweb viewer released under the MIT licence, is developed primarily at Massachusetts General Hospital and Harvard Medical School. Orthanc, a lightweight open-source PACS originating at the University of Liège, ships as a single binary, supports full DICOMweb, and is widely deployed at the edge for small clinics and research data collection. The dcm4che project provides a Java-based DICOM toolkit and server suite used by large enterprises for conformance testing and reference implementations.

4.10 Korean Edition Note (한국어판 안내)

The Korean edition (한국어판) extends this chapter with section §4.A on Korean PACS infrastructure, including the Infinitt Healthcare INFINITT PACS (approximately 35 per cent domestic market share, 2024), the Vieworks LiveMD PACS, the Selvas Healthcare ALPS suite, the Bundang Seoul National University Hospital BESTCare PACS, the Asan Medical Centre AMIS PACS (a petabyte-scale archive), the Samsung Medical Center DARWIN platform, and the Severance YUHS PACS. The K-PACS Standard jointly published by MFDS and KOSMI is also discussed in detail.

4.11 Disaster Recovery and Business Continuity

Modern PACS architectures must satisfy stringent Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets. The radiology department of a large tertiary hospital typically operates under a continuity policy that mandates RTO under four hours for routine imaging access and RTO under thirty minutes for emergency imaging access, with RPO measured in single-digit minutes for newly acquired images.

Recommended architectural elements include synchronous replication between primary and secondary on-premise data centres, asynchronous replication to a geographically distant cloud-based VNA, automated failover orchestrated by a clinical IT incident response team, and routine disaster recovery drills carried out at least annually. Modern cloud-resident VNAs offered by hyperscale providers can deliver RPO measured in seconds at competitive total cost of ownership compared with traditional dual-data-centre operations.

An often-overlooked element of business continuity is the integrity of the DICOM Conformance Statement matrix during recovery. After a failover, the recovered PACS must present the same AE Titles, supported SOP Classes, and Transfer Syntaxes as the primary, so that modalities and downstream viewers do not need reconfiguration. This requires the Conformance Statement to be treated as an operational artefact, version-controlled alongside the PACS configuration database and validated as part of every disaster recovery drill.