Annex C QUERY/RETRIEVE SERVICE CLASS (Normative)

C.1 Overview

C.1.1 Scope

The Query/Retrieve Service Class defines an application-level class-of-service which facilitates the simple management of composite object instances in a manner functionally similar to ACR-NEMA 300-1988. The types of queries which 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.

Note: Functional similarity to ACR-NEMA 300-1988 facilitates the migration to DICOM.

C.1.2 Conventions

The following conventions are used to define the types of keys used in Query/Retrieve Information Models.

Symbol Description
U Unique Key Attribute
R Required Key Attribute
O Optional Key Attribute

C.1.3 Query/retrieve Information Model

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

C.1.4 Service Definition

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 PS 3.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 which 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) A C-FIND service conveys the following semantics:

Note: 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 PS 3.7.

b) A C-MOVE service conveys the following semantics:

Note: This does not imply that they use the same AE Title. See C.6.1.2.2.2, C.6.2.2.2.2 and C.6.3.2.2.2 for the requirements to the C-MOVE SCP conformance.

c) A C-GET service conveys the following semantics:

C.2 Query/retrieve information model definition

The Query/Retrieve 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 Query/Retrieve 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 Query/Retrieve Service Class are defined in this Annex. A Query/Retrieve Information Model Definition contains:

C.2.1 Entity-Relationship Model Definition

For any Query/Retrieve Information Model, an Entity-Relationship Model defines a hierarchy of entities, with Attributes defined for each level in the hierarchy (e.g. Patient, Study, Series, Composite object instance)

C.2.2 Attributes Definition

Attributes shall be defined at each level in the Entity-Relationship Model. An Identifier in a C-FIND, C-MOVE, or C-GET command shall contain values to be matched against the Attributes of the Entities in a Query/Retrieve Information Model. For any query, the set of entities for which Attributes are returned, shall be determined by the set of Key Attributes specified in the Identifier which have corresponding matches on entities managed by the SCP associated with the query.

C.2.2.1 Attribute Types

All Attributes of entities in a Query/Retrieve Information Model shall be either a Unique Key, Required Key, or Optional Key. The term Key Attributes refers to Unique, Required, and Optional Key Attributes.

C.2.2.1.1 Unique Keys

At each level in the Entity-Relationship Model, one Attribute shall be defined as a Unique Key. A single value in a Unique Key Attribute shall uniquely identify a single entity at a given level. That is, two entities at the same level may not have the same Unique Key value.

C-FIND, C-MOVE, and C-GET SCPs shall support existence and matching of all Unique Keys defined by a Query/Retrieve Information Model. All entities managed by C-FIND, C-MOVE, and C-GET SCPs shall have a specific non-zero length Unique Key value.

Unique Keys may be contained in the Identifier of a C-FIND request. Unique Keys shall be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.1.2 Required Keys

At each level in the Entity-Relationship Model, a set of Attributes shall be defined as Required Keys. Required Keys imply the SCP of a C-FIND shall support matching based on a value contained in a Required Key of the C-FIND request. Multiple entities may have the same value for Required Keys. That is, a distinct value in a Required Key shall not necessarily identify a single entity at the level of the key.

C-FIND SCPs shall support existence and matching of all Required Keys defined by a Query/Retrieve Information Model. If a C-FIND SCP manages an entity with a Required Key of zero length, the value is considered unknown and all matching against the zero length Required Key shall be considered a successful match.

Required Keys may be contained in the Identifier of a C-FIND request. Required Keys shall not be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.1.3 Optional Keys

At each level in the Entity-Relationship Model, a set of Attributes shall be defined as Optional Keys.

Optional Keys contained in the Identifier of a C-FIND request may have three different types of behavior depending on support for existence and/or matching by the C-FIND SCP. If the C-FIND SCP:

Notes: 1. C-FIND SCU may not assume an Optional Key with non-zero length will be processed in the same manner as a Required Key. The Conformance Statement of the C-FIND SCP shall list the Optional Keys which are supported.

2. Optional Keys are differentiated from Required Keys in that Optional Keys may or may not be supported for existence and/or matching by C-FIND SCPs. Whereas, Required Keys must always be supported by C-FIND SCPs.

Optional Keys may be contained in the Identifier of a C-FIND request. Optional Keys shall not be contained in the Identifier of C-MOVE and C-GET requests.

C.2.2.2 Attribute Matching

The following types of matching may be performed on Key Attributes in the Query/Retrieve Service Class:

Matching requires special characters ( i.e. “*”,”?”,”-”, “=” and “\”) which need not be part of the character repertoire for the VR of the Key Attributes.

Notes: 1.For example, the “-“ character is not valid for the DA, DT and TM Vrs but is used for range matching.

2. When character sets other than the default character repertoire are used, then the rules in PS 3.5 apply, such as with respect to the use of the 05/12 “\” (BACKSLASH) (in ISO IR 6) or 05/12 “(” (YEN SIGN) (in ISO IR 14).

The total length of the Key Attribute may exceed the length as specified in the VR in PS 3.5. The Value Multiplicity (VM) may be larger than the VM specified in PS 3.6 for the Key Attribute, as defined for particular Matching Type.

The Specific Character Set (0008,0005) Attribute may be present in the Identifier but is never matched. Rather, it specifies how other Attributes are encoded in the Request and Response Identifiers.

It may influence how matching of other Attributes is performed. If Specific Character Set (0008,0005) is absent, then the default character repertoire shall be used. Specific Character Set (0008,0005) shall not have a zero length value.

Specific Character Set (0008,0005) may have multiple values if escape sequences are used to switch between character repertoires within values.

If the SCP does not support the value(s) of Specific Character Set (0008,0005) in the Request Identifier, then the manner in which matching is performed is undefined and shall be specified in the conformance statement.

Notes: 1. If an SCU sends a Request Identifier with a single byte character set not supported by the SCP, then it is likely, but not required, that the SCP will treat unrecognized characters as wildcards and match only on characters in the default repertoire, and return a response in the default repertoire.

2. Some Specific Character Set values are used with multi-component group person names (e.g., single-byte, ideographic and phonetic and phonetic component groups separated by an “=” (3DH) character), which may also affect the behavior of literal string matching.

The Timezone Offset From UTC (0008,0201) attribute may be present in the Identifier but is not matched if Timezone query adjustment is negotiated. If Timezone query adjustment is negotiated, it specifies how date and time Attribute values are interpreted in the Request and Response Identifiers if those values lack a specific time zone offset specification.

C.2.2.2.1 Single Value Matching

If the value specified for a Key Attribute in a request is non-zero length and if it is:

a) not a date or time or datetime, contains no wild card characters

