医工互联

标题: PACS知识综合 [打印本页]

作者: 芷亦止兮 时间: 2023-2-20 10:38
标题: PACS知识综合
无论是在DICOM文件还是DICOM通信中，其信息都是由许多data element（数据单元)的集合所表示，每个data element表示一个属性，如病人姓名、图像类型等等。这些data element按照Tag值从小到大依次连接，类似于数据结构的链表或者数组(SQ类型有另外的编码方式,以后会讲到)，请看下图，一个data element包含四个字段Tag,VR,ValueLength,Value Field.
DICOMDIR 是一个可变长度迷你 database 文件。由 group (0002, xxxx) 和 group (0004, xxxx) 为主题。描述的是一个 4 层的树状结构 (tree structure)。
1. Patient
2. Study
3. Series
4. Image
将data element的数据结构编码为字节流时受以下几个因素影响:
1.传输语法： Implicit/Explicit VR,      BIG/LITTLE Endian
2.VR
当采用implicit VR时，其编码如下，这个时候是没有VR字段的，它采用data dictionary默认的VR.
DICOMDir结构的delphi实现
///
//
// Filename: uDICOMDIR.pas
//
// Summary:
//    DicomStation Source With Delphi7
//
// Modification History:
//    Date         By       Summary
//    --------     -------- ---------------------------------------------
//    07/24/2011   hegb     Original Creation
///
unit uDICOMDIR;
interface
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;
type
  //Instance Class
  TImageItem = class(TObject)
    NextDirRecordOffset: LongWord; //(0004,1400)
    RecordInUseFlag: Word; //(0004,1410)
    LowerLevelDirOffset: LongWord; //(0004,1420)
    DirRecordType: string; //(0004,1430)
    ReferenceFileID: string; //(0004,1500)
    ReferenceTransSyntaxUID: string; //(0004,1512)
    InstanceNumber: string; //(0020,0013)
  public
    constructor Create;
    destructor Destroy; override;
  end;
  //Series Class
  TSeriesItem = class(TObject)
    NextDirRecordOffset: LongWord; //(0004,1400)
    RecordInUseFlag: Word; //(0004,1410)
    LowerLevelDirOffset: LongWord; //(0004,1420)
    DirRecordType: string; //(0004,1430)
    Modality: string; //(0008,0060)
    SeriesInstanceUID: string; //(0020,000E)
    SeriesNumber: string; //(0020,0011)
  private
    ImageList: TList; //Image for this Series
  public
    procedure AddImage(pImage: TImageItem);
    constructor Create;
    destructor Destroy; override;
  end;
  //Study Class
  TStudyItem = class(TObject)
    NextDirRecordOffset: LongWord; //(0004,1400)
    RecordInUseFlag: Word; //(0004,1410)
    LowerLevelDirOffset: LongWord; //(0004,1420)
    DirRecordType: string; //(0004,1430)
    StudyDate: string; //(0008,0020)
    StudyTime: string; //(0008,0030)
    AccessionNumber: string; //(0008, 0005) /(0008,0050) ===== SH
    StudyInstanceUID: string; //(0020,000D)
    StudyID: string; //(0020,0010)
  private
    SeriesList: TList; //Series for this Study
  public
    procedure AddSeries(pSeries: TSeriesItem);
    constructor Create;
    destructor Destroy; override;
  end;
  //Patient Structure
  TPatientItem = class(TObject)
    NextDirRecordOffset: LongWord; //(0004,1400)
    RecordInUseFlag: Word; //(0004,1410)
    LowerLevelDirOffset: LongWord; //(0004,1420)
    DirRecordType: string; //(0004,1430)
    PatientName: string; //(0010,0010)
    PatientID: string; //(0010,0020)
  private
    StudyList: TList; //Study for this Patient
  public
    procedure AddStudy(pStudy: TStudyItem);
    constructor Create;
    destructor Destroy; override;
  end;
  //DicomDir Class
  TDicomDir =  class(TObject)
    GroupLength: LongWord; //(0002,0000)
    FileMetaVersion: string[2];  //(0002,0001)        ====OB====
    MediaSOPClassUID: string;  //(0002,0002)
    MediaSOPInstanceUID: string;  //(0002,0003)
    TransferSyntaxUID: string;  //(0002,0010)
    ImplementClassUID: string;  //(0002,0012)
    ImplementVersionName: string; //(0002,0013)
    FilesetID: string; //(0004,1130)
    RootDirFistRecord: LongWord; //(0004,1200)
    RootDirLastRecord: LongWord; //(0004,1202)
    FileSetConsFlag: Word;   //(0004,1212)
    DirRecordSequence: LongWord; //(0004,1220)     ====SQ====
    SOPClassUID: string; //(0008, 0016)
  private
    PatientList: TList; //Patient for DICOMDIR
  public
    procedure AddPatient(pPatient: TPatientItem);
    procedure ClearPatient;
    function WriteDicomDir(FilePath: string): Boolean;
    constructor Create;
    destructor Destroy; override;
  end;
function GetEvenStr(const str: string): string;
var
  g_pDICOMDIR: TDicomDir;
implementation
const
  GroupTagLen = 2;   //Group Number -- 2bytes
  ElementTagLen = 2; //Element Number -- 2bytes
//  VR2 = 2;           //Explicit VR时，如果VR = OB,OW,OF,SQ,UT,UN时，VR占用2字节
//  VR4 = 4;           //Explicit VR时，如果VR <> OB,OW,OF,SQ,UT,UN时，VR占用4字节
//  VR_Len2 = 2;       //Explicit VR时，如果VR = OB,OW,OF,SQ,UT,UN时，Value Length占用2字节
//  VR_Len4 = 4;       //Explicit VR时，如果VR <> OB,OW,OF,SQ,UT,UN时，Value Length占用4字节
var
  DICOM_signature: array[0..131] of byte =
    (
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0, 0, 0, 0 , 0,
       68, 73, 67 , 77
    );
  VR_Reserved: array[0..1] of Byte = (0, 0);
  ItemBegin_Group: Word = $FFFE;
  ItemBegin_Element: Word = $E000;
  ItemEnd_Group: Word = $FFFE;
  ItemEnd_Element: Word = $E00D;
  ItemEnd_Sequence: Word = $E0DD;
  ItemBegin_Value: LongWord = $FFFFFFFF;
  ItemEnd_Value: LongWord = $00000000;
  iOffSet: LongWord = 0;
procedure WriteDicomDir;
begin
end;
function SwapLong(Value: Cardinal): Cardinal;
asm
  BSWAP EAX
end;
function GetEvenStr(const str: string): string;
begin
  if Length(str) mod 2 <> 0 then
    Result := str + Char(0)
  else
    Result := str;
