DICOM PS3.4 2020a - Service Class Specifications

Y.4 DIMSE-C Service Groups (Current)
Prev | Y Composite Instance Root Retrieve Service Class (Normative) | Next

## Y.4 DIMSE-C Service Groups

A single DIMSE-C Service is used in the construction of SOP Classes of the Composite Instance Root Retrieve Service. The following DIMSE-C operation is used:

- C-MOVE

- C-GET

### Y.4.1 C-MOVE Operation

SCUs of the Composite Instance Root Retrieve Service shall generate retrievals using the C-MOVE operation as described in PS3.7.The C-MOVE operation allows an application entity to instruct another application entity to transfer stored SOP Instances or new SOP Instances extracted from such stored SOP Instances to another application entity using the C-STORE operation. Support for the C-MOVE service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-MOVE in order for a C-MOVE operation to occur over the Association. The C-STORE sub-operations shall always be accomplished over an Association different from the Association that accomplishes the CMOVE operation. Hence, the SCP of the Query/Retrieve Service Class serves as the SCU of the Storage Service Class.

### Note

The application entity that receives the stored SOP Instances may or may not be the originator of the C-MOVE operation.

A C-MOVE request may be performed to any level of the Composite Object Instance Root Retrieve Information Model,and the expected SCP behavior depends on the level selected.

#### Y.4.1.1 C-MOVE Service Parameters

##### Y.4.1.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-MOVE is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-MOVE operation.

##### Y.4.1.1.2 Priority

The Priority Attribute defines the requested priority of the C-MOVE operation and corresponding C-STORE sub-operations with respect to other DIMSE operations being performed by the same SCP.

Processing of priority requests is not required of SCPs. Whether or not an SCP supports priority processing, and the meaning of the different priority levels shall be stated in the Conformance Statement of the SCP. The same priority shall be used for all C-STORE sub-operations.

##### Y.4.1.1.3 Identifier

The C-MOVE request shall contain an Identifier. The C-MOVE response shall conditionally contain an Identifier as required in Section C.4.3.1.3.2.

### Note

The Identifier is specified as U in the definition of the C-MOVE primitive in PS3.7 but is specialized for use with this service.

###### Y.4.1.1.3.1 Request Identifier Structure

An Identifier in a C-MOVE request shall contain:

- the Query/Retrieve Level (0008,0052) that defines the level of the retrieval

- SOP Instance UID(s) (0008,0018)

- One of the Frame Range Keys if present in the Information Model for the level of the Retrieval

- Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has accepted during Association Extended Negotiation. It shall not be included otherwise.

Specific Character Set (0008,0005) shall not be present.

The Keys at each level of the hierarchy and the values allowable for the level of the retrieval shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

##### Y.4.1.1.4 Status

Table Y.4-1 defines the status code values that might be returned in a C-MOVE response. General status code values and fields related to status code values are defined for C-MOVE DIMSE Service in PS3.7.

Table Y.4-1. C-MOVE Response Status Values for Instance Root Retrieve

