你了解DCM的AE Title的长度限制吗?

Posted 2022-09-26 inter_peng

本文由Markdown语法编辑器编辑完成.

1.背景:

DCM是医学图像的通用标准格式, 无论是CT, MRI, 还是超声, 乳腺, DR等设备拍摄的图像, 最终都会以DICOM的格式, 存储在医院的PACS系统中.

在和医院的PACS/CT机进行对接服务时, 一般是通过主动/被动的方式, 接收患者的检查数据, 然后传到后台服务器对数据进行一定的分析和计算. 有时候需要区分这些数据是从哪台CT机过来的.

通过访问以下链接, 可以查询DICOM标准中, 每个tag的含义, 值的类型, 属于第几类标签等信息.
https://dicom.innolitics.com/ciods/ct-image

DCM的tag中, 是有两个相关的tag来记录这个信息的.

另外一个是: SourceApplicationEntityTitle.

Tag	Type	VR
StationName	Optional(3)三类标签	Short String(SH)
SourceApplicationEntityTitle	–	AE

从以上表格中, 可以看出StationName是三类标签, 有可能不存在, 且假如是同一个型号的设备, 有可能StationName是相同的.
但是SourceApplicationEntityTitle, 则是医院设备的AE_TITLE.

对于AE_TITLE来说, 一般医院都会给每台设备一个特有的标识, 就跟每个人都有一个独一无二的身份证号码一样. 只有拥有独立的名称, 才可以很方便地定位到这台设备和位置.

2. 如何获取SourceApplicationEntityTitle

既然SourceApplicationEntityTitle能够反映出影像的拍摄设备的名称, 那么我们如何从一张dicom图像中获取到这个信息呢?
由于医疗设备一般只有医院才有, 那么在公司做研发时, 如何来模拟CT机发送dicom图像呢.

dcmtk是一个集成了很多医学图像处理的工具. 当在电脑上安装了dcmtk后, 便可以使用它内置的很多工具包, 来模拟实现很多医院设备间的数据传递.

dcmdump是一个用于读取dcm图像中的tag信息的工具。
storescu则是用于模拟CT机发送图像的工具。
storescp则是用于模拟接收图像的工具。
……

我们比较常用的是storescu.
storescu的介绍wiki如下:

storescu最常用的命令行如下:

storescu -aet CT_Title -aec PACS_Title +sd +r  -v -d PACS_IP PACS_PORT ./
# CT_Title: 表示模拟某一台CT机的AE_TITLE, 它是图像的发起者.
# PACS_Title: 表示接收图像的PACS的AE_TITLE, 它是图像的接收者.
# PACS_IP: PACS的IP
# PACS_PORT: PACS的Port
# ./: 表示将运行该指令的当前目录下的文件夹, 发送到上述的PACS服务器.

用这个指令, 将图像发送完毕后, 通过用dcmdump查看图像的tag信息, 可以发现, 图像的某一个TAG值发现了变化.
这个TAG值就是: SourceApplicationEntityTitle.

使用dcmdump, 或者gdcmdump, 或者DicomViewer软件，都可以查看到经过storescu发送后的图像的这个TAG值，就是当时发送指令中的-aet后面跟着的CT_Title的值。

于是，我们就可以根据这个TAG值，知道这个图像是来自哪台CT机器的。

3. 忽略VR的长度限制带来的问题

虽然这个TAG可以记录CT机器的Title. 但是，正如每一种数据类型都有长度限制一样。
这个TAG的VR（Value Representation）是AE, 而AE类型的值，最长就是16个字符。

因此，当前面的指令中，如果CT_Title的长度大于16位，那么超过16位的字符会被无情地截掉。

这次正是因为没有注意到这个限制，导致业务的后面，在根据CT_Title的内容来判断是哪台CT机器时，总是无法判断出来。通过增加日志的方式，才看到实际记录的Title是不完整的，才恍然大悟。