Digital Imaging and Communications in Medicine (DICOM)

7.10 Matching Application Roles 167
your manufacturer that you do in fact have true DICOM C-Echo functionality
in your system interface.
7.9
Gentleman’s Toolkit
The C-Echo, C-Find, C-Store, and C-Get/C-Move protocols are by far the most
commonly used in all DICOM implementations. In fact, most DICOM devices
and software are completely based on these SOPs and do not implement anything
else. This makes perfect sense. If you can verify DICOM connectivity,
and you can find and transfer data between DICOM entities, you can consider
your system DICOM-capable.
Also, if you are involved in DICOM software development, bear in mind
that with proper SOP IODs and attributes you can squeeze a lot of functionality
out of those few services. What immediately comes to mind as one of the most
appreciated functions in any DICOM interface is the ability to perform keyword
searches in DICOM free-text fields. For example, searching for a study
description (element (0008,1030) in the DICOM Data Dictionary), which is
very commonly used in teaching archives as well as for clinical history.
Let’s have a closer look at just such an example. Suppose you wanted to
find all recent studies with the keywords “aneurism” or “endoleak” in their description.
If the list of your C-Find-supported attributes includes (0008,1030),
then you can set the (0008,1030) value to “aneurism\endoleak” and use it in a
C-Find-Rq message to find what you need. In fact, to include all potential word
form variations, you can even specify “*aneurism*\*endoleak*” to ensure that
all “aneurisms” and “wejustdonottypespacesendoleaks” will be found as well. As
you know by now, if you can C-Find something, you should be able to retrieve
it with C-Get or C-Move. In brief, with a few DICOM protocols and sufficient
attribute support you can become extremely flexible in your DICOM data management,
even if you are limited to hierarchical query/retrieve only.
7.10
Matching Application Roles
Before we conclude, let’s take another look at the SCU-SCP concept of DICOM
communications that was introduced at the beginning of 7.2. Folks with a
computer backgrounds tend to relate SCUs and SCPs to the well-known client–
server view of computer networks and applications: SCPs are treated as servers
and SCUs as clients. This is not exactly the case.
SCP-SCU is nothing but a role that any compatible AE can play depending
on the current situation; the role is what this particular application is doing
at this particular moment for another particular application. For example