SOP Class

A SOP (Service Object Pair) Class is a combination of a service such as Store, Retrieve, and an object such as an image. The class defines the rules on how to use these. A class is negotiated as a capability between devices during negotiation of the association. Analagy of a Class is a type of fruit, e.g. Granny Smith. A SOP Class is defined as a combination of one or more DICOM Service Element (DIMSE), which are commands, and an Object, which is defined by an Information Object Definition (IOD). Examples of Service Elements are Store, Get, Find, Move, etc. Examples of Objects are CT images, MR images, but also include schedule lists, print queues, etc. A class defines a certain functionality consisting of a combination of a Service and an Object, which make up the Pair – e.g. CT Storage is an example of an SOP Class. DICOM has two different types of services, the composite and normalized services. Each SOP class is part of either the composite family or the normalized family. The DIMSE commands are identified as either composite or normaiized commends, e.g. there is a C_Get and N_GET. The composite commands operate on objects that are composed of several real world entities. A normalized object, however, consists of a single real world entity.Each DICOM standard SOP Class is identified with a Unique Identifier (UID). These SOP Class UIDs are issued by NEMA so that they can be used by the software that performs the actual negotiation, as well as to specify which SOP class it represents. It is critical to match up the UIDs between a sender and receiver, because the description of the SOP Classes can be very similar, such as in the case of the new and old versions of some of the SOP classes. The SOP class UIDs specify precisely which standardized DICOM services and objects are being used.