DICOM Protocol

Established in 1993 through a joint committee of the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA), Digital Imaging and Communications in Medicine (DICOM) is the international standard explicitly designed for handling, storing, printing, and transmitting medical imaging information.

DICOM is not merely an image format; it is a comprehensive specification that defines both a file structure and a complex network communications protocol operating over TCP/IP. DICOM is highly specialized, utilized primarily by radiology, cardiology, and other imaging-intensive medical disciplines.

Historical Evolution of DICOM

The DICOM standard evolved from earlier ACR-NEMA standards developed in the 1980s. Understanding this evolution provides context for why certain legacy behaviors persist in modern implementations.

DICOM defines numerous Information Object Definition (IOD) classes, each specifying the structure and attributes for a particular type of medical image or object. Each IOD defines which attributes are required, optional, or conditional.

When a modality acquires an image, it creates a DICOM object conforming to the appropriate IOD. This ensures that any DICOM-compliant workstation can correctly interpret the image regardless of manufacturer.

A standard DICOM file (often referred to as a DICOM Part 10 object) is unique because it inextricably binds the visual data with its clinical context.

It encapsulates the massive binary pixel data of the medical scan alongside highly structured, embedded metadata known as the DICOM header. This header contains hundreds of specific tags that dictate patient demographics, unique identifiers, the specific settings of the imaging modality during the scan, spatial orientation vectors, and radiation dose metrics.

DICOM Tag Structure

DICOM tags follow a standardized format: (GGGG,EEEE) where GGGG is the group number and EEEE is the element number. Each tag has a Value Representation (VR) defining the data type and a Value Multiplicity (VM) specifying how many values can be stored.

Understanding tag structure is critical for Australian healthcare architects implementing de-identification pipelines. Tags containing Protected Health Information (PHI) must be identified and either removed, replaced, or encrypted according to DICOM Part 15 Basic Application Level Confidentiality Profile.

To move these massive binary files across the hospital network, DICOM relies on a specific set of network transactions known as the DICOM Message Service Element (DIMSE). These application-layer commands dictate how different nodes (such as the modality, the router, and the archive) interact.

DIMSE Service Classes

DIMSE operations are organized into service classes, each defining a specific type of interaction between DICOM nodes. Understanding these service classes is essential for configuring PACS network topology and troubleshooting connectivity issues.

SCU and SCP Roles

Every DICOM communication involves two roles: the Service Class User (SCU) initiates the request, and the Service Class Provider (SCP) responds to it. For example, when a modality sends images to PACS, the modality acts as SCU (C-STORE initiator) and PACS acts as SCP (C-STORE receiver). These roles are defined in each device's DICOM Conformance Statement.

C-MOVE vs C-GET: Push vs Pull Retrieval Models

Both C-MOVE and C-GET are used to retrieve studies from a PACS archive, but they operate on fundamentally different models with distinct use cases:

DIMSE-C vs DIMSE-N: Composite vs Normalized Services

DICOM defines two families of DIMSE operations with different data handling characteristics:

• DIMSE-C (Composite): Operations that act on complete, persistent DICOM objects (IODs). Includes C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO, and N-CREATE. These services transfer or manipulate entire DICOM instances with all pixel data and metadata intact.
• DIMSE-N (Normalized): Operations that act on managed objects or attributes within the DICOM network management framework. Includes N-GET, N-SET, N-ACTION, N-CREATE, and N-EVENT-REPORT. These services are used for workflow management, device monitoring, and status notifications rather than image transfer.

N-Event-Report and MPPS Workflow

The Modality Performed Procedure Step (MPPS) service utilizes DIMSE-N N-Event-Report operations to provide real-time workflow visibility across the imaging enterprise. MPPS enables modalities to broadcast status changes without requiring polling from the RIS:

