The C-GET service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user, and retrieve all composite SOP Instances which match. It triggers one or more C-STORE sub-operations on the same Association. It is a confirmed service.
See Table 9.1-3.
Table 9.1-3 C-GET PARAMETERS
|DIMSE-C Parameter Name||Req/Ind||Rsp/Conf||CnclReq/CnclInd|
|Message ID Being Responded To||⎯||M||M|
|Affected SOP Class UID||M||U(=)||⎯|
|Number of Remaining Sub-operations||⎯||C||⎯|
|Number of Completed Sub-operations||⎯||C||⎯|
|Number of Failed Sub-operations||⎯||C||⎯|
|Number of Warning Sub-operations||⎯||C||⎯|
This parameter identifies the operation. It is used to distinguish this operation from other notifications or operations that the DIMSE-service-provider may have in progress. No two identical values for the Message ID (0000,0110) shall be used for outstanding operations or notifications.
Noteσ: 1. Inclusion of this parameter in the confirmation was permitted in previous versions of this Standard but this mode of use is now retired. This parameter may be included in the confirmation but in such a case the invoking DIMSE-service-user should not attach any semantic significance to this parameter.
2. The Message ID (0000,0110) is recommended to be unique within the scope of an Association, to support debug procedures.
This parameter specifies the Message ID (0000,0110) of the request/indication to which this response/confirmation applies.
For the request/indication, this parameter specifies the SOP Class of the Information Model for the retrieve. It may be included in the response/confirmation. If included in the response/confirmation, this parameter shall be equal to the value in the request/indication.
This parameter specifies the priority of the C-GET operation. It shall be one of LOW, MEDIUM or HIGH. This priority shall also be the priority used for all sub-operations.
In the request/indication, this is a list of Attributes to be matched against the values of the Attributes of known composite SOP Instances of the performing DIMSE-service-user. The list of Attributes allowed and the rules for the construction are specified in PS 3.4.
Note: The Identifier is specified as U in the Response/Confirmation, but Services defined in PS 3.4 that use this primitive may impose mandatory or conditional requirements on its presence.
In the response/confirmation, this is a list of Attributes which provide status information about the C-GET operation. The list of Attributes allowed and the rules which define the usage of the Identifier are specified in PS 3.4.
Indicates the status of the response. It may have any of the following values:
a) Success⎯This indicates that processing of the matches and all sub-operations are complete.
b) Pending⎯This indicates that processing of the matches and sub-operations is initiated or continuing.
c) Refused: Out of Resources⎯Indicates that processing of the C-GET has been terminated because it was out of resources. This may be the initial response to the C-GET or may be sent after a number of Pending statuses.
d) Refused: SOP Class Not Supported⎯Indicates that processing of the C-GET has been terminated because the SOP Class was not supported.
e) Cancel⎯Indicates that processing of the C-GET has been terminated due to a C-GET Cancel indication primitive.
f) Failed⎯Indicates that the C-GET operation failed at the performing DIMSE-service-user.
This specifies the number of remaining C-STORE sub-operations to be invoked by this C-GET operation. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
This specifies the number of C-STORE sub-operations invoked by this C-GET operation which have completed successfully. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
This specifies the number of C-STORE sub-operations invoked by this C-GET operation which have failed. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
This specifies the number of C-STORE sub-operation invoked by this C-GET operation which generated Warning responses. It may be included in any response/confirmation and shall be included if the status is equal to Pending.
The following C-GET service procedures apply to the invoking DIMSE-service user:
a) The invoking DIMSE-service-user requests a performing DIMSE-service-user to match an Identifier against the Attributes of all SOP Instances known to the performing DIMSE-service-user and generate a C-STORE sub-operation for each match. This request is made by issuing a C-GET request primitive to the DIMSE-service-provider. If the request is rejected by the DIMSE-service-provider, the following procedures do not apply.
b) At any time before receiving a C-GET confirmation primitive with status unequal to Pending, the invoking DIMSE-service-user may request the performing DIMSE-service-user to cancel the service by issuing a C-GET cancel request primitive to the DIMSE-service-provider.
c) The invoking DIMSE-service-user may receive C-GET confirmation primitives with status of Pending during the processing of the C-GET operation.
d) The invoking DIMSE-service-user receives a final C-GET confirmation primitive.
Note: In the above procedures, (c) may precede (b).
The following C-GET service procedures apply to the performing DIMSE-service-user:
a) When the performing DIMSE-service-user receives a C-GET indication from the DIMSE-service-provider it matches the Identifier against the Attributes of known composite SOP Instances and generates a C-STORE sub-operation for each match.
b) At any time following the C-GET indication, the performing DIMSE-service-user may receive a C-GET cancel indication.
c) If the C-GET cancel indication is received before the processing of the C-GET indication has completed, then the C-GET operation is terminated; otherwise the following procedure does not apply.
d) The performing DIMSE-service-user issues a C-GET response with a status of Canceled to the DIMSE-service-provider to indicate that the C-GET has been canceled. The following procedures do not apply.
e) For each match, the performing DIMSE-service-user initiates a C-STORE sub-operation on the same Association as the C-GET. In this sub-operation, the C-GET performing DIMSE-service-user becomes the C-STORE invoking DIMSE-service-user. The C-STORE performing DIMSE-service-user is the C-GET invoking DIMSE-service-user.
f) During the processing of the C-GET operation, the performing DIMSE-service-user may issue C-GET response primitives with a status of Pending.
g) When the C-GET operation completes (either in success or in failure), the performing DIMSE-service-user issues a C-GET response with the status set to either refused, failed or success to the DIMSE-service-provider.
The following C-GET service procedures apply to the DIMSE-service-provider:
a) When the DIMSE-service-provider receives a C-GET request primitive from the invoking DIMSE-service-user, it issues a C-GET indication primitive to the performing DIMSE-service-user.
b) When the DIMSE-service-provider receives a C-GET cancel request primitive from the invoking DIMSE-service-user, it issues a C-GET cancel indication to the performing DIMSE-service-user.
c) When the DIMSE-service-provider receives a C-GET response primitive from the performing DIMSE-service-user, it issues a C-GET confirmation primitive to the invoking DIMSE-service-user.
The performing DIMSE-service-user may return a C-GET response primitive with the status of Failed or Refused before the entire C-GET indication (Data Set) has been completely transmitted by the invoking DIMSE-service-user. A C-GET response primitive with the status of Success or Warning shall not be returned until the entire C-GET indication has been received by the performing DIMSE-service-user.
Note: Such an occurrence of a "Failed" response is often called an early failed response.