【转帖】dicom协议的简单解释

DICOM 简介

数字影像传输标准协议的初衷，是为了在不同厂商生产的数字影像设备之间实现影像及其附属信息的调用。这个标准的最初版本是所谓ACR（美国放射学会）-NEMA（全国电器设备制造商协会）标准，这个标准定义了点对点的连接协议。但是计算机网络技术的日新月异和PACS（影像传输及归档系统）的发展，很快就让这个协议显得捉襟见肘。其结果是以后的工作目标变成了对ACR-NEMA标准的升级，以使此标准能够支持复杂网络系统的信息处理需要。DICOM（医用数字影像和传输）标准应运而生。目前这个标准在数字影像系统的采购和评介过程中，已经得到广泛的应用。

DICOM标准有很强的适应性。在设计初期，就充分考虑到了DICOM标准对放射以外的影像支持（比如：病理、内窥镜和牙科影像）。医疗影像设备的制造商往往都是大型跨国企业，他们的对DICOM标准的关注，对此标准的推广起到推波助澜的作用。欧洲标准化组织（the Comitâ Europâen de Normalisation）在制定MEDICOM标准时完全基于并且兼容了DICOM标准。在日本，放射设备及医疗信息系统行业协会发展中心已经采用了DICOM标准中可擦写媒介影像交换标准部分，并且考虑将DIOCM标准纳入其未来的医疗影像处理标准。目前，DICOM标准已经在全球范围内得到不同领域组织的广泛认同。

在医疗影像通讯领域DICOM标准已经成为主导标准。然而，尽管DICOM标准在厂商那里唾手可得、应用广泛，并且在迅速扩展进入包括非放射影像在内的新领域，仍然有很多放射专家仍然对DICOM认识不足。这种情况出现的部分原因是DICOM的“学习曲线过于陡峭”，现有的DICOM介绍材料不是写给工程人员的对于放射专家来说太过技术性，就是写给高层管理人员对于放射专家来说太肤浅了。
为什么我们要对这样一个看上去很简单的东西大费周章呢？答案是，事情并不想它看上去那么简单。通常放射专家都对胶片影像了如指掌，胶片影像在任何有光源的地方都可以观看。当我们把传统胶片影像转化为数字影像的时候需要面对一系列的问题，传输、显示、存储等等，这时候DICOM的出现就很必要了。在胶片时代，曝光、处理流程和读片工作中的细微变化对工作影响不大。而在数字影像时代，几个字节的差异就足以中断影像在系统之间的传送。

DICOM标准由一组文档组成，现今的版本就包括了13个发行部分。每一个DICOM文档通过标题和标准编码来识别，看上去的样子就像这样“PS 3.X-YYYY”，其中‘X”就是常说的标号，“YYYY”是发行的年份。举例来说，DICOM 标准第二部分的标题是“顺应性”文件标号是PS3.2-1996. 在正式场合，年份经常被省略。

DICOM标准的核心就是设置了一套统一的易于理解的数字影像通讯规则。在本文中，“通讯”是指系统中信息的交换。这个动作听上去很简单实际上，通讯就是我们日常生活中的一部分。然而，我们之所以能够良好的沟通是因为我们遵循了一套良好的规则。这套规则是我们在孩提时代就掌握了的。

电子通讯通常被划分为不同的层次，每一个层面上完成相应的功能。这种将通讯标准划分成不同层面的模型实际上是一个国际通讯标准的一部分，此标准就是ISO-SOI（国际标准组织开发系统互联）参考模型。这个模型可以类比为一个生产加工厂的结构。在这个模型的最高层面是用户应用程序的界面（比如在一个计算机终端上用户可以通过应用程序跨越网络访问数据）。这个层面相当于工厂的决策者他们决定工厂生产什么样的产品，运输什么样的货物。在模型的最低层面是物理层，这个层面为电子通讯提供物理介质( 比如：线缆)。这个层面相当于运输部门的货车。模型中的“高层”和“低层”并不是表示不同层面的重要程度，实际上高低的区别只是因为不同层面象一个堆栈，物理层在最下面，应用层在最上面。
在最高层和最低层之间，还有其他层面负责解决类似下列问题：用什么样的字符集来显示信息；用什么样的规则在物理层上建立连接；如何处理通讯过程中出现的错误等等。这些中间层面类似于我们假象工厂中不同的职能部门，每个都承担着特定的功能（比如：零件选择、制造装配、质量控制、规划运输路线等等）。在电子通讯模型和假象工厂中发生着同样的情况，每个层面（部门）从上一个层面（部门）获得信息，按照预定功能工作，将结果输出到下一个层面（下游部门）。

