C.4 DIMSE-C Service Groups

Three DIMSE-C Services are used in the construction of SOP Classes of the Query/Retrieve Service Class. The following DIMSE-C operations are used:

C.4.1 C-FIND Operation

SCPs of some SOP Classes of the Query/Retrieve Service Class may be capable of processing queries using the C-FIND operation as described in PS3.7. The C-FIND operation is the mechanism by which queries are performed. Matches against the keys present in the Identifier are returned in C-FIND responses.

C.4.1.1 C-FIND Service Parameters

C.4.1.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-FIND 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-FIND operation.

C.4.1.1.2 Priority

The Priority Attribute defines the requested priority of the C-FIND operation 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.

C.4.1.1.3 Identifier

Both the C-FIND request and response contain an Identifier encoded as a Data Set (see PS3.5).

Note

The definition of a Data Set in PS3.5 specifically excludes the range of groups below group 0008, and this includes in particular Meta Information Header elements such as Transfer Syntax UID (0002,0010). The C-FIND request and identifier do not support a mechanism for ascertaining the manner in which an SCP might have encoded a stored image whether it be by requesting Transfer Syntax UID (0002,0010) or by any other mechanism.

C.4.1.1.3.1 Request Identifier Structure

An Identifier in a C-FIND request shall contain:

  • Key Attributes values to be matched against the values of storage SOP Instances managed by the SCP.

  • Query/Retrieve Level (0008,0052), which defines the level of the query.

  • Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has been accepted during Association Extended Negotiation. It shall not be included otherwise.

  • Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier. It shall not be included otherwise.

  • Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if Key Attributes of time are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The Key Attributes and values allowable for the level of the query shall be defined in the SOP Class definition for the Query/Retrieve Information Model.

C.4.1.1.3.2 Response Identifier Structure

The C-FIND response shall not contain Attributes that were not in the request or specified in this section.

An Identifier in a C-FIND response shall contain:

  • Key Attributes with values corresponding to Key Attributes contained in the Identifier of the request.

    Note

    1. All Required Keys in the Request Identifier, as well as all Optional Keys in the Request Identifier that are supported by the SCP, will therefore be present in the Response Identifier.

    2. Required Keys and supported Optional Keys in the Response Identifier will have zero length if the SCP has no value to send; i.e., there is no requirement that the SCP have a value for these, or create a dummy value.

    3. The requirement that unsupported Optional Keys present in the Request Identifier not be included in the Response Identifier is specified in Section C.2.2.1.3.

  • Query/Retrieve Level (0008,0052), which defines the level of the query. The Query/Retrieve level shall be equal to the level specified in the request.

  • Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.

  • Conditionally, the Attribute Timezone Offset From UTC (0008,0201). This Attribute shall be included if any Attributes of time in the Response Identifier are to be interpreted explicitly in the designated local time zone. It shall not be present otherwise, i.e., it shall not be sent with a zero-length value.

The C-FIND SCP is required to support either or both the Retrieve AE Title Data Element or the Storage Media File-Set ID/Storage Media File Set UID Data Elements. An Identifier in a C-FIND response shall contain:

  • Storage Media File-Set ID (0088,0130), which defines a user or implementation specific human readable Identifier that identifies the Storage Media on which the Composite Object Instance(s); reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

  • Storage Media File-Set UID (0088,0140), which uniquely identifies the Storage Media on which the Composite Object Instance(s) reside. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Retrieve AE Title Data Element is not present. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Note

    The File-Set concepts are used in PS3.10.

  • Retrieve AE Title (0008,0054), which defines a list of DICOM Application Entity Title(s) that identify the location from which the Composite Object Instance(s) may be retrieved on the network. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). This Attribute shall be present if the Storage Media File-Set ID and Storage Media File-Set UID elements are not present. The Application Entity named in this field shall support either the C-GET or C-MOVE SOP Class of the Query/Retrieve Service Class. A null value (Data Element length of 0) is valid for all levels except the lowest level in the Information Model as defined by the SOP Class.

    Note

    1. For example, a DICOM AE with the AE Title of "A" performs a C-FIND request to a DICOM AE with the AE Title of "B" with the Query/Retrieve level set to "STUDY". DICOM AE "B" determines that the Composite Object Instances for each matching study may be retrieved by itself and sets the Data Element Retrieve AE Title to "B".

    2. File-Sets may not be defined at every Query/Retrieve Level. If the SCP supports the File-Set ID/File-Set UID option but does not define these Attributes at the Query/Retrieve Level specified in the C-FIND request it may return these Data Elements with a length of 0 to signify that the value is unknown. An SCU should reissue a C-FIND at a Query/Retrieve Level lower in the hierarchy.

    3. The fact that the value of the Key Attribute is unknown to the SCP of the Query/Retrieve Service Class does not imply that it is not present in the underlying Information Object. Thus, a subsequent retrieval may cause a Storage of a SOP Instance that contains the value of the Attribute.

