DICOM 标签 0008,0018 SOPInstanceUID 变体答案

【问题标题】：DICOM tag 0008,0018 SOPInstanceUID variantsDICOM 标签 0008,0018 SOPInstanceUID 变体
【发布时间】：2015-01-14 14:32:01
【问题描述】：

我有一个关于以下 DICOM 标签的问题

0002,0003   MediaStorageSOPInstanceUID
0004,1511   ReferencedSOPInstanceUIDInFile
0008,0018   SOPInstanceUID
0008,0058   FailedSOPInstanceUIDList
0008,1155   ReferencedSOPInstanceUID

看起来都一样。我如何获得新的 0008,0018 值并且两个文件具有相同的值？

【问题讨论】：

标签： dicom

【解决方案1】：

拥有两个具有相同 SOP 实例 UID 的不同 DICOM 文件是完全合法的。这种情况在无损压缩 DICOM 数据集时经常发生。

由于压缩是无损的，对 DICOM 包含的像素数据的专业解释不可能受到影响，因此保留完全相同的 SOP Instance UID 是合法的。

只要像素数据的专业解释可能受到影响（例如有损压缩），应用程序就需要更改 SOP 实例 UID。

您可以在 GDCM wiki 上找到关于 DICOM 中派生机制的基本解释：

http://gdcm.sourceforge.net/wiki/index.php/Writing_DICOM

但无论如何，如有疑问，您应该始终参考 DICOM 标准。

作为旁注，根据定义，媒体存储 SOP 实例 UID 和 SOP 实例 UID 是相同的。来自组 0x2 的信息只是从 DICOM 数据集派生而来，以生成有效的 Part-10 DICOM 文件。

Also Referenced SOP Instance UID In File 有点特殊，因为它属于组 0x4。因此，它可能只存在于一个不是典型的 DICOM 数据集中的 DICOMDIR 数据集中。 DICOMDIR 只需要索引媒体上的其他 DICOM 文件（例如 CDROM...）

失败的 SOP 实例 UID 列表也不存在于典型的 DICOM 数据集中，因为它应该只存在于 C-STORE 响应数据集中。

并且明确引用的 SOP 实例 UID 不可能与 SOP 实例 UID 具有相同的值，因为它会在 DICOM 数据集中创建一个自引用循环。

【讨论】：

@AndersGustafsson 你稍微改写了我的回答。PS 3.3 C.7.6.1.1.2 对此非常清楚。并且整个 C-STORE/C-GET/C-MOVE 机制严格符合我上面所说的（所以它需要在第 7 部分/第 8 部分中）。
谢谢，@malat。很好的答案，我一定会投赞成票:-)