鉴于实例UID如PS3.5 B.2中所述是从UUID派生的。
例如，给出以下DICOM实例UID：
2.25.329800735698586629295641978511506172918
通过添加是否允许/标准符合UID的后缀
2.25.3298007356985866292956419785115061729181, 2.25.3298007356985866292956419785115061729182, ...2.25.329800735698586629295641978511506172918.1, 2.25.329800735698586629295641978511506172918.2, ...请用DICOM标准的引号引起争议。
背景：
我们只有一个UUID，我们需要为其创建多个DICOM。向派生的UID添加后缀将是最简单的解决方案（我们提出的唯一解决方案）。
对我来说，文档读起来像是无法更改源自UUID的UID。它的最大长度也为5 + 39个字符，因此在UID的64个字符限制之前还有一定的空间。
编辑：
据我所知，DICOM标准是在2012年添加的PS3.5 B.2，是PS3.5 9.1和PS3.5 B.1定义的普通UID定义的例外。它不需要组织根前缀。相反，它对从UUID派生的所有实例UID使用通用前缀2.25。这里要注意的重要一点是，它仅应用于SOP实例UID。参见：
UUID派生的UID可能适用于动态创建的UID，例如SOP实例UID，但通常不适用于UID在应用程序软件设计期间确定，例如私有SOP类或传输语法UID或实现类UID。
[通过阅读标准，我以某种方式给人的印象是，DICOM标准仅将这种形式的UID定义为有效，只要它仅由2.25前缀和有效UUID的十进制表示组成，仅此而已：
ISO/IEC 9834-8 / ITU-T X.667定义了一种方法，UID可以通过该方法从根“ 2.25”构建。后跟一个小数通用唯一标识符（UUID）的表示形式。小数点表示将128位UUID视为整数，因此可能是最多39位数字（必须禁止前导零）。
没有明确说明是否可以有后缀。
只要UID是唯一的，就没有理由不这样做。DICOM标准要求它以有效的组织根开头，唯一且明显地最多64个字符长（当然要遵循所定义的格式）。
您可能已经阅读过PS3.5, chapter 9中定义的内容。从标准：
组件定义（用于后缀）是特定于实现的，只要保持唯一性，它可能会更改。
我们在应用程序中做了类似的事情，其中UID由确定性算法生成，如果UID生成得非常快，则可以保证唯一性。