任何两个层面之间的交换都是无往不复的，因为所有通讯（正如同货物在不同公司之间的交流）都是双向的。在通讯术语中，信息在不同层面之间的流动被称之为层面提供的服务。然而，通讯意味着信息的交换，因此，还需要对方设备上有相对应的层面并且有物理媒介的连接。

我们的假想工厂加工并且运输自己的产品到另外一个公司，在那里经过组装产生新的产品。后面这个公司并不把产品原封不动地送回到去我们的假想公司（除非他们收到劣质产品要退货），不过他们要把货款发送回来。两个公司的物流部门需要为双方货运制定计划和规则（比如，不要在在长假期间发运保鲜货物）。同理，两个电器设备之间的的通讯也需要事先设定的规则或者协议，这样设备间相对应通讯层面才能连接。在电子通讯中，两个设备之间真正的数据流动只存在于物理层。然而，由于建立了机遇层面的通讯模型，每一个层面可以看作和对方设备的对应层面基于已有协议的直接通讯。在提供本层面的服务时，一个层面在所接收到的数据上加入一些信息然后发送给下游层面，下游层面接收到数据后也作相同的工作。在接收端，数据在向上穿行过各个层面的时候，每个层面提取从数据中出自己所需要的信息实现层面功能。在我们的假想公司中，质控部门会在产品的包装上贴合格标签再将其送到物流部门发货，而在收货的公司，产品接收后会开包验货，公司的质控部门会检查产品的合格标签并且确认产品没有任何运输损坏。只有产品通过检查后，才会被发送到别的部门接受进一步处理，最后财务部门会得到签收通知安排付款。在上述过程中的协议保证了发货人在产品上粘贴了正确的质控标签，而收货人可以根据发票检查产品数量和质量。如果过程中有人违反协议（比如发货人没有检查产品，或者忘记了贴标签），产品将被拒绝接收（收货人拒绝收货或者扣留货物直到问题解决）。

 
电子通讯的层面模型优势之一是当一个层面被新层面替代时其他层面不受到影响。举例来说：如果我们能找到一种物理媒介其速度是现有物理媒介的10倍，而且能够提供现有物理层提供的所有服务，我们就能立刻用新的物理层替换掉现有系统。在我们的假想公司中找到一个新的物流公司，新公司运货速度提高一倍，使用原有的集装箱，提供和现有公司一样的货物保险，那么我们可以不对其他部门作任何调整直接转换到新的物流公司。

不同层面的集合通常被称为栈或者协议栈。 DIOCM标准使用了层面通讯结构，实际上它并没有新建一个标准通讯栈而是直接使用了一个已有标准。可能有人会问，如果DICOM仅仅是使用了一个已有的通讯标准，它还有什么意义？为什么不直接用那些现有的通讯协议标准呢？

DICOM标准的意义和其功能的重要性，可以用个假想制造厂之间的交易来解释。

假想你是产品开发部的经理，现在需要一些零件来组装一个原形产品。于是你要求你的采购经理贝蒂从埃克美零件公司采购一些零件。贝蒂知道最快捷的办法就是打电话给埃克美公司订货，但同时她也知道你需要的零件非常抢手很可能已经销售一空。她拿起电话拨号，听到了熟悉的声音：“你好，这里是埃克美公司，请问你要找哪位？”贝蒂回答道：“请转销售部鲍勃罗伯茨。”

贝蒂刚才所做的工作非常类似于一台设备使用DICOM协议与另外一台设备通讯。当她拿起电话，她首先要求线路畅通。她听到的拨号音告诉她线路正常（如果没有拨号音则说明线路有问题）。同理，DICOM标准通过服务请求与网络上的另一台设备通讯。网络协议会首先探测网络是否可用。如果可用，DICOM协议就将发起一系列的活动，由此产生一个对另一台设备的连接。