The C-FIND SCP may also, but is not required to, support the Instance Availability (0008,0056) Data Element. This Data Element shall not be included in a C-FIND request. An Identifier in a C-FIND response may contain:

  • Instance Availability (0008,0056), which defines how rapidly Composite Object Instance(s); become available for transmission after a C-MOVE or C-GET retrieval request. This element pertains to the set of Composite Object Instances available at the Query/Retrieve Level specified in the Identifier of the C-FIND request (e.g., Patient, Study, Series, Composite Object Instance). When some composite instances are less rapidly available than others, the availability of the least rapidly available shall be returned. If this Data Element is not returned, the availability is unknown or unspecified. A null value (Data Element length of 0) is not permitted. The Enumerated Values for this Data Element are:

    • "ONLINE", which means the instances are immediately available,

    • "NEARLINE", which means the instances need to be retrieved from relatively slow media such as optical disk or tape, or require conversion that takes time,

    • "OFFLINE", which means the instances need to be retrieved by manual intervention,

    • "UNAVAILABLE", which means the instances cannot be retrieved. Note that SOP Instances that are unavailable may have an alternate representation that is available (see section Section C.6.1.1.5.1).

C.4.1.1.4 Status

Table C.4-1 defines the specific status code values that might be returned in a C-FIND response. General status code values and fields related to status code values are defined in PS3.7.

Table C.4-1. C-FIND Response Status Values

Service Status

Further Meaning

Status Codes

Related Fields

Failure

Refused: Out of Resources

A700

(0000,0902)

Identifier does not match SOP Class

A900

(0000,0901)

(0000,0902)

Unable to process

Cxxx

(0000,0901)

(0000,0902)

Cancel

Matching terminated due to Cancel request

FE00

None

Success

Matching is complete - No final Identifier is supplied.

0000

None

Pending

Matches are continuing - Current Match is supplied and any Optional Keys were supported in the same manner as Required Keys.

FF00

Identifier

Matches are continuing - Warning that one or more Optional Keys were not supported for existence and/or matching for this Identifier.

FF01

Identifier


C.4.1.2 C-FIND SCU Behavior

This Section discusses both the baseline and extended behavior of the C-FIND SCU.

C.4.1.2.1 Baseline Behavior of SCU

All C-FIND SCUs shall be capable of generating query requests that meet the requirements of the Hierarchical Search.

The Identifier contained in a C-FIND request shall contain a single value in the Unique Key Attribute for each level above the Query/Retrieve level. No Required or Optional Keys shall be specified that are associated with levels above the Query/Retrieve level.

The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. In addition, Required and Optional Keys associated with the Query/Retrieve level may be contained in the Identifier.

An SCU conveys the following semantics using the C-FIND request:

  • The SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information it possesses down to the Query/Retrieve level specified in the request.

    Note

    1. The SCU may not assume the SCP supports any Optional Keys. Hence, Optional Keys serve only to reduce network related overhead when they are supported by the SCP.

    2. The SCU must be prepared to filter C-FIND responses when the SCP fails to support an Optional Key specified in the C-FIND request.

  • The SCU shall interpret Pending responses to convey the Attributes of a match of an Entity at the level of the query.

  • The SCU shall interpret a response with a status equal to Success, Failed or Refused to convey the end of Pending responses.

  • The SCU shall interpret a Refused or Failed response to a C-FIND request as an indication 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. The SCU shall recognize a status of Canceled to indicate that the C-FIND-CANCEL was successful.

C.4.1.2.2 Extended Behavior of SCU

Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be performed with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.1.2.2.1 Relational-Queries

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. The Unique Key Attribute associated with the Query/Retrieve level shall be contained in the C-FIND request and may specify Single Value Matching, Universal Value Matching, or List of UID Matching. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

C.4.1.2.2.2 Enhanced Multi-Frame Image Conversion

The C-FIND Service with Enhanced Multi-Frame Image Conversion allows for selection of the default or an alternative view of the instances represented by the Information Model.

Support for Enhanced Multi-Frame Image Conversion allows the SCU to specify the Query/Retrieve View (0008,0053) in the Request Identifier with a value of either "CLASSIC" or "ENHANCED".

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCU requests that the SCP perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The SCU may assume that no duplicate information will be returned. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Unconverted instances, such as for other modalities like Ultrasound, will appear identical regardless of view.

  4. Implementations may apply performance optimizations, such as pre-computing or caching the potential information against which CLASSIC and ENHANCED queries may be performed, in order to minimize significant delays between the query request and response caused by converting "on demand", but SCUs may need to consider the potential for a delayed response when configuring timeouts, etc.

