Digital Imaging and Communications in Medicine (DICOM)

7.4 Query: Find 141
5. Sequence matching. This is perhaps the most complex form of DICOM attribute
matching. It is typically employed when an entire sequence of attributes
(formed with the SQ VR, see 5.3.10) is used to match data. For example,
to match a modality-scheduled patient study, DICOM uses a sequence
of attributes such as patient ID, study date, and accession number. Each
attribute in this sequence can have either exact values, or can use one of the
above matching types. Grouping attributes into an SQ sequence works as a
logical “and” (meaning that all attributes must match), as opposed to using
the backslash (\) wildcard as a logical “or”.
6. Single-value matching. This simply means using the exact attribute value as
the matching parameter: using “Smith” for patient name, “20000201” for
date, and so on. Naturally enough, single-value-matched attributes must
not contain wildcards or ranges. Single-value matching is commonly used
for various IDs and UIDs, and in particular for hierarchical key attributes
(see 5.6.3).
All attributes in DICOM data matching can be either required or optional.
Required attributes, as the name suggests, must be present in the matching
request. If we have no idea what their values might be, we simply insert
them with blank values (universal matching). This also implies that we are
guaranteed to receive the matched values. Optional attributes may be included
if we are interested in using them. The DICOM standard usually specifies required
and optional attributes for each query type (such as C-Find at the Patient,
Study, Series, or Image level), but you always need to check the DICOM
Conformance Statements for the devices you are querying; they commonly
override more generic DICOM specifications. This is understandable in part
because attributes used on an ultrasound scanner will definitely differ from
those used on a CT teaching archive. However, this always presents a certain
implementation headache when you have to deal with different query attribute
profiles for different devices.
Finally, nearly all matching in DICOM is case-sensitive. Case-insensitive
matches are permitted for certain attributes such as names (PN VR), where
they can also be space- and accent-insensitive. Personally, I doubt that casesensitivity
brings any advantages to DICOM whatsoever: first, cases can be easily
altered when typed, and second, they almost never matter. Worse, some
major PACS interfaces would require the users to enter certain data using a
certain case: for example, typing patient names in uppercase only. This quickly
turns into a major annoyance when patient Smith cannot be found unless you
type him as SMITH. Practically, it often forces users to “Caps Lock” their PACS
keyboards, which, as we can easily guess, inevitably creates an abundance of
other typing problems. Thus, whenever possible, DICOM and DICOM applications
should not be case-sensitive.