Infrastructure

PACS Explained

PACS — Picture Archiving and Communication System — is the backbone of a modern imaging department. It receives images from modalities, stores them, serves them to reading workstations, and bridges out to other systems (EHR, reporting, billing). DICOM is the language a PACS speaks; the PACS itself is the database + file store + access layer.

The four components

  1. Acquisition gateway — DICOM endpoint that receives C-STOREs from modalities. Often does on-the-fly routing, de-duplication, and transfer-syntax conversion.
  2. Archive — the durable store. Relational DB for metadata + blob store (local disk tier → SSD hot tier → tape or cloud cold tier) for pixel data.
  3. Reading workstations — where radiologists interpret. Pull via C-MOVE, C-GET, or (modern) WADO-RS. Includes hanging protocols, measurement tools, and voice dictation integration.
  4. Web distribution — zero-footprint viewers for referring physicians, patient portals, and remote reading. OHIF, Weasis, MicroDICOM, and PACS-vendor web viewers all fill this slot.

VNA — Vendor-Neutral Archive

A VNA is a storage layer that separates image archival from the PACS application tier. The idea: when you replace your PACS vendor every 5-8 years, you should not have to migrate 10 PB of imaging data with them. A VNA speaks DICOM (and usually XDS-I / DICOMweb) and owns the long-term storage; the PACS caches what's hot and reads from the VNA on demand.

VNAs shine in multi-facility health systems where different sites run different PACS vendors but want one logical archive. They also decouple the archive-sizing calculation from the PACS-licensing calculation, which tends to save money at scale.

VNA vs PACS archive: a PACS archive is typically vendor-locked — the database schema, storage format, and retrieval APIs are proprietary. A VNA is neutral by design: any DICOM-compliant PACS can point at it, and data migration to the next VNA is a DICOM-level export rather than a database-dump-and-rewrite.

Cloud PACS

"Cloud PACS" encompasses three distinct patterns — don't confuse them:

  • Hosted PACS — a vendor-managed PACS running in their cloud tenant. You still have a PACS; it's just not in your data center.
  • Cloud-native archive — AWS HealthImaging, Google Cloud Healthcare API, Azure Health Data Services. Object-storage-backed DICOM stores with native APIs plus DICOMweb.
  • Cloud-bridged archive — on-prem PACS extended with cloud tiers for cold storage. Transparent to clinical users; controlled via lifecycle policies.

See the vendor support matrix: cloud support by attribute →

How a study moves through a PACS

  1. Modality (CT scanner) C-STOREs images to the acquisition gateway after each patient.
  2. Gateway validates, routes, optionally compresses, then C-STOREs to the archive.
  3. Archive persists to hot storage; kicks off an MPPS/Storage Commitment confirmation back to the modality.
  4. Radiologist opens the patient in their worklist; workstation C-MOVEs the current study + priors from the archive to the workstation's local cache.
  5. Radiologist dictates findings; the Structured Report (SR) is C-STOREd back to the archive.
  6. Hot-to-cold tiering runs nightly: studies older than 90 days move to cold storage. Access from cold adds latency but the lifecycle policy is transparent to clients.

Integration points around the PACS

  • RIS / EHR — HL7 v2 ADT + ORM + ORU messages drive the worklist and carry report text back. Modern stacks use FHIR ImagingStudy + DiagnosticReport.
  • Modality Worklist (MWL) — modalities C-FIND against RIS/PACS for the day's scheduled procedures.
  • Reporting / speech — PowerScribe, Fluency Direct integrations via proprietary SDKs plus DICOM SR for structured findings.
  • Enterprise viewer — zero-footprint web viewer accessible from the EHR via context launch.
  • AI / CAD — inference pipelines that consume images via DICOMweb, produce annotations as DICOM SR, Presentation States, or Segmentation objects.

Saga's specialty: medical imaging integration services →

Explore further