拿起电话拨入需要接通的号码然后倾听回应，你就遵循了一系列通讯协议。首先，你遵从一定的规则拨号。如果你在办公室里拨号，可能还要先拨一个外线号码，如果对方不在本地，你还要拨对方的区号。然后你听到对方的振铃声，你知道对方没有占线，否则你的“协议”会引导你挂上电话等会儿再拨。

电话那一端的人所说的头两个字就很有意义。它告诉你两件重要的事情，首先对方所说的语言是你能够听懂的，其次你没有拨错号码。如果你听到的回答是“Moshi moshi, Fujiyama Denki desu”，你可能会马上挂断电话或者寻问对方是不是你要找的人。在这种情况下，会发生某种谈判，你会询问对方的电话号码，对方也会改说一种你能够听懂的语言。你假设对方能够听懂你说的话，而对方此时的反应决定了你下一个问题是什么。

DICOM协议也是用过发起某种谈判来建立连接的。这些谈判的主要内容是判断发起通讯的设备希望完成什么工作，以及接受设备能够完成什么工作。实际上，在DICOM协议中并不是设备本身完成这些谈判，而是其上运行的软件完成这一功能。DIOCM协议作为设备所支持的一个应用实体而存在，因为发起建立通讯是应用层（通讯栈中最上面的一个层面）的功能。

正如同你在电话中的谈判确定了通讯双方的基础能力（比如，使用的语言，对方的身份等），DIOCM中的连接建立也需要谈判来确定能力。应用实例的连接发起方将希望完成的工作编成一个列表发给对方。而接收方回应一个能够完成工作的列表。后续的交流是在两个列表的交集范围内进行的。举个例子，对于大于8位的数字像素值不同系统的处理就不同。有些计算机系统先发送最小有效字节，而有些系统则恰恰相反。如果两个系统用相反的表示方法传送数据，将导致错误数值出现。解决办法是设备能够发现这个问题，并且自动转换数值。DICOM协议对两种表示方法都支持，因而在信息交换前的谈判中有一个内容就是检测设备使用哪种方法。

另外一个影像设备之间的差异是对数值的表示方法。正如后面将要详述的，DICOM标准将所要发送的信息分解为一系列的数据元素。对于数据元素中所包含的数值，不同的应用程序会有不用的表示方法。DICOM对所支持的数据类型有着非常明确的定义，被称之为数值表现方法（VR）。其中包括了不等长混合字符串（像一个句子那样包含了开头、结尾和一连串顺序字符的文字串）、二进制数据、时间和日期数据以及人员姓名数据等等。在早期的ACR-NEMA标准中，这些VR被定义在所谓数据字典的一组标准中。如果你需要编写能够接收ACR-NEMA标准数据的应用程序，为了解释接收到的数据，你需要在数据字典查询ACR-NEMA元素标签才能了解数据元素中包含什么样的数据以及如何表示这些数据。DICOM标准需要扩充新的VR标准，未来的进一步扩展将增加数据字典的大小和复杂性。这也就是为什么在DICOM标准中同时支持ACR-NEMA方法和在数据元素中定义VR的新方法。 DICOM新定义的方法VR被定义在数据元素中，这样就不免了可能的混淆。对于软件设计人员来说，新方法减少了查阅数据字典的负担。在数据字典中定义VR的ACR-NEMA方法被称做内部VR；而DICOM所使用的在数据元素中定义VR的方法被称为外部VR。DICOM同时支持这两种方法，在通讯能力谈判时知道这一点很重要。

不论是VR方法还是字节顺序都是谈判信息的一部分，这些信息对成功建立信息交换至关重要。这些信息被称做传输语法，被定义在DICOM标准中。在建立连接的最早期阶段，使用何种传输语法进行信息交换是主要的谈判内容。

