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.之前已经上传了一组数据,如下图所示:
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第1张图片

重新利用dcmsnd.bat工具在本地重复上传一次,查看服务端日志输出。
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第2张图片

从日志中可以清楚地看到,对于已经存在的数据,再次上传时直接忽略掉。具体的实现逻辑在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)。
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第3张图片
上述实例上传到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。
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第4张图片
【注】:此时为了快速修改实现存储相同数据的方法,并未对Series下的每个SOPInstanceUID进行修改,只修改了SeriesInstanceUID一级。
再一次利用dcmsnd.bat进行上传测试,竟然又一次失败了,如下图所示:
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第5张图片
此次提示发现,dcm4chee背后的验证逻辑足够奇葩,竟然提示已经存在该数据,按照上述四级UID结构来看(如下图),修改了SeriesInstanceUID后,即使不修改下属的SOPInstanceUID,也应该可以存储。相当于重新开了一个序列,只不过存储的相同的图像罢了。
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第6张图片

既然偷懒只修改SeriesInstanceUID不可以,只好对每一个文件的SOPInstanceUID进行修改了,但是这一步如果靠手动来修改工作量巨大,通常一个序列少则几百张,多则上千张图片。因此我这里利用dcm4che工具写了一个自动修改StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID三级UID的程序,修改思路是对原有的各级UID添加后缀,后缀格式是“yyyyMMdd.HHmmss”的时间戳。修改StudyInstanceUID的代码截图如下:
DICOM:dcm4chee奇葩逻辑浅析之UID修改_第7张图片
具体的完整代码博文最后会给出下载链接。

后记:

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

代码示例:

GitHub: changeUIDbyYourselfUsingDcm4che
CSDN: changeUIDbyYourselfUsingDcm4che





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

你可能感兴趣的:(java,uid,DICOM,dcm4che,dcm4chee)