DICOM PS3.4 2024e - Service Class Specifications
C.4.3.3 C-GET SCP Behavior (Current)
Prev  C.4.3 C-GET Operation  Next
PS3.4 > Query/Retrieve Service Class (Normative) > DIMSE-C Service Groups > C-GET Operation > C-GET SCP Behavior

C.4.3.3 C-GET SCP Behavior

This Section discusses both the baseline and extended behavior of the C-GET SCP.

C.4.3.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 retrieval 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 corresponding storage SOP Instances. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the Storage Service Class.

  • The SCP shall initiate C-STORE sub-operations over the same Association for all stored SOP Instances related to the Patient ID, List of Study Instance UIDs, List of Series Instance UIDs, or List of SOP Instance UIDs depending on the Query/Retrieve level specified in the C-GET request

  • A sub-operation is considered Failed 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, Failed, or Refused. The status contained in the C-GET response shall contain:

    • Success if all sub-operations were successfully completed

    • Warning if one or more sub-operations were successfully completed and one or more sub-operations were unsuccessful or had a status of warning

    • Warning if all sub-operations had a status of Warning

    • Failure or Refused if all sub-operations were unsuccessful

  • The SCP may receive a C-CANCEL-GET 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-CANCEL-GET 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 included in the set of object instances retrieved by a C-GET request at the Patient, Study, or Series level.

    Note

    For retrieval of images with alternate encodings using a C-GET request at the Patient, Study, or Series level, the SCP may select the appropriately encoded Instance for the retrieval based on identity of the SCU, transfer syntaxes accepted in the C-STORE Association Negotiation, or other factors.

Prev  Up  Next
C.4.3.2.2 Extended Behavior of SCU  Home  C.4.3.3.2 Extended Behavior of SCP
DICOM PS3.4 2024e - Service Class Specifications