b) a date or time or datetime, contains a single date or time or datetime with no “-“

then single value matching shall be performed. Except for Attributes with a PN Value Representation, only entities with values which match exactly the value specified in the request shall match. This matching is case-sensitive, i.e., sensitive to the exact encoding of the key attribute value in character sets where a letter may have multiple encodings (e.g., based on its case, its position in a word, or whether it is accented).

For Attributes with a PN Value Representation (e.g., Patient Name (0010,0010)), an application may perform literal matching that is either case-sensitive, or that is insensitive to some or all aspects of case, position, accent, or other character encoding variants.

Note: For multi-component names, the component group delimiter “=” (3DH) may be present in the Key Attribute value, but may give unexpected results if the SCP does not support matching on separate components but interprets the entire value literally as a single string. E.g., “Wang^XiaoDong=王^小東” may or may not match “Wang^XiaoDong” or “王^小東”; wildcard matching without the component group delimiter, such as “*Wang^XiaoDong*” or “*王^小東 *” may be necessary.

If extended negotiation of fuzzy semantic matching rather than literal matching of PN Value Representation is successful, not only may matching be insensitive to case, position, accent, and character encoding, but in addition other techniques such as phonetic matching may be applied.

If the Timezone Offset From UTC (0008,0201) attribute is present in the Identifier and Timezone query adjustment was negotiated, it shall be used to adjust values of time attributes (and associated date attributes, if present) from the local timezone to UTC. It shall also adjust values of datetime attributes that do not specify a timezone offset. The encoding and semantics of the Timezone Offset From UTC (0008,0201) attribute shall be as defined in the SOP Common Module in PS3.3.

The manner in which matching is performed is implementation dependent and shall be specified in the conformance statement.

Notes: 1. This definition implies that dates or times or datetimes are matched by their meaning, not as literal strings. For example:

2. If an application is concerned about how single value matching of dates and times is performed by another application, it may consider using range matching instead, which is always performed by meaning, with both values in the range the same.

3. Exclusion of the “-“ character for single value matching implies that a Key Attribute with DT Value Representation may not contain a negative offset from Universal Coordinated Time (UTC) if single value matching is intended. Use of the “-“ character in date, time or datetime indicates range matching.

4. If an application is in a local time zone that has a negative offset then it cannot perform single value matching using a local time notation. Instead, it can convert the Key Attribute value to UTC and use an explicit suffix of “+0000”.

5. Matching of PN Attributes may be accent-insensitive, as specified in the conformance statement. Accent-insensitive matching would successfully match, for instance, a query character “SMALL LETTER a” (06/01 in the default ISO-IR 6) with

“SMALL LETTER a WITH GRAVE ACCENT” (14/00 in ISO-IR 100),

“SMALL LETTER a WITH TILDE” (14/03 in ISO-IR 100),

“SMALL LETTER a WITH BREVE” (14/03 in ISO-IR 101), and

“CAPITAL LETTER a WITH ACUTE ACCENT” (12/01 in ISO-IR 100) (if matching is also case-insensitive),

but would not match 14/00 in ISO-IR 101, which is “SMALL LETTER r WITH ACUTE ACCENT”. Matching to particular bit-combinations is specific to each supported character set (note the difference in meaning of 14/00), and should be described in the conformance statement.

6. An SCU application may elect to perform additional filtering of the responses by applying the matching rules itself. In the event that both the SCU and SCP are applying the matching rules, this process will be successful as long as literal matching is performed by both, and any additional SCU filtering is insensitive to case, position, accent, or other character encoding variants.

However if fuzzy semantic matching of PN Attributes has been negotiated, matching by the SCP may result in responses that are not obviously related to the request, hence care should be taken if any additional filtering of responses is performed by the SCU. For example, if phonetic matching is performed, a query for “Swain” might well return “Swayne”, or if name component order insensitive matching is performed, a query for “Smith^Mary” might well return “Mary^Smith” or “Mary Smith” or “Smith, Mary”. Fuzzy semantic matching may also take into account separate single-byte, ideographic and phonetic name component groups.

C.2.2.2.2 List of UID Matching

A List of UIDs is encoded by using the value multiplicity operator, backslash (“\”), as a delimiter between UIDs. Each item in the list shall contain a single UID value. Each UID in the list contained in the Identifier of the request may generate a match.

Note: A list of single values is encoded exactly as a VR of UI and a VM of Multiple (see PS 3.5).

C.2.2.2.3 Universal Matching

If the value specified for a Key Attribute in a request is zero length, then all entities shall match this Attribute. An Attribute which contains a Universal Match specification in a C-FIND request provides a mechanism to request the selected Attribute value be returned in corresponding C-FIND responses.

C.2.2.2.4 Wild Card Matching

If the Attribute is not a date, time, signed long, signed short, unsigned short, unsigned long, floating point single, floating point double, other byte string, other word string, unknown, attribute tag, decimal string, integer string, age string or UID and the value specified in the request contains any occurrence of an “*” or a “?”, then “*” shall match any sequence of characters (including a zero length value) and “?” shall match any single character. This matching is case sensitive, except for Attributes with an PN Value Representation (e.g., Patient Name (0010,0010)).

For attributes with a PN value representation, including the case of extended negotiation of fuzzy semantic matching, wild card matching is implementation dependent and shall be specified in the conformance statement.

Notes: 1. Wild card matching on a value of “*” is equivalent to universal matching.

2. The wild card matching method specified by DICOM might not be supported by some non-DICOM multi-byte character text processors.

3. For multi-component group names, the component group delimiter “=” (3DH) may be present in the Key Attribute value, but may give unexpected results if the SCP does not support matching on separate components but interprets the entire value literally. E.g., “*=*” or “*=*=*” may or may not return all strings, and hence is not equivalent to “*”, nor to universal matching.

