The Query/Retrieve Service Class defines an application-level class-of-service that facilitates the simple management of Composite Object Instances in a manner functionally similar to ACR-NEMA 300-1988. The types of queries that are allowed are not complex. This Service Class is not intended to provide a comprehensive generalized database query mechanism such as SQL. Instead, the Query/Retrieve Service Class is focused towards basic Composite Object Instance information queries using a small set of common Key Attributes.
In addition, the Query/Retrieve Service Class provides the ability to retrieve/transfer a well-identified set of Composite Object Instances. The retrieve/transfer capability allows a DICOM AE to retrieve Composite Object Instances from a remote DICOM AE or request the remote DICOM AE to initiate a transfer of Composite Object Instances to another DICOM AE.
Functional similarity to ACR-NEMA 300-1988 facilitates the migration to DICOM.
An Enhanced Multi-Frame Image Conversion Extended Negotiation option allows the Query/Retrieve Service Class to access Classic single-frame images that have been converted to Enhanced multi-frame images, or vice-versa. This is achieved by providing alternative "views" of studies, such that:
the default view provides the images in the form they were received,
a Classic single-frame "view" provides images as Classic single frame (that were received that way or have been converted from Enhanced multi-frame),
an Enhanced multi-frame "view" provides images as Enhanced multi-frame (that were received that way or have been converted to Enhanced multi-frame).
A query or retrieval above the IMAGE level does not show or return duplicate information (two sets of images). The SCU may request the default, enhanced multi-frame or Classic single frame view. For each view, referential integrity is required to be consistent within the scope of the Patient and that view; i.e., references to UIDs will be converted in all Instances, not only within converted images.
The Classic single-frame view is not intended as an alternative to the Frame Level Retrieve SOP Classes defined in Annex Y. Enhanced Image Storage SOP Classes and Frame Level Retrieve SOP Classes should be used together since they support a unified view of the relationships between instances through a common set of UIDs.
In the Enhanced view, Instances that have no Enhanced equivalent will be returned in their original form but with referential integrity related changes.
The following conventions are used to define the types of keys used in Query/Retrieve Information Models.
Table C.1.2-1. Key Type Conventions for Query/Retrieve Information Models
|
Symbol |
Description |
|---|---|
|
U |
Unique Key Attribute |
|
R |
Required Key Attribute |
|
O |
Optional Key Attribute |
In order to serve as an SCP of the Query/Retrieve Service Class, a DICOM AE possesses information about the Attributes of a number of stored Composite Object Instances. This information is organized into a well defined Query/Retrieve Information Model. The Query/Retrieve Information Model shall be a standard Query/Retrieve Information Model, as defined in this Annex of the DICOM Standard.
Queries and Retrievals are implemented against well defined Information Models. A specific SOP Class of the Query/Retrieve Service Class consists of an Information Model Definition and a DIMSE-C Service Group. In this Service Class, the Information Model plays a role similar to an Information Object Definition (IOD) of most other DICOM Service Classes.
Two peer DICOM AEs implement a SOP Class of the Query/Retrieve Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Query/Retrieve Service Class are implemented using the DIMSE-C C-FIND, C-MOVE, and C-GET services as defined in PS3.7.
Both a baseline and extended behavior is defined for the DIMSE-C C-FIND, C-MOVE, and C-GET services. Baseline behavior specifies a minimum level of conformance for all implementations to facilitate interoperability. Extended behavior enhances the baseline behavior to provide additional features that may be negotiated independently at Association establishment time.
The following descriptions of the DIMSE-C C-FIND, C-MOVE, and C-GET services provide a brief overview of the SCU/SCP semantics:
A C-FIND service conveys the following semantics:
The SCU requests that the SCP perform a match of all the keys specified in the Identifier of the request, against the information it possesses, to the level (E.g. Patient, Study, Series, or Composite Object Instance) specified in the request.
In this Annex, the term "Identifier" refers to the Identifier service parameter of the C-FIND, C-MOVE, or C-GET service as defined in PS3.7.
The SCP generates a C-FIND response for each match with an Identifier containing the values of all key fields and all known Attributes requested. All such responses will contain a status of Pending. A status of Pending indicates that the process of matching is not complete.
When the process of matching is complete a C-FIND response is sent with a status of Success and no Identifier.
A Refused or Failed response to a C-FIND request indicates that the SCP is unable to process the request.
The SCU may cancel the C-FIND service by issuing a C-FIND-CANCEL request at any time during the processing of the C-FIND service. The SCP will interrupt all matching and return a status of Canceled.
A C-MOVE service conveys the following semantics:
The SCU supplies Unique Key values to identify an entity at the level of the retrieval. The SCP of the C-MOVE initiates C-STORE sub-operations for the corresponding storage SOP Instances identified by Unique Key values. These C-STORE sub-operations occur on a different Association than the C-MOVE service. The SCP role of the Query/Retrieve SOP Class and the SCU role of the Storage SOP Class may be performed by different applications that may or may not reside on the same system. Initiation mechanism of C-STORE sub-operations is outside of the scope of DICOM standard.
This does not imply that they use the same AE Title. See Section C.6.1.2.2.2 and Section C.6.2.2.2.2 for the requirements to the C-MOVE SCP conformance.
The SCP may optionally generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These C-MOVE 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 may indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of a C-STORE sub-operation was Failed a UID List will be returned.
The SCU may cancel the C-MOVE service by issuing a C-MOVE-CANCEL request at any time during the processing of the C-MOVE. The SCP terminates all incomplete C-STORE sub-operations and returns a status of Canceled.
A C-GET service conveys the following semantics:
The SCU supplies Unique Key values to identify an entity at the level of the retrieval. The SCP generates C-STORE sub-operations for the corresponding storage SOP Instances identified by the Unique Key values. These C-STORE sub-operations occur on the same Association as the C-GET service and the SCU/SCP roles will be reversed for the C-STORE.
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 may indicate the number of C-STORE sub-operations returning the status of Success, Warning, and Failed. If the status of a C-STORE sub-operation was Failed a UID List will 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.