SCU (Service Class User)

The SCU is the client in a DICOM network transaction. It actively opens a TCP/IP Association to a listening SCP. The SCU's role is defined by the operation it requests: a PACS workstation acts as an SCU when it sends a C-FIND request to query a study, or a modality acts as an SCU when it uses a C-STORE command to push images to an archive. The SCU always sends the first command message after the association is established.

Before any operation, the SCU must propose a set of capabilities to the SCP. This handshake includes:

• SOP Classes: The specific operations the SCU wants to perform (e.g., CT Image Storage).
• Transfer Syntaxes: The encoding rules it supports (e.g., JPEG Lossless, Explicit VR Little Endian).
• Maximum PDU Length: The largest data packet size it can receive. The SCP selects from these proposals, and the SCU must respect the negotiated terms for the session's duration.

The SCU's behavior is strictly defined by the DIMSE command it issues:

• C-STORE SCU: Pushes a composite SOP Instance to an SCP. The SCU retains responsibility for the data until a successful response is received.
• C-FIND SCU: Sends a query with matching keys and must be prepared to receive multiple, paginated responses from the SCP.
• C-MOVE SCU: Requests the SCP to initiate a separate C-STORE sub-operation to a third-party Destination AE. The SCU here is instructing the SCP to act as a C-STORE SCU to another system.
• C-ECHO SCU: Sends a simple verification request to test network connectivity and association capability.

An SCU's exact capabilities are documented in its DICOM Conformance Statement. This document is the definitive source for integration, detailing:

• The complete list of SOP Class UIDs it can request as an SCU.
• The specific Transfer Syntaxes it proposes for each SOP Class.
• Any specializations or limitations, such as maximum query results or specific attribute handling. Integration engineers must compare the SCU's conformance statement with the SCP's to ensure a compatible intersection of supported services.

A classic SCU scenario is a CT scanner querying a Modality Worklist SCP. The scanner (SCU) initiates a C-FIND request to the RIS broker (SCP) using the Scheduled Procedure Step SOP Class. It sends matching keys like Patient ID or Accession Number. The SCP returns the patient demographics and procedure details, which the SCU then uses to populate the DICOM header of the subsequent acquired images, eliminating manual technologist entry and reducing error rates.

A single Application Entity (AE) can simultaneously function as both an SCU and an SCP, depending on the operation. A PACS archive is an SCP for incoming C-STORE requests from modalities, but it acts as an SCU when it initiates a C-MOVE to forward studies to a reporting workstation. The roles are defined per-association, not per-system. This duality is fundamental to designing a DICOM network topology where data flows are initiated by the consumer.