PACS and DICOM Basics for Radiologic Technologists

Why PACS and DICOM Matter to Every Rad Tech

As a radiologic technologist, your primary focus is on positioning, exposure factors, and patient care. The imaging objects you create also pass through a digital workflow before interpretation. Understanding PACS and DICOM supports safe patient identification, image availability, and appropriate troubleshooting.

Whether you work in a large hospital system with a fully integrated enterprise PACS or a small clinic with a mini-PACS attached to a single DR unit, the principles are the same. Your images must be acquired, formatted, transmitted, stored, retrieved, and displayed correctly. When a study fails to appear on the radiologist's worklist, the technologist who understands the system can often solve the problem before it requires an IT ticket.

This guide covers practical PACS and DICOM fundamentals, from identifiers and compression to RIS-PACS integration, security, downtime, and connectivity problems.

What Is PACS? The Three Core Components

PACS stands for Picture Archiving and Communication System. It is the hardware and software infrastructure that enables digital medical images to be acquired from modalities, stored on servers, transmitted across networks, and displayed on workstations — all without film.

Every PACS has three essential subsystems:

These components communicate through interfaces that may include DICOM DIMSE services, DICOMweb, and other integration standards. A vendor-neutral archive (VNA) is an archive strategy, not a viewer. A zero-footprint viewer is a browser-based viewing application; whether and where it may be used for diagnosis depends on its intended use, display environment, validation, and facility policy.

Types of PACS by Scale

Not all PACS are created equal. You will encounter different configurations depending on the size of your facility:

• Enterprise PACS: A hospital-wide system connecting all modalities, all departments, and multiple sites. Usually features vendor-neutral archiving (VNA), advanced reporting tools, and deep RIS/EMR integration. Found in large hospitals and health systems.
• Mini-PACS: A modality-specific or department-scale system, such as a CT mini-PACS or ultrasound mini-PACS. Often used in specialty clinics or as a temporary solution in smaller departments.
• Cloud-hosted PACS: Some or all services run in remotely hosted infrastructure. Availability, latency, bandwidth, identity/access management, encryption, contractual safeguards, backup, recovery, and an approved downtime path all require planning.
• Vendor-Neutral Archive (VNA): An archive intended to reduce dependence on a particular PACS vendor by storing and exposing imaging objects through standardized interfaces. A PACS replacement can still require testing, reconciliation, and data or metadata migration.

What Is DICOM? The Language of Medical Imaging

DICOM (Digital Imaging and Communications in Medicine), published internationally as ISO 12052, specifies medical-imaging information objects and communication services. It provides a foundation for multi-vendor exchange, but a DICOM label alone does not guarantee plug-and-play interoperability: systems must support compatible SOP Classes, SCU/SCP roles, transfer syntaxes, security options, and workflow profiles. Compare vendors' DICOM conformance statements and test the configured workflow.

Every DICOM-compliant device — whether it is a CT scanner, DR detector, CR reader, ultrasound machine, MRI scanner, or nuclear medicine gamma camera — implements a specific set of DICOM services. The most important ones for rad techs are:

• DICOM Storage (C-STORE): Transfers a DICOM SOP Instance from a Storage SCU (sender) to a Storage SCP (receiver). A successful C-STORE response confirms the receiver accepted that operation; it does not by itself promise durable archival. Storage Commitment is the separate service by which another system commits to safekeeping specified instances for an implementation-defined period and retrieval capability documented in its conformance statement.
• DICOM Query/Retrieve (C-FIND plus C-MOVE or C-GET): C-FIND queries an information model. C-MOVE asks the archive to send matching instances to a named destination; C-GET returns instances over the same association. Support is declared in each product's DICOM conformance statement.
• Modality Worklist (MWL; C-FIND): Allows an acquisition device to query a worklist SCP—often populated from the RIS/order-filler workflow—and select scheduled procedure data. This reduces re-keying but does not eliminate the technologist's obligation to verify the patient and order.
• DICOM Print Management: Uses normalized DIMSE services such as N-CREATE, N-SET, and N-ACTION to manage print jobs on a conforming printer. There is no DICOM command named “C-PRINT.”
• Modality Performed Procedure Step (MPPS): Reports performed-step information and state (IN PROGRESS, COMPLETED, or DISCONTINUED) from an MPPS SCU to an MPPS SCP. The receiver may be a RIS, broker, PACS, or other workflow system.

DICOM Information Model: Patient → Study → Series → Instance

DICOM organizes image data in a hierarchical model with four levels. Understanding this hierarchy is critical for navigating any PACS:

DICOM uses UIDs for entities such as studies, series, and SOP instances. Conforming UID generators are responsible for global uniqueness. The patient level is normally matched with Patient ID plus its assigning authority/issuer—not a Study/Series/SOP UID—and Patient ID alone is not necessarily unique across organizations.

DICOM Tags: The Metadata Behind Every Image

A DICOM Data Set is a sequence of data elements identified by hexadecimal group and element numbers. Depending on the SOP Class, elements may describe the patient, procedure, acquisition, pixels, waveforms, measurements, or other content; not every DICOM object contains Pixel Data. A DICOM file also has a file preamble/prefix and File Meta Information, whereas a Data Set exchanged over a network is not necessarily a Part 10 file. For example, Patient's Name is (0010,0010), and Modality is (0008,0060).

These example data elements illustrate identifiers, demographics, acquisition context, and display parameters:

RIS-PACS Integration: How Images and Data Flow Together

In an integrated imaging department, a RIS or other order-filler system may support scheduling, procedure tracking, reporting, and result distribution, while PACS manages imaging objects and reading workflow. Interfaces vary: HL7 v2 or newer health-information standards often carry orders, demographics, and results; DICOM supports imaging objects and imaging workflow services. DICOM is not limited to pixels, and HL7 is not simply “text data.”

Here is how a typical exam flows from order to report:

1. Order Entry: An authorized clinician enters an imaging order in the EHR/order-entry system. An order filler assigns or supplies an Accession Number whose uniqueness scope is defined by its issuer.
2. Modality Worklist Query (DICOM MWL): The CT scanner queries a MWL SCP and the technologist selects the correct Scheduled Procedure Step. Relevant patient, order, and procedure attributes populate the acquisition workflow, reducing re-keying.
3. Exam Performed (Modality): The technologist performs the scan. Image data is generated along with DICOM tags containing the patient and study information.
4. Object Transfer (DICOM C-STORE): The modality transfers SOP Instances to a configured Storage SCP. Local policy may also require instance-count reconciliation and/or successful Storage Commitment before the modality copy can be deleted.
5. Performed-Step Update: MPPS can report performed procedure details and state to an MPPS SCP; separate messages may update order/result workflow. Successful MPPS and successful image storage are distinct events.
6. Interpretation: An authorized interpreting clinician reviews the study on an appropriate display system and creates a report using the facility's reporting workflow.
7. Result Distribution: The verified report and access to images are made available through configured EHR/RIS/PACS interfaces, subject to access controls.

Image Compression: Lossless vs Lossy

Imaging study size varies widely with modality, matrix, bit depth, frame count, reconstructions, and associated objects. Compression can reduce storage and transfer demands, but fixed study-size or daily-volume estimates are not reliable across protocols and facilities.

DICOM supports two types of compression:

JPEG Lossless, Non-Hierarchical, First-Order Prediction uses Transfer Syntax UID 1.2.840.10008.1.2.4.70. DICOM also defines other compressed and uncompressed transfer syntaxes. It does not require every modality or PACS to support a compressed lossless syntax, and it explicitly leaves the clinical acceptability and parameter selection for lossy compression outside the standard. Consult each product's conformance statement and the facility's validated policy. When irreversible compression has occurred, required DICOM attributes such as Lossy Image Compression, Ratio, and Method provide provenance; later lossless encoding does not restore discarded information.

Troubleshooting Common PACS Connectivity Issues

PACS workflows can encounter transfer, routing, reconciliation, and performance problems. The checks below are general; product messages and local procedures take precedence.

"Send Failed" on the Modality Console

The message may reflect association, negotiation, timeout, network, authentication, transfer-syntax/SOP-class, or receiver errors; it does not diagnose one cause. Preserve the local images and error details. Check the destination AE title, host/port, network status, send queue, and receiver status only within your role, then retry according to local procedure or escalate. Do not re-expose the patient merely because transfer failed. A successful C-STORE response is also not Storage Commitment; use the facility's required reconciliation/commitment check before deleting the modality copy.

Study Missing from Radiologist's Worklist

The sender reports success, but the study is absent from a reading worklist. Checklist: (1) Using an approved status/query tool, verify the expected destination received every instance. (2) Check patient, Study Instance UID, Accession Number/issuer, procedure, and routing/reconciliation status. (3) Have authorized staff investigate exceptions such as an incorrect merge/split, hold, or unmatched order. (4) Check whether the reading worklist's filters exclude the study. A study can be stored correctly yet omitted from a workflow list.

Wrong Patient Information Visible