C.2.2.2.5 Range Matching

In the absence of extended negotiation, if the Attribute is a date, then:

a) A string of the form “<date1> - <date2>”, where <date1> is less or equal to <date2>, shall match all occurrences of dates which fall between <date1> and <date2> inclusive

b) A string of the form “- <date1>” shall match all occurrences of dates prior to and including <date1>

c) A string of the form “<date1> -“ shall match all occurrences of <date1> and subsequent dates

In the absence of extended negotiation, if the Attribute is a time, then:

a) A string of the form “<time1> - <time2>”, where <time1> is less or equal to <time2>, shall match all occurrences of times which fall between <time1> and <time2> inclusive

b) A string of the form “- <time1>” shall match all occurrences of times prior to and including <time1>

c) A string of the form “<time1> -“ shall match all occurrences of <time1> and subsequent times

If the Attribute is a datetime, then:

a) A string of the form “<datetime1> - <datetime2>”, where <datetime1> is less or equal to <datetime2>, shall match all moments in time which fall between <datetime1> and <datetime2> inclusive

b) A string of the form “- <datetime1>” shall match all moments in time prior to and including <datetime1>

c) A string of the form “<datetime1> -“ shall match all moments in time subsequent to and including <datetime1>

  1. The offset from Universal Coordinated Time, if present in the Value of the Attribute, shall be taken into account for the purposes of the match.

If extended negotiation of combined datetime matching is successful, then a pair of Attributes that are a date and a time, both of which specify the same form of range matching, shall have the concatenated string values of each range matching component matched as if they were a single datetime Attribute.

Note: For example, a Study Date of “20060705-20060707” and a Study Time of “1000-1800” will match the time period of July 5, 10am until July 7, 6pm, rather than the three time periods of 10am until 6pm on each of July 5, July 6 and July 7, as would be the case without extended negotiation.

Regardless of other extended negotiation, an application may use the value of Timezone Offset From UTC (0008,0201) to adjust values of time and datetime attributes from the local timezone to UTC for matching. See C.2.2.2.1.

Note: If extended negotiation of combined datetime matching is successful, the timezone offset may effect a change in date if the local time and UTC are on different sides of midnight.

Range matching is not defined for types of Attributes other than dates and times.

C.2.2.2.6 Sequence Matching

If a Key Attribute in the Identifier of a C-FIND request needs to be matched against an Attribute structured as a Sequence of Items (Value Representation of Type SQ), the Key Attribute shall be structured as a Sequence of Items with a single Item. This Item may contain zero or more Item Key Attributes. Each Item Key Attribute matching shall be performed on an Item by Item basis. The types of matching defined in Section C.2.2.2 shall be used: Single Value Matching, List of UID Matching, Universal Matching, Wild Card Matching, Range Matching and Sequence Matching (recursive Sequence matching)

If all the Item Key Attributes match, for at least one of the Items of the Attribute against which the match is performed, a successful match is generated. A sequence of matching Items containing only the requested attributes is returned in the corresponding C-FIND responses.

If the Key Attribute in the Identifier of a C-FIND request contains no Key Item Attribute (zero-length Item Tag), then all entities shall match this Attribute. This provides a universal matching like mechanism to request that the selected Key Attribute value (the entire Sequence of Items) be returned in corresponding C-FIND responses.

C.2.2.3 Matching Multiple Values

When matching an Attribute which has a value multiplicity of greater than one, if any of the values match, then all values shall be returned.

C.3 Standard query/retrieve information models

Three standard Query/Retrieve Information Models are defined in this Annex. Each Query/Retrieve Information Model is associated with a number of SOP Classes. The following three hierarchical Query/Retrieve Information Models are defined:

C.3.1 Patient Root Query/Retrieve Information Model

The Patient Root Query/Retrieve Information Model is based upon a four level hierarchy:

The patient level is the top level and contains Attributes associated with the Patient Information Entity (IE) of the Composite IODs as defined in PS 3.3. Patients IEs are modality independent.

The study level is below the patient level and contains Attributes associated with the Study IE of the Composite IODs as defined in PS 3.3. A study belongs to a single patient. A single patient may have multiple studies. Study IEs are modality independent.

The series level is below the study level and contains Attributes associated with the Series, Frame of Reference and Equipment IEs of the Composite IODs as defined in PS 3.3. A series belongs to a single study. A single study may have multiple series. Series Ies are modality dependent. To accommodate this modality dependence, the set of Optional Keys at the series level includes all Attributes defined at the series level from any Composite IOD defined in PS 3.3.

The lowest level is the composite object instance level and contains Attributes associated with the Composite object IE of the Composite IODs as defined in PS 3.3. A composite object instance belongs to a single series. A single series may contain multiple composite object instances. Most composite object IEs are modality dependent. To accommodate this potential modality dependence, the set of Optional Keys at the composite object instance level includes all Attributes defined at the composite object instance level from any Composite IOD defined in PS 3.3.

C.3.2 Study Root Query/Retrieve Information Model

The Study Root Query/Retrieve Information Model is identical to the Patient Root Query/Retrieve Information Model except the top level is the study level. Attributes of patients are considered to be Attributes of studies.

C.3.3 Patient/Study Only Query/Retrieve Information Model

Retired. See PS 3.4 2004.

C.3.4 Additional Query/Retrieve Attributes

Some optional attributes that may be used in Query/Retrieve Information Models that are not Attributes of an Information Object Definition and, therefore, are not defined in PS 3.3. These attributes are defined in Table C.3-1.

Table C.3-1 ADDITIONAL QUERY/RETRIEVE ATTRIBUTES