Service Status | Further Meaning | Status Codes | Related Fields
--- | --- | --- | ---
Failure | Refused: Out of resources - Unable to calculate number of matches | A701 | (0000,0902)
Refused: Out of resources - Unable to perform sub-operations | A702 | (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Refused: Move Destination unknown | A801 | (0000,0902)
Error: Data Set does not match SOP Class | A900 | (0000,0901) (0000,0902)
Failed: Unable to process | Cxxx | (0000,0901) (0000,0902)
Failed: None of the frames requested were found in the SOP Instance | AA00 | (0000,0902)
Failed: Unable to create new object for this SOP Class | AA01 | (0000,0902)
Failed: Unable to extract frames | AA02 | (0000,0902)
Failed: Time-based request received for a non-time-based original SOP Instance. | AA03 | (0000,0902)
Failed: Invalid Request | AA04 | (0000,0901) (0000,0902)
Cancel | Sub-operations terminated due to Cancel Indication | FE00 | (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Warning | Sub-operations Complete - One or more Failures or Warnings | B000 | (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Success | Sub-operations Complete - No Failures or Warnings | 0000 | (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Pending | Sub-operations are continuing | FF00 | (0000,1020) (0000,1021) (0000,1022) (0000,1023)

Some Failure Status Codes are implementation specific.

An SCP implementation shall assign specific failure status codes by replacing each 'x' symbol with a hexadecimal digit in the range from 0 to F. An SCP implementation wishing to differentiate between causes of "Failed: Unable to process" Failure Meaning shall assign those causes specific Status Code Values within valid range specified in Table Y.4-1.

An SCU implementation shall recognize any Failure Status Code within the value range specified in Table Y.4-1 as an indicator of the Failure Meaning stated in the table. There is no requirement for an SCU implementation to differentiate between specific Status Codes within the valid range.

##### Y.4.1.1.5 Number of Remaining Sub-Operations

Inclusion of the Number of Remaining Sub-operations shall be as specified in Section C.4.2.1.6

##### Y.4.1.1.6 Number of Completed Sub-Operations

Inclusion of the Number of Completed Sub-operations shall be as specified in Section C.4.2.1.7

##### Y.4.1.1.7 Number of Failed Sub-Operations

Inclusion of the Number of Failed Sub-operations shall be as specified in Section C.4.2.1.8

##### Y.4.1.1.8 Number of Warning Sub-Operations

Inclusion of the Number of Warning Sub-operations shall be as specified in Section C.4.2.1.9.

#### Y.4.1.2 C-MOVE SCU Behavior

##### Y.4.1.2.1 Baseline Behavior of SCU

An SCU conveys the following semantics with a C-MOVE request:

- If the Retrieve Level (0000,0052) is IMAGE, the SCU shall specify one SOP Instance UID or a list of SOP Instance UIDs.

- If the Retrieve Level (0000,0052) is FRAME, the SCU shall specify the single SOP Instance UID of the item from which the new Composite SOP Instance should be extracted and the requested Frame List. The Requested Frame List shall be constructed as defined in Section Y.3.2.

- The SCU shall accept C-MOVE responses with status equal to Pending during the processing of the C-STORE sub-operations. These responses indicate the number of Remaining, Completed, Failed and Warning C-STORE sub-operations.

- The SCU shall interpret a C-MOVE response with a status equal to Success, Warning, Failure, or Refused as a final response. The final response indicates the number of Completed sub-operations and the number of Failed C-STORE sub-operations resulting from the C-MOVE operation. The SCU shall interpret a status of:

  - Success to indicate that all sub-operations were successfully completed

  - Failure or Refused to indicate all sub-operations were unsuccessful

  - Warning in all other cases. The Number of Completed Sub-Operations (0000,1021), Number of Warning Sub-Operations (0000,1023), Number of Failed Sub-Operations (0000,1022) can be used to obtain more detailed information.

- The SCU may cancel the C-MOVE operation by issuing a C-MOVE-CANCEL request at any time during the processing of the C-MOVE request. A C-MOVE response with a status of Canceled shall indicate to the SCU that the retrieve was canceled. Optionally, the C-MOVE response with a status of Canceled shall indicate the number of Completed, Failed, and Warning C-STORE sub-operations. If present, the Remaining sub-operations count shall contain the number of C-STORE sub-operations that were not initiated due to the C-MOVE-CANCEL request.

### Note

For FRAME level C-MOVE operations, the application receiving the C-STORE sub-operations will receive a new SOP Instance with a different SOP Instance UID from the one included in the C-MOVE request. If it is required to link the received instance to the request, then it may be necessary to inspect the Frame Extraction Sequence of the instance received, to compare the original Instance UID and Requested Frame List to those in the request.

##### Y.4.1.2.2 Extended Behavior of SCU

The extended behavior of the SCU shall be as specified in Section C.4.2.2.2, except that Relational-retrieve shall not be supported.

#### Y.4.1.3 C-MOVE SCP Behavior

##### Y.4.1.3.1 Baseline Behavior of SCP

An SCP conveys the following semantics with a C-MOVE response:

- If the Retrieve Level (0000,0052) is IMAGE the SCP shall identify a set of Entities at the level of the transfer based upon the values in the Unique Keys in the Identifier of the C-MOVE request.

- If the Retrieve Level (0000,0052) is FRAME, the SCP shall create a new Composite Instance according to the rules in section Section Y.3.2. The newly created SOP Instance shall be treated in the same manner as the set of Entities identified above.

- The SCP shall either re-use an established and compatible Association or establish a new Association for the C-STORE sub-operations

- The SCP shall initiate C-STORE sub-operations over the Association for the identified or newly created SOP Instances.

- A sub-operation is considered a Failure if the SCP is required to create new SOP Instance, but is unable to do so due to inconsistencies in the Frame Range Keys, or if the resulting SOP Instance would not be valid.

- Optionally, the SCP may generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These responses shall indicate the number of Remaining, Completed, Failure, and Warning C-STORE sub-operations.

- When the number of Remaining sub-operations reaches zero, the SCP shall generate a final response with a status equal to Success, Warning or Failed. The status contained in the C-MOVE response shall contain:

  - Success if all sub-operations were successfully completed

  - Failure if all sub-operations were unsuccessful

  - Warning in all other cases.

- The SCP may receive a C-MOVE-CANCEL request at any time during the processing of the C-MOVE request. The SCP shall interrupt all C-STORE sub-operation processing and return a status of Canceled in the C-MOVE response. The C-MOVE response with a status of Canceled shall contain the number of Completed, Failed, and Warning C-STORE sub-operations. If present, the Remaining sub-operations count shall contain the number of C-STORE sub-operations that were not initiated due to the C-MOVE-CANCEL request.

- If the SCP manages images in multiple alternate encodings (see Section C.6.1.1.5.1), only one of the alternate encodings of an image shall be used as the existing SOP Instance from which frames are to be extracted.

##### Y.4.1.3.2 Extended Behavior of SCP

The extended behavior of the SCP shall be as specified in Section C.4.2.3.2, except that Relational-retrieve shall not be supported.

Prev | Up | Next
Y.3.3 New Instance Creation At the Frame Level | Home | Y.4.2 C-GET Operation

DICOM PS3.4 2020a - Service Class Specifications