贝蒂呼叫埃克美公司销售部鲍勃的电话叫通了，双方寒暄几句后，鲍勃问贝蒂需要什么帮助。贝蒂说：“我需要15个零件”。鲍勃查了一下库存量回答说：“没错，我们正好有库存。”他接着说：“你知道，贝蒂，我们刚刚发布了马克二型零件，它的价格和马克一型一样速度提高了10% 。” 贝蒂问道：“新零件的界面怎么样？”“马克二型向前兼容马克一型，一旦清空马克一型的库存，我们将停止销售老产品。”贝蒂说：“听上去不错，这样我定15个马克二型的零件。”
这次交易简捷高效，主要是因为双方都对流程非常熟悉。假如贝蒂不认识销售部的鲍勃，她也会和销售部的其他人员要求相同的东西。

在上述场景中发生的事情，也发生在我们每天的日常生活中。这些交易如此频繁以至于除非出了什么茬子，否则很少有人会注意到它们的存在。在这个例子中不论是术语的定义还是工作的模式都是你、贝蒂和鲍勃所熟知的。现实生活中的沟通交流就是这个样子：我们基于人所共知的术语词汇和交流模式，一旦出现我们不熟悉的词汇或者交流模式，我们或者停下来明确它们的准确定义或者冒着出问题的风险继续交流下去。在这个例子中你（产品开发经理）要求购买一打零件，但是贝蒂（工程采购经理）定购了15个。因为贝蒂根据和你共事的历史经验数据判断，你总是忘记需要为安全性测试多定购几个零件。由于贝蒂对你所设计的原形设备有一定了解，所以在定购马克二型零件的时候会确认界面一致性。同时她知道提高零件的运行速度对你的设计有利，没有理由不定购新型零件。在这个场景中还存在更高层次的考量。有的工程是可能对使用新型号持保留意见，因为新型号通常不象久经使用的老型号那样稳定。然而，在这个场景中，你和贝蒂都对埃克美公司的质控体系有信心，知道新老产品在可靠性方面的差距可以忽略不计。

DICOM标准的最重要的意义就是尽可能明确地定义影像传输过程中涉及到的术语词汇和模型。并且保证接收此协议的用户能够方便使用这些定义。在比较高层面的通讯中（比如用户之间的通讯) ,对术语词汇的认同非常重要。不论实在放射科内部还是在放射科与其他学科交流中，明确地术语定义是保证沟通准确的前提。举例来说，对于“中间”和“侧面”的不准确理解，对于一个基于放射科报告作出诊断的外科医生来说会直接导致灾难性的后果。美国病理学协会已经在“系统化医疗术语”（SNOMED）标准上作了一些工作。这个也被称为受控词汇表的术语标准是基于解剖学和病理应用的。现在美国病理学会是DICOM标准委员会成员，并且正在致力于开发一个新的SNOMD章节用于影像描述。这个章节也被称作SNOMED-DICOM 词汇表。

DICOM同时也采用了其他一些适用标准的常规定义，比如说HL7 标准中的人员姓名格式。在这个格式定义中描述了姓名的表现格式以及称呼中前缀（比如：Mr. Fr.) 以及后缀（比如：Jr ) 的使用。格式定义中将姓名划分成几个部分，比如姓氏，名字，前缀等等，同时每个部分还可能是单个或者多个单元以应对一些不常见的姓名结构。

DIOCM标准的定义范围已经超越了术语词汇、测量值和环境变量等范围。它还定义了实体之间的关系模型。举例来说，一个患者和一个他所做过的检查之间的关系。这个例子中两者之间的关系可以用一个简单的字来描述“做过“。一个患者做过一个检查。同理类推，一个检查包含一系列影像。通过对临床活动的研究，流程也可以被定义为标准模型，在这个模型中定义了一组实体（比如：患者、检查、影像、报告）以及实体之间的关系。这个流程称为实体关系模型（E-R）。值得注意的是实体关系模型通常是一个图表，并不描述具体数据的流动方向。

在E-R模型中每一个实体都有其描述或者属性。例如，患者这个实体可以用下列属性来描述：姓名、年龄、性别、病案号、身高体重等等。所有这些属性可以用来标志或者描述一个特定的患者。DICOM标准不但定义了E-R模型，而且定义到了模型中每个实体的具体属性。实际上，DICOM中使用的属性就是ACR-NEMA标准中的数据元素。