Attribute Name Tag Attribute Description
Number of Patient Related Studies (0020,1200) The number of studies that match the Patient level Query/Retrieve search criteria
Number of Patient Related Series (0020,1202) The number of series that match the Patient level Query/Retrieve search criteria
Number of Patient Related Instances (0020,1204) The number of composite object instances that match the Patient level Query/Retrieve search criteria
Number of Study Related Series (0020,1206) The number of series that match the Study level Query/Retrieve search criteria
Number of Series Related Instances (0020,1209) The number of composite object instances in a Series that match the Series level Query/Retrieve search criteria
Number of Study Related Instances (0020,1208) The number of composite object instances that match the Study level Query/Retrieve search criteria
Modalities in Study (0008,0061) All of the distinct values used for Modality (0008,0060) in the Series of the Study.
SOP Classes in Study (0008,0062) The SOP Classes contained in the Study.
Alternate Representation Sequence (0008,3001) A Sequence of Items, each identifying an alternate encoding of an image that matches the Instance level Query/Retrieve search criteria (see C.6.1.1.5.1)

If the SCP manages images in multiple alternate encodings, only one of the alternate encodings of an image is included in the number of object instances.

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 PS 3.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 PS 3.5).

Note: The definition of a Data Set in PS 3.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:

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:

Notes: 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 C.2.2.1.3.

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:

Note: The File-Set concepts are used in PS 3.10.

Notes: 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 which 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:

C.4.1.1.4 Status

Table C.4-1 defines the specific status code values which might be returned in a C-FIND response. General status code values and fields related to status code values are defined in PS 3.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 which 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 which 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:

Notes: 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.

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:

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.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 which meet the requirements of the Hierarchical Search.

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

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.

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:

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

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

c) 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:

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:

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

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

c) 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 which match those in the C-FIND request.

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

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

Notes: 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.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 PS 3.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 which 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 which 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 C.4.2.1.4.2.

Note: The Identifier is specified as U in the definition of the C-MOVE primitive in PS 3.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:

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 Baseline 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:

C.4.2.1.5 Status

Table C.4-2 defines the specific status code values which might be returned in a C-MOVE response. General status code values and fields related to status code values are defined in PS 3.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:

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 which have completed successfully.

A C-MOVE response with a status of:

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 which have Failed.

A C-MOVE response with a status of:

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 which had a status of warning.

A C-MOVE response with a status of:

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:

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:

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:

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:

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

2. 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:

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:

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 PS 3.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 which 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 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.

C.4.3.1.3.1 Request Identifier Structure

An Identifier in a C-GET request shall contain:

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 Baseline 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:

C.4.3.1.4 Status

Table C.4-3 defines the specific status code values which might be returned in a C-GET response. General status code values and fields related to status code values are defined in PS 3.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:

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 which have completed successfully.

A C-GET response with a status of:

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 which have Failed.

A C-GET response with a status of:

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 which had a status of Warning.

A C-GET response with a status of:

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:

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:

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:

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:

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:

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:

C.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 Query/Retrieve Service Class, which include query services based on the C-FIND operation, may use SOP Class Extended Negotiation Sub-Item to negotiate options such as Relational-queries.

SOP Classes of the Query/Retrieve Service Class, which include retrieval services based on the C-MOVE and C-GET operations, may use the SOP Class Extended Negotiation Sub-Item to negotiate relational-retrieval.

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

C.5.1 Association Negotiation for C-FIND SOP Classes

The following negotiation rules apply to DICOM SOP Classes and Specialized DICOM SOP Classes of the Query/Retrieve Service Class which include the C-FIND operation.

The Association-requester (query SCU role) shall convey in the A-ASSOCIATE request:

The Association-acceptor (query SCP role) of an A-ASSOCIATE request shall accept:

C.5.1.1 SOP Class Extended Negotiation

The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application Association information defined by specific SOP Classes. This is achieved by defining the Service-class-application-information field. The Service-class-application-information field is used to define support for relational-queries, combined date time matching, and fuzzy semantic matching of person names.

This negotiation is optional. If absent, the default conditions shall be:

The Association-requester, for each SOP Class, may use one SOP Class Extended Negotiation Sub-Item. The SOP Class is identified by the corresponding Abstract Syntax Name (as defined by PS 3.7) followed by the Service-class-application-information field. This field defines either a single sub-field:

or three sub-fields:

The Association-acceptor shall return a single byte field (single sub-field) if offered a single byte field (single sub-field) by the Association-requester. The Association-acceptor may return either a single byte field (single sub-field) or a three byte field (three sub-fields) if offered a three byte field (three sub-fields) by the Association-requester. A one byte response to a three byte request means that the missing sub-fields shall be treated as 0 values.

The Association-acceptor, for each sub-field of the SOP Class Extended Negotiation Sub-Item offered, either accepts the Association-requester proposal by returning the same value (1) or turns down the proposal by returning the value (0)

If the SOP Class Extended Negotiation Sub-Item is not returned by the Association-acceptor then relational-queries are not supported over the Association (default condition).

If the SOP Class Extended Negotiation Sub-Items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE response.

C.5.1.1.1 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)

The SOP Class Extended Negotiation Sub-Item consists of a sequence of mandatory fields as defined by PS 3.7. Table C.5-1 defines the Service-class-application-information field for DICOM Query/Retrieve SOP Classes and Specialized DICOM Query/Retrieve SOP Classes which include the C-FIND operation. This field may be either one or three bytes in length (i.e., item bytes 2 and 3 are optional).

Table C.5-1— SOP CLASS EXTENDED NEGOTIATION SUB-ITEM (service-class-application-information field)—A-ASSOCIATE-RQ

Item Bytes Field Name Description of Field
1 Relational-queries This byte field defines relational-query support by the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – relational queries not supported 1 – relational queries supported
2 Date-time matching This byte field defines whether or not combined date and time attribute range matching is requested by the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – combined matching not requested 1 – combined matching requested
3 Fuzzy semantic matching of person names This byte field defines whether or not fuzzy semantic person name attribute matching is requested by the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – fuzzy semantic matching not requested 1 – fuzzy semantic matching requested
4 Timezone query adjustment This byte field defines whether or not the Attribute Timezone Offset From UTC (0008,0201) shall be used to adjust the query meaning for time and datetime fields in queries. 0 - Timezone query adjustment not requested 1 – Timezone query adjustment requested

C.5.1.1.2 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)

The SOP Class Extended Negotiation Sub-Item is made of a sequence of mandatory fields as defined by PS 3.7. Table C.5-2 defines the Service-class-application-information field for DICOM Query/Retrieve SOP Classes and Specialized DICOM Query/Retrieve SOP Classes which include the C-FIND operation. This field may be either one or three bytes in length (i.e., item bytes 2 and 3 are optional).