• IN PROGRESS: Sent when the modality begins acquiring images for a scheduled procedure
• DISCONTINUED: Sent if the procedure is aborted before completion (e.g., patient movement, equipment failure)
• COMPLETED: Sent when all planned images have been acquired and the procedure is finished

MPPS notifications enable the RIS to update examination status in real-time, trigger downstream workflows (such as notifying radiologists that studies are ready for interpretation), and provide accurate billing codes based on actual procedures performed.

Storage Commitment: Safe Deletion Handshake

Storage Commitment is a critical DIMSE-N service that provides modalities with cryptographic assurance that images have been durably archived before local deletion. This handshake prevents catastrophic data loss:

• Modality sends C-STORE commands to push images to PACS archive
• After all C-STORE operations complete, modality sends N-ACTION (Storage Commitment Request) containing the Study Instance UIDs of all images requiring commitment
• PACS archive validates that all referenced images are durably stored (not queued or in transit)
• PACS returns N-ACTION-RSP with success status if all images are confirmed, or failure with specific UIDs that failed
• Only upon receiving success does the modality safely delete images from its limited local storage

Before any DICOM images can be transmitted, two DICOM nodes must establish a formal network association. This handshake protocol ensures both parties agree on communication parameters, supported operations, and data formats before exchanging any clinical data.

Association Establishment (A-ASSOCIATE)

The association lifecycle begins when the Service Class User (SCU) sends an A-ASSOCIATE-RQ (request) to the Service Class Provider (SCP). This request contains critical negotiation parameters including the Application Context Name, calling and called AE Titles, and most importantly, the Proposed Presentation Contexts.

Each Proposed Presentation Context specifies a single Abstract Syntax (representing a DICOM service class like C-STORE or C-FIND) along with a list of acceptable Transfer Syntaxes (compression formats). The SCP evaluates each proposed context and responds with an A-ASSOCIATE-AC (accept) indicating which contexts are accepted, or an A-ASSOCIATE-RJ (reject) if no common ground can be established.

Data Transfer Phase

Once the association is established, the SCU can initiate DIMSE operations within the bounds of the accepted presentation contexts. Each DIMSE command (C-STORE, C-FIND, C-MOVE, etc.) is sent as a command set followed by optional data payloads. The SCP processes each request and returns appropriate responses with status codes indicating success, failure, or pending status.

Association Release (A-RELEASE)

When data transfer is complete, either party can initiate a graceful termination by sending an A-RELEASE-RQ. The receiving party acknowledges with an A-RELEASE-RP, and the TCP connection is closed. This graceful release ensures both parties agree that all pending operations have completed successfully.

Error Conditions (A-ABORT and A-P-ABORT)

Two types of abort conditions can terminate an association prematurely:

• A-ABORT: Initiated by the DICOM application layer when a protocol violation occurs, such as receiving an unexpected command, invalid PDU structure, or unrecoverable error during data transfer. The abort source provides a reason code to aid troubleshooting.
• A-P-ABORT: Generated by the lower-layer TCP/IP protocol when the underlying network connection fails unexpectedly, such as network cable disconnection, server crash, or timeout. No graceful cleanup is possible.

DICOM State Machine

The DICOM association lifecycle follows a deterministic state machine defined in DICOM Part 8. The key states include:

• Sta1 (Idle): Initial state, no association exists
• Sta2 (Transport Connection Open): TCP connection established, awaiting A-ASSOCIATE
• Sta3 (Association Established): Ready for DIMSE operations
• Sta4 (Awaiting Release Response): A-RELEASE-RQ sent, awaiting acknowledgment
• Sta13 (Awaiting Release): A-RELEASE-RQ received, preparing to release
• Sta14 (Release Collision): Both parties requested release simultaneously

Every DICOM network communication involves two distinct roles that define which party initiates requests and which party responds. Understanding these roles is essential for configuring DICOM network topology, troubleshooting connectivity issues, and designing cloud migration architectures.

Service Class User (SCU) and Service Class Provider (SCP)

