DICOM PS3.4 2020c - Service Class Specifications

6.5 Service-Object Pair (SOP) Class (Current)
Prev | 6 DICOM Information Model | Next

## 6.5 Service-Object Pair (SOP) Class

The SOP Class definitions in PS3.4 contain the rules and semantics that may restrict the use of the services in the DIMSE Service Group or the Attributes of the IOD. PS3.10 and PS3.18 contain the rules and semantics that may restrict the attributes of the IOD or the use of the services in the Media Storage Services and the Web Services respectively.

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction for SOP Classes based on DIMSE Services. This negotiation is performed at Association establishment time as described in PS3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class.

### Note

1. The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the Managed Object Class. Readers familiar with object-oriented terminology will recognize the SOP Class operations (and notifications) as comprising the methods of an object class.

2. SOP Class Specifications play a central role in defining DICOM conformance. They allow DICOM Application Entities to select a well-defined application level subset of this Standard to which they may claim conformance. See PS3.2.

### 6.5.1 Normalized and Composite SOP Classes

DICOM defines two types of SOP Classes, Normalized and Composite. For DIMSE Services, Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services, while Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services. Media Storage Services only support Composite IODs and Web Services support both Normalized and Composite SOP Classes.

Prev | Up | Next
6.4 DIMSE Service Group | Home | 6.6 Association Negotiation

DICOM PS3.4 2020c - Service Class Specifications