C.4.1.3 C-FIND SCP Behavior

This Section discusses both the baseline and extended behavior of the C-FIND SCP.

C.4.1.3.1 Baseline Behavior of SCP

All C-FIND SCPs shall be capable of processing queries that meet the requirements of the Hierarchical Search.

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

  • The SCP is requested to perform a match of all the keys specified in the Identifier of the request, against the information it possesses, to the level specified in the request. Attribute matching is performed using the key values specified in the Identifier of the C-FIND request as defined in Section C.2.

  • The SCP generates a C-FIND response for each match using the Hierarchical Search method. All such responses shall contain an Identifier whose Attributes contain values from a single match. All such responses shall contain a status of Pending.

  • When all matches have been sent, the SCP generates a C-FIND response that contains a status of Success. A status of Success shall indicate that a response has been sent for each match known to the SCP.

    Note

    When there are no matches, then no responses with a status of Pending are sent, only a single response with a status of Success.

  • The SCP shall generate a response with a status of Refused or Failed if it is unable to process the request. A Refused or Failed response shall contain no Identifier.

  • If the SCP receives C-FIND-CANCEL indication before it has completed the processing of the matches it shall interrupt the matching process and return a status of Canceled.

  • If the SCP manages images in multiple alternate encodings (see Section C.6.1.1.5.1), only one of the alternate encodings of an image shall be included in the set of matches for a C-FIND request at the Instance level.

    Note

    For query of images with alternate encodings, the SCP may select the appropriately encoded Instance for the request response based on identity of the SCU or other factors.

C.4.1.3.1.1 Hierarchical Search Method

Starting at the top level in the Query/Retrieve Information Model, continuing until the level specified in the C-FIND request is reached, the following procedures are used to generate matches:

  1. If the current level is the level specified in the C-FIND request, then the key match strings contained in the Identifier of the C-FIND request are matched against the values of the Key Attributes for each entity at the current level. For each entity for which the Attributes match all of the specified match strings, construct an Identifier. This Identifier shall contain all of the Unique Keys at higher levels and all of the values of the Attributes for this entity that match those in the C-FIND request. Return a response for each such Identifier. If there are no matching keys, then there are no matches, return a response with a status equal to Success and with no Identifier.

  2. Otherwise, if the current level is not the level specified in the C-FIND request and there is an entity matching the Unique Key Attribute value for this level specified in the C-FIND request, perform this procedure at the next level down in the hierarchy.

  3. Otherwise there are no matches; return a response with a status equal to Success.

    Note

    The above description specifies a recursive procedure. It may recur upon itself multiple times as it goes down the hierarchical levels, but at each level it recurs only once.

C.4.1.3.2 Extended Behavior of SCP

Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:

  • Relational-queries

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.1.3.2.1 Relational-Queries

The C-FIND Service with relational-queries allows any combination of keys at any level in the hierarchy. At the lowest level, a query using the relational-queries shall contain the Unique Key for that level with either a single value match, a wild card match, or a universal match. Support for relational-queries removes the baseline restriction that a Unique Key shall be specified for all levels above the Query/Retrieve level in the C-FIND request.

The C-FIND SCP shall perform matching based on all keys specified in the C-FIND request regardless of the Query/Retrieve level.

C.4.1.3.2.2 Relational Search Method

A query using the relational method may contain any combination of keys at any level in the hierarchy. Starting at the top level in the Query/Retrieve Information Model, continuing until the Query/Retrieve level specified in the C-FIND request is reached, the following procedures are used to generate matches:

  1. The key match strings contained in the Identifier of the C-FIND request are matched against the values of the Key Attributes for each entity at the current level.

  2. If no Key Attribute is specified at the current level and the current level is not the level specified in the C-FIND request, the match shall be performed as if a wild card were specified for the Unique Key Attribute for the current level (i.e., all entities at the current level shall match).

  3. If the current level is the level specified in the C-FIND request, then for each matching entity (a matching entity is one for which the Attributes match all of the specified match strings in the Key Attributes), construct an Identifier. This Identifier shall contain all of the Attributes generated by this procedure at higher levels on this recursion path and all of the values of the Key Attributes for this entity that match those in the C-FIND request.

  4. Otherwise, if the current level is not the level specified in the C-FIND request, then for each matching entity construct a list of Attributes containing all of the matching Key Attributes and all Attributes that were prepared at the previous level for this entity. Then perform this procedure at the next level down in the hierarchy for each matching entity.

  5. Otherwise, if there are no matches, return a response with status equal to Success and no Identifier.