end;
第一讲 DICOM标准概述
一什么是DICOM？
DICOM是Digital Imaging and COmmunication of Medicine的缩写，是美国放射学会(American College of Radiology，ACR)和美国电器制造商协会(National Electrical Manufacturers Association，NEMA)组织制定的专门用于医学图像的存储和传输的标准名称。经过十多年的发展，该标准已经被医疗设备生产商和医疗界广泛接受，在医疗仪器中得到普及和应用，带有DICOM接口的计算机断层扫描(CT)、核磁共振(MR)、心血管造影和超声成像设备大量出现，在医疗信息系统数字网络化中起了重要的作用。
DICOM是随着图像化、计算机化的医疗设备的普及和医院管理信息系统，特别是图像存档和通信系统(Picture Archiving and Communication System, PACS)和远程医疗系统的发展应运而生的。当CT和MR等设备生成高质量的、形象直观的图像在医疗诊断中广泛使用时，由于不同的生产商不同型号的设备产生的图像各自采用了不同的格式，使得不同的设备之间的信息资源难以互相使用，医院PACS系统的实施具有很大的困难。医疗信息系统随之带来许多新的问题: 如何存储数据量极大的图像并能有效地管理？不同生产商的设备能否直接连接？如何能够在不同的生产商设备之间能够共享信息资源？等等。很明显这些问题的解决方法就是采用统一的标准。为此，美国放射学会和美国电器制造商协会在1983年成立了专门委员会，制定用于医学图像存储和通信的标准，提供与制造商无关的数字图像及其相关的通信和存储功能的统一格式，以促进PACS的发展，并提供广泛的分布式的诊断和查询功能。ACR-NEMA1.0版本于1985年推出，随后增加了新的数据元素并对部分内容进行修改，形成2.0版本。由于认识到标准对网络支持的不足和标准本身存在的结构性问题，ACR-NEMA结合当时的技术条件和方法对标准作了彻底的重新制定，在1993年正式公布了新的版本，命名为DICOM3.0。与原版本相比，3.0版本采用了面向对象的分析方法，定义了医学图像在存储和通信过程中的各种实体和关系，提供了对ISO-OSI(Inter-national Standard Organization-Open System Interconnection)和TCP/IP (Transmission Control Protocol / Internet Protocol)的支持，使得在医学图像应用层上可以与其它通信协议栈直接通信而不需要重新编写程序。考虑到技术的发展，标准采用了多部分的文档结构，对可能变化或扩充的部分以附录的形式提供，这样标准在更新时涉及面可以尽量小。
二标准中涉及的基本概念和定义
DICOM标准涉及到医学图像、数据通信、管理信息系统等领域，在标准中又采用了面向对象的描述方法和E-R (Entity-Relation)模型，从而引入了大量的各专业方面的术语，给标准的阅读和理解带来困难。下面简要地将标准中涉及的常用的技术词汇和缩略语给予解释。
1. 实体(Entity): 表示一个或一类有相同特性个体的应用对象。在计算机系统分析中，凡是可以区别并被人们识别的事、物、概念等，都可以被抽象为实体。实体一般具有若干特征，称为属性。如: 患者是一个实体，具有姓名、性别、年龄等属性。图像也是一个实体，它有图像尺寸、图像数据等属性。
2. 联系(Relation): 表示实体之间的相互关系。如患者实体与分析实体之间存在着引用联系，打印机实体和胶片实体之间存在着打印的联系。
3. E-R模型: 描述现实世界的一种信息模型。通过定义实体以及实体间的联系，表现系统的需求和功能。通常以E-R图的方式表示。在DICOM中，用方框表示实体，菱形表示联系，用带箭头或不带箭头的线段将实体(方框)与联系(菱形)连接表示它们之间存在联系。这是面向对象的分析方法所采用的主要表示方法，是对客观世界的一种抽象。
4. 对象(Object): 外部世界事物在计算机内部的表示，是事物属性值和处理方法的集合。对象具有封装和继承的特征。封装是指对象将属性和方法集合在一起，一般情况下只提供给自己和派生对象使用。继承是指当一个对象是由另一个对象(父对象)派生出时，它就自动具有父对象所具有的属性和方法。面向对象的方法就是以对象技术为中心，分析系统中各种信息之间的关系，抽象出系统各层次的对象模型，给出准确的系统描述，并在计算机系统中给予实现。应用面向对象的方法，可以提高开发效率，实现软件复用。
5. 信息对象定义(Information Ob-ject Definition，IOD): 信息实体的抽象，是DICOM命令的作用受体。
6. 服务(Service): 某对象为其它对象或程序提供的功能。当要求使用此功能时称申请服务，申请服务的对象称服务用户，而能完成该功能的对象是服务的提供者。
7. 服务对象对(Service Object Pair，SOP): DICOM信息传递的基本功能单位。包括一个信息对象和一组DICOM消息服务元素。
8. 协议: 计算机网络中为保证能正确地传输数据而必须共同遵守的通信规则和格式。
9. ISO-OSI: 国际标准化组织(ISO)所定义的开放系统互联(OSI)的七层网络参考模型。作为一个严格的网络模型，对于计算机网络的研究和发展起了重要的作用，但是由于种种原因在实际中并未得到广泛的普及使用。DICOM标准在制定时，OSI正是发展的高潮，因此也作为DICOM中主要的网络参考模型。
10. TCP/IP: 是传输控制协议/互联网协议，它首先在UNIX系统中使用，随后成为计算机网络中不同种类计算机之间通信的主要通信协议，是互联网的基础。
三标准的组成
DICOM标准是经历了一个从无到有、从简单到复杂的发展过程。在标准的制定过程中不断听取工业界、学术界、医疗界等各方面的意见和建议，注意标准的可扩充性和可扩展性，经历了ACR-NEMA 1.0和2.0的版本到目前的DICOM 3.0版本，标准的组成也在不断地加以补充，目前标准共有以下14个基本部分和扩充部分组成，见图1:
1. 第1部分: 给出了标准的设计原则，定义了标准中使用的一些术语，对标准的其它部分给了一个简要的概述。
2. 第2部分: 给出了DICOM的兼容性定义和方法。兼容性是指遵守DICOM标准的设备能够互相连接互相操作的能力。由于DICOM标准内容庞大，功能复杂，包含面广，目前为止，还没有什么设备能够涵盖所有的DICOM功能，只是实现本设备必需的功能。因此标准要求设备制造商必须给出本设备所支持的DICOM功能的说明，即兼容性声明。本部分标准内容定义了声明的结构和必须表现的信息，包含三个主要部分:
a. 本实现中可以识别的信息对象集合;
b. 本实现支持的服务类集合;
c. 本实现支持的通信协议集合。
标准没有规定兼容性实现的测试和验证的过程。用户在采购DICOM功能的设备时，必须注意各设备的兼容性水平是否一致，否则各设备互连时会出现一些问题。
3. 第3部分: 描述如何定义信息对象，对医学数字图像存储和通信方面的信息对象提供了抽象的定义。每个信息对象定义是由其用途和属性组成的。为方便标准的扩充和保持与老版本的兼容，在DICOM中定义了复合型和普通型两大类的信息对象类。普通型信息对象类仅包含现实世界实体中固有的那些属性。复合型信息对象类可以附加上并不是现实世界实体中固有的属性。如CT图像信息对象类既包含了图像固有的图像日期、图像数据等图像实体的属性，又包含了如病人姓名等并不属于图像本身的属性。复合对象类提供了表达图像通信所需求的结构性框架，使网络环境下的应用更加方便。
4. 第4部分: 服务类的说明。服务类是将信息对象与作用在该对象上的命令联系在一起，并说明了命令元素的要求以及作用在信息对象上的结果。典型的DICOM服务类有查询/检索服务类、存储服务类、打印管理服务类等。服务类可以简单理解为DICOM提供的命令或提供给应用程序使用的内部调用函数。这部分实际上说明的是DICOM消息中的命令流。
5. 第5部分: 数据结构和语义，说明了DICOM应用实体如何构造从信息对象与服务类的用途中导出的数据集信息，给出了构成消息中传递的数据流编码规则。数据流是由数据集的数据元素产生的，几个数据集可以被一个复合数据集引用或包容。一个复合数据集可以在一个“数据包”中传递信息对象的内容。这部分着重说明的是有关DICOM消息中数据流方面的内容。此外也定义了许多信息对象共同的基本函数的语义，即要求的条件、完成的结果、实现的功能等等。
6. 第6部分: 数据字典，是DICOM中所有表示信息的数据元素定义的集合。在DICOM标准中为每一个数据元素指定了唯一的标记、名字、数字特征和语义，这样在DICOM设备之间进行消息交换时，消息中的内容具有明确的无歧义的编号和意义，可以相互理解和解释。
7. 第7部分: 消息交换。消息是由用于交换的一个或多个命令以及完成命令所必需的数据组成，是DICOM应用实体之间进行通信的基本单元。这部分说明了在医学图像环境中的应用实体用于交换消息的服务和协议。
8. 第8部分: 消息交换的网络支持。说明了DICOM实体之间在网络环境中通信服务和必要的上层协议的支持。这些服务和协议保证了应用实体之间有效地和正确地通过网络进行通信。DICOM中的网络环境包括OSI和TCP/IP两种参考模型，DICOM只是使用而不是实现这两类协议，因而具有通用性。
9. 第9部分: 消息交换的点对点通信支持。说明了与ACR-NEMA2.0相兼容的点对点通信环境下的服务和协议。它包括物理接口、信号联络过程以及使用该物理接口的与OSI类似的会话/传输/网络协议及其服务。
10. 第10部分: 用于介质交换的介质存储和文件格式。这一部分说明了一个在可移动存储介质上医学图像信息存储的通用模型。提供了在各种物理存储介质上不同类型的医学图像和相关信息进行交换的框架，以及支持封装任何信息对象定义的文件格式。
11. 第11部分: 介质存储应用卷宗，用于医学图像及相关设备信息交换的兼容性声明。给出了心血管造影、超声、CT、核磁共振等图像的应用说明和CD-R格式文件交换的说明。
12. 第12部分: 用于介质交换的物理介质和介质格式。它提供了在医学环境中数字图像计算机系统之间信息交换的功能。这种交换功能将增强诊断图像和其它潜在的临床应用。这部分说明了在描述介质存储模型之间关系的结构以及特定的物理介质特性及其相应的介质格式。具体说明了各种规格的磁光盘，PC机上使用的文件系统和1.44M软盘，以及CD-R可刻写光盘。
13. 第13部分: 点对点通信支持的打印管理。定义了在打印用户和打印提供方之间点对点连接时，支持DICOM打印管理应用实体通信的必要的服务和协议。点对点通信卷宗提供了与第8部分相同的上层服务，因此打印管理应用实体能够应用在点对点连接和网络连接。点对点打印管理通信也使用了低层的协议，与已有的并行图像通道和串行控制通道硬件硬拷贝通信相兼容。
14. 第14部分: 说明了灰度图像的标准显示功能。这部分仅提供了用于测量特定显示系统显示特性的方法。这些方法可用于改变显示系统以与标准的灰度显示功能相匹配或用于测量显示系统与标准灰度显示功能的兼容程度。
四应用
毫无疑问，DICOM是医学图像信息系统领域中的核心，它主要涉及到信息系统中最主要也是最困难的医学图像的存储和通信，可直接应用在放射学信息系统(RIS)和图像存档与通信系统(PACS)中。DICOM也是研究和开发具有网络连接功能，实现信息资源共享的新型医疗仪器的技术基础。医疗仪器在朝着自动化、智能化发展的同时，也在向着具有通信能力的遥控遥测和信息远程获取的网络功能发展，医疗仪器既是医疗信息系统中的信息源，又是系统中的信息使用者，是信息系统中的一个主要环节，网络化的医疗仪器对医学信息系统的重要性是不言而喻的。
DICOM标准的另一个特点是它定义在网络通信协议的最上层，不涉及到具体的硬件实现而直接应用网络协议，因此与网络技术的发展保持相对独立，可以随着网络性能的提高而使DICOM系统的性能立即得到改善。DICOM尽管提供了OSI的网络模型，但现在实际上网络绝大部分都是在TCP/IP协议下构成的，网络硬件采用的形式可以多种多样，如100M的双绞线100Base-T，光纤FDDI，综合业务数字网ISDN，T1线路等，还有速度较低的10兆网10Base-T和电话线路。只要设备具有支持TCP/IP协议的网络接口，在软件的支持下，就可以做到像PC机一样实现“即插即用”，非常方便地加入到医学信息系统的网络中。在这样的意义下，用DICOM实现的医疗信息系统，无论是RIS还是PACS，都具有类似的结构，如图2所示:
在采用DICOM标准的信息网络系统中，所有DICOM设备之间都可以按照DICOM的网络上层协议进行互相连接和操作。临床医生可以在办公室查看B超设备的图像和结果，可以在CT机上调用核磁共振图像进行图像的叠加融合，也可以通过网络调用存储在其他医院的图像结果。无论是本院、本地还是相距很远的外地，DICOM设备都可以通过网络相互联系，交换信息。
由于提供了统一的存储格式和通信方式，普及DICOM标准，可以简化医疗信息系统设计，避免许多重复性的工作，加快信息系统的开发速度。对于实现无纸化、无胶片化的医院和远程医疗系统的实施将会起极其重要的作用
第二讲 DICOM信息模型和信息定义
第二讲 DICOM信息模型和信息定义
一概述
DICOM标准是要解决在不同的地点、不同设备制造商、不同国家等复杂的网络环境下的医学图像存储和传输的问题。要在这样复杂的情况下能够实现准确的无歧义的信息交换，当然存在许多技术问题，基本问题有语法和语义两大类。
所谓语义的问题就是指交换信息的具体含义。通常人们都是用自己的语言(称自然语言)进行交流，但世界上使用的自然语言种类繁多，还存在二义性问题，表达的意思存在多种含义，使得计算机处理有困难，这在医疗技术方面更是要解决的问题。因此DICOM中专门定义了自己的“语法”和“词汇”。DICOM的“词汇”是用一对整数表示的，称为标记(Tag)，用数据字典给出详细的定义和解释。另外用UID的方法给出唯一标识。
语法则是指信息组成的规则。在DICOM中，数据种类相当多，被分成各个层次，有信息对象定义(IOD)、消息(Message)、命令集、数据集、数据元素、传输语法等。只有通信双方按约定的统一的方法组织数据，才可能准确获得对方传输的信息。
下面就DICOM标准中数据定义、表示，以及组织所涉及到的概念和方法加以介绍，并通过一些具体实例帮助理解。
二数据组织形式
1. 唯一标识符UID
这个标识可被用在世界上不同地点的多制造商环境中。为保证每个标识的全球的唯一性，使用了下面的字符串(称为唯一标识符或UID)产生机制:
<根>.<后缀>
根部分是由权威部门支持的，它保证没有其他人或机构再使用这个根标识。这个数值由标准化组织分配给公司或医院，但也必须保证在它们自己内部网络中也是唯一的。通过使用一个唯一的系统标识，每个系统在世界范围内有一个唯一的根。后缀是由系统在产生实例时动态产生的。例如:
“1.2.840.113619.2.16.1.120.940 481283.2.61”是GE的心血管造影系统产生的一个UID。
一旦一个实例通过UID标识，必须一致地使用它。若制作了复件或未加修改的再生成，它必须使用相同的UID。否则相同信息的两部分将存在不同的标识，这会导致混乱。在DICOM中UID也用于标识有关的属性，如:
“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图像存储。
2. 标记Tag
标记是用一对16进制数表示的，前面的数是数据元素的组号，后面的是元素号。组号为偶数的是标准数据元素，具体含义可以在DICOM的数据字典中查到。DICOM的数据字典定义了许多数据元素标记，涵盖了大多数的应用需要。组号为奇数的为私有数据元素，由用户在使用过程中自己定义。
例如: 在DICOM中(0007，0000)表示组长，(0008，0020)表示研究日期， (0018，1088)表示心率。
3. 值表示法
DICOM标准中，对每个属性都定义了值表示法。值表示法具体描述了属性值如何进行编码。
值表示法有隐式和显式这两种形式。隐式就是采用预先规定的表示方法，通过标记从数据字典中查到DICOM对这个属性表示方法的规定，从而正确解释属性值的内容。显式是用两个字符明确表示值的表示方法，如AE表示应用实体，AS表示年龄字符串，DT是日期和时间，FD表示双精度浮点数等。
值表示法的知识是信息交换双方所共享的。对某个属性(以标记标识)的解码和编码过程必须仔细选择正确的值表示法。共享这个信息有两种可能的方法:共享包含所有可能属性的数据字典，或把数值表示法作为数据元素的一部分。后一种方法增加了信息交换的开销，但比用共享数据字典更灵活，尤其在多制造商环境，数据字典同步更新很困难。
4. 传输语法
在SOP实例数据集能被交换之前，数据集编码到字节流的编码方式是固定的，或者是网络交换中协商的，或者在介质上是与数据存储在一起的。编码方式由传输语法指明。
传输语法定义了三个方面的内容:数值表示法如何指定; 多字节数在存储或传输时的字节顺序，是低位字节先存储或发送(Little Endian)，还是高位字节先存储或发送(Big Endian); 封装情况下的压缩格式，是采用JPEG还是RLE的压缩算法，是有损方式还是无损方式等。
例如，对于一个32位无符号整数12345678H，在LittleEndian方式下的字节顺序为78、56、34、12，而在Big Endian方式下的字节顺序则为12、34、56、78。
传输语法的处理是服务提供方的一部分，但双方都要初始设置正确的对双方都可接受的传输语法。
传输语法是由一个UID标识的。DICOM默认的传输语法是隐式VR Li-ttleEndian传输语法，并采用无损方式的JPEG压缩算法。
5. 数据元素
数据元素是通过数据元素标记唯一标识的。一个数据元素包含了数据元素标记、值长度和数据元素值。数据元素的值表示法是否存在决定于协商的传输语法。对隐式VR 的传输语法，数据元素没有也没必要有值表示法域。而在显式VR下，存在表示长度方法上不同的两种形式。
数据元素有标准数据元素和私有数据元素两种类型。标准数据元素具有偶数值组号，私有数据元素具有奇数组号，自DICOM 3.0以后，数据组号并不传递任何语义上的含义。数据元素结构见表1。
数据元素中值域的字节长度必须是偶数个，不足的部分填充空格。
6. 数据集
数据集是由若干个数据元素组成，按数据元素标记中的组号以及元素号数值增加的方式进行排序，依次排列。一个数据元素在数据集内至多只能出现一次。但是在嵌套的数据集中可以再次出现。
显式和隐式VR在数据集精确嵌套数据集中并不同时存在，一个数据集是否使用显式或隐式VR以及其它特性，取决于传输语法的协商。
数据集的作用有两个:
(1) 作为信息对象定义IOD中的信息对象模块IOM;
(2) 作为信息交换中消息(Message)携带的数据内容。
三信息对象定义(IOD)
一个信息对象定义(IOD)是信息实体的集合，而信息实体是信息有关成分的组合。每个实体包含有关现实世界单个条目信息，如患者、图像等，称为属性。一个属性描述了信息某一特征，如患者姓名等。相互关联的属性组合到信息对象模块IOM中。IOM以数据集的形式出现，可以使用在多于一个IOD中。这些IOM具有属性的语义描述，可以组合到一起。
在DICOM中，一个IOD可以由单个信息实体(称普通IOD)或多个信息实体组合(称复合IOD)组成。实现管理功能(通常是单一条目)的服务类使用普通IOD，而那些处理图像数据流(具有复杂信息结构)的服务类使用复合IOD。
DICOM定义了在医学环境中所需的大部分的信息对象，详细规定了这些对象的组成格式、要求、相互之间的关系等等各方面的内容，如患者、CT、磁共振、核医学、超声等等，具体内容可参见标准的第三部分“信息对象定义”。
患者IOD是最基本的普通IOD，DICOM对其定义如下:
患者IOD:
● SOP公用模块
SOP类UID，SOP实例UID，特殊字符集，实例生成的日期和时间，生成者UID，实例号。
● 患者关系模块
引用研究序列，引用访问序列，引用患者别名序列。
● 患者标识模块
姓名，ID，issuer，其它ID，其它名，出生日，母亲生日，医疗记录定位。
● 患者人口统计信息
年龄，职业，数据保密限制描述，出生日期，出生时间，性别，保险计划代码序列，身高，体重，住址，军阶，服务机构，居住国家，电话号码，种族，宗教，注解。
● 患者医疗信息
医疗警告，对比敏感，吸烟情况，患者其它历史，怀孕情况，上次月经日期，特殊需求，患者症状。
作为一个复合IOD的例子，一个图像IOD的主要内容在图1中示意性表示。
四图像信息模型
DICOM图像信息模型是从放射科处理图像的方式中衍生出来的，它是基于来自不同形态方式上的假设，见图2。图像从多种形态上被收集到患者的病历中。患者病历中的图像是以检查的类型(与图像系列有一定的关系)排序。每一种形态类型的用户对这些排序都有自己的术语，如检查、运行、扫描、切片等。当不同来源的图像数据集合到一个单一的环境中，必须将不同来源的图像数据排序，这仅在所有图像数据依照同一个信息模型构造时才有可能。
在DICOM的信息模型上主要有四个层次，分别是患者、研究、系列和图像层次。这四个层次分别对应了相关类型的信息的生成阶段和不同来源。
1. 患者层次
患者层次包含属于某个研究的患者标识和人口统计信息。由于一个患者可能存在多个研究，患者层次是最高层次(当一个患者的所有信息被考虑时)。然而在通常的实践中是使用研究层次用于对单个的检查请求由不同系统处理的信息的收集。
2. 研究层次
研究层次是在信息模型中最重要的层次。一个研究是某个特定类型检查请求的结果。在一个放射科的所有活动都围绕着研究的正确处理。在研究层次上，保持着标识信息，并可以包含有与同一个研究有关的医院管理信息系统中的信息引用。
一般，一个请求可能会涉及不同形态的检查过程。这导致一个或多个图像的序列，取决于检查所定义的协议。研究作为“根”将所有图像数据收集到一起。一个患者可能由于其它或以前的检查而有多个研究。
3. 序列层次
在研究层次下收集了所有的图像序列。序列层次标识了生成图像的形态类型、序列生成的日期、检查类型的细节和使用的设备。
序列是来自单一形态有关图像的集合。图像组合到序列中的方式取决于它们的临床用途。而图像在形态上是如何获取的对分组并不重要。但是不同的属性将获取标识，并在显示图像时表现出来。
在许多情况下，图像关系是通过获取发生的方式定义的。当按顺序地获取具有空间或普通的关系时，这种获取结果的图像可以组成到一个序列中。当存在于图像之间的关系不再有效时，必须开始新序列。
4. 图像层次
信息模型的最低层次是图像层次，每个图像包含获取和位置以及图像数据本身，取决于方法的类型。图像层次包含有一幅(单幅)、两幅(双屏)和在相对短的时间内收集的多幅图像(多帧图像)。
多帧图像的使用节约了高层次上信息的重复，但这仅在帧之间关系可以用简单方法描述时才有可能。例如时间或系统移动的增量在所有帧之间都是相等的。
生成多帧图像比单帧图像更复杂，会消耗更多的资源。帧之间的关系、方法的能力、产生图像数据的数目，可用来确定是单帧系列还是多帧系列更适用。
五总结
本篇较为详细地介绍了DICOM中的信息定义和信息模型，通过这些内容可以了解DICOM标准对现实世界的信息是如何进行组织、表示和定义的，掌握这些内容是理解和实现DICOM标准的基础。

