Unique SOP Instance UID for every frame of a MultiFrame Image

Digital Imaging and Communications in Medicine (DICOM) is a standard for handling, storing, printing, and transmitting information in medical imaging devices. It includes a file format definition and a network communications protocol (conforms to the ISO OSI reference model) and incorporates object-oriented design concepts. The National Electrical Manufacturers Association (NEMA) developed and holds the copyright to this standard.

The information object and the service class are the two fundamental components of DICOM. Information objects define the core contents of medical image, and service classes define what to do with those contents. The service classes and information objects are combined to form the elemental and functional units of DICOM. This combination is called a service-object pair, or SOP. Since DICOM is an object-oriented standard, the combination is actually called a service-object pair class, or a SOP class.

DICOM defines a series of storage SOP classes. When the attributes in the information object and the variables of the service class are populated by values representing a real patient, a particular imaging equipment, and a resulting image, the SOP class becomes a SOP instance (object of SOP class) and is assigned its own identifier.

DICOM standard suggests objects to be identified in such a way that each system that generates data can create an identifier for the data that is guaranteed to be unique. This is the unique identifier (UID). UIDs are made up of a sequence of numeric components separated by dots.
UIDs globally and uniquely identify an object which means that two different objects, even if they are not of the same type or do not appear in the same context, cannot have the same UID. With the aid of UIDs it is possible for related data objects to be sent by separate routes to an archive system and the linkages can be restored on arrival.

When there is a change and if the modified instance is sent to a PACS (Picture Archiving and Communication System) without creating a new instance, the PACS may reject it and keep the copy received before. Many servers do so and DICOM states explicitly there shall be no predictions what a Service Class Provider does when receiving an Instance already present in local storage.

One typical problem observed while transferring a single frame of a MultiFrame image to DICOM server (e.g. conquest) is that the single frame image overwrites the same MultiFrame image due to the usage of common SOP Instance UID. The problem can be depicted below:

A simple solution to avoid overwriting is making the SOP Instance UID unique for all frames & unique for an image as whole. The existing SOP Instance UID of the MultiFrame image is a string to which the Frame Number can be appended, which in turn is unique for each & every Frame throughout the MultiFrame image. The resulted SOP Instance UID will be unique avoiding ambiguities (such as overwriting or rejecting) at server level. The solution can be depicted below: