| DICOM PS3.4 2024e - Service Class Specifications |
|---|
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).
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.
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.
The DIMSE-N Services applicable to all SOP Classes of the Storage Management Service Class are shown in Table KK.1-1.
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.
The SOP Classes of the Storage Management Service Class are defined using the IODs specified in Table KK.1-2.
Additional constraints on these IODs, such as specific Attributes required for the different action types, are specified for each SOP Class.
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.
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.
As DICOM defaults the Association-requestor to the SCU role, the SCP (i.e., the Association-requestor) negotiates an SCP role using the SCP/SCU Role Selection Negotiation (see Section D.3.3.4 “SCP/SCU Role Selection Negotiation” in PS3.7).
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.
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.
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 an N-ACTION Success Response status. If it does not accept the N-ACTION request for processing, it sends an N-ACTION Failure Response status. 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 2024e - Service Class Specifications |
|---|