Note

  1. The above description specifies a recursive procedure. It may recur upon itself multiple times as it goes down the hierarchical levels, and at each level, it may recur multiple times (one for each matching entity). This may result in a large number of Identifiers being generated.

  2. It is not required that the above defined procedure be used to generate matches. It is expected that implementations will incorporate different algorithms for performing searches of the databases. For a given query, the set of matches shall be equivalent to that which would be generated by the above procedure.

C.4.1.3.2.3 Enhanced Multi-Frame Image Conversion

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about the instances that it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCP shall perform a match of all keys specified in the Identifier of the request against the information about Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The SCP will not return information that is duplicated. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-FIND will not return both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. Unconverted instances, such as for other modalities like Ultrasound, will appear identical regardless of view.

C.4.2 C-MOVE Operation

SCUs of some SOP Classes of the Query/Retrieve Service Class may generate retrievals using the C-MOVE operation as described in PS3.7. The C-MOVE operation allows an application entity to instruct another application entity to transfer stored SOP Instances to another application entity using the C-STORE operation. Support for the C-MOVE service shall be agreed upon at Association establishment time by both the SCU and SCP of the C-MOVE in order for a C-MOVE operation to occur over the Association. The C-STORE sub-operations shall always be accomplished over an Association different from the Association that accomplishes the C-MOVE 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 may or may not be the originator of the C-MOVE operation.

A C-MOVE request may be performed to any level of the Query/Retrieve Information Model. However, the transfer of stored SOP Instances may not be performed at this level. The level at which the transfer is performed depends upon the SOP Class (see Section C.6).

C.4.2.1 C-MOVE Service Parameters

C.4.2.1.1 SOP Class UID

The SOP Class UID identifies the Query/Retrieve Information Model against which the C-MOVE 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-MOVE operation.

C.4.2.1.2 Priority

The Priority Attribute defines the requested priority of the C-MOVE 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.

C.4.2.1.3 Move Destination

Move Destination specifies the Application Entity Title of the receiver of the C-STORE sub-operations.

C.4.2.1.4 Identifier

The C-MOVE request shall contain an Identifier. The C-MOVE response shall conditionally contain an Identifier as required in Section C.4.2.1.4.2.

Note

The Identifier is specified as U in the definition of the C-MOVE primitive in PS3.7 but is specialized for use with this service.

C.4.2.1.4.1 Request Identifier Structure

An Identifier in a C-MOVE request shall contain:

  • Query/Retrieve Level (0008,0052), which defines the level of the retrieval

  • Unique Key Attributes, which may include Patient ID (0010,0020), Study Instance UIDs (0020,000D), Series Instance UIDs (0020,000E), and the SOP Instance UIDs (0008,0018)

  • Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has been accepted during Association Extended Negotiation. It shall not be included otherwise.

Specific Character Set (0008,0005) shall be present if Patient ID (0010,0020) is using a character set other than the default character repertoire.

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

Note

In the non-Relational behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

C.4.2.1.4.2 Response Identifier Structure

The Failed SOP Instance UID List (0008,0058) specifies a list of UIDs of the C-STORE sub-operation SOP Instances for which this C-MOVE operation has failed. An Identifier in a C-MOVE response shall conditionally contain the Failed SOP Instance UID List (0008,0058) based on the C-MOVE response status value. If no C-STORE sub-operation failed, Failed SOP Instance UID List (0008,0058) is absent and therefore no Data Set shall be sent in the C-MOVE response.

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

The Identifier in a C-MOVE response with a status of:

  • Canceled, Failure, Refused, or Warning shall contain the Failed SOP Instance UID List Attribute

  • Pending shall not contain the Failed SOP Instance UID List Attribute (no Data Set)

C.4.2.1.5 Status

Table C.4-2 defines the specific status code values that might be returned in a C-MOVE response. General status code values and fields related to status code values are defined in PS3.7.

Table C.4-2. C-MOVE Response Status Values

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,1021)

(0000,1022)

(0000,1023)

Refused: Move Destination unknown

A801

(0000,0902)

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

B000

(0000,1021)

(0000,1022)

(0000,1023)

Success

Sub-operations Complete - No Failures

0000

(0000,1021)

(0000,1022)

(0000,1023)

Pending

Sub-operations are continuing

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


C.4.2.1.6 Number of Remaining Sub-Operations

Inclusion of the Number of Remaining Sub-operations is conditional based upon the status in the C-MOVE response. The Number of Remaining Sub-operations specifies the number of Remaining C-STORE sub-operations necessary to complete the C-MOVE operation.

A C-MOVE response with a status of:

  • Pending shall contain the Number of Remaining Sub-operations Attribute

  • Canceled may contain the Number of Remaining Sub-operations Attribute

  • Warning, Failure, or Success shall not contain the Number of Remaining Sub-operations Attribute

C.4.2.1.7 Number of Completed Sub-Operations

