DICOM协议学习笔记（二）

由于工作问题，几年没涉及DICOM协议的学习了。于是下定决心沉浸式学习和分享DICOM协议。

第一篇学习dicom26种数据类型或者称为标签，这26种数据类型就相当于编程语言中的数据类型，如Int、string、byte、bool等。

本篇将深入学习dicom的数据类型，以及了解dicom的数据格式和数据字典。

一、VR长度（dicom属性、标签）

在VR介绍的表格中会有该值得长度，如下：当类型是IS（Interger String）时，长度为12个字符。

diocm的VR类型对长度的限制是强制的。

1）VR的值得约定数据验证字符系统---兼容语言（中文、英文、拉丁文等)

所有 DICOM 数据元素都应该为偶数长度，他们必须是偶数字符。为了保证这一点，DICOM 在奇数大小的字符串（比如短文本，ST）后追加空格；或者在奇数二进制数字串后面追加一个空 NULL 的字节，这样就能保证长度为偶数了。

不同国家的用户会希望在本国的语言环境下使用 DICOM 数据。DICOM 是具有这种本地化支持的。但是，语言的选择（对操作系统本地特性的设置）会影响到 VR 数据类型中字母和字符的选择。DICOM 将字符的选择称为“字符系统（character repertoire）

通配符：星号（*）通配符表示任何字符序列；问号（?）通配符表示任何单个字符；反斜线符号（\）表示“或”。

（2）文本VR：CS, SH, LO, ST, LT, UT

文本 VR（CS，SH，LO，ST，LT，UT，代码字符串，短字符串，长字符串，短文本，长

文本，无限制文本）比较简单：他们的用处就是存文本字符串，可以说是最不用费劲去处理

的数据类型，因为使用他们极少需要处理（除了向其他应用程序传送数据时，需要在结尾处

理之前所讲的空格以外）。最重要的一定要记住文本 VR 是有长度的。

（3）日期和时间：DA，TM，DT，AS

DA（日期）、TM（时间）、DT（日期时间）类型是比较一目了然的：它们通过字符串格

式存储日期和时间。最重要的问题就是去了解日期和时间的正确排布顺序。同样，较早的

DICOM版本和ACR-NEMA使用的日期和时间格式与当下版本比起来稍有不同，那时是使用半

角句号（.）和半角冒号（:）分隔的；比如，较早版本中的18:32:00这个时间串，在当前版

本表示为183200。好的DICOM系统开发者会考虑到这些问题，提供这方面的向下兼容性是很

重要的。

DA和TM类型的另一个问题是，单一属性（single attributes）DT类型总是需要将其分割

为DA何TM两种类型

DA、TM和DT格式还有一个问题就是不支持时区信息

（4）二进制格式的数字：SS, US, SL, UL, FL, FD, OB, OW, OF, AT

这些类型实际上和IS、DS这类文本数字串差不多，只不过是用二进制格式存储的。SS、

US、SL、UL、FL、FD通常用来表示单个数（有时可能将这些单个数组合在一起使用）。OB、

OW、OF则通常用在长数字串上。怎么才能储存一个数字图像的像素序列呢？比如，这个例

子中，序列中的每个数都会有相同的字节大小（分别是1、2、4字节），他们将串接成一个长

二进制序列。只有一个类型，OB使用长度为1字节的数。其他类型都比1字节要大，因此他

们都会受到大小端字节序问题的影响。

最后，AT（属性标签（attribute tag））存储一对两字节的数。这种数据类型是用来为所

有DICOM属性存储标签的，我们马上将在5.4中看到他的作用。所以说，AT类型和其他数字

类型不一样，他的唯一的作用就是枚举DICOM数据属性。

（5）PN：存储病人名字

PN（病人姓名）VR编码整个病人姓名。很不幸，DICOM使用一个单一字段保存这些值。

因此，整个病人姓名（名、姓、中名等（主要指欧美国家的名字））会用一个PN类型VR存储。

DICOM 规定了如下的姓名顺序：

姓^教名^中名^名前缀^名后缀

所有的字段之间都会用补字符（^）分开。这和我们在VR表中的示例是一样的。然而，

在纷乱的医疗环境中，这种顺序常遭到改变，导致永久的信息丢失或病人识别错误。

有两个补救的办法：1. 标识病人，一般都是使用病人ID而不是病人姓名。使用病人ID就不会受到拼写错误影响了。

（6）AE：命名应用实体（Application Entity）

AE VR是用来表示DICOM应用实体的。AE本质上是DICOM设备和程序的名字，用来唯一

区分它们（在你的PACS网络中，绝不允许存在两个一样的AE）的。对于任何DICOM网络或PACS

