关于comp.protocols.dicom-google小组的其他讨论
具体示例：
假设实例UID是从PS3.5 B.2中描述的UUID派生的。
例如，给定以下DICOM实例UID:
2.25.329800735698586629295641978511506172918
添加附加组件是否符合UID后缀的标准
2.25.329800735698586629295641978511506172918.1,
2.25.329800735698586629295641978511506172918.2,
...
问题：
从阅读该标准中，我不知何故得到了这样的印象：DICOM标准仅在由2.25前缀和有效UUID的十进制表示组成的情况下才将这种形式的UID定义为有效：
ISO/IEC 9834-8/ITU-T X.667定义了一种方法，通过该方法，UID可以由根"2.25."后面跟一个小数构成通用唯一标识符(UUID(的表示。那个小数表示将128位UUID视为整数，因此可以最多39位数字(必须抑制前导零(。
它没有明确说明是否可以有后缀。
它的最大长度为5+39个字符，因此在达到UID的64个字符限制之前还有一些空间。
PS3.5 9.1中的所有规则仍然适用于PS3.5 B.2的UID定义吗？还是PS3.5 B.2是一个独立的定义
UUID派生UID:的附加信息
就我对DICOM标准的理解而言，PS3.5 B.2是2012年添加的，是PS3.5 9.1和PS3.5 B.1定义的正常UID定义的例外。它不需要组织根前缀。相反，它对从UUID派生的所有实例UID使用通用前缀2.25。这里需要注意的是，它应该只用于实例UID。参见：
UUID派生的UID可能适用于动态创建的UID，例如SOP实例UID，但通常不适用于UID在应用软件设计过程中确定，例如专用SOP类或传输语法UID或实现类UID。
作为此异常的附加指针(来源(：
生成不需要获取的UID的另一种方法一个人自己的根前缀可以利用标准前缀为在中使用通用唯一标识符(UUID([…]而建立本质上，它涉及转换正常连字符的十六进制UUID的字符串形式转换为一个大的十进制数字并附加它的前缀为"2.25">
绝对不是。
您不能将任何内容作为后缀添加到2.25+UUID。
我认为修改现有的UUID派生UID是不符合要求的，即使这样做也不是一个好主意。期望的是，带有2.25.前缀的UID后面跟着一个可以覆盖到UUID的组件值。
2.25.+UUID的使用是已注册的OID。