Inclusion of the Number of Completed Sub-operations is conditional based upon the status in the C-MOVE response. The Number of Completed sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that have completed successfully.

A C-MOVE response with a status of:

  • Pending shall contain the Number of Completed Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Completed Sub-operations Attribute

C.4.2.1.8 Number of Failed Sub-Operations

Inclusion of the Number of Failed Sub-operations is conditional based upon the status in the C-MOVE response. The Number of Failed sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that have Failed.

A C-MOVE response with a status of:

  • Pending shall contain the Number of Failed Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Failed Sub-operations Attribute

C.4.2.1.9 Number of Warning Sub-Operations

Inclusion of the Number of Warning Sub-operations is conditional based upon the status in the C-MOVE response. The Number of Warning sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that had a status of warning.

A C-MOVE response with a status of:

  • Pending shall contain the Number of Warnings Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Warning Sub-operations Attribute

C.4.2.2 C-MOVE SCU Behavior

This Section discusses both the baseline and extended behavior of the C-MOVE SCU.

C.4.2.2.1 Baseline Behavior of SCU

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

  • The SCU shall supply a single value in the Unique Key Attribute for each level above the Query/Retrieve level. For the level of retrieve, the SCU shall supply a single value for one unique key if the level of retrieve is above the STUDY level and shall supply one UID, or a list of UIDs if a retrieval of several items is desired and the retrieve level is STUDY, SERIES or IMAGE. The SCU shall also supply a move destination. The move destination shall be the DICOM Application Entity Title of a DICOM Application Entity capable of serving as the SCP of the Storage Service Class.

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

  • The SCU shall interpret responses with a status equal to Success, Warning, Failure, or Refused as final responses. The final response shall indicate the number of Successful C-STORE sub-operations and the number of Failed C-STORE sub-operations resulting from the C-MOVE operation. The SCU shall interpret a status of:

    • Success to indicate that all sub-operations were successfully completed

    • Warning to indicate one or more sub-operations were successfully completed and one or more sub-operations were unsuccessful or had a status of warning, or all sub-operations had a status of warning

    • Failure or Refused to indicate all sub-operations were unsuccessful.

  • 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 SCU shall interpret a C-MOVE response with a status of Canceled to indicate the transfer was canceled. The C-MOVE 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-MOVE-CANCEL request.

C.4.2.2.2 Extended Behavior of SCU

Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be performed with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:

  • Relational-retrieve

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.2.2.2.1 Relational-Retrieve

The C-MOVE Service with relational-retrieve removes the restriction that the SCU supply Unique Key values for levels above the Query/Retrieve level to identify an entity at the level of the retrieval. Hence, the Identifier of a C-MOVE request may transfer:

  • all Composite Object Instances related to a study by only providing a Study Instance UID (0020,000D)

  • all Composite Object Instances related to a series by only providing a Series Instance UID (0020,000E)

  • individual Composite Object Instances by only providing a list of SOP Instance UIDs (0008,0018)

C.4.2.2.2.2 Enhanced Multi-Frame Image Conversion

The C-MOVE Service with Enhanced Multi-Frame Image Conversion allows for selection of the default or an alternative view of the instances represented by the Information Model, and hence the retrieval of either the legacy or the converted images, together with any unconverted instances, all of which are required to be processed to maintain referential integrity within the scope of the Patient.

Support for Enhanced Multi-Frame Image Conversion allows the SCU to specify the Attribute Query/Retrieve View (0008,0053) in the Request Identifier with a value of either "CLASSIC" or "ENHANCED".

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCU requests that the SCP provide all the requested instances it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCU requests that the SCP provide all the Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCU requests that the SCP provide all the Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The SCU may assume that no duplicate information will be provided. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-MOVE will not provide both series.

  2. The Query Information Model is unchanged, and the same unique keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. The Query/Retrieve View is still required in an IMAGE or SERIES level request identifier, even though the requested unique key(s) are unambiguous, and the view is in a sense "redundant", because the conversion that created the requested instances may not have been executed yet. It is not permitted to specify a view that is inconsistent with the requested unique key(s).

C.4.2.3 C-MOVE SCP Behavior

This section discusses both the baseline and extended behavior of the C-MOVE SCP.

C.4.2.3.1 Baseline Behavior of SCP