Table C.5-2—SOP CLASS EXTENDED NEGOTIATION SUB-ITEM(service-class-application-information field)—A-ASSOCIATE-AC

Item Bytes Field Name Description of Field
1 Relational-queries This byte field defines relational-query support for the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – relational-queries not supported 1 – relational-queries supported
2 Date-time matching This byte field defines whether or not combined date and time attribute range matching will be performed by the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – combined matching not performed 1 – combined matching performed
3 Fuzzy semantic matching of person names This byte field defines whether or not fuzzy semantic person name attribute matching will be performed by the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – fuzzy semantic matching not performed 1 – fuzzy semantic matching performed
4 Timezone query adjustment This byte field defines whether or not the Attribute Timezone Offset From UTC (0008,0201) shall be used to adjust the query meaning for time and datetime fields in queries. 0 – Timezone adjustment of queries not performed 1 – Timezone adjustment of queries performed

C.5.2 Association Negotiation for C-MOVE SOP Classes

The following negotiation rules apply to DICOM SOP Classes and Specialized DICOM SOP Classes of the Query/Retrieve Service Class which include the C-MOVE operation.

The Association-requester (retrieval SCU role) shall convey in the A-ASSOCIATE request:

The Association-acceptor (retrieval SCP role) of an A-ASSOCIATE request shall accept:

C.5.2.1 SOP Class Extended Negotiation

The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application Association information defined by specific SOP Classes. This is achieved by defining the Service-class-application-information field. The Service-class-application-information field is used to define support for relational-retrievals.

This negotiation is optional. If absent, the default condition shall be:

The Association-requester, for each SOP Class, may use one SOP Class Extended Negotiation Sub-Item. The SOP Class is identified by the corresponding Abstract Syntax Name (as defined by PS 3.7) followed by the Service-class-application-information field. This field defines:

The Association-acceptor, for each SOP Class Extended Negotiation Sub-Item offered, either accepts the Association-requester proposal by returning the same value (1) or turns down the proposal by returning the value (0).

If the SOP Class Extended Negotiation Sub-Item is not returned by the Association-acceptor then relational-retrievals are not supported (default condition)

If the SOP Class Extended Negotiation Sub-Items do not exist in the A-ASSOCIATE indication they shall be omitted in the A-ASSOCIATE response.

C.5.2.1.1 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-RQ)

The SOP Class Extended Negotiation Sub-Item consists of a sequence of mandatory fields as defined by PS 3.7. Table C.5-3 defines the Service-class-application-information field for DICOM Query/Retrieve SOP Classes and Specialized DICOM Query/Retrieve SOP Classes which include the C-MOVE and C-GET operations.

Table C.5-3—SOP CLASS EXTENDED NEGOTIATION SUB-ITEM(service-class-application-information field)—A-ASSOCIATE-RQ

Item Bytes Field Name Description of Field
1 Relational-retrieval This byte field defines relational-retrieval support by the Association-requester. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – relational-retrieval not supported 1 – relational-retrieval supported

C.5.2.1.2 SOP Class Extended Negotiation Sub-Item Structure (A-ASSOCIATE-AC)

The SOP Class Extended Negotiation Sub-Item consists of a sequence of mandatory fields as defined by PS 3.7. Table C.5-4 defines the Service-class-application-information field for DICOM Query/Retrieve SOP Classes and Specialized DICOM Query/Retrieve SOP Classes which include the C-MOVE and C-GET operations.

Table C.5-4—SOP CLASS EXTENDED NEGOTIATION SUB-ITEM(service-class-application-information field)—A-ASSOCIATE-AC

Item Bytes Field Name Description of Field
1 Relational-retrieval This byte field defines relational-retrieval support for the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values 0 – relational-retrievals not supported 1 – relational-retrievals supported

C.5.3 Association Negotiation for C-GET SOP Classes

When an SCP performs the C-GET operation it induces a C-STORE operation for the purpose of transmitting composite SOP Instances for Storage. This induced C-STORE operation (called a sub-operation) requires a switch from the C-GET Presentation Context to a Presentation Context that supports the specific C-STOREsub-operation.

The following negotiation rules apply to retrieval based DICOM Query/Retrieve SOP Classes and Specialized DICOM Query/Retrieve SOP Classes which include the C-GET operation.

The Association-requester (retrieve SCU role) in the A-ASSOCIATE request shall convey:

a) C-GET operation support with:

b) Induced Storage sub-operation support where the SOP Class (in the retrieval SCU role) is acting as a Storage SOP Class in the SCP Role. See Figure C.5-1. For each supported Storage SOP Class, the A-ASSOCIATE request contains:

[pic]

Figure C.5-1 AN EXAMPLE OF THE SUB-OPERATION SCU/SCP ROLES

Note: This negotiation does not place any requirements on the SCU-flag of the SCP/SCU Role Selection Negotiation Sub-Item. It may be set if the Association-requester supports the Storage Service Class in the SCU role.

The Association-acceptor (retrieve SCP role) in the A-ASSOCIATE response shall convey:

a) C-GET operation support with:

b) Induced Storage sub-operation support where the SOP Class (using the retrieval SCP role) is acting as a Storage SOP Class in the SCU Role. See Figure C.5-1. For each supported Storage SOP Class, the A-ASSOCIATE response contains both:

Note: The negotiation does not place any requirements on the SCU-flag of the SCP/SCU Role Selection Negotiation Sub-Item. It may be set if the Association-acceptor accepts the Storage SCP role. Figure C.5-2 illustrates an example of the retrieve (C-GET) negotiation.

Figure C.5-2 illustrates an example of the retrieve (C-GET) negotiation.

C.5.3.1 SOP Class Extended Negotiation

The SOP Class Extended Negotiation allows, at Association establishment, peer DICOM AEs to exchange application Association information defined by specific SOP Classes.

This is achieved by defining the Service-class-application-information field. The Service-class-application-information field is used to define support for relational-retrievals.

[pic] Figure C.5-2 AN EXAMPLE OF THE RETRIEVE (C-GET) NEGOTIATION

