Composite Instance Retrieve Without Bulk Data Service is a service within the DICOM Query/Retrieve Service class defined in Annex C. The retrieve capability of this service allows a DICOM AE to retrieve Composite Instances without retrieving their pixel data or other potentially large attributes as defined in Section Z.1.3.
Retrievals are implemented against the Composite Instance Retrieve Without Bulk Data Information Model, as defined in this Annex of the DICOM Standard. A specific SOP Class of the Query/Retrieve Service Class consists of an Information Model Definition and a DIMSE-C Service Group.
The attributes that shall not be included in the top level of the Dataset sent by an SCP of this Service are as defined in Table Z.1-1
Attributes not to be Included in Instances Sent
|Pixel Data URL||(7FE0,0120)|
|Audio Sample Data||(50xx,200C)|
The Waveform Data (5400,1010) attribute shall not be included within the Waveform Sequence (5400,0100).
Two peer DICOM AEs implement a SOP Class of the Composite Instance Retrieve Without Bulk Data Service with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Composite Instance Retrieve Without Bulk Data Service are implemented using the DIMSE-C C-GET service as defined in PS 3.7.
The following descriptions of the DIMSE-C C-GET service provide a brief overview of the SCU/SCP semantics:
a) A C-GET service conveys the following semantics:
– 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 then generate C-STORE sub-operations for the corresponding storage SOP Instances, but shall not include attributes as described in Section Z.1.3 in the data sent during those sub-operations. These C-STORE sub-operations occur on the same Association as the C-GET service and the SCU/SCP roles are reversed for the C-STORE.
Note: If the source instance does not contain any of the attributes described in Section Z.1.3 then, the version sent via the C-STORE sub-operation would be identical to the original data. This is not an error.
– The SCP may optionally generate responses to the C-GET with status equal to Pending during the processing of the C-STORE sub-operations. These C-GET responses indicate the number of remaining C-STORE sub-operations and the number of C-STORE sub-operations returning the status of Success, Warning, and Failed.
– When the number of Remaining C-STORE sub-operations reaches zero, the SCP generates a final response with a status equal to Success, Warning, Failed, or Refused. This response shall indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of any C-STORE sub-operation was Failed a UID List shall be returned.
– The SCU may cancel the C-GET service by issuing a C-GET-CANCEL request at any time during the processing of the C-GET. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.