An SCP conveys the following semantics with a C-MOVE 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-MOVE request. The SCP shall initiate C-STORE sub-operations for the corresponding storage SOP Instances. These C-STORE sub-operations shall occur on a different Association (that may already exist) from the C-MOVE operation. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the Storage Service Class.

  • The SCP shall either reuse an established and compatible Association or establish a new Association for the C-STORE sub-operations. The SCP shall initiate C-STORE sub-operations over that Association for all stored SOP Instances related to the Patient ID, List of Study Instance UIDs, List of Series Instance UIDs, or List of SOP Instance UIDs depending on the Query/Retrieve level specified in the C-MOVE request. A sub-operation is considered Failed if the SCP is unable to negotiate an appropriate presentation context for a given stored SOP Instance.

  • Optionally, the SCP may generate responses to the C-MOVE with status equal to Pending during the processing of the C-STORE sub-operations. These responses shall indicate the Remaining, Completed, Failed, 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, Failure, or Refused. This response shall indicate the number of Completed sub-operations, the number of Failed sub-operations, and the number of sub-operations with Warning Status. The status contained in the C-MOVE response shall contain:

    • Success if all sub-operations were successfully completed

    • Warning if one or more sub-operations were successfully completed and one or more sub-operations were unsuccessful or had a warning status

    • Warning if all sub-operations had a warning status

    • Failure or Refused if all sub-operations were unsuccessful

  • The SCP may receive a C-MOVE-CANCEL request at any time during the processing of the C-MOVE. The SCP shall interrupt all C-STORE sub-operation processing and return a status of Canceled in the C-MOVE response. The C-MOVE 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-MOVE-CANCEL request.

  • If the SCP manages images in multiple alternate encodings (see Section C.6.1.1.5.1), only one of the alternate encodings of an image shall be included in the set of object instances retrieved by a C-MOVE request at the Patient, Study, or Series level.

    Note

    For retrieval of images with alternate encodings using a C-MOVE request at the Patient, Study, or Series level, the SCP may select the appropriately encoded Instance for the retrieval based on identity of the SCU, transfer syntaxes accepted in the C-STORE Association Negotiation, or other factors.

Note

If the association on which the C-MOVE operation was issued is abnormally terminated, then it will not be possible to issue any further pending responses nor a final response, nor will C-MOVE-CANCEL requests be received. The behavior of the C-MOVE SCP acting as a C-STORE SCU is undefined in this condition. Specifically, whether or not any uncompleted C-STORE sub-operations continue is undefined.

C.4.2.3.2 Extended Behavior of SCP

Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:

  • Relational-retrieve

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.2.3.2.1 Relational-Retrieve

The C-MOVE Service with relational-retrieve removes the restriction that the SCU supply Unique Key values for levels above the Query/Retrieve level to help identify an entity at the level of the retrieval. Hence, the Identifier of a C-MOVE request may specify the transfer of:

  • all Composite Object Instances related to a study by only providing a Study Instance UID (0020,000D)

  • all Composite Object Instances related to a series by only providing a Series Instance UID (0020,000E)

  • individual Composite Object Instances by only providing a list of SOP Instance UIDs (0008,0018)

C.4.2.3.2.2 Enhanced Multi-Frame Image Conversion

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then 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-MOVE request that correspond to the instances it possesses, as received, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then 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-MOVE request that correspond to the Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then 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-MOVE request that correspond to the Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

Note

  1. The SCP will not send information that is duplicated to the C-STORE SCP. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-MOVE will not send both series.

  2. The C-STORE SCP will need to support the necessary SOP Classes for converted instances, otherwise the C-STORE sub-operations will fail in the normal manner and this will be reflected in the C-MOVE responses.

  3. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  4. The Query/Retrieve View is still required in an IMAGE or SERIES level request identifier, even though the requested unique key(s) are unambiguous.

C.4.3 C-GET Operation

SCUs of some SOP Classes of the Query/Retrieve Service Class may generate retrievals using the C-GET operation as described in PS3.7. The C-GET operation allows an application entity to instruct another application entity to transfer stored SOP Instances 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.

A C-GET request may be performed to any level of the Query/Retrieve Information Model. However, the transfer of stored SOP Instances may not be performed at this level. The level at which the transfer is performed depends upon the SOP Class.

C.4.3.1 C-GET Service Parameters

C.4.3.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.

C.4.3.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.

C.4.3.1.3 Identifier

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

Note

The Identifier is specified as U in the definition of the C-GET primitive in PS3.7 but is specialized for use with this service.

C.4.3.1.3.1 Request Identifier Structure

An Identifier in a C-GET request shall contain:

  • Query/Retrieve Level (0008,0052), which defines the level of the retrieval

  • Unique Key Attributes, which may include Patient ID (0010,0020), Study Instance UIDs (0020,000D) Series Instance UIDs (0020,000E), and SOP Instance UIDs (0008,0018)

  • Conditionally, the Attribute Query/Retrieve View (0008,0053). This Attribute may be included if Enhanced Multi-Frame Image Conversion has been accepted during Association Extended Negotiation. It shall not be included otherwise.

Specific Character Set (0008,0005) shall be present if Patient ID (0010,0020) is using a character set other than the default character repertoire.

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

Note

In the non-Relational behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching, but only Single Value Matching value may be specified for Patient ID (0010,0020).