定义E-R模型和模型中实体属性的过程式信息分析和建模工作的重要内容。这个分析和建模过程就是面向对象的分析。这项技术与现代计算机科学紧密相关，目前不使用面向对象分析方法的信息科学几乎是不可能的。建立E-R模型的部分目的就是得到一个面向对象的结果：实体就是对象，用属性来描述对象。

DICOM 的设计逻辑中部分地采用了面向对象方法。类似影像、报告
患者这样的实体在DICOM中被称为信息对象，因为它们的功能就在于承载信息。对于信息对象构成的定义在DICOM中被称为信息对象定义。信息对象定义的实质就是一个属性列表，这些属性分成必要属性，可选属性和条件属性（这种属性在某些条件下是必需的）。在描述信息对象细微的差别都有重大的意义。信息对象定义类似于一张包含很多空白字段的表格。象患者姓名、病案号这样的信息片断都可以当作一个属性。即使一个空白表格，也代表了一定的信息结构意义。当表格中的空白被填满，属性被赋予数值，对象就有了具体的实际意义它可能代表一个患者，一幅影像或者其他什么对象。这个填表的过程，也就是为属性分配数值的过程就是所谓的创建信息对象实例。

在ACR-NEMA标准的第一和第二版本中并没有使用面向对象的分析和设计思路。相反地，所有的属性（这里叫做数据元素）按照用途分组。举例来说，描述患者身份的元素分为一组，而描述检查影像获取方法的元素分为另外一组。因为这些版本没有依照E-R模型开发，所以这些分组也不符合面向对象定义的原则。举例来说，在ACR-NEMA第二版中关于CT检查影像的描述元素中也包含了患者姓名。按照E-R模型，患者姓名应当是患者对象的一个属性，而不属于影像对象。换句话说，即使CT影像需要使用患者姓名来做标志，患者姓名也不是CT影像的必要描述内容。这些复杂对象可以看作是由E-R模型中多个实体组成的集合。

产生这些问题的原因在于DICOM标准开发者（当时还是ACR 和NEMA）仍然希望保持新标准对老版本的兼容性。另外一个原因是，当时的计算机技术人员认为对象应当有具体的数值，而不是离经叛道地让对象包含一些属性。首先，从存储设备中调用复杂对象会更有效率，因为如果对象被拆分为更细小的元素，那么在调用的时候需要在存储中搜索更多更小的元素，耗费更多的时间。因此，DICOM标准继承了所谓的复杂数据及结构，称之为复合对象。遵从面向对象设计原则，DICOM标准E-R模型定义的新对象并不包含除子对象属性外的任何新属性。这些DICOM定义的新对象叫做规范化对象。影像对象（比如CT，超声和MRI的影像）都是复合对象，用于影像及其报告管理的对象是规范化对象。 

现在回到我们的假想公司，记得吗你是公司的产品开发经理，为建立准确有效的质量控制流程你需要对组装到产品中的每一个零件追踪。这样的话，不论是你自己的实验室还是你的客户，一旦发现产品有问题，你就可以追踪到产品中哪个部分的设计或者加工有缺陷。支持这个流程，首先需要你对产品中的零部件型号编号。但是仅仅这样还不足以让你能够定位出加工制造的缺陷源头。换句话说，型号编号可以在一个产品线中标志唯一零件，但是不能在多个产品批次中找到唯一零件。举例来说，贝蒂订购的零件型号编号是2011030-001。但是你所有生产的产品中都有这几个编号的零件。所以要定位到特定的某个零件你还需要一个唯一编码（UID）。如果你发现埃克美公司给每个出品零件都分配了序列号，你就可以使用这个编号来描述特定产品中的特定零件。只有一个产品可能安装了型号为2011030-001序列号为97-2003的零件，凡是有埃克美公司零件的售后服务就简单多了。