The DICOM standard defines two complementary roles for network communications:

• Service Class User (SCU): The client or initiator that sends DIMSE requests. The SCU opens the TCP connection, sends the A-ASSOCIATE-RQ, and initiates operations like C-STORE, C-FIND, or C-MOVE.
• Service Class Provider (SCP): The server or responder that receives and processes DIMSE requests. The SCP listens for incoming associations, responds to A-ASSOCIATE-RQ with A-ASSOCIATE-AC or A-ASSOCIATE-RJ, and executes the requested operations.

Common Device Roles in Clinical Workflows

Role Negotiation During Association

During the A-ASSOCIATE negotiation phase, the SCU and SCP establish which roles each party will play for the duration of the connection. The SCU proposes presentation contexts that implicitly define its role (e.g., proposing C-STORE Abstract Syntax indicates SCU will send images). The SCP accepts or rejects each context based on its configured capabilities.

A single association can support bidirectional operations if both parties accept presentation contexts for complementary roles. For example, a workstation might establish an association with PACS where the workstation is SCU for C-FIND (querying) but SCP for C-STORE (receiving retrieved images).

DICOM Conformance Statements and Roles

Every DICOM-compliant device must publish a DICOM Conformance Statement (DCS) that explicitly documents its supported SCU and SCP roles. The DCS specifies:

• Which service classes the device supports as SCU (initiator)
• Which service classes the device supports as SCP (responder)
• Supported Abstract Syntaxes and Transfer Syntaxes for each role
• Maximum PDU size, association limits, and timeout configurations
• Private extensions or vendor-specific implementations

Before integrating any new device into your Australian healthcare network, thoroughly review the DCS to ensure role compatibility with existing infrastructure. For example, if your PACS only supports C-MOVE (not C-GET), ensure all workstations are configured to use C-MOVE for retrieval.

In real-world clinical environments, DICOM and HL7 operate in tight synchronization to deliver seamless patient care. DICOM manages the diagnostic images while HL7 manages the administrative and clinical data. This integration follows the IHE Scheduled Workflow (SWF) profile, which defines how these protocols interoperate across eight distinct steps.

The 8-Step Integrated DICOM+HL7 Workflow

The complete end-to-end workflow from clinician order to final report delivery:

1. Clinician Enters Request in HIS/EHR: A physician orders an imaging examination (e.g., CT chest with contrast) through the Hospital Information System or Electronic Health Record. The order includes patient demographics, clinical indications, and urgency level.
2. HIS → HL7 ORM → RIS: The HIS translates the clinical order into an HL7 ORM^O01 (Order Message) and transmits it to the Radiology Information System. The ORM message contains patient ID, name, date of birth, ordered procedure code (CPT/ICD-10), and clinical priority.
3. RIS Populates DICOM Modality Worklist (MWL): The RIS parses the HL7 ORM message and populates its internal scheduling database. This database is exposed as a DICOM Modality Worklist, which modalities can query to retrieve scheduled patients without manual data entry.
4. Modality C-FIND Queries MWL: The CT or MRI technologist selects the patient from the modality's local interface. The modality sends a DICOM C-FIND request to the RIS Modality Worklist SCP, retrieving accurate patient demographics and exam parameters. This eliminates dangerous typographical errors from manual entry.
5. Technician Performs Scan, Modality Creates DICOM File: After verifying patient identity, the technologist performs the scan. The modality acquires the raw imaging data and constructs a DICOM Part 10 file, binding the binary pixel data with structured metadata (patient info, acquisition parameters, spatial orientation).
6. Modality C-STORE to PACS + MPPS to RIS: The modality initiates two parallel operations: (1) DICOM C-STORE pushes the images to the PACS archive for permanent storage, and (2) DICOM N-EVENT-REPORT (MPPS) sends an "IN PROGRESS" then "COMPLETED" status to the RIS. The PACS may respond with Storage Commitment to confirm durable storage.
7. Radiologist C-MOVE Images, Reviews, Dictates: The radiologist opens the diagnostic workstation and queries the PACS using DICOM C-FIND. After locating the study, the workstation initiates C-MOVE to retrieve images. The radiologist reviews the images, formulates findings, and dictates a report through the RIS interface.
8. RIS → HL7 ORU → EHR (Closing the Loop): The RIS formats the finalized radiology report into an HL7 ORU^R01 (Observation Result) message and transmits it back to the EHR. The report becomes part of the patient's permanent longitudinal health record, visible to the referring physician and, under Australia's 2026 mandate, to the patient via My Health Record.

