DICOM PS3.2 2025b - Conformance
7.3 Rules Governing Types of SOP Classes (Current)
Prev  7 Conformance Requirements  Next
PS3.2 > Conformance Requirements > Rules Governing Types of SOP Classes

7.3 Rules Governing Types of SOP Classes

Each SOP Class published in a Conformance Statement is one of four basic types. Each SOP Class in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of SOP Class.

Standard SOP Classes conform to all relevant Parts of the DICOM Standard with no additions or changes.

To claim conformance to a Standard SOP Class, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.

Standard Extended SOP Classes shall:

  1. be a proper super set of one Standard SOP Class;

  2. not change the semantics of any Standard Attribute of that Standard SOP Class;

  3. not contain any Private Type 1, 1C, 2, or 2C Attributes, nor add additional Standard Type 1, 1C, 2 or 2C Attributes;

  4. not change any Standard Type 3 Attributes to Type 1, 1C, 2, or 2C;

  5. use the same UID as the Standard SOP Class on which it is based.

A Standard Extended SOP Class may include Standard and/or Private Type 3 Attributes beyond those defined in the IOD on which it is based as long as the Conformance Statement identifies the added Attributes and defines their relationship with the PS3.3 information model. If additional Type 3 Attributes drawn from the Data Dictionary in PS3.6 are sent that affect the encoding of other Attributes, or whose encoding depends on the values of other Attributes, their presence and use shall be consistent.

Note

E.g., An Attribute such as Pixel Padding Value (0028,0120) with a dictionary VR of US or SS would not be allowed to be present without Pixel Representation (0028,0103) also being present to resolve the encoding ambiguity. Further, Pixel Padding Value would not be allowed to be present in the absence of the Pixel Data (7FE0,0010) to which it applies.

An implementation claiming conformance with a Standard Extended SOP Class shall identify in its Conformance Statement the Standard SOP Class being extended, the options, roles, and behavior selected, and describe the Attributes being added with the Standard SOP Class's IOD Model and Modules.

Specialized SOP Classes shall:

  1. be completely conformant to relevant Parts of the DICOM Standard;

  2. be based on a Standard SOP Class, i.e.:

    • contain all the Type 1, 1C, 2, and 2C Attributes of Standard SOP Class on which it is based;

    • not change the semantics of any Standard Attribute;

    • use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);

  3. be based on the DICOM Information Model in PS3.3 and PS3.4.

Specialized SOP Classes may:

  1. contain additional Standard and/or Private Type 1, 1C, 2, or 2C Attributes;

  2. add Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

    Note

    The usage of any unpublished Attributes may be ignored by other users and providers of the Specialized SOP Class.

  3. enumerate the permitted values for Attributes within the set allowed by the Standard SOP Class;

  4. enumerate the permitted Templates for Content Items within the set allowed by the Standard SOP Class.

An implementation claiming conformance with a Specialized SOP Class shall include in its Conformance Statement the identity of the Standard SOP Class being specialized, a description of usage of all Standard and Private Type 1, 1C, 2, and 2C Attributes in the Specialized SOP Class, a description of the constraints on Attributes values and Templates, and the associated Privately Defined UID.

Private SOP Classes shall:

  1. be completely conformant to relevant Parts of the DICOM Standard with the possible exception that support of the DICOM Default Transfer Syntax or a Transfer Syntax mandated by a Media Storage Application Profile is not required;

  2. not change the PS3.6 specification of any Standard Attributes;

  3. use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);

  4. not change existing DIMSE Services or create new ones;

  5. not change existing DICOM File Services defined in PS3.10 or extend them in a manner that jeopardizes interoperability.

Private SOP Classes may:

  1. use or apply DIMSE Services to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);

  2. use or apply Media Storage Operations to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);

  3. designate any Standard Attribute as Type 1, 1C, 2, or 2C regardless of the Type of the Attribute in other IODs;

  4. define Private Attributes as Type 1, 1C, 2, or 2C;

  5. include Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

An implementation claiming conformance with a Private SOP Class shall provide a PS3.3, PS3.4, and PS3.6-like description of the Private SOP Class in the implementation's Conformance Statement, including descriptions of the usage of all Standard and Private Type 1, 1C, 2, or 2C Attributes in the SOP Class, the DICOM Information Model, and the Privately Defined UIDs.

Note

Unpublished SOP Classes (i.e., SOP Classes that are not defined in the DICOM Standard and are not defined in the Conformance Statement) are permitted in order to allow an implementation to support other abstract syntaxes within the DICOM Application Context. Such unpublished SOP Classes would utilize Privately Defined UIDs. The presence of an unpublished SOP Class does not prevent the implementation from being DICOM conformant but would have no meaning to other implementations and may be ignored.

Prev  Up  Next
7.2 DICOM Media Interchange Conformance Requirements  Home  7.4 Rules Governing Types of Media Storage Application Profiles
DICOM PS3.2 2025b - Conformance