正如同某些工业品标志有唯一识别号码一样，包括影像、报告及其他一些由一台影像设备传输到另外一台设备的信息都需要唯一识别号码。DICOM定义了UID来起到这个作用。UID的格式遵从国际标准，当正确使用时，这个识别码不但在一个机构内是唯一的而且应当在全球范围内是唯一的。UID号码大多是由计算机软件生成的，其结果是号码看上去晦涩难懂。在DICOM标准中任何时候一个对象指向另外一个对象时都要使用UID。举例来说，我们前面提到的不同的传输语法就有不同的UID，这样当设备通讯时可以利用UID来指向某个特定的语法规则。作为国际标注组织的一部分，DICOM委员会负责申请并获得了一个特定的数字字段用来定义DICOM的UID。这个数字字段被称为组织根字段。DIOCM组织获得的字段是1.2.840.10008。在这个根字段上可以附加数字作为标志码。比如说，UID 1.2.840.10008.1.2.1 就表示了DICOM协议众某个特定的语法。组织根字段根据UID由厂商发放还是由用户发放而略有不同。在这些数字中间出现的符号看上去似乎把数字分成了几个有特定意义的字段，但实际上它们并没有什么意义。UID仅仅给特定对象一个唯一标识，并不附带关于被标识对象的任何信息。

DICOM标准中的信息对象是用来在不同的硬件设备之间传送影像及相关信息的。不过，仅有这些信息不足以保证操作流程的正常进行。当贝蒂给埃克美公司打电话之后，不仅是告诉对方自己需要什么，而且还引发了一系列的活动。贝蒂说她需要订购15个零件。下这个订单会引发下列动作：埃克美公司的仓库会完成分拣工作，并将货物发送给运输部门，运输部打包后装车发货。在此过程中，需要填写相应得纸质或者电子表格来跟踪流程，记录库存变化。从功能上来说，订单的信息交流引发了埃克美公司不同部门提供的不同服务。同样，当这批零件到达你的公司时，也会引发公司中不同部门的不同服务。因此，在信息交换之外（例如说：“我将预定15个零件”“我们已经用型号二代替了型号一”），还需要一些与信息相关的服务来最终满足公司的要求。

医疗影像信息的通讯也有类似的情况。在与设备通讯的同时，你还需要设备能够提供一些服务（比如，显示器能够显示影像，打印机能够打印，归档设备能够存储）。我们前面提到的谈判过程，就是设备声明其能够提供服务类型的方法。

DICOM为其所定义的信息对象制定了标准化的服务类型。这些服务是基于一组数据元素服务而建立的。因为DICOM的信息对象包括复合对象和规范化对象两种，相应的服务也分为复合服务和规范化服务。所有服务都是通过一组数据元素服务来实现的。在我们的例子中，填写订单这个服务实际上就是由一组简单的动作组成的。首先是接线员接听电话，然后转接到销售部门，销售人员根据电话提示书写订单后将复印件发送到付款部门。这样一组小的活动，组成了填写订单这个服务。同理，DIOCM也将其复杂的服务分解成一些小的服务元素，称之为DICOM消息服务元素，简称DIMSE。对于复合信息对象定义了五种DIMSE（叫做DIMSE-C），对于规范化信息对象定义了六种DIMSE（叫做DIMSE-N）。所有这些DIMSE可以分为两类：操作（比如“存储”可以把信息写入存储设备）；通知（比如“事件报告”用来通知设备有事情发生）。这些简单的DIMSE构成了影像归档和通讯系统中所需的服务。这些服务包括“归档”（用来将信息对象写入归档设备）和“查询-调阅”（用来在存储设备上提供信息查询和调用功能）。某些服务要求DIMSE成对出现才能正常工作（比如“发送存储”和“接受存储”，另一些服务则需要多个DIMSE才能实现（比如：查询-调阅）。在“查询-调阅“服务中使用了“find”“get” 和 “ move” 三个DIMSE。

由于DICOM的面向对象特性，服务通常被称为服务类。这样称呼的部分原因是对于某个制定的服务，可以被多个（或者多类）信息对象所使用。了解一台设备到底是服务的提供这还是服务的使用者非常重要。举例来说：工作站中的文件系统可以提供影像存储服务，而超声机利用工作站的存储服务来存储和最终显示影像。DICOM标准用服务角色来描述这个差别。设备可以是服务的提供方，或者是服务的使用方，也可以两者都是。毫无疑问，如果一个系统中的各个设备能够正常通讯，明确各自的角色就是前提。这一点需要在我们前面提到的谈判过程中明确，换句话说，在功能列表中不但要明确能够支持什么样的服务类，而且要明确对应服务类的角色。

