DICOM PS3.7 2019a - Message Exchange

D Association Negotiation (Normative)

Association establishment is the first phase of any instance of communication between peer DICOM AEs. The AEs use the Association establishment to negotiate how data will be encoded and the type of data to be exchanged. This Annex provides an overview of the negotiation mechanisms plus a discussion of each concept, its objectives, relationships, usage principles and specifications.

D.1 Abstract Syntax

Abstract Syntaxes specify the Application Layer Data Elements and Application Layer protocol control information (with associated semantics) that are independent of the encoding technique used to represent them.

Each Abstract Syntax shall be identified by an Abstract Syntax Name in the form of a UID. DICOM AEs use the Abstract Syntax Name to identify and negotiate which SOP Classes and related options are supported on a specific Association. Abstract Syntax Names shall be defined in the Service Class Definitions specified in PS3.4. Each Abstract Syntax Name defined shall have a value of either

  • a Service-Object Pair Class UID

  • a Meta Service-Object Pair Group UID

D.1.1 Service-Object Pair Class UID

Each Service Class Definition defines one or more functionally-related Service-Object Pair (SOP) Class definitions that specify well-defined operations and/or notifications that may be performed between peer DICOM Application Entities to provide an application-level service. Each SOP Class, identified by a SOP Class UID, is defined by the union of one Information Object Definition (IOD) and a specific set of one or more DIMSE Services called the DIMSE Service Group (DSG) in that

  • The IOD defines the data structures

  • The DSG defines the operations and/or notifications that can be performed on this data structure.

Two SOP Classes defined by a single Service Class Definition may differ by the IOD, the DSG or both. Two different IODs shall not, however, be part of the same SOP Class. Figure D.1-1 shows the relationships between Service Classes, IODs, DSGs and SOP Classes.

Service Class, IOD, DSG and SOP Class Relationships

Figure D.1-1. Service Class, IOD, DSG and SOP Class Relationships


Note

  1. Two examples of Service Classes are the Storage and Study Management Service Classes. The Storage Service Class relates to image Information Object Definitions such as CT, MR etc. and the Study Management Service Class relates to the Study Information Object Definition.

  2. For readers familiar with OSI terminology, the concept of the Managed Object Class is the equivalent to the DICOM Service-Object Pair Class. The SOP Class specifies both the data (Attributes defined in the Information Object Definition) and the methods (Operations and Notifications (DSG) defined in the Service Class).

By setting the Abstract Syntax Name to a specific SOP Class UID value, DICOM Application Entities may negotiate Service Class operations and/or notifications for each defined SOP Class individually.

D.1.2 Meta Service-Object Pair Group UID

Each Service Class Definition may optionally define one or more Meta Service-Object Pair Classes each being identified by a Meta SOP Class UID. Each Meta SOP Class represents the union of a set of SOP Classes defined in the Service Class.

By setting the Abstract Syntax Name to a specific Meta SOP Class UID value, DICOM Application Entities may negotiate Service Class operations and/or notifications for a set of defined SOP Classes using a single Abstract Syntax. Figure D.1-2 depicts this.

SOP Class UIDs and Meta SOP Class UIDs and Abstract Syntax Names

Figure D.1-2. SOP Class UIDs and Meta SOP Class UIDs and Abstract Syntax Names


DICOM PS3.7 2019a - Message Exchange