A UID of a DICOM entity is not the same as a unique identifier of an individual, such as would be proscribed by some privacy regulations.

UIDs are generated using a hierarchical scheme of "roots", which may be traceable by a knowledgeable person back to the original assignee of the root, typically the device manufacturer, but sometimes the organization using the device.

When evaluating the risk of matching UIDs with the original images or PACS database, one should consider that even if the UIDs are changed, the pixel data itself presents a similar risk. Specifically, the pixel data of the de-identified image can be matched against the pixel data of the original image. Such matching can be greatly accelerated by comparing pre-computed hash values of the pixel data. Removal of burned-in identification may change the pixel data but then matching against a sub-region of the pixel data is almost certainly possible (e.g., the central region of an image). Even addition of noise to an image is not sufficient to prevent re-identification since statistical matching techniques can be used. Ultimately, if any useable pixel data is retained during de-identification, then re-identification is nearly always possible if one has access to the original images. Ergo, replacement of UIDs should not give rise to a false confidence that the images have been more thoroughly de-identified than if the UIDs are retained.

Regardless of this Option, implementers should take care not to remove UIDs that are structural and defined by the Standard as opposed to those that are instance-related. E.g., one would never remove or replace the SOP Class UID for de-identification purposes.

The Implementation Class UID (0002,0012) is not included in the list of UID Attributes to be retained, since it is part of the File Meta Information (see PS3.10), which is entirely replaced whenever a file is stored or modified during de-identification. See Section E.1.1.

UIDs may have been generated using a date/time stamp mechanism to assist in uniqueness generation. Hence if the original UIDs are not replaced, they may assist identity recovery. That said, the presence of an apparent date/time stamp in a UID does not indicate that it is an original UID, since replacement UIDs may contain new date/time stamps related to when the instance was de-identified. Also, UUIDs may be time-based rather than name-based or random-number-based, so use of the PS3.5 Section B.2 UUID Derived UID mechanism does not necessarily avoid this issue.