信息对象和服务类是DICOM标准中两个最基础的部件。在首先理解了这些部件之后才有可能理解DIOCM的功能和用途。信息对象定义了医疗影像的核心内容，而服务类定义了这些内容能做什么事情。

服务类和信息对象结合成为DICOM标准中的基本单元，这个单元叫做服务对象对（service-object pair) 简称 SOP。既然DICOM是个面向对象的标准，SOP实际上被称为SOP类。SOP类是DICOM的最基础单元，DICOM中任何功能的实现都是基于对SOP类的使用。

服务和信息对象的结合简单直接。举例来说，DICOM定义了一系列的存储SOP类（比如，CT影像存储 SOP类，MR 影像存储SOP类）。CT影像存储SOP类是由CT信息对象定义和存储服务类组成和，其他存储SOP类也是用类似的方法组成的。因为SOP类是一种描述DICOM功能的方法，所以它也有自己的UID。而且一旦信息对象的属性被赋值，服务类的变量被确定，SOP被实例化时它就有了自己的UID。

在DICOM通讯过程中，通过DICOM消息传递，SOP实例可以被交换。DICOM消息可以传输SOP类的版本，消息中包含特定服务的提供方或者使用方命令，同时还包括创建相应信息对象的数据集。

对于任何标准来说顺应性的确定都是头等大事。在许多涉及好公众安全和健康的领域内，对标准的顺应性是法律强制的。而其他一些标准，DIOCM也在此列，仅仅是自愿的。DICOM标准委员会并没有任何强制性权威。不过即便如此，DICOM标准中专门有一个章节是关于顺应性问题的。任何人在宣称其设备和软件顺应DICOM标准的时候，都必须提供顺应性说明文件，在这个文件详细叙述了其设备或者软件如何符合标准。关于DICOM标准的一个常见问题是：既然这是个标准为什么还需要顺应性说明文件？简单地公布符合标准不就可以了吗？象前面曾经讲过的那样，DICOM标准支持许多不同的影像格式，传输语法，服务角色等等。为支持多样的医疗影像应用程序，DICOM标准必须保持其柔性，但同时带来的问题就是对于某一个特殊的运用必须了解其具体处理的细节。而顺应性说明文件就是来做这个工作的。

让我们用一个使用实例来总结前面的理论。假设现在我们要把一个CT检查影像从CT设备上发送到一个工作站，来看看在DICOM中如果如何实现这个操作。你或者操作设备的放射科技师需要设置CT设备上的软件来准备选择特定的检查来发送。设备会要求你明确具体要哪台工作站接收图像。这个操作实在医疗影像应用层完成的，基本不涉及到DICOM。但是，设备控制台需要以DICOM格式保存其影像，也就是说控制台对设备产生的影像生成了一个DIOCM CT信息对象。生成信息对象的过程就是一连串的赋值过程，有一些值需要在控制台输入（比如：患者姓名，医嘱编号），还有一些值是设备产生的（比如：检查日期，时间，医院名称，设备名称等等）。当检查发送之前，还需要知道工作站的具体名称的网络地址。

工作站的CT设备之间的物理连接问题通过通讯协议（通常是TCP/IP协议）来处理。当选择发送功能时， CT控制台的软件开始组装一系列SOP实例，具体说就是CT存储SOP实例。在这个例子中，每发送一幅图像就要创建一个实例。一旦的得到工作站的位置信息，DICOM软件就开始建立网络连接，开始通讯过程。网络通讯协议首先建立通讯通道，以保证后续操作的进行。在建立连接的过程中，CT设备首先声明自己的通讯语法，告诉工作站：这是一台以服务类用户身份支持CT存储服务类的设备，要求对方的应用程序以服务类提供者身份支持CE存储服务类。CT设备同时还声明自己默认支持的VR类型。工作站发送的回应包括：声明自己即可以以服务提供者身份也可以以服务使用者身份支持CT影像服务类。同时工作站还声明自的通讯语法与CT设备的默认语法一致。这样，一个关于建立连接和服务能力确认的通知就发回了对应的设备端。

转载：http://blog.csdn.net/jackmacro/archive/2010/02/27/5332641.aspx