DICOM PS3.4 2017d - Service Class Specifications

Z Composite Instance Retrieve Without Bulk Data SOP Classes (Normative)

Z.1 Overview

Z.1.1 Scope

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 Root Retrieve Service.

Z.1.2 Composite Instance Retrieve Without Bulk Data Information Model

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.

Z.1.3 Attributes Not Included

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

Table Z.1-1. Attributes Not to Be Included in Instances Sent

Attribute Name

Tag

Pixel Data

(7FE0,0010)

Float Pixel Data

(7FE0,0008)

Double Float Pixel Data

(7FE0,0009)

Pixel Data Provider URL

(0028,7FE0)

Spectroscopy Data

(5600,0020)

Overlay Data

(60xx,3000)

Curve Data

(50xx,3000)

Audio Sample Data

(50xx,200C)

Encapsulated Document

(0042,0011)


Note

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).

Z.1.4 Service Definition

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:

  1. 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.

DICOM PS3.4 2017d - Service Class Specifications