DICOM UID相关

标准定义：Part 5 Data Structures and Encoding - 9 Unique Identifiers (UIDs)
DICOM PS3.5 2020b 第89页

---

以下内容来源：网页

Organizationally Derived UID
A UID may be formed using a registered root (see Annex C) and an organization specific suffix. The manner in which the suffix of such an organizationally derived UID is defined is not constrained by the DICOM Standard. Only the guarantee of its uniqueness by the defining organization is required by DICOM.

The following example presents a particular choice made by a specific organization in defining its suffix to guarantee uniqueness of a SOP Instance UID.

In this example, the root is:

● 1 Identifies ISO

● 2 Identifies ANSI Member Body

● 840 Country code of a specific Member Body (U.S. for ANSI)

● xxxxx Identifies a specific Organization.(assigned by ANSI)

In this example the first two components of the suffix relate to the identification of the device:

● 3 Manufacturer defined device type

● 152 Manufacturer defined serial number

The remaining four components of the suffix relate to the identification of the image:

● 235 Study number

● 2 Series number

● 12 Image number

● 187636473 Encoded date and time stamp of image acquisition

In this example, the organization has chosen these components to guarantee uniqueness. Other organizations may choose an entirely different series of components to uniquely identify its images. For example it may have been perfectly valid to omit the Study Number, Series Number and Image Number if the time stamp had a sufficient precision to ensure that no two images might have the same date and time stamp.

Because of the flexibility allowed by the DICOM Standard in creating organizationally derived UIDs, implementations should not depend on any assumed structure of UIDs and should not attempt to parse UIDs to extract the semantics of some of its components.

---

以下内容来源：网页
Q： Should a DICOM StudyInstanceUID be unique to the patient?
While working with the DICOM study, series and media concepts, I wondered if these values are to be unique over all data, or only to the patient they belong to.
Phrased otherwise; can I have 2 patients having a study/series/sop instance uid that is the same value for both patients?
Or does the DICOM standard simply doesn’t care about that and is that open to the implementor to decide?

I know how to generate a unique DICOM UID. My question was more about what to do in case I choose to clone a patient in my system and attach the same dicom(s) to it. Should I regenerate the dicom-uid’s or could I keep them as-is. But I guess it’s more of a business decision then a technical decision.

A：In DICOM, a Study (identified by its Study Instance UID) is always associated with a single Patient. See DICOM standard part 3 for details.
To answer your initial question/thought: a Unique Identifier (UID) has to be globally unique, i.e. world-wide over all patients, devices, hospitals, etc.

A：UID in DICOM (no matter what UID) is always globally unique. So, as you asked in question, uniqueness is not limited to Patient level or something.
I am not sure what you mean by “clone”. While cloning, if there is change in dataset, you should regenerate the SOPInstance UID. Even if you simply apply lossy transfer syntax to your dataset, you should regenerate the SOPInstance UID. Any action that differentiates/separates the the datasets from original require new SOPInstance UID. So, while cloning, if you are changing patient demographics, new UID should be generated. Whether new StudyInstance UID should be generated or not depends upon what is changed.
OTOH, if you are just copying your dataset at different location, it is still same dataset. You do not need to regenerate UIDs in this case.

A：Unfortunately although the standard states the UID should be globally unique you can not guarantee it at the series level in my experience. I have come across series with duplicate ids across studies. To protect yourself assume you have to use StudyUID +SeriesUID to ensure a unique series key.

---

以下内容来源：网页
Q：How to generate unique DICOM UID? I am working on DICOM gated (PET) data.
I would like to artificially create a DICOM image series which includes gated data. I am inquiring on the increment values of SOPInstanceUID which labels each image slice in each phase or gate.
These have different values for each slice in a gate and are incremented between gates but I can’t find out the logic to how this value is chosen.
Is there a reference to where and how these values are written?

A：Following are the general rules for DICOM UID:

1.Total length must be <= 64 characters, including the stops
2.Must contain only digits 0-9 and full stops
3.Each numeric “component” (between stops) must be a valid and unambiguous integer number, and so must not have a leading zero (unless the whole component is zero)
4.Must be guaranteed to be unique - this means:
1)It must be derived from a proper official root under your sole control.
2)It must not be created by appending digits (however special you consider the combination!) to someone else’s UID.
3)In particular, series UIDs for secondary capture images, KIN objects etc. must not be created as derivatives of the Study UID (unless you own that root!)
5.Related to the above, there is no expectation or requirement that the Study UID, Series UID and Instance UID for images should be derived from the same root (though in practice, Series UID and Instance UID normally are, as both must be generated internally by the equipment which generates the images)
6.Date and Time are useful for generating UIDs, but only if:
1)Each machine has a unique root (normally your company UID root + a machine specific suffix such as a serial number
2)If it is possible for UIDs to be generated at > 1 per second, then a sequential counter should also be used
3)if on a multi-threaded machine, then the thread ID or a properly interlocked counter are needed to prevent 2 applications or 2 threads in the same application from generating identical UIDs simultaneously.
4)Do not use time on its own - it is too easy to end up with a leading zero 0 - e.g. 20060724.093017 use instead 20060724093017