第三讲 DICOM消息交换和网络通信
正如DICOM标准本身的命名那样，DICOM标准要解决的一个主要问题就是网络传输，也就是在各种各样的网络硬件和软件的环境下，如何能够实现医学图像可靠地高效地传送到期望的目的计算机中。为此，DICOM标准采取的策略是在成熟的标准化的网络环境基础上增加对医学图像的支持，而不是从最低层开始定义，这样就可以直接利用现有的网络硬件和软件资源，促进DICOM标准的开发和应用。
一 DICOM网络的层次模型
在DICOM标准的制定中，主要采用了在实际中广泛使用的TCP/IP协议和影响较大的OSI网络协议，作为对DICOM网络支持的基础。在这两个协议之上分别定义了DICOM自己的基于消息的信息交换的上层协议DIMSE (Dicom Message Service Element)。为保持与以前版本的兼容，仍保留了对点对点打印的支持。DICOM网络的层次模型如图1所示。
在这个模型中，圆角框部分是DICOM标准中所定义的部分，虚线框表示具体的应用程序，由用户根据需求自行定义。方框部分则是在其它标准中所定义的，DICOM标准只不过直接使用。
应用程序与DICOM应用实体之间的应用程序接口(API)并不是在DICOM标准中说明，而决定于实现。一般这个API提供了对其它应用的连接，构造和处理SOP实例并传送到远方应用等这类函数。
对应用层，对应用实体提供了两组服务: 联系控制协议(ACSE)和DICOM消息协议(DIMSE)，它们都必须对DICOM实现有效。ACSE是一个标准的OSI协议。DIMSE的DICOM服务，是应用实体中提供的服务的一部分。
在ACSE和DIMSE应用之间的接口是DICOM标准中说明的DICOM接口。这个说明描述了对ACSE和DIMSE请求的每一个功能所要求的每一个参数，是DICOM应用上下文的一部分。
TCP/IP栈和OSI应用服务扩展的组合广泛地应用在通过网络来实现DICOM。由于TCP/IP没有定义高层，DICOM所要求的应用、表现和会话层功能在DICOM标准中组合为一个层，称为DICOM高层或DUL。
DUL对TCP/IP协议栈使用了相同的DICOM接口。在低层DUL具有与TCP层的接口。在应用实体之间的DICOM联系映射到一个TCP连接。表现地址映射到一个TCP端口号，与IP号或主机名相结合。这个IP号和TCP端口的组合称套接地址。在网络中这个组合是唯一的。
在DICOM 3.0版本中，点对点环境是为保持与以前版本的兼容而保留的。
二工作过程
对于一次DICOM的通信，具体过程为:
● 应用程序通过API发出DICOM功能服务要求
● DICOM服务器构造应用实体，将API参数放入应用实体上下文
● 应用实体根据上下文功能要求调用对应的DICOM上层服务功能
● DICOM上层服务将相关参数组成TCP包传递给TCP Socket
● 操作系统的TCP/IP服务通过物理网络将数据传送到目标计算机
● 目标计算机在接收到信息后，回送应答信息
上面的通信过程只是一个非常示意性的概要说明。由于在网络中会出现的情况非常复杂，实际的通信联络的过程和内容是繁琐而具体的。举个最简单的例子，我们在上一讲中介绍过传输语法，它规定了传送内容的编码方式、字节发送的次序、图像的封装形式等等。在两台计算机(网络中称主机)之间进行DICOM通信时，DICOM需要就传输语法进行协商，首先由通信的请求方使用默认的传输语法给出自己可以用的传输语法清单由对方选择，通信的另一方则根据自身的硬件和操作系统等软件情况选择合适的传输语法，并回答对方。这样就确定了在其后通信中所采用的传输语法。
传输语法的协商只是DICOM网络通信中的一小部分，还有很多其它方面内容必须在通信的联系过程中确定。具体可以查阅标准。
三数据结构
在DICOM的各个网络层次上，使用了多种数据结构，下面介绍主要的两个数据结构。
1. 消息 (Message)
在DICOM的网络接口中，信息是通过DICOM消息通信的。一个消息是由命令集与后面有条件的数据集复合而成的。命令集用来指明待完成的在数据集上的操作和通告。
命令集由若干个命令元素构成，命令元素包含有DIMSE协议指定语义的命令集中每个独立域中的编码值(见9.2和10.2)。每个命令元素由一个显式标记、值长度和值域复合而成。数据集我们已经在第二讲中介绍过，这里不再重复。DICOM消息的总的结构见图2。
2. 协议数据单元(Protocol Data Unit，PDU)
协议数据单元(PDUs)是在对等实体间交换的信息格式，它用于将DICOM消息经DIMSE协议发送到对方。一个PDU将由协议控制信息和用户数据组成。PDUs由强制固定字段和紧随其后的可选值字段构成，可选值字段包含一个或多个条目或子条目。DICOM UL协议由P-DATA-TF PDU、A-ASSO-CIATION-RQ PDU、A-RELEASE-RQ PDU、A-ABORT PDU等七种协议数据单元PDUs组成。A-ASSOCIATION-RQ PDU的结构可用图3表示
四 DIMSE联系协议
与其它通信协议一样，DICOM也使用了对等的观点对协议进行解释和说明。所谓对等的观点是指通信双方的操作是在同一个层次上进行，例如，在说明数据链路层的操作，就认为发送的数据是传送到对方的数据链路层，对方的回应信息也来自数据链路层，而不考虑接收方数据链路层再向上层的信息交换。
两个应用实体之间的用于信息交换的连接称为联系(Association)。对一个联系，许多通信内容都是作为上下文(Context)被确定的，其中的内容可以发生变化，这种变化实际上体现了信息的交换。在DICOM标准中定义了这个上下文(称应用上下文)，双方必须根据这个上下文的定义协调动作。
一个应用上下文用UID标识，并在联系初始化中传递到对方。通过比较应用上下文的UID，对方能够决定是否能够处理这个联系的请求。它可以为联系接受建立或拒绝它。
一个应用上下文覆盖了信息交换的全局功能。通过联系，哪一种类的信息交换能够发生是由SOP类和这些SOP类的服务类定义。联系的启动方建议的SOP将使用的类型、每个SOP类的SCU/SCP(服务类用户/服务类提供者)角色和信息的表示方式，取决于另一方的能力，它可以接受或拒绝每一个单独的SOP类。
经过这个协商过程，双方都知道对方的能力和限制。实际的信息交换能够根据服务类和SOP类角色(为这些类定义的)进行。当联系不再需要时，联系被终止。
在联系的初始化过程中，协商的每一个SOP类，必须在两个进程之间达成协议，涉及到两个进程之间使用的传输语法。启动方建议所有的特定SOP类能够处理的传输语法，另一方选择其中一个传输语法。经过协商双方SOP类都接受的表现上下文被确定。
一个表现层上下文通过双方都同意的数标识，称表现上下文ID。在一个联系的上下文中可能存在许多表现上下文。表现上下文ID标识了发生信息交换的SOP类。
以上联系中的信息都是封装在PDU中经过TCP/IP及物理层传送到对方的。
五结束语
DICOM的网络功能，采用了标准化的低层结构，有很好的应用基础，受硬件技术发展的影响小，能够在网络性能提高的同时直接受益。这使得支持DICOM功能的设备有较长的生存期，是医疗信息网络化的基础