Workflow Diagram

The following diagram illustrates the data flow between systems:

Australian 2026 Share-by-Default Mandate Impact

Commencing 1 July 2026, the Australian Government's Health Legislation Amendment (Modernising My Health Record: Sharing by Default) Act 2025 mandates that all diagnostic imaging reports must be uploaded to My Health Record by default. This legislation impacts step 8 of the workflow:

• Basic X-ray reports (limbs): Immediately visible to patients upon upload
• Advanced imaging reports (CT, MRI, PET): Five-day delay before patient access (reduced from previous seven days)
• Software conformance: RIS systems must conform to ADHA B2B gateway standards to transmit reports
• Exceptions: Only permitted for explicit patient opt-outs or documented technical outages

HL7 v2 to FHIR Migration

While most Australian hospitals currently use HL7 v2.x for steps 2 and 8, the industry is transitioning to FHIR (Fast Healthcare Interoperability Resources) for modern API-based integrations. FHIR provides:

• RESTful HTTP APIs instead of pipe-delimited TCP messages
• JSON/XML data formats instead of HL7 v2.x segment structures
• Granular resource-level access (Patient, DiagnosticReport, ImagingStudy resources)
• Native support for mobile and web applications

AWS HealthLake provides FHIR R4-compliant storage and querying, enabling integration engines like Mirth Connect to transform HL7 v2 messages to FHIR resources for cloud-native workflows.

Transfer Syntax defines how DICOM data is encoded for transmission, including byte ordering, VR encoding, and compression. During association negotiation, DICOM nodes agree on a common transfer syntax before exchanging images.

The choice of transfer syntax significantly impacts storage costs and network bandwidth. Lossless compression preserves diagnostic quality while reducing file size, whereas lossy compression achieves higher compression ratios at the cost of some image fidelity.

HTJ2K: The Cloud-Native Transfer Syntax

High-Throughput JPEG 2000 (HTJ2K), standardized as transfer syntax 1.2.840.10008.1.2.4.201, represents a breakthrough for cloud-based medical imaging. Unlike traditional JPEG 2000, HTJ2K supports incremental decoding, enabling progressive image rendering without full decompression.

AWS HealthImaging moves away from legacy TCP/IP DIMSE commands and instead offers native representations of standard DICOMweb APIs. Specifically, HealthImaging supports Web Access to DICOM Persistent Objects (WADO-RS) for image retrieval and Query based on ID for DICOM Objects (QIDO-RS) for metadata searching.

By utilizing HTJ2K encoding, HealthImaging supports progressive resolution data access. When a clinician opens a viewer, the application utilizes DICOMweb APIs to request only the Tile Level Markers (TLM)—lower-resolution representations—which are transmitted and rendered almost instantly. As the radiologist zooms in, the viewer progressively loads the full-fidelity pixels only for the targeted area.

Why DICOMweb Replaces DIMSE for Cloud Deployments

Traditional DIMSE protocols were designed for localized hospital LANs in the 1990s. When forced to operate over modern wide-area internet connections required for cloud PACS, DIMSE exhibits critical limitations that DICOMweb resolves:

Progressive Loading with HTJ2K

