DICOM PS3.4 2016e - Service Class Specifications

Z.4 DIMSE-C Service Groups
Prev | Z Composite Instance Retrieve Without Bulk Data SOP Classes (Normative) | Next

## Z.4 DIMSE-C Service Groups

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

- C-GET

### Z.4.1 C-GET Operation

SCUs of the Composite Instance Retrieve Without Bulk Data Service shall generate retrievals using the C-GET operation as described in PS3.7. The C-GET operation allows an application entity to instruct another application entity to transfer SOP Instances without the Attributes as described in Section Z.1.3 to the initiating application entity using the C-STORE operation. Support for the C-GET service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-GET in order for a C-GET operation to occur over the Association. The C-STORE Sub-operations shall be accomplished on the same Association as the C-GET 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 is always the originator of the C-GET operation.

#### Z.4.2.1 C-GET Service Parameters

##### Z.4.2.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-GET 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-GET operation.

##### Z.4.2.1.2 Priority

The Priority Attribute defines the requested priority of the C-GET 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.

##### Z.4.2.1.3 Identifier

The C-GET request shall contain an Identifier. The C-GET 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-GET primitive in PS3.7 but is specialized for use with this service.

###### Z.4.2.1.3.1 Request Identifier Structure

An Identifier in a C-GET request shall contain:

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

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

- 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.

Query/Retrieve Level (0008,0052) shall be IMAGE.

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 are defined in the SOP Class definition for the Query/Retrieve Information Model.

##### Z.4.2.1.4 Status

The status code values that might be returned in a C-GET response shall be as specified in Table Z.4-1

Table Z.4-1. C-GET 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)
Identifier does not match SOP Class | A900 | (0000,0901) (0000,0902)
Unable to process | Cxxx | (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)

##### Z.4.2.1.5 Number of Remaining Sub-Operations

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

##### Z.4.2.1.6 Number of Completed Sub-Operations

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

##### Z.4.2.1.7 Number of Failed Sub-Operations

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

##### Z.4.2.1.8 Number of Warning Sub-Operations

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

#### Z.4.2.2 C-GET SCU and C-STORE SCP Behavior

##### Z.4.2.2.1 Baseline Behavior of SCU

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

- The SCU shall specify one Instance UID or a list of Instance UIDs.

- The SCU shall have proposed sufficient presentation contexts at Association establishment time to accommodate expected C-STORE sub-operations that will occur over the same Association. The SCU of the Query/Retrieve Service Class shall serve as the SCP of the Storage Service Class.

- The SCP of the Storage Service Class shall not store the incomplete SOP Instance; rather the behavior is implementation defined.

- The SCU shall accept C-GET 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-GET 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-GET 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-GET operation by issuing a C-GET-CANCEL request at any time during the processing of the C-GET request. A C-GET response with a status of Canceled shall indicate to the SCU that the retrieve was canceled. Optionally, the C-GET 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-GET-CANCEL request.

- The SCP of the Storage Service Class shall not return a status of "Error: Data set does not match SOP Class" (A9xx) or "Warning: Data set does not match SOP Class" (B007) due to the absence of the Attributes described in Section Z.1.3.

##### Z.4.2.2.2 Extended Behavior of SCU

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

#### Z.4.2.3 C-GET SCP and C-STORE SCU Behavior

##### Z.4.2.3.1 Baseline Behavior of SCP

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

- 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-GET request.

- The SCP shall initiate C-STORE sub-operations for the identified SOP Instances, but shall not include in this C-STORE sub-operation the Attributes described in section Section Z.1.3. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the Storage Service Class.

- Apart from the Attributes listed in section Section Z.1.3, the SOP Instance sent via the C-STORE sub-operation shall be unchanged, and no corresponding changes to other Attributes shall be made.

### Note

In particular, the Study, Series and SOP Instance UIDs and SOP Class UID will not be altered.

- The SCP shall initiate C-STORE sub-operations over the same Association for all SOP Instances specified in the C-GET request.

- A sub-operation is considered a Failure if the SCP is unable to initiate a C-STORE sub-operation because the Query/Retrieve SCU did not offer an appropriate presentation context for a given stored SOP Instance.

- Optionally, the SCP may generate responses to the C-GET 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-GET 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-GET-CANCEL request at any time during the processing of the C-GET request. The SCP shall interrupt all C-STORE sub-operation processing and return a status of Canceled in the C-GET response. The C-GET 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-GET-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.

##### Z.4.2.3.2 Extended Behavior of SCP

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

Prev | Up | Next
Z.3 Standard Composite Instance Retrieve Without Bulk Data Information Model | Home | Z.5 Association Negotiation

DICOM PS3.4 2016e - Service Class Specifications