北京协和医院：基于XDS-I.b的全院级影像文档平台设计与实现
时间:2016-05-15 23:48来源:未知 作者:admin
[影像技术与PACS] 北京协和医院：基于XDS-I.b的全院级影像文档平台设计与实现 技术 , 成本 , 带宽 , 北京 , 协和医院 医疗 影像 信息 作为医疗信息 的 重要组成部分，对疾病的诊断、 治疗 方案 及手术方案的制定具有关键作用。目前市场上有三种比较主流的医
医疗影像信息作为医疗信息的重要组成部分，对疾病的诊断、治疗方案及手术方案的制定具有关键作用。目前市场上有三种比较主流的医疗影像共享交换方案，即中心化PACS方案、数据网格PACS（Grid PACS）方案、XDS-I技术架构方案。数据网格PACS方案在影像信息注册与索引、图像存储、系统架构、系统扩展性、单点故障、网络带宽要求、系统建设成本等方面要优于中心化PACS方案，而XDS-I技术架构方案在保留数据网格PACS方案优势的基础上，增加了在系统架构与非影像系统的集成方面的优势，因此选择XDS-I技术架构方案作为医疗影像的共享与交换方案，不仅能满足院内影像集成与共享要求，还能适应未来更大范围的医疗信息共享交换需求。
IHE与医疗信息共享
XDS.b简介
随着IT领域的相关技术发展和XDS基础技术框架实践应用经验积累，IHE于2007年颁布了XDS.b规范，相对于以前的XDS（改称为XDS.a）主要存在以下改变：元数据格式从ebXML Reg/Rep RIM 2.1升级到3.0；文档元数据增加了新的存储唯一标识属性；定义了新的文档集获取交易取代了XDS.a中的文档获取交易事务；为跟随web服务规范的变化更新了注册表存储查询绑定。
XDS.b基础技术框架图
XDS-I.b的技术框架
伴随XDS的升级，XDS-I也升级到了XDS-I.b，图2显示了XDS-I.b的主要角色及其交易事务。由于XDS-I.b是建立在XDS.b的基础技术框架上，所以两者有类似的逻辑架构。
XDS-I.b基础技术框架
XDS-I.b新增角色介绍
从图中可以看出XDS-I.b基础技术框架在保留文档仓库、文档注册中心和文档用户角色及其交易事务的基础上，新增了影像文档源和影像文档用户角色，及其相对应的交易事务规范。由于影像文档往往占用较大字节，所以影像文档源在生成包含影像实例的影像文档清单（DICOM manifest）后，依据消息传输优化机制（MTOM）将相关数据提交并注册到文档仓库，影像文档源必须保证影像实例的有效性及可获取性。影像文档用户通过文档注册中心查询需要的文档信息，并依据反馈的结果，从文档仓库获取影像文档清单及关键对象选择文档实例（Key Object Selection Document Instance），解析KOS文档实例，获取影像文档实体的地址，再通过WADO或者DICOM标准从影像文档源获取影像文档。
全院级影像文档平台与第三方系统的接口设计
全院级影像文档平台是基于IHE最新规范XDS-I.b的大型系统，由于XDS本身比较复杂，涉及多种国际标准（HL7、DICOM、ebXML等），基于ebXML的信息模型抽象度又比较高，对国内很多厂商来说技术比较新颖，开发难度较大。如果按照以往HL7集成的经验，提供一套接口文档的方式，集成厂商花费的集成时间较长，最好提供一套封装好的开发包，简化集成的复杂度，尽量减少接口对各子系统的内部影响，缩短项目的实施进展。实际上，全院级影像文档平台应包含完整的XDS-I.b角色及其相应的功能，对于第三方系统来讲，与整个影像文档平台的集成接口主要有两个：作为影像文档的生产和提供方以标准的方式向影像文档平台发布共享所需的影像文档；作为需要集成影像文档浏览能力的临床系统（如HIS）通过界面集成方式启动对应的影像文档浏览客户端。对应的技术接口主要包括以下三个。
ITI-41规范
IHE标准的ITI-41规范定义了以标准方式提交文档到影像文档平台的Web Service接口，其中包含文档内容以及表达该文档特性的元数据。它是XDS基础技术框架中文档仓库所提供服务接口中的提供/注册文档集交易事务规范。科室级影像系统通过ITI-41规范将规范格式（如PDF）的影像诊断报告及其元数据提交到影像文档平台的文档仓库。
C-Store接口
C-Store接口使用标准的DICOM接口，但为了影像共享的要求，需要在原有必须Tag的基础上增加相应的必填项。科室级影像系统通过C-Store接口标准将需要共享的影像传到影像文档平台的影像文档源，由影像文档源生成影像清单提交注册到文档仓库。
PIV Open API接口
第三方系统如HIS系统使用PIV Open API方式通过 Web URL 启动针对特定患者的影像文档浏览客户端。PIV是一个用于访问基于XDS-I.b的影像文档平台中以患者为核心的临床文档的Web应用程序，可以通过标准的URL方式打开。为了在保证患者隐私信息的基础上提供方便的临床发布和访问特性，PIV在访问接口集成层面提供了基本加密访问。接口内主要包含患者ID，全局ID及访问账号等内容。
全院级影像文档平台的逻辑架构
全院级影像文档平台与科室级影像系统既有关联又相互独立。平台的影像文档来源于科室级影像系统，科室级影像系统故障又不会影响到已共享影像文档的访问。平台可以建立单独的客户端和账号，也可以与HIS系统集成便于访问。下面以与HIS系统集成的例子来探讨平台的逻辑架构。
HIS系统向科室级影像系统发送检查申请单消息，RIS系统登记后将登记状态回填给HIS系统，同时RIS系统通过Worklist将患者信息和检查信息发送到相应的影像设备，检查完成后，影像设备通过MPPS服务将检查完成状态返回给RIS，将影像按照标准的DICOM C-Store接口推送到影像文档源，同时RIS系统会将检查完成状态发送给HIS系统。报告完成后，RIS系统会将报告完成消息回填给HIS，并将报告内容传送到文档仓库，最后注册到注册中心。需要说明的是，科室级影像系统提交影像文档到全院级影像文档平台时，平台会对患者基本信息，主要是全局ID进行校验，校验失败则提交失败。
当医生需要查看患者的影像或报告时，通过HIS点击“影像报告”快捷方式，提交患者全局ID、患者ID及访问账号等内容唤起全院级影像文档平台的文档用户角色， 文档用户角色会向注册中心查询，并通过查询反馈消息向文档仓库调阅诊断报告及影像清单信息，同时唤起影像用户角色，解析影像清单，向影像文档源调取压缩的图像或者DICOM原始图像。
基于XDS-I.b的全院级影像文档平台的逻辑架构
全院级影像文档平台的逻辑架构图里并未提及病人标识源角色，是因为我院已建立患者主索引（EMPI）并通过国家OID注册中心申请了机构全球唯一编码，通过OID和患者主索引可以全局唯一标识一个患者，所以不再需要病人标识源角色对病人进行身份标识。但科室级影像系统在提交影像文档到平台时，平台会对患者身份进行校验，只有校验成功的影像文档方能成功提交。针对未建立EMPI的单位，可以参考IHE患者标识交叉索引PIX规范或者先建立EMPI（EMPI被认为是PIX集成模式的特殊实现形式）, 这样可大大简化患者身份及其临床数据管理方面的复杂性。
为保证患者身份校验的顺利进行，全院级影像文档平台需要与HIS之间建立有效的主索引同步机制，比如患者挂号、建卡以及修改基本信息的时候，都需要HIS将患者的基本信息（ID号、姓名、身份 证号等基本信息）主动推送给平台，平台也可以定期主动与主索引进行同步，以保证患者基本信息在平台的有效性。 |
|
------分隔线----------------------------
