DICOM：dcm4chee奇葩逻辑浅析之UID修改

背景：

近期由于项目需要，开始频繁接触基于Java的DICOM标准实现库，即dcm4che。与以往使用的dcmtk和fo-dicom不同的是，dcm4che工具包是整个dcm4che项目的一部分，只作为解析DICOM格式的工具包被dcm4chee使用，而dcm4chee是一种托管在JBoss AS中的WEB应用。因此其内部添加了诸多的业务层的逻辑。此次在实际应用中遇到了几个问题，记录下来，以备后续仔细学习分析。

重复数据的处理逻辑：

之前自己使用dcmtk或fo-dicom开发PACS相关功能模块时，对于重复上传的影像数据，往往采用直接覆盖的方式来处理。起初认为dcm4chee中也是如此处理的，今天查看服务端日志时偶然发现，dcm4chee对于重复数据并不进行复写，而是直接忽略新上传的数据。
这里以之前博文介绍的DICOM：Ubuntu14环境下安装dcm4chee+oviyam2.1为例，进行测试。本地我采用的是Ubuntu虚拟机方式运行，其部署地址是：192.168.148.149，端口8088.之前已经上传了一组数据，如下图所示：


重新利用dcmsnd.bat工具在本地重复上传一次，查看服务端日志输出。


从日志中可以清楚地看到，对于已经存在的数据，再次上传时直接忽略掉。具体的实现逻辑在dcm4jboss-sar的org.dcm4chex.archive.dcm.storescp包中。

UID修改逻辑：

既然重复数据无法上传，如果遇到需要上传两套数据的情形怎么办？现实中也是存在这种场景的，例如《A Practical Introduction and Survival Guide》中的例子。
在面向对象应用中经常提到实例“Intance”这个词，通常认为是某个类的具体对象，是包含了具体对象的所有数据某个时刻的快照（原文：Whether you ever played with object-oriented applications or not, you should be familiar with the notion of “instance”. In brief, an instance is a snapshot of an object in time with all its current data values. )。因此修改对象数据总是会生成另一个实例。在头侧X光片中，经常会对原始数据进行编辑，例如勾画相关ROI区域、压缩图像、上传到PACS备份、诊断报告等等。此时对应同一组原始数据，会存在诸多不同的实例(多个instance）。

上述实例上传到dcm4chee服务器，是无法顺利存储的。那么如何解决该问题呢？之前我们对DICOM已经讲解的很多了，其实做法很简单。在DICOM标准中，UID（Unique Identifiers）就像人类的DNA一样，作为数据的唯一标示，因此想要存储相同的数据（这里的数据通常指的是DICOM文件中包含的患者信息、检查信息、序列信息、实际影像相同，除了UID不同以外），可以修改UID来实现。
为了验证我们的想法，直接使用Sante DICOM Editor工具修改测试数据zstest1整个序列数据的SeriesInstanceUID，由之前的1.3.6.1.4.1.30071.6.979046.4296168899037731.2修改为1.3.6.1.4.1.30071.6.979046.4296168899037731.2.2。

【注】：此时为了快速修改实现存储相同数据的方法，并未对Series下的每个SOPInstanceUID进行修改，只修改了SeriesInstanceUID一级。
再一次利用dcmsnd.bat进行上传测试,竟然又一次失败了，如下图所示：

此次提示发现，dcm4chee背后的验证逻辑足够奇葩，竟然提示已经存在该数据，按照上述四级UID结构来看（如下图），修改了SeriesInstanceUID后，即使不修改下属的SOPInstanceUID，也应该可以存储。相当于重新开了一个序列，只不过存储的相同的图像罢了。


既然偷懒只修改SeriesInstanceUID不可以，只好对每一个文件的SOPInstanceUID进行修改了，但是这一步如果靠手动来修改工作量巨大，通常一个序列少则几百张，多则上千张图片。因此我这里利用dcm4che工具写了一个自动修改StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID三级UID的程序，修改思路是对原有的各级UID添加后缀，后缀格式是“yyyyMMdd.HHmmss”的时间戳。修改StudyInstanceUID的代码截图如下：

具体的完整代码博文最后会给出下载链接。

后记：

通过此次调试，发现dcm4chee内部的逻辑比较复杂，虽然对DICOM标准比较了解，而且对相关的开源工具包也比较熟悉，但是在实际使用过程中还是遇到了很多问题。这里就简单记录上述两个“坑”，待后续有时间再详细分析dcm4chee底层的源码实现，搞清楚奇葩逻辑背后的真相。敬请期待！

代码示例：

GitHub: changeUIDbyYourselfUsingDcm4che
CSDN: changeUIDbyYourselfUsingDcm4che

作者：[email protected]
时间：2015-06-14