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

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:

– 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: Dataset does not match SOP Class” (A9xx) or “Warning: Dataset does not match SOP Class” (B007) due to the absence of the Attributes described in Section Z.1.3.