第四讲 DICOM介质存储功能与文件格式
在上一讲中，我们介绍了DICOM标准中的网络传输功能，即利用通信线路进行DICOM信息交换。这一讲将介绍通过存储介质而进行的信息交换。将图像、诊断、检查的结果等信息存储在如软盘和光盘等存储介质中，实现在不同的系统之间在不同的时间内进行信息交换，也可以实现信息长久的保存。
通过介质进行信息交换，与通过通信信道进行信息交换，两者既有联系又有区别。它们都使用了DICOM的消息交换机制，但用介质实现信息交换时，交换信息的应用系统双方不是在同时工作，由此而带来与网络信息交换的不同之处。
一介质存储模型简述
在考虑了介质存储的情况下，DICOM的工作模型可以扩充为如图1所示。
从DICOM通用通信模型上可以看出介质存取模型也是具有层次性的，这三个层次分别为:
1.物理介质层
物理介质层定义了介质的物理特性，如: 物理介质格式参数、维数、机械特性、存储属性、及比特流信息的组织等等。例如，在PC环境下的3.5英寸双面高密软盘是DICOM标准中定义的一种物理介质，其相应的参数说明就是对应的物理介质层，它应该符合ANSI X3.171的规定，也就是通常使用的1.44M软盘。
2. 介质格式层
介质格式层是由操作系统决定的。它规定了存储介质上具体的数据组织形式以及文件系统进行的操作，它同时也定义了该介质上的目录结构。例如，一个3.5英寸的软盘在不同的操作系统中的数据结构是不同的。在MS-DOS及WINDOWS中，它采用的介质格式是FAT16格式的文件分配表，而在UNIX中使用的是超级块构成的链表。无论什么介质格式，它们都应该至少可以提供DICOM的文件服务功能，并且通过文件服务限制对文件内容的直接操作的权限，以确保DICOM数据格式层独立于介质格式和物理介质的选择。
3. DICOM数据格式层
DICOM数据格式层包括4个方面的内容: DICOM介质存储服务/对象对(以下简称SOP类)及与之相联系的信息对象定义、DICOM文件格式、DICOM介质存储目录SOP类、DICOM介质存储应用卷宗。下面分别详细说明。
二介质存储SOP类及信息对象定义IOD
介质存储服务类定义了一组用存储介质进行数据交换的服务。一般来说，使用存储介质有下面两个原因: 一是在两个进程之间交换的图像暂时存储在介质中，但没有有关处理的进一步说明，仅仅是传送信息而已。二是用于打印的图像是以胶片会话的方式来组织，接收进程必须处理介质中的打印管理信息，有关打印任务进展的状态信息也是在存储介质上反映出来。
在这个服务类中一个进程扮演的角色与在网络情况中是不同的。在网络中双方的角色有SCP和SCU之分，而在存储介质中只与介质上的操作有关。介质存储服务类定义了三种角色: 文件集生成者(FileSet Creator，FSC)、文件集读者(FileSet Reader，FSR)和文件集更新者(FileSet Updator，FSU)，显而易见，这些名字都是指允许的操作。
使用在这些服务类中的SOP类中的服务元素说明了在作为文件集或完全文件集管理的SOP类实例上的操作。这些服务使用的IOD定义了信息必须存储在一个文件中。这个信息可以是普通和复合对象的混合。
这个服务类仅处理一个文件中信息的存储，而不管其内容。例外的是有一个特殊的SOP类，介质存储中的目录存储类处理有关文件集和目录(DICOMDIR)的信息。
介质存储服务类的其它SOP类与用于图像数据的患者管理、研究管理、结果管理和打印管理网络存储服务类中的SOP类相同。存储在文件中的SOP实例能够由对应的SOP类的服务类在使用介质存储服务类的服务存取后直接使用。
三目录结构
除了DICOM影像及相关的SOP类(如诊断结果、病历信息)之外，还有其它用于管理介质存储的SOP类。这种SOP类就是DICOM标准PS3.4中定义的介质存储目录类。它们的实例就是相应的DICOMDIR文件。
由于在DICOM标准中规定了多种通用的存储介质，如容量为230M，650M，2.3G等光盘，这些大容量的外存储器，必须采用多级目录管理才能有效地使用。DICOM正是通过DICOM-DIR文件实现对多级目录管理的支持。
在一个存储介质上，DICOM的文件组织是按照患者、研究、序列、图像这四个层次进行的。患者、研究、序列具有目录的性质，可以根据需要选择，也可以省略，图像则是以最终的文件形式出现。
介质目录描述文件，即DICOMDIR文件，总体说明了整个介质上DICOM文件的层次性结构信息，在文件内部是通过子—兄节点的二叉树形式链接而成的(见图2)。
这样对介质中任何图像文件进行操作时，只要检索该目录文件即可得到文件的位置信息，由此对文件进行操作。
这种组织方式的优点是它与具体的文件系统的实现是独立的。操作系统中的文件子系统只要能提供基本的文件操作功能，即可实现逻辑上的患者—图像文件的层次结构，而不依赖于操作系统对多级子目录的支持。
四文件格式
DICOM文件提供了一种封装方式，将DICOM信息对象定义IOD的一个SOP实例以数据集的形式封装在一个文件中。数据集的字节流位于DICOM文件元信息之后，每个文件包含一个单一的SOP实例。这个实例包含有一帧或多帧图象。
1.DICOM文件元信息
文件元信息包括已封装的数据集的标识信息。文件头由128字节的预定义的引导加4字节DICOM前缀以及表1中介绍的文件元信息构成。每个DICOM文件均有这样一个文件头。
预定义文件头可以根据应用卷宗或实现实例的要求灵活应用。DICOM标准对这个固定长度的预定义头没有任何结构性的要求，它不必像DICOM数据元素在结构上要有一个标识和长度信息。这是为了让DICOM文件数据易于和许多通用计算机图像格式相兼容。无论预定义头是否包含信息，DICOM文件格式应当遵循这部分要求。而数据集中的内容则应当与文件元信息所表述的SOP类相一致。
如果预定义头没有被应用卷宗及实现实例使用到，此128字节应当被置为00H，以便于识别此128字节是否载有应用信息。例如，这个预定义头可能用来向一个多媒体应用程序进行授权以决定其对DICOM数据集内影像的操作权限。这样在同一个文件上可以有两种操作方式: 利用预定义头的多媒体应用程序，和忽略这个预定义头的DICOM应用。
DICOM四字节前缀应当包含特征字串DICM(大写且字体采用ISO8859-G0字符集，即常用的ASCII编码)，这四个字节没有标识及长度信息。预定义头及词缀后是一系列DICOM元元素。它们包含标识及长度信息，具体含义见表1。
2.数据集的封装
在DICOM介质存储应用中，每个文件应包含描述唯一的一个SOP实例的数据集。这个SOP实例属于某个SOP类以及对应的IOD，如一个研究、序列或存储等。
正如特定的IOD可以被定义为多帧一样，一个文件可能包含有一个以上的影像帧，由SOP 实例中具体内容确定。用于数据集中的编码必须是DICOM文件元信息中传输语法UID标识的那一种。
由于DICOM数据集内并不包含它的长度信息。DICOM文件服务提供的文件结束提示是数据集结束的唯一标志。
3.文件管理信息的支持
DICOM文件格式不包含文件管理信息，为的是不与介质格式层发生功能上的重复。如果一个特定的DICOM应用卷宗需要，介质格式层应包括下列信息:
文件描述表自身的信息; 文件入口的统计(如创建时间、日期); 应用程序文件权限控制; 物理权限控制(如写保护)。如同我们前面所说，介质应用层是由操作系统实现并提供的。
当前版本的DICOM标准不涉及介质及文件权限控制服务之外的介质交互安全性的控制。特定的介质格式层可能支持这种安全性机制。超越物理介质层及介质格式层安全性的管理需求，将体现在新的有关介质存储的DICOM标准中。
五介质存储应用卷宗与可用的存储介质
介质存储应用卷宗定义了应用系统对DICOM介质存储模型中不同层次的选择，目的在于满足使用介质进行信息交换的特殊需要。这种选择由规范化的介质存储应用卷宗来表述，DICOM标准要求具体实现之间的介质信息交换必须遵循系统的介质存储应用卷宗。这种一致性的描述允许用户对不同的实际系统进行选择，以保证系统之间的互操作性。
介质存储应用卷宗一般包括以下内容:
(1) 用应用卷宗表达需求的描述及其应用的上下文。
(2) 数据格式层的选择。
(3) 介质格式层的定义，DICOM标准中规定了可供选择的物理介质、介质格式以及介质格式(或称文件系统)服务如何映射到DICOM文件服务。
(4) 选择合理的传输语法。
(5) 其它一些有助于互操作性的特殊限制，如: 文件最大长度支持的选项等。
最后我们将DICOM标准目前所支持的可交换存储介质的种类及有关内容归纳为下表，以供参考

第五讲医学图像的信息组织及其表现
如同我们前面所介绍的那样，DICOM是有关医学图像的标准。前面介绍了图像在存储介质和通信环境下的交换，本讲主要介绍有关图像的组织和表现方面的内容。
所谓表现(Presentation)是指图像数据在显示设备或胶片上完成可视化的过程。它要求在不同的系统，不同特性的设备上达到一致的显示效果，即视觉等价。这样才能保证临床应用上的要求。
为此，DICOM标准规定了相应的图像信息组织和处理功能。下面分别作介绍。
一图像编码格式
对于图像的描述，DICOM采用的是位图的方式。即逐点表示出其位置上的颜色、亮度等信息。对单色图像只有亮度信息，称灰度级。而对彩色图像则存在不同的颜色表示方法。一般采用的是RGB三原色的表示，即一个点用红绿蓝三个分量的值表示。DICOM允许用三个矩阵(称位平面)分别表示三个分量，也允许仅用一个矩阵表示整个图像，在这种情况下，矩阵中每一点是由三个值组成的。
对于一个象素值，DICOM称为采样值(Sample value)。采样值的描述方法用三个数据元素给出，分配位数(Bits Allocated)指出了该采样值存储的二进制位数。存储位数(Bits Stored)指实际占用的位数。最高位位置(High Bit)指明该值最高位在分配的存储单元中的位置。
例如: 某CT中的图像象素存储格式如图1所示: 则分配位数为16位，存储位数为12，最高位为11。
必须说明的是，在实际存取图像数据的时候，还必须由传输语法中的Big-Endian或LittleEndian属性来决定象素高低字节的实际存储单元地址顺序。当然，在DICOM标准中还存在许多说明图像的其它属性，可以参考标准的具体内容。
DICOM对多帧图像的支持，是通过将多帧图像封装在一个象素数据元素(Pixel Data)中实现的。由帧数属性(0028，0008)指出。
二压缩方法简述
原始医学图像占用存储量大，在传输与存储过程中效率较低，必须使用压缩的方法来减少图像中的冗余信息，以达到在不损失图像信息或少损失的情况下，减少图像存储所需要的字节数，对于缩短通信传输时间，减少存储空间都是十分必要的。
压缩方法分为无损压缩和有损压缩两种方法。无损压缩方法可以将原数据原封不动地恢复，而有损压缩则是不可逆的过程，不能恢复到原来的情况。无损压缩由于对还原的约束，其压缩比较小，一般为2~10∶1。而有损压缩则可达到较大的压缩比，一般可以达到10~ 200∶1，甚至可以达到300∶1以上。根据被压缩对象的特点，无损压缩适合于对文本类的压缩，因为文本信息损失后不能表达出原来的意义。而有损压缩适合于语音、图像一类的多媒体信息，这些信息由人类的听觉和视觉器官所感受，有很大的冗余度，适当的损失对信息的理解并无损害，可以以此来达到较高的压缩比。
无损压缩使用的方法主要有游程编码(Run Length Encode，RLE)和霍夫曼(Huffman)编码。有损压缩的方法常用的是变换压缩，即将信息变换到另一个表示域中，利用在不同的域中的分布特点，去除冗余。例如通过富氏变换变换到频域，保存图像的低频部分，以损失一些细节实现压缩。再比如通过小波变换将图像变换到不同的尺度，保存不同区域不同尺度下的变换值，可以实现较高的压缩比。
由于涉及到医疗责任和法律的原因，西方医疗界对医学图像的有损压缩采取了相当谨慎的态度。反映在DICOM标准中，主要推荐使用无损压缩的方法。具体讲，使用了简单的RLE和JPEG标准中的无损压缩算法。
游程编码RLE有很多形式，在DICOM中采用的编码算法如下:
对重复字节，用< -字节数+ 1><字节值>代替。
对非重复字节，用< 字节数- 1 > <非重复字节序列>代替。
用RLE压缩方法封装的图像格式如图2。
JPEG是目前使用最广的图像压缩标准。在JPEG标准中，包含了有损压缩和无损压缩的多种方法。JPEG压缩的基本过程是被压缩图像分割成8×8的方格，先进行差分编码以减小码长，再用霍夫曼或算术编码进行无损压缩，或者用离散余弦编码进行有损压缩。JPEG标准实现的压缩比高，效果也不错，由于算法比较复杂，这里就不给出详细的说明，具体的内容可以查阅有关文献。采用JPEG无损压缩的DICOM的唯一标识符是“1.2.840.10008.1.2.4.70”。
三灰度显示
来自图像的数字信号可以被精确地和有目的地测量、描述、传送和重建。然而，信号的可视化解释依靠于显示图像时所用的不同特性的系统。因此，由相同信号产生的图像在不同的显示设备下可能会有完全不同的可视化表现、信息和特征。
在医学图像中，重要的一点是保持在各种已给数字图像表示时的一致性，而不管这个图像是否被观察。例如，在一个工作站的视频监视器上显示，或作为幻灯片播放，它们都应该保持一致。如果缺乏规范，不能形成在不同设备下图像可视化表示的标准，那么极有可能出现这样一种现象: 即一幅图像在某一设备下观察时，有非常好的诊断价值; 但是在另一设备上观察时却与前者大不相同，这样就大大地减少了其诊断价值。因此，DICOM为将数字图像值转换至不同层次的亮度值的描绘方法提供了一种有目的的、高质量的机制，若将这种方法应用于已知数字图像值和显示亮度之间的关联时，则无论是在各种性质截然不同的显示设备上显示都能够产生较好的视觉一致性。DICOM所定义的存在于数字图像值和显示亮度之间的关系是基于人类对于较大范围亮度的理解而产生的模型和测量标准，而并非基于任一种图像显示设备或是任一种图像格式的形态特征描述，它也不依赖于用户的个人喜好。因为它很容易被其它诸如DICOM查找表之类的结构所正确的调用。DICOM标准使用了人类的视觉系统的BARTEN模型来处理图像数据，达到视觉一致性的目的。
DICOM从数学角度定义了标准图像系统中的标准灰度阶显示函数。这些图像系统可以是打印硬拷贝的打印机，或是用于显示软拷贝内容的电子显示系统。硬拷贝既包含透射性的图像，也包含反射性的打印图像。这些打印件中的图像，在被重现时由于传输过程中的散射型反射的影响，将在图像上有光密度的差异。对于一个观察者来说，它所看到的图像中每一个具有一定亮度的象素都是图像元素的照明度和光密度所决定的。软拷贝由发射性显示系统(如CRT监视器)和电子光阀系统(如光源型和液晶显示系统)产生。
DICOM的目的是显示系统采用数字驱动层次产生亮度和光密度的变化来表现图像。图像传输的可预测性应用，如形态、有价值的数值(VOL)和查找表LUT等，都需知道显示系统的特性曲线。若将显示系统的响应函数及曲线标准化，就可使在不同的显示系统中传输图像(如在一个网络环境中传输图像)变得简单而易用。
图3和4阐明了标准灰度显示函数的内容，标准灰度显示函数是图像表现的一部分。在采用灰度显示函数之前有很多其它图像修饰的环节。图像的获取设备将在图像产生的同时对图像作适当的调整。而其它环节将产生一些窗口或是层次来为图像的表现选择各部分的动态范围。即使其它环节能够调节显示准备工作中所选取的动态区域。表现查找表LUT输出P值(表现值)。这些P值就成为了标准显示系统中的数字驱动层次(DDL)。标准灰度显示函数将P值映射到标准显示系统中的亮度的对数值。而标准显示系统所产生的这个映射过程是由其独立完成的。
在图像获取的DICOM模型、显示链和标准化显示系统之间的边界上，用P值表示时，便趋向于设备的独立化和概念上的视觉线性化。换一句话说，不管标准化显示系统的性能如何，相同的P值范围都将表现得非常相似。
DICOM的主要目标是从数学的角度为所有的图像表现系统定义一类合适的标准灰度显示函数。定义这类标准灰度显示函数的目的是允许去发掘早先P值怎样被转换为标准化显示系统中可观测的亮度值。在本质上，定义灰度阶标准显示函数固定了来自LUT显示的P值输出的单位，而且还能够用作标准化显示系统的数字驱动层次。
DICOM的第二目标是选择一个显示函数，这一函数能够提供对于已给定的图像在不同亮度级的显示系统和非常容易使用的可求得的显示系统的数字驱动等级之间的灰度感知度或基本表示的几个相似的层次。在许多其他函数能够为实现第一目标而服务的同时，这个灰度阶显示函数便能被选取去实现第二个目标。对于这一类函数，P值几乎是线性的与人类感知反应度相关。相近却并不保证有同样的信息内容。拥有更大亮度区域范围和(或)更高的亮度的显示系统将有能力展现更多的细微差异。
由于感知度是依靠与图像内容和观测者的主观想法两方面的因素而定的，因此，亮度差异对于一个观测者来讲，同样不能严格的遵循感知度的绝对线性化。为了达到绝对的线性化感知度，应用时必须通过在DICOM标准(例如: VOL和LUT显示)中所定义的某些方法来调整图像的表现以符合用户的期望值。如果没有这个已定义的显示函数，那么在网络上遇到这类基于范围更广、类型更多的显示系统的调节问题时，这一切将变得很复杂，处理起来也相对困难。
显示系统的特性曲线与标准灰度显示函数的特性曲线一般说来是不同的，这些设备可能会包含合并的方法，特别是那些在变换中定义的能够使设备与灰度阶标准显示函数达到一致的那些方法。DICOM为这些显示系统的测试形式提供了实例。这些显示系统一般都有这样一个特点，即他们的性能工作能够被标量，其过程与标准灰度显示函数的评价相似。
DICOM没有详细规定用于彩色图像的特定显示函数。
四结束语
图像是DICOM标准的核心，除了以前介绍的图像存储和图像传输外，图像的表现也是一个相当重要的内容，它涉及到使用者对图像的最终感受，进而影响到对图像的理解和对疾病的诊断。
规划、引进和构建PACS及RIS系统是一个系统工程，其不同于医学成像设备(如CT、MR、CR等)的引进，对国内大多数医院及其医学影像学科而言，执行PACS及RIS系统的规划、设计和论证过程，仍然存在相当的难度和较多不易把握的环节。
在正式的PACS规划和引进过程，通常的步骤是先产生一个需求方案文档，称为RFP(Requirement For Proposal)，作为指导整个系统引进过程的纲领文件。当在需求方案中充分地规划和定义了医院和影像学科信息化过程所可能要求的主要系统需求，然后按此方案完成系统的引进和构建，这是成功地实现医院医学影像学科信息化建设的可靠保证。
　　但是,完成一个真正有价值的RFP,要求对所规划的信息系统(如PACS系统)设计的技术层面以及相关领域的知识和技能具有相当程度的了解和掌握,否则将难以使RFP真正具有确保系统成功实现的纲领性指导文件的职能。
　　RIS系统亦是医院最重要的医学影像学信息系统之一，其与PACS共同构成医学影像学信息化环境。尤其是近年来DICOM标准向RIS管理域的扩展，以及IHE(Integrating The Healthcare Enterprise)对医学影像学环境的信息流管理模型的定义，为医院对RIS系统规划定义了更深层次的需求。对用户而言，其关键点在于，必须将医学影像学信息化环境作为一个整体进行设计和规划，这应该成为成功实现医院医学影像学科信息化建设的基本要求，因此，RIS系统的规划也应该顺理成章的成为RFP基本内容之一。
　　下面把在国内医院环境中，执行PACS和RIS系统规划、设计、购买和构建过程可能需要考虑和论证的主要环节，或者说建立医院PACS和RIS系统需求方案应该关注的问题和要求做一个概括的说明和介绍，希望能对医院医学影像学科信息化过程提供有价值的参考。
一、 PACS系统
1. 影像采集设备(Modality)：
　　影像采集设备的引进和购买虽然并不包括在PACS的引进和购买范畴，但影像设备作为PACS系统的数据采集前端，是PACS系统规划和购买过程必须予以考虑和论证的部分，因为PACS系统必须顺利地实现与纳入PACS系统管理框架的现有(或将购买的)影像采集设备间的连接和数据通讯。在PACS规划和购买过程对已装备或将要装备的影像采集设备需要进行两方面的论证，即DICOM标准遵从和影像通讯连接(Connectivity)的论证。
1) DICOM标准遵从论证：下述需求除了应用在PACS规划和购买过程，也同样可以作为新的影像采集设备购买过程的需求规划。需要确认的DICOM SOP支持类型及其执行功能描述如下：
基础DICOM SOP遵从：

DICOM SOP支持	角色	功能执行描述
Storage*	SCU	将DICOM影像从成像设备传送(push)至支持DICOM Storage SOP(作为SCP角色)的PACS系统设备(如PACS服务器或PACS工作站)
Modality Worklist	SCU	直接从支持DICOM Worklist SCP的RIS系统获取患者的人口统计学信息(姓名/ID/年龄等)及检查相关信息，自动完成影像检查设备控制台端的数据登录过程
Modality Performed Procedure Step (mPPS)	SCU	执行向RIS系统(及PACS系统) 传递和更新影像检查过程及检查状态信息，通常作为与Worklsit SOP执行过程匹配的操作过程
Storage Commitment	SCU	在影像远程存储过程中通告和传递影像存储执行过程及状态信息，通常是在应用Storage SOP实现影像归档存储(archiving)过程中执行
Print Management	SCU	执行从成像设备或PACS设备经网络将影像送至DICOM打印机完成影像打印输出过程

扩展的DICOM标准遵从：

DICOM SOP支持	角色	功能执行描述
Storage*	SCP	接受从其它支持DICOM Storage SCU的成像设备或PACS系统设备(如PACS工作站)回传的影像
Query/Retrieve	SCU	直接从支持DICOM Query/Retrieve SCP的PACS系统设备(如PACS服务器或PACS工作站)查询及提取DICOM影像(pull)

* 最基础的要求是至少提供对该成像设备所产生的影像类型IOD的存储(Storage)执行过程的支持，譬如，成像设备为CT机，则至少要求支持CT Storage SCU, 如果为MRI设备，则至少支持MR Storage SCU.
　　一般的情形，90年代中期以后的数字化成像设备可以提供Storage SCU支持，并通常为设备的标准配置，具体遵从细节应该以该设备附带的DICOM Conformance Statement陈述文档描述为准。90年代末以后多数提供商已将Modality Worklist SCU作为其影像设备的标准配置，近年来，将mPPS和Storage commitment SCU作为标准配置的影像设备也逐步增多；扩展的DICOM标准遵从所列项目，一般情形设备提供商多将其作为成像设备的选配项，对设备的规划提出这类需求可能会增加投资，因此医院应根据实际需求决定是否执行这类功能规划。
2) 影像通讯连接(Connectivity)：
　　a) DICOM影像设备的连接和通讯：在典型的PACS影像工作流，影像应该从影像采集设备直接传送至PACS服务器完成影像的归档存储过程，即是说，DICOM影像设备在逻辑上应该是直接与PACS服务器连接和通讯，因为DICOM Storage SCU是影像采集设备最基础的DICOM标准遵从项，而对DICOM Storage SCP的支持也是PACS服务器的最基本的要求和属性，因此，在PACS系统的网络拓扑中DICOM影像采集设备直接与PACS服务器通讯并完成影像的归档存储过程(archiving)，成为必然的要求。对于某些PACS提供商的系统拓扑中DICOM影像设备的影像经过某类专用工作站或所谓”DICOM网关”后再转接至PACS服务器的系统构型，用户在规划和引进过程中有必要对此提出疑问并进行审慎的论证。
　　b) 非DICOM影像设备的连接和通讯：对于90年代中期以前的不能提供DICOM标准支持的影像设备，完成与PACS系统的连接和通讯需要采用一类称为”DICOM网关”的转换设备或软件完成非DICOM影像至DICOM影像的转换后再传送至PACS服务器完成归档存储过程。因此，存在这类情形的医院在考虑PACS系统的规划和购买时，应该将”DICOM网关”的论证列入规划范畴。通常采用的”DICOM网关”执行方式主要包括以下几种方式：
　＊软件升级：要求成像设备提供商执行影像设备软件升级，完成对DICOM影像输出的支持。如果投资状况允许，这应该作为首选的方式，其通常可以获得标准的DICOM IOD(如CT IOD或MR IOD)类型输出，但此种软件升级方式通常价格较为昂贵。
＊专用的DICOM网关设备：部分影像设备商可以提供专用的DICOM网关设备，用于将非DICOM影像设备接入PACS系统，采用这类专用网关设备也可以获得较为可靠和效率较高的DICOM影像转换，但对国内多数医院可能也同样存在价格承受力的问题。
＊视频采集转换：这里的视频采集转换指通常由PACS系统商提供的DICOM网关解决方案，由视频采集卡和转换控制软件组成。优点在于一旦该非DICOM设备淘汰后，该网关仍可应用于其它具有视频输出的影像设备(如B超等)，缺点在于影像质量缺乏标准的控制手段以及采集操作可能存在不便。
　　其它的影像格式转换方式也有通过(如FTP)获取影像采集设备的非DICOM影像后，直接执行影像格式转换操作获取DICOM影像后输出。这类方式其用户获得的网关软件模块仅对应于用户环境中某一特定的成像设备的影像类型，而这类影像设备多已接近淘汰年限，一旦该设备停止使用，其应用的DICOM网关软件很难直接应用于医院的其它设备，其投资的效用也随之终止。从这个意义而言，医院在规划过程中对于应用此类DICOM网关的方案需进行充分的论证和权衡。
2. PACS服务器管理系统(包括工作流管理和接口系统)
　　PACS服务器管理系统的规划和购买论证可能需要包括以下几方面的内容：
1) DICOM标准遵从：完整的遵从应该包括通讯、数据库设计和影像媒质存储格式管理三个层次分别提供对DICOM标准第8部分(通讯)、第6部分(数据定义)和第10部分(Media Storage/File Format)定义和规范的全方位支持。
a. DICOM通讯：
　　　基础的DICOM SOP遵从：

DICOM SOP支持	角色	功能执行描述
Storage*	SCP	为DICOM影像提供归档存储服务，接受来自支持DICOM Storage SCU的PACS系统设备(如影像采集设备或PACS工作站)的DICOM影像
Query/Retrieve	SCP	为支持DICOM Query/Retrieve SCU的PACS系统设备(如PACS工作站)提供影像查询和调取服务
Storage Commitment	SCP	在影像远程存储过程中执行影像安全存储的能力的确认以及通告影像完成归档存储过程的状态信息传递

* 至少应该提供对DICOM标准定义的全部影像IOD的Storage SCP的支持
b. 数据库设计：
　　　DICOM标准第6部分(DICOM Dictionary)对执行DICOM标准规范的操作和处理过程可能涉及的数据类型、属性等做了相当详尽的定义，PACS(也包括RIS)系统数据库设计提供对DICOM标准第6部分的数据定义的遵从和支持，是保证系统在医学影像学信息化环境中始终具备良好的适应性和兼容能力的基础。如果一个PACS提供商的系统产品数据库设计不能对DICOM Dictionary(DICOM标准Part 6)所定义的数据类型及其属性提供充分的支持，在用户环境实际的应用中，譬如在执行某些新的SOP(如新的影像类型)执行过程中，该数据库很可能将出现不兼容和匹配问题，这类问题可能迫使PACS提供商不得不对其数据库执行改动操作，显然，这种情形对PACS产品的用户存在潜在的危险和不利。但如何确认PACS提供商的系统数据库具备对DICOM Dictionary定义的遵从，作为用户端的医院较难获得确定的信息和证据，或许可能的处理方式是要求PACS商承诺其提供对医院医学影像学信息化环境中可能涉及的全部数据类型的兼容能力。
c. 影像媒质存储格式管理
　　　在影像存储和存储管理格式方面提供对DICOM标准的完整遵从，对用户存储的数据的持续有效性是至关重要的，这应该被视为最高层次的数据安全需求。简言之，在影像存储格式管理方面提供对DICOM标准的完整遵从，可以确保对医院而言至关重要的影像数据的安全和有效性不会依赖于特定的系统提供商，即便系统提供商的系统产品或其维护支持服务过程因各种原因不能持续，医院不得不对已有系统的部分或全部进行更改或更换时，系统已积累的全部影像数据信息仍然可以导出至新的系统管理框架内，从而保证医院的数据资料管理的连续性和持续有效性，不致于因提供商或其产品的原因被部分”丢失”甚至完全废弃。
　　　具体的要求，包括两部分：(1) 要求PACS提供商在影像数据存储格式管理上保证提供对DICOM标准第10部分的完整遵从，包括媒质存储支持DICOM File-set定义和DICOMDIR格式管理；(2) 要求提供并执行DICOM标准定义的压缩算法。某些系统提供商执行自己专有的压缩算法，虽然其声称可以实现更高倍率的无损压缩，但是，这样的结果是完全窒息了DICOM标准遵从提供的开放性特征，使医院的影像数据的导出完全依赖于特定系统提供商的软件执行过程(解压缩过程)，这显然使影像数据的持续有效性面临着潜在的危险。
　2) 在线存储系统及设备规划
　　影像归档存储(Archiving)是PACS的基本任务及功能要求，存储管理模式和应用设备的选择等，对系统的响应速率存在着显著的影响，同时，影像存储设备及其管理系统部分也是影响PACS总体投资的主要因素。因此，对PACS系统存储管理设备的规划应该予以相当的重视。
　　典型的PACS存储模式和管理流程通常分为在线(Online)、近线(Nearline)和离线(Offline)存储及管理。医院在规划PACS系统时应该要求系统提供商对影像数据在上述三种状态存储管理模式间迁移过程的控制和维护能够提供自动执行和管理的能力，这是PACS服务器管理过程的基本要求。
　　通常情形，在线存储用磁盘阵列实现，一般采用RAID-5构型，以提供良好的容错能力、较高的数据读取速率及最大的磁盘空间利用率。近线存储目前多采用光盘库(CD/DVD jukebox)或磁带库(DLT jukebox)实现，推荐采用前者。磁带库存储管理对环境要求较高，为保证数据存储的可靠性和良好的读取能力，可能需要对数据磁带执行定期的转录和重写操作。影像数据位于在线或近线存储位置可以执行不需人工介入的自动查询和影像自动迁移、转存，离线存储指影像数据存储媒质单元(如光盘、磁带等)被放置于与系统分离的存放位置，系统不能执行离线存储媒质上的影像数据的自动读取操作过程，需要人工介入操作。
　　通行的PACS系统存储架构为”磁盘阵列+光盘库(或磁带库)”模式，这种模式比较好地兼顾了近期影像数据(在线存储)的快速响应能力、中远期影像的自动读取操作能力和对投资水平实施适当控制这三方面的要求。在线存储成本较高，应根据用户的投资水平设计合适的在线存储间期，从而完成最贴近医院实际情形的PACS存储管理解决方案。
　　近年来，随着磁盘阵列成本价格的显著降低，尤其是性价比较好的”SCSI to IDE”模式磁盘阵列在技术上的成熟，为PACS存储方案提供了一个非常具有吸引力的选择。医院现在可以用接近普通PC存储的投资，获得性价比非常高的磁盘阵列在线存储，基于这类磁盘阵列，医院可以从容的规划PACS系统的”完全在线”存储方案，即能够以逐年扩展在线存储(磁盘阵列)容量的方式，真正实现所有影像全部处于在线状态，为系统的快速响应能力提供完全的保障，同时，因所有影像均为在线状态，仅需配置简单的光盘刻录设备(CD/DVD-R)作为影像数据”备份”解决方案即可，省去传统PACS存储方案中昂贵的光盘库或磁带库投资，使系统整体投资水平和执行效率都可同时获得优化。因此，推荐在PACS系统在线存储方案规划中选择”磁盘阵列-CD/DVD-R”并执行影像全在线存储管理模式。
　　另一类低端的PACS存储解决方案是基于普通PC机配置硬盘的简单存储方式，这类方案虽然有投资水平低的长处，但PC系统的不稳定、PC硬盘读写I/O的响应速率限度等都不同程度的制约了这类存储方式的性能发挥。虽然PC存储也可以基于操作系统实现RAID-5类的容错构型，但其效率受系统资源等因素的限制也影响其性能的提升。因此，基于普通PC的存储方式应用于中等规模以上的PACS系统存储存在着较多的不利因素。
3) 影像工作流管理能力
　　PACS影像的应用操作过程主要是医学影像的诊断浏览过程，这个过程的特殊性在于一次操作和处理的影像数据容量巨大，即影像诊断过程不仅需要操作当前检查的影像序列，同时常常需要操作同一患者既往多次(多种)检查的全部影像，而这些影像的存储或响应位置可能在本地硬盘，也可能位于远程(如PACS服务器)系统的在线或近线存储内，甚至位于多个不同的存储管理系统管理域内。这种情形决定了要获得较高的系统响应速率，单纯依靠PACS系统的影像在线存储和扩展网络带宽都难以满足需求，这就是近年发展起来的PACS影像工作流管理(Workflow Management)进程所要承担和实现的任务。
　　目前比较通行的PACS工作流管理进程包括自动路由(Auto-routing)、影像预取(Pre-fetching)和影像预载(Pre-loading)等。只有真正有效地运用了特定的影像工作流管理进程，才能可靠地保证PACS影像诊断过程所要求的执行效率和响应速率。
　　因此，推荐医院在PACS系统的规划中对影像工作流管理进程提出具体的需求，以确保PACS提供商的相关产品可以满足医院对系统响应的特定要求。
3. PACS工作站系统
　　 PACS影像工作站的规划和购买论证可能需要包括以下几方面的内容：
　　 1) DICOM标准遵从
　　　基础的DICOM SOP遵从：

DICOM SOP支持	角色	功能执行描述
Storage*	SCU	将DICOM影像从工作站传送(push)至支持DICOM Storage SCP的PACS系统设备(如PACS服务器或其它PACS工作站)
Query/Retrieve	SCU	从支持DICOM Query/Retrieve SCP的PACS系统设备(如PACS服务器或其它PACS工作站)查询或调取DICOM影像(pull)
Print Management	SCU	执行影像从工作站经网络送至DICOM打印机完成影像打印输出过程

