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

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 Dataset 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 Tag
Pixel Data (7FE0,0010)
Pixel Data URL (7FE0,0120)
Spectroscopy Data (5600,0020)
Overlay Data (60xx,3000)
Curve Data (50xx,3000)
Audio Sample Data (50xx,200C)
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 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.

Z.2 Composite Instance Retrieve Without Bulk Data Information Model definition

The Composite Instance Retrieve Without Bulk Data Information Model is identified by the SOP Class negotiated at Association establishment time. The SOP Class is composed of both an Information Model and a DIMSE-C Service Group.

Note: This SOP Class identifies the class of the Composite Instance Retrieve Without Bulk Data Information Model (i.e. not the SOP Class of the stored SOP Instances for which the SCP has information)

Information Model Definitions for standard SOP Classes of the Composite Instance Retrieve Without Bulk Data Service are defined in this Annex. A Composite Instance Retrieve Without Bulk Data Information Model Definition contains:

– Entity-Relationship Model Definition

– Key Attributes Definition

Z.2.1 Entity-Relationship Model Definition

For any Composite Instance Retrieve Without Bulk Data Information Model, an Entity-Relationship Model defines a hierarchy of entities, with Attributes defined for each level in the hierarchy (e.g. Composite Instance, Frame).

Z.2.2 Attributes Definition

Attributes and matching shall be as defined in section C.2.2

Z.3 Standard Composite Instance Retrieve Without Bulk Data Information Model

One standard Composite Instance Retrieve Without Bulk Data Information Model is defined in this Annex. The Composite Instance Retrieve Without Bulk Data Information Model is associated with a single SOP Class. The following Composite Instance Retrieve Without Bulk Data Information Model is defined:

– Retrieve Without Bulk Data

Z.3.1 Composite Instance Retrieve Without Bulk Data Information Model

The Composite Instance Retrieve Without Bulk Data Information Model is based upon a one level hierarchy:

– Composite Instance

The Retrieve Without Bulk Data Information Model may be represented by the entity relationship diagram shown in Figure Z.3.1-1.

[pic]

FIGURE Z.3.1-1 RETRIEVE WITHOUT BULK DATA INFORMATION MODEL E/R DIAGRAM

The Composite Instance level is the only level and contains only the SOP Instance UID.

Z.4 DIMSE-C service groups

A single DIMSE-C Service is used in the construction of SOP Classes of the Composite Instance Retrieve Without Bulk Data Service. The following DIMSE-C operation is used:

– C-GET

Z.4.1 C-GET Operation

SCUs of the Composite Instance Retrieve Without Bulk Data Service shall generate retrievals using the C-GET operation as described in PS 3.7. The C-GET operation allows an application entity to instruct another application entity to transfer SOP Instances without the Attributes as described in Section Z.1.3 to the initiating application entity using the C-STORE operation. Support for the C-GET service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-GET in order for a C-GET operation to occur over the Association. The C-STORE Sub-operations shall be accomplished on the same Association as the C-GET operation. Hence, the SCP of the Query/Retrieve Service Class serves as the SCU of the Storage Service Class.

Note: The Application Entity that receives the stored SOP Instances is always the originator of the C-GET operation.

Z.4.2.1 C-GET Service Parameters

Z.4.2.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-GET is to be performed. Support for the SOP Class UID is implied by the Abstract Syntax UID of the Presentation Context used by this C-GET operation.

Z.4.2.1.2 Priority

The Priority Attribute defines the requested priority of the C-GET operation and corresponding C-STORE sub-operations with respect to other DIMSE operations being performed by the same SCP.

Processing of priority requests is not required of SCPs. Whether or not an SCP supports priority processing, and the meaning of the different priority levels shall be stated in the Conformance Statement of the SCP. The same priority shall be used for all C-STORE sub-operations.

Z.4.2.1.3 Identifier

The C-GET request shall contain an Identifier. The C-GET response shall conditionally contain an Identifier as required in C.4.3.1.3.2.

Note: The Identifier is specified as U in the definition of the C-GET primitive in PS 3.7 but is specialized for use with this service.

Z.4.2.1.3.1 Request Identifier Structure

An Identifier in a C-GET request shall contain:

