精华内容
下载资源
问答
  • DICOM 标准

    千次阅读 2014-04-30 20:24:48
    对于一个与DICOM标准的第十部分相容的图像文件,人们一般称之为DICOM格式的文件。 一个单一的DICOM文件既包括一个头部信息(其中存贮病人姓名,扫描类型,图像维数等信息),又包含图像数据本身(可以是三维信息...

    第一章 DICOM 标准

    1. DICOM 单文件格式 简介

    DICOM(Digital Imaging and Communications in Medicine)标准由美国NEMA(National Electrical Manufactures Association)建立,以便于医学图像,如CT,MRI及超声图像的发布和查看。该标准的第十部分,描述了图像发布的文件格式。该格式是老的NEMA标准的一个扩展。对于一个与DICOM标准的第十部分相容的图像文件,人们一般称之为DICOM格式的文件。

    一个单一的DICOM文件既包括一个头部信息(其中存贮病人姓名,扫描类型,图像维数等信息),又包含图像数据本身(可以是三维信息)。这与著名的Analyze格式不同,它将图像数据存贮在一个文件中(*.img),而将头部信息存贮在另一个文件中(*.hdr)。DICOM与Analyze不同的另一个方面是DICOM的图像数据可以是压缩的。既可以使用有损或无损的JPEG格式进行压缩,也可以用无损游程编码格式。

    对医院来讲,DICOM是接受扫描(图像)的最常用标准。Neuroimagers及Neuropsychologists如果想使用SPM来规范化扫描(结果)stereotaxic空间,则需要将其转换为Analyze格式。自由软件MRIcro可以将大多数DICOM图像与Analyze格式相互转换。

    2. DICOM头

    左边的图像显示的是一个假设的DICOM图像文件。最前面的794个字节是DICOM格式的头,它描述了DICOM格式的图像大小,以及其他关于扫描情况的文件信息。

    头部的大小依赖于存贮信息的多少而变化。此外,头部定义了一个图像大小109*91*2个体素。数据分辨率头为每个体素1个字节。图像本身的数据紧接头部之后。(头与图像数据保存在同一文件之中)。

    头部的细节(略)。实践中,大多数DICOM格式的浏览器(包括MRIcro及ezDICOM)都要检查(许多头部)元素是否存在,而只是取出描述图像大小的头部信息。

    DICOM之前的NEMA标准,其结构与此非常相似。主要差别在于NEMA格式没有128-byte的数据偏移。及紧随其后的字符‘DICM’。此外,NEMA没有显式定义多帧(3D)图像,因此,成员0028,0008不存在。

        一个特别重要的组成员是0002:0010,它定义了“Transfer Syntax Unique Identification”(见下表):

    Transfer Syntax UID

    Definition

    1.2.840.10008.1.2

    Rawdata,Implicit VR,Little Endian

    1.2.840.10008.1.2.x

    Rawdata,Implicit VR:

    1.2.840.10008.1.2.4.xx

    JPEG compression

    1.2.840.10008.1.2.5

    Lossless Run Length Encoding

    这个值反映了图像数据的结构,提示了数据经过压缩。

    注意:不少DICOM浏览器只能处理未经压缩的Raw数据。

    这些代码在DICOM标准的第5部分描述。

    注意:该“Transfer Syntax UID”不仅报告了压缩技术方面的信息,还报告了raw data的字节顺序。不同计算机存储整数值的方式不同,即所谓“big endian”与“little endian”。

    例如:对16-位整数257;主字节存储01(=255),次字节存储02。某些计算机将该值存为01:02,其它计算机存储为02:01。因此,对每次采样超过8-位的数据,DICOM浏览器须考虑数据字节的存储次序。

    除了Transfer Syntax UID之外,图像特性还包括,

    (1)Samples Per  Pixel(0028:0002)

    (2)Photometric  Interpretation(0028:0004)

    (3)Bits  Allocated(0028:0100)

    大多数MRI及CT图像,其Photometric  Interpretation是一个连续的灰度级图像。在DICOM中,对这些单色调的图像的Photometric  Interpretation值为“MONOCHROME1”(低位值=bright,高位值=drak)或“MONOCHROME2”(低位值=dark,高位值=bright)。然而,许多超声图像或医学照片包含色彩,其Photometric  Interpretation值为(例如:Palette,RGB,CMYK,YBR等)

     

    例:对前面的MRI*

    First 128 bytes:unused by DICOM format(保留128个字节,通常全为0值)

    Followed by the characters:’D’,’I’,’C’,’M’(四个字;8个字节?)

    这个序值之后是其它头部信息,分组存储(如0002Hex是文件信息组):

    (256)    0002,0000:  File Meta Elements Group Len:132     (文件组长度132字节)

               0002,0001:  File Meta Info Version:256            (文件版本)

               0002,0010:  Transfer Syntax UID:1.2.840.10008.1.2.1(传输方式)

    (248)    0008,0000:  Identifying Group Length:152         (特征组长度:152字节)

               0008,0060:  Modality:MR                      (图像类型)

               0008,0070:  Manufacturer:MRIcro

               0018,0000:  Acquisition Group Length:28          (采样组长度,28字节)

               0018,0050:  Slice Thickness:2.00                 (切片厚度:2.00)

               0018,1020:  Software Version:46\64\37

               0028,0000:  Image Presentation Group Lenth:148   (图像表示组长:148)

    0028,0002:  Sample Per Pixel:1                  (每个像素样本数?)

    0028,0004:  Phtometric Interpretation:MONOCHOM2(图像表示法)

    0028,0008:  Number of Frames:2                 (帧数)

    0028,0010:  Rows :109                         (每帧行数)

    0028,0011:  Columes:91                        (每帧列数)

    0028,0030:  Pixel Spacing:2.00\2.00               (像素间隔:行间\列间)?

    0028,0100:  Bits Allocated:8                     (每像素分配位数)

    0028,0101:  Bits Stored:8                       (每像素实际存储位数)

    0028,0102:  High Bit:7                          (高位:7)

    0028,0103:  Pixel Representation:0                (像素表示:0)?

    0028,1052:  Rescale Intercept:0.00                (缩放轴取:0.00)?

    0028,1053:  Rescale Slope:0.00392157 

    7FE0,0000:  Pixel Date Group Length:19850          (体像素数据组长:19850)

    7FE0,0010:  Pixel Data:19838                     (实际数据:19838 Bytes)

    后面是实际图素数据,

    中间还有一些组,如(0010,nnnn)病人信息等,头部共794 bytes。

     

    注:little endian存储模式问题:(Windows,大多数Linux均用)

    存储顺序为:从低字节到高字节(一个整数含4个字节)

    例:0 x 12345678 存贮为(内存表示):0 x 78  0 x 56  0 x 34  0 x 12

    Little endian

    字节3            字节2        字节1        字节0

    0 x 78

    0 x 56

    0 x 34

    0 x 12

     

     


    76543210     15 14 13 12 11 10 9 8 23 22……17 16  31……………..24

     


      

                                         总共32位

     Big-endian

      8位               8位            8位           8位

    字节0        字节1           字节2        字节3

    0 x 78

    0 x 56

    0 x 34

    0 x 12

     

     


    31……………..24   23……17 16     15……………8     7…………….0      

     


      8位               8位            8位           8位

     

                           总共32位

     

    例:对0 x 3548(两个字节)

    Little Endian                     Big Endian

    35

    48

    内存                Byte[0]                        byte[0]

    48

    35

         i

        I + 1             byte[1]                        byte[1]

             Windows                        Unix

    用fgetc去读:存入ushort  x中,则

       Windows下:BYTE  b[2]                 Unix下:unsigened  char  b[2];

                   b[0]=fgetc(fp);                       b[0]=fgetc(fp);

                   b[1]=fgetc(fp);                       b[1]=fgetc(fp);

                   x=(ushort)(b[1]<<8|b[0])               x=(ushort)(b[0]<<8|b[1])

     

    常见问题解答

    第一部分:简介

    一.        目标

    本文的目标是为了访问存储在医学图像仪器(如CT和MR扫描仪)中的医学图像提供便利。特别是为那些无法接触转悠设备的人。对那些有志于使用现有设备建立类PACS系统的人或一些老旧的设备,供应商已不支持的人,期望也能从本文中获得帮助。

    当然,本文不期望取代来自于设备供应商的真正工具和描述。包含了一些有用的链接,对那些按协议要求不能公开的则尽力注意不被包含。所提供的材料,要么是供应商自由发布的,要么来自于世界本领域人士的提点,要么是对十六进制调试结果的细致分析,要么来自于对扫描参数的实验并精研所致的结果。其目的在于传播多年浸淫于这种方法而艰难获取的知识,丝毫无意侵害他人之专利,也无意取代来自于供应商的技术支持,涵盖从免费到豪夺,从优异到万丈深渊的范围。

    二.        格式类型

    后面的章节将考虑从仪器获取图像到工作站的问题,当前假设图像文件已获得,并急需解读。

    这类文件通常包含四类信息

    1、  图像信息:可能原封不动,也可能经过压缩;

    2、  病人信息:标示和人口统计方面的信息;

    3、  技术信息:有可检查方面;

    4、  切片信息:

    提取图像数据通常叫简单直接,在下一节(三)中介绍。而处理有关描述性信息,如在PACS系统中传播有关数据或抽取几何细节,以便将图像整合为3D数据集则较困难,并需读文件结构有更深入的理解。

    常用的有三类基本格式:

    1、  固定格式:每个文件的排布完全相同;

    2、  分块格式:(block format),头部包含指向信息的指针;

    3、  基于标记的格式(tag based format):每个项目包含它自身的长度信息。

    分块格式目前是最流行的,尽管在多数情况下,头部的前面部分对大块包含少量指针,至少对标准而非改良的图像格式块几乎总在相同位置并有固定长度。如果我们不知道排布的规则,我们可以把它当作固定格式。我觉得这可能反映了设计者的意图,以便处理将来格式的扩展和修正。

    与基于标记的格式等同优秀的例子是ACR/NEMA风格的数据流。它虽然本未从未打标作为一种文件格式。但却被证明对于建模很有用。参见关于ACR/NEMA标准以及DICOM的章节。ACR/NEMA风格的标记在别处详述,此外只需明白每个这种标记是自包含和自描述的(至少当你有适合的数据字典时),并包含它自身的长度。因此,如果你无法解释它,就可跳过它。非常方便,大多数基于这一方案的文件格式只是将一系列的标记串连起来,除了不必须猜测字节顺序外,它也没有指定,有时跳过一段不长的头部信息,是非常容易处理的。

    要观察这样一个文件,只须做一下:

    “strings<file/grep’ACR-NEMA’ ”

    通读16进制dump文件,直到发现16位字的有序“对偶“,等于ACR/NEMA,dumping程序,看它包含了什么,如果你发现含偶数个标记,说明它是合乎标准的,如果发现含奇数个标记,说明它是供应商专有的,须与供应商联系。

     

    三.       奋不顾身——快速与肮脏的技巧

    由于放射学者,放射图像师、技术员。物理学者及图像程序员都是天生受苦受难的动物,他们在逆境中长时间劳作,只获得微弱报酬。故而供应商们只好慷慨的让人们的生活稍微好过一点,几乎一致的将图像数据放在了文件的最后。很少发现有文件会填充到固定的长度边界(就像VaxVMS的512个字节的记录长度)。有时层叠平面数据可能存贮在内容不压缩,也不参杂。即使在ACR/NEMA中,图像像素数据的标记早数值上也是最高的,因而将出现在已排序的序列的最后。

    在文件的尾部无故加上一些乱七八糟的可变长差点让我们无所适从(screwed us up),但碰上这样情况的仅有一次是对Siemens使用基于ACR/NEMA的SPI格式填充到512个字节。换句话说,如果一幅图像是256*256,无压缩,12~16位深度的(因此,通常虽然不全是,每个像素存为2字节),则我们知道该文件在尾部将包含256*256*2=131072个字节的像素数据。如果文件的长度为145408个字节,如对所有GE Signa3*/4*文件那样,则在获得图像数据之前,需要跳过145408—131072=14336个头部字节。假设从左上角开始对光删顺序逐行处理,对两种字节顺序(big endian或 little endian )分别尝试,并处理16到8位窗口问题(?),则很快可以在你的屏幕上获得图像。

    这种技术非常有用,甚至Macintosh的NIH图像(BTW程序)也提供一个raw数据导入工具完成该项工作,其手册中描述说应用了14336个字节的偏移。

    当然,你会缺乏人口统计方面的一些标示信息和技术信息,但对许多有酒喝表现方面的目的,这就够了。

    有时会碰见一些很聪明的文件,它们将四个12位字装入三个16位的字之中。如果想弄清楚这样装配逻辑会做的一种方法。但还是很容易计算出其长度。

    我猜想大多数图像(数据长度)都是2的一个号次幂。甚至是(256,320,512)等的倍数。当然,GE CT9800使用周长编码,这种技巧无法施展。

     

    第二部分   标准格式

    一.        ACR/NEMA 1.0 及2.0

    ACR/NEMA 标准出版物NO.300—1985  ACR/NEMA 1.0

    ACR/NEMA 标准出版物NO.300—1988  ACR/NEMA 2.0

    ACR/NEMA 标准出版物NO.300—1989  数据压缩

    美国放射学研究会(American College of Radiologists)及美国电子制造商协会(National Eletrical Manufacturers Association(NEMA))此前认识到需要一个标准来方便多个供应商之间(设备)的互连,以提升PACS的开发。第一个这标准时版本1.0,1985年发表,接下来修订过几次,并在1988年发布为版本2.0。停顿几年后,作了一次重大修订和重新组织,同时保留了向后兼容性,终于在1992~1993年间发布了ACR/NEMA标准出版物PS3,也称为DICOM3。

    其间,为方便压缩图像的传递,发布了另一个标准出版物PC2,虽然本部分标准从无人真正明确的实现过,而是被直接从事DICOM3压缩的人轻松绕过,但它却是一个不错的技术总结,读来有趣。

    关于ACR/NEMA 1.0及2.0我们究竟需要了解什么?该标准沿着ISO—OSI的层次模型的线索定义了物理层,传输/网络层,会话层和应用层的机制。除非你真的想了解物理上支持单一50针点到点的连接设备如何工作,否则,你只需了解ACR/NEMA是如何实现表示层和应用层的。

    它通过“消息格式”的概念加以描述。(Message format)该“消息格式”对许多人都很重要,并不是因为这个早期标准所预示的有限前景令人真的期望去连接有关的设备,而是因为许多专有格式或其他事实上的标准都采用了ACR/NEMA消息格式及其对应的数据字典和扩展机制。

    该消息格式在ACR/NEMA标准出版物NO.3000—1988的第4、5和第10节中加以描述。其中第6节描述了命令结构,其实它并不相关,只是命令也与数据相同的方式构造,并且占用了部分数据字典。在包含于文件格式的数据流中(“message”,你不会遇见命令标记。下面对它作简要的总结:

    (*)消息格式:

    消息有一系列“数据元素”组成。每个数据元素(data elements)包含一条信息。数据元素由“元素名”(element name)加以说明,元素名有一对16位无符号整数组成,形式为:

    (“组号”,“数据元素号”)。

    数据流按组号升序排列,每组内部则按元素号升序排列。每个元素在消息中只能出现一次。偶数偏好的组表示是标准中定义的元素,奇数编号的组诗供应商或用户自定义的,但必须符合于标准元素相同的结构。在数对(组号,数据元素号)之后是一个长度域,它是一个32位无符号偶数,说明了从长度域结尾到下一个数据元素的开头共多少个字节。

    数据元素的最后部分是它的值。根据数据字典定义为ascii(数字—AN或文本—AT)或二进制(BI—位或BD—32位)。(AN:ASCII Numeric,AT:ASCII text,Binary Integer,Binary Double)。数据值可以是(S)单个或(M)多个,多个ASCII值由反斜杠字符分割(\。05CH)。

    奇数(字节)长度ASCII值由空格填补(020H)。

    例:0008 0010 000C 0000 4341 2D52 454E 414D 3120 302E

    是一个数据元素“Recognition Code”。根据数据字典,它的组为0008,元素号为0010。长度域说明其长度为0 x 0000 0000C即12个字节长。这个组元素较数据字典说明知:是AT(ascii text)类型的,值的重复度为单值,且为枚举值,此时应为一个ascii串,即“ACR-NEMA2.0”?

    41  43  52  2D  4E  45  4D  41  20  31  2E  30  (16进制)

    (转为10进制)

                  65 A  67C  82(R)                            46 O

     

    电子接口是16位的,因此既使32位二进制值被定义为次重要“字”先位,标准中没有提到如何将消息封装到8位中。(32位的顺序也实际上没有指定),不同的用户或供应商可以选择Little或big endian方式。新DICOM标准缺省采用little endian表示法,它要求次重要的16位字先位。

    这样一来供应商以字节为导向来解释ACR/NEMA标准就可能产生三种字节顺序:

    (1)little endian 16及32位字,如DICOM3中采用。

    (2)big endian 16及32位字,也如DICOM3中采用(Unix系统)。

    (3)big endian 16位字,但对32位字,次重要一半先传(如ACR/NEMA2.0).

    选择似乎通常基于主机处理器中整数的本机字节顺序。本人所遇到的大多数格式都是前二种之一,但的确遇到这一种来自于Philips的格式使用最后一种方式,有一段时间令我差点发疯,直到后来我对它的灵巧由衷赞赏!我称之为:“big bad Endian”格式,但可能这只是我的价值判断。

    应注意这种设计如何使我们即使在数据字典不完备的情况下也能解释消息。考虑一个元素,它有一个无法识别的元素名。人们无法翻译元素的内容,因此只有忽略它。人们甚至不清楚它包含的是二进制还是ascii信息(这就DICOM后来所指的“隐式表达”(implicit representation)),尽管如此,其后的长度值使我们可以跳过它来继续前行。

    多年以来,在那些忠意隐式字典驱动的人和喜欢显式表达,包括元素类型的显式表达(binary或ascii等)甚至元素描述本身的显式表达的人们之间争论不休。有些人喜欢消息包含如“Recognition Code=’ACR-NEMA_2.0’;”之类的东西。核医学组已采用了一个事实上的标准称为Interfile。它使用了ACR/NEMA数据元素,并使用了这类描述性的表达方式。它们辩称这种数据流更易读,并更容易扩展,这当然也是事实。

    (*)部分组号如下:

         0000         命令组

         0008         特征(标识)组

         0010         病人信息组

         0018         采样方式组

         0020         关系组

         0028         图像表示组

         4000         文本组

         60000-601E  (偶数)层叠组

         7FE0         像素数据组

     

    (*)部分有趣的元素如下:

    (nnnn,0000)   BD  S  :组nnnn中字节数量(组长)

    (nnnn,4000)   AT  M  :注释(任意组nnnn)

    (0008,0010)   AT  S   :标识码,只能是ACR/NEMA1.0或2.0

    (0008,0020)   AT  S  :研究日期yyyy.mm.dd

    (0008,0021)   AT  S  :系列日期yyyy.mm.dd(?)

    (0008,0022)   AT  S  :采样(获取)日期yyyy.mm.dd

    (0008,0023)   AT  S  :图像日期yyyy.mm.dd

    (0008,0030)   AT  S  :研究时间hh.mm.ss.frac

    (0008,0031)   AT  S  :系列时间hh.mm.ss.frac

    (0008,0032)   AT  S  :采样(获取)时间hh.mm.ss.frac

    (0008,0033)   AT  S  :图像(成像)时间hh.mm.ss.frac

    (0008,0060)   AT  S  :仪器(号)CT,NM,MR,DS,DR,US,OT

    (0010,0010)   AT  S  :病人姓名

               (0010,0020)   AT  S  :病人编号

    (0010,0030)   AT  S  :病人生日yyyy.mm.dd

    (0010,0040)   AT  S  :病人性别M,F,O(其它)

    (0010,1010)   AT  S  :病人年龄***D或W或M或Y

     

    (0018,0010)   AT  M  :Contrast/Bolus Agent # or None

    (0018,0030)   AT  M  :Radio nuclide

    (0018,0050)   AN  S  :切片厚度#mm

    (0018,0060)   AN  M  :KVP

    (0018,0080)   AN  S  :副本(拷贝)时间(?)ms(Repetition Time)

    (0018,0081)   AN  S  :Echo Time # ms

    (0018,0082)   AN  S  :Inversion Time # ms

    (0018,1120)   AN  S  :Gantry Tilt # 度数

    (0020,1040)   AT  S   :部位参考#如.iliac crest

    (0020,1041)   AN  S  :切片定位# in mm(有符号)

    (0028,0010)   BT  S   :行数

    (0028,0011)   BT  S   :列数

    (0028,0030)   AN  M  :像(体)素间隔大小row\col in mm

    (0028,0100)   BT  S   :已分配倍数,例如对CT为12位

    (0028,0101)   BT  S   :存储位数,如16位

    (0028,0102)   BT  S   :高位,如11

    (0028,0103)   BT  S   :像素表示,1=有符号,0=无符号

    (TFE0,0010)   BT  S   :像素数据

     

    像素数据存储的方式可是千差万别。虽然万幸大多数供应商和用户都应用如上所述简单的方式,即一个12位的像素存储在一个16位字的低阶部分,而不填充其它东西。下面是出现在标准附录E中的一些例子。注意,当我们考虑little/big endian问题时,排列将会增加。

    例1:Bits Allocated=16,Bits Stored=12,High Bit=11

    |            像素数据            |

    | xxxxxxx  |  1  1  1  |          |           |

    15        12 11  8  7  4          3           0

     

     

     

    例2:Bits Allocated=16,Bits Stored=12,High Bit=15

    |           像素数据            |

    |  1        |          |          |  xxxxxxx  |

    15         12 11  8  7  4          3          0

     

    例3:Bits Allocated=12,Bits Stored=12,High Bit=11

          略。详细情况还需参考标准本身。

     

    二.ACR/NEMA DICOM 3.0

    PS3.1, …,PS3.16系列出版物

    DICOM (Digital Imaging and Communications in Medicine)标准是量词放射交会的热点。与以前卡法标准的尝试不同,本标准的开发似乎能够达其目标,其核心是供应商能够生产出一件设备或一款软件,其有较大可能性与其他供应商的设备通信。

    DICOM与其他尝试的根本不同点在于它定义了一些所谓“服务对象”偶,(Service-Object Pairs)。例如,如果一个供应商的MR DIOM一致性陈述说:它作为一个服务类提供者(Service Class Prouider)支持一个MR存贮类,而另一个供应商的工作站说:它作为一个服务类使用者(Service Class User)支持MR存贮类,并且两者在仪态网上可以通过TCP/IP建立连接,则两种设备一旦确立了彼此的网址之后几乎肯定能够建立会话。

    DICOM成功的关键在于使用了网络互连的标准设施(TCP/IP及ISO-OSI)。协商消息传输的协议机制,面向对象的信息对象(即数据集)规范以及服务类。

    当然,所有这些将昌盛一个巨大而难以阅读的标准。不过一旦掌握起其本概念则标准本身不过提供了一个详细参考。从用户到设备购买者的观点来看,重要的是能够阅读到或匹配几个供应商的一致性陈述,看看两个设备是否能够建立会话。

    显然,仅仅是能够进行沟通和传递信息是远远不够的,这只不过是有了建立整个实用系统的有用工具,固为一个工作站能够从MRI扫描器拿下图象并不意味着它知道何时去拿?何时有了图象?该图象属于哪个病人?然后保存于何处?更不用提在执行这一项工作时通知RIS/HIS系统(Radiology or Haspital Information System)。换句话说,DICOM一致性并不能保证功能完整性,它知识提供了连接(可能性)保证。

    换句话说,获取了DICOM功效不可欣喜若狂。不能指望它成为创建多供应商应用环境的万能药。

    为获取有关DICOM的更多信息,可以

    <1>Follow the Usenet group: comp.protocals.dicom

    <2>……

    这些与医学图象格式有什么关系呢?

    首先,DICOM3.0将解决将来的连接问题,因此,如果大家都遵从DICOM标准,则从点A到点B传输图象将实实在在地变得更简单。其次,对那些有老设备的人,与新的DICOM符合性设备的借口可能有问题。换句话说,老的网络方案及文件格式必须转换,如果要与DICOM3.0结合建立单向或双向通信的话。我们仍然面临着同样的老问题,既如何移动数据,如何解释它。

    DICOM“消息格式”规范基于ACR/NEMA并与之十分相似。数据字典已被大大扩展,某些数据元素已“退役”,但如果碰上,可以轻松忽略它。消息本身可以在网上以字节流的方式传递。而不是以点对点的排它方式(虽然老的点对点的接口仍然可用)。消息可用多种不同的“传输句法”(Tranfor Stntaxes)编码的传送。

    当两个设备(亦称“应用实体”(Application Entities)或AE)开始“联系”时,它们协调适当的传送句法。它们可以选择“显式Big-Endian传输句法”,其他整数的big-endian方式编码,几个数据元素包含一个特定的域,它陈述说:“我是一个元素符号16号整数”或“我是一个assii浮点数”。或者,反过来,它们可以降低为几个AE都必须支持的缺省传输句法,既“隐式Little-Endian传输句法”,它们和老的ACR/NEMA消息完全相同,字节顺序一旦定义便完全定义。

    这一切都非常好,如果你使用DICOM的方式正如它当初所展望的那样:建立网上会话,协商使用协议,确定传输句法等。但如果你想将DICOM消息存储在一个文件中又将如何?谁能说应使用那种传输句法对它进行离线编码?由Mallinkrodr生产的Central Test Node软件使用的一种方法(用于RSNA Inforad演示)是:直接使用缺省的Little-endian隐式句法存贮它。如果有人想在不同地区或供应商之间寄送磁带,软盘或光盘的话,这种方式显然不是太好。因此,DICOM小组决定定义标准的一个“Media Storage & File Format”(媒介存贮与文件格式)部分,第10,11和12部分已经通过投票。

    在诸多子项中,第10部分定义了一个一般的DICOM文件格式:它定义了一个简单的头部,既“DICOM File Meta Information Header”,

    ①它包含一个128位的预备部分(用户可以填入任何东西)。

    ②一个4字节的DICOM前缀“DICM”。

    ③一个短的DICOM格式消息,它包含新定义的组0002的元素,使用专门的传输语句,它唯一地确定了数据集,也为文件的期于部分指定了传输句法。

    起初,第10部分草案指定缺省的Implicity Value Representation Little Endian Transfer Syntax 作为DICOM File Meta Information Header Tranfer Syntax (文件媒介信息头传输句法)所幸最后文案将次改为Value Representation Little Endian Tranfer Sytax (显式值表示)。

    那我们到底选哪种“传输句法”呢?为何如此麻烦?最大的差别就在于“隐式和显式值表达”,它使单一元素有多种可能的表示法,至少在理论上如此。让人因此有可能创建更多未知数据元素。有些纯粹主义者(如Interfile支持者)可能争辩论,元素应与描述相一致,但也没法阻止某些定义他们自己私有的传输句法,它们所做可信完全一样(多么古怪的想法,用肥皂净口有何不可)。关于Little 与big endian 之争,我不知道有什么好大惊小怪的,它们对运行没有什么影响。

    也许,从长远来看更重要的是:传输句法机制提供了一个封装压缩数据流的方法。这使标准自身不必去处理有关压缩的机制和各种奇思秒想。例如,对DICOM3.0如果出来“正常”传输句法,还定义了一个系列对应与JPEG的各个处理方法。这些传输句法以正常方式编码数据元素,而对图象像素数据,则被编码为一个有效的,自包含的JPEG字节流。各种可逆和不可逆的方法都可提供,不必关系JPEG处理程序需要的多种编码表和参数等技术细节。可以想象,一个支持这种传输句法的显示程序将会切下字节流,将它传递给一个相关的JPEG解码程序,然后取回一个已解压的图象。

    有人可能会不喜欢JPEG标准,但不可否认该方案是可行的,并且已经有一个可逆的压缩方法被无障碍吸收进去,这种压缩方案的有效性有待考查,不可逆法案是否会获取广泛接受还听命于常规的医学合法性偏执狂(medical-legal paranoia),他在美国是很流行的。选择已在那里,就看他们怎么选了。虽然最初多个可想象的JPEG(ISO 10918-1)压缩处理方法早标准中都有定义,但最近除了几个最常用的(如8和12位DCT有损huffman和16无损huffman)的之外,其余都已退役。当然没有拒绝私有的压缩方案被采纳的理由如果它也使用相同的“封装”机制。为保持其广度(bandwidth带宽?),这无疑将会发生。这不会牺牲兼容性,因为我们总是可以回归到缺省的压缩传输句法。近来,JEPG,-LS及JPEG2000也被加入到标准之中,并用于超声应用(程序)(就我可知,也仅用于此)。

      为了识别诸如此类的传输句法,信息对象等,DICOM已采用ISO的“唯一标识”概念(UID),他是一个字符串。对八个用ISO进行注册的组织使用唯一的跟循环,各级组织一次注册形成一个层次状。例如:

    1.2.840.10008.1.2定义为:mplicit VR Little Endian TranSfer Synta,其中1赛表ISO,2代表ISO的一个成员组织分部,840是特定成组织的国家码,此处即为ANSI,10008有ANSI为 注册DICOM。UID也用于唯一表示的非DICOM的特定事物,例如 :信息对象。DICOM称为“UIDS”的东西在ISO OSI的世界中被称为“对称识别符”(Object Identifiers)(OIDS)。

    UIDS的构造是从有一个提供商或供应商或站点的前缀开始,然后接一个唯一的后缀,该后缀金额能由(比如说)一个日期或时间戳产生。例如,一个CT信息对象的实例的UID可能是:

     1.2.840.123456.2.999999.940629.170717

    其中,可以假设一个美国的供应商注册了123456,而设备模组基于他的设备号,病人医院 ID,日期和时间等产生了一个唯一的后缀。这个后缀扯了唯一性外没有其他意义。多个DICOM实现供应商需要一个UID跟,由此产生它们自由的UIDS。

    据说“2016.country”形成的joint ISO-ITU跟当前比“1.country”形成的跟更受欢迎。在注册建立你自己的根号时应记住这点。举例来说,GE目前使用“1.2.840.113619”作为根,但我们可以用“2.16.840.1.113662”作为其根。

    其中“840”是美国的国家码(有一种假设说,多个国家都有一个成员组织负责注册),使用的是ISO3166数字国家码。我不知道在“2.16.840”后为什么会有一个“1”,但使用ISO注册方案时人们似乎不必在“1.2.840”后面加上一个“1”。我也不知道“840”后面的“1”是使用Joint 注册时美国独有的问题,正是别的国家这个“1”。注意:人们不会用0来填充UID单元,因此,对于像巴西这样的国家的三位数ISO3166编码“076”将实际上表示为“7”,如“1.2.74.XXX”。这是对某个特定

    UID产生唯一性后缀时需要特别的注意的。(例如:不要使用序列号“002456”,而应使用“2456”)。

    DICOM带来的另一个新概念是:“信息对象”的概念。在以前的ACR/NEMA标准中,虽然设备模组有特定的数据元素标识,虽然也有规则指出在某些设定下哪些数据元素是前置需要的,哪些是有条件的,哪些是可选的,但这些概念是相对松散定义的。可以认为,为了提供一种机制,以便于制定符合性(一致性),以保证互操作性,所以定义了各种“信息对象”,它们由一些模块集组成。多个模块包含一个特定的数据元素集,按照特别规划可以存在或不存在。

    例如:一个CT图像信息对象包含:一个病人模块,一个一般设备模块,一个CT图像模块和一个图像像素模块。而一个MR图像信息对象则包含有这些模块,除了CT图像模块之外,它由MR图像模块取代。很显然,人们需要有关CT图像的描述信息,他不同于MR图像,然而图像像素数据及病人信息的共同性,该模型已可识别。

    因此,正如此前所述,人们可以定义信息对象和服务“对偶”,它们作用在这类对象之上(提供存贮、查询、提取等操作),人们可以获得SOP类及其实例。这一切都十分面向对象,起初可能有点混淆,但它确实提供了一种机制的以说明(自己)符合(标准)。

    从一个DICOM兼容数据流的解释者的角度来看:这意味着对于一个信息对象的实例,某些信息可以确保在那,这很好!而作为这种数据流的创造者,他必须保证 遵循了所有规则,以确保来自所有必要模块的所有数据元素都存在。

    如果这一切都做了,人们只须将所有数据元素扔到一起,然后按组和元素顺序升序排列,最后把它们泵出去。很可惜数据流本身并不反映这种信息对象的底层顺序。我估计,它们必须保持向后兼容性,故拥有这么一点丑陋。当人们开始考虑如何将多于一个对象放入另一个对象内部的文件夹中时,情况可能更糟。

    现在,我总想包含更多细节,有关多种不同的模块,数据元素及传输句法,甚至TCP/IP的连机接制。然而,所有这些信息,标准自身均已涵盖。

     

    (Philips 医学系统公司  荷兰分公司)

    第一章     DICOM分布式应用概述

      本章主要解释DICOM标准中定义的一些概念。首先,作为介绍DICOM概念的基础,描述了分布式处理的一般模型。其中处理部分设计信息处理(服务类 Service Classes)及其它事项。

    其后二节描述了网络和信息的媒介交换问题。最后,概述了DICOM标准的各个部分和保证联接的特性。

    1.1分布式处理

      一个简单的分布式模型足以解释DICOM标准中使用的机制和术语:

     

    Process1

     

    Process2

    信息

    系统A

    系统B

    分布式Process

     

    通讯

    分布式处理至少有二个process共享信息,各自完成它们自己的处理但依赖与彼此的功能。多个分布的process共享(进程)一起为环境(如放射部门)中的系统提供服务(Service)。例如:Modalities(医学采样设备,建模设备),archive(存储设备),和工作站(都是一个process)各自提供的服务为“采集”“存储”和“图像数据的观察”。

        在大多数分布式处理场合,应用处理程序都力不与通讯进程(process)耦合。通讯进程负责两个系统之间数据传输的协调并补偿不同系统内部数值表达的差异性。

    Proc1

     

    info

    Data

    Data

    Proc2

    info

    传输

    通讯的外观

     

     

    在各个Processes可以协同工作之前;有一些事情必先处理。那就是它们必须统一各自扮演的角色,对信息有一致的看法并选择各自应完成的操作。下图1-1呈现了更多的细节。

     

     

    Client

     

     

     

    Service

    User

    Service

    Provider

    Server

     

     

     

    Service

    User

    Service

    Provider

    关系

    -操 作

    - 信 息

     

    表  示

    (Transfer Format)

    转换格式

    物理交换

    分布式处理

    -网络  -媒介质等

    角色

    角色

     

    服务

    使用者

     

    服务

    提供者

                         图1-1:分布式处理模型

     

    首先,多一边的“角色”必须定义为Server或Client。根据认同的模型行动的另一方为Server彼此之间的期待在它们共享的“关系”中定义。关系定义了哪一边在什么条件下启动process。在大多数情况下,由Client触发process。但有时,Server会合作起动process。

    除了角色之外,双方必须对它们之间交换的“信息”达成一致意见。这里,信息考虑的是它们的语义而不是表达方式(句法)。信息由分布式处理实现的服务的“内容”确定。多个独立的Process对该信息可能有供选择的视角,但该视角必须与整个“内容”一致。

    “操作”定义了对方怎样处理被交换的信息,如存储信息,返回一个结果等。

    “内容”,“关系”,“操作”与“信息”相结合奠定分布式处理的基石。也是实现一个真正的分布式处理必须可先确定的。

    所有这些都是分布式处理“应用领域”的问题。它们不关心信息实际上是如何交换的,而是依赖“交换领域”提供的底层服务(如TCP/IP)来处理交换。

    Client和Server部分都ixu 能够项底层服务发出请求。底层服务的部分称为“服务使用者”(Service user)。相对应的部分称为“服务提供者”(Service provider)。;两方的实现方式可能不同,但它们关于数据交换的知识(协议)相同,并且服务提供者和服务使用者应有相同的逻辑接口(请求格式)。

    服务提供者和服务使用者必须确定信息以哪种格式传输,并将它转换为应用领域期望的“表示方式”。“表示方式”在用户坏人服务器的另一端的服务使用者与提供者之间以及两个服务提供者之间都是相互清楚的。交换之后,呈现给实用信息的process的信息在(client和Server)两端是相同的,不管它是如何交换的。

    服务提供者之间的物理交换可以通过网络或媒介质(如DOR,磁带等)进行。多种机制都有它自己处理表示知识的方式。

     

    1.2        DICOM的一般概念

    DICOM是个标准,它部分地涵盖了前一节讨论的子项。在本届主要讨论有关已使用的实际的交换机制的一般概念。为使本节与前一节保持一致,交换领域的有关概念仅与网络交换有关,在媒介质交换部分尚未发现。

    DICOM使用他自己的术语来描述“内容”,“关系”等概念。第一步我们建立了与分布式处理相同的模型,置换等价的DICOM术语边将图1-1转换成图1-2:

     

     

     

     

     

         角色:                              角色:               

     

                       Service Class(服务器)

                        Class Definition

                         -Service (SOP)

                         -Object (SOP)

     

     

     

                            表   示

     

     

     

     

                         转换句法

     

     

     

                         物理交换

                    一网络,一媒介质等

     

     

     

     

     

     

    Provider

    Service

     

    Service

    Class

    Provider

    (SCP)

     

     

     

    Service

    User

    Service

    Provider

     

    Service

    Class        

    User

    (SCU)

     

     

     

    Service

    User

         

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    图1-2 DICOM Service Class

     

    1.2.1          Service Class与SOP Classes

        现在两个协作者之间的“关系”由“服务类(Service Class)”来描述。“服务类”明确地描述了双方扮演的角色。服务的“内容”依单个“服务类”而定义。对于DICOM两个角色分别命名为:“服务类使用者”(Servie Class User简称SCU)和“服务类提供者”(Servie Class Provider,简称SCP),相当于一个是Client,一个是Server。不要吧SCU和SCP与交换领域的“服务使用者”和“服务提供者”相混淆。

    “服务类”部分本应描述信息和操作,但在DICOM中,这些已和(面向对象的)类定义相结合,称为Service Object Pair Class(服务对象偶类),简称SOP Class。在整个SOP类的定义中,一个单独的Information Object Definition(信息对象定义),简称IOD与一到多个Services相结合。对其中整个service双方需要扮演的角色的细节已经确定。一个服务类中可以有多个SOP类。此时含有多个IOD。一个服务类制定了定义在不同IODs中信息的关系。

    SOP类确定科对一个特定服务类的应用分布式处理的能力,当双方同意使用一个SOP类时,两方映确保各自扮演的角色,使用封装的服务类的内容。在信息交换发生之前,SOP类的确认是一个必须首先处理的重要子项。使用的机制依赖于文档的类别,网络还是媒介质。

    使用服务类及其它诱导的定义,一个分布式处理环境中的协作双方通过交换领域土工的服务共同起作用。

     

    1.2.2信息对象定义(IOD)

    一个SOP类的信息部分在IODs中定义,一个IOD是信息的相关中断的集合,分组为“信息试题”(Information Entities),整个“信息试题”包含可现实世界中一个单项子物的信息,如一个病人,一幅图像等。

    单一信息实体

                          

    IOM

     

    IOM

     

    IOM

      。

      。

      。

      。

    IOM

     

    IOM

     

     

     


    IOD    常规IOD

     

    信息实体

     

    信息实体

     

    信息实体

     

    信息实体

     

     

     


          复合IOD

     

     

     

     

     

     

     

     

     

    图1-3   IOD及属性间的关系

     

        根据服务而来定义内容之不同,一个IOD可以由单一的信息实体构成(称为常规或正规IOD),也可以由一组信息实体构成(称为复合IOD)。实现管理功能的服务类(通常单一子务)一般使用常规IOD,而处理图像数据流的服务类通常使用复合IODs(所处理复杂的信息结构)。

    复合IODs的不同信息实体(结构)之间的关系在隶属于“服务类”的“信息模型”中描述。出现IODs(只有一个信息实体)不需要结构,与其它信息中断的“关系”由指向该信息的引用搞定。

    信息实体由“属性”构成,属性描述了一条单独信息,如“病人姓名”等。具有相互关系的属性被组合到“信息对象模块”中,简记为IOMs。

    IOMs的定义方式使它们可以用于多个IOD。这些IOMs的好处是相关属性的语义描述,可以组合在一起,见图1-3.

    作为一个复合IOD的例子,下图展示了一幅图像的IOD:

     

    属性

    SOP类UID

    SOP实例UID

    病人姓名

    病人ID

    ……

    研究UIO

    研究日期

    研究时间

    研究ID

    ……

    序列UID

    序列编号

    Modality类型

    制造商

    研究机构名

    图象IOD:

    采样属性

    位置编码

    图象编号

    图象类型

    分配位数

    实存位数

    高位

    行数,列数

    ……

    窗口宽度

    窗口中心

    病号(实体)

     

    研究(信息实体)

    序列(信息实体)

    设备(实体)

    图象

    (信息实体)

    模块IOMs

    图1-4

     

     

     

     

    1.2.3属性(是信息实体的组成部分,也可以本身就是信息实体)

    属性是基本的信息实体,必须详细描述。对于属性,DICOM标准定义了如下特性:

    位于属性名(人类可读)

    唯一属性标记(信息系统可读)

    属性描述(语文上的)

    值表示(句法上的)

    值复合度(Value Multiplicity)

    类型分类:1,1C,2,2C或3(用法依赖于SOP类的内容,服务类角色*)。

    类型分类指定了与SOP类和SCU或SCP角色有关的属性的使用。针对具体情况,整个属性被强迫取值(类型1)或被迫带(forced with)或不带一个值(类型2?)或可选(类型3)

    在一个IOD的内部,分组或单一属性依IOD的使用情况而定。例如:使用对比度的检查可以将信息存储在Contrast/Bolus 模块中。因此,该模块的属性是否可用就与“对比”的使用有关。如果使用了(对比度),则该属性的类型分类必被服从(定义为 type1c及type2c)。

     

    1.2.4 服从元素(Service element)

    “服从元素”是允许在某些SOP类的“信息对象”上进行的操作。属于某SOP的服务元素组称为“服务组”。

    一个SOP类的服务组选自于一个DICOM服务元素的固定列表。某些服务元素期望用于一个复用IOD,其他服务元素则用于正规IODs,第三类的服务元素期望与存储媒体相关,以文件方式处理复合及正规SOP类的实例。

    与使用复合IODs(如:传输图像)时,服务类所描述的内容是非常有限的。这种“服务元素”具有复杂含义,如:STORE,FIND,MOVE等。当使用组合服务类时,系列“服务元素”的个体之间可认为存在关联。即便其中真有一个关系存在,也被认为是在服务类的范围之外,应使用服务类在过程中定义。

    相反,使用正规IODs的服务类有广泛的内容,如管理函数等。它们使用原始元素进行简单信息的处理,如:GET,SET,ACTION等。该服务类定义了系列原始法求之间的关系。使用“正规服务类”,合作双方会跟踪两边的进程,并使用“服务元素”来控制它们。

    整个SOP类使用一到多个来自于复合组(C-XXXX)或正规组(N-XXXX)的服务元素。共有以下“服务元素”可供使用:

    C-STOPE,C-FIND,C-MOVE,C-GET,

    C-CANCEL,C-ECHO,

    N-GET,N-SET,N-ACTION,N-CREATE,

    N-DELETE,N-EVENT-REPOPT

    这些服务类的语义取决与它们被用于的服务类和SOP类,与媒介相关的服务元素有:

    M-WRITE,M-DELETE,M-INQUIRE-FILE-SET,M-INQUIRE-FILE

    它们定义了操作文件集的函数原型。

     

    1.2.5.SOP实例

    上述定义的框架当用于分布式处理时X以成形。在双方同意哪个SOP类(蕴含着哪个服务类)被支持,SCU及SCP角色如何划分之后,SOP类的实例就可在双方进行交换。必须为属性提供(语义)正确的值,并将属性存贮于SOP实例之中,如属性定义所指定那样。

    在信息收集完之后,需要按DICOM定义格式对它进行编码,使用TAG(标记)和Value Representation(值表示)来创建DICOM“数据集”。在数据集中,整个属性被编码到一个“数据元素”(Data element)之中。该数据集然后被提交给“交换服务提供者”,它能确保对应方接收到相同的数据集。与系统相关的表示方法有所差异,这些在交换服务中已加以考虑,以确证在语义上值保持不变。

    数据集的接受者将解码数据集的提取它需要的信息,并按SOP类在语义上所认同的那样进行工作。

     

    1.2.6.标识(Identification)

    作为SOP实例创建过程的一部分,会产生一个标识作为SOP实力的属性。“标识”主要提供信息系统使用,而不是供人类使用,它包含两个方面:类标识和实例标识。

    在世界的不同地方有多个供应商的情况下,应使用标识。为保证整个标识的全球唯一性,使用了一种机制以产生如下所示字符串(称为唯一标识或UID):

    <root>.<suffix>

    “根”部分由一个权威部门提供,它能确保没有其它(供应商)使用相同的根。根是一个数字(字串),它由标准组织分派给个公司(如Philips)和医院,她必须确保在它们自己的各系统中保持唯一。通过使用唯一的系统标识,整个系统都会有全球唯一的根,而后缀(suffix)必须由系统在创建实例时动态产生。

    一旦一个实例由一个UID标识了,它就必须持续地使用它。如果对它进行拷贝或重新创建它而无任何改变,则它必有相同的UID,否则,两端同样的信息便会有不同的标识,这将导致混乱。

     

    1.2.7.关系

    除了SOP类和SOP实例标识之外,UIDS也用于实例之间的关系。对于一个复合实例,(公用)如果其中包含一系列图像中的一幅图像(?公共),则包含系列(本身)信息的信息实体对各个实例是公共的。故其关系可由对所有属于该序列的复合的序列实例UID属性使用相同的UID来确定。

    对于正规实例,只有对它本身外部的实例的“参数”可使用,此时需要类与实例标识相结合。当图像之间有一定关系要相互引用时,情况亦如此。

    使用UIDS唯一索引的方法,只有实例相同时方可比较。UID的值本身没有意义,它不能用于排序等处理。使用其它更有意义的属性如:日期,时间,序列号等,可以建立信息之间的关系。

     

    1.2.8 值表示(Value Representation)

    对整个属性都定义了一个“值表示”(VR)。一个“值表示”描述了属性在数据元素中是如何编码的。直白偶是的知识在信息交换的伙伴之间共享,编码与解码过程必须考虑对一个属性(由其标识确定)选择正确的VR。

    共享该信息有两种方法:

    <1>共享数据字典,它包含了整个可能交换的属性

    <2>将值表示作为数据元素的一部分。

    后一种方法增加了信息交换的负担(量),但比迁移中方法灵活。尤其是在有多个供应商的环境中,同步数据子弟你是很困难的。

    如果信息中包含了值表示,则称它的编码方式是“Explicit VR”的显式VR),否则,它使用了隐式VR(implicit VR)。

     

    1.2.9 传输句法(Transfer Syntax)

    在一个SOP实例的数据集能够进行交换之前,将数据集编码为字节流的方式必先确定。如果偶通过网络交换,则用协议。如果用媒介交换,则将数据存储在一起。编码方式由传输句法指定。

    传输句法必须定义的三部分:

    <1>值表示如何指定

    <2>多字节数的字节顺序(words longwords等):little andian或big endian

    <3>在封装情形下(压缩):压缩形式。

    传输句法的处理是服务提供者(serbice provider)的一部分。不过两端进程都必须初始化两方均可接受的,正确的传输句法设置类似于SOP类的标识,传输句法也有一个UID。

     

    1.2.10 (编,解码)概览

    图1-5是编码和解码流的一个概览。

    应用域

    来自字节流的解码数据集

    信 息

    Process1

    SOP

    实例

    表 示

    信息对象定义(IOD)

    传输句法

    信 息

    Process2

    SOP

    实例

    表 示

    编码为字节流

    的数据集

    交换域

    来自数据集的解码SOP实例

    来自SOP实例的解码信息

    SOP实例的编码信息

    数据集中的编码SOP实例

    字节流中的编码数据集

    图1-5SOP实例编码、解码概览

    在交换域中的服务必须确保两端的SOP实例包含“相同信息”不管彼岸是和传输方法如何。

    编码和解码过程包括两个步骤:

    第一步:使用DICOM定义的格式(数据集)传输内部表示,其中整个属性按照为该属性定义的值表示进行存储。

    第二步:将数据集传送到字节流,以便底层进行处理,该步中字节顺序必须与传输句法一致。

        使用这些信息的应用程序必须知道数据对象内部信息的含义(语义)。

     

    1.3 DICOM网络概念

    在上一节讨论了应用域中的DICOM概念,当使用网络进行信息交换时,交换域将包含用于通讯的功能。通讯图见图1-6:

    1.3.1应用实体

    网络化分布式应用的主要X项是:应用程序如何相互接触,必须进行适当安排以便能向对方寻址,并且在交换SOP实例钱就各种X项达成一致。在DICOM网络中,合作双方通过应用实体相互识别。一个“应用实体”是进程的(process)处理通讯的部分。它包含进程的“Service User”,包含建立联系和传输信息的功能。各个应用实体都有一个名称(“应用标题”),在建立通讯的时候必须使用之。

    1.3.2表示地址(Presentation  Address)

    “应用标题”是进行通讯的进程的符号名。在一个真实的网络环境中,必须提供网络地址。称为“表示地址”并指向应用实体的地址,之所以称为“表示地址”是固有“Service User”对应(OSI的)应用层,而“Service Provider”对应(OSI的)表示层(及以下层)。两层之间的边界是“网络访问点”,在此外,数据从应用层传输到网络层。王网络中的各个访问点具有唯一地址。

    “应用标题”到标示地址的映射必须唯一,因为表示地址主要用于连接初始化等,在应用层次方面,应用标题长用于将应用程序与一个目录或类别中的信息源或目标进行等同。如果这源不能无歧意的进行注册,那么系统间的互操作就会有问题。

    附图1-6:

    带网络交换的DICOM

    分布式网络处理

    Service

    Class

    User

     

     

    Service

    User

    Service

    Class

    Provider

     

     

    Service

    User

    类定义:

    -Service

    -Object

     

    Pair(偶)

    Service

    Provider

     

    Service

    Provider

     

    传输句法

    网络交换

    -TCP/IP      –其他

    Associate

     

    Presentation Content

     

     

    表示地址的格式依赖于所使用的网络协议。DICOM网络在大多数情况下是使用TCP/IP协议来实现的。此时,表示地址被映射到TCP/IP套接字。详见1.3.6“TCP/IP协议”。对OSI协议的情形,必须提供一个有效的OSI Presentation Service Access Point(PSAP)(表示服务访问点)。

     

    1.3.3 协商(Association Negotiation)

    为了在两个应用实际之间进行信息交换而建立的连接称为“协同”(Association)。对于一个协同,有一系列沟通子项被确定作为“上下文”(Context),信息在其中交换。该“上下文”(称为Application Context)在DICOM标准中定义,两端必须同意按照该上下文定义进行行动。

    一个应用上下文由一个UID标识,在协同启动过程中,该UID被传送给协作方。通过比较Application Context的找个UID,协作方可以确定是否能够处理协同的这个请求。它要么接受建立协同,要么拒绝它。

    应用上下文覆盖了信息交换的全部功能。哪种类型的信息将跨越协同的双方惊醒交换由SOP类及那些SOP类的服务类确定。协同的初始协作方提议它将使用的SOP类,每个SOP类的SCU/SCP角色,以及信息的表示方法。根据协作的另一方的能力之不同,它可以接受,也可以拒绝每个单独的SOP类。

    经过协商处理之后,协作双方知道了彼此的能力和限制。真正的信息交换就可以按照为这些类定义的服务类规则及SOP类规则来进行。当协同不再被需要时,就会终止。

     

    1.3.4 表示上下文(Presentation Context)

    对协同初始化协商的每个SOP类,涉及的进程之间必须达成一个契约,主要是关于彼此之间使用的传输句法。初始方提议它对某个特定SOP类能够处理的所有传输句法。另一方选出其中一个,确定为该SOP类的“表示上下文”。经过协商之后,每个被接受的SOP类的表示上下文被确定下来。

    一个表示上下文由双方同意的一个数来标识。在一个协同的上下文中可以有多个表示上下文。表示上下文数字标识了发生信息交换的SOP类。

     

    1.3.5  网络协议

    1.3.6          真正的网络协议必须符合OSI协议中定义的标准服务。除了很少使用的OSI协议外,也可以使用其他协议,但它必须与OSI服务相适配,见图1-7.

    图的左侧一般性地展示了带有通讯的进程中的应用实体,右侧展示了应用实体的DICOM功能。

    在应用层,一个DICOM实现应提供两组服务:

    (1)       协同控制协议(Association Control Protocol (ACSE)(服务元素))

    (2)       DICOM消息协议(DICOM Message Protocol(DIMSE)).

    ACSE是标准的OSI协议。

     

    展开全文
  • DICOM标准

    千次阅读 2012-03-08 14:57:31
    dcmtk程序包简介 ***该文简单列出了dcmtk程序包的简介,包括主要接口类...下一步工作准备详细分析每个程序包中的接口类功能,并结合源码和dicom文档分析其实现过程。 Dcmtk程序包简介 一、Config程序包 -

    转自:http://blog.csdn.net/diqiucun666/article/details/2866908

    dcmtk程序包简介
    ***该文简单列出了dcmtk程序包的简介,包括主要接口类的简单说明,可用工具以及一些例子。下一步工作准备详细分析每个程序包中的接口类功能,并结合源码和dicom文档分析其实现过程。

    Dcmtk程序包简介

    一、Config程序包

    -config目录下的文档:

    --config.txt:

    指出你编辑的任何.h .c .cc文件首先必须包含该目录下的头文件#include "osconfig.h"

    --dirstruc.txt:

    给出了dcmtk项目的项目目录结构,这个用cmake会自动生成

    --envvars.txt:

    这个文件比较重要,它指出了一些运行时环境变量,这些变量可能会影响dcmtk的工具和库的使用,这些变量包括:

    ---DCMDICTPATH:影响dcmdata

        On Win32 platforms, a built-in dictionary is used by default. If

        the DCMDICTPATH environment variable is set, the applications will

        attempt to load _additional_ DICOM data dictionaries specified in

        the DCMDICTPATH environment variable instead. The DCMDICTPATH

        environment variable has the same format as the shell PATH variable

        in that a semicolon (";") separates entries. The data dictionary

        code will attempt to load each file specified in the DCMDICTPATH

        environment variable.

        See also: documentation in dcmdata/docs/datadict.txt

    ---TCP_BUFFER_LENGTH:影响dcmnet

        By default, DCMTK uses a TCP send and receive buffer

        length of 32K. If the environment variable TCP_BUFFER_LENGTH is set,

        it specified an override for the TCP buffer length. The value is

        specified in bytes, not in Kbytes.

    ---TCP_NODELAY:影响dcmnet

        If this environment variable contains a non-zero number,

        the Nagle algorithm will not be disabled for TCP transport

        connections. Also see documentation for macro

        DONT_DISABLE_NAGLE_ALGORITHM in config/docs/macros.txt

    ---TMPDIR:影响dcmnet

        Affects the implementation of the tempnam() emulation on

        platforms where tempnam() is not defined. See tempnam(3S) main page

        for a description.

    --macros.txt:

    这个文件也特别重要,它给出了很多编译时的宏,这些宏可能会影响dcmtk的工具和库的使用。大部分的宏可以用来激活一些实验性的或很少需要的特性,另外有一些是用来取消某些功能。要尽量谨慎使用。详细见文档。

    --modules.txt:

    这个文件讲述如何自己配置各个模块,不需要掌握。

    -config的include目录下的文件

    --osconfig.h:这个文件是必须包含在所有.h .c文件中的

    其中指出在win32环境下包含"dcmtk/config/cfwin32.h"文件

    --cfwin32.h:包含了大量的宏定义。***如果需要查找某个宏的定义,可到这个文件中查找***

    二、ofstd程序包

    -ofstd:作为一般目的的类库。

    这个模块包含了一般目的的类库,这些类所描述的对象概念并非在Dicom标准中特有。它们广泛的在toolkit中使用。主要包含下面的类

    --OFCommandLine:处理命令行参数,头文件在ofcmdln.h。***详情需要结合具体的代码来理解***

    --OFCondition:描述条件码的一般类。头文件在ofcond.h。***详情需要结合具体的代码来理解***


    --OFConsole:是一个singleton(孤立)类***不明白***。提供线程安全的对标准输出流和错误流的访问。允许以多线程的方式同时创建输出。***多线程的东西不太明白,它的作用应该是在多线程中实现指定线程的输出流进行输出操作***

    --OFList:是一个双向链表模板类,接口是STL list类中的一个子集。头文件在oflist.h。***不明白为什么不直接用标准库中的list,兼容性应该更好啊***

    --OFStack:是一个堆栈模板类,接口是STL stack类中的一个子集。头文件在ofstack.h。***不明白为什么不直接用标准库中的stack,兼容性应该更好啊***

    --OFStandard:包含大量帮助函数组成的类,用来包含大量“全局”帮助函数。注意全部都是静态函数。其中的一些函数实现调用了windows API函数,如fileexists()。头文件在ofstd.h。***如果需要一些全局函数,可以到这里了找一找。***


    --OFString:一个简单的string类,实现了std::string的一个子集,没有iterator或trait,在速度上也没有优化。头文件在ofstring.h。***不明白为什么不直接用标准库中的string,兼容性应该更好啊***

    --除了上述的主要类以外,还包含了大量辅助类,用来支撑上述类的功能。***详情需要结合具体的代码来理解***

    三、dcmdata程序包

    -dcmdata:一个数据编码/解码库和可用的工具

    这个模块包含了一些类来管理Dicom数据结构和文件。同时它也提供了对DICOMDIR文件的支持以满足Dicom storage media(存储介质)的需要。

    ----------------------------------------------------

    主要的接口类有:

    --DcmFileFormat:a class handling the DICOM file format (with meta header) 。头文件在dcfilefo.h。***详情在单独的文档中分析***

    --DcmDataset:a class handling the DICOM dataset format (files without meta header) 。头文件在dcdatset.h。***详情在单独的文档中分析***

    --DcmItem:a class representing a collection of DICOM elements。头文件在dcitem.h。***详情在单独的文档中分析***

    --DcmElement:abstract base class for all DICOM elements。头文件在dcelem.h。***详情在单独的文档中分析***。它的派生类包括:DcmAttributeTag/DcmByteString/DcmFloatingPointDouble/DcmFloatingPointSingle/DcmOtherByteOtherWord/DcmSequenceOfItems/DcmSignedLong/DcmSignedShort/DcmUnsignedLong/DcmUnsignedShort

    ----------------------------------------------------

    ----------------------------------------------------

    工具:这个模块包含了下面的命令行工具:

    dcm2xml: Convert DICOM file and data set to XML

    dcmconv: Convert DICOM file encoding

    dcmcrle: Encode DICOM file to RLE transfer syntax

    dcmdrle: Decode RLE-compressed DICOM file

    dcmdump: Dump DICOM file and data set

    dcmftest: Test if file uses DICOM part 10 format

    dcmgpdir: Create a general purpose DICOMDIR

    dcmodify: Modify DICOM files

    dump2dcm: Convert ASCII dump to DICOM file

    xml2dcm: Convert XML document to DICOM file or data set

    ***暂时不对命令行工具进行详细的分析***

    ----------------------------------------------------

    ---------------------------------------------------

    举例:

    --调入一个DICOM文件,输出病人姓名

    DcmFileFormat fileformat;

    OFCondition status = fileformat.loadFile("test.dcm");

    if (status.good())

    {

    OFString patientsName;

    if (fileformat.getDataset()->findAndGetOFString(DCM_PatientsName, patientsName).good())

    {

        cout << "Patient's Name: " << patientsName << endl;

    } else

        cerr << "Error: cannot access Patient's Name!" << endl;

    } else

    cerr << "Error: cannot read DICOM file (" << status.text() << ")" << endl;

    --创建一个DICOM dataset数据集,并保存为文件

    char uid[100];

    DcmFileFormat fileformat;

    DcmDataset *dataset = fileformat.getDataset();

    dataset->putAndInsertString(DCM_SOPClassUID, UID_SecondaryCaptureImageStorage);

    dataset->putAndInsertString(DCM_SOPInstanceUID, dcmGenerateUniqueIdentifier(uid, SITE_INSTANCE_UID_ROOT));

    dataset->putAndInsertString(DCM_PatientsName, "Doe^John");

    /* ... */

    dataset->putAndInsertUint8Array(DCM_PixelData, pixelData, pixelLength);

    OFCondition status = fileformat.saveFile("test.dcm", EXS_LittleEndianExplicit);

    if (status.bad())

    cerr << "Error: cannot write DICOM file (" << status.text() << ")" << endl;

    --如何为多个文件创建一般目的的DICOMDIR

    DicomDirInterface dicomdir;

    OFCondition status = dicomdir.createNewDicomDir();

    if (status.good())

    {

    while ( /* there are files */ )

        dicomdir.addDicomFile( /* current filename */ );

    status = dicomdir.writeDicomDir();

    if (status.bad())

        cerr << "Error: cannot write DICOMDIR (" << status.text() << ")" << endl;

    } else

    cerr << "Error: cannot create DICOMDIR (" << status.text() << ")" << endl;

    ------------------------------------------------------------

    四、dcmimgle程序包

    dcmimgle是一个图像处理库和可用的工具模块,它包括了对DICOM单色图像的访问和显示。对颜色图像的支持由dcmimage模块提供,对JPEG压缩图像的支持由dcmjpeg模块支持。

    主要接口类:

    --DicomImage: 为dcmimgle/dcmimage模块提供接口类。主要目的是图像显示。在dcmimage.h中定义。

    --DiDisplayFunction: Class to handle hardcopy and softcopy device characteristics file and manage display LUTs (for calibration). 在didispfn.h中定义。

    可用工具:

    --dcmdspfn: Export standard display curves to a text file

    --dcod2lum: Convert hardcopy characteristic curve file to softcopy format

    --dconvlum: Convert VeriLUM files to DCMTK display files

    举例:

    --载入一幅DICOM单帧单色图像,并显示其像素数据。

    DicomImage *image = new DicomImage("test.dcm");

    if (image != NULL)

    {

    if (image->getStatus() == EIS_Normal)

    {

        if (image->isMonochrome())

        {

          image->setMinMaxWindow();

          Uint8 *pixelData = (Uint8 *)(image->getOutputData(8 /* bits */));

          if (pixelData != NULL)

          {

            /* do something useful with the pixel data */

          }

        }

    } else

        cerr << "Error: cannot load DICOM image (" << DicomImage::getString(image->getStatus()) << ")" << endl;

    }

    delete image;


    五、dcmimage程序包

    dcmimage模块为dcmimgle模块提供对彩色图像的支持。对单色图像的支持由dcmimgle提供,对JPEG压缩图像的支持由dcmjpeg模块支持。


    主要接口类:

    --DicomImage: 在dcmimgle中已介绍。

    工具:

    --dcm2pnm: Convert DICOM images to PPM/PGM, PNG, TIFF or BMP

    --dcmquant: Convert DICOM color images to palette color

    --dcmscale: Scale DICOM images

    举例:

    --载入一幅DICOM单帧图像(单色或彩色),并显示其像素数据。

    #include "diregist.h"   /* required to support color images */

    /* ... */

    DicomImage *image = new DicomImage("test.dcm");

    if (image != NULL)

    {

    if (image->getStatus() == EIS_Normal)

    {

        Uint8 *pixelData = (Uint8 *)(image->getOutputData(8 /* bits per sample */));

        if (pixelData != NULL)

        {

          /* do something useful with the pixel data */

        }

    } else

        cerr << "Error: cannot load DICOM image (" << DicomImage::getString(image->getStatus()) << ")" << endl;

    }

    delete image;


    六、dcmjpeg程序包

    dcmjpeg提供了一个压缩/解压缩库以及可用工具。该模块包含一些类,可将DICOM图像对象在非压缩和JPEG压缩表示(传输协议)之间转换。无失真和有失真JPEG处理都被支持。这个模块实现了一族codec(编码解码器,由DcmCodec类派生而来),可以将这些codec在codec list中注册,codec list是由dcmdata模块保存的。


    主要接口类:

    --DJEncoderRegistration: 一个singleton(孤立)类,为所有支持的JPEG处理注册编码器。在djencode.h中定义。

    --DJDecoderRegistration: 一个singleton(孤立)类,为所有支持的JPEG处理注册解码器。在djdecode.h中定义。

    --DJCodecEncoder: JPEG编码器的一个抽象codec类。This abstract class contains most of the application logic needed for a dcmdata codec object that implements a JPEG encoder using the DJEncoder interface to the underlying JPEG implementation. This class only supports compression, it neither implements decoding nor transcoding. 在djcodece.h中定义。

    --DJCodecDecoder: JPEG解码器的一个抽象codec类。This abstract class contains most of the application logic needed for a dcmdata codec object that implements a JPEG decoder using the DJDecoder interface to the underlying JPEG implementation. This class only supports decompression, it neither implements encoding nor transcoding.

    工具:

    dcmcjpeg: Encode DICOM file to JPEG transfer syntax

    dcmdjpeg: Decode JPEG-compressed DICOM file

    dcmj2pnm: Convert DICOM images to PGM, PPM, BMP, TIFF or JPEG

    dcmmkdir: Create a DICOMDIR file

    举例:

    --用无失真JPEG压缩一幅DICOM图像文件。

    DJEncoderRegistration::registerCodecs(); // register JPEG codecs

    DcmFileFormat fileformat;

    if (fileformat.loadFile("test.dcm").good())

    {

    DcmDataset *dataset = fileformat.getDataset();

    DcmItem *metaInfo = fileformat.getMetaInfo();

    DJ_RPLossless params; // codec parameters, we use the defaults

    // this causes the lossless JPEG version of the dataset to be created

    dataset->chooseRepresentation(EXS_JPEGProcess14SV1TransferSyntax, &params);

    // check if everything went well

    if (dataset->canWriteXfer(EXS_JPEGProcess14SV1TransferSyntax))

    {

        // force the meta-header UIDs to be re-generated when storing the file

        // since the UIDs in the data set may have changed

        delete metaInfo->remove(DCM_MediaStorageSOPClassUID);

        delete metaInfo->remove(DCM_MediaStorageSOPInstanceUID);

        // store in lossless JPEG format

        fileformat.saveFile("test_jpeg.dcm", EXS_JPEGProcess14SV1TransferSyntax);

    }

    }   

    DJEncoderRegistration::cleanup(); // deregister JPEG codecs

    --解压缩一幅JPEG压缩的DICOM图像文件。

    DJDecoderRegistration::registerCodecs(); // register JPEG codecs

    DcmFileFormat fileformat;

    if (fileformat.loadFile("test_jpeg.dcm").good())

    {

    DcmDataset *dataset = fileformat.getDataset();

    // decompress data set if compressed

    dataset->chooseRepresentation(EXS_LittleEndianExplicit, NULL);

    // check if everything went well

    if (dataset->canWriteXfer(EXS_LittleEndianExplicit))

    {

        fileformat.saveFile("test_decompressed.dcm", EXS_LittleEndianExplicit);

    }

    }    
    DJDecoderRegistration::cleanup(); // deregister JPEG codecs

    七、dcmnet程序包

    dcmnet是一个网络库及可用工具。该模块包含了实现DICOM网络通信的所有函数集,即:DICOM上层有限状态机(DICOM Upper Layer Finite State Machine),关联控制服务元素(Association Control Service Element, ACSE)以及DICOM消息服务元素(DICOM Message Service Element, DIMSE)。


    主要接口:该模块的主要接口包括在文件assoc.h和dimse.h中定义的大量结构和函数。


    --assoc.h: 这个文件包含程序,为DICOM应用提供关联管理。它维护描述活动关联的结构,提供对关联特定信息的访问。也提供程序帮助关联协议association negotiation(presentation contexts, abstract syntaxes, transfer syntaxes, maximum PDU length, and other extended negotiation)。该包使用了DICOM上层机制接收/发送关联请求/响应。每一个活动的关联由T_ASC_Association结构表示,包含了所有相关的信息。模块前缀ASC_。

    --dimse.h: 这个文件包含程序,为DICOM应用提供dimse层的服务。

    工具:

    --echoscu: DICOM verification (C-ECHO) SCU

    --findscu: DICOM query (C-FIND) SCU

    --movescu: DICOM retrieve (C-MOVE) SCU

    --storescp: DICOM storage (C-STORE) SCP

    --storescu: DICOM storage (C-STORE) SCU

    --termscu: DICOM termination SCU

    举例:

    --一个简单的Echo SCU(Verification Service Class SCU)。大多数错误处理代码省去了,在Win32上的特定代码如WinSock初始化也省去了。


    T_ASC_Network *net; // network struct, contains DICOM upper layer FSM etc.

    ASC_initializeNetwork(NET_REQUESTOR, 0, 1000 /* timeout */, &net);

    T_ASC_Parameters *params; // parameters of association request

    ASC_createAssociationParameters(&params, ASC_DEFAULTMAXPDU);

    // set calling and called AE titles

    ASC_setAPTitles(params, "ECHOSCU", "ANY-SCP", NULL);


    // the DICOM server accepts connections at server.nowhere.com port 104

    ASC_setPresentationAddresses(params, "localhost", "server.nowhere.com:104");


    // list of transfer syntaxes, only a single entry here

    const char* ts[] = { UID_LittleEndianImplicitTransferSyntax };

    // add presentation context to association request

    ASC_addPresentationContext(params, 1, UID_VerificationSOPClass, ts, 1);

    // request DICOM association

    T_ASC_Association *assoc;

    if (ASC_requestAssociation(net, params, &assoc).good())

    {

    if (ASC_countAcceptedPresentationContexts(params) == 1)

    {

        // the remote SCP has accepted the Verification Service Class

        DIC_US // generate next message ID

        DIC_US status; // DIMSE status of C-ECHO-RSP will be stored here

        DcmDataset *sd = NULL; // status detail will be stored here

        // send C-ECHO-RQ and handle response

        DIMSE_echoUser(assoc, id, DIMSE_BLOCKING, 0, &status, &sd);

        delete sd; // we don't care about status detail

    }

    }

    ASC_releaseAssociation(assoc); // release association

    ASC_destroyAssociation(&assoc); // delete assoc structure

    ASC_dropNetwork(&net); // delete net structure

    八、dcmpstat程序包

    dcmpstat: 一个描述状态(presentation state)库和可用工具。This module contains classes that implement a high-level API for the DICOM Softcopy Grayscale Presentation State Storage SOP Class. It also contains various support classes that are used by DICOMscope, a free DICOM viewer that has been developed as a demonstrator for presentation states. See http://dicom.offis.de/dscope

    主要接口:

    --DVPresentationState: 一个灰度软拷贝描述状态。这个类管理着一个描述状态对象的数据结构。描述状态可以创建、读、写和更改。在dvpstat.h中定义。

    --DVInterface: 这个接口类是用来帮助软拷贝描述状态浏览器工作的。这个类管理着数据库机制,允许开始和停止网络交互,并访问图像和描述状态。在dviface.h中定义。

    --DVPSStoredPrint: the representation of a Stored Print object。在文件dvpssp.h中定义。

    工具:

    dcmmkcrv: Add 2D curve data to image

    dcmmklut: Create DICOM look-up tables

    dcmp2pgm: Read DICOM image and presentation state and render bitmap

    dcmprscp: DICOM basic grayscale print management SCP

    dcmprscu: Print spooler for presentation state viewer

    dcmpschk: Checking tool for presentation states

    dcmpsmk: Create DICOM grayscale softcopy presentation state

    dcmpsprt: Read DICOM images and presentation states and render print job

    dcmpsrcv: Network receive for presentation state viewer

    dcmpssnd: Network send for presentation state viewer

    举例:

    --给一幅DICOM图像创建一个缺省的描述状态

    DcmFileFormat infile;

    DcmFileFormat outfile;

    if (infile.loadFile("image.dcm").good())

    {

    DVPresentationState pstate; // presentation state handler

    if (pstate.createFromImage(*infile.getDataset()).good())

    {

        // serialize presentation state into DICOM data set structure

        if (pstate.write(*outfile.getDataset(), OFFalse).good())

        {

          // and write to file

          outfile.saveFile("gsps.dcm", EXS_LittleEndianExplicit);     

        }

    }

    }


    --应用一个描述状态中的灰度变换管道给一幅DICOM图像

    DcmFileFormat imagefile;

    DcmFileFormat gspsfile;

    if (imagefile.loadFile("image.dcm").good() &&

        gspsfile.loadFile("gsps.dcm").good())

    {

    DVPresentationState pstate; // presentation state handler

    if (pstate.read(*gspsfile.getDataset()).good()) // parse gsps object

    {

        // attach presentation state to image data

        if (pstate.attachImage(&imagefile, OFFalse).good())

        {

          const void *pixel; // pointer to pixel data, one byte per pixel

          unsigned long width;   // width of image bitmap

          unsigned long height; // height of image bitmap

          if (pstate.getPixelData(pixel, width, height).good())

          {

            /* do something useful with the pixel data */

          }

          pstate.detachImage(); // release connection between GSPS and image

        }

    }

    }

    九、dcmsign程序包

    dcmsign是一个数字签名库和可用工具。这个模块包含了一些类,以创建DICOM数据集中的数字签名,并验证和删除签名。这个模块需要扩展的OpenSSL库的支持。


    主要接口:
    --DcmSignature: this class provides the main interface to the dcmsign module - it allows to create, examine and verify digital signatures in DICOM datasets or items. The methods in this class do not handle digital signatures embedded in sequence items within the dataset, other than providing helper functions that allow to locate and attach the sub-items separately. 在dcsignat.h中定义。

    --SiSecurityProfile: 所有安全框架的抽象基类。abstract base class for all security profiles. 在sisprof.h文件中定义。

    --SiCertificate: a class representing X.509 public key certificates. 在sicert.h文件中定义。


    --SiPrivateKey: a class representing a private key. 在siprivat.h文件中定义。

    --SiMAC: a base class for all classes that implement hash functions. 在simac.h文件中定义。


    工具:

    dcmsign: Sign and Verify DICOM Files


    举例:

    --验证一个DICOM文件中的所有签名。

    DcmFileFormat fileformat;

    if (fileformat.loadFile("test.dcm").good())

    {

    int counter = 0;          // counts the signatures in the DICOM file

    int corrupt_counter = 0; // counts signatures that failed verification

    DcmDataset *dataset = fileformat.getDataset();

    DcmStack stack;           // stores current location within file

    DcmSignature signer;      // signature handler

    DcmItem *sigItem = DcmSignature::findFirstSignatureItem(*dataset, stack);

    while (sigItem) // browse through items that contain digital signatures

    {

        signer.attach(sigItem); // each item may contain multiple signatures

        for (unsigned long l=0; l < signer.numberOfSignatures(); ++l)

        {

          if (signer.selectSignature(l).good())

          {

            ++counter;
            if (signer.verifyCurrent().bad()) // verify signature
               corrupt_counter++;
          }
        }
        signer.detach();
        sigItem = DcmSignature::findNextSignatureItem(*dataset, stack);
    }
    if (counter == 0) 
          cerr << "no signatures found in dataset." << endl;
    else 
          cerr << counter << " signatures verified in dataset, " 
               << corrupt_counter << " corrupted." << endl;
    }
    --给一个DICOM文件增加签名。
    DcmFileFormat fileformat;
    if (fileformat.loadFile("test.dcm").good())

    {
    DcmDataset *dataset = fileformat.getDataset();
    SiCreatorProfile profile; // select the "RSA Creator Profile"
    SiRIPEMD160 mac;           // use RIPEMD160 as MAC algorithm
    DcmSignature signer;       // signature handler
    SiCertificate cert;        // our certificate
    if (cert.loadCertificate("certificate.pem", X509_FILETYPE_PEM).bad())
    {
        cerr << "unable to load certificate" << endl;
        return;
    }
    SiPrivateKey key; // private key, must be unencrypted here
    if (key.loadPrivateKey("privkey.pem", X509_FILETYPE_PEM).bad())
    {
        cerr << "unable to load private key" << endl;
        return;
    }
    signer.attach(dataset); // connect handler to data set
    if (signer.createSignature(key, cert, mac, profile).good())
    {
        fileformat.saveFile("test_signed.dcm"); // write back
    }
    }
    十、dcmsr程序包
    dcmsr是一个结构化报表库和可用工具。这个模块包括一些类来读、写、创建、修改、访问、打印和显示DICOM结构化报表文档。所支持的SOP类列表由DSRTypes::E_DocumentType提供。

    主要接口:
    --DSRDocument: Interface class for 'dcmsr' (DICOM Structured Reporting Documents). This class supports reading, writing, creation, printing and rendering of DICOM SR documents (according to DICOM PS 3.x-2004, formerly known as Supplement 23). The list of supported SOP classes is available in file "dsrtypes.h". 在dsrdoc.h中定义。
    --DSRDocumentTree: 管理SR文档树的类。在dsrdoctr.h中定义。
    --DSRContentItem: Interface class for content items. This class allows to access the document tree nodes without using any pointers. 在dsrcitem.h中定义。
    --DSRCodedEntryValue: Class for coded entry values. 在dsrcodvl.h中定义。

    工具:
    dsr2html: Render DICOM SR file and data set to HTML 
    dsr2xml: Convert DICOM SR file and data set to XML 
    dsrdump: Dump DICOM SR file and data set 
    xml2dsr: Convert DICOM SR file and data set to XML

    举例:
    --载入一个DICOM结构化报表,并以HTML格式显示其内容。
    DcmFileFormat fileformat;
    OFCondition status = fileformat.loadFile("test.dcm");
    if (status.good())
    {
    DSRDocument document;
    status = document.read(*fileformat.getDataset());
    if (status.good())
    {
        status = document.renderHTML(cout);
        if (status.bad())
          cerr << "Error: cannot render SR document (" << status.text() << ")" << endl;
    } else
        cerr << "Error: cannot parse SR document (" << status.text() << ")" << endl;
    } else
    cerr << "Error: cannot read DICOM file (" << status.text() << ")" << endl;
    --创建一个DICOM结构化报告,并将其存为文件。
    DSRDocument document;
    document.setPatientsName("Doe^John");
    /* ... */
    document.getTree().addContentItem(DSRTypes::RT_isRoot, DSRTypes::VT_Container);
    document.getTree().getCurrentContentItem().setConceptName(DSRCodedEntryValue(/* some code */));
    document.getTree().addContentItem(DSRTypes::RT_hasObsContext, DSRTypes::VT_Code, DSRTypes::AM_belowCurrent);
    /* ... */
    DcmFileFormat fileformat;
    OFCondition status = document.write(*fileformat.getDataset())
    if (status.good())
    {
    status = fileformat.saveFile("test.dcm", EXS_LittleEndianExplicit);
    if (status.bad())
        cerr << "Error: cannot write DICOM file (" << status.text() << ")" << endl;
    } else
    cerr << "Error: cannot write SR document (" << status.text() << ")" << endl;
    --读取文档树的属性,并直接修改。
    DSRDocument document(DSRTypes::DT_KeyObjectDoc);
    /* ... */
    document.getTree().addContentItem(DSRTypes::RT_isRoot, DSRTypes::VT_Container);
    DSRCodedEntryValue *codePtr = document.getTree().getCurrentContentItem().getConceptNamePtr();
    if (codePtr != NULL)
    codePtr->setCode("113000", "DCM", "Of Interest");
    /* ... */
    document.getTree().addContentItem(DSRTypes::RT_contains, DSRTypes::VT_Image);
    DSRImageReferenceValue *imagePtr = document.getTree().getCurrentContentItem().getImageReferencePtr();
    if (imagePtr != NULL)
    {
    imagePtr->setValue(DSRImageReferenceValue(UID_UltrasoundMultiframeImageStorage, /* image UID */));
    imagePtr->setPresentationState(DSRCompositeReferenceValue(UID_GrayscaleSoftcopyPresentationStateStorage, /* GSPS UID */));
    imagePtr->getFrameList().addItem(2);
    imagePtr->getFrameList().addItem(5);
    }

    /* ... */
    十一、dcmtls程序包
    dcmtls是网络库的安全扩展。This module contains classes that implement DICOM network communication tunneled through a Transport Layer Security (TLS) connection, conforming to the DICOM "Security Enhancements One" extension (formerly Supplement 31). This module requires the external OpenSSL library.

    主要接口:
    --DcmTLSTransportLayer: factory class which creates secure TLS transport layer connections and maintains the parameters common to all TLS transport connections in one application (e.g. the pool of trusted certificates, the key and certificate to be used for authentication and the list of ciphersuite to be used for association negotiation.)。在tlslayer.h文件中定义。
    --DcmTLSConnection: this class represents a TLS (Transport Layer Security) V1 based secure transport connection.

    举例:
    --TLS的关联请求应用
    T_ASC_Network *net;        // network initialization code not shown,
    T_ASC_Parameters *params; // we just assume these pointers to be valid

    // create TLS object that initializes the random generator through a file

    // "random.dat" containing random data (1 kByte is sufficient).

    DcmTLSTransportLayer *tLayer = new DcmTLSTransportLayer(

    DICOM_APPLICATION_REQUESTOR, "random.dat");

    if (TCS_ok != tLayer->setPrivateKeyFile("privkey.pem", SSL_FILETYPE_PEM))
    {
    cerr << "unable to load private key" << endl;
    return;
    }

    if (TCS_ok != tLayer->setCertificateFile("certificate.pem", SSL_FILETYPE_PEM))
    {
    cerr << "unable to load certificate" << endl;
    return;
    }

    // enable the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite

    tLayer->setCipherSuites(SSL3_TXT_RSA_DES_192_CBC3_SHA);

    // accept any certificate from the remote site (not recommended)

    tLayer->setCertificateVerification(DCV_ignoreCertificate);

    // register and activate TLS layer

    ASC_setTransportLayer(net, tLayer, 1);

    ASC_setTransportLayerType(params, 1);

    十二、dcmwlm程序包

    dcmwlm是一个设备工作表(Modality Worklist)数据库服务器。这个模块包含类,作为一个SCP,为实现DICOM Modality Worklist Management Service的应用提供支持。基于这些类的SCP可以从C-Find-RSP返回消息中找到相关信息。

    主要接口:

    --WlmActivityManager: This class encapsulates data structures and operations for basic worklist management service class providers. 在wlmactmg.h文件中定义。

    --WlmDataSource: This class encapsulates data structures and operations for connecting to an arbitrary data source in the framework of the DICOM basic worklist management service. 在wlds.h文件中定义。

    --WlmDataSourceFileSystem: This class encapsulates data structures and operations for connecting to a file-based data source in the framework of the DICOM basic worklist management service. 在wldsfs.h文件中定义。

    --WlmFileSystemInteractionManager: This class encapsulates data structures and operations for managing data base interaction in the framework of the DICOM basic worklist management service. 在wlfsim.h文件中定义。

    工具:

    wlmscpfs: DICOM Basic Worklist Management SCP (based on data files)

    举例:

    For an example of how to use the main interface classes of this module, see file 'wlmscpfs.cc' (containing the main function of the corresponding tool) and file 'wlcefs.cc' (making use of the WlmActivityManager class that manages all activities a corresponding SCP has to manage).

    十三、dcmqrdb程序包

    dcmqrdb是一个图像数据库服务器。This module contains a simple image archive that manages a number of storage areas and allows images to be stored in these storage areas using the DICOM Storage Service Class. It also allows image attributes to be queried and images to be retrieved using the DICOM Query/Retrieve Service Class.

    工具:

    dcmqridx: Register a DICOM image file in an image database index file

    dcmqrscp: DICOM image archive (central test node)

    dcmqrti: The Terminal Initiator Telnet Client Program

    文件:下面文件提供进一步信息。

    --dcmqrcnf.txt:

    展开全文
  • DICOM标准简介

    2016-09-23 15:21:25
    DICOM标准简介
  • DICOM标准.zip

    2021-03-23 15:53:48
    DICOM标准协议,说明文档,离线查看无须等待加载
  • DICOM标准中文PDF版

    2019-02-14 17:09:25
    DICOM标准中文PDF版。老版本DICOM标准的中文翻译,学习DICOM标准的时候可以参考一下。 DICOM 中文。
  • dicom标准2011版

    2020-11-04 11:47:11
    2011版dicom标准,影像方向必看必学,介绍了医疗影像相关的基础知识和常识,dcm文件的组成、生成,以及dicom软件如何进行通信等
  • DICOM标准3.0中文版

    2019-04-10 17:32:37
    DICOM标准3.0中文翻译版本,详细介绍了DICOM标准3.0版本的内容。
  • DICOM标准中文版

    2018-10-16 16:00:54
    此压缩包包括:dicom标准协议1-13章和dicom协议解释1-3部分.
  • dicom 标准三方测试工具
  • DICOM标准概要

    2019-08-14 16:27:40
    1.DICOM标准英文文档https://www.dicomstandard.org/current/...3.DICOM标准文件内容概要 DICOM(Digital Imaging and Communications in Medicine)医学数字成像和通信 重点在2——9 第一部分:引言与概述,简要...

    1.DICOM标准英文文档 https://www.dicomstandard.org/current/  

    2.DCM4CHE相关网页https://www.dcm4che.org/

    3.DICOM标准文件内容概要

    DICOM(Digital Imaging and Communications in Medicine)医学数字成像和通信

      重点在2——9

    第一部分:引言与概述,简要介绍了DICOM的概念及其组成。

    第二部分:兼容性,精确地定义了声明DICOM要求制造商精确地描述其产品的DICOM兼容性,即构造一个该产品的DICOM兼容性声明,它包括选择什么样的信息对象、服务类、数据编码方法等,每一个用户都可以从制造商处得到这样一份声明。

    第三部分:利用面向对象的方法,定义了两类信息对象类:普通性、复合型。

    第四部分:服务类,说明了许多服务类,服务类详细论述了作用与信息对象上的命令及其产生的结果。

    第五部分:数据结构及语意,描述了怎样对信息对象类和服务类进行构造和编码。

    第六部分:数据字典,描述了所有信息对象是由数据元素组成的,数据元素是对属性值的编码。

    第七部分:消息交换,定义了进行消息交换通讯的医学图像应用实体所用到的服务和协议。

    第八部分:消息交换的网络通讯支持,说明了在网络环境下的通讯服务和支持DICOM应用进行消息交换的必要的上层协议。

    第九部分:消息交换的点对点通讯支持,说明了与ACR—NEMA2.0兼容的点对点通讯的服务和协议。

    第十部分:便于数据互换的介质存储方式和文件格式

    第十一部分:介质存储应用框架

    第十二部分:便于数据互换的介质格式和物理介质

    第十三部分:打印管理的点对点通讯支持

    第十四部分:亮度[灰度]色标显示功能标准

    第十五部分:安全性概述

    第十六部分:绘制资源目录

    第十七部分:信息解释(Explanatory Information)

    第十八部分:Web获取DICOM永久对象(Web Access to DICOM Persisent Objects(WADO))

    4.ACSE级别服务(http://dicom.nema.org/medical/dicom/current/output/html/part08.html

    ACSE:连接控制服务元素(Association Control Service Element)

    对应的PDU有A-ASSOCIATE-RQ、A-ASSOCIATE-AC、A-ASSOCIATE-RJ、P-DATA-TF、A-RELEASE-RQ、A-RELEASE-RP、A-ABORT七种。

    5.DICOM服务(http://dicom.nema.org/medical/dicom/current/output/html/part07.html

    DIMSE:DICOM 消息服务元素(DICOM Message Service Elements)

    DIMSE-C服务是只适用于复合IOD的服务,只提供操作服务。

    DIMSE-N是只适用于规格化IOD的服务,即提供操作服务也提供通知服务。

    组别 名称 作用 类型
    DIMSE-C C-ECHO 确认通信 operation
    C-FIND 查询病人图像信息 operation
    C-STORE 存储图像 operation
    C-GET 属性值检索匹配的SOP实例 operation
    C-MOVE 转存或获取病人图像 operation
    DIMSE-N N-GET 检索属性值 operation
    N-SET 设置参数 operation
    N-ACTION 触发服务过程 operation
    N-CREATE 生成SOP实例 operation
    N-DELETE 删除SOP实例 operation
    N-EVENT-REPORT 报告当前状态 Notification


    6.VR

    VR是什么???最开始的时候一直没搞懂,其实它就类似于JAVA总的int、String...,这么说是不是很好理解了;

    标准描述为 VR是DICOM标准中用来描述数据类型的,总共有27个值。

    简单分类如下:

    VR

    含义

    允许

    字符

    数据长度

    CS - Code String

    代码字符串

    开头结尾可以有没有意义的空格的字符串,比如“CD123_4”

    大写字母,0-9,空格以及下划线字符

    最多 16 个字符

    SH - Short String

    短字符串

    短字符串,比如:电话号码,ID等

     

    最多 16 个字符

    LO - Long String

    长字符串

    一个字符串,可能在开头、结尾填有空格。比如“Introduction to DICOM”

     

    最多 64 个字符

    ST - Short Text

    短文本

    可能包含一个或多个段落的字符串

     

    最多 1024 个字符

    LT - Long Text

    短文本

    可能包含一个或多个锻炼的字符串,与LO相同,但可以更长

     

    最多 10240 个字符

    UT - Unlimited Text

    无限制文本

    包含一个或多个段落的字符串,与 LT类似

     

    最多(2的32次方–2)个字符

    AE - Application Entity

    应用实体

    标识一个设备的名称的字符串,开头和结尾可以有无意义的字符。比如“MyPC01”

     

    最多 16 个字符

    PN - Person Name

    病人姓名

    有插入符号(^)作为姓名分隔符的病人姓名。比如“SMITH^JOHN” “Morrison- Jones^Susan^^^Ph.D, Chief Executive Officer”

     

    最多 64 个字符

    UI - Unique Identifier (UID)

    唯一标识符

    一个用作唯一标识各类项目的包含 UID的字符串。比如“1.2.840.10008.1.1”

    0-9 和半角句号(.)

    最多64 个字符

    DA - Date

    日期

    格式为 YYYYMMDD 的字符串;YYYY代表年;MM 代表月;DD 代表日。比如“20050822”表示 2005 年 8 月22 日

    0-9

    8个字符

    TM - Time

    时间

    格式为 HHMMSS 的字符串。FRAC;HH 表示小时(范围“00”-“23”);MM表示分钟(范围“00”-“59”); 而 FRAC包含秒的小数部分,即百万分 之一秒。比如“183200.00” 表示下午6:32

    0-9 和半角句号(.)

    最多 16 个字符

    DT - Date Time

    日期时间

    格式为 YYYYMMDDHHMMSS. FFFFFF,串联的日期时间字符串。字符串的各部分从左至右是:年 YYYY;月 MM;日 DD;小时 HH;分钟MM;秒 SS;秒的小数 FFFFFF。比如20050812183000.00”表示 2005年 8 月 12 日下午 18 点 30 分 00秒

    0-9,加号,减号和半角句号

    最多 26 个字符

    AS - Age String

    年龄字符串

    符合以下格式的字符串:nnnD,nnnW, nnnM, nnnY;其中 nnn对于 D 来说表示天数,对于W来说表示周数,对于M 来说表示月数,对于Y来说表示岁数。 比如“018M”表示他的年龄是 18 个月

    0–9, D,W,M, Y

    4 个字符

    IS - Integer String

    整型字符串

    表示一个整型数字的字符串。比如“-1234567”

    0-9,加号(+),减号(-)

    最多 12 个字符

    DS - Decimal String 小数字符串

    表示定点小数和浮点小数。 比如“12345.67”,“-5.0e3”

    0-9,加号(+),减号(-), 最多 16个字符 E,e和半角句号(.)

    最多 16 个字符

    SS - Signed Short

    有符号短型

    符号型二进制整数,长度 16 比特

     

    2 个字符

    US - Unsigned Short 无符号短型

    无符号二进制整数,长度 16 比特

     

    2 个字符

    SL - Signed Long

    有符号长型

    有符号二进制整数

     

    4 个字符

    UL - Unsigned Long 无符号长型

    无符号二进制整数,长度 32 比特

     

    4 个字符

    AT - Attribute Tag

    属性标签

    16 比特无符号整数的有序对,数据元素的标签

     

    4 个字符

    FL - Floating Single 单精度浮点

    单精度二进制浮点数字

     

    4 个字符

    FD - Floating Point Double

    双精度二进制浮点数字

    双精度二进制浮点数字

     

    8 个字符

    OB - Other Byte String

    其他字节字符串

    字节的字符串(“其他”表示没有在VR中定义的内容)

       

    OW - Other Word String

    其他单词字符串

    16 比特(2 字节)单词字符串

       

    OF - Other Float String

    其他浮点字符串

    32 比特(4 个字节)浮点单词字符串

       

    SQ - Sequence Items

    条目序列

    条目的序列

       

    UN – Unknown

    未知

    字节的字符串,其中内容的编码方式是未知的

       

    7. DICOM TAG分类和说明

    Tag是4个字节表示的  前两字节是组号   后两字节是偏移号   比如0008,0018。

    通俗的讲dataElement就是指Tag,Tag就是DICOM标准里面定义的数据字典;

    显示VR:VR为OB OW OF UT SQ UN的元素结构

    组号

    元素号

    VR

    预留

    值长度

    数据元素值

    2

    2

    2

    2(0x00,0x00)

    4

    由数据长度决定

    显示VR:VR为普通类型时元素结构(少了预留那一行)

    组号

    元素号

    VR

    值长度

    数据元素值

    2

    2

    2

    2

    由数据长度决定

    隐式VR 时元素结构

    组号

    元素号

    值长度

    数据元素值

    2

    2

    4

    由数据长度决定

    以下为DICOM文件中部分Tag的说明

    Patient Tag

    Group

    Element

    Tag Description

    中文解释

    VR

    0010

    0010

    Patient’s Name

    患者姓名

    PN

    0010

    0020

    Patient ID

    患者ID/影像号

    LO

    0010

    0030

    Patient’s Birth Date

    患者出生日期

    DA

    0010

    0032

    Patient’s Birth Time

    患者出生时间

    TM

    0010

    0040

    Patient’s Sex

    患者性别

    CS

    0010

    1030

    Patient’s Weight

    患者体重

    DS

    0010

    21C0

    Pregnancy Status

    怀孕状态

    US

    Study Tag 

    Group

    Element

    Tag Description

    中文解释

    VR

    0008

    0050

    Accession Number:

    A RIS generated number that identifies the order for the Study.

    检查号/存取编号;

    RIS的生成序号,用以标识做检查的次序.

    SH

    0020

    0010

    Study ID

    检查ID.

    SH

    0020

    000D

    Study Instance UID:

    Unique identifier for the Study.

    检查实例号:

    唯一标记不同检查的号码.

    UI

    0008

    0020

    Study Date:

    Date the Study started.

    检查日期:

    检查开始的日期.

    DA

    0008

    0030

    Study Time:

    Time the Study started.

    检查时间:

    检查开始的时间.

    TM

    0008

    0061

    Modalities in Study

    一个检查中含有的不同检查类型.

    CS

    0008

    0015

    Body Part Examined

    检查的部位.

    CS

    0008

    1030

    Study Description

    检查的描述.

    LO

    0010

    1010

    Patient’s Age

    做检查时刻的患者年龄,而不是此刻患者的真实年龄.

    AS

     

    Series Tag   

    Group

    Element

    Tag Description

    中文解释

    VR

    0020

    0011

    Series Number:

    A number that identifies this Series.

    序列号:

    识别不同检查的号码.

    IS

    0020

    000E

    Series Instance UID:

    Unique identifier for the Series.

    序列实例号:

    唯一标记不同序列的号码.

    UI

    0008

    0060

    Modality

    检查模态(MRI/CT/CR/DR)

    CS

    0008

    103E

    Series Description

    检查描述和说明

    LO

    0008

    0021

    Series Date

    检查日期

    DA

    0008

    0031

    Series Time

    检查时间

    TM

    0020

    0032

    Image Position (Patient):

    The x, y and z coordinates of the upper left hand corner of the image, in mm.

    图像位置:

    图像的左上角在空间坐标系中的x,y,z坐标,单位是毫米. 如果在检查中,则指该序列中第一张影像左上角的坐标.

    DS

    0020

    0037

    Image Orientation (Patient):

    The direction cosines of the first row and the first column with respect to the patient.

    图像方位:

    DS

    0018

    0050

    Slice Thickness:

    Nominal slice thickness, in mm.

    层厚.

    DS

    0018

    0088

    Spacing Between Slices

    层与层之间的间距,单位为mm

    DS

    0020

    1041

    Slice Location:

    Relative position of exposure expressed in mm.

    实际的相对位置,单位为mm.

    DS

    0018

    0023

    MR Acquisition

     

    CS

    0018

    0015

    Body Part Examined

    身体部位.

    CS

     

    Instance Tag 

    Group

    Element

    Tag Description

    中文解释

    VR

    0008

    0008

    Image Type:

    Image identification characteristics.

     

    CS

    0008

    0018

    SOP Instance UID

    SOP实例UID.

     

    0008

    0023

    Content Date:

    The date the image pixel data creation started.

    影像拍摄的日期.

    DA

    0008

    0033

    Content Time

    影像拍摄的时间.

    TM

    0020

    0013

    Image/Instance Number:

    A number that identifies this image.

    图像码:

    辨识图像的号码.

    IS

    0028

    0002

    Samples Per Pixel:

    Number of samples (planes) in this image.

    图像上的采样率.

    US

    0028

    0004

    Photometric Interpretation:

    Specifies the intended interpretation of the pixel data.

    光度计的解释,对于CT图像,用两个枚举值

    MONOCHROME1,MONOCHROME2.

    用来判断图像是否是彩色的,

    MONOCHROME1/2是灰度图,

    RGB则是真彩色图,还有其他.

    CS

    0028

    0010

    Rows: Number of rows in the image.

    图像的总行数,行分辨率.

    US

    0028

    0011

    Columns: Number of columns in the image.

    图像的总列数,列分辨率.

    US

    0028

    0030

    Pixel Spacing:

    Physical distance in the patient between the center of each pixel.

    像素间距.

    像素中心之间的物理间距.

    DS

    0028

    0100

    Bits Allocated:

    Number of bits allocated for each pixel sample. Each sample shall have the same number of bits allocated.

    分配的位数:

    存储每一个像素值时分配的位数,每一个样本应该拥有相同的这个值.

    US

    0028

    0101

    Bits Stored:

    Number of bits stored for each pixel sample. Each sample shall have the same number of bits stored.

    存储的位数:有12到16列举值.

    存储每一个像素用的位数.每一个样本应该有相同值.

    US

    0028

    0102

    High Bit:

    Most significant bit for pixel sample data. Each sample shall have the same high bit.

    高位.

    US

    0028

    0103

    Pixel Representation:

    Data representation of the pixel samples. Each sample shall have the same pixel representation.

    Enum: 0000H=unsigned integer,

    0001H=2’s complement.

    像素数据的表现类型:

    这是一个枚举值,分别为十六进制数0000和0001.

    0000H = 无符号整数,

    0001H = 2的补码.

    US

    0028

    1050

    Window Center

    窗位.

    DS

    0028

    1051

    Window Width

    窗宽.

    DS

    0028

    1052

    Rescale Intercept:

    The value b in relationship between stored values (SV) and the output units.

    Output units = m*SV + b.

    Required if Modality LUT Sequence (0028, 0030) is not present.

    截距:

    如果表明不同模态的LUT颜色对应表不存在时,则使用方程

    Units = m*SV + b,计算真实的像素值到呈现像素值。

    其中这个值为表达式中的b。

    DS

    0028

    1053

    Rescale Slope:

    m in the equation specified by Rescale Intercept (0028,1052).

    Required if Rescale Intercept is present.

    斜率.

    这个值为表达式中的m。

    DS

    0028

    1054

    Rescale Type:

    Specifies the output units of Rescale Slope (0028,1053) and Rescale Intercept (0028,1052).

    Enum: US=Unspecified Requried if Photometric Interpretation is MONOCHROME2, and Bits Stored is greater than 1.

    This specifies an identity Modality LUT transformation.

    输出值的单位.

    这是一个枚举值,

    LO

     

    后续会补充具体C-FIND 、C-STORE、C-MOVE等通讯的是如何工作;

    展开全文
  • DICOM标准,DICOM3.0

    2009-08-24 12:50:46
    dicom标准,适合医学软件开发者。定义几台机器之间的一种标准!
  • DICOM标准解析器 该程序将的Web版本解析为对人类和机器友好的JSON文件。 这些JSON文件的目的是双重的: 提供一种标准化的且机器可读的方式来访问软件应用程序的DICOM标准信息 为DICOM标准中的交叉引用部分之间的关...
  • [医疗信息化][DICOM教程]DICOM标准简介 使用OsiriX的DICOM标准简介 内容 介绍 什么是DICOM 医院系统内的图像传输 了解DICOM服务 OsiriX提供的DICOM服务 其他DICOM服务 DICOM文件格式 DICOM结构化报告 符合DICOM ...

    [医疗信息化][DICOM教程]DICOM标准简介

    使用OsiriX的DICOM标准简介

    内容

    1. 介绍
    2. 什么是DICOM
    3. 医院系统内的图像传输
    4. 了解DICOM服务
    5. OsiriX提供的DICOM服务
    6. 其他DICOM服务
    7. DICOM文件格式
    8. DICOM结构化报告
    9. 符合DICOM
    10. DICOM与其他标准的互操作性
    11. 结论

    介绍

    这是我有关DICOM标准的系列文章的一部分,并快速概述了DICOM标准。

    DICOM是一种医疗保健标准,负责管理医学成像的几乎所有方面,例如图像传输,图像解释,打印管理,程序管理和离线存储,并且几乎用于与医疗保健相关的所有成像“模态”,例如磁共振,核医学,计算机断层扫描和超声检查。全世界几乎所有的临床成像工作流程都基于DICOM标准。如果您在医疗信息学行业工作或想要工作,那么学习此标准至关重要。我希望写本系列文章的目的是通过查看简短但有针对性的代码示例,帮助进入“ DICOM世界”的人们更快地学习标准的各个方面和部分。在本文中,我们将从较高的层次看待该标准的所有主要部分,本系列的文章中,我们将使用有助于将DICOM的理论与实际实现联系起来的代码示例,对这些方面的每个方面进行更详细的研究。

    带代码的电脑屏幕

    为了说明该标准中的许多核心概念,我决定使用一个免费可用的功能强大的工具“ OsiriX”,该工具具有许多开箱即用的DICOM功能。但是,请记住,该软件只能在Mac OS X操作系统上运行。因此,如果您正在运行其他操作系统,我深表歉意。但是,只需阅读此处的材料以及查看显示的屏幕截图,即可帮助您理解这些概念并将其应用于您选择使用的任何其他DICOM软件。另外,请记住,这不是编程教程,尽管很像我以前的HL7文章中采用的方法,

    什么是DICOM

    DICOM代表“医学数字成像和通信”,由美国国家电气制造商协会(NEMA)和美国放射学院(ACR)联合开发,以允许成像设备之间以及与其他设备之间的互操作性。该标准负责管理图像格式以及传输在许多与医疗保健相关的成像“方式”(例如磁共振,核医学,计算机断层扫描和超声)期间生成的医学图像信息所需的各种网络协议。自1983年以来,DICOM标准就以一种或多种形式存在,并且每年都在不断发展。

    医院系统内的图像传输

    我认为,解释该标准的最佳方法是首先描述在诊所,医院或大型卫生网络中经常发生的与影像相关的工作流程。稍后,我将以这种情况为基础来解释标准的“细节”。

    假设某位患者因胸痛入院。主治医师可以命令进行MRI扫描,并且当此请求记录在医院信息系统(HIS)上时,通常会将电子请求发送到位于成像中心的放射学信息系统(RIS)。该请求通常包括有关该请求的来源,订购者,患者的详细信息,所请求的成像方式的类型等信息。一旦完成预订,就将患者发送到成像中心进行扫描。扫描完成后,将从原始数据中创建一组符合DICOM要求的图像,并将其称为“研究”。一项研究本身可能由多个采集组成,具体取决于扫描配置,这些采集中的每一个都称为“系列”。

    扫描程序完成后,所有图像都将被存档以传输到PACS系统(图片存档和通信系统)。在将扫描的图像传输到PACS系统之前,可以检查其质量,如果不满意,检查技术人员可以再次下令进行扫描。然后可以将存档的图像从PACS系统中检索到工作站,以供放射科医生查看。放射科医生可以直接在屏幕上查看图像,也可以在胶片上打印这些图像。稍后,她可以在报告中添加有关其观察结果的其他注释。一旦她完成了此过程,更改将与PACS系统上的原始研究合并。电子消息也被发送回RIS,指示模态请求已经完成。

    “我们应该被教导不要等到灵感来开始做某件事。行动总能激发灵感。灵感很少产生作用。” 弗兰克·蒂博特

    在继续阅读我的文章之前,您可能需要暂停一下,观看Marc Kohli的精彩视频,该视频解释放射学的典型工作流程,包括DICOM标准(以及其他标准,例如HL7)如何适合其中。我觉得这段视频确实说明了DICOM如何与任何医院网络中更大的医疗保健工作流程集成。

    了解DICOM服务

    如果不使用DICOM(和HL7),则很难轻松实现前面部分所述的工作流中涉及的多种类型的硬件和软件之间的图像和图像相关信息的无缝流动。现在让我们深入研究细节,看看DICOM标准如何使这种类型的信息流发生。

    Osirix DICOM软件

    DICOM标准的本质是基于服务提供商(也称为“服务类别提供商”或“ SCP”),服务使用者(也称为“服务类别用户”或“ SCU”)和信息的概念提供者和消费者所作用的对象。例如,前面部分中描述的打印机是服务提供商的示例,被称为具有“ C-PRINT SCP”功能。请求打印活动的应用程序充当服务使用者,并具有“ C-PRINT SCU”功能。服务类及其作用于其上的信息对象模板的组合称为“服务对象对”类,也称为“ SOP”。SOP为与DICOM相关的合规性(或“合规性”)奠定了基础,并允许供应商披露其软件和硬件支持的与DICOM相关的功能。每个SOP类都有一个由DICOM委员会颁发的唯一标识号。SOP类的列表已经很长了,并且随着支持更多的方式而继续增长。

    DICOM标准的目标是在任何医疗保健信息网络中实现“即插即用”架构。因此,该标准规定,所有具有DICOM功能的设备都会在兼容DICOM的设备之间发生的初始“握手”期间以电子方式公开其功能。这种握手通常称为“协会建立”。根据支持的功能,此关联可以成功还是失败。如果关联成功,则将在握手期间协商的格式下,在服务的使用者和提供者之间交换SOP类的实例。先前描述的打印示例中的SOP实例可以携带诸如患者信息之类的信息,要打印图像的像素数据,以及需要与图像一起打印的所有注释。让我们进一步了解使用OsiriX的DICOM兼容设备提供的各种服务。

    OsiriX提供的DICOM服务

    OsiriX软件具有“ C-STORE SCP”功能,因此能够将传入的DICOM图像存储到本地数据库中。这使软件可以作为基本的PACS服务器运行。为了能够使用此功能,您将在“首选项”屏幕中配置设置,以使OsiriX能够作为DICOM侦听器运行。该软件具有许多功能,包括能够使用DICOM标准的“ WADO”规范通过HTTP协议接收图像(WADO表示“对DICOM对象的Web访问”)。它还通过基于SOAP的消息传递提供Web服务集成。OsiriX提供的另一项与存储相关的功能是“ C-STORE SCU”。此功能使我们能够将OCOM的DICOM信息发送到其他DICOM存储服务提供商,例如PACS系统。“本地数据库”屏幕(如下所示)显示了在OsiriX中如何组织患者的图像。图像始终存储在由患者,他们的研究以及研究中的图像(或“系列”)组成的层次结构中。

    Osirix查询检索

    通常,当将DICOM图像从查看工作站推送到PACS系统以在硬盘上或在备份介质(例如CD)上进行长期存档时,至关重要的是,存储设备必须提供一些确认,说明信息已成功接收并存储在发送方删除图像之前。使用存储承诺服务在DICOM中可以使用此功能,该服务通常通过结合使用其他服务(例如“ C-MOVE SCU”,“ C-MOVE SCP”,“ N-ACTION”和“ N-EVENT”)来实现。此功能由OsiriX提供。

    OsiriX提供的另一个DICOM功能是DICOM图像的查询/检索。这使用户可以搜索远程PACS系统,然后检索他们感兴趣的图像以在本地查看。查询功能指定为“ C-FIND SCU”和“ C-FIND SCP”,检索功能通过“ C-GET SCU”和“ C-GET SCP”以及使用“ C-MOVE SCU”指定”和“ C-MOVE SCP”操作。C-GET操作非常类似于大多数软件开发人员应该熟悉的HTTP协议中使用的HTTP GET请求,并且经常在从医院等医院环境进行通信以从运行中的服务器提取放射图像时使用在医院网络中。C-MOVE操作主要在医院网络内使用,既可以检索图像,也可以将图像发送到完全不同的目的地。请查看上面的屏幕截图,显示在OsiriX软件中如何实现某些查询/检索功能。

    Osirix打印

    DICOM打印服务使图像采集设备和查看工作站可以共享与DICOM兼容的打印机,类似于在信息网络中通常使用普通打印机的方式。DICOM打印可以使用标准校准(在DICOM图像本身中进行编码),以确保各种显示设备以及在其上可以看到图像的硬拷贝打印输出之间的一致性。设备的打印功能指定为“ C-PRINT SCU”或“ C-PRINT SCP”。有多种类型的DICOM打印机可用,它们的功能通过它们声称支持的SOP类来描述。基本支持始终包括灰度打印,彩色打印,具有查找表增强功能的灰度打印以及具有查找表增强功能的彩色打印。可选功能包括注释,图像覆盖和打印作业执行状态报告。OsiriX支持标准中指定的所有基本打印功能。

    “最小的善举比最大的意图有价值。” 〜Kahlil Gibran

    DICOM离线存储服务使用户可以在可移动存储介质(例如软盘,CD-ROM和光盘)上交换DICOM文件。基于成像环境,例如冠状动脉造影,一般诊断超声或胃肠道内窥镜检查,优选不同的存储机制。OsiriX提供了将DICOM图像刻录到CD-ROM的内置功能(请参见下面的屏幕截图)。但是,它还允许将DICOM图像导出为JPEG,TIFF和QuickTime电影格式,从而可以更轻松地进行传输。

    其他DICOM服务

    尽管OsiriX具有许多DICOM功能,但它不提供DICOM中指定的其他更高级的服务,例如“模态工作清单”服务或“模态执行过程步骤”服务(也称为“ MPPS”)。通常仅在需要实现与RIS或PACS系统交互时发生的复杂工作流方案时才需要这些服务。

    Osirix离线存储

    当您希望最大程度地减少手动键入的信息量时,模态工作列表服务非常有用。例如,它允许进行MRI的技术人员将所请求的过程中包含的信息自动传输到作为扫描一部分收集的图像上。这种方法不仅提高了信息传输的效率,而且还提高了患者安全性,因为减少了错误信息的可能性。

    MPPS服务用于在执行扫描的设备与RIS和/或PACS之间传达与正在执行的成像步骤有关的消息。基本上有两种类型的消息被使用。在过程步骤开始时会发送一个称为“ N-CREATE”的消息,而在过程步骤完成后会发送一个“ N-SET”消息。作为步骤完成的一部分获取的任何图像也将作为此消息的一部分进行传输。

    DICOM文件格式

    除了图像像素数据之外,DICOM文件还包含其他信息,例如患者身份信息,研究和图像采集的系列信息等。所有这些信息都以数据集的形式存储在DICOM文件中。这些数据集本质上是数据对象的集合,而它们又由名称/值表示形式的几个属性组成。有关图像的信息(包括患者信息,模态信息,图像的像素数据)存储在这些属性中,这些属性通过DICOM词典进行维护/管理。一个DICOM文件可以存储许多图像(也称为“帧”),以便以电影形式或“电影循环”的形式进行查看,因为它们在DICOM世界中经常被提及。属性内的图像像素数据可以根据存储和传输要求以压缩或未压缩格式存储。图像查看器应用程序可以读取图像数据并将其显示在高分辨率打印机上,从而可以对结果进行准确的诊断。下面的屏幕截图显示了OsiriX中如何显示DICOM图像的“元信息”。

    Osirix结构化报告

    DICOM结构化报告

    DICOM标准内的结构化报告(SR)支持在医疗设备之间交换诊断报告。这些报告以与任何其他DICOM对象相同的格式存储。为SR定义的特殊SOP类提供了一种简便的方法来基于研究中的图像存储基本诊断信息,例如可以无缝存储过程日志,观察值,测量值,波形,并允许我们链接这些报告到任何对应的图像。根据报告中包含的编码信息的复杂性,有两种类型:基本文本SR;和增强型SR。

    符合DICOM

    尽管不是强制性的,但声称其产品符合DICOM标准的供应商通常会提供一份一致性声明,说明其设备或软件如何支持该标准。一致性声明中的信息包括如何处理关联(例如,是否能够启动关联以及并行并行的数量等),受支持的SOP类以及其他信息(例如表示上下文)和通讯资料。客户可以使用这些文档中包含的信息来确定供应商的产品是否可以与他们网络中其他兼容DICOM的设备或软件成功通信。如果您对如何编写/构造这些文件感到好奇,请在此处查看OsiriX的一致性声明示例。

    DICOM与其他标准的互操作性

    与仅使用DICOM标准相比,在医疗保健信息网络中实施有效的工作流程需要更多的组件。例如,使用HL7处理医疗系统的许多复杂交易。但是,如果要无缝集成DICOM和HL7,则仍然需要解决一些差距。为此,制定了IHE(整合医疗保健企业)计划,以帮助改善DICOM,HL7和许多其他现有医疗保健标准机构之间的合作。以后,我将在单独的教程中介绍IHE。有关HL7标准的教程,请参阅我的HL7文章系列

    结论

    我希望您发现此入门教程对深入了解DICOM标准很有用。Internet上还有许多其他资源,还有许多不错的书,它们对我在本教程的更高层次上介绍的领域进行了更深入的研究。我的建议是,如果可能的话,还请您进行培训,以帮助您提高对使用此标准的熟悉度和信心。如果您对此处提供的信息有任何疑问或批评,请随时给我发送电子邮件。请注意,由于工作和其他承诺,我可能不会立即与您联系。

     

    Introduction to the DICOM Standard using OsiriX

    CONTENTS

    1. Introduction
    2. What is DICOM
    3. Image Transmission within Hospital Systems
    4. Understanding DICOM Services
    5. DICOM Services Offered by OsiriX
    6. Other DICOM Services
    7. DICOM File Format
    8. DICOM Structured Reporting
    9. Conformance in DICOM
    10. DICOM Interoperability with Other Standards
    11. Conclusion

    Introduction

    This is part of my series of articles on the DICOM standard, and provides a quick overivew of the DICOM standard.

    DICOM is a healthcare standard responsible for governing nearly all aspects of medical imaging such as image transmission, image interpretation, print management, procedure management and off-line storage, and is used in nearly all healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. Nearly all clinical imaging workflows around the world are based on the DICOM standard. Learning this standard is vital if you work or want to work in the healthcare informatics industry. My hope in writing this series is to help a person entering the "DICOM world" to be able to learn the various aspects and parts of the standard faster by looking at short but focused code examples. In this article, we will look at at all major parts of the standard from a very high level, and in the subsequent articles of this series, we will look at each of those aspects in more detail using code examples that help tie the theory of DICOM to practical implementation.

    Computer Screen with Code

    To illustrate many of the core concepts within this standard, I decided to use a freely available and yet powerful tool called “OsiriX” which has many DICOM capabilities right out of the box. However, please keep in mind that this software runs on the Mac OS X operating system only. So, my apologies if you are running a different operating system. However, simply reading the material here as well as viewing the screenshots shown should help you take in the concepts and apply it to any other DICOM software that you choose to utilize. Also, please keep in mind that this is not a programming tutorial, although much like the approach that I took with my earlier HL7 articles, I plan to use this tutorial as a foundation for some of my DICOM programming tutorials in which I will illustrate how to write custom software applications using the DICOM standard.

    What is DICOM

    DICOM stands for “Digital Imaging and Communications in Medicine” and was developed jointly by the National Electrical Manufacturers Association (NEMA) as well as the American College of Radiology (ACR) to permit interoperability between imaging equipment as well as with other devices. This standard is responsible for governing both the image format as well as the various network protocols required for transmission of medical image information generated during the many healthcare-related imaging “modalities” such as magnetic resonance, nuclear medicine, computed tomography and ultrasound. The DICOM standard has existed in one form or the other since 1983 and continues to evolve every year.

    Image Transmission within Hospital Systems

    I feel that the best way to explain the standard is by first describing an imaging-related workflow that occurs very frequently in clinics, hospitals, or large health networks. Later, I will use this scenario as the basis for explaining the “nuts and bolts” of the standard.

    Let us say a patient was admitted to a hospital with some chest pains. The attending physician may order an MRI scan, and when this request is recorded on the Hospital Information System (HIS), an electronic request is often transmitted to the Radiology Information System (RIS) located in the imaging centre. This request typically comprises of information about where the request came from, who ordered it, the details of the patient, the type of imaging modality requested, etc. Once the booking is done, the patient then is sent for the scan to the imaging centre. After a scan has been completed, a set of DICOM-compliant images are created from the raw data and is referred to as a “Study”. A study may itself consist of several acquisitions depending on the scan configurations, and each of these acquisitions is referred to as a “Series”. Each series will consist of several images, and each of these images are individually referred to as a “DICOM Information Object”.

    After the scanning procedure has been completed, all the images are transmitted for archival to a PACS system (Picture Archival and Communication System). The scanned images may be reviewed for quality before being transmitted to a PACS system, and the reviewing technologist may order a scan again if they are not satisfactory. The archived images can then be retrieved from the PACS system to a workstation for viewing by a radiologist. The radiologist may either view the images directly on the screen or print these images on film. Later, she may add additional comments about her observations on a report. Once she completes this process, the changes are merged with the original study on the PACS system. An electronic message is also transmitted back to the RIS indicating that the modality request has been completed. Information may also be transmitted back to the originating HIS along with some of the key images to assist in intervention by a cardiologist if necessary.

    “We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.” Frank Tibolt

    Before you continue reading my article any further, you may want to take a pause and watch this excellent video by Marc Kohli explaining the typical workflow in radiology including how the DICOM standard (along with other standards such as HL7) fits within it. I feel that this video really explains the big picture of how DICOM integrates into the larger healthcare workflow within any hospital network.

    Understanding DICOM Services

    The seamless flow of images and image-related information between the many types of hardware and software involved in the workflow described in the earlier section could not be easily achieved without the use of DICOM (and HL7). Let us now dive a little bit into the details to see how the DICOM standard enables this type of information flow to occur.

    Osirix DICOM Software

    At its very core, DICOM standard is based on the concept of service providers (also referred to as “Service Class Providers” or “SCP”), service consumers (also referred to as “Service Class Users” or “SCU”) and information objects that are acted upon by the providers and consumers. For example, the printer described in the earlier section is an example of a service provider and is referred to as having a “C-PRINT SCP” capability. The application requesting the print activity is acting as a service consumer and has “C-PRINT SCU” capability. The combination of a service class along with the information object template that it acts upon is referred to as “Service-Object Pair” class, also referred to as “SOP”. SOPs form the foundation for DICOM-related compliance (or “conformance”) and allow vendors to disclose what DICOM-related capabilities their software and hardware support. Each SOP class has an unique identification number issued by the DICOM committee. The list of SOP classes is very long already and continues to grow as more modalities are supported.

    The goal of the DICOM standard is to enable a “plug-n-play” architecture within any healthcare information network. The standard therefore stipulates that all DICOM-capable devices electronically disclose their capabilities during an initial “handshake” that occurs that occurs between DICOM-compliant devices. This handshaking is often referred to as an “Association Establishment”. Depending on the capabilities supported, this association can be successful or fail. If the association is successful, instances of the SOP classes are exchanged between the consumers and providers of a service in the format negotiated during the handshake. The SOP instance in the print example described previously may carry information such as the patient information, pixel data of the images to be printed as well as any annotations that are required to be printed along with the images. Let us look at the various services offered by DICOM-compliant devices a little further using OsiriX.

    DICOM Services Offered by OsiriX

    OsiriX software has a “C-STORE SCP” capability and is therefore capable of storing incoming DICOM images into a local database. This allows the software to operate as a rudimentary PACS server. In order to be able to use this feature, you will have configured the settings in the “Preferences” screen to enable OsiriX to run as a DICOM listener. This software has many capabilities including being able to receive images through the HTTP protocol using the “WADO” specification of the DICOM standard (WADO stands for “Web Access to DICOM Objects”). It also offers web service integration through SOAP-based messaging. Another storage-related capability that OsiriX offers is the “C-STORE SCU”. This capability permits us to send DICOM information from OsiriX to other DICOM storage service providers such as PACS systems. The “Local Database” screen (shown below) shows how the images for a patient are organized within OsiriX. The images are always stored in a hierarchy consisting of patients, their studies, and the images in the study (or “series”).

    Osirix Query Retreive

    Often, when DICOM images are pushed from a viewing workstation to a PACS system for long-term archival on hard disk, or on backup media such as CD, it is essential that the storage device provides some acknowledgement that information has been successfully received and stored before the images are deleted at the sender. This feature is possible within DICOM using the Storage Commitment Service which is typically achieved using a combination of other services such as “C-MOVE SCU”, “C-MOVE SCP”, “N-ACTION” and “N-EVENT”. This capability is provided by OsiriX.

    Another DICOM capability that OsiriX offers is the query/retrieval of DICOM images. This enables users to search a remote PACS system, and later retrieve images that are of interest to them for viewing locally. The querying capabilities are specified as “C-FIND SCU” and “C-FIND SCP”, and the retrieval capabilities are specified through “C-GET SCU” and “C-GET SCP” as well as by using “C-MOVE SCU” and “C-MOVE SCP” operations. The C-GET operation works very much like a HTTP GET request used in the HTTP protocol that most software developers should be familiar with, and is often used when communicating from outside a hosptial setting such as a clinic to pull radiological images from a server running within a hospital network. The C-MOVE operation is used mostly within a hospital network to both retrieve images and also send images to a completely different destination. Please see screenshot above showing how some of query/retrieval features are implemented within the OsiriX software.

    Osirix Print

    DICOM printing services enable image acquisition devices as well as viewing workstations to share DICOM-compliant printers similar to how normal printers are often utilized within an information network. DICOM printing enables the use of standard calibration (encoded within the DICOM images themselves) to ensure that there is consistency between various display devices as well as hard copy printouts on which the images are seen. The print capabilities of devices are specified either as “C-PRINT SCU” or “C-PRINT SCP”. There are many types of DICOM printers available, and their capabilities are described through the SOP classes they claim to support. Basic support always includes grayscale printing, colour printing, grayscale printing with lookup table enhancement, and colour printing with lookup table enhancement. Optional features include annotation, image overlays, and print job execution status reporting. OsiriX supports all the basic printing capabilities specified in the standard.

    “The smallest act of kindness is worth more than the greatest intention.” ~ Kahlil Gibran

    DICOM off-line storage services enable users to exchange DICOM files on removable storage media such as diskettes, CD-ROMs, and optical disks. Different storage mechanisms are preferred based on the imaging context such as coronary angiography, general diagnostic ultrasonography, or gastrointestinal endoscopy. OsiriX provides a built-in feature to burn DICOM images onto CD-ROMs (see screenshot below). However, it also permits the ability to export the DICOM images to JPEG, TIFF and QuickTime movie formats which can transferred more easily.

    Other DICOM Services

    Although OsiriX has many DICOM capabilities, it does not offer other more advanced services specified within the DICOM such as the “Modality Worklist” service or the “Modality Performed Procedure Step” service (also known as “MPPS”). These services are typically only required when needing to implement complex workflow scenarios that occur when interacting with a RIS or PACS system.

    Osirix Offline Storage

    The modality worklist service is useful when you want to minimize the amount of information that is keyed in manually. For example, it allows the technologist conducting an MRI to automatically transfer the information contained within the requested procedure onto the images collected as part of the scan. This approach not only increases the efficiency of information transfer, but also increases the level of patient safety as there is a reduced chance for incorrect patient information.

    The MPPS service is used to communicate messages pertaining to the imaging steps being performed between the device performing a scan and the RIS and/or PACS. There are fundamentally two types of messages that are utilized. There is something called a “N-CREATE” message which is sent at the start of a procedure step, as well as a “N-SET” message is which is transmitted after a procedure step has been completed. Any images acquired as part of the step completion are also transferred as part of this message.

    DICOM File Format

    In addition to the image pixel data, the DICOM file contains other information such as patient identification information, study and series information of the image acquisition, etc. All this information is stored inside a DICOM file in the form of data sets. These data sets are essentially a collection of data objects, and these in return consist of several attributes in the form of name/value representations. Information about the image (including patient information, modality information, pixel data for the images) are stored in these attributes which are maintained/managed through a DICOM Dictionary. A single DICOM file can store many images (also known as “frames”) to enable for viewing in the form of a movie or as “cine loop” as they are often referred to in the DICOM world. Image pixel data inside the attributes may be stored in either compressed or uncompressed formats depending on the storage and transmission requirements. Image viewer applications can read and display the image data onto high resolution printers permitting accurate diagnosis of the results. The screenshot below shows how the “meta information” of a DICOM image is displayed within OsiriX.

    Osirix Structured Reporting

    DICOM Structured Reporting

    Structured Reports (SR) within DICOM standard enables the exchange of diagnostic reporting between medical devices. These reports are stored in the same format as any other DICOM object. The special SOP classes defined for SR permit an easy way to store the essential diagnostic information based on the images in a study, such as procedure logs, observations, measurements, waveforms can be stored in a seamless manner, and allow us to link these reports to any corresponding images. Based on the complexity of the encoded information contained in the report, there are two types: a Basic Text SR; and an Enhanced SR.

    Conformance in DICOM

    Although not mandatory, vendors who claim that their products adhere to the DICOM standard typically provide a Conformance Statement describing how their device or software supports the standard. The information in the conformance statement include how the associations are handled (for example, whether it is capable of initiating associations, and how many in parallel, etc.), the SOP classes that are supported, as well as other information such as presentation contexts and communication profiles. Customers can use the information contained in these documents to decide whether the vendor product can successfully communicate with other DICOM-compliant devices or software within their network. If you are curious how these are written/structured, see an example of a conformance statement for OsiriX here.

    DICOM Interoperability with Other Standards

    There are many more components required to implement an effective workflow within an healthcare information network than is possible using the DICOM standard alone. For example, many complex transactions with a healthcare system are handled using HL7. However, if DICOM and HL7 are to seamlessly integrate, some gaps are still required to be addressed. For this purpose, IHE (Integrating the Healthcare Enterprise) initiative was developed to help improve the cooperation between DICOM, HL7 and many other existing healthcare standards agencies. I will cover IHE in a separate tutorial in the future. For a tutorial on the HL7 standard, see my HL7 article series.

    Conclusion

    I hope you found this introductory tutorial useful for gaining a high-level understanding of the DICOM standard. There are many additional resources on the Internet as well as many good books that delve much deeper into the areas that I covered at a high level in this tutorial. My recommendation is also that you also take hands on training if possible, to help boost your familiarity and confidence in using this standard. If you have any questions or criticisms on the information presented here, please feel free to send me an email. Please note that I may not get back to you right away due to work and other commitments.

    展开全文
  • 中文版的DICOM标准

    2010-03-18 16:11:06
    中文版的DICOM标准,中文版的DICOM标准,中文版的DICOM标准,中文版的DICOM标准,中文版的DICOM标,
  • DICOM标准 英文原版

    2012-03-01 21:48:54
    英文原版的DICOM标准,可以结合中文版来看
  • DICOM标准及应用

    2019-07-27 05:18:52
    第一讲 DICOM标准概述 一 什么是DICOM?  DICOM是Digital Imaging and COmmunication of Medicine的缩写,是美国放射学会(American College of Radiology,ACR)和美国电器制造商协会(National Electrical ...
  • DICOM:DICOM标准学习路线图(初稿)
  • DICOM标准相关资料

    2016-08-02 15:36:00
    由于需要阅读影像,对DICOM需要先熟悉起来。...DICOM标准:http://dicom.nema.org/standard.html 中文 DICOM 标准4.0:http://www.docin.com/p-56572201.html&dpage=1&key=DIC%E6%80%8E%E4%B9%88%E6%B2%B...
  • DICOM:开源书籍之『DICOM标准中文版』启动计划

    万次阅读 热门讨论 2015-06-14 01:18:37
    背景:开源书籍之【DICOM标准中文版】启动计划。如我博客格言“只要踏出一步,路就在前方”所言,路总是需要一步一步走的,事情总是需要一件一件做的。因此近期开始着手启动“DICOM中文标准”开源书籍项目,由于...
  • DICOM 标准 2009版

    2010-03-10 12:36:27
    最新的DICOM标准2009版,注意:第二部分一致性声明的模板有较大变化。同时请注意第三部分IOD的变化与增加,文件过大,分三部分上传。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 840
精华内容 336
关键字:

dicom标准