第一章 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 |
|
48 |
|
35 |
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）。协商消息传输的协议机制，面向对象的信息对象（即数据集）规范以及服务类。
当然，所有这些将昌盛一个巨大而难以阅读的标准。不过一旦掌握起其本概念则标准本身不过提供了一个详细参考。从用户到设备购买者的观点来看，重要的是能够阅读到或匹配几个供应商的一致性陈述，看看两个设备是否能够建立会话。
显然，仅仅是能够进行沟通和传递信息是远远不够的，这只不过是有了建立整个实用系统的有用工具，固为一个工作站能够从ＭＲＩ扫描器拿下图象并不意味着它知道何时去拿？何时有了图象？该图象属于哪个病人？然后保存于何处？更不用提在执行这一项工作时通知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,其中１赛表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分布式处理
一个简单的分布式模型足以解释DICOM标准中使用的机制和术语：
|
Process1 |
|
Process2 |
|
信息 |
|
系统Ａ |
|
系统Ｂ |
|
分布式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
１.２.３属性（是信息实体的组成部分，也可以本身就是信息实体）
属性是基本的信息实体，必须详细描述。对于属性，DICOM标准定义了如下特性：
位于属性名（人类可读）
唯一属性标记（信息系统可读）
属性描述（语文上的）
值表示（句法上的）
值复合度（Value Multiplicity）
类型分类：1，1C，２，２C或３(用法依赖于SOP类的内容，服务类角色*)。
类型分类指定了与SOP类和SCU或SCP角色有关的属性的使用。针对具体情况，整个属性被强迫取值（类型１）或被迫带（forced with）或不带一个值（类型２？）或可选（类型３）
在一个IOD的内部，分组或单一属性依IOD的使用情况而定。例如：使用对比度的检查可以将信息存储在Contrast/Bolus 模块中。因此，该模块的属性是否可用就与“对比”的使用有关。如果使用了（对比度），则该属性的类型分类必被服从（定义为 type1c及type2c）。
１.２.４ 服从元素（Service element）
“服从元素”是允许在某些SOP类的“信息对象”上进行的操作。属于某SOP的服务元素组称为“服务组”。
一个SOP类的服务组选自于一个DICOM服务元素的固定列表。某些服务元素期望用于一个复用IOD，其他服务元素则用于正规IODs，第三类的服务元素期望与存储媒体相关，以文件方式处理复合及正规SOP类的实例。
与使用复合IODs（如：传输图像）时，服务类所描述的内容是非常有限的。这种“服务元素”具有复杂含义，如：STORE,FIND，MOVE等。当使用组合服务类时，系列“服务元素”的个体之间可认为存在关联。即便其中真有一个关系存在，也被认为是在服务类的范围之外，应使用服务类在过程中定义。
相反，使用正规IODs的服务类有广泛的内容，如管理函数等。它们使用原始元素进行简单信息的处理，如：GET，SET，ACTION等。该服务类定义了系列原始法求之间的关系。使用“正规服务类”，合作双方会跟踪两边的进程，并使用“服务元素”来控制它们。
整个SOP类使用一到多个来自于复合组（Ｃ－XXXX）或正规组（Ｎ－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 Ｍessage Protocol(DIMSE)）.
ACSE是标准的OSI协议。
转播