– the Query/Retrieve Level (0008,0052) that defines the level of the retrieval

– SOP Instance UID(s) (0008,0018)

Query/Retrieve Level (0008,0052) shall be IMAGE.

Specific Character Set (0008,0005) shall not be present.

The Keys at each level of the hierarchy and the values allowable for the level of the retrieval are defined in the SOP Class definition for the Query/Retrieve Information Model.

Z.4.2.1.4 Status

The status code values that might be returned in a C-GET response shall be as specified in Table Z.4-1

Table Z.4-1 C-GET RESPONSE STATUS VALUES FOR INSTANCE ROOT RETRIEVE

Service Status Further Meaning Status Codes Related Fields
Failure Refused: Out of Resources – Unable to calculate number of matches A701 (0000,0902)
Refused: Out of Resources – Unable to perform sub-operations A702 (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Identifier does not match SOP Class A900 (0000,0901) (0000,0902)
Unable to process Cxxx (0000,0901) (0000,0902)
Cancel Sub-operations terminated due to Cancel Indication FE00 (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Warning Sub-operations Complete – One or more Failures or Warnings B000 (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Success Sub-operations Complete – No Failures or Warnings 0000 (0000,1020) (0000,1021) (0000,1022) (0000,1023)
Pending Sub-operations are continuing FF00 (0000,1020) (0000,1021) (0000,1022) (0000,1023)

Z.4.2.1.5 Number of Remaining Sub-Operations

Inclusion of the Number of Remaining Sub-operations shall be as specified in C.4.3.1.5

Z.4.2.1.6 Number of Completed Sub-Operations

Inclusion of the Number of Completed Sub-operations shall be as specified in C.4.3.1.6

Z.4.2.1.7 Number of Failed Sub-Operations

Inclusion of the Number of Failed Sub-operations shall be as specified in C.4.3.1.7

Z.4.2.1.8 Number of Warning Sub-Operations

Inclusion of the Number of Warning Sub-operations shall be as specified in C.4.3.1.8.

Z.4.2.2 C-GET SCU and C-STORE SCP Behavior

An SCU conveys the following semantics with a C-GET request:

– The SCU shall specify one Instance UID or a list of Instance UIDs.

– The SCU shall have proposed sufficient presentation contexts at Association establishment time to accommodate expected C-STORE sub-operations that will occur over the same Association. The SCU of the Query/Retrieve Service Class shall serve as the SCP of the Storage Service Class.

– The SCP of the Storage Service Class shall not store the incomplete SOP Instance; rather the behavior is implementation defined.

– The SCU shall accept C-GET responses with status equal to Pending during the processing of the C-STORE sub-operations. These responses indicate the number of Remaining, Completed, Failed and Warning C-STORE sub-operations.

– The SCU shall interpret a C-GET response with a status equal to Success, Warning, Failure, or Refused as a final response. The final response indicates the number of Completed sub-operations and the number of Failed C-STORE sub-operations resulting from the C-GET operation. The SCU shall interpret a status of:

– The SCU may cancel the C-GET operation by issuing a C-GET-CANCEL request at any time during the processing of the C-GET request. A C-GET response with a status of Canceled shall indicate to the SCU that the retrieve was canceled. Optionally, the C-GET response with a status of Canceled shall indicate 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 that were not initiated due to the C-GET-CANCEL request.

– The SCP of the Storage Service Class shall not return a status of “Error: Dataset does not match SOP Class” (A9xx) or “Warning: Dataset does not match SOP Class” (B007) due to the absence of the Attributes described in Section Z.1.3.

Z.4.2.3 C-GET SCP and C-STORE SCU Behavior

An SCP conveys the following semantics with a C-GET response:

– The SCP shall identify a set of Entities at the level of the transfer 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 identified SOP Instances, but shall not include in this C-STORE sub-operation the Attributes described in section Z.1.3. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the Storage Service Class.

– Apart from the Attributes listed in section Z.1.3, the SOP Instance sent via the C-STORE sub-operation shall be unchanged, and no corresponding changes to other attributes shall be made.

Note: In particular, the Study, Series and SOP Instance UIDs and SOP Class UID will not be altered.

– The SCP shall initiate C-STORE sub-operations over the same Association for all SOP Instances specified in the C-GET request.

– A sub-operation is considered a Failure 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 or Failed. The status contained in the C-GET response shall contain:

– 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 that were not initiated due to the C-GET-CANCEL request.

– If the SCP manages images in multiple alternate encodings (see C.6.1.1.5.1), only one of the alternate encodings of an image shall be used as the existing SOP Instance from which frames are to be extracted.

Z.5 Association negotiation

Association establishment is the first phase of any instance of communication between peer DICOM AEs. AEs supporting DICOM Query/Retrieve SOP Classes utilize Association establishment negotiation by defining the use of Application Association Information. See PS 3.7 for an overview of Association negotiation.

SOP Classes of the Composite Instance Retrieve Without Bulk Data Service, which include retrieval services based on the C-GET operation, use the SCP/SCU Role Selection Sub-Item to identify the SOP Classes that may be used for retrieval.

Z.5.1 Association Negotiation for C-GET SOP Classes

Rules are as specified in C.5.3, except that the Relational-retrieval extended negotiation sub-item shall not be used for this service class.

Z.6 SOP CLASS DEFINITIONS

Z.6.1 Composite Instance Retrieve Without Bulk Data SOP Class Group

In the Composite Instance Retrieve Without Bulk Data Only Information Model, only a single Retrieve Level is used.

Table Z.6.1-1

Retrieve Level Value for Retrieve Without Bulk Data

Retrieve Level Value in (0008,0052)
Composite Instance IMAGE

Note: The use of the word “IMAGE” rather than “Composite Instance” is historical to allow backward compatibility with previous versions of the standard. It should not be taken to mean that Composite Instances of other than image type are not included at the level indicated by the value IMAGE.

Z.6.1.1 Composite Instance Retrieve Without Bulk Data Information Model

Z.6.1.1.1 E/R Model

The Composite Instance Retrieve Without Bulk Data Only Information Model has only a single level: IMAGE.

Z.6.1.1.2 Composite Instance Level

Table Z.6-1 defines the keys at the Composite Instance level of the Composite Instance Retrieve Without Bulk Data Query/Retrieve Information model.

Table Z.6-1

COMPOSITE INSTANCE LEVEL KEYS FOR THE COMPOSITE INSTANCE ROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Matching Key Type
SOP Instance UID (0008,0018) U

Z.6.1.1.3 Scope of the C-GET Commands and Sub-Operations

A C-GET request may only be performed at the IMAGE level of the Query/Retrieve Model. A C-GET indicates that selected individual Composite Instances, without bulk data attributes shall be transferred.

Z.6.1.2 Conformance Requirements

An implementation may conform to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS 3.2.

Z.6.1.2.1 SCU Conformance

An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group as an SCU shall support retrievals against the Query/Retrieve Information Model described in Section Z.6.1.1 using the C-GET SCU Behavior described in Section Z.4.2.2. An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group as an SCU, and which generates retrievals using the C-GET operation shall state in its Conformance Statement the Storage Service Class SOP Classes under which it shall support the C-STORE sub-operations generated by the C-GET.

Z.6.1.2.2 SCP Conformance

An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group as an SCP shall support retrievals against both levels of the Retrieve Information Model described in Section Z.6.1.1 using the C-GET SCP Behavior described in Section Z.4.2.3. An implementation that conforms to one of the SOP Classes of the Composite Instance Retrieve Without Bulk Data SOP Class Group as an SCP, and which satisfies retrievals using the C-GET operation shall state in its Conformance Statement the Storage Service Class SOP Classes under which it shall support the C-STORE sub-operations generated by the C-GET.

Z.6.1.3 SOP Classes

The SOP Classes in the Composite Instance Retrieve Without Bulk Data SOP Class Group of the Query/Retrieve Service Class identify the Composite Instance Retrieve Without Bulk Data Only Information Model, and the DIMSE-C operations supported. The Standard SOP Classes are listed in Table Z.6.1.3-1.

Table Z.6.1.3-1

SOP Classes for Composite Instance Query/Retrieve Root

UID NAME UID Value
Composite Instance Retrieve Without Bulk Data – GET 1.2.840.10008.5.1.4.1.2.5.3