What is PACS?

PACS meaning in medical imaging

PACS stands for Picture Archiving and Communication System. In medical imaging, a PACS is the software that stores, retrieves, distributes and displays medical images such as CT, MRI, ultrasound and X-ray studies, replacing film archives with a digital archive, a worklist and a viewer. Before PACS, clinics shot film, hung it on a lightbox, and physically moved the film between referring doctors, radiologists and the patient; the digital archive is instead reachable from any authorized workstation over the network.

The same letters mean something else in cardiology: PACs stands for premature atrial contractions, extra heartbeats that start in the atria, the upper chambers of the heart. That is an unrelated medical abbreviation, and this page covers the imaging system, not the heart rhythm. Outside medicine, PAC can also mean political action committee.

The term covers the whole system, not just the screen a radiologist looks at. A PACS is the combination of an archive that stores the images, a network that moves them, and a viewer and worklist that present them for reading. When people search "pacs meaning medical" or "pacs system," they are usually asking about this whole chain, not a single piece of software. At clinic scale the same chain comes in a compact form; see what a mini PACS is for that category.

How a PACS actually works

The flow is the same in almost every clinic, regardless of vendor:

• A modality (the CT, MR, ultrasound or X-ray machine) finishes a scan and sends the study to the archive as DICOM, the standard image format for medical imaging.
• The archive stores the study and indexes it by patient, date, modality and accession number, so it can be found later without scrolling through raw files.
• The study appears on a worklist, the queue radiologists work through to read outstanding cases.
• A viewer opens the study for reading: window/level adjustment, zoom, measurements, multi-series comparison. In some systems, MiniPACS included, the report is attached to the study so it travels with the images on export instead of living in a separate system that can go out of sync.

In a browser-based PACS, none of this requires anything installed on the referring doctor's computer: a study that hits the worklist is reachable from any browser with the right login. Older systems still lean on installed viewers, plugins or a VPN, which is worth checking before buying. To feel the difference, the free DICOM viewer opens a .dcm file straight in the browser, parsing it locally so nothing is uploaded. Either way, the move away from physical film and mailed CDs is the reason PACS exists. The related workflow question is medical image sharing, which covers portals, DICOM transfer and the source archive.

The four classic components of a PACS

Most descriptions of PACS break it into four parts:

• Modality: the imaging hardware (CT, MR, US, X-ray) that produces the DICOM study.
• Archive: the storage layer where studies live, with the audit trail, backups and access control around them.
• Worklist: the queue that organizes studies for reading and tracks status (new, in progress, read).
• Viewer: the workstation or browser software that displays the study for diagnosis and reporting.

Older PACS installations sold these as separate modules, sometimes from different vendors, stitched together with interfaces. Modern PACS more often ship all four as one product, which removes a category of integration bugs and support calls. The display side has its own guide: what a DICOM viewer is covers how the viewer component works and when a standalone viewer is enough on its own.

PACS vs RIS: what is the difference

PACS and RIS get confused constantly because they sit next to each other in the same workflow. A radiology information system (RIS) handles the administrative and clinical-workflow side: scheduling appointments, tracking patient demographics, billing codes, and managing the reporting workflow from dictation to signed report. PACS handles the images themselves: storage, retrieval and display.

Large hospital radiology departments still run RIS and PACS as separate systems, connected over HL7 or a shared database. Smaller imaging centers and clinics increasingly run a combined system where the reporting and worklist functions that used to require a RIS are built into the PACS directly, since most of the RIS workflow a single-location clinic actually needs is the worklist and report attachment, which fit inside a modern PACS without a second license, with booking left to the scheduler or referral portal the clinic already uses. The full breakdown is in RIS vs PACS.

Cloud PACS vs onsite PACS, briefly

A PACS can run in a vendor's cloud, on a server the clinic owns, or on a small onsite machine like a mini PC behind the front desk. Cloud PACS moves the hosting and maintenance burden to the vendor in exchange for a recurring bill that scales with usage. Onsite PACS keeps images on hardware the clinic controls, trading that convenience for owning the box and the backup process. Both approaches use the same DICOM standard and the same basic archive/worklist/viewer structure described above; the difference is where the server physically sits and who pays for what. See the full comparison for the tradeoffs in detail, or the mini PACS guide for small imaging centers if you already know you want to own the archive.

What a PACS costs

Pricing models vary a lot by vendor. Legacy cloud PACS vendors commonly charge per location as a recurring rental, typically somewhere in the $150 to $2,000 a month range depending on study volume, storage and support tier; the clinic never owns anything, and the bill continues for as long as the archive is in use.

The alternative is a flat yearly license instead of a metered rental. MiniPACS, for example, is priced at $300 a month ($3,600 a year) per location as a flat fee regardless of study volume, machines or staff count, with setup from $1,500 one time. Over five years, at a typical $700-a-month cloud PACS bill, renting comes to $42,000 against $38,400 for an owned combo license covering both the archive and a referral portal, roughly the point where renting starts to cost more than owning.

Whichever model a clinic evaluates, the questions worth asking are the same: is the price per study, per user or flat per location; what happens to access if a payment is missed; and who owns the data and the backups. The PACS cost guide works through these pricing models in more detail.

What to look for when choosing a PACS

• DICOM compliance and a clean modality worklist connection, so new machines connect without custom integration work.
• A clear answer on what happens to the archive if the clinic stops paying: read-only access is very different from a hard lockout.
• Who holds the encryption keys and the backups, and whether a copy exists off the vendor's infrastructure.
• Migration support for the existing archive: how studies move in, and whether an interrupted import can resume without starting over.
• Support response time and who is actually reachable when a modality stops sending studies at 8am.

For a side-by-side view of how the main options answer these questions, the roundup of best PACS systems compares the vendors an independent clinic actually shortlists.

Where MiniPACS fits

MiniPACS is a self-hosted PACS built around this same archive/worklist/viewer structure, sold as a flat yearly license rather than a metered rental, and it can run on the clinic's own server, a mini PC, or the clinic's own AWS account. If the archive currently under evaluation is Orthanc, the Orthanc comparison covers the specific tradeoffs of that switch. Otherwise, MiniPACS has the full pricing, security posture and live demo.

FAQ