| DICOM PS3.4 2024d - Service Class Specifications |
|---|
The following types of matching may be performed on Key Attributes in the Query/Retrieve Service Class:
Matching requires special characters (i.e., "*","?","-", "=", "\", and QUOTATION MARK of the Default Character Repertoire), which need not be part of the character repertoire for the VR of the Key Attributes.
For example, the "-" character is not valid for the DA, DT and TM VRs but is used for Range Matching. The wild card characters "*" and "?" are not valid for the CS VR but are used for Wild Card Matching.
When character sets other than the Default Character Repertoire are used, then the rules in PS3.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 PS3.5. The Value Multiplicity (VM) may be larger than the VM specified in PS3.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.
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 wild cards and match only on characters in the default repertoire, and return a response in the default repertoire.
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 Attribute Values of VR of DT and TM (including related Attribute Values of VR of DA, if present) are interpreted in the Request and Response Identifiers if those values lack a specific time zone offset specification.
If the value specified for a Key Attribute in a request is non-zero length and if it is not of VR SQ and:
of VR of AE, CS, LO, LT, PN, SH, ST, UC, UR or UT and contains a single value with no wild card characters, and if Extended Negotiation of Empty Value Matching is successful and it does not have the value of exactly two QUOTATION MARK characters, or
of VR of DA, TM or DT and contains a single value with no "-" and no QUOTATION MARK characters, or
then Single Value Matching shall be performed. Except for Attributes with a PN VR, only entities with values that 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).
The following subsections define specifics for certain VRs.
For Attributes with a PN VR (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.
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 "王^小東"; Wild Card 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 VR is successful, not only may matching be insensitive to case, position, accent, and character encoding (including combining characters), but in addition other techniques such as phonetic matching may be applied.
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
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.
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.
The AE, LO, LT, PN, SH, ST, UC, UR and UT VRs allow the presence of wild card characters "*" and "?". Wild Card Matching is also defined for CS values. Single Value Matching against such characters is not supported. See Section C.2.2.2.4.
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 Attributes of VR of TM (and associated Attributes of VR of DA, if present) from the local timezone to UTC. It shall also adjust values of Attributes of VR of DT 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.
This definition implies that values of VR of TM, DA and DT are matched by their meaning, not as literal strings. For example:
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.
Exclusion of the "-" character for Single Value Matching implies that a Key Attribute with a VR of DT may not contain a negative offset from Universal Coordinated Time (UTC) if Single Value Matching is intended. Use of the "-" character in values of VR of TM, DA and DT indicates Range Matching.
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".
| DICOM PS3.4 2024d - Service Class Specifications |
|---|