来说，基于他的用途，所以AE VR可谓最重要的VR。

（7）UIDs: 唯一标识

UIDs VR是用来对唯一标识进行编码的，唯一标识主要是用来标识特定DICOM数据（对

象）实例的。AE只要求在本地是唯一的（在网络内）；但无论何时何地，DICOM UID必须全

球唯一。

（8）SQ：序列化数据集 --嵌套（类似XML中的嵌套）

SQ VR是对数据集序列的编码，每个数据集可能包含多个数据属性。此VR支持最为复杂

的DICOM结构，他允许在VR中嵌套其他VR。在DICOM文档中包括一个叫做一致性声明（conformance statement）的东西，它的序列层级是通过大于号（>）来表示的。比如，若你进入一个DICOM数据中，你会发现它很像图6 中的样子。在图6的数据表格中，第一行的“参考的检查序列序列（Referenced Series Sequence）” 属性附带有两个属性，前面都有个大于号（>），这表示“参考的检查序列序列”属性有一个 SQ VR，并且如这个序列所示，其中有“检查序列实例UID（Series Instance UID）”和“参考的实例序列（Referenced Instance Sequence）”。更加有趣的是，“参考的实例序列”属性还跟着两个其他元素，他们前面都用双大于号（>>）表示，这说明“参考的实例序列”内部还有一个序列，并且包含两个属性“参考的SOP类UID（Referenced SOP Class UID）”和“参考的SOP 实例UID（Referenced SOP Instance UID）”。这么说来，“参考的检查序列序列”包括四个子元素；来自他自己的第一层序列的元素和来自他子序列的元素。序列化导致一个复杂，非线性的DICOM数据格式因为一些VR是从另一些中扩展出来的。序列化同样需要更加小心地设计DICOM软件。

(9)UN：表示未知值

UN VR编码未知值。在许多情况下，UN VR多用在那些无法匹配26个VR的值上。UN最常

见的作用是供厂商特定（私有）数据使用，这些数据无论如何都无法让标准去判别了。

我建议每个从事DICOM应用程序开发的人都需要避免使用UN VR。第一，其余的26个VR

足够表达几乎所有数据类型了。第二，使用“未知”属性类型仿佛是一种绝望的做法，为什

么不使用结构化的数据类型定义呢？大、小端字节重拍序就是一个很好的例子：你不能在

UN属性上执行重排序的操作，因为你都不知道这个数据是文本的还是二进制的，甚至也不

知道是否真的需要重排序。

二、数据字典

VR在DICOM数据结构化方面发挥了无可比拟的作用。他们帮助DICOM与外面世界

连接在了一起。VR是DICOM能够理解和沟通的一种构词形式。但是我们如何把现实世界的数

据项翻译为VR呢？答案就是DICOM数据字典（Data Dictionary）。

（1）标准的 DICOM 数据字典

说白了，DICOM 数据字典就是在数字医疗方面，所有标准数据项（属性）的注册表。

据我们现在所知，这些项目需要用 27 个 VR 属性进行格式化。

为了把这些超过 2000 个的项目按照一定顺序排列，所有项目首先被分成编号的项目组

（group）（如果项目内容的大概相似就分为一组）。项目组是由单独的元素组合在一起的。

因此，每个项目都有其自己的编号“(项目组,元素)”，这就是所谓的元素“标签（tag）”。所

有进行标签的元素都称作“属性（attribute）”，或者 DICOM“数据元素（data element）”或

简称为 DICOM“元素”。

（项目组，元素）

数据元素值多样性（VM, Value Multiplicity）定义了相关元素包含的内容是单值还是多值。

如 VM 对应的是 1-N 这说明改标签/元素代表有多个值，每个值通常以'\' 来分开

如：元素(0010,1001) vm是 1-2 值为： zhangsan/lisi 这个人的姓名可以为张三或者李四

DICOM 数据字典中的“RET”标志表明属性已经退休（弃用），这些是较早前版本标

准中的属性，未来 DICOM 将不再支持。

通过以上的学习应该可以使用dicom语言表示下面的例子：

“病人 John Smith，男性，出生日期 1945 年 8 月 6 日”。

“病人姓名”（0010,0010）“病人性别”（0010,0040）和“病人出生日期”（0010,0030）。这些元素分别使用 PN、CS 和 DA 三个 VR。因此，用他们的标签替换了名称，并且使用 VR 格式，

(0010,0010)Smith^John (0010,0030)19540806 (0010,0040)M

（2）私有的 DICOM 数据字典

DICOM 提供一个非常简单的解决方案。所有双数组编号提供 DICOM 数据字典的供标准数据使用；所有单数子编号供私有数据使用。