PACS 服务器的评估.doc

第三届全国数字化影像及PACS应用与进展研讨会PACS/RIS 服务器与数据库的设计JB Wang (王景白), Ph.D., CTO & Acting CEO, 美国深思公司, 中国 PACS 论坛总版主 /bbs联系方式：, 电话：408-865-0355 (美国)摘要PACS/RIS 服务器与数据库的设计是PACS 的核心技术，对一套 PACS 的可用性和可靠性起了决定性的作用。与 PACS 影像工作站和临床科浏览工作站相比，PACS 服务器有一层看不见、摸不着的神秘色彩，用户在购买系统时几乎无法评估。PACS 服务器的设计缺陷与产品质量问题往往不会在短期使用过程中表现出来的。问题一旦发现，数据库里已经有了大量的数据，任何修修补补的措施不但可能耗费大量的人力和财力，造成数据的损失，而且如果问题致命，唯一解决方式可能是换掉整套 PACS 系统。本文将从技术角度和用户使用和管理的角度分析PACS/RIS 服务器与数据库设计的相关问题。PACS 和RIS 分别为 Picture Archiving and Communications System (医疗图像管理与通信系统) 与 Radiology Information System (放射科信息系统) 的缩写。DICOM 是 Digital Imaging and Communications in Medicine 的缩写，是美国 ACR (American College of Radiology) 和NEMA (National Electrical Manufacturers Association) 两个组织自80 年代中以来致力制定的一个医疗影像格式、通讯和打印协议标准。DICOM 3.0自1993 年出了第一个版本后，每一、两年修订一次。以我们经理的观点是，摘要100字左右，关键字，然后是“引言”，然后是正文。PACS/RIS 服务器的组成与主要功能PACS 服务器有下列主要组成部分： 1. 服务器平台：服务器计算机 (如 Dell 服务机)、海量储存介质 (如 RAID 5 磁盘阵)、备份设备 (如 AIT3 磁带转盘)、计算机操作系统 (如 Windows 2003 Server)等。这些都是市面能买到的，而且速度和容量每年大幅度提高、成本大幅度下降。2. 数据库软件：用的是专业数据库，如市面能买到 Oracle 和微软 SQL Server，或高质量、久经考验的免费数据库软件。 3. DICOM 服务器软件：PACS 厂家设计和制作的服务器软件，用 DICOM 3.0标准的 Storage SCP 服务来接收从各影像设备、采集工作站、HIS/RIS 和终端工作站送来的信息；也可能提供其他 DICOM 服务，如 Query (查询) 、Retrieve (提取图像) 、Storage Commitment、Modality Worklist 等等。4. 数据管理与数据流软件，该软件不但提供了数据库和 DICOM 管理的人机界面，还包含许多数据管理和数据流逻辑和算法。5. 储存管理、预取和备份软件。6. HL 7 网关软件用来与 HIS 和 RIS 接口。7. 其他辅助软件与硬件。PACS/RIS 服务器平台与操作系统的选择在上世纪 90 年代市面几乎所有的 PACS 服务器用的都是 UNIX 平台。但是自2000 年以来几乎所有的厂家，无论大小，都已转向Intel兼容机，采用 Windows NT 、Windows 2000 Server或最新的微软Window 2003 Server操作系统。这个转变与计算机发展史有密切的关系。70 至 80年代初是大型主机的年代，IBM 和 DEC 主机占了主要的市场，主要操作系统有 IBM VM 和 DEC VMS。那时候还没有 PACS。80 年代初Unix工作站 (Workstation)和个人电脑 (Personal Computer) 开始普及。工作站的主要代表有 Sun, HP, IBM RS/6000, SGI 和 DEC Alpha。个人电脑的主要代表是苹果公司的 Macintosh 和 IBM、Dell、Compaq、HP、Gateway 等很多厂家的 IBM 兼容机。 早期 Unix工作站和个人电脑之间有很鲜明的界线。这个界线不光是体现在超过十几倍的硬件、软件和配件的价格差；硬件配置、操作系统、浮点处理器速度、联网能力、显示卡、三维图像处理与显示以及内部数据传输速度的确也是相差甚远。长期UNIX 平台曾是科技/工程应用的首选，PC 只用于家庭和办公室。微软总裁 Bill Gates 在 1981 年曾说过：640KB 的内存足够大家用 (640Kb ought to be enough for anyone)。有了这种指导思想，PC 机的操作系统一直是个最大限。16-位的DOS 操作系统和Windows 3.0/3.1限制了 PC 机能容纳文件数目、每个文件的大小、机器最大内存以及应用程序的最大内存用量等等。总之，当时的IBM 兼容机不能满足 PACS 服务器和工作站的要求。 这些缺陷自 1993 Windows NT 操作系统出来后就开始消失了。首先，NT 是前 DEC VMS 大型操作系统的主设计师设计的，而且把各类UNIX 的主要优点都加进去了。UNIX 没有图像界面 （Graphical User Interface)，要依靠外加免费的 X11 Windows来弥补。而自 Windows NT和 Windows 95 以后微软Windows 含图像界面、操作系统、三维、联网和其他 Unix 有的和没有的功能。那么，是否 Unix和 Windows 任选一种都行呢 ？其实不然，因为 Unix 机器销量低，其硬件、软件、特别是维修和升级要用到配件都比 Windows 贵很多，而且几年老的机器就找不到配件了。有时初买一台服务器时好像用什么平台的价格都差不多，但是今后升级、管理和维护成本可以差几倍甚至几十倍。因此目前已经没有足够的理由用 Unix 来做 PACS。服务器平台与工作站平台有许多不同的要求，这些区别主要体现在多 CPU母板设计 (14颗Intel Zeon CPU)、充裕内存条插口 (通常最多4 GB)、多网卡、RAID 控制板、高速超宽 SCSI 控制板、多槽热撤换 (hot swap) 硬盘插口等等。为了安全起见，有些单位选用双机服务器，即两台机器共用一套 RAID 储存系统。这种做法在欧美比较少见，国内和台湾较多。作为一个正在评估 PACS 的用户，除了要注意厂家设计和制作的 DICOM 服务器和数据管理软件，也要注意厂家选用了什么计算机平台、储存介质、操作系统和数据库软件。假如说发现厂商用到自己特制的 (proprietary) 硬件或是昂贵的 UNIX 平台或部件，那就要必须特别小心。这些可能是今后钱财和人力的黑洞，也是厂商将用户套牢的一种手段。PACS 服务器海量储存介质5-6 年前PACS 界最常见的是用三级图像储存模式：在线 (online) 、近线 (near-line) 和离线 (off-line)。当时最大单个 SCSI 硬盘容量不过 9GB。假如说PACS 在线存储用 15颗 SCSI 3 磁盘RAID 5 (冗余存储磁盘阵列) ，也只有不到45GB 的容量。而医院通常需要 1TB 到 12TB的容量，这样的 PACS 只能通过 DLT 或 AIT 磁带塔或 MOD 光盘塔来实现。有时提取一个图像要 5 分钟，而且磁带磨损厉害。自 2000 年后欧美先进 PACS 厂家已经放弃三级储存，都改用在线和备份两级储存。备份只是为了防意外，如火灾、地震等。在线用的是硬盘，用 RAID (冗余存储磁盘阵列)。目前单个 3.5英寸硬盘存储量就已经超过 200GB。单机配一个 2TB 的 RAID 5 已经不是个问题。逐年扩充可以用NAS (Network Attached Storage) 或 SAN (Storage Area Network) 。长期归档储存的图像一般加以压缩。用了无损压缩后，储存容量可以提高 4-10 倍。新一代的 PACS 大多采用 DICOM 支持的标准压缩算法，如 JPEG、JPEG Lossless、JPEG 2000、JPEG-LS 和 Deflate 等算法。没有压缩功能的 PACS 可以用操作系统或储存设备内设的压缩，一般压缩比可以两倍以上。用户评估 PACS 系统时要特别注意海量存储、特别是多单元(multi-volume)海量存储有一些特殊的技术问题。有些厂家的最大存储容量不能超过 2TB。有些厂家的 PACS 在扩充容量时要备份所有文件，重新格式化后才行。有些厂家用第三家文件系统扩展软件 (如 Veritas) 来将一系列存储介质模拟成一个大硬盘，但是同时也大幅度提高 PACS 系统的成本。PACS/RIS 服务器数据库的选择市面几个大型数据库的代表是： 1. Oracle2. Microsoft SQL Server 企业版3. Sybase：在 UNIX 时代曾经有些厂家用 Sybase 做 PACS 数据库4. Informix：尚无听说用 Informix 的成熟 PACS5. IBM DB2：有用 DB2 做 PACS 数据库也极个别的中型数据库的代表是： 1. Microsoft SQL Server 标准版 (在 PACS 界用得普遍)2. Oracle 8 或 9 (在 PACS 界有厂商用)3. MySQL (基本免费)4. Mini SQL (基本免费)5. PostgreSQL (免费) 小型数据库的代表是：1. Microsoft Access (不少 PACS 工作站用到)2. Borland Dbase3. DICOMDIR (有些厂商的工作站用 DICOMDIR 代替数据库)现在大家用得最多的是微软 SQL 2000 Server标准版和 Oracle。这些数据库的成本跟几个用户有关。5、10、25、50 个用户或按 CPU 个数算。微软 SQL Server安装和维护起来比 Oracle 要简单，而且在 10 个用户以下时比 Oracle 便宜。PACS/RIS 用到的数据库功能和算法非常有限，没有大量并发数据库搜索和读写，不需要复杂的大型数据库和高级数据库功能。但是数据库里存的数据量会逐年增加，大一点的医院几年内会有几百万上千万条的检查记录，下层的系列和图像记录数目就更大了。为此Microsoft Access之类的小型数据库不适合于PACS 服务器，因为它们在数据量大时搜索和读写起来太慢。MySQL 等“免费”数据库虽然比Microsoft Access 速度快，功能强，但是不能与Microsoft SQL相比。再说还是专业软件公司的产品用起来放心。DICOMDIR是 DICOM 标准委员会给移动介质设计的，当时移动介质的容量有限，目前用在大一点容量的DVD 已经不胜任了，用来做 PACS 不可取。作为一个评估用户，数据库软件是一个不小的开支。数据库用户数目与用 PACS 的医生数目是两码事。并不是 100 个医生就要买100 个用户的 Microsoft SQL 或 Oracle。这里指的是并发用户，而且与软件设计有关，如果软件设计得好 5 -用户数据库可供一家大医院。如果不确定用户的计算办法，建议按 CPU 购买，单 CPU 不限用户数量微软 SQL 2000 目前美国价格是 $5000 美元 (按用户买每五个用户约 $1000 美元) 。PACS 服务器备份问题目前 PACS/RIS 服务器内部多用 RAID (冗余存储磁盘阵列) 来存储图像、数据库和其他相关资料。RAID 能够保证数据的安全性，但是万一有自然灾害或意外造成机器毁灭性破坏，数据就丢了。解决这一问题的办法是定期备份，有必要时定期将备份介质存放在防火保险柜。注意，备份与离线储存是两种完全不同的概念。所谓备份就是万一机器坏了，可以从备份介质将数据全部拷贝回到修复的机器里。离线储存则可以通过数据库查询，从介质中单独提取某些检查或图像。目前可行的的备份方式有下面几种：1. 网络远程备份 （用的仍然是RAID 、NAS或 SAN，但是在不同地点)2. 刻录CD-R/CD-RW3. 刻录DVD-RAM/DVD-RW4. 备份到DLT 或 AIT 磁带如果需要自动化程度比较高的备份可以考虑如下其中一种方式： 网络远程备份 DVD-RAM 塔 磁带库或磁带转盘其中磁带备份值得考虑，目前单个 Sony AIT3 磁带可以存 256GB 的数据 (带压缩)，新版 AIT4 容量已经达到 1TB。也就是说中型医院一年的图像可以备份到一、两合磁带上。网络远程备份是一个发展方向。北美有些公司提供这样的服务，有时也叫 ASP。其实就是在一个不同的中心地点设一个 PACS 服务器来做冗余存储。这种数据中心 (Data Center) 设施有些讲究，可以在某种程度上抗自然灾害。CD-R/CD-RW 的容量太小，操作繁琐，保险系数不高。目前国内人力便宜，尚有人用，但是在欧美已经被淘汰。欧美刻录 CD-R 只是让病人带回家，代替胶片。PACS 服务器的 DICOM 服务器软件DICOM 服务器软件是PACS 服务器的主要软件与核心部分。其主要功能是用 DICOM 3.0标准的 Store SCP 和其他相关服务来接收从影像设备、采集工作站、HIS/RIS 和终端工作站送来的图像和其他信息。SCP 全称 Service Class Provider，是服务器的意思。影像工作站和PACS工作站也可能向服务器索取资料，因此服务器 DICOM 软件必须支持相关服务，包括 Query / Retrieve (查询/提取图像) 、Storage Commitment、Modality Worklist (工作清单)、Structured Reporting (结构化报告)、 DICOM Grayscale Softcopy Presentation State (灰阶图像显示状态)、Hanging Protocol(悬片协议) 等等。因为PACS 本身并不产生图像，图像必须从影像设备或工作站传过来。图像从影像设备传到 PACS 服务器有几个目的。1. 供医生影像工作站调用2. 分发给临床主治医师和会诊专家3. 当成病历的一部分归档长期保存以备后用因此，医院上 PACS 的一个关键步骤是把影像设备数字化和 DICOM 化。新购置的影像设备可能都配置了DICOM 软件。但是一些旧的设备没有 DICOM，要购买厂家 DICOM 选件或 DICOM 网关产品。有些旧式影像设备不是数字型的，只能通过视频采集，经转换后输出 DICOM。另外，目前尚有 65%左右的医疗影像还是用常规X-光平片。常规X-光图像感应在化学胶片上，不是一种数字型影像、上不了 PACS。数字化的解决方案包括：1. 给现有常规 X-光机配备 CR。2. 淘汰现有 X-光设备，换成 DR。3. 配胶片扫描机。影像设备有了 DICOM，就可以向 PACS 服务器传送图像。DICOM 服务器 Store SCPDICOM Store 是 DICOM 标准中一个最简单而且最有用的子协议 。其用途是将图像从一台机器传到另一台机器。Store SCU 是发送方，Store SCP 是接收方。Store SCP 是DICOM 服务器软件的一部分。DICOM 服务器收到一个图像后还有许多工作要做：如检验图像的 DICOM 正确性，在数据库表中添加该图像的 Patient (病人) 、Study (检查) 、Series (系列) 、Image (图像) 几层的信息，将图像文档存在数据库指定的地方等等。因此 DICOM 协议只是 PACS软件的一小部分。一般来说 DICOM服务器可以接收任一影像设备输出的 DICOM 图像。但是，1. 不是所有接收进来的图像都能在工作站上正确显示出来。2. 从可以接收图像，到可以正确地接收和保存图像还有很长一段距离。并不是所有 PACS 服务器都能很好地、完全无误地接收和保存影像设备发送过来的所有图像。这类问题变得尤其显著如果医院选择让影像设备自动向 PACS 发送图像。比如说国内常见的柯达 CR 900和 Acuson 的 Sequoia 超声波机器就具有边采集边发送图像的功能。有实例证明一些 PACS 产品与它们不兼容。与柯达 CR 900不兼容的例子在国内有。本作者去年被请到美国某著名心脏专科医院去协助解决超声波图像不能可靠传送到某厂家 PACS 的问题，症状是一个检查的几十幅图像传送到中途失败了，即便技师手工全部重新传送也是失败次数超过成功次数，客户非常不满。最后解决方式是买个DICOM 网关来桥接，超声波用 DICOM 将图像送给网关，网关再用 DICOM 送给 PACS；听起来费解，但是事实就是如此。DICOM 标准每隔一、两年就更新一次，经常新添影像模式、图像类型、或新的传输格式。DICOM 服务器的设计，应该是开放式的，能够跟上 DICOM 标准的发展。DICOM 服务器 Query/retrieve SCP 功能DICOM Query/retrieve是 DICOM 服务器的另一个必备的功能。其作用是让 PACS 工作站和影像设备查询 (query) 和提取 (retrieve) 病人图像资料。Query/retrieve 是三个不同的 DICOM 子协议的组合，C-Find, C-Move 和 C-Store。这部分软件与数据库的设计是紧密联系的，当 DICOM 服务器软件收到一个列表查询 (Query) 指令，它必须实时将其翻译成数据库 (SQL) 指令来从数据库搜索资料，然后再翻译成 DICOM 发送回去。实现 C-Move 时，服务器用 Store SCU 发送图像，工作站用 Store SCP 来接收，这里要另开一个 DICOM 连接 (Association)。因此，必须先在PACS 服务器中输入工作站的 DICOM Application Entity (AE) 信息才行。PACS 服务器其他DICOM 服务除DICOM Store 和 Query/retrieve 外，在 PACS 服务器里常见的其他几个 DICOM 服务包括如下几项： Storage Commitment Structured Reporting (结构化报告) DICOM Grayscale Softcopy Presentation State (灰阶图像显示状态) Hanging Protocol(悬片协议) Modality Worklist (工作清单) Modality Performed Procedure Step 等等其中 Storage Commitment 的用途是让图像发送方告诉 PACS 服务器全权接管所列的图像，发送方可能在本地删除这些图像。Structured Reporting (结构化报告) 是通过 DICOM Store 来发送的，但是Structured Reporting 不是一幅图像，而是文字或图文报告。DICOM Grayscale Softcopy Presentation State (GSPS) 描述的是某图像或某系列图像在某工作站上显示时的窗宽窗位等灰度调节、图像标注和其他一些状态，以便以后显示时用同一套参数。GSPS 也是通过 DICOM Store 来传输的。Hanging Protocol(悬片协议) 与GSPS有类似的地方，描述的也是图像的显示参数。所不同的是Hanging Protocol描述的不是灰度显示参数，而是某个检查或某个病人在不同时期的几个检查的图像在计算机屏幕上的排列格式。Hanging Protocol也是通过 DICOM Store 来传输送的。Modality Worklist (工作清单) 与 Modality Performed Procedure Step (MPPS) 是两个与工作流有关的 DICOM 服务子协议，详细请看下一节的讨论。DICOM Worklist 与 MPPS影像工作流从临床医生下单开始，病人做完诊断结束。举个例子，临床医生看一个心绞痛的病人，因单靠临床检查无法确诊，下单做核医学 Stress-Rest 心肌灌注检查。这个单子由护士输入 RIS 终端。核医科护士在 RIS 终端知道有这么个病人要来。病人到了以后技师通过 ECT 机器的DICOM Modality Worklist 功能从 PACS/RIS 服务器搜取该检查的病人和检查基本资料。这样就省去了重新输入病人基本资料的步骤。检查开始，ECT 采集工作站用Modality Performed Procedure Step 通知 PACS/RIS 服务器检查开始了，检查结束后ECT 采集工作站用 MPPS通知 PACS/RIS 服务器检查已经结束了。这个检查便从PACS/RIS 工作清单里消失。当然，这里的前提是PACS/RIS 服务器的 DICOM软件必须有Modality Worklist 和Modality Performed Procedure Step SCP 功能。病人做完扫描，核医科医生做影像诊断，报告打完经上级医师二级审批 (approval) 后通过PACS/RIS 的 HL7 接口送到 HIS。临床医生看了报告，可能建议进一步做心导管造影检查。然后最后确诊，决定治疗方案。PACS/RIS 服务器数据库的设计在服务器机器上安装了微软 SQL 2000或 Oracle 9 数据库软件并不说明就有了 PACS/RIS 数据库。数据库软件只是一个引掣，数据库本身要根据应用具体设计。这就跟汽车有了引掣还要有变速箱、方向盘、轮子等才能开的道理是一样的。PACS/RIS 数据库是一个关系型数据库 (relational database) 。PACS 数据库的各种表 (tables) 和关系 (entity relationship) 在定义 DICOM 标准时都已经考虑到了。其实 DICOM 标准第三章的 IE (Information Entity) 和 Module 对应的就是数据库里的 Information Entity 和 Tables。一个简单的 PACS 数据库可以只有四个从 DICOM 标准中直接抄来的表 (某大型医疗器械跨国公司的 PACS 服务器的数据库就只有有五个表)：1. Patient Module (DICOM 标准 2003 版PS3.3 C.7.1.1)2. General Study Module (DICOM 标准 2003 版PS3.3 C.7.2.1)3. Series Module (DICOM 标准 2003 版PS3.3 C.7.3.1)4. General Image Module (DICOM 标准 2003 版PS3.3 C.7.6.1)每个表里的 Attributes (DICOM 元素) 是数据库表里的组 (column), DICOM UID (Unique ID) 就是数据库表里的主键（primary key）。一般来说DICOM图像的像素数据 (pixel data) 不直接存在数据库里的，而保留在 DICOM 文件里。如果 RIS 与 PACS 共用一个数据库话，必须加一些与病人基本资料和检查预约等有关的表，这些表也可以在 DICOM 标准里找到，比如说 DICOM 标准 PS 3.3 的下列表格： Scheduled Procedure Step Module (C.4.10) Requested Procedure Module (C.4.11) Performed Procedure Step Information Module (C.4.14)PACS/RIS 数据库的设计要遵循关系数据库设计的三级正规化基本原理 (three principles of normalization)。1. 第一级正规化形式 消除每个表格中重复的组 (如PhoneNumber1、PhoneNumber2) 为每套相关的数据建立一个独立的表格 (如PhoneNumberTable) 使用一个主键来标识每套相关的数据 (如 PatientUID)2. 第二级正规化形式 为应用在多条记录的字段建立独立的表格 通过一个foreign key来关联这些表格的值3. 第三级正规化形式 消除不依赖于该键的字段对数据库设计理论有兴趣的读者，请参考相关数据库书籍。数据管理与数据流软件有了服务器平台、数据库软件、DICOM 服务器软件和设计好了的 PACS/RIS 数据库，下面需要的就是数据管理与工作流软件软件。该软件不但提供了数据库和 DICOM 管理的人机界面，还包括许多数据管理和工作流逻辑和算法。下面是该软件的一些最基本功能： 接到一个新的图像后往数据库里存信息 (Insert)。 搜索和查询列表 (Select)。 病人图像或其他信息被自动或手工更新信息后，软件要刷新数据库表格 (Update)。 用户自动或手动删去一些图像、系列、检查、病人 并刷新表格 (Delete)。上述某些功能需要人机界面，有些只是软件开发时用到的控件或用户看不见的软件模块 (如 COM)。PACS/RIS 的设计如果不是集中所有图像和数据在一台服务器里，就会牵涉到数据流问题。如果医院用户有几个设施，需要共享数据，也会碰到同样的问题。数据流是个复杂的问题，很多医院 PACS 用得不成功的主要原因就是查询速度慢、下游数据库刷新不及时、图像显示操作反应迟钝或者图像下载太费时间。下面就一个简单的数据流问题来讨论：影像设备把图像送到了服务器，如何在医生工作站上看到这些图像？就图像数据来说 PACS 工作站与 PACS 服务器的关系是什么？ 以下是目前工业界一些比较典型的做法：1. 工作站用数据库本身的查询功能通过网络来查询数据库，然后用一些标准的网络数据传输协议 (如 FTP，NTFS) 来提取图像文档。2. 工作站和服务器各自有自己的数据库和图像文档集。图像从影像设备传到服务器后自动转发到工作站。服务器长期保存所有的图像，工作站只保存最近的。3. 工作站用DICOM query 来列表查询和搜索 PACS服务器的数据库，用 retrieve 来提取图像。工作站本身没有数据库，不拷贝服务器里的图像数据。这种做法的问题是 DICOM Query/retrieve 不是为 PACS 而设计的，使用起来会有许多问题。有些厂家通过延伸 DICOM Query/retrieve 来实现。4. 临床浏览工作站用 WEB方式通过 CGI 查询服务器数据库并用浏览器 HTML列表，然后通过WEB或某特殊 image streaming方式下载图像。除了工作站与服务器的数据流问题，还有服务器与服务器间的数据流，mini PACS 与大 PACS 之间的数据流，远程诊断的数据流等等。储存管理，预取和备份软件PACS/RIS 服务器对储存空间和备份要定期进行自动管理。这部分软件的设计也是非常重要的。如果医院的图像资料是通过几级的储存来管理，软件设计就更为复杂。最基本的，PACS 服务器要定期对比较老的图像进行压缩。如果储存空间不够了，要自动找下一个本地或网络储存空间。所有资源到找过了还是没有，要通知网管。如果医院有网络储存或多级 PACS, 要能自动将旧的检查归档到网络储存，工作站需要时自动或半自动提取。PACS 服务器的维护与管理一些医院 PACS 管理员把主要时间都用在 PACS/RIS 服务器的管理上，这是一种不良现象。PACS 管理员的主要时间应当用与支持影像科室、门诊和临床科室，提高生产力。让PACS/RIS 服务器自动运行。下面是一些 PACS/RIS 服务器可能遇到的一些问题： 图像传送问题：由于 DICOM 软件问题或网络问题造成图像传送失败、不完全或不可靠。这类问题又可进一步分为突发性的与经常性的。经常性的可能是 DICOM 软件问题，或兼容性问题，突发性的可能是网络和软件问题。 丢图：丢图是一个比较严重的问题，会直接造成医院服务质量和法律责任问题。如果一个检查的图像有时传得过来、有时不行、有时只有部分图像到位，或者已经存到服务器的图像不翼而飞。这类问题不容忽视，要追根刨底，彻底解决。 工作站与服务器通讯问题：列表查询的反应太慢，或者内容不全；下载图像速度太慢，系列图像不全；或找不到应该有病人或检查。 查询时有资料，但是显示时欲没有图像。 张冠李戴：病人图像、报告或其他信息搞混了。 一个病人的资料从另一个病人的名下调出来，而想要的该病人的资料欲没有。 添加一个简单 DICOM 工作站或影像设备手续繁琐，有时不成功。 浏览工作站不能浏览，或者速度太慢。 用 CD-R/CD-RW 手工数据备份很费时间。解决方法是配置比较大容量的，能自动化的备份设施。 系统升级成本太高，时间太长， 这里包括增加 CPU 个数、内存大小、存储空间、备份设施、网络卡数目等等。 软件升级造成丢数据、服务器不能用，软件与数据库不匹配等现象。 操作系统遭到病毒感染。 经常性死机。 等等、等等上述问题大多是产品设计或PACS网络设计问题，只有一些是具体运行问题。设计问题只有改进或更换了产品才能得到解决。PACS 服务器的维护和管理的工作量很大程度决定于产品的设计和医院的投资。一般来说 UNIX 平台服务器比 Windows 管理起来需要技术水平要高，工作量要大，维护与升级成本高。 有简单人机界面的 PACS 管理起来会简单、方便。需要在指令提示符 (Unix Shell 或 DOS Prompt) 敲入指令的管理方式是老式，不可取。 有远程管理工具的 PACS 产品，不需要专人24 小时值班。 PACS/RIS 应该装在防火墙内，安装防毒软件。一旦中毒，应当做些调研，寻找一个最佳消毒方案，很少需要大动干戈重新安装软件和格式化硬盘的需要。PACS 与HIS/RIS 的接口 HL7 网关软件HIS (Hospital Information System) 是医院信息系统的缩写。HIS 和单独的 RIS不用 DICOM 3.0 标准，而采用 HL7 (Healthcare Level 7) 标准。欧美不少 PACS 含 HL7 网关软件。HIS/RIS 与 PACS 的接口可以是单向的，也可以是双向的。PACS与 HIS 相连的主要益处是保证病人和检查基本资料的正确性和一致性，而且病人基本资料只需在 HIS 上输入一次。如整合得好，每次来了一个新病人或病人资料有了变更 HIS 可以通过 HL7 自动刷新 PACS/RIS 的数据库；每次预约或更改了一个影像检查 RIS 会自动通过 HL7 通知 PACS。在检查开始时影像设备，可以用 DICOM Modality Worklist 到 RIS 查询病人和检验基本资料。检查做完后影像设备会用 DICOM Performed Procedure Step 告诉 RIS 检查做完了。放射科医师在 RIS 上打完报告后，RIS 会自动把报告传给 HIS。这样，整个流程就畅通了。HL7 与 DICOM 的原理和设计思想很不一样，采用文字字段来发送消息，底层的通讯方式靠用户自己决定。两个都支持 HL7 设备必须通过实际测试，对照通讯层和消息的结构与内容才能证明是否兼容，不像 DICOM 一样可以通过阅读DICOM 一致性文件来判断。目前欧美比较通用的是 HL7 版本是2.3 与 2.4，通讯层用 TCP socket。HL7 3.0 版本刚刚出来，还用得不普遍。下面例举说明 HL7 消息的应用。HL7病人资料刷新消息:比较理想的做法是在HIS 数据库表格里加些触发点(trigger)，一旦病人信息改变，HIS 自动发送一个 HL7 ADTA08 消息。PACS/RIS 是这个消息的接收方。这个消息的结构是：ADT A08 Message SegmentsDescriptionMSHMessage Header PIDPatient Identification虽然也可以用其他HL7 ADT 事件来传递病人的信息，如A01 (Admit Patient), A04 (Register A Patient) 和 A05 (Pre-admit A Patient)，PACS 并不关心病人的入院和注册状况，用A08 统一处理于病人基本信息比较简单。 消息例子：MSH|&|MY RIS|YOUR PACS|200304021043|ADTA08|000561810007466|P|2.3|PID|787423541|787423541|MATTJOANL|19661117|F|150 WARDING RDTOUDONMN37784|3344089878|3344588600|787423541|787423541|PACS 服务器接到此信息后要反馈一个确认消息。ACK Message SegmentsDescriptionMSHMessage Header MSAMessage Acknowledgement ERRErrorMSH|&|MY PACS|YOUR RIS|200305081534|ACK|10|P|2.3 |MSA|CA|10HL7影像检查单子消息:医生下了影像检查单子，护士将其输入 RIS 后，HIS/RIS用HL7 ORM指令向 PACS 发送一个消息。这个消息的结构是：ORM Message SegmentsDescriptionMSHMessage Header PIDPatient Identification ORCCommon Order OBROrder Detail消息例子：MSH|&|My RIS|Your PACS |200305081043|ORMO01|000561810007466|P|2.3|PID|123423541|123423541|MATTHEWSJOANL|19421017|F|1150 WARDING STKOUDONTN37774|8764089878|8764588600|123423541|123423541|ORC|NW|000561810007466|200305280800|48PONERALBERTMD|87658818475887390|OBR|000561810007466|000561810007466|76700ULTRASOUND ABDOMEN|UNITED HEALTHCAREPREV AT FSRMC PER OFC TT JILL OFC,NOT ALLERGIC,NOT ASTHMATIC,NOT DIABETIC PER OFC,NO RENAL DZ,NO MM PER OFC VFD ORDER & EXAMS WITH JUANITA|48PONERALBERTMD|XRAY RADIOLOGYUS RM1|US01|UNKNOWN|200305280800|HL7报告呈交消息:影像诊断报告在 RIS 一经二级审批就可自动用 HL7 ORU 消息呈交给 HIS。PACS/RIS 是消息的发送方，HIS 是接收方。这个消息的结构是：ORU Message SegmentsDescriptionMSHMessage Header PIDPatient Identification ORCCommon Order OBROrder D