Extended negotiation for SOP Classes based on the retrieval services which include C-GET operations is identical to the negotiation defined for C-MOVE which is defined in Section C.5.2.1 of this Annex.

Extended negotiation for the SOP Classes of the Storage Service Class (for the C-STORE sub-operation) is defined in Annex B.

C.6 SOP class definitions

C.6.1 Patient Root SOP Class Group

In the Patient Root Query/Retrieve Information Model, the information is arranged into four levels which correspond to one of the four values in element (0008,0052) shown in Table C.6.1-1.

Table C.6.1-1 Query/Retrieve Level Values for Patient Root

Query/Retrieve Level Value in (0008,0052)
Patient Information PATIENT
Study Information STUDY
Series Information SERIES
Composite object instance Information IMAGE

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

C.6.1.1 Patient Root Query/Retrieve Information Model

C.6.1.1.1 E/R Model

The Patient Root Query/Retrieve Information Model may be represented by the entity relationship diagram shown in Figure C.6-1.

[pic]

Figure C.6-1 PATIENT ROOT QUERY/RETRIEVE INFORMATION MODEL E/R DIAGRAM

C.6.1.1.2 Patient Level

Table C.6-1 defines the Attributes at the Patient Query/Retrieve level of the Patient Root Query/Retrieve Information Model.

Notes: 1. A description of the attributes of this Information Model is contained in Section C.3 of this part.

2. Although the Patient ID may not be globally unique, the Study Instance UID is globally unique ensuring that no two studies may be misidentified.

Table C.6-1 PATIENT LEVEL ATTRIBUTES FOR THE PATIENT ROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Type
Patient’s Name (0010,0010) R
Patient ID (0010,0020) U
Issuer of Patient ID (0010,0021) O
Referenced Patient Sequence (0008,1120) O
>Referenced SOP Class UID (0008,1150) O
>Referenced SOP Instance UID (0008,1155) O
Patient’s Birth Date (0010,0030) O
Patient’s Birth Time (0010,0032) O
Patient’s Sex (0010,0040) O
Other Patient Ids (0010,1000) O
Other Patient Names (0010,1001) O
Ethnic Group (0010,2160) O
Patient Comments (0010,4000) O
Number of Patient Related Studies (0020,1200) O
Number of Patient Related Series (0020,1202) O
Number of Patient Related Instances (0020,1204) O
All other Attributes at Patient Level O

C.6.1.1.3 Study Level

Table C.6-2 defines the keys at the Study Information level of the Patient Root Query/Retrieve Information Model.

Notes: 1. A description of the attributes of this Information Model is contained in Section C.3 of this Part.

2. Although the Patient ID may not be globally unique, the Study Instance UID is globally unique ensuring that no two studies may be mis-identified.

Table C.6-2 STUDY LEVEL KEYS FOR THE PATIENT ROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Type
Study Date (0008,0020) R
Study Time (0008,0030) R
Accession Number (0008,0050) R
Study ID (0020,0010) R
Study Instance UID (0020,000D) U
Modalities in Study (0008,0061) O
SOP Classes in Study (0008,0062) O
Referring Physician’s Name (0008,0090) O
Study Description (0008,1030) O
Procedure Code Sequence (0008,1032) O
>Code Value (0008,0100) O
>Coding Scheme Designator (0008,0102) O
>Coding Scheme Version (0008,0103) O
>Code Meaning (0008,0104) O
Name of Physician(s) Reading Study (0008,1060) O
Admitting Diagnoses Description (0008,1080) O
Referenced Study Sequence (0008,1110) O
>Referenced SOP Class UID (0008,1150) O
>Referenced SOP Instance UID (0008,1155) O
Patient’s Age (0010,1010) O
Patient’s Size (0010,1020) O
Patient’s Weight (0010,1030) O
Occupation (0010,2180) O
Additional Patient History (0010,21B0) O
Other Study Numbers (0020,1070) O
Number of Study Related Series (0020,1206) O
Number of Study Related Instances (0020,1208) O
All other Attributes at Study Level O

C.6.1.1.4 Series Level

Table C.6-3 defines the keys at the Series Information level of the Patient Root Query/Retrieve Information Model.

Table C.6-3 SERIES LEVEL ATTRIBUTES FOR THE PATIENT ROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Type
Modality (0008,0060) R
Series Number (0020,0011) R
Series Instance UID (0020,000E) U
Number of Series Related Instances (0020,1209) O
All Other Attributes at Series Level O

Note: The Attribute Number of Series Related Instances is an optional key. It is, however recognized as a broadly needed key and return attribute which SCPs are strongly encouraged to support.

C.6.1.1.5 Composite object instance Level

Table C.6-4 defines the keys at the Composite object instance Information level of the Patient Root Query/Retrieve Information Model.

Table C.6-4 COMPOSITE OBJECT INSTANCE LEVEL KEYS FOR THE PATIENT ROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Type
Instance Number (0020,0013) R
SOP Instance UID (0008,0018) U
SOP Class UID (0008,0016) O
Alternate Representation Sequence (0008,3001) O
>Series Instance UID (0020,000E) O
>SOP Class UID (0008,1150) O
>SOP Instance UID (0008,1155) O
>Purpose of Reference Code Sequence (0040,A170) O
>>Code Value (0008,0100) O
>>Coding Scheme Designator (0008,0102) O
>>Coding Scheme Version (0008,0103) O
>>Code Meaning (0008,0104) O
Related General SOP Class UID (0008,001A) O
Concept Name Code Sequence (0040,A043) O
>Code Value (0008,0100) O
>Coding Scheme Designator (0008,0102) O
>Coding Scheme Version (0008,0103) O
>Code Meaning (0008,0104) O
Content Template Sequence (0040,A504) O
>Template Identifier (0040,DB00) O
>Mapping Resource (0008,0105) O
Container Identifier (0040,0512) O
Specimen Description Sequence (0040,0560) O
>Specimen Identifier (0040,0551) O
>Specimen UID (0040,0554) O
All Other Attributes at composite object instance Level O

Notes: 1. SOP Class UID (0008,0016) is an optional key, but it is strongly recommended that it always be returned by all SCPs, if matching is requested.