High-Throughput JPEG 2000 (HTJ2K) is the breakthrough compression codec that enables DICOMweb's sub-second retrieval promises. Unlike traditional JPEG or even baseline JPEG 2000, HTJ2K supports incremental decoding through Tile Level Markers (TLM):

• Initial Request: Viewer requests only TLM data (typically 50-100 KB per frame), rendering a low-resolution preview in milliseconds
• Progressive Refinement: As radiologist pans/zooms, viewer requests additional resolution layers via HTTP Range requests
• Full Fidelity On-Demand: Full-resolution pixels are only downloaded for regions actually viewed, reducing total bandwidth by 60-80%
• Lossless Guarantee: HTJ2K is mathematically lossless—full diagnostic quality is preserved when all layers are decoded

AWS HealthImaging automatically converts all ingested DICOM files to HTJ2K format during the import process, achieving up to 40% storage cost reduction while enabling this progressive loading capability.

AWS HealthImaging DICOMweb Support

AWS HealthImaging provides native, fully-managed DICOMweb endpoints that eliminate the need to operate your own DICOMweb gateway:

• WADO-RS (Web Access to DICOM Persistent Objects): Retrieve individual frames, series, or complete studies via HTTPS GET requests. Supports range requests for partial retrieval and HTJ2K progressive decoding.
• QIDO-RS (Query based on ID for DICOM Objects): Search for studies, series, and instances using RESTful queries filtered by patient ID, study date, modality, or any DICOM metadata attribute. Returns JSON-formatted results without downloading pixel data.
• STOW-RS (Store Over The Web): Upload DICOM objects via HTTP POST requests. Enables direct ingestion from web applications, mobile devices, or edge gateways without requiring DIMSE C-STORE infrastructure.
• BulkData Access: Recently added support for efficient bulk retrieval of multiple images or entire studies, optimized for AI/ML training pipelines and research workflows.

DICOMweb API Services

DICOMweb (DICOM Part 18) defines three core RESTful services that enable modern web-based medical imaging workflows:

• WADO-RS (Web Access to DICOM Persistent Objects): Retrieves images and metadata via HTTP GET requests. Supports range requests for partial retrieval, enabling progressive rendering.
• QIDO-RS (Query based on ID for DICOM Objects): Searches for studies, series, and instances using RESTful queries. Returns metadata in JSON or XML format without downloading pixel data.
• STOW-RS (Store Over The Web): Uploads DICOM objects to the archive via HTTP POST. Enables direct ingestion from web applications and mobile devices.

For Australian healthcare organizations, DICOMweb is particularly valuable because it operates over standard HTTPS, traversing firewalls and network address translation (NAT) devices without requiring complex VPN configurations. This enables secure teleradiology workflows from remote clinics connected via Starlink or NBN.

Every DICOM-compliant device must publish a DICOM Conformance Statement (DCS), a detailed technical document describing the device's DICOM capabilities. The DCS is essential for system integration and troubleshooting.

Before integrating any new modality, PACS, or workstation into your Australian healthcare network, thoroughly review the DCS to ensure compatibility with existing infrastructure and cloud services.

Key Conformance Statement Components

IHE Integration Profiles

The Integrating the Healthcare Enterprise (IHE) initiative defines integration profiles that specify how DICOM and HL7 should be combined to support specific clinical workflows. Common radiology profiles include:

• Scheduled Workflow (SWF): Coordinates patient scheduling, image acquisition, and report distribution
• Post-Processing Workflow (PPW): Manages 3D reconstruction and advanced visualization
• Import Reconciliation Workflow (IRWF): Handles external studies and prior image reconciliation
• Consistent Presentation of Images (CPI): Ensures images display consistently across workstations

Understanding the distinct responsibilities of DICOM and HL7 is critical when designing cloud migration strategies. In simple architectural terms, DICOM is responsible for managing the diagnostic image, while HL7 is responsible for managing the administrative data of the patient.

For further reading on DICOM protocol and specifications: