<转载>医学图像存储与传输系统(PACS)
第十一章 医学图像存储与传输系统(PACS)
第一节 绪论
随着现代医学科技的迅速发展，计算机信息技术已越来越广泛地渗入到医学领域。在影像医学方面，突出表现为越来越多的成像方式在向数字化技术转化，数字化放射学、数字化影像科室乃至数字化医院已成为医疗卫生信息化的发展方向。
图像存储与传输系统(Picture Archiving and Communication System, PACS)是专门为医学图像管理而设计的包括图像存储、检索、传输、显示、处理和打印的硬件和软件系统。其目标是为了有效地管理和利用医学图像资源。
PACS的建立对医学图像的管理和疾病诊断具有重要意义。它实现了无胶片的电子化医学图像的管理，解决了迅速增加的医学影像的存储、传送、检索和使用问题。采用大容量磁盘和光盘存储技术，克服了胶片存档时间长、存储空间大的问题；实现了高速检索，避免了胶片丢失；可以实现同一病人相关医学图像的整理归档，简化了数据管理；充分利用多模式显示、图像增强和计算机辅助诊断等技术，提高了图像诊断能力；电子通信网络支持多用户同时处理，利用计算机对图像进行处理提高了诊断能力，并可接人远程医疗系统实现远程会诊；分布式医学图像数据库便于实现医学数据共享，从而提高了医院的工作效率和诊断水平。
一、 PACS的产生和发展
PACS的概念提出于80年代初。1982年1月国际光学工程协会(SPIE)在美国主办的第一届国际PACS研讨会正式提出了PACS这一术语。建立PACS的想法主要是由两个因素引起的：一是数字化影像设备，如CT设备等的产生使得医学影像能够直接从检查设备中获取；另一个是计算机技术的发展，使得大容量数字信息的存储、通讯和显示都能够实现。在80年代初期，欧洲、美国等发达国家基于大型计算机的医院管理信息系统已经基本完成了研究阶段而转向实施，研究工作在80年代中就逐步转向为医疗服务的系统，如临床信息系统，PACS等方面。在欧洲、日本和美国等相继建立起研究PACS的实验室和实验系统。随着技术的发展，到90年代初期已经陆续建立起一些实用的PACS。
美国最早的PACS研究是美国军方1983年主持的远程放射项目,该项目后来发展为美国军方资助的数字成像网络和图像存储及通讯系统项目（DIN/PACS），于1985年投入使用。1990年10月，在法国的Evain召开了一次对于PACS发展有重要意义的会议，这次会议由北大西洋公约组织高级研究院（NATO ASI）举办，来自17个国家的近百名专家参加了会议。会议概述了当时国际PACS研究和发展的概况，同时促使了PACS系统在美国军方中大规模使用。
经过近二十年各方面不懈的努力，PACS系统已由第一代进化到第二代，在一些先进国家的医院内基本实现了无胶片化的、实用的数字化影像业务网络，并且进一步利用新技术，在很多机构内已经开始了更深层次的研究。第一代PACS系统通常关注某一特定或若干成像设备，是影像科室局部的影像数字化，一般只有部分医师使用。由于当时技术、行业标准规范以及对这一领域的认知深度等因素的制约，第一代PACS系统多采用定制（Case by Case）的解决方案，建成的系统在可扩展性、开放性、可互连性方面存在先天不足。第二代PACS系统强调系统的标准化、开放性、可连接性、可扩展性，使用工业标准技术、协议和体系结构构建PACS系统，并考虑PACS系统与相关的RIS、HIS系统间的接口集成。
随着PACS系统的概念逐步清晰，应用逐步广泛，PACS系统在国内的推广也逐步深入。自1990年后，国内众多研究机构和医院从不同角度、层面逐步开始了在这一领域上的研究和实践。PACS系统已逐渐为业界所接受，已显示出其自身的经济社会价值，并得到了越来越多的医疗机构管理者、放射医生、临床医生的认同。
从PACS的技术发展来看可以分为三个阶段。
(一) 第一阶段（20世纪80年代中期~90年代中期）
计算机自身性能有限，CPU主频仅几十兆，内存只有64M，而且价格昂贵。研究主要集中在如何利用有限的计算机资源处理大容量的数字图像，如用各种算法优化、硬件加速等。 而显示技术也不能保证图像显示的一致性。因为没有统一的标准，不同设备的图像交换困难，DICOM标准开始出现。
这一时期的PACS系统主要是将放射科的一些影像设备进行连接，以胶片的数字化为目标，实现医学影像传输、管理和显示。由于显示质量不高，人们普遍认为不可能用软拷贝代替胶片。PACS显然不能满足临床的需要。
(二) 第二阶段（20世纪90年代中期~90年代末期）
计算机技术、网络技术的发展，特别是PC机性能的大大提高，使PACS用户终端的速度和功能加强了。DICOM标准的形成促进了商用和大型PACS系统的发展。而显示技术的发展和显示质量控制软件的出现，图像显示质量基本达到读片要求，PACS的诊断价值开始得到临床认可。应诊断报告和信息保存的要求，RIS开始出现。临床的应用使人们关注工作流问题，即在检查登记、图像获取、存储、分发、诊断等等步骤中PACS如何与RIS沟通，提高工作效率。
(三) 第三阶段（20世纪末到现在）
DICOM标准被广泛接受，PACS、RIS开始与HIS全面整合，PACS被用于远程诊断。质量控制软件技术的进一步发展，新的显示设备的出现，淡化了温度、寿命对显示器显示质量的影响。PACS系统中引进临床专用软件，以利于辅助诊断和治疗。无胶片化的进程，促使人们开始研究PACS系统的安全性。
二、 PACS的分类
作为实现医学影像数字化和工作手段信息化的产物，PACS是集影像、通信、网络、计算机及存储等多学科、多领域的技术而成。伴随着相关信息技术的发展，人们对PACS的需求、认识也在不断变化，由此PACS本身的概念和外延也在发生变化。 着眼于不同的系统目标、应用需求和系统结构可对PACS做如下分类：
(一) 设备级 PACS
这是一种纯图像的PACS系统，实现几台影像设备图像的数字化存储和传输，系统只包含病人的基本信息、设备信息、位图信息等，尚未满足影像科室的数字化工作流程。也称之为mini PACS。
(二) 部门级 PACS
这一层次的PACS系统连接一个影像科室内所有影像设备，对其图像做集中存储，实现科室内影像数字化诊断，实现不同设备的图像资源及相关信息的共享。为保证系统的实用性，PACS 系统与病人相关信息管理结合起来，具有病人信息登录、预约、查询、统计等功能，即PACS要与RIS融合，或说这一层次的PACS本身就要包涵RIS的所有功能；科室级PACS主要是以放射科室为主，兼顾及其他影像科室。
(三) 全院级 PACS
以满足以数字化诊断为核心的医院整个影像工作过程的PACS，称为“Full PACS”。系统将医院所有影像设备连接互动，实现全院不同设备的图像资源及相关信息的共享，医院各个科室围绕影像数据互相配合协同工作。此阶段的PACS是以数字化影像诊断（无纸化、无胶片化）为核心的大型网络系统，它涉及到放射科、超声科、内镜室、病理科、导管室、核医学科等相关影像科室，将全院影像设备资源和人力资源进行更合理有效的配置。系统使影像科室医生可通过PACS提高影像诊断水平和工作效率，通过网络为临床医生提供病人图像及诊断报告；临床医生通过网络快速调阅病人图像及诊断报告，在网络中为影像医生提供病人其他病历和病程信息，实现诊治资源的最大化共享。为实现上述功能，系统至少应包括数字影像采集、数字化诊断工作站、影像会诊中心、网络影像打印管理、网络影像存储、网络影像分发系统、网络影像显示计算机、网络综合布线和数据交换系统等部分，此外系统还必须和医院其他系统融合，尤其是HIS系统。
(四) 区域级PACS
随着医院集团和区域医疗信息化的发展，在医疗机构之间共享影像信息资源，并开展异地诊断和远程会诊的需求日益显现。对PACS系统的体系结构、传输、存储以及安全认证、授权等方面提出了新的挑战，出现了集中式的区域影像数据中心和以跨区域影像文档共享(XDS-I)为代表的分布式解决方案。
三、 PACS的功能
PACS系统使得医学影像真正地实现了数字化存储、传输、检索、处理，概括起来，具有如下功能：
(一) 联接不同类别的影像设备。
PACS系统利用计算机信息技术将不同型号、类别、地点的设备产生的图像，在统一的数字图像格式标准下，进行采集和集中存储，使得医生可以在自己的终端上调阅感兴趣的图像，做各种处理、辅助诊断和治疗。
(二) 医学图像的大容量存储与高效管理。
图像保存的传统介质采用的是胶片、照片或纸张等，其缺点是成本高，效率低；保存场地需不断增加，保管不易；需防虫蛀、霉变、丢失；图像复制、传递不便，历史图像检索困难。PACS彻底改变了传统的图像保存和传递方式，数字图像保存在磁盘、磁带、光盘上，占地小，成本低，保存时间长。
(三) 便捷的图像调用与后处理。
利用计算机信息技术可以高速、高效的检索、复制、传递图像，真正实现了医学图像信息资源的共享。图像的跨科室、跨医院、跨地区流动，减少了等待检查结果的时间，方便了医生检索相关图像，有利于迅速诊断和治疗，无损、高效的图像传输，提高了远程会诊的质量。
计算机强大的图像处理功能，可以在读片终端上对图像做各种处理，进行更细致的观察，具有更多的图像显示方式：三维重建、虚拟内窥镜、图像融合等等，因而提供了更多的信息，将人类在利用医学图像诊断和治疗上的知识积累，转变为计算机软件，使医学图像诊断治疗技术走向更深的层次。
(四) 优化工作流程，提高工作效率。
PACS的优势不仅仅局限于医学影像的存储与传输，PACS的建设可以帮助医院优化影像工作流程，节省医生和技师的时间，提高医疗质量和工作效率，缩短病人的等候时间和住院时间，提高病人满意度。通过PACS可以帮助协调科室管理，安排工作，并可对工作的质和量进行在线监控和统计分析。
第二节 DICOM标准
一、 概述
DICOM是Digital Imaging and Communication of Medicine的缩写，是美国放射学会(American College of Radiology，ACR)和美国电器制造商协会(National Electrical Manufacturers Association，NEMA)组织制定的专门用于医学图像的存储和传输的标准名称。经过十多年的发展，该标准已经被医疗设备生产商和医疗界广泛接受，在医疗仪器中得到普及和应用，带有DICOM接口的计算机断层扫描(CT)、核磁共振(MR)、心血管造影和超声成像设备大量出现，在医疗信息系统数字网络化中起了重要的作用。
DICOM是随着图像化、计算机化的医疗设备的普及和PACS系统的发展应运而生的。当CT和MRI等设备生成高质量的、形象直观的图像在医疗诊断中广泛使用时，由于不同的生产商不同型号的设备产生的图像各自采用了不同的格式，使得不同的设备的信息资源难以统一管理，PACS系统的实施具有很大的困难。为此，美国放射学会和美国电器制造商协会在1983年成立了专门委员会，制定用于医学图像存储和传输的标准，提供与制造商无关的数字图像及其相关的传输和存储功能的统一格式，以促进PACS的发展。
ACR-NEMA1.0版本于1985年推出，随后增加了新的数据元素并对部分内容进行修改，形成2.0版本。由于认识到标准对网络支持的不足和标准本身存在的结构性问题，ACR-NEMA结合当时的技术条件和方法对标准作了彻底的重新制定，在1993年正式公布了新的版本，命名为DICOM3.0。与原版本相比，3.0版本采用了面向对象的分析方法，定义了医学图像在存储和传输过程中的各种实体和关系，提供了对ISO-OSI(International Standard Organization-Open System Interconnection)和TCP/IP (Transmission Control Protocol / Internet Protocol)的支持，使得在医学图像应用层上可以与其它通信协议栈直接通信而不需要重新编写程序。考虑到技术的发展，标准采用了多个部分的文档结构，对可能变化或扩充的部分以附录的形式提供，这样标准在更新时涉及面可以尽量小。
DICOM标准是经历了一个从无到有、从简单到复杂的发展过程。在标准的制定过程中不断听取工业界、学术界、医疗界等各方面的意见和建议，注意标准的可扩充性和可扩展性，经历了ACR-NEMA 1.0和2.0的版本到目前的DICOM 3.0版本，标准的组成也在不断地加以补充和调整，目前标准共有以下16个基本部分和扩充部分组成:
第1部分: 介绍和概述（Introduction and Overview）
给出了标准的设计原则，定义了标准中使用的一些术语，对标准的其它部分给了一个简要的概述。
第2部分: 一致性（Comformance）
一致性是指符合DICOM标准的设备能够互相连接互相操作的能力。标准要求设备制造商必须给出本设备所支持的DICOM功能的说明，即一致性声明。包含三个主要部分：本实现中可以识别的信息对象集合、本实现支持的服务类集合和本实现支持的通信协议集合。
第3部分: 信息对象定义（Information Object Definitions）
对医学数字图像存储和传输方面的信息对象提供了抽象的定义。每个信息对象定义是由其用途和属性组成的。
第4部分: 服务类规范（Service Class Specifications）
服务类是将信息对象与作用在该对象上的命令联系在一起，并说明了命令元素的要求以及作用在信息对象上的结果。服务类可以简单理解为DICOM提供的命令或提供给应用程序使用的内部调用函数。
第5部分: 数据结构和语义（Data Structure and Semantics）
说明了DICOM应用实体如何构造从信息对象与服务类的用途中导出的数据集信息，给出了构成消息中传递的数据流编码规则。
第6部分: 数据字典（Data Dictionary）
是DICOM中所有表示信息的数据元素定义的集合。标准中为每一个数据元素指定了唯一的标记、名字、数字特征和语义。
第7部分: 消息交换（Message Exchange）
消息是由用于交换的一个或多个命令以及完成命令所必需的数据组成，是DICOM应用实体之间进行通信的基本单元。这部分说明了在医学图像环境中的应用实体用于交换消息的服务和协议。
第8部分: 消息交换的网络支持（Network Communication Support for Message Exchange）
说明了DICOM实体之间在网络环境中通信服务和必要的上层协议的支持。这些服务和协议保证了应用实体之间有效地和正确地通过网络进行通信。
第9部分: 消息交换的点对点通信支持（Point-to-Point Communication Support for Message Exchange）
说明了与ACR-NEMA2.0相兼容的点对点通信环境下的服务和协议。在DICOM 3.0 中，该部分已淘汰。
第10部分: 数据交换的介质存储和文件格式（Media Storage and File Format for Data Interchange）
这一部分说明了一个在可移动存储介质上医学图像信息存储的通用模型。提供了在各种物理存储介质上不同类型的医学图像和相关信息进行交换的框架，以及支持封装任何信息对象定义的文件格式。
第11部分: 介质存储应用框架（Media Storage Application Profiles）
用于医学图像及相关设备信息交换的遵从性声明。给出了心血管造影、超声、CT、核磁共振等图像的应用说明和CD-R格式文件交换的说明。
第12部分: 数据交换的存储功能和介质格式（Storage Functions and Media Formats for Data Interchange）
它提供了在医学环境中数字图像计算机系统之间信息交换的功能。这部分说明了在描述介质存储模型之间关系的结构以及特定的物理介质特性及其相应的介质格式。具体说明了各种规格的磁光盘，PC机上使用的文件系统和1.44M软盘，以及CD-R可刻写光盘。
第13部分: 打印管理点对点通信支持（Print Management Point-to-Point Communication Support）
定义了在打印用户和打印提供方之间点对点连接时，支持DICOM打印管理应用实体通信的必要的服务和协议。在DICOM 3.0中，该部分已淘汰。
第14部分:灰度标准显示函数（Grayscale Standard Display Function）
这部分仅提供了用于测量特定显示系统显示特性的方法。这些方法可用于改变显示系统以与标准的灰度显示功能相匹配或用于测量显示系统与标准灰度显示功能的兼容程度。
第15部分：安全框架（Security Profiles）
该部分为DICOM 3.0标准新增部分。该部分定义了安全框架的遵从性声明。安全框架通过引用外部已开发的安全标准，使用诸如PKI、智能卡等安全技术。
第16部分：内容映射资源（Content Mapping Resource）
该部分也为DICOM 3.0标准新增部分。定义了DICOM 信息对象结构化文档的模板，信息对象所使用的编码术语集合，DICOM维护的术语词典，针对不同国家的编码术语的翻译。
二、 DICOM信息模型
DICOM标准是要解决不同设备制造商、不同国家等复杂的网络环境下的医学图像存储和传输的问题。要在这样复杂的情况下能够实现准确的无歧义的信息交换，需要解决的基本问题有语法和语义两大类。
所谓语义的问题就是指交换信息的具体含义。人们用自然语言进行交流时，就存在二义性问题，即表达的意思存在多种含义，难于用计算机进行处理。为此DICOM需要专门定义自己的“语法”和“词汇”，解决二义性问题。DICOM的“词汇”是用一对整数表示的，称为标记(Tag)，用数据字典给出详细的定义和解释，另外用UID的方法给出唯一标识。“语法”则是指信息组成的规则，在DICOM中通信双方只有按约定的方法组织数据，才可能使对方准确获得所传输的信息。
(一) 唯一标识符(UID)
用于唯一标识DICOM标准中各种不同信息对象的字符串，以保证不同国家、地区、生产商生成的标识可在世界上任何地点也可与其它生产商生成的标识相互区别。为保证每个标识的全球的唯一性，使用了下面的字符串(称为唯一标识符或UID)产生机制:
<根>.<后缀>
根部分是由权威部门分配的，它保证没有其他人或机构再使用这个根标识。这个数值由标准化组织分配给公司或组织。后缀由该公司或组织自行分配，但必须保证在它们自己内部也是唯一的。如此保证了每一个UID在全球范围内是唯一的标识。
例如“1.2.840.113681.2162644097.636.3189276047.7.50”是某企业影像系统产生的一张影像的UID。其中“1.2.840.113681”是该企业从ANSI申请得到的根标识，其余部分是该企业影像系统所产生的这张影像的内部唯一的标识。因此，该影像系统所产生的每张影像的UID，根标识每张相同，后缀部分张张不同，保证了UID全球唯一。
UID也用于标识DICOM定义的有关的属性。“1.2.840.10008”是ANSI分派给NEMA的根，用于标识DICOM术语，例如：
“1.2.840.10008.1.1”是验证服务类。
“1.2.840.10008.1.2”是DICOM默认的隐式LittleEndian传输语法。
“1.2.840.10008.5.1.4.1.1.2”是CT图像存储。
(二) 传输语法(Transfer Syntax)
数据存储与传输时，DICOM传输语法指明了数据如何编码得到字节流的编码方式。传输语法可以是默认的，或者是通信双方传输前协商好，或者与数据一起存储在介质上。
传输语法定义了三个方面的内容：值表示法如何指定，是明确给出(显式VR)还是采用预先规定的方式(隐式VR)；多字节数在存储或传输时的字节顺序，是低位字节先存储或发送(Little Endian)，还是高位字节先存储或发送(Big Endian)；封装情况下的压缩格式，是采用JPEG还是RLE的压缩算法，是有损方式还是无损方式等。
双方都采用一致的传输语法是非常重要的。不同的传输语法会导致信息的错误理解。例如，对于一个32位无符号整数12345678H，在Little Endian方式下的字节顺序为78、56、34、12，而在Big Endian方式下的字节顺序则为12、34、56、78。
传输语法是由一个UID标识的，各种DICOM传输语法见表11-1。DICOM默认的传输语法是隐式Little Endian传输语法，并采用无损方式的JPEG压缩算法，UID为“1.2.840.10008.1.2”。
表 11-1 DICOM传输语法
|
UID |
传输语法 |
|
1.2.840.10008.1.2 |
隐式VR Little Endian传输语法 |
|
1.2.840.10008.1.2.1 |
Little Endian传输语法(显式VR) |
|
1.2.840.10008.1.2.2 |
Big Endian传输语法(显式VR) |
|
1.2.840.10008.1.2.4.* |
各种数据压缩的传输语法 |
|
1.2.840.10008.1.2.5 |
RLE编码像素数据传输语法 |
(三) 数据元素(Data Element)与数据集(Data Set)
DICOM数据组织的基本单元是数据元素(Data Element)，数据集(Data Set)是DICOM信息保存与传递的主要形式，由一系列数据元素组成。
数据元素是通过数据元素标记(Tag)唯一标识的。一个数据元素包含了数据元素标记、值表示法(可选的)、值长度和数据元素值。数据元素的值表示法是否存在决定于协商的传输语法。数据元素结构见图11-1。
图11-1 DICOM数据集和数据元素结构
1． 标记(Tag) 标记是用一对16进制数表示的，前面的数是数据元素的组号，后面的是元素号。数据元素有标准数据元素和私有数据元素两种类型。组号为偶数的是标准数据元素，具体含义可以在DICOM的数据字典中查到。组号为奇数的为私有数据元素，由用户在使用过程中自己定义。
DICOM的数据字典定义了许多数据元素标记，涵盖了大多数的应用需要。例如: 在DICOM中(0010，0010)表示病人姓名，(0008，0020)表示检查日期， (0018，1088)表示心率。
2． 值表示法(Value Representation) DICOM标准中，对每个属性(用Tag标记)都定义了值表示法。值表示法具体描述了属性值如何进行编码。值表示法有隐式和显式两种形式。
隐式就是采用预先规定的表示方法，通过标记从数据字典中查到DICOM对这个属性表示方法的规定，从而正确解释属性值的内容。这种方式要求信息交换双方共享包含所有可能属性的数据字典。
显式是用两个字符明确表示值的表示方法，如AE表示应用实体，AS表示年龄字符串，DT是日期和时间，FD表示双精度浮点数等。这种方法增加了信息交换的开销，但比用共享数据字典更灵活，尤其在多制造商环境下，数据字典同步更新很困难。
3． 值长度(Value Length) 值长度指明了数据元素值域的字节长度，不包括标记、值表示法和值长度本身。如值长度为4字节且其值为FFFFFFFFH时，则表示未定义长度。值长度本身占用的字节数为2字节或4字节，具体如下：
(1) 隐式值表示法，值长度占4字节。
(2) 显式值表示法为OB、OW、SQ或UN(UT)时，紧跟着的2字节为0000H，预留给DICOM的以后版本。值长度占4字节。
(3) 其它显式值表示法，值长度占2字节。
4. 值域(Value Field) 数据元素中值域的字节长度由值长度指明，必须是偶数个，不足的部分填充空格。如果值长度为未定义长度，则由序列定界标记(FFFE,E0DD)或条目定界标记(FFFE,E00D)来表示该数据元素值的结束。
例如：默认传输语法下，病人姓名“COTTA^ANNA”的编码是这样的：病人姓名的标记为(0010,0010)，没有值表示法，值长度为10，值为“COTTA^ANNA”。最后得到的数据元素编码为：
10 00 10 00 0A 00 00 00 43 4F 54 54 41 5E 41 4E 4E 41 20
标记 值长度 值域
数据集是由若干个数据元素组成，按数据元素标记中的组号以及元素号数值增加的方式进行排序，依次排列。一个数据元素在数据集内至多只能出现一次。但是在嵌套的数据集中可以再次出现。
显式和隐式值表示法(VR)不能在同一个数据集以及其中的嵌套数据集中共存，一个数据集究竟使用显式还是隐式值表示法以及其它特性，取决于传输语法。
数据集的作用有两个：
(1) 作为信息对象定义IOD中的信息对象模块IOM；
(2) 作为信息交换中消息(Message)携带的数据内容。
(四) DICOM图像信息模型
DICOM图像信息模型是从放射科处理图像的方式中衍生出来的。一个患者可能前后多次来做检查或做多种设备的检查，每次检查可能有多个检查方式，每个检查方式下又可能有多幅图像。这些图像在患者病历中是以检查的类型(与图像序列有一定的关系)排序。当不同来源的图像数据集合到一个单一的环境中，必须将不同来源的图像数据排序，这仅在所有图像数据依照同一个信息模型构造时才有可能。
在DICOM的信息模型上主要有四个层次，分别是患者、检查、序列和图像层次。这四个层次分别对应了相关类型的信息的生成阶段和不同来源。
1． 患者层次(Patient) 患者层次包含属于某个检查的患者标识和描述信息。由于一个患者可能存在多个检查，患者层次是最高层次(当考虑一个患者的所有信息时)。然而在通常的实践中是使用检查层次用于对单个的检查请求由不同系统处理的信息的收集。
2． 检查层次(Study) 检查层次是在信息模型中最重要的层次，放射科的所有活动都围绕着检查的正确处理。一个检查是某个检查请求所产生的一个或多个图像序列，这些图像序列可能由多个影像设备产生。在检查层次上，保持着标识信息，并可以包含有与同一个检查有关的医院管理信息系统中的信息引用。一个患者可能由于其它或以前的检查而有多个检查。
3． 序列层次(Series) 在检查层次下收集了所有的图像序列。序列层次标识了生成图像的形态类型、序列生成的日期、检查类型的细节和使用的设备。
一个序列是单一影像设备产生的相关图像的集合。在许多情况下，图像间关系是通过采集发生的方式定义的。当按序地采集具有空间联系或一般联系的图像时，这些图像可以组成到一个序列中。当存在于图像之间的联系不再有效时，必须开始新序列。
4． 图像层次(Image) 信息模型的最低层次是图像层次，每个图像包含描述信息以及图像数据本身。图像层次包含有一幅(单幅)、两幅(双屏)和在相对短的时间内收集的多幅图像(多帧图像)。
(五) 应用实体
应用实体(Application Entity , AE)是指一个具体的DICOM应用，包括各种设备、PACS服务器、PACS工作站。通常用应用实体标题(AE Title)标识。DICOM的信息交换是在应用实体之间进行的。在实际的TCP/IP物理网络中，应用实体与一个IP地址及端口号对应。
三、 DICOM信息对象定义(IOD)
DICOM标准的第三部分说明了许多信息对象类（information object class，简称IOC）。这些信息对象类为现实世界中能够以数字医疗图像这种方式通讯的实体提供了一个面向对象的抽象的定义，也叫信息对象定义（information object definition，简称IOD）。每个信息对象类的定义包括了两个部分，即为什么要定义这个类，以及类所包含的属性（attribute）。由于它是类（class）的定义，而不是实例（instance）的定义，故属性具体值没有说明。
(一) 信息对象定义的结构
一个信息对象定义（IOD）是由若干包含相关信息的信息实体（IE）所组成。每一个信息实体对应着DICOM应用模型中的现实世界实体（如患者patient、图像image等）的一个数据抽象。每个信息实体是由若干属性（attribute）所组成的，属性是现实世界实体性质（如病人的姓名、年龄，图像的成像日期、时间等）的抽象。标准还将一个信息实体中相关的属性组合在一起，形成一个可被多个信息对象定义重复使用的模块（module，简称IOM），这样就使得信息对象定义更为方便，而且相关属性的语义描述更加集中，更易于理解。
(二) 信息对象定义的分类
为了满足标准未来的发展需要和维持与以前版本的兼容，在DICOM标准中将信息对象定义分为两类：标准信息对象定义（normalized IOD）和复合信息对象定义（composite IOD）。
1． 标准信息对象定义 包含且只包含一个信息实体（IE），其中的属性均为现实世界实体所固有的属性。例如一个被定义为检查（study）的标准信息对象定义，包含了检查日期和时间两个属性，对于检查来说，这两个属性是其本身固有的。而患者姓名（patient name）这个属性，由于它是接受检查的病人所固有的性质，而非检查本身所固有的性质，故不能包含在检查的属性中。标准信息对象定义的定义是严格符合面向对象设计的要求的。当一个标准信息对象定义的实例在通讯中被使用时，该实例的上下文并不真正交换，而是通过使用与标准信息对象定义实例相关的指针来提供上下文。标准信息对象定义一般在与系统管理相关的服务类（service class）中使用。
2． 复合信息对象定义 包含一个以上的相关信息实体（IE）。这就意味着该类信息对象定义所包含的属性有两类：①现实世界实体本身所固有的；②不是现实世界实体固有但是与之相关的属性。例如被定义为复合信息对象定义的CT图像信息对象定义，其中既包含了图像（image）本身所固有的，如成像日期等属性，也包含了图像本身所没有，但与之相关的（如患者姓名等）属性。这些相关的现实世界对象为被交换的信息提供了一个完整的上下文（context）。当一个复合信息对象定义的实例参与通讯时，在应用实体（application entity）间交换的是整个的上下文。多个复合信息对象定义之间的关系应当在这个上下文信息中传送。
严格地来说，复合信息对象定义的定义并不完全符合面向对象设计的要求，它主要是为了使标准保持与以前的1.0和2.0版本兼容而不得不采取的相应措施。但是随着近来计算机科学的发展，人们也已逐渐认识到了复合对象的一些好处。最重要的一点在于通过使用复合对象，人们可以通过较少的读取查询次数来获得全部信息，而对内存的存取速度远比对磁盘的存取速度快，这就节约了时间。例如一幅DICOM格式的CT图像，只要读取一次并解码后即可获得病人姓名等人口统计学的、成像时间条件以及图像的像素等数据，而若不采用复合信息对象定义，则至少要读取三次才行。
(三) 标准信息对象定义
一个标准信息对象定义是单个实体的信息对象定义，通常用来表示DICOM现实世界模型中的一个实体。其中一部分是从HIS或RIS传来的，用于PACS系统管理。
以患者信息对象定义为例，有服务对象对公用模块、患者关系模块、患者标识模块、患者描述信息、患者医疗信息五个模块，每个模块包含有患者实体的一组属性。DICOM的定义如下:
1．服务对象对公用模块 服务对象对类UID，服务对象对实例UID，特殊字符集，实例生成的日期和时间，生成者UID，实例号。
2．患者关系模块 参考检查序列，参考就诊序列，参考患者别名序列。
3．患者标识模块 姓名，患者ID，发放ID的医疗机构，其它ID，其它名，患者父姓，医疗记录定位符。
4．患者描述信息 年龄，职业，数据保密限制描述，出生日期，出生时间，性别，保险计划号序列，身高，体重，住址，军阶，军种，居住国家，电话号码，种族，宗教，注解。
5．患者医疗信息 医疗警告，造影剂过敏史，吸烟情况，患者其它历史，怀孕情况，上次月经日期，特殊需求，患者状态。
(四) 复合信息对象定义
复合信息对象定义大多为医疗图像，这些医疗图像复合对象包含一些与成像设备相关的属性，这些属性根据各自成像设备的不同而不同。除此之外，它们包含一些共同的属性，主要有：
1) 标识属性：即使一图像区别于其余图像的标识。包括服务对象对类UID、检查实例UID、序列实例UID以及图像实例UID等；
2) 成像设备的类型：是CT、MR或是US等；
3) 与像素有关的属性：包括每像素的采样、阵列的行、列等数字、分配比特数、存贮比特数、高位比特、像素表示、平面配置等。
以下是一个CT图像的信息对象定义，涉及患者、检查、序列、参考帧、设备和图像实体，每个实体又有若干模块，其中有些模块是可选的，用(U)标明。
1．患者实体
(1) 患者模块：姓名，患者ID，出生日期，性别，参考病人序列，出生时间，其它ID，其它名，种族，注解。
(2) 临床试验模块(U)：临床试验组织者，临床试验协议ID，协议名，临床试验场所ID，场所名。
2．检查实体
(1) 一般检查模块：检查实例UID，检查日期，检查时间，经治医生姓名，经治医生标识序列，检查ID，访问号，检查描述，记录医生，记录医生标识序列，读片医生姓名，读片医生标识序列，参考检查序列，操作代码序列。
(2) 患者检查模块(U)：入院诊断描述，入院诊断代码序列，患者年龄，身高，体重，职业，附加病史。
(3) 临床试验检查模块(U)：临床试验时点ID，临床试验时点描述。
3．序列实体
(1) 一般序列模块：影像设备，序列实例UID，序列号，体侧，序列日期，时间，实施医生姓名，实施医生标识序列，协议名，协议描述，操作员姓名，操作员标识序列，参考操作程序步骤序列，检查部位，患者体位，最小像素值，最大像素值，请求属性序列，操作程序步骤ID，操作程序步骤开始日期，操作程序步骤开始时间，操作程序步骤描述，操作协议代码序列，操作程序步骤说明。
(2) 临床试验序列模块(U)：临床试验协调中心名称。
4．参考帧实体
(1) 参考帧模块： 参考帧UID，位置参考指示。
5．设备实体
(1) 一般设备模块：制造商，机构名称，机构地址，工作站名称，机构科室名称，设备型号，设备序列号，软件版本，空间分辨率，最后校准日期，最后校准时间，像素填充值。
6．图像实体
(1) 一般图像模块：实例编号，患者方向，内容日期，内容时间，图像类别，采集编号，采集日期，采集时间，参考图像序列，派生方法描述，派生方法代码序列，原图像序列，参考波形序列，图像说明，质控图像标志，写入标注标志，有损图像压缩，压缩比，图标图像序列，显示查找表锐化。
(2) 图像平面模块：像素间距，图像方向，图像位置，切片厚度，切片位置。
(3) 图像像素模块：每像素平面数，光度解释，行数，列数，分配位数，存储位数，最高位，象素表示，象素数据，平面配置，象素表观比率，最小图像象素值，最大图像象素值，红调色板颜色查找表描述符，绿调色板颜色查找表描述符，蓝调色板颜色查找表描述符，红调色板颜色检查表数据，绿调色板颜色检查表数据，蓝调色板颜色检查表数据。
(4) 对比度增强剂模块：对比度增强剂，对比度增强剂序列，给药途径，给药途径序列，给药容量，给药开始时间，结束时间，对比度增强剂总剂量，给药速率，给药持续时间，对比度增强剂成份，对比度增强剂成份浓度。
(5) CT图像模块： 图像类型，每像素平面数，光度解释，分配位数，存储位数，最高位，换算截距，换算斜率，千伏数，采集编号，扫描选项，数据收集直径，重建直径，源到探测器的距离，源到病人的距离，支架/探测器倾斜度，床高，旋转方向，曝光时间，X射线管电流，曝光量，微安秒曝光量，过滤器类型，发生器功率，焦点，回旋中心。
(6) 叠加平面模块(U)：叠加行数，列数，叠加类型，叠加起点，叠加分配位数，叠加位的位置，叠加数据，叠加描述，叠加子类型，叠加标签，ROI区域，ROI均值，ROI标准差。
(7) 感兴趣值(VOI)查找表模块(U)：感兴趣值查找表序列，窗宽，窗位，窗宽窗位解释
(8) 服务对象对(SOP)通用模块：服务对象对类UID，服务对象对实例UID，特殊字符集，实例创建日期，实例创建时间，实例创建者UID，编码方案标志序列，时区UTC时差，相关设备序列，实例编号，服务对象对实例状态，服务对象对认证日期时间，服务对象对认证说明，认证设备证书编号，加密属性序列。
四、 DICOM服务类
服务(Service)是指某对象为其它对象或程序提供的功能。当要求使用此功能时称申请服务，申请服务的对象称服务用户，而能完成该功能的对象是服务的提供者。如DICOM消息服务元素(DIMSE)可以为上层DICOM应用实体(Application Entity，AE)即DICOM应用程序提供消息传送的服务。
面向对象的设计不仅描述了对象本身的属性，同时还说明了怎样处理这些对象的方法。DICOM标准中就利用这个概念，定义了诸如存贮图像、获取病人信息之类的服务（service）。由于是面向对象的设计，故服务又叫做服务类。一个服务类由若干个相关的服务对象对（service object pair，SOP）类组成。SOP类是DICOM标准中定义的基本功能单位。
(一) 服务对象对类
服务对象对(SOP)类定义为一个IOD和一组DIMSE服务的联合。SOP类定义中含有一些规则和语义，对DIMSE服务组的服务和/或IOD属性的使用进行限制。
应用实体(AE)通过选择SOP类来建立支持相互交互的协商一致的性能集合。这个协商在关联建立时进行。一种扩展的协商机制允许应用实体进一步就一个SOP类内部的某些特定的选项进行协商。
DICOM定义了两类SOP类：标准SOP类和复合SOP类。标准SOP类定义为一个标准IOD与一套DIMSE-N服务的联合。复合SOP类定义为一个复合IOD和一套DIMSE-C服务的联合。
SOP类规范在定义DICOM一致性声明中起着一个核心作用，允许DICOM应用实体选择DICOM 3.0标准所定义的应用级子集来声明其一致性。
(二) 服务类规范
一个服务类规范定义了一组与某一特定功能相关的一个或几个SOP类，该功能需要应用实体间的通信才能完成。服务类规范也定义了一些规则，允许具体的实现声明对一个或多个SOP类的一些预定义级别的一致性。应用实体既可作为SOP服务类用户(SCU)也可作为SOP服务类提供者(SCP)。
两个应用实体间以“客户机-服务器”模式工作。服务类提供者（service class provider，SCP）提供SOP类的服务，它相当于客户/服务器模型中的服务器（server）。服务类使用者（service class user，SCU）使用SOP类的服务，它相当于客户/服务器模型中的客户。例如一台成像设备要向PACS服务器存储一幅图像，在这种情况下，该成像设备为与存储相关的服务类的SCU，PACS服务器为存储相关服务类的SCP。
(三) DICOM服务类
DICOM标准定义了如下的服务类：
1．验证(Verification)服务类 定义了验证对等DICOM应用实体间应用级通信的服务。使用验证SOP类，其中仅由C-ECHO DIMSE-C服务组成，没有定义相关联的IOD。
2．存储服务类(Storage ) 定义一个便于实现简单的图像传送的应用级的服务。使用CR图像存储SOP类、CT图像存储SOP类、MR图像存储SOP类、核医学图像存储SOP类、PET图像存储SOP类、超声图像存储SOP类、灰阶软拷贝显示状态存储SOP类、结构化报告存储SOP类等诸多复合SOP类，使用C-STORE DIMSE-C服务。
3．查询/检索(Query/Retrieve)服务类 定义一个便于实现对复合对象实例进行简单管理的应用级的服务。使用患者根SOP类、检查根SOP类、患者/检查SOP类及C-FIND、C-MOVE、C-GGET DIMSE-C服务。
4．检查内容通知(Study Content Notification)服务类 定义一种允许一个DICOM应用实体将一次检查所得到的图像存在与否、内容及源位置等信息通知另一个DICOM应用实体的应用级的服务。由基本检查内容通知SOP类构成，使用基本检查描述者IOD和C-STORE DIMSE 服务。
5．患者管理(Patient Management)服务类 定义一种便于创建和跟踪有助于管理放射影像检查的患者信息子集及患者就诊信息的应用级服务。使用独立患者管理SOP类、独立就诊管理SOP类、独立患者管理元SOP类。
6．检查管理(Study Management)服务类 定义一种便于创建、安排、执行和跟踪影像检查的应用级服务。使用独立检查管理SOP类、检查组件管理SOP类、检查管理元SOP类、设备执行过程步骤SOP类、设备执行过程步骤检索SOP类、设备执行过程步骤通知SOP类、通用计划过程步骤SOP类、通用执行过程步骤SOP类。
7．结果管理(Result Management)服务类 定义一种便于创建、跟踪检查结果及其相关诊断解释的应用级服务。使用独立结果管理SOP类、独立解释管理SOP类、独立结果管理元SOP类。
8．打印管理(Print Management)服务类 定义一种便于将图像及其相关数据打印到硬拷贝介质上的应用级服务。使用基本胶片会话SOP类、基本胶片区SOP类、图像区SOP类、基本标注区SOP类、打印任务SOP类、打印机SOP类、VOI查找表SOP类、图像叠加区SOP类、显示查找表SOP类、下拉打印请求SOP类、打印机配置检索SOP类、基本打印图像叠加区SOP类。
9．介质存储(Media Storage)服务类 定义一种便于通过存储介质在DICOM应用实体间简单传送图像及其关联信息的应用级服务。使用CR图像存储SOP类、CT图像存储SOP类、MR图像存储SOP类、核医学图像存储SOP类、PET图像存储SOP类、超声图像存储SOP类、灰阶软拷贝显示状态存储SOP类、结构化报告存储SOP类、独立患者管理存储SOP类、独立就诊管理存储SOP类、独立检查管理存储SOP类、独立结果管理存储SOP类等诸多SOP类。
10．存储提交(Storage Commitment)服务类 存储服务类只对SCP接收传送的图像有所规定，而没有显式地对其安全存储图像的责任加以考虑。为此存储提交服务类定义一种方便提交存储的应用级服务。使用存储提交推送模式SOP类。
11．基本工作列表管理(Basic Worklist Management)服务类 定义一种便于访问工作列表的应用级服务。使用设备工作列表SOP类、通用工作列表SOP类。
12．队列管理(Queue Management)服务类 定义一种便于在网络环境中进行队列管理的应用级服务。使用打印队列管理SOP类。
13．灰度软拷贝显示状态存储(Grayscale Softcopy Presentation State Storage)SOP类 本类扩展了存储服务类的功能，增加了传送想要的显示状态或对已存在的显示状态进行记录的能力。
14．结构化报告存储(Structured Reporting Storage)SOP类 本类扩展了存储服务类的功能，增加结构化报告存储的SCP行为和一致性要求。
五、DICOM消息交换和网络通信
正如DICOM标准本身的命名那样，DICOM标准要解决的一个主要问题就是网络传输，也就是在各种各样的网络硬件和软件的环境下，如何能够实现医学图像可靠地高效地传送到期望的目的计算机中。为此，DICOM标准采取的策略是在成熟的标准化的网络环境基础上增加对医学图像的支持，而不是从最低层开始定义，这样就可以直接利用现有的网络硬件和软件资源，促进DICOM标准的开发和应用。
在DICOM标准的制定中，主要采用了在实际中广泛使用的TCP/IP协议和影响较大的OSI网络协议，作为对DICOM网络支持的基础。在这两个协议之上分别定义了DICOM自己的基于消息的信息交换的上层协议DIMSE (Dicom Message Service Element)。需要注意的是在DICOM3.0版中，已不再采用OSI网络协议和点对点协议，只采用单一的TCP/IP协议。
(一) 消息
应用实体间是通过DICOM消息(Message)经DICOM网络接口进行通信的。一个消息是由命令集及随后的有条件数据集复合而成的。命令集用来指明在数据集上将要执行的或利用数据集的操作或通告。数据集已经在前面章节进行过介绍。
命令集由若干个命令元素构成，命令元素含有DIMSE协议指定的每个语义的命令集中每个独立域中的编码值。每个命令元素由一个显式标记、值长度和值域复合而成。DICOM消息的总的结构见图11-2。
图11-2 DICOM消息结构
(二) DICOM消息服务元素
DICOM消息服务元素（DIMSE）为DICOM应用实体提供两种类型的信息传输服务：通知(Notification)服务和操作(Operation)服务。通知服务允许一个DICOM应用实体通知另一个应用实体某个事件的发生或状态的改变。通知的定义以及随后的应用实体的行为取决于服务类和IOD。操作服务允许一个DICOM应用实体显式请求执行另一个DICOM应用实体管理的一个SOP实例上的操作。
由于对复合SOP实例的操作方式与标准SOP实例的操作和通知的方式相差较大，DIMSE定义了两组服务：DIMSE-C服务和DIMSE-N服务。
1．关联服务 两个应用实体之间的用于信息交换的连接称为关联(Association)。对一个关联，许多通信内容都是作为上下文(Context)被确定的，其中的内容可以发生变化，这种变化实际上体现了信息的交换。在DICOM标准中定义了这个上下文(称应用上下文)，双方必须根据这个上下文的定义协调动作。
一个应用上下文用UID标识，并在关联初始化中传递到对方。通过比较应用上下文的UID，对方能够决定是否能够处理这个关联的请求从而接受或拒绝这个关联请求。通过关联，哪一种类的信息交换能够发生是由SOP类和这些SOP类的服务类定义。关联的发起方建议的SOP将使用的类型、每个SOP类的SCU/SCP(服务类用户/服务类提供者)角色和信息的表示方式，取决于另一方的能力，它可以接受或拒绝每一个单独的SOP类。
经过这个协商过程，双方都知道对方的能力和限制。实际的信息交换能够根据服务类和SOP类角色(为这些类定义的)进行。当关联不再需要时，关联被终止。
2．DIMSE-C服务 仅提供操作服务。支持与复合SOP类相关的操作，提供与老版本DICOM标准有效的兼容性。允许一个DICOM应用实体显式请求执行另一个DICOM应用实体的一个复合SOP实例上的操作。
(1) C-STORE服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求复合SOP实例信息的存储。
(2) C-FIND服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求用一系列属性串与后者管理的SOP实例集的属性进行匹配，对每个匹配均返回一个所请求的属性及其值的列表。
(3) C-GET服务：由一个DIMSE服务使用者激活，提供一些属性从对等DIMSE服务使用者获取一个或多个相匹配的复合SOP实例的信息。
(4) C-MOVE服务：由一个DIMSE服务使用者激活，提供一些属性从对等DIMSE服务使用者处将一个或多个相匹配的复合SOP实例的信息转移到一个第三方的DIMSE服务使用者。
(5) C-ECHO服务：由一个DIMSE服务使用者激活，证明与对等DIMSE服务使用者间的端对端的通信是否存在。
3．DIMSE-N服务 提供与标准SOP类相关的通知和操作，提供面向对象的操作/通知的扩展集。
(1) N-EVENT-REPORT服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者报告有关某个SOP实例的事件。该服务为证实服务，需要等待响应。
(2) N-GET服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求检索信息。
(3) N-SET服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求修改信息。
(4) N-ACTION服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求执行某个动作。
(5) N-CREATE服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求创建某一SOP类的一个实例。
(6) N-DELETE服务：由一个DIMSE服务使用者激活，向对等DIMSE服务使用者请求删除某一SOP类的一个实例。
(三) DICOM通信举例
1． 图像存储 设一次CT检查有多幅图像要从CT机送到PACS控制器存储。每幅图像从CT机送到PACS控制器时利用C-STORE来服务。此时CT机充任客户方，作为C-STORE服务类的使用者（SCU）。而PACS控制器则充当服务方，作为C-STORE服务类的提供者（SCP）。整个过程如图11-3所示。
首先，CT机向PACS控制器发出一关联请求①；PACS控制器应答并送出关联响应②；然后CT机（SCU）给PACS控制器（SCP）发出一C-STORE服务请求③；控制器收到C-STORE请求并向CT机发出C-STORE响应④；接着CT机向控制器发出第一个数据包⑤；PACS控制器执行该被请求的C-STORE服务，存储这一数据包，一旦完成，即给CT机发出一个证实信号⑥。在接到PACS控制器的证实信号确证数据包已存储完毕后，CT机发出第2个数据包。重复⑤、⑥两步直至第一幅图像的全部数据包传送完毕。此后CT机发出第2个C-STORE服务请求给PACS控制器以传送第2幅图像，重复③-⑥直至这一检查的所有图像全部传送完毕。CT机发出释放关联请求命令；PACS控制器发出释放关联响应命令，断开联系。
span style='mso-ignore:vglayout;;z-index:5;left:0px;margin-left:92px;margin-top:30px;width:398px; height:328px'
图11-3 DICOM图像存储操作
2． 查询与检索 设工作站欲查询PACS服务器，以检索过去的CT检查档案，从而在工作站上与当前的检查进行比较。查询与检索服务类含有三种消息服务元素（DIMSE）：C-FIND，C-MOVE和C-STORE。
在进行SOP服务时，在每个工作站和PACS控制器方有一个作为使用者，另一个作为提供者，在查询／检索时，工作站方扮演使用者SCU，PACS控制器方扮演提供者SCP。在传送已检索到的图像时，用C-STORE，此时两者角色互换，即工作站方扮演提供者，而控制器方扮演使用者。DICOM查询／检索操作的流程图如图11-4所示。
首先，工作站发出建立关联的请求；PACS控制器作出响应；工作站的查询／检索应用实体（AE）向PACS控制器发出一C-FIND服务请求；该控制器的应用实体收到C-FIND请求后执行C-FIND服务，从数据库中寻找“检查”、“系列”和“图像”并给工作站发出一C-FIND响应；工作站的查询／检索应用实体收到C-FIND响应。这是一张含有全部请求的表；工作站从该表中选择一感兴趣的图像；并对每一图像给PACS控制器发出一C-MOVE服务请求；PACS控制器查询／检索实体收到C-MOVE请求后给PACS控制器的C-STORE SCU发出一个指示；此时，PACS控制器的作用已转换为SCU。C-STORE SCU从存档设备中检索被请求的图像；PACS控制器的C-STORE SCU发出一C-STORE请求给工作站的C-STORE SCP⑩；以便给工作站发送检索得到的图像。工作站收到C-STORE请求后给PACS控制器发出一C-STORE响应。此后C-STORESOP服务与上例相同。如此依次进行第2幅，第3幅操作，当工作站收到最后一幅图像后发出释放关联请求，并终止联系。
span style='mso-ignore:vglayout;;z-index:4;left:0px;margin-left:83px;margin-top:30px;width:434px; height:344px'
图11-4 DICOM查询/检索操作
六、DICOM文件格式
除了利用通信线路进行DICOM信息交换外，也可以通过存储介质进行信息交换。将图像、诊断、检查的结果等信息存储在如软盘和光盘等存储介质中，实现在不同的系统之间在不同的时间内进行信息交换，还可以实现信息长久的保存。
(一) DICOM文件格式
DICOM文件提供了一种封装方式，将DICOM IOD的一个SOP实例以数据集的形式封装在一个文件中。DICOM标准文件由DICOM文件头和DICOM数据集两部分组成。每个文件包含一个单一的SOP实例，其中包含有一帧或多帧图象。
1．DICOM文件头 DICOM文件头信息位于文件的起始，用于描述该文件的版本信息、存储媒体、传输语法标识等信息。
文件头的最开始是128个字节的文件前导符（Preamble）和 4字节的DICOM前缀（prefix），接下来是文件头元素（Meta Elements）。
文件前导符可以根据应用框架或具体实现的定义来使用。DICOM标准对这个固定长度的前导符没有任何结构性的要求，它不必像DICOM数据元素在结构上要有一个标识和长度信息。这是为了让DICOM文件数据易于和许多通用计算机图像格式相兼容。如果文件前导符没有被应用框架或具体实现使用到，此128字节应当被置为00H，以便于识别此128字节是否载有应用信息。
DICOM四字节前缀应当包含特征字串DICM(大写且字体采用ISO8859-G0字符集，即常用的ASCII编码)，这四个字节没有标识及长度信息。
前导符及DICOM前缀后是一系列DICOM头元素，包括组群长度(0002,0000)、版本号(0002,0001)、存储介质SOP类UID(0002,0002)、存储介质SOP实例UID(0002,0003)、传输语法UID(0002,0010)、应用类UID(0002,0012)、应用版本名(0002,0013)、源应用实体标题(0002,0016)、专用信息创建者UID(0002,0100)、专用信息(0002,0102)等属性。
2．DICOM数据集 DICOM数据集由一系列的数据元素(data element)组成，每一个数据元素由唯一数据元素标记tag来表示。多个数据元素在数据集中以标记从小到大递增的顺序排列。数据元素有三种结构，其中两种包含数值表示法VR，称为显式VR，另一种不包括VR，称为隐式VR。但是三种结构都包括标记、值长度和值域。VR是否存在，取决于文件头中的传输语法UID元素(0002,0010)的值。
在DICOM介质存储应用中，每个文件应包含单一的数据集，表示与单一的SOP类及其对应的IOD相联系的单个的SOP实例。由于特定的IOD可以被定义为包含多帧图像，一个文件可能包含有一个以上的影像帧。
由于DICOM数据集内并不包含它的总长度信息，DICOM文件服务所提供的文件结束标志就是数据集结束的唯一标志。当文件写入时数据集必须采用填充的情况下，数据集的最后一个数据元素可以是（FFFC, FFFC）。这个数据集尾部填充数据元素的值并不重要，所有读出该数据集的DICOM应用必须予以忽略。
(二) DICOM图像文件分析
按照上述的文件格式，读取DICOM文件中的数据并对照DICOM数据字典，即可获得DICOM文件中的所有信息。以下以一个CT图像文件为例解释如下：
|
文件内容 |
标签 |
VR |
长度 |
值 |
备注 |
|
00 00 00 00 00 00 …… |
128字节前导符 |
||||
|
44 49 43 4D |
DICM标识 |
||||
|
02 00 00 00 55 4C 04 00 A8 00 00 00 |
0002,0000 |
UL |
4 |
168 |
Group Length |
|
02 00 01 00 4F 42 00 00 02 00 00 00 00 01 |
0002,0001 |
OB |
2 |
00\01 |
FileMetaInformationVersion |
|
02 00 02 00 55 49 1A 00 31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 32 00 |
0002,0002 |
UI |
26 |
“1.2.840.10008.5.1.4.1.1.2” |
MediaStorageSOPClassUID |
|
02 00 03 00 55 49 22 00 31 2E 32 2E 38 34 30 2E 31 31 33 36 37 34 2E 39 35 30 38 30 39 31 33 32 33 35 34 32 34 32 2E 31 30 30 |
0002,0003 |
UI |
34 |
“1.2.840.113674.950809132354242.100” |
MediaStorageSOPInstanceUID |
|
02 00 10 00 55 49 12 00 31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 31 2E 32 00 |
0002,0010 |
UI |
18 |
“1.2.840.10008.1.2” |
TransferSyntaxUID |
|
02 00 12 00 55 49 14 00 31 2E 32 2E 34 30 2E 30 2E 31 33 2E 30 2E 30 2E 31 31 33 00 |
0002,0012 |
UI |
20 |
“1.2.40.0.13.0.0.113” |
ImplementationClassUID |
|
02 00 13 00 53 48 10 00 54 49 41 4E 49 5F 4A 44 49 43 4F 4D 5F 31 31 33 |
0002,0013 |
SH |
16 |
“TIANI_JDICOM_113” |
ImplementationVersionName |
|
08 00 00 00 04 00 00 00 54 01 00 00 |
0008,0000 |
UL |
4 |
340 |
Group Length |
|
08 00 08 00 1A 00 00 00 4F 52 49 47 49 4E 41 4C 5C 50 52 49 4D 41 52 59 5C 4C 4F 43 41 4C 49 5A 45 52 |
0008,0008 |
CS |
26 |
“ORIGINAL\PRIMARY\LOCALIZER” |
ImageType |
|
08 00 16 00 1A 00 00 00 31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 32 00 |
0008,0016 |
UI |
26 |
“1.2.840.10008.5.1.4.1.1.2” |
SOPClassUID |
|
08 00 18 00 22 00 00 00 31 2E 32 2E 38 34 30 2E 31 31 33 36 37 34 2E 39 35 30 38 30 39 31 33 32 33 35 34 32 34 32 2E 31 30 30 |
0008,0018 |
UI |
34 |
“1.2.840.113674.950809132354242.100” |
SOPInstanceUID |
|
08 00 20 00 08 00 00 00 31 39 39 35 30 36 30 38 |
0008,0020 |
DA |
8 |
“19950608” |
StudyDate |
|
08 00 21 00 08 00 00 00 31 39 39 35 30 36 30 38 |
0008,0021 |
DA |
8 |
“19950608” |
SeriesDate |
|
08 00 23 00 00 00 00 00 |
0008,0023 |
DA |
0 |
ContentDate |
|
|
08 00 30 00 0A 00 00 00 31 33 31 36 34 36 2E 30 30 30 |
0008,0030 |
TM |
10 |
“131646.000” |
StudyTime |
|
08 00 31 00 0A 00 00 00 31 33 31 36 34 36 2E 30 30 30 |
0008,0031 |
TM |
10 |
“131646.000” |
SeriesTime |
|
08 00 33 00 00 00 00 00 |
0008,0033 |
TM |
0 |
ContentTime |
|
|
08 00 50 00 08 00 00 00 54 48 55 39 39 34 38 20 |
0008,0050 |
SH |
8 |
“THU9948 “ |
AccessionNumber |
|
08 00 60 00 02 00 00 00 43 54 |
0008,0060 |
CS |
2 |
“CT” |
Modality |
|
08 00 70 00 12 00 00 00 47 45 4E 45 53 49 53 5F 48 49 53 50 45 45 44 5F 52 50 |
0008,0070 |
LO |
18 |
“GENESIS_HISPEED_RP” |
Manufacturer |
|
08 00 80 00 1A 00 00 00 50 4F 52 54 4C 41 4E 44 20 41 44 56 45 4E 54 49 53 54 20 4D 45 44 2E 20 43 20 |
0008,0080 |
LO |
26 |
“PORTLAND ADVENTIST MED. C “ |
InstitutionName |
|
08 00 90 00 08 00 00 00 53 20 4C 49 53 4F 4F 4B |
0008,0090 |
PN |
8 |
“S LISOOK” |
ReferringPhysiciansName |
|
08 00 10 10 12 00 00 00 47 45 4E 45 53 49 53 5F 48 49 53 50 45 45 44 5F 52 50 |
0008,1010 |
SH |
18 |
“GENESIS_HISPEED_RP” |
StationName |
|
08 00 30 10 0A 00 00 00 43 48 45 53 54 2F 41 42 44 20 |
0008,1030 |
LO |
10 |
“CHEST/ABD” |
StudyDescription |
|
10 00 00 00 04 00 00 00 4C 00 00 00 |
0010,0000 |
UL |
4 |
76 |
Group Length |
|
10 00 10 00 10 00 00 00 57 49 4C 4B 49 4E 53 5E 43 48 41 52 4C 45 53 20 |
0010,0010 |
PN |
16 |
“WILKINS^CHARLES ” |
PatientName |
|
10 00 20 00 06 00 00 00 47 45 30 35 31 34 |
0010,0020 |
LO |
6 |
“GE0514” |
PatientID |
|
10 00 30 00 00 00 00 00 |
0010,0030 |
DA |
0 |
PatientBirthDate |
|
|
10 00 40 00 02 00 00 00 4D 20 |
0010,0040 |
CS |
2 |
“M ” |
PatientSex |
|
10 00 10 10 00 00 00 00 |
0010,1010 |
AS |
0 |
PatientAge |
|
|
10 00 30 10 04 00 00 00 30 2E 30 20 |
0010,1030 |
DS |
4 |
“0.0 ” |
PatientWeight |
|
18 00 00 00 04 00 00 00 6E 00 00 00 |
0018,0000 |
UL |
4 |
110 |
Group Length |
|
18 00 10 00 00 00 00 00 |
0018,0010 |
LO |
0 |
ContrastBolusAgent |
|
|
18 00 22 00 00 00 00 00 |
0018,0022 |
CS |
0 |
ScanOptions |
|
|
18 00 50 00 04 00 00 00 30 2E 30 20 |
0018,0050 |
DS |
4 |
“0.0 ” |
SliceThickness |
|
18 00 60 00 06 00 00 00 31 32 30 2E 30 20 |
0018,0060 |
DS |
6 |
“120.0 ” |
KVP |
|
18 00 20 11 04 00 00 00 30 2E 30 20 |
0018,1120 |
DS |
4 |
“0.0 ” |
GantryDetectorTilt |
|
18 00 30 11 04 00 00 00 30 2E 30 20 |
0018,1130 |
DS |
4 |
“0.0 ” |
TableHeight |
|
18 00 50 11 04 00 00 00 39 33 33 33 |
0018,1150 |
IS |
4 |
“9333” |
ExposureTime |
|
18 00 51 11 04 00 00 00 31 30 30 20 |
0018,1151 |
IS |
4 |
“100 ” |
XRayTubeCurrent |
|
18 00 52 11 00 00 00 00 |
0018,1152 |
IS |
0 |
Exposure |
|
|
18 00 00 51 04 00 00 00 46 46 53 20 |
0018,5100 |
CS |
4 |
“FFS ” |
PatientPosition |
|
20 00 00 00 04 00 00 00 E2 00 00 00 |
0020,0000 |
UL |
4 |
142 |
Group Length |
|
20 00 0D 00 1A 00 00 00 31 2E 32 2E 38 34 30 2E 31 31 33 36 37 34 2E 35 31 34 2E 32 31 32 2E 32 30 30 |
0020,000D |
UI |
26 |
“1.2.840.113674.514.212.200” |
StudyInstanceUID |
|
20 00 0E 00 1E 00 00 00 31 2E 32 2E 38 34 30 2E 31 31 33 36 37 34 2E 35 31 34 2E 32 31 32 2E 38 31 2E 33 30 30 00 |
0020,000E |
UI |
30 |
“1.2.840.113674.514.212.81.300” |
SeriesInstanceUID |
|
20 00 10 00 04 00 00 00 31 37 38 34 |
0020,0010 |
SH |
4 |
“1784” |
StudyID |
|
20 00 11 00 02 00 00 00 31 20 |
0020,0011 |
IS |
2 |
“1 ” |
SeriesNumber |
|
20 00 12 00 00 00 00 00 |
0020,0012 |
IS |
0 |
AcquisitionNumber |
|
|
20 00 13 00 02 00 00 00 30 20 |
0020,0013 |
IS |
2 |
“0 ” |
InstanceNumber |
|
20 00 20 00 04 00 00 00 4C 5C 46 20 |
0020,0020 |
CS |
4 |
"L\F " |
PatientOrientation |
|
20 00 32 00 12 00 00 00 2D 32 34 38 2E 31 38 37 35 39 5C 30 2E 30 5C 30 2E 30 |
0020,0032 |
DS |
18 |
" -248.18759\0.0\0.0 " |
ImagePositionPatient |
|
20 00 37 00 18 00 00 00 31 2E 30 5C 30 2E 30 5C 30 2E 30 5C 30 2E 30 5C 30 2E 30 5C 2D 31 2E 30 |
0020,0037 |
DS |
24 |
“1.0\0.0\0.0\0.0\0.0\-1.0” |
ImageOrientationPatient |
|
20 00 52 00 00 00 00 00 |
0020,0052 |
UI |
0 |
FrameOfReferenceUID |
|
|
20 00 60 00 00 00 00 00 |
0020,0060 |
CS |
0 |
Laterality |
|
|
20 00 40 10 00 00 00 00 |
0020,1040 |
LO |
0 |
PositionReferenceIndicator |
|
|
20 00 41 10 04 00 00 00 30 2E 30 20 |
0020,1041 |
DS |
4 |
“0.0 ” |
SliceLocation |
|
20 00 00 40 00 00 00 00 |
0020,4000 |
LT |
0 |
ImageComments |
|
|
28 00 00 00 04 00 00 00 A8 00 00 00 |
0028,0000 |
UL |
4 |
168 |
Group Length |
|
28 00 02 00 02 00 00 00 01 00 |
0028,0002 |
US |
2 |
1 |
SamplesPerPixel |
|
28 00 04 00 0C 00 00 00 4D 4F 4E 4F 43 48 52 4F 4D 45 32 20 |
0028,0004 |
CS |
12 |
“MONOCHROME2 ” |
PhotometricInterpretation |
|
28 00 10 00 02 00 00 00 B3 02 |
0028,0010 |
US |
2 |
691 |
Rows |
|
28 00 11 00 02 00 00 00 00 02 |
0028,0011 |
US |
2 |
512 |
Columns |
|
28 00 30 00 12 00 00 00 31 2E 30 31 34 36 37 32 5C 31 2E 30 31 34 36 37 32 20 |
0028,0030 |
DS |
18 |
“1.014672\1.014672” |
PixelSpacing |
|
28 00 00 01 02 00 00 00 10 00 |
0028,0100 |
US |
2 |
16 |
BitsAllocated |
|
28 00 01 01 02 00 00 00 10 00 |
0028,0101 |
US |
2 |
16 |
BitsStored |
|
28 00 02 01 02 00 00 00 0F 00 |
0028,0102 |
US |
2 |
15 |
HighBit |
|
28 00 03 01 02 00 00 00 00 00 |
0028,0103 |
US |
2 |
0 |
PixelRepresentation |
|
28 00 50 10 06 00 00 00 2D 39 36 2E 30 20 |
0028,1050 |
DS |
6 |
“-96.0 ” |
WindowCenter |
|
28 00 51 10 06 00 00 00 39 37 31 2E 30 20 |
0028,1051 |
DS |
6 |
“971.0 ” |
WindowWidth |
|
28 00 52 10 04 00 00 00 30 2E 30 20 |
0028,1052 |
DS |
4 |
“0.0 ” |
RescaleIntercept |
|
28 00 53 10 04 00 00 00 31 2E 30 20 |
0028,1053 |
DS |
4 |
“1.0 ” |
RescaleSlope |
|
E0 7F 00 00 04 00 00 00 08 CC 0A 00 |
7FE0,0000 |
UL |
4 |
707592 |
Group Length |
|
E0 7F 10 00 00 CC 0A 00 41 FE 43 FE 43 FE 41 FE 44 FE 42 FE 41 FE 49 FE... |
7FE0,0010 |
OW|OB |
707584 |
41\FE\43\FE\43\FE\41\FE\44\FE\42\FE\41\FE\49\FE... |
PixelData |
文件中文件头中传输语法数据元素(0002，0010)的值是“1.2.840.10008.1.2” ，即DICOM默认的隐式值表示法(VR) Little Endian传输语法，因此数据集中每个数据元素中的值表示法都被省略，为阅读方便，上表中值表示法一栏用下划线标注以示区别。
在隐式值表示法(VR) Little Endian传输语法下，数据元素的格式为组号(2字节)、元素号(2字节)、值长度(4字节)以及值(值长度给出的字节数)。例如数据元素（08 00 16 00 1A 00 00 00 31 2E 32 2E 38 34 30 2E 31 30 30 30 38 2E 35 2E 31 2E 34 2E 31 2E 31 2E 32 00），2字节组号(08 00)表示组号为0008，2字节元素号为(16 00)即元素号为0016，4字节值长度(1A 00 00 00)为十进制26，表示此后的26字节为该数据元素的值。查数据字典得到tag(0008，0016)为SOP Class UID数据元素，默认值表示法为UI，即表示UID的字符串。将该26字节的值以字符串格式读出为“1.2.840.10008.5.1.4.1.1.2”，可知这是CT图像存储SOP类的一个实例。
对照前述的CT复合IOD定义，可见DICOM文件中的数据集并不是以IOD的信息模块的顺序来组织的，而是以其中的属性标记值(Tag)的组号和元素号从小到大顺序排列的。
七、DICOM的图像压缩
原始医学图像占用存储量大，在传输与存储过程中效率较低，必须使用压缩的方法来减少图像中的冗余信息，以达到在不损失图像信息或少损失的情况下，减少图像存储所需要的字节数，对于缩短通信传输时间，减少存储空间都是十分必要的。
压缩方法分为无损压缩和有损压缩两种方法。无损压缩方法可以将原数据原封不动地恢复，而有损压缩则是不可逆的过程，不能恢复到原来的情况。无损压缩由于对还原的约束，其压缩比较小，一般为2~10∶1。而有损压缩则可达到较大的压缩比，一般可以达到10~ 200∶1，甚至可以达到300∶1以上。根据被压缩对象的特点，无损压缩适合于对文本类的压缩，因为文本信息损失后不能表达出原来的意义。而有损压缩适合于语音、图像一类的多媒体信息，这些信息由人类的听觉和视觉器官所感受，有很大的冗余度，适当的损失对信息的理解并无损害，可以以此来达到较高的压缩比。
无损压缩使用的方法主要有游程编码(Run Length Encode，RLE)和霍夫曼(Huffman)编码。有损压缩的方法常用的是变换压缩，即将信息变换到另一个表示域中，利用在不同的域中的分布特点，去除冗余。例如通过富氏变换变换到频域，保存图像的低频部分，以损失一些细节实现压缩。再比如通过小波变换将图像变换到不同的尺度，保存不同区域不同尺度下的变换值，可以实现较高的压缩比。
在DICOM3.0中，提供了对JPEG、RLE、JPEG-LS、JPEG2000四种图像压缩算法的支持。JPEG是目前使用最广的静止图像压缩标准。在JPEG标准中，包含了有损压缩和无损压缩的多种方法。JPEG压缩的基本过程是被压缩图像分割成8×8的方格，先进行差分编码以减小码长，再用霍夫曼或算术编码进行无损压缩，或者用离散余弦编码进行有损压缩。JPEG允许编码器有不同的编码过程，这些编码过程用连续的编号表示，区别在于编码方案中的数据量化和采样精度不同。DICOM 标准采用了其中的4种：基本型(Baseline, 编号1)、扩展型(Extended, 编号2和4)和无损型(Lossless, 编号14)。JPEG标准实现的压缩比高，效果也不错。
RLE压缩由以下步骤组成：图像先转换为复合像素编码(Composite Pixel Code)序列，再产生字节片断集(Byte Segment)，每个字节片断经RLE压缩产生RLE片断，最后在串接的RLE片断前面加上RLE头。DICOM中采用的RLE编码算法如下：
对多个重复字节序列，用<-重复字节数+ 1><重复字节值>两个字节编码代替。
对非重复字节序列，用<字节数- 1 > <非重复字节序列>代替。
JPEG-LS压缩算法是一个国际标准，代号为 ISO/IS-14495-1。该标准定义了单一的有损(接近无损)编码过程，编码过程中通过限制绝对误差为零可以实现无损压缩。无损和有损(接近无损)编码采用基于统计模型的预测算法，在编码前先计算像素与周围像素间的误差并对其上下文进行建模，编码中平坦区域采用游程编码。这种压缩方式在无损模式下实现的压缩效果比JPEG的无损压缩过程好，同时复杂度较低。尽管JPEG-LS编码过程与JPEG规定的不同，但是编码比特流的所使用的语法却非常接近。JPEG-LS标准使用单一的编码过程可对最多16位比特深度的图像进行编码。
JPEG2000是一个新的图像压缩国际标准，代号为ISO/IS-15444-1。标准规定了应用程序间交换压缩图像数据的编码表示法的规范和实现指南，目标是在一个统一的集成系统中，可以使用不同的成像模式，对不同类型不同性质的图像都可以进行压缩。JPEG2000不仅解决了JPEG和JPEG-LS存在的不足，而且还增加了很多新的功能，其中感兴趣区编码、图像渐进式传输、运动(序列)图像压缩、三维图像压缩以及图像安全性都非常适合应用于医学图像。
不同的图像压缩算法就需要采用不同的传输语法。如JPEG基本型传输语法UID为1.2.840.10008.1.2.4.50，JPEG扩展型UID为1.2.840.10008.1.2.4.51，RLE为1.2.840.10008.1.2.5，JPEG-LS UID为1.2.840.10008.1.2.4.80，JPEG2000 UID为1.2.840.10008.1.2.4.90。
第三节 PACS的基本构成
PACS系统在物理结构上采用各种网络将不同类型的计算机连接起来，包括医学成像设备、图像采集计算机、PACS控制器(包括数据库和存档管理)、以及图像显示工作站，如图11-5所示。
图11-5 PACS系统结构框图
按照功能一般包括以下几个组成部分：
一、图像数据采集子系统
图像数据采集子系统包括成像设备和图像采集计算机。PACS的成像设备包括医院内各种用于诊疗的影像设备，如常规X线设备、CR、DR、CT、MRI、PET/CT、超声等。
成像设备的成像原理各异，图像属性亦有较大差异。通过图像采集计算机系统与这些成像设备进行通信，获取图像数据，并同时进行一些必要的预处理和信息格式的转换，最终以DICOM标准的格式将图像数据发送给PACS控制器。现代的成像设备通常都内置有图像采集和格式转换功能，直接以DICOM格式输出。
二、PACS控制器
PACS控制器是PACS系统的核心，它包括数据库服务器和存储管理系统两大部分。采集计算机和显示工作站通过网络与PACS控制器连接，把各种成像设备获得的图像送到存储服务器保存，并送到指定的显示工作站显示。PACS 控制器有下列主要组成部分：服务器平台、数据库软件、DICOM 服务器软件、数据管理与数据流软件、储存管理、预取和备份软件及其他辅助软件与硬件。
(一) PACS控制器的功能
1．图像接收与存档 各种影像首先在图像采集计算机中转换为DICOM格式，然后通过以太网或ATM送到存档数据库。PACS控制器使用客户机／服务器结构，可以同时接收多个采集计算机的图像数据。PACS控制器接收的图像数据暂时保存在服务器硬盘或磁盘阵列上，这样，显示工作站可以直接从服务器硬盘或磁盘阵列中快速检索图像，降低响应时间。
2．图像查询与检索 PACS服务器根据优先级对显示工作站的查询请求进行服务。根据应用需要给显示工作站确定不同优先级，如用于最初诊断、会诊和危重病房的工作站优先级最高。在工作站提出图像提取请求时，及时响应并将所需的图像传送到指定的工作站中。
3．图像预取 当PACS服务器收到来自RIS／HIS的ADT消息得知病人到达时，采用查表方式进行图像预取处理，即从PACS数据库和光盘库中选择历史图像、病人统计数据以及相关诊断报告，在病人检查结束前送到指定的显示工作站。预取算法根据预先定义的参数 (包括检查类型、断面码、放射科医生、相关医生、显示工作站地点、保存的图像数量和时间)来确定要提取的历史图像。
4．图像管理 到达PACS控制器的图像由暂存硬盘复制到光盘或磁带等离线存储介质上做较长期保存。复制完成后，PACS服务器将通知相应的采集计算机删除图像文件并释放存储空间。
5．与RIS／HIS接口 PACS控制器通过PACS网关计算机与RIS／HIS相连，RIS／HIS将病人人院、出院和转院(ADT)信息及时通知PACS，这样不仅能及时向PACS提供病人统计数据，而且能触发存档服务器进行数据预取、病案分组、盘片管理等处理过程。
6．PACS数据库更新 PACS服务器使用SQL语言实现数据处理，如数据插入、删除、选择和更新。PACS数据库使用多种表保存数据，如病人描述表记录病人统计数据，病案表记录每次放射检查过程，存档目录表记录每个图像的存储记录，诊断表记录每次检查的诊断报告。PACS服务器根据接收图像数据和RIS／HIS接口数据对这些表进行及时更新。
(二) PACS数据库
PACS数据库服务器为已经存档的图像文件建立索引，将图像文件按照病人、检查、序列、图像的四层信息进行规范化存储，以方便图像的管理和图像的检索。PACS 数据库的各种表在定义 DICOM 标准时都已经考虑到了。在DICOM 标准第三章的信息实体 (Information Entity) 和模块(Module) 对应的就是数据库里的信息实体和表。如：
1．Patient Module (DICOM 标准3.0版PS3.3 C.7.1.1)
2．General Study Module (DICOM 标准3.0版PS3.3 C.7.2.1)
3．Series Module (DICOM 标准3.0版PS3.3 C.7.3.1)
4．General Image Module (DICOM 标准3.0版PS3.3 C.7.6.1)
每个表里的属性DICOM 元素(Attributes) 是数据库表里的列 (column), DICOM UID (Unique ID) 就是数据库表里的主键（primary key）。一般来说DICOM图像的像素数据不直接存在数据库里的，而保留在 DICOM 文件里。
(三) DICOM服务器软件
DICOM 服务器软件是PACS 服务器的主要软件与核心部分。其主要功能是用 DICOM 3.0标准的存储服务（Store SCP）和其他相关服务来接收从影像设备、采集工作站、HIS/RIS 和终端送来的影像和其他信息。各种显示工作站可以向服务器索取影像资料，因此DICOM服务器软件必须支持相关服务，包括查询/检索图像 (Query / Retrieve) 、存储提交(Storage Commitment)、设备工作清单(Modality Worklist)、结构化报告(Structured Reporting)、灰阶图像显示状态(Grayscale Softcopy Presentation State)、悬片协议(Hanging Protocol) 等。
1．存储服务（Store SCP） DICOM Store 是 DICOM 标准中一个最简单而且最有用的子协议，其用途是将图像从一台机器传到另一台机器。Store SCU 是发送方，Store SCP 是接收方。Store SCP 是DICOM 服务器软件必备的一部分。DICOM 服务器收到一个图像后还有许多工作要做：如检验图像的 DICOM 正确性，在数据库表中添加该图像的 Patient (病人) 、Study (检查) 、Series (系列) 、Image (图像) 几层的信息，将图像文档存在数据库指定的地方等等。
2．查询/检索服务(Query/retrieve SCP) DICOM Query/retrieve是 DICOM 服务器的另一个必备的功能。其作用是让 PACS 工作站和影像设备查询和检索病人图像资料。
Query/retrieve 是三个不同的 DICOM 子协议的组合:C-Find, C-Move 和 C-Store。这部分软件与数据库的设计是紧密联系的，当 DICOM 服务器软件收到一个列表查询指令，它必须实时将其翻译成数据库的SQL命令来从数据库搜索资料，然后再翻译成 DICOM 发送回去。实现 C-Move 时，需要建立另一个 DICOM关联，服务器用 Store SCU 发送图像，工作站用 Store SCP 来接收。
3．其他DICOM 服务 PACS 服务器里常见的其他几个 DICOM 服务包括如下几项：
(1) 存储提交(Storage Commitment)：让图像发送方告诉 PACS 服务器全权接管所列的图像，发送方可能在本地删除这些图像。
(2) 结构化报告(SR)：通过 DICOM Store 来发送，但是结构化报告本身不是一幅图像，而是文字或图文报告。
(3) 灰阶图像显示状态(GSPS)：描述的是某图像或某序列图像在某工作站上显示时的窗宽窗位等灰度调节、图像标注和其他一些状态，以便以后显示时用同一套参数。GSPS 也是通过 DICOM Store 来传输的。
(4) 悬片协议(Hanging Protocol)：与GSPS有类似的地方，描述的也是图像的显示参数。所不同的是Hanging Protocol描述的不是灰度显示参数，而是某个检查或某个病人在不同时期的几个检查的图像在计算机屏幕上的排列格式。Hanging Protocol也是通过 DICOM Store 来传输送的。
(5) 成像设备工作清单(Modality Worklist)：设备工作清单与设备执行操作步骤是两个与工作流有关的 DICOM 服务子协议。影像设备从 PACS服务器获取该影像检查的病人和检查基本资料。这样就省去了重新输入病人基本资料的步骤。实际应用中也有将成像设备工作清单与RIS结合在一起，在RIS系统进行检查安排时生成成像设备工作清单。
(6) 设备执行过程步骤（Modality Performed Procedure Step，MPPS）: 影像设备或采集工作站用MPPS 通知 RIS/PACS服务器检查开始、检查结束等检查进展情况。当一个检查结束后将该检查从设备工作清单中删除。
(四) 数据流管理软件
PACS系统的工作流程的两个主要部分是影像归档存储（archiving）过程和影像的应用操作过程即所谓的软拷贝诊断执行过程（soft copy interpreting）。前者主要发生在影像设备和PACS服务器之间，其对PACS服务器的网络带宽和响应速率并不存在特殊的要求，仅对PACS服务器执行进程存在较大的数量和时间的压力。而影像软拷贝诊断过程，其主要的要求即为系统的响应速率，通常要求在尽可能短的时间限度内快速地完成一次诊断过程所需要浏览和操作的全部影像的过程，在不考虑影像软件执行速率的情形下，这一系列任务的完成过程的瓶颈主要在影像序列的检索和网络传输环节，这两个环节的速率均取决于PACS服务器的性能和网络端口的数据流量，集中式的PACS系统管理模式（所有影像工作站直接从中央服务器查询和提取影像）将很难为执行诊断任务的工作站群提供可靠的响应速率。
在引入影像数据流程管理过程后，影像诊断过程需要操作的影像序列的一个拷贝，在诊断过程开始之前，均已通过自动路由等影像自动迁移进程的执行完成了从PACS中央服务器存储位置向诊断过程执行位置迁移，当诊断过程开始时，所有影像的通讯和操作均被局限于本地存储或局部网络管理范畴，从而保证了在任何情形获取要求的系统响应速率的能力。影像工作流管理过程的引入，也会明显改善PACS全局系统网络带宽的使用和效率。 可靠而快速的系统响应，是PACS系统执行性能的基本指标，也是影像学软拷贝诊断过程的基本要求。
影像数据流程管理常采用下列技术：
1．影像预取(pre-fetching) 在病人检查开始前，自动将特定病人的历史影像数据迁移至优化的存储位置。
2．自动路由(auto-routing) 在病人检查结束后，根据特定的规则和逻辑将影像序列自动地送往某一指定的位置。
3．分级调度技术 从调度角度将PACS分为影像服务器、分中心服务器和影像工作站。影像服务器在接受病人影像后自动把影像传送到检查科室和病人所在科室影像分中心服务器中，分中心服务器在接受病人影像后自动把影像传送到本科室其他影像工作站中。由于科室医生浏览影像的实时性并不高，影像服务器完全有足够的时间在医生调阅前把病人影像传递到相应的影像工作站中。这样，科室医生可在科室任一影像工作站上从本地调阅所有病人影像。又由于采用分级调度的方法，可大大减轻影像服务器和网络的压力。
(五) 其它软件
1．存储管理和备份软件 PACS服务器对储存空间和备份要定期进行自动管理。这部分软件的设计也非常重要。如果医院的图像资料是通过几级的储存来管理，软件设计就更为复杂。最基本的，PACS 服务器要定期对比较老的图像进行压缩。如果储存空间不够，要自动找下一个本地或网络储存空间。所有资源到找过了还是没有，要通知网管。如果医院有网络存储或多级 PACS, 要能自动将旧的检查归档到网络存储，工作站需要时自动或半自动提取。
2．HL7 网关软件 医院管理信息系统(HIS)及放射信息系统(RIS) 与 PACS 的接口可以是单向的，也可以是双向的。PACS与 HIS 相连的主要益处是保证病人和检查基本资料的正确性和一致性，而且病人基本资料只需在 HIS 上输入一次。每当来了一个新病人或病人资料有了变更 HIS 可以通过 HL7 自动刷新RIS、PACS 的数据库；每次预约或更改了一个影像检查 RIS 会自动通过 HL7 通知 PACS。在检查开始时影像设备，可以用Modality Worklist 到RIS 查询病人和检查基本资料。检查做完后影像设备会用MPPS告诉 RIS 检查做完了。放射科医师在得知检查做完后可以马上开始影像诊断，并在 RIS或PACS中生成诊断报告。RIS 可以把病人检查的动态及时反映给 HIS，使得整个流程畅通。
三、PACS图像存储
图像存储是PACS的重要组成部分。PACS不仅需要海量的存储，而且对存取数据的能力和安全性也有很高的要求。随着信息技术中存储技术的发展，新的存储技术和理念已经渗入到PACS解决方案中来。
(一) 存储介质与存储设备
常用的存储介质有硬盘、磁盘阵列、光盘与光盘库、磁带与磁带库等多种。
1．硬盘和磁盘阵列(RAID) 硬盘和磁盘阵列是常用的在线存储设备。硬盘有多种规格、速度和容量。按照接口的不同主要分为IDE硬盘和SCSI硬盘，SCSI硬盘的存取速度由于IDE硬盘，但价格相对较贵。目前的单个硬盘容量可达数百GB，磁盘阵列技术将若干个硬盘组合起来作为一个硬盘来使用，可以达到数T级的存储容量，满足医学影像大容量在线存储的要求。由于应用了数据冗余技术，RAID增强了数据安全性，在单个硬盘出现故障的情况下不影响数据的使用。磁盘阵列的另一个显著的优点是提高了数据的存取速度，改善了磁盘的性能。
2．光盘与磁光盘 光盘存储技术在医学影像上应用已有多年。早期使用的是一次写入多次读出的WORM技术，记录的信息一旦写入无法更改。磁光盘(MO)的外形与3.5英寸软盘大体相同，磁光盘盘片主要是由用于记录信息的磁光薄膜组成。往磁光盘写入数据时，激光束照射加热垂直磁化的记录层，通过外加磁场的作用改变记录层的磁化方向，从而在盘片上写入数据。磁光盘有较大的容量（可达14G）,常用的是每张盘5.2G, 有较高的性价比。CD-R单张存储容量为650-700MB,可一次或多次写入，但是不能擦除；CD-RW则可以多次擦除重复写入。由于容量的限制，CD-R和CD-RW主要作为小型系统的离线存储与备份。DVD是一个应用电视标准和有多样化商业产品的新技术。DVD技术增加了存储空间并提高了读写能力，单面存储容量达4.5GB。蓝光(Blue Ray)技术更是达到了单面25G的容量。光盘库(塔)由一个或多个光盘驱动器（或光盘刻录机）及一组光盘柜组成，可以自动调换、加载柜中光盘的存储设备，适用于大量光盘数据的共享。
3．磁带和磁带库 磁带是一种低成本、可移动、顺序读写的存储介质。磁带介质不仅能提供高容量、高可靠性以及可管理性，而且价格比光盘、磁盘媒体便宜很多。磁带有多种类型，如4mm、8mm、1/4 inch、1/2 inch、travan等，较先进的技术有数字线性磁带(DLT)、可扩充线性记录磁带(SLR)、开放线性磁带(LTO)、先进智能磁带(AIT)等。单盘磁带容量为数十G到数百G，AIT 4技术甚至可达TB级的存储容量。磁带库是由一个或多个磁带驱动器和一组磁带盘柜组成，可自动加载柜中磁带的海量存储设备，容量可达数百TB。
(二) 三级存储结构
传统存储结构采用的是两级结构：在线存储和离线海量存储。在线存储采用高速数据存储设备，满足系统对图像数据访问的速度要求。离线海量存储主要是用于对在线存储的图像进行备份，以防范可能发生的数据灾难。
随着数据量的急剧增长，传统的两级模式已经越来越不能应对因数据膨胀而带来的许多问题。为了能够快速可靠地访问数据，就需要增加在线存储的投资，而通过数据备份来解决，就会对图像存储服务器的性能或服务时间产生影响。这就直接导致了近线存储的诞生。近线存储就是近似在线的存储，其特点是数据访问的速度接近在线存储，但在价格上接近离线海量存储。
1．在线存储 又称工作组级的存储，存储设备和所存储的数据时刻保持“在线”状态，是可随意读取的，可满足计算平台对数据访问的速度要求。如我们PC机中常用的磁盘基本上都是采用这种存储形式的。一般在线存储设备为磁盘和磁盘阵列等磁盘设备，价格相对昂贵，但性能最好。
2．离线存储 主要是用于对在线存储的数据进行备份，以防范可能发生的数据灾难，因此又称备份级的存储。离线海量存储的典型产品就是磁带或磁带库，价格相对低廉。离线存储介质上的数据在读写时是顺序进行的。当需要读取数据时，需要把带子卷到头，再进行定位。当需要对已写入的数据进行修改时，所有的数据都需要全部进行改写。因此，离线海量存储的访问是慢速度、低效率的。
3．近线存储 就是将那些并不是经常用到，或者说数据的访问量并不大的数据存放在性能较低的存储设备上，如存储性能稍低的磁盘（如IDE或SATA接口磁盘）、网络上的其他存储资源或光盘存储设备。对这些的设备要求是寻址迅速、传输率高。因此，近线存储对性能要求相对来说并不高，但由于不常用的数据要占总数据量的大多数，这也就意味着近线存储设备首先要保证的是容量。
在分级数据存储结构中，磁带库等成本较低的存储资源用来存放访问频率较低的信息，而磁盘或磁盘阵列等成本高、速度快的设备，用来存储经常访问的重要信息。数据分级存储的工作原理是基于数据访问的局部性。通过将不经常访问的数据自动移到存储层次中较低的层次，释放出较高成本的存储空间给更频繁访问的数据，可以获得更好的总体性价比。分级存储具有以下优点
1．减少总体存储成本 在传统的在线存储中，所有数据都存储在一线磁盘存储设备上，而由于绝大多数数据的访问率并不高，占住了大量宝贵的磁盘空间，在一定程度上是一种浪费。如果把这些数据转移到存储性能稍低的磁盘（如IDE或SATA接口磁盘）或网络上的其他存储设备上，存储成本可得以大幅降低。
2．提高整体系统性能 由于绝大部分数据转移到下级存储设备上，需要时刻保持在线的数据就少了，系统资源的占用也就少了许多，整体系统性能自然也就提高了。如果采用了离线存储方式对很少使用的数据保存在像磁带这样的离线存储媒体上时，则不仅可提高系统性能，还可确保数据的安全性。
但是随着近年来存储介质容量和价格的变化，以及PACS对存储的要求， PACS中的存储又重新倾向主要采用在线和离线两种方式，并不断呈现独立化、集群化和网络化的发展趋势。
四、PACS图像显示工作站
作为用户获取PACS图像的主要接口，图像显示工作站是PACS数据流中的最后一个组件。图像显示工作站由计算机硬件和工作站软件两部分组成。用户通过与它交户实现图像及其相关信息的查询和显示，以满足诊断、浏览或科研的使用要求。
(一) 显示工作站硬件配置和类型
图像显示工作站硬件由图像缓存和处理、显示、存储等三个部分所组成，工作站软件通过通信网络与PACS控制器通信。图像缓存和处理器用于实现图像数据到显示器的可视化转换，存储器要满足大容量、高性能的图像显示需要，工作站软件通过通信网络与PACS控制器通信实现图像到显示工作站的数据传送。
显示工作站应该有较高的处理能力和独立显卡。一般的显卡只能提供256个灰阶，因此作为诊断工作站时，通常配置有专业高分辨率、10-12bit医用显示器，需要相应地配置专用显卡，提供更高的灰阶数，满足临床诊断的要求。若要显示CT、MRI图像，可以使用2MP的显示器；显示CR、DR图像需要采用3MP的显示器，而显示乳腺钼靶片，则需要配置5MP的显示器。用于放射科医生或临床医生浏览病案及相关的诊断报告，对图像显示精度要求不高时，可使用1MP显示器。
显示工作站的存储设备不仅要求容量大，而且需要很高的数据输出能力，以满足图像处理和显示速度要求。为了加速从存储介质到视频显示的图像传输速度，图像显示工作站常采用大容量随机存储器(RAM)和磁盘阵列。RAM具有非常高的I/O速度，但价格贵，一般作为显示工作站缓存使用。磁盘阵列允许多个磁盘同时进行读写操作，其I／O速度大大提高。
(二) 图像显示工作站软件
PACS系统的一个突出优点是可以充分利用计算机和图像处理技术，增强图像的诊断价值。图像显示工作站除了具备数字图像的基本显示工具外，还提供了复杂的图像处理功能。基本工具包括图像的缩放、移动、对比度调整、翻转、量比测量和图像标注等，见图11-6。高级图像处理能力，除了滤波、勾边、消噪等图像处理工具外，还包括图像三维重构、图像融合、教学文件的生成等工具。
1．影像显示功能
(1) 查询与调阅：可根据患者的影像号、姓名、检查日期、检查部位、设备类型、设备明细、住院号、门诊号；典型诊断片语、检查报告片语、检查资料模式等进行综合查询和模糊查询，进行选择性的图像调阅。可边调图边显示，医生可以在1—2秒内进行工作。
(2) 显示模式：可以以检查、序列、图像等多种模式显示图像，便于图像的比较；可以拖拽任意检查、序列图像到指定的显示位置，便于对比检查。可设置单幅、2幅、4幅、9幅、16幅等显示方式，支持1～4台显示器。可以定义图像上显示的信息(病人名称、影像号、检查时间、缩放比率等)以及信息显示的位置。
(3) 缩放与移动：可按一定比例局部放大指定位置的影像或把当前的医疗影像最大化显示，也可平滑的放大、缩小整个医疗影像。可以把感兴趣部位的医疗影像移动到视窗中心，以方便医生的观察。
(4) 窗宽窗位：用于实现图像显示的灰度调节。灰度直方图中5％～95％范围内的最大灰度与最小灰度的平均值称为窗位，两者之差称为窗宽。窗位的选择范围分布在显示器整个动态范围内，减小窗宽将增大图像对比度。可预置不同设备、不同部位的经验窗宽、窗位值。
(5) 镜像和旋转：医疗影像左右、上下镜像对调。可以 ±90o或±180o的增值旋转医疗影像。
(6) 图像反转：使用查找表（LUT）通过数据求反可以实现图像黑白像素反转，图像反转主要用于确定体内异物，如ICU的X线透视检查胸内导管。
(7) 电影播放：速度可调、连续、循环播放序列医疗影像，便于观察时间先后不同的影像或者空间上相邻影像间的差异。
(8) 定位线显示：在CT等断层扫描影像显示中，可在正交图像窗口上显示定位线（scout line），标示该断层的位置。
图12-6 PACS图像显示工作站
2．影像处理功能 图像处理工具能增强图像效果，显示工作站的图像处理与采集计算机的图像预处理间的差别在于，采集计算机的图像预处理不会改变图像显示效果，而显示工作站的图像处理会加强图像的诊断信息，提高图像的诊断价值，包括以下处理工具。
(1) 直方图修正：是增强图像显示效果的有效方法，首先从原始图像求出灰度直方图，然后调整每个像素灰度以获得较好的显示效果。
(2) 图像勾边：通过显示最大灰度微分值增强图像显示效果。
(3) 边缘检测：在图像浏览过程中，需要对图像感兴趣区的平均灰度、形状和几何参数进行测量，测量前要确定ROI边界。边界检测过程分为两步：首先通过直方图或主观定义目标边界的灰度来确定灰度转折点，然后进行边界搜索。
(4) 去噪：放射图像中最常见的是灰度值随机分布的雪花点，可对图像进行局部平均处理消除这种噪声，但会使图像模糊，另一种方法是采用非线性处理过程，除了进行局部平均外，还检测与邻近点的显著差别。
(5) 滤波：可采用空间或频域这两种方法进行滤波，实现图像平滑。
3．辅助测量与标注功能
(1) CT、MRI值：测量图像上不同点的CT值或MRI值。
(2) 距离、面积和平均灰度测量：这是三种基本测量功能，距离是通过移动光标定义两像素点间的实际距离。面积和平均灰度测量要求用户首先确定ROI，然后计算ROI的面积和平均灰度。
(3) 标注功能：有箭头标注、直线测量标注、角度测量标注、文本注释、手画线、矩形、椭圆形、折线等多种标注功能，用来标识病变部位和测量信息。
4．诊断报告生成
(1) 报告书写：医生根据系统赋予的权限，阅读、书写或审核医疗影像报告。
(2) 报告审核：用拒签、批注等模式进行报告审核，便于初级医师的训练。
(3) 应用报告模板：根据患者的诊断部位调用已定义的典型报告模板，模板调入后可进行简单的编辑，快速生成影像诊断报告，支持ICDl0编码。
(4) 报告的打印和预览：在打印之前可以选择系统中已定义好的输出报告模板，以确定输出报告的形式。
5．胶片输出 DICOM打印功能，是PACS系统的重要功能之一，各种数字医疗设备生成的医学图像，最终要保存在系统服务器中，但患者的诊断图像，需要硬拷贝输出。该功能是将各种医学图像文件用DICOM网络打印机输出到医用胶片或医用打印纸上。
其主要功能应包括：选择要打印的图像文件，调入系统中，等待处理及打印输出；删除不需要打印的图像；调整图像的窗宽、窗位，进行图像的缩放、旋转、反向、位置等；可以进行打印效果预览；设置与DICOM打印机网络连接方式；设置输出图像的显示信息，设置打印参数、行数和列数等。
6．其它功能
(1) 计算机辅助诊断与三维重建：峰值时间测量、脑血流量测量、三维重建、虚拟内窥镜等先进的诊断算法，实现影像辅助诊断，以获得更准确的诊断依据。
(2) 对新协议的支持：随着医生对操作方便的要求越来越高，新版本的DICOM标准定义了悬片协议(hanging protocol)、灰阶软拷贝显示状态(grayscale softcopy presentation state)、打印查找表(print presentation LUT)等协议。
（郑建立）
作业11：
1． 什么是PACS? PACS具有哪些功能？
2． 传输语法定义了哪些内容？DICOM默认的传输语法是什么？
3． 试述数据集与数据元素的结构。
4． DICOM信息模型的四个层次是什么？
5． 什么是IOD？分为哪两类？
6． 什么是SOP？DICOM标准定义了哪些SOP类？
7． 什么是DIMSE? DICOM定义了哪些DIMSE服务？
8． 试述DICOM图像存储的通信过程。
9． 简述DICOM文件格式。
10． DICOM支持哪些图像压缩算法？
11． PACS系统由哪些组成部分？
12． PACS控制器的主要功能是什么？
13． 为什么要引入影像数据流程管理？通过哪些技术实现？
14． 什么是三级存储结构？分级存储有什么优点？
15． PACS图像显示工作站应具有哪些基本功能？
参考文献
1．ACR-NEMA. Digital Imaging and Communications in Medicine (DICOM).
2．RSNA/HIMSS. IHE Technical Framework Version 6.0. http://www.ihe.net
3．傅征，任连仲主编。医院信息系统建设与应用。北京：人民军医出版社，2003
4．陈克敏，赵永国，潘自来主编。PACS与数字化影像进展。上海：上海科技出版社。2005
5．丁宝芬主编。实用医学信息学。南京：东南大学出版社，2003
6．金新政，陈敏编著。医院信息系统。北京：科学出版社，2003
7．张凯，吕扬生。DICOM标准及应用。世界医疗器械. 7(5), 2001
8．JB Wang，PACS/RIS服务器与数据库设计。第三届全国数字化影像及PACS应用与进展研讨会论文集。上海，2004
9．贾克斌。数字医学图像处理、存档及传输技术。北京：科学出版社，2006
