This Section discusses both the baseline and extended behavior of the C-GET 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-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 which were not initiated due to the C-GET-CANCEL request.
If the SCP manages images in multiple alternate encodings (see C.184.108.40.206.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.
Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:
The C-GET Service with relational-retrieve removes the restriction that the SCU supply Unique Key values for levels above the Query/Retrieve level to help identify an entity at the level of the retrieval. Hence, the Identifier of a C-GET request may retrieve:
all composite object instances related to a study by providing a Study Instance UID
all composite object instances related to a series by providing a Series Instance UID
individual composite object instances by providing a list of SOP Instance UIDs