Digital Imaging and Communications in Medicine (DICOM)

120
7.2
Services and Data
Chapter 7 DICOM SOPs: Basic
The model of data processing and exchange adopted by DICOM is classy and
elegant; DICOM AEs provide services to each other. One DICOM entity can
request a service from another, and that entity provides service to the first. In
DICOM lingo, a service-requesting AE is viewed as an SCU, and a serviceproviding
AE is viewed as an SCP. In other words, AEs can play SCP or SCU
application roles to communicate with each other (Fig. 33).
As the SCP and SCU names suggest, all DICOM services are rendered on
the level of DICOM Service Classes. Service Classes in DICOM bind DICOM
data with data-processing functions. In more strict terms, DICOM Service
Class associates one or more DICOM IODs with one or more commands.
Consider printing digital images on film, for example. The DICOM Print Management
Service Class is responsible for printing (command) various images
(IODs, such as CT or MR images). Consequently, any DICOM printer can provide
this service (that is, act as a Print Management SCP). Any DICOM device
sending images to the printer requests the service (that is, acts as a Print Management
SCU).
In this section, we will become more acquainted with the structure and
meaning of DICOM services. I should point out that while the DICOM standard
is doing a particularly great job detailing the contents of its services, the
Fig. 33 SCU-SCP model