C.4.3.1.3.2 Response Identifier Structure

The Failed SOP Instance UID List (0008,0058) specifies a list of UIDs of the C-STORE sub-operation SOP Instances for which this C-GET operation has failed. An Identifier in a C-GET response shall conditionally contain the Failed SOP Instance UID List (0008,0058) based on the C-GET response. If no C-STORE sub-operation failed, Failed SOP Instance UID List (0008,0058) is absent and therefore no Data Set shall be sent in the C-GET response.

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

The Identifier in a C-GET response with a status of:

  • Canceled, Failure, Refused, or Warning shall contain the Failed SOP Instance UID List Attribute

  • Pending shall not contain the Failed SOP Instance UID List Attribute (no Data Set)

C.4.3.1.4 Status

Table C.4-3 defines the specific status code values that might be returned in a C-GET response. General status code values and fields related to status code values are defined in PS3.7.

Table C.4-3. C-GET Response Status Values

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,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,1021)

(0000,1022)

(0000,1023)

Success

Sub-operations Complete - No Failures or Warnings

0000

(0000,1021)

(0000,1022)

(0000,1023)

Pending

Sub-operations are continuing

FF00

(0000,1020)

(0000,1021)

(0000,1022)

(0000,1023)


C.4.3.1.5 Number of Remaining Sub-Operations

Inclusion of the Number of Remaining Sub-operations is conditional based upon the status in the C-GET response. The Number of Remaining Sub-operations specifies the number of Remaining C-STORE sub-operations necessary to complete the C-GET operation.

A C-GET response with a status of:

  • Pending shall contain the Number of Remaining Sub-operations Attribute

  • Canceled may contain the Number of Remaining Sub-operations Attribute

  • Warning, Failure, or Success shall not contain the Number of Remaining Sub-operations Attribute.

C.4.3.1.6 Number of Completed Sub-Operations

Inclusion of the Number of Completed Sub-operations is conditional based upon the status in the C-GET response. The Number of Completed Sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that have completed successfully.

A C-GET response with a status of:

  • Pending shall contain the Number of Completed Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Completed Sub-operations Attribute

C.4.3.1.7 Number of Failed Sub-Operations

Inclusion of the Number of Failed Sub-operations is conditional based upon the status in the C-GET response. The Number of Failed Sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that have Failed.

A C-GET response with a status of:

  • Pending shall contain the Number of Failed Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Failed Sub-operations Attribute

C.4.3.1.8 Number of Warning Sub-Operations

Inclusion of the Number of Warning Sub-operations is conditional based upon the status in the C-GET response. The Number of Warning Sub-operations specifies the number of C-STORE sub-operations generated by the requested transfer that had a status of Warning.

A C-GET response with a status of:

  • Pending shall contain the Number of Warning Sub-operations Attribute

  • Canceled, Warning, Failure, or Success may contain the Number of Warning Sub-operations Attribute

C.4.3.2 C-GET SCU Behavior

This Section discusses both the baseline and extended behavior of the C-GET SCU.

C.4.3.2.1 Baseline Behavior of SCU

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

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

  • The SCU shall supply a single value in the Unique Key Attribute for each level above the Query/Retrieve level. For the level of retrieve, the SCU shall supply a single value for one unique key if the level of the retrieve is above the STUDY level and shall supply one UID, or a list of UIDs if a retrieval of several items is desired and the retrieve level is STUDY, SERIES or IMAGE.

  • The SCU shall interpret C-GET responses with status equal to Pending during the processing of the C-STORE sub-operations. These responses shall indicate the number of Remaining, Completed, Failed, 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 shall indicate 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:

    • Success to indicate that all sub-operations were successfully completed

    • Warning to indicate one or more sub-operations were successfully completed and one or more unsuccessful or all sub-operations had a status of warning

    • Failure or Refused to indicate all sub-operations were unsuccessful

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

C.4.3.2.2 Extended Behavior of SCU

Extended SCU behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCU behavior shall be supported with respect to that option. Extended SCU behavior includes all baseline behavior with the following option:

  • Relational-retrieve

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.3.2.2.1 Relational-Retrieve

The C-GET Service with relational-retrieve removes the restriction that the SCU supply Unique Key values for levels above the Query/Retrieve level to help identify an entity at the level of the retrieval. Hence, the Identifier of a C-GET request may retrieve:

  • all Composite Object Instances related to a study by providing a Study Instance UID (0020,000D)

  • all Composite Object Instances related to a series by providing a Series Instance UID (0020,000E)

  • individual Composite Object Instances by providing a list of SOP Instance UIDs (0008,0018)

C.4.3.2.2.2 Enhanced Multi-Frame Image Conversion

