文本 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
DICOM 提供一 个非常简单的解决方案。所有双数组编号提供 DICOM 数据字典的供标准数据使用;所有单 数子编号供私有数据使用。