2. The Concept Name Code Sequence (0040,A043) and Content Template Sequence (0040,A504) are optional keys that are useful for identifying instances of various Structured Reporting Storage SOP Classes. It is strongly recommended that these keys be supported by the SCP for query against such instances.

C.6.1.1.5.1 Alternate Representation Sequence

The Alternate Representation Sequence (0008,3001) encodes a reference to an alternate encoding of the composite image identified in the Query response item. This alternate encoding may utilize a different SOP Class or have different image quality characteristics, but it shall be the same image.

Note: The Alternate Representation Sequence (0008,3001)allows the query response about an original image to reference a lossy compressed version, and vice versa.

An image may be lossy compressed, e.g., for long-term archive purposes, and its SOP Instance UID changed. An application processing a SOP Instance that references the original image UID, e.g., a Structured Report, may query the C-FIND SCP for the image. The SCP returns a reference to an accessible version of the image even if the original SOP Instance is no longer available.

The Alternate Representation Sequence (0008,3001), if present in a Query Request Identifier, shall be zero-length, or shall contain a single zero-length Item. That is, only Universal Matching is defined for this attribute.

The Alternate Representation Sequence (0008,3001), if present in the Query Response Identifier, may include zero or more Items. Each Alternate Representation Sequence Item in the Query Response Identifier shall include

C.6.1.1.6 Scope of the GET and MOVE Commands and Sub-Operations

A C-MOVE or C-GET request may be performed to any level of the Query/Retrieve Model. However, the transfer of Stored SOP Instances shall always take place at the Composite object instance level. A C-MOVE or C-GET where the Query/Retrieve level is the:

Note: In the Baseline 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.6.1.2 Conformance Requirements

An implementation may conform to one of the SOP Classes of the Patient Root SOP Class Group as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS 3.2.

C.6.1.2.1 SCU Conformance
C.6.1.2.1.1 C-FIND SCU Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group shall support queries against the Query/Retrieve Information Model described in Section C.6.1.1 using the baseline C-FIND SCU Behavior described in Section C.4.1.2.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall state in its Conformance Statement whether it supports Optional Keys. If it supports Optional Keys, then it shall list the Optional Keys which it supports.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall state in its Conformance Statement whether it may generate Relational-queries. If it supports Relational-queries, then it shall also support extended negotiation of relational-queries.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall state in its Conformance Statement whether or not it supports extended negotiation of combined date-time matching and/or fuzzy semantic matching of person names.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when encoding queries and interpreting responses.

C.6.1.2.1.2 C-MOVE SCU Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall support transfers against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-MOVE SCU Behavior described in Section C.4.2.2.

C.6.1.2.1.3 C-GET SCU Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU shall support retrievals against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-GET SCU Behavior described in Section C.4.3.2.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCU, 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.

C.6.1.2.2 SCP Conformance
C.6.1.2.2.1 C-FIND SCP Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group shall support queries against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-FIND SCP Behavior described in Section C.4.1.3.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports Optional Keys. If it supports Optional Keys, then it shall list the Optional Keys which it supports.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports Relational-queries. If it supports Relational-queries, then it shall also support extended negotiation of relational-queries.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall state in its Conformance Statement whether or not it supports extended negotiation of combined date-time matching and/or fuzzy semantic matching of person names. If fuzzy semantic matching of person names is supported, then the mechanism for fuzzy semantic matching shall be specified.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports case-insensitive matching for PN VR attributes and list attributes for which this applies.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when interpreting queries, performing matching and encoding responses.

C.6.1.2.2.2 C-MOVE SCP Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall support transfers against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-MOVE SCP Behavior described in Section C.4.2.3.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP, which generates transfers using the C-MOVE 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-MOVE.

C.6.1.2.2.3 C-GET SCP Conformance

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP shall support retrievals against the Query/Retrieve Information Model described in Section C.6.1.1 using the C-GET SCP Behavior described in Section C.4.3.3.

An implementation that conforms to one of the SOP Classes of the Patient Root SOP Class Group as an SCP, 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.

C.6.1.3 SOP Classes

The SOP Classes in the Patient Root Query SOP Class Group of the Query/Retrieve Service Class identify the Patient Root Query/Retrieve Information Model, and the DIMSE-C operations supported. The Standard SOP Classes are listed in Table C.6.1.3-1.

Table C.6.1.3-1 SOP Classes for Patient Root Query/Retrieve

SOP Class Name SOP Class UID
Patient Root Query/Retrieve Information Model – FIND 1.2.840.10008.5.1.4.1.2.1.1
Patient Root Query/Retrieve Information Model – MOVE 1.2.840.10008.5.1.4.1.2.1.2
Patient Root Query/Retrieve Information Model – GET 1.2.840.10008.5.1.4.1.2.1.3

C.6.2 Study Root SOP Class Group

In the Study Root Query/Retrieve Information Model, the information is arranged into three levels which correspond to one of the three values in element (0008,0052) shown in Table C.6.2-1.

Table C.6.2-1 Query/Retrieve Level Values for Study Root

Query/Retrieve Level Value in (0008,0052)
Study Information STUDY
Series Information SERIES
Composite object instance Information IMAGE

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

C.6.2.1 Study Root Query/Retrieve Information Model

C.6.2.1.1 E/R Model

The Study Root Query/Retrieve Information Model may be represented by the entity relationship diagram shown in Figure C.6-2.

[pic]

Figure C.6-2 STUDY ROOT QUERY/RETRIEVE INFORMATION MODEL E/R DIAGRAM

C.6.2.1.2 Study level

Table C.6-5 defines the keys at the Study Information level of the Study Root Query/Retrieve Information Model.

Notes: 1. A description of the attributes of this Information Model is contained in Section C.3.

2. Although the Patient ID may not be globally unique, the Study Instance UID is globally unique ensuring that no two studies may be mis-identified.

Table C.6-5STUDY LEVEL KEYS FOR THE STUDYROOT QUERY/RETRIEVE INFORMATION MODEL