The C-GET Service with Enhanced Multi-Frame Image Conversion allows for selection of the default or an alternative view of the instances represented by the Information Model, and hence the retrieval of either the legacy or the converted images, together with any unconverted instances, all of which are required to be processed to maintain referential integrity within the scope of the Patient.

Support for Enhanced Multi-Frame Image Conversion allows the SCU to specify the Attribute Query/Retrieve View (0008,0053) in the Request Identifier with a value of either "CLASSIC" or "ENHANCED".

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then the SCU requests that the SCP retrieve all the requested instances it possesses, as received.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then the SCU requests that the SCP retrieve all the Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then the SCU requests that the SCP retrieve all the Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted.

Note

  1. The C-GET SCU acting as a C-STORE SCP may assume that no duplicate information will be provided. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-GET will not return both series.

  2. The C-GET SCU acting as a C-STORE SCP will need to support the necessary SOP Classes for converted instances, otherwise the C-STORE sub-operations will fail in the normal manner and this will be reflected in the C-GET responses.

  3. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  4. The Query/Retrieve View is still required in an IMAGE or SERIES level request identifier, even though the requested unique key (s) are unambiguous, and the view is in a sense "redundant", because the conversion that created the requested instances may not have been executed yet. It is not permitted to specify a view that is inconsistent with the requested unique key(s).

C.4.3.3 C-GET SCP Behavior

This Section discusses both the baseline and extended behavior of the C-GET SCP.

C.4.3.3.1 Baseline Behavior of SCP

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

  • 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 initiate C-STORE sub-operations for the corresponding storage SOP Instances. The SCP of the Query/Retrieve Service Class shall serve as an SCU of the Storage Service Class.

  • The SCP shall initiate C-STORE sub-operations over the same Association for all stored SOP Instances related to the Patient ID, List of Study Instance UIDs, List of Series Instance UIDs, or List of SOP Instance UIDs depending on the Query/Retrieve level specified in the C-GET request

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

    • Success if all sub-operations were successfully completed

    • Warning if one or more sub-operations were successfully completed and one or more sub-operations were unsuccessful or had a status of warning

    • Warning if all sub-operations had a status of Warning

    • Failure or Refused if all sub-operations were unsuccessful

  • 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 Section C.6.1.1.5.1), only one of the alternate encodings of an image shall be included in the set of object instances retrieved by a C-GET request at the Patient, Study, or Series level.

    Note

    For retrieval of images with alternate encodings using a C-GET request at the Patient, Study, or Series level, the SCP may select the appropriately encoded Instance for the retrieval based on identity of the SCU, transfer syntaxes accepted in the C-STORE Association Negotiation, or other factors.

C.4.3.3.2 Extended Behavior of SCP

Extended SCP behavior shall be negotiated at Association establishment time. If an option within the extended behavior is not agreed upon in the negotiation, then only baseline SCP behavior shall be performed with respect to that option. Extended SCP behavior includes all baseline behavior with the following option:

  • Relational-retrieve

  • Enhanced Multi-Frame Image Conversion

More than one option may be agreed upon.

C.4.3.3.2.1 Relational-Retrieve

The C-GET Service with relational-retrieve removes the restriction that the SCU supply Unique Key values for levels above the Query/Retrieve level to help identify an entity at the level of the retrieval. Hence, the Identifier of a C-GET request may retrieve:

  • all Composite Object Instances related to a study by providing a Study Instance UID

  • all Composite Object Instances related to a series by providing a Series Instance UID

  • individual Composite Object Instances by providing a list of SOP Instance UIDs

C.4.3.3.2.2 Enhanced Multi-Frame Image Conversion

If Query/Retrieve View (0008,0053) is not present in the Request Identifier, then 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 that correspond to the instances it possesses, as received, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

If Query/Retrieve View (0008,0053) is present with a value of "CLASSIC", then 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 that correspond to the Classic single frame Instances (converted from Enhanced multi-frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

If Query/Retrieve View (0008,0053) is present with a value of "ENHANCED", then 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 that correspond to the Enhanced multi-frame Instances (converted from Classic single frame Instances if required), as well as any instances that were converted to preserve referential integrity, and any that did not need to be converted, and shall initiate C-STORE sub-operations for all the corresponding storage SOP Instances.

Note

  1. The C-GET SCP acting as a C-STORE SCU will not send information that is duplicated to the C-GET SCU acting as a C-STORE SCP. For example, if an entire series of single frame instances can be converted to a separate series of converted instances, a STUDY level C-GET will not send both series.

  2. The Query Information Model is unchanged, and the same unique, required and optional keys are equally applicable to both views, except that the values for the SERIES and IMAGE level queries will be different and will depend on the converted instance content.

  3. The Query/Retrieve View is still required in an IMAGE or SERIES level request identifier, even though the requested unique key(s) are unambiguous.