DICOM PS3.4 2022c - Service Class Specifications

KK Storage Management Service Class

The Storage Management Service Class defines an application-level class-of-service that facilitates peer-to-peer controls for management of persistent storage of Composite SOP Instances. The Service Class allows asynchronous operations between the Service Class User (SCU) and the Service Class Provider (SCP).

KK.1 Overview

KK.1.1 Use Cases

DICOM supports all manner of peer-to-peer interactions for systems within the biomedical imaging domain. In many enterprises, one or more systems are responsible for long-term management of stored SOP Instances. This Service Class supports the interoperability use cases associated with such long-term storage management.

KK.1.2 SOP Classes

Each SOP Class of the Storage Management Service Classis formed from a combination of a common DIMSE Service Group and a specific Information Object Definition.

KK.1.2.1 DIMSE Service Group

The DIMSE-N Services applicable to all SOP Classes of the Storage Management Service Class are shown in Table KK.1-1.

Table KK.1-1. DIMSE Service Group Applicable to Storage Management

DICOM Message Service Element






The DIMSE-N Services and Protocol are specified in Section 10 “DIMSE-N” in PS3.7. Additional constraints on these services, such as specific action and event types, are specified for each SOP Class.

KK.1.2.2 Information Object Definitions

The SOP Classes of the Storage Management Service Class are defined using the IODs specified in Table KK.1-2.

Table KK.1-2. Storage Management Service SOP Classes

SOP Class Name


IOD Specification (defined in PS3.3)

Inventory Creation


Inventory Creation IOD

Additional constraints on these IODs, such as specific Attributes required for the different action types, are specified for each SOP Class.

KK.1.3 Service Protocol

KK.1.3.1 Association Negotiation

Association establishment is the first phase of any instance of communication between peer DICOM AEs. The Association negotiation rules as specified in Annex D “Association Negotiation (Normative)” in PS3.7 are used to negotiate the supported SOP Classes and peer AE roles.


Implementations may restrict Association establishment subject to exchange of security related information, such as application identity and authorization, either within DICOM Association negotiation or outside the scope of the DICOM protocol. See Section YYYY.6 “Security Considerations” in PS3.17.

Support for the SCP/SCU Role Selection Negotiation is mandatory. The SOP Class Extended Negotiation is not defined for this Service Class.

The SCU will open an Association when it desires to request a storage management operation by the SCP.

The SCP will typically open an Association when it is reporting status, or has completed a requested operation or reached some other termination condition, such as a failure. This Association establishment includes negotiation of SCP/SCU role.


  1. The SCP may attempt to issue an N-EVENT-REPORT on the same Association as the initiating N-ACTION, but this operation may fail because the SCU is free to release at any time the Association on which it sent the N-ACTION-Request.

  2. As DICOM defaults the Association-requestor to the SCU role, the SCP (i.e., the Association-requestor) negotiates an SCP role using the SCU/SCP role negotiation (see Section D.3.3.4 “SCP/SCU Role Selection Negotiation” in PS3.7).

  3. When responding on a different Association, the SCP uses the same AE Title as it used on the original Association, because the DICOM Standard defines a Service between two peer applications, each identified by an AE Title. Thus, the SCP should be consistently identified for all transactions with a particular peer in a SOP Class.

KK.1.3.2 Operations and Notifications

Following Association establishment, peer-to-peer communication between the SCU and SCP uses the DIMSE N-ACTION and N-EVENT-REPORT (see Section 10.1 “Services” in PS3.7).

The N-ACTION and N-EVENT-REPORT primitives shall contain the well-known Storage Management SOP Instance specified in Table KK.1-3 in their Requested SOP Instance UID and Affected SOP Instance UID parameters.


In the usage described here, there is no explicit creation of a SOP Instance (using N-CREATE) upon which an N-ACTION may operate. Instead, the N-ACTION operates upon a well-known SOP Instance. This SOP Instance is conceptually created during start-up of each Storage Management Service Class SCP Application.

Table KK.1-3. Storage Management SOP Instance UID

SOP Instance UID

UID Name


Storage Management SOP Instance

The SCP requests a storage management operation using the N-ACTION-Request primitive of one of the Storage Management Service SOP Classes. The request includes a Transaction UID for tracking purposes.

If the SCP accepts the N-ACTION request for processing, it sends a Success N-ACTION Response Status Code. If it does not accept the N-ACTION request for processing, it sends an Error N-ACTION Response Status Code. The actions taken by the SCU upon receiving the status is beyond the scope of this Standard.

At any time after receipt of the N-ACTION-Response, the SCU may release the association on which it sent the N-ACTION-Request.

The SCP notifies the SCU using the N-EVENT-REPORT primitive when it has completed the requested operation or reached some other termination condition, such as a failure or a time-out. The notification includes the Transaction UID of the request. Upon completion or termination, the Transaction UID is no longer active and shall not be reused.

DICOM PS3.4 2022c - Service Class Specifications