DICOM PS3.7 2016c - Message Exchange

D.3.3.2 Implementation Identification Notification
Prev | D.3.3 DICOM Application Association Information | Next

#### D.3.3.2 Implementation Identification Notification

The implementation identification notification allows implementations of communicating AEs to identify each other at Association establishment time. It is intended to provide respective (each network node knows the other's implementation identity) and non-ambiguous identification in the event of communication problems encountered between two nodes. This negotiation is required.

Implementation identification relies on two pieces of information:

- Implementation Class UID (required)

- Implementation Version Name (optional)

The Implementation Class UID identifies in a unique manner a specific class of implementation. Each node claiming conformance to this Standard shall be assigned an Implementation Class UID to distinguish its implementation environment from others. Such Implementation Class UIDs shall be registered by the implementing organization per the policies defined in PS3.5. This Standard does not specify the policies associated with assigning such a UID.

Different equipment of the same type or product line (but having different serial numbers) shall use the same Implementation Class UID if they share the same implementation environment (i.e., software).

The notification by Association requestors and acceptors of their respective Implementation Class UID is required for all implementations conforming to this Standard. Figure D.3-3 illustrates the Implementation Class UID notification.

Figure D.3-3. Implementation Class UID Notification

In addition to the Implementation Class UID, an option is provided to convey an Implementation Version Name of up to 16 characters. Figure D.3-4 illustrates the Implementation Version Name notification. This Standard does not specify the structure and policies associated with such an Implementation Version Name. The absence of the Implementation Version Name requires that the use of the same Implementation Class UID by two nodes guarantees that these use the same version of implementation.

### Note

As the UID shall not be parsed (their structure is not intended to convey any semantic significance beyond uniqueness), this optional Implementation Version Name provides an adequate mechanism to distinguish two versions of the same implementation (same Implementation Class UID).

##### D.3.3.2.1 Implementation Class UID Sub-Item Structure (A-ASSOCIATE-RQ)

The Implementation Class UID Sub-Item shall be made of a sequence of mandatory fixed length fields followed by a variable field. Only one Implementation Class UID Sub-Item shall be present in the User Data Item of the A-ASSOCIATE-RQ. Table D.3-1 shows the sequence of the mandatory fields.

Figure D.3-4. Implementation Version Name Notification

Table D.3-1. Implementation Class UID Sub-Item Fields (A-ASSOCIATE-RQ)

Item Bytes | Field Name | Description of Field
--- | --- | ---
1 | Item-type | 52H
2 | Reserved | This reserved field shall be sent with a value 00H but not tested to this value when received.
3 - 4 | Item-length | This Item-length shall be the number of bytes from the first byte of the following field to the last byte of the Implementation-class-uid field. It shall be encoded as an unsigned binary number.
5 - xxx | Implementation-class-uid | This variable field shall contain the Implementation-class-uid of the Association-requester as defined in Section D.3.3.2. The Implementation-class-uid field is structured as a UID as defined in PS3.5.

Prev | Up | Next
D.3.3 DICOM Application Association Information | Home | D.3.3.2.2 Implementation Class UID Sub-Item Structure (A-ASSOCIATE-AC)

DICOM PS3.7 2016c - Message Exchange