Another patient's data on a study is a patient-safety and privacy event. Stop the normal workflow and report it immediately under facility policy. Do not delete, edit, merge, split, or resend objects unless authorized and trained to use the site's reconciliation process. Correction may use PACS/RIS exception-management tools while preserving provenance and audit history; deletion and resend are not universally required and can create additional risk.

Slow Image Loading

Loading time can be affected by study size, server load, network path, retrieval tier, routing/prefetch rules, viewer cache, decompression, and workstation performance. Record the affected study, device, time, and error/latency pattern, then follow local troubleshooting and escalation procedures. Do not change network QoS, server, or diagnostic-display configuration unless that is within your assigned role.

Display, Privacy, Security, Retention, and Downtime

• Display: DICOM PS3.14 defines the Grayscale Standard Display Function (GSDF) for consistent grayscale response; it does not by itself certify a monitor for every diagnostic task. Use displays, ambient lighting, calibration, acceptance testing, and quality control appropriate to the intended use and facility policy. Do not assume a browser viewer or an uncalibrated clinical display is equivalent to a diagnostic workstation.
• Privacy and security: DICOM compatibility does not make a connection secure. DICOM PS3.15 specifies security and system-management profiles, including secure transport and audit-related profiles, but products must implement and configure them. Apply unique accounts, least-necessary access, approved secure channels, screen locking, audit logging, patch/change controls, and incident reporting under organizational policy. Never export identifiable studies to personal devices, consumer messaging, or unapproved cloud services.
• Retention: DICOM does not prescribe how long images must be kept. In the United States, HIPAA does not set a medical-record retention period; state law, other federal/program rules, accreditation requirements, contracts, litigation holds, and facility policy may apply. HIPAA does require specified Security Rule documentation to be retained for six years, which is a different requirement from image-record retention.
• Downtime: HIPAA contingency planning includes data backup, disaster recovery, and emergency-mode operation planning for systems containing electronic protected health information. Technologists should know the approved downtime identifiers/order process, where images queue, how urgent interpretation is obtained, who may correct demographics, and how studies, orders, MPPS/status, and reports are reconciled after recovery. Preserve local image copies until transfer and any required commitment/reconciliation are confirmed.
• Scope: Technologists verify identity/order data, select the correct worklist item, monitor queues, document errors, and escalate under policy. PACS administration, record amendment/deletion, server/network changes, security configuration, and determination of diagnostic acceptability or retention generally require specifically authorized personnel and organizational governance.

Key PACS and DICOM Terms

Use these concise definitions to review the workflow:

• DICOM: Digital Imaging and Communications in Medicine — the standard for medical image exchange.
• PACS: Picture Archiving and Communication System — manages storage, retrieval, distribution, and display of imaging objects.
• RIS: Radiology Information System — supports radiology administrative and clinical workflow; exact functions vary.
• HL7: A family of standards for exchanging and integrating electronic health information; HL7 v2 messaging is commonly used in radiology workflows.
• Modality Worklist (MWL): DICOM C-FIND service by which an acquisition device queries a worklist SCP for Scheduled Procedure Steps.
• Accession Number: An identifier for an imaging service request whose uniqueness scope is defined by its issuer.
• UID (Unique Identifier): A globally unique numeric string used to identify DICOM entities such as studies, series, SOP classes, and SOP instances.
• Lossless Compression: Compression from which original pixel values can be reconstructed exactly.
• Lossy Compression: Irreversible compression; clinical use requires validated policy rather than an assumption that discarded information is nonessential.
• Query/Retrieve: DICOM services that commonly use C-FIND to query and C-MOVE or C-GET to retrieve matching instances.
• Storage Commitment: A service that confirms commitment to safekeeping specified SOP Instances under the SCP's documented duration and retrieval terms; it is distinct from a successful C-STORE transfer.
• VNA (Vendor-Neutral Archive): An archive intended to reduce vendor dependence through standardized storage and access interfaces; “neutral” does not eliminate compatibility testing or migration work.
• MPPS (Modality Performed Procedure Step): DICOM service for reporting performed-step details and state to an MPPS SCP.

Authoritative References

• DICOM PS3.3 — Information Object Definitions
• DICOM PS3.4 — Service Class Specifications (Storage, Query/Retrieve, MWL, MPPS, and Storage Commitment)
• DICOM PS3.5 — Data Structures and Encoding (transfer syntaxes and compression)
• DICOM PS3.14 — Grayscale Standard Display Function
• DICOM PS3.15 — Security and System Management Profiles
• HHS OCR — HIPAA Security Rule
• HHS OCR FAQ — HIPAA and medical-record retention
• 45 CFR § 164.308 — Administrative safeguards (including contingency planning)
• 45 CFR § 164.316 — Policies, procedures, and documentation requirements