D.3.3.2 Implementation Identification Notification

D.3.3.2 Implementation Identification Notification (Current)
Prev	D.3.3 DICOM Application Association Information	Next

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, which identifies a version of an implementation for an Implementation Class UID. 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).
It is expected that if the Implementation Version Name is present, it will will include version information in addition to the name of the implementation. The Implementation Version Name is expected to be more specific than the Implementation Class UID, and not less; i.e., the Implementation Version Name will not have the same value when there are different values of the 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-requestor as defined in Section D.3.3.2. The Implementation-class-uid field is structured as a UID as defined in PS3.5.