Description Tag Type
Study Date (0008,0020) R
Study Time (0008,0030) R
Accession Number (0008,0050) R
Patient’s Name (0010,0010) R
Patient ID (0010,0020) R
Study ID (0020,0010) R
Study Instance UID (0020,000D) U
Modalities in Study (0008,0061) O
SOP Classes in Study (0008,0062) O
Referring Physician’s Name (0008,0090) O
Study Description (0008,1030) O
Procedure Code Sequence (0008,1032) O
>Code Value (0008,0100) O
>Coding Scheme Designator (0008,0102) O
>Coding Scheme Version (0008,0103) O
>Code Meaning (0008,0104) O
Name of Physician(s) Reading Study (0008,1060) O
Admitting Diagnoses Description (0008,1080) O
Referenced Study Sequence (0008,1110) O
>Referenced SOP Class UID (0008,1150) O
>Referenced SOP Instance UID (0008,1155) O
Referenced Patient Sequence (0008,1120) O
>Referenced SOP Class UID (0008,1150) O
>Referenced SOP Instance UID (0008,1155) O
Issuer of Patient ID (0010,0021) O
Patient’s Birth Date (0010,0030) O
Patient’s Birth Time (0010,0032) O
Patient’s Sex (0010,0040) O
Other Patient Ids (0010,1000) O
Other Patient Names (0010,1001) O
Patient’s Age (0010,1010) O
Patient’s Size (0010,1020) O
Patient’s Weight (0010,1030) O
Ethnic Group (0010,2160) O
Occupation (0010,2180) O
Additional Patient History (0010,21B0) O
Patient Comments (0010,4000) O
Other Study Numbers (0020,1070) O
Number of Patient Related Studies (0020,1200) O
Number of Patient Related Series (0020,1202) O
Number of Patient Related Instances (0020,1204) O
Number of Study Related Series (0020,1206) O
Number of Study Related Instances (0020,1208) O
All other Attributes at Study Level O

Note: The use of the word “Images” rather than “composite object instances” is historical, and should not be taken to mean that composite object instances of other than image type are not included in the number.

C.6.2.1.3 Series Level

Attributes for the Series Level of the Study Root Query/Retrieve Information Model are the same as the Attributes for the Series Level of the Patient Root Query/Retrieve Information Model described in Section C.6.1.1.4.

C.6.2.1.4 Composite object instance Level

Attributes for the Composite object instance Level of the Study Root Query/Retrieve Information Model are the same as the Attributes for the Composite object instance Level of the Patient Root Query/Retrieve Information Model described in Section C.6.1.1.5.

C.6.2.1.5 Scope of The GET and MOVE Commands and Sub-Operations

A C-MOVE or C-GET request may be performed to any level of the Query/Retrieve Model. However, the transfer of Stored SOP Instances shall always take place at the Composite object instance level. A C-MOVE or C-GET where the Query/Retrieve level is the:

Note: In the Baseline behavior, more than one entity may be retrieved if the Query/Retrieve Level is IMAGE, SERIES or STUDY, using List of UID matching,

C.6.2.2 Conformance Requirements

An implementation may conform to one of the SOP Classes of the Study Hierarchy SOP Class Group as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS 3.2.

C.6.2.2.1 SCU Conformance
C.6.2.2.1.1 C-FIND SCU Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group shall support queries against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-FIND SCU behavior described in Section C.4.1.2.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall state in its Conformance Statement whether it supports Optional Keys. If it supports Optional Keys, then it shall list the Optional Keys which it supports.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall be capable of generating queries using the Hierarchical Search. It shall not generate queries using Relational-queries unless the Relational-queries option has been successfully negotiated.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall state in its Conformance Statement whether it may generate Relational-queries. If it supports Relational Search, then it shall also support extended negotiation of relational-queries.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall state in its Conformance Statement whether or not it supports extended negotiation of combined date-time matching and/or fuzzy semantic matching of person names.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when encoding queries and interpreting responses.

C.6.2.2.1.2 C-MOVE SCU Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall support transfers against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-MOVE SCU Behavior described in Section C.4.2.2.

C.6.2.2.1.3 C-GET SCU Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU shall support retrievals against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-GET SCU Behavior described in Section C.4.3.2.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCU, 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.

C.6.2.2.2 SCP Conformance
C.6.2.2.2.1 C-FIND SCP Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group shall support queries against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-FIND SCP behavior described in Section C.4.1.3.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports Optional Keys. If it supports Optional Keys, then it shall list the Optional Keys which it supports.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports Relational Search. If it supports Relational Search, then it shall also support extended negotiation of relational-queries.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall state in its Conformance Statement whether or not it supports extended negotiation of combined date-time matching and/or fuzzy semantic matching of person names. If fuzzy semantic matching of person names is supported, then the mechanism for fuzzy semantic matching shall be specified.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall state in its Conformance Statement whether it supports case-insensitive matching for PN VR attributes and list attributes for which this applies.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall state in its Conformance Statement how it makes use of Specific Character Set (0008,0005) and Timezone Offset From UTC (0008,0201) when interpreting queries, performing matching and encoding responses.

C.6.2.2.2.2 C-MOVE SCP Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall support transfers against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-MOVE SCP Behavior described in Section C.4.2.3.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP, which generates transfers using the C-MOVE 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-MOVE.

C.6.2.2.2.3 C-GET SCP Conformance

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP shall support retrievals against the Query/Retrieve Information Model described in Section C.6.2.1 using the C-GET SCP Behavior described in Section C.4.3.3.

An implementation that conforms to one of the SOP Classes of the Study Root SOP Class Group as an SCP, 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.

C.6.2.3 SOP Classes

The SOP Classes in the Study Root SOP Class Group of the Query/Retrieve Service Class identify the Study Root Query/Retrieve Information Model, and the DIMSE-C operations supported. The Standard SOP Classes are listed in Table C.6.2.3-1.

Table C.6.2.3-1 SOP Classes for Study Root Query/Retrieve

SOP Class Name SOP Class UID
Study Root Query/Retrieve Information Model – FIND 1.2.840.10008.5.1.4.1.2.2.1
Study Root Query/Retrieve Information Model – MOVE 1.2.840.10008.5.1.4.1.2.2.2
Study Root Query/Retrieve Information Model – GET 1.2.840.10008.5.1.4.1.2.2.3

C.6.3 Patient/Study Only SOP Class Group

Retired. See PS 3.4 2004.