| DICOM PS3.4 2024c - Service Class Specifications |
|---|
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.
The Enhanced Multi-Frame Image Conversion Extended Negotiation Option of the DICOM Query/Retrieve Service class defined in Annex C is also supported for the Composite Instance Retrieve Without Bulk Data Service.
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 Data set sent by an SCP of this Service are as defined in Table Z.1-1
This implies that the pixel data within Icon Image Sequence (0088,0200) Items will be preserved.
The Waveform Data (5400,1010) Attribute shall not be included within the Waveform Sequence (5400,0100).
Private Attributes may be preserved or discarded by a Storage SCP, as defined in Section B.4.1. A Storage SCP that claims conformance to Storage Level 2 (Full) support of the Storage Service Class may choose to return Private Attributes in the Retrieve Without Bulk Data Service or not. Whether or not particular Private Attributes are returned shall be documented in the Conformance Statement.
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 PS3.7.
The following descriptions of the DIMSE-C C-GET service provide a brief overview of the SCU/SCP semantics:
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.
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-CANCEL-GET 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.
| DICOM PS3.4 2024c - Service Class Specifications |
|---|