DICOM PS3.4 2024e - Service Class Specifications

Y Composite Instance Root Retrieve Service Class (Normative)

Y.1 Overview

Y.1.1 Scope

Composite Instance Root Retrieve Service is a service within the DICOM Query/Retrieve Service class defined in Annex C.The retrieve capability of this service allows a DICOM AE to retrieve Composite Instances or selected frames from a remote DICOM AE over a single Association or request the remote DICOM AE to initiate a transfer of Composite Object Instances or selected frames from image objects to another DICOM AE.

The Enhanced Multi-Frame Image Conversion Extended Negotiation Option of the DICOM Query/Retrieve Service class defined in Annex C is also supported for the Composite Instance Root Retrieve Service.

Y.1.2 Composite Instance Root Retrieve Information Model

Retrievals are implemented against the Composite Instance Root Retrieve Information Model, as defined in this Annex of the DICOM Standard. A specific SOP Class of the Query/Retrieve Service Class consists of an Information Model Definition and a DIMSE-C Service Group.

Y.1.3 Service Definition

Two peer DICOM AEs implement a SOP Class of the Composite Instance Root Retrieve Service with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Composite Instance Root Retrieve Service are implemented using the DIMSE-C C-MOVE and C-GET services as defined in PS3.7.

The following descriptions of the DIMSE-C C-GET and C-MOVE services provide a brief overview of the SCU/SCP semantics:

  1. A C-MOVE service conveys the following semantics:

    • The SCU supplies Unique and Frame Range Key values to identify the requested SOP Instance(s). The SCP creates new SOP instances if necessary and then initiates C-STORE sub-operations for the corresponding storage SOP Instances. These C-STORE sub-operations occur on a different Association than the C-MOVE service. The SCP role of the Retrieve SOP Class and the SCU role of the Storage SOP Class may be performed by different applications that may or may not reside on the same system. Initiation mechanism of C-STORE sub-operations is outside of the scope of DICOM Standard.

    • The SCP may optionally generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These C-MOVE responses indicate the number of Remaining C-STORE sub-operations and the number of C-STORE sub-operations returning the status of Success, Warning, and Failed.

    • When the number of Remaining C-STORE sub-operations reaches zero, the SCP generates a final response with a status equal to Success, Warning, Failed, or Refused. This response shall indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If any of the sub-operations was successful then a Successful UID list shall be returned. If the status of a C-STORE sub-operation was Failed a UID List shall be returned.

    • The SCU may cancel the C-MOVE service by issuing a C-CANCEL-MOVE request at any time during the processing of the C-MOVE. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.

  2. A C-GET service conveys the following semantics:

    • The SCU supplies Unique and Frame Range Key values to identify the requested SOP Instance(s). The SCP creates new SOP instances if necessary and then generates C-STORE sub-operations for the corresponding storage SOP Instances. These C-STORE sub-operations occur on the same Association as the C-GET service and the SCU/SCP roles are reversed for the C-STORE.

    • The SCP may optionally generate responses to the C-GET with status equal to Pending during the processing of the C-STORE sub-operations. These C-GET responses indicate the number of remaining C-STORE sub-operations and the number of C-STORE sub-operations returning the status of Success, Warning, and Failed.

    • When the number of Remaining C-STORE sub-operations reaches zero, the SCP generates a final response with a status equal to Success, Warning, Failed, or Refused. This response shall indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of any C-STORE sub-operation was Failed a UID List shall be returned.

    • The SCU may cancel the C-GET service by issuing a C-CANCEL-GET request at any time during the processing of the C-GET. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.

DICOM PS3.4 2024e - Service Class Specifications