*应该要求提供对医院当前或今后可能操作的影像IOD类型的Storage SCU支持
　　这里需要说明的是，PACS影像工作站DICOM标准遵从的规划并非必需的项目。对PACS影像工作站提出DICOM标准遵从的要求往往预示着投资额度的增加，对每一项DICOM标准遵从的增加在多数PACS提供商的产品都可能要求额外的付费，减少工作站对DICOM标准遵从的项及数目则预示着投资额的降低。因此，医院在执行PACS系统的论证和规划时，有必要对每一台/组PACS工作站必需的DICOM标准遵从项进行恰如其分的评估和研究，以期提出一个可满足医院及医学影像学科正常工作流程执行中对影像工作站DICOM标准遵从的基本需求。
　　PACS影像工作站通讯的对象主要为PACS服务器，如果医院的影像学科采用同一PACS提供商的产品完成系统构建任务，PACS工作站与服务器、工作站与工作站间的通讯通常不必执行速率较低的DICOM通讯，而可以通过提供商内部定义的通讯方式实现更有效率的影像数据交换。但是，考虑到医学影像学科环境往往存在着其它第三方网络系统资源(如影像采集设备、后处理工作站等)，以及影像学科的发展和系统今后的扩展都可能引入第三方系统设备，因此，至少应考虑一台影像工作站具备必要的DICOM标准遵从，以便为当前应用的PACS系统提供一个基于工作站途径的与第三方DICOM标准遵从系统及设备执行通讯和数据交换的接口方式。
　　PACS工作站对于DICOM Print Management SCU的支持，可以为PACS系统硬拷贝输出提供一个便捷的执行方式，但是，工作站具备执行影像胶片打印输出能力使任何具有工作站影像操作权限的人均可执行影像的胶片硬拷贝输出过程，这可能增大医学影像学科的胶片输出管理难度，这些因素都需要在医院执行PACS系统规划过程中予以考虑和权衡。
　2) 工作站构型和配置的规划和考虑
　　　主要是两个方面的规划和考虑，即显示分辨率和工作站配置构型选择。
　　显示分辨率是一个需要慎重考虑的问题。在目前的工作站硬件技术水平状态下，选择较高的分辨率预示着投资额可能会显著地增加，因此，基于国情的设计，可能需要根据医院的实际投资水平确定一个既能满足基本诊断要求又不至于显著增加医院的投资压力的PACS工作站显示分辨率规划方案。根据ACR(America College of Radiology)标准，对PACS诊断工作站显示分辨率要求分为两类，一类是Small matrix images如CT/MR/RF/DSA等，显示分辨率512×512×8bit可满足诊断要求，即普通PC机配置的彩色显示器应可基本满足分辨率需求；另一类称为Large matrix images，如CR/DR影像，ACR对分辨率要求的定义为1024×1024×10bit，这需要专业的灰阶显示器才能达到这一参数指标。但专业的灰阶显示器昂贵的价格所造成的投资压力对于国内大多数医院可能都存在着承受力问题，作为变通的解决方式医院虽可以采用宽屏的彩色显示器(分辨率通常可达1600×1200×8bit)作为替代方案，但建议投资水平允许的医院尽可能保证至少规划一套标准的灰阶显示器以便确保复杂病例影像的诊断和会诊质量。
　　在工作站配置构型的选择上，由于医学影像诊断的执行和完成过程同时涉及PACS和RIS系统的的操作，即PACS和RIS系统工作流程在此环节需要被物理地集成在同一位置，因此，影像诊断工作站的配置和构型应该适应这一需求，并能够提供优化的执行方式使诊断医师可以方便地进行PACS和RIS系统相关软件模块的操作。单机双屏(一台主机配置两台显示器)的工作站构型应该是一个较为可取的配置，其可以为诊断医师提供同时执行RIS诊断报告过程和PACS软拷贝影像浏览过程的能力，同时双屏也可以提供较之单屏更大的影像浏览和显示空间，有利于诊断过程的操作和执行。目前通行的计算机操作系统如Windows 98、Windows 2000和Windows XP均可容易的实现单机双屏构型配置。推荐医院在进行PACS工作站规划时选择单机双屏的影像工作站构型。
4. 医学影像浏览服务系统
　　现代PACS的管理和应用范畴已经扩展至整个医院信息化环境，PACS影像除了应用于影像学科的影像诊断过程外，另一个重要的应用领域是为医院临床诊疗过程提供网络化的医学影像学支持服务。现在通常采用Web方式(Intranet方式)实现，即在PACS系统框架内建立一个提供医学影像及其相关信息浏览服务的Web服务器，为医院整体信息化环境提供影像、影像检查及影像诊断报告的查询和浏览功能。
　　医院在执行PACS的影像浏览服务系统规划过程时主要需要着重关注以下几个方面：
1. 影像流程设计与DICOM标准遵从：根据不同的影像数据流程考虑可能要求影像Web服务器提供不同的DICOM SOP遵从，通常情况下应该支持下述DICOM SOP执行：
　　a) Storage SCP：应该要求支持医院信息化环境中可能应用的全部DICOM影像IOD类型的Storage SCP。执行　Storage SCP可以接受来自PACS服务器的DICOM影像，即放射科PACS的影像可以通过DICOM通讯迁移一个拷贝至Web服务器管理环境。
　　b) Query/Retrieve SCU：执行DICOM Query/Retrieve SCU使Web服务器可以直接向PACS服务器查询并提取需要的影像。
2. 影像格式及压缩方式的考虑：影像格式通常有两种选择，一是直接提供DICOM格式影像浏览；另外一种选择是将DICOM影像转换为JPEG等普通影像格式后提供浏览。推荐采用DICOM影像浏览方式，因为DICOM影像可以为浏览者提供更为丰富的患者及影像相关信息和操作功能。从减轻医院信息化环境网络干带宽压力以及保证浏览效率考虑，影像浏览服务通常需要对影像采用适当倍率的压缩(有损压缩)后提供浏览，从安全的角度而言这也是必要的，目的是使这类向整个医院信息化环境开放(共享)的影像不同于作为医疗档案存储的PACS服务器管理的原始影像。如果可能，应该强调用户可以自定义影像的压缩倍率，以便可以容易的选择提供适宜影像质量的压缩率。
3. 集成RIS系统的相关信息和数据：除了提供影像的浏览服务以外，影像检查相关的信息如诊断报告、检查状态信息等，也应该可以通过该Web服务提供浏览服务，这要求提供商能够同时集成PACS和RIS的数据信息。
4. 影像数据浏览过程的用户安全控制(影像工作站的控制和用户权限的管理)：影像在医院整个信息化环境的共享，实际上相当于在一定程度上对公众环境开放，因此，是存在着安全问题的。目前通常采用的基础安全管理方式包括两类，一是影像浏览工作站侧的控制，即通过软件管理的途径仅允许指定的工作站执行影像浏览操作；另一个方式是用户注册及权限管理，即只允许通过专门管理的用户注册程序执行注册过程的用户能够执行影像浏览操作。这两者的结合，可以在一定程度上提供安全的保障。
5. 临床影像浏览要求的显示分辨率及工作站配置：根据ACR标准，临床影像浏览过程采用常规的PC显示器分辨率可以满足需求，因此，对影像浏览工作站通常没有特殊的要求。但是，由于操作的数据是医学影像，常常要求同时对数十帧以上的影像执行操作和处理，因此，这类影像浏览工作站宜配置足够的系统资源(如CPU、内存及网络接口带宽等)。
二、 RIS系统
　　 RIS系统的规划对医院及其医学影像学科是一个需要予以相当重视的内容，这是因为RIS系统的引进和执行是医学影像学科信息化环境建立的关键组成，换言之，完成影像学科传统的管理模式向数字化、计算机化管理模式的转换过程，主要有赖于一套解决放射科整体工作流程的RIS系统的建立以及成功运行。
　　RIS系统的规划应该强调两点：(1)流程化系统管理。要求对放射科整体工作流进行管理、控制和操作，而不是简单操作以工作站为中心的相对独立执行的功能模块；(2) 相关标准及规范的遵从和执行。现在讨论RIS系统的规划，存在两个不可回避的内容，即标准(DICOM/HL7)遵从及IHE流程方案的执行能力。
1. IHE流程方案及标准(DICOM/HL7)遵从
　　IHE流程方案的支持及标准(DICOM/HL7)遵从对现代RIS系统规划有相似的含义，因为IHE定义的流程模型的基础主要是通过标准(主要是DICOM和HL7标准)的执行完成数据信息在医院信息化环境(着重在影像学环境)中优化的执行和通讯。医院用户执行RIS系统规划时，应重点要求和考虑两点：
1) 要求提供必要的DICOM SOP支持和HL7接口通讯能力。DICOM SOP遵从方面，现阶段至少应该提供Modality Worklist SCP和Modality Performed Procedure Step SCP的支持；HL7支持方面，在RIS-HIS通讯界面应该能够提供双向(送出和接收)数据通讯的HL7接口能力,在RIS-PACS层面至少能够提供单向(RIS至PACS)的HL7通讯接口。
2) 要求具备持续地跟踪并执行IHE流程方案的响应能力。IHE的流程方案的定义是一个动态变化和增长的过程，RIS提供商要具备跟踪并快速响应和执行新的流程方案的能力，除了对发展状态和动向的把握以外，更重要的是需要对医院尤其是医学影像学科工作流程执行的特点和需求的理解和把握。真正做到了对这类流程的理解，软件的实现是比较容易的。由于IHE流程方案的发展是一个动态的过程，在医院用户环境中的RIS系统的执行(包括运行管理、功能操作过程以及工作流程模型的设计和调整等)也应该是一个动态的过程，医院在规划时应该对此予以关注和考虑。
2. 系统整体工作流程管理
　　RIS系统的规划，必须强调实现对医学影像学科整体工作流程执行过程的管理，即在对影像学检查实际流程中的各个环节的操作和处理上具备专门的功能模块设计的基础上，同时应强调系统对各功能模块执行流程化的集中控制和管理，即集中式管理模式，软件架构通行采用Server/Client模式。集中式的管理使RIS常规工作流程中的各执行环节的操作容易实现有效控制，同时亦能可靠地保障不同功能模块之间的数据交互和通讯执行的效率.
3. 其它相关因素考虑
1) 系统用户化过程：RIS系统是一个用户化需求相当突出的信息管理系统，一则因为其关联的信息管理流程较多(PACS系统及医院环境其它信息管理系统)，同时，不同层次和规模的医院均可能存在着大量个性化的流程执行和应用惯例方面的特殊要求。因此，医院在规划RIS系统时，应该对自己的具有个性化和特征性的一些运行操作和管理模式做到心中有数，并在拟就的需求规划方案中予以强调和体现。由于用户环境对RIS系统的需求存在着动态变化的特点，因此，有必要要求RIS系统提供商具备动态地响应用户变化和新产生的需求的能力；从RIS系统的功能执行方面，应该要求RIS提供商的系统产品能够赋予用户充分的用户化设置和定义的能力，譬如数据项(如检查部位/检查部门/申请科室/收费/诊断模板等等)的自定义能力，以便提供灵活的系统执行机制适应复杂的用户环境需求。
　2) 用户权限管理：由于RIS系统的许多操作涉及患者医疗档案数据的产生、编辑和处理，因此，执行严格的和独立的用户权限管理是必要的。医院在执行RIS系统规划时应该对此提出明确而具体的需求说明。
3) 与PACS、HIS系统的通讯和交互：RIS系统在一定意义上是连接HIS与PACS的一个中间环节，在IHE流程执行模型中这一特点尤为突出。因此，RIS必须具备相应的功能执行能力完成与不同状态的HIS系统及PACS系统工作流的集成和数据通讯，理想情形，应该是基于标准(主要是DICOM/HL7标准)层面的集成。在IHE定义的流程，RIS系统与PACS系统至少需要在影像采集设备(Modality)、PACS服务器和影像工作站三个环节上实现集成和通讯。对于此项，医院在执行系统规划时，应该有适当前瞻性的考虑并提出明确的需求陈述。
三、结论与说明
　　总而言之，执行医学影像学信息系统(PACS和RIS)的引进规划对国内医院用户是一个必要且有价值的过程和任务，在系统的引进之前完成一个基本满足医院相关需求的规划文本，可以帮助医院容易地界定将引进的系统应该达到的规模、实现的主要功能指标和任务以及对于实际投资水平进行预估和控制，同时，规划文本本身亦可以作为规范和保障系统引进、实施过程的指导性文件。因此，有条件的医院推荐在执行系统引进过程之前，对医院的实际需求和PACS及RIS系统相关的技术要求进行必要的归纳和准备，咨询该领域的专业人士和机构，尔后建立自己的PACS & RIS系统规划方案，这样将会大大降低系统投资的风险和确保系统投资的有效性。

来源：https://blog.csdn.net/qq_35326134/article/details/52909466
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

欢迎光临医工互联 (https://www.yigonghl.com/)