IHE与医院信息系统集成技术研究-何雨生

获得积分
资料库会员登录
搜索: [高级搜索]
下载首页 | 资源分类 | 下载排行
您的位置: 首页 > 标准文档  > IHE
 
分类导航
 HL7及CDA (77个)
 DICOM (83个)
 卫生部相关信息化标准 (84个)
 其它标准 (30个)
 数据字典相关 (36个)
 ICD (27个)
 IHE (57个)
 SNOMED (8个)
 国家标准 (54个)
下载排行
·IHE PIX的实现
·IHE与医院信息系统集成技术研
·IHE基本教程(1)
·基于IHE规范的大型城市医疗信
·IHE 在医疗信息交换(HIE)中的
·IHE基本教程(3)
·IHE基础教程
·通过Web Services设计IHE-XD
·IHE基本教程(2)
·HIE与大数据时代的医院信息化
最新资源
·IHE RID_正式用例xds翻译
·HIE与大数据时代的医院信息化
·以HIE帮助医疗信息化的顶层技
·IHE中国2013年第二次测试会通
·IHE相关介绍
·IHE_PIX
·IHE XDS 基础培训
·IHE
·IHE
·HITSP-EHR
IHE与医院信息系统集成技术研究-何雨生
资源大小:876.04 KB 资源类型:文档
下载积分: 0
更多
-->
下载统计:总下载:391,本月下载:2,本周下载:1,今日下载:1
发表评论 错误报告 加入收藏夹
资源介绍
HE与医院信息系统集成技术研究

何雨生1  王力华1  王秀民1  孟兆斌2  靳罡2  王永辉3

1北京大学人民医院医学信息中心
2美国GE公司医疗部
3北京众邦惠智公司

摘要:本文介绍了国际上医疗信息集成标准的进展,重点介绍了IHE有关集成的基本体系结构和互操作性问题,同时介绍了系统集成技术的进展和面向服务的体系结构,讨论了其在医学中的应用。在此基础上,讨论了北京大学人民医院集成系统体系结构的设计方案。

关键字:医院信息系统  系统集成 标准化 面向服务的体系结构 区域卫生信息系统

1.        简介
随着国内医院建设的信息系统规模不断发展,信息系统集成的需求越来越强烈。医院信息系统集成的需求主要来自于以下几个方面:
        医院不同子系统的集成需求。国内大型医院信息化的需求十分复杂,单一HIS提供商无法满足。随着软件专业化分工的发展,PACS/RIS、检验、财务、人事等系统得到独立发展的机会;电子病历的专业化发展对集成需求更为强烈和复杂。
        医疗集团之间信息系统的集成需求。集团中不同医院的信息系统可以是同构或异构的系统。只要不是使用同一个服务器和数据库,就存在集成问题。即使使用同一数据库,也有不同医院病人的标志问题。
        区域/国家卫生信息网中信息共享的需求。这种共享包括不同医疗机构之间信息共享,还有不同医疗机构与管理部门的信息共享。近年来发达国家投入巨资研究的国家卫生信息网,其核心内容就是电子病历的互操作性,本质上就是集成问题。
由于近年信息化的集成需求,通用集成技术研究取得了长足的进展,其典型的三大技术是“企业应用集成(Enterprise Application Integration,EAI)技术”、“企业信息集成(Enterprise Information Integration, EII)技术”和“撷取、转换和载入(Extract, Transform and Load, ETL)技术”[1]。随着面向服务架构(Service Oriented Architecture,SOA)技术的发展,人们开始从软件的体系结构上考虑系统的集成问题,甚至有人提出SOA将是集成的终结[2],意思是人们从此将不用考虑集成的问题,软件天生就是可分布的,可任意组合的。这种想法过于天真,但SOA代表了软件的发展方向,HL7版本3已经使用了面向服务的思想分解医院需求。当然,HL7版本3距离任意分步和任意组合功能的目标还差得很远,也可能永远达不到这个目标。

2.        IHE集成与互操作性内容简介
2.1.        IHE简介
IHE(Integrating the Healthcare Enterprise)是北美放射医学协会(RSNA)和美国医疗卫生信息与管理系统协会(HIMSS)于1998年成立的组织[3],其目标是促进医疗信息系统的集成, 为不同子系统之间的互连提供集成方案。IHE并不是定义新的集成标准,而是基于现有成熟的标准(例如DICOM、HL7和其他一些系统集成的行业标准)制定的一套集成方案。IHE定位在制定一套规范的流程,并通过DICOM、HL7等消息系统实现这种流程,以实现不同系统的集成。IHE集成规范目前的版本包括如下内容:
        IHE技术框架-集成规范         版本6.0         2005.5发布
        IHE技术框架-事务处理            版本6.0         2005.5发布
        IHE技术框架-国家扩展                版本6.0         2005.5发布
        IT基础技术框架-集成规范         版本2.0         2005.8发布
        IT基础技术框架-事务                版本2.0         2005.8发布
        实验室技术框架-集成规范        版本1.1         2004.7发布
        实验室技术框架-事务                版本1.2         2005.2发布
        心血管科技术框架-集成规范         版本2.0         2005.6发布(试用版)
        心血管科技术框架-事务                 版本2.0         2005.6发布(试用版)
        IHE 患者诊疗协作                2005.10发布(试用版)
IHE技术框架和体系结构将医疗系统集成的公共部分抽象出来,用UML描述,例如一些标准流程和一些标准处理过程,其余规范则是针对具体应用领域制定的流程规范。在此我们重点讨论集成的基本体系结构和互操作性问题。

2.2.        MPI和PIX[4]
MPI(Master Patient Indexes)是医院信息系统中病人基本信息的主索引,是唯一完整的病人标识,通常它只能由一个应用系统输入,并对其它应用系统进行分发,以保证整个系统中病人基本信息的一致性。
国内一直没有重视病人主索引的技术研究,目前还有很多HIS系统在病人主索引的设计中存在严重的问题,即使用病人门诊和住院号作为病人的主索引,这种设计将带来“灾难性”的后果。因为病人门诊和住院号一人多号问题普遍存在,为了病人信息的完整性和一致性,医院需要将多号合并。如果HIS使用病人门诊和住院号作为主索引,在合号过程中,HIS系统需要将变更号码的所有记录修改为新号,这将涉及多个表的多个记录,很难修改完整,一旦出错,有可能会导致收错费或发错药的严重后果。另外,HIS数据量巨大,医院不可能永远将其保存在当前运行的数据库中,需要将其迁移到过期数据备份服务器上,或者备份到磁带上,理论上讲,这些数据的主索引更本不可能再修改,因而必将破坏数据的一致性。过期数据的检索和统计将受到影响。我们建议,医院采购HIS时要将这个问题列为考核系统的重要指标,因为这是系统设计的重大问题,不可能通过维护修改解决。可喜的是,2006年全国医院网络大会收到了多篇讨论MPI的文章,希望引起与会者的重视和讨论[5][6][7][8]。
随着医疗集团和区域卫生信息系统的发展,病人标识和病人主索引也引起了IHE的重视。2003年,IHE提出了PIX(Patient Identifier Cross-referencing Integration Profile)集成规范,其目的在于从多个产生病人标识符的应用中,实现病人标识的交叉引用。
以前,MPI没有实现规范,实现起来比较混乱。PIX集成规范定义了实现MPI的一套流程规范,使用HL7标准实现。不同的应用系统遵循该规范,使用HL7消息,可以比较容易的加入到现有应用系统的MPI中。
在一个医疗集团中,不同医院分别使用相同或不相同的HIS,使病人主索引的问题更为复杂。在一个医院中,我们需要解决不同部门应用系统的病人标识问题,如放射、病理、B超检查编号等。在医疗集团中,出现了同类系统不同病人标识问题。当然,我们仍然可以按照不同类型应用系统的处理方法,但这些数据没有办法汇总统计分析。当然,若要彻底解决问题,还要通过门诊和住院系统的主索引结构实现。

2.3.        XDS
2003年以后,IHE重点讨论了互操作性(Interoperability)问题,提出了“跨机构文档共享规范(Cross-Enterprise Document Sharing, XDS)”,以解决区域性的医疗信息共享问题。XDS主要为医疗机构之间的文档共享的管理提供一个规范,这些医疗企业可以包括私人诊所和门诊部甚至是一个住院病人的紧急看护科室。图1显示医生在联网环境下远程读取病人资料,临床信息系统通过访问索引系统实现查找并读取不同地点的病人文档的过程。图2介绍了XDS使用的其它标准,XDS自己没有定义任何标准,只是一个临床流程规范建议。因为流程具有很强的地域性,非常容易受人为因素影响,不可能强制统一。图3介绍了在区域范围内临床文档共享,文档注册、病人ID与病人主索引之间的关系。
目前各国都在积极建设自己的国家、区域卫生信息系统,这种系统的基础模型就是XDS,因此应该引起各级卫生信息化规划者的足够重视。我们不能重走医保系统建设的老路,在没有研究、规划、设计好的前提下匆忙建设,造成大量人力物力的浪费。一个大型医院和医疗集团的需求模型与其相同,只是稍微简单一些。



图1. 区域卫生信息系统中基于XDS        的电子病历交换


图2. XDS使用的标准


图3. 基于XDS规范的临床文档访问流程

3.        系统集成技术进展
3.1.        EAI基本概念
在集成方法学方面,近年来人们进行了大量的研究,企业应用集成(Enterprise Application Integration,EAI)[9]讨论了集成的不同模型。其中,集成消息模型就是HL7、DICOM实现的基础[图4]。
     
图4. 集成的消息模型
企业应用集成EAI(Enterprise Application Integration)被定义为:将进程、软件、标准和硬件联合起来,在两个或更多的企业系统之间实现无缝集成,使它们就像一个整体一样。实际就是研究异构系统互连的方法学。
从集成的内容上看,随着集成的发展及人们对集成的不同需求,可以从几个不同的层次去实现。分别是数据(Date)层,应用(Application)层及表示(Presentation)层,根据其实施机制分为四种集成模型,图5介绍了不同的应用集成方法。其中数据集成主要是在不同的系统间传递数据,目前HL7的应用,主要还是用于数据集成。应用接口集成和方法集成是在不同的系统之间实现功能集成,传统的功能集成很多通过远程调用实现,Web Service在功能集成方面代表了最重要的发展方向。界面集成主要讨论不同应用系统之间用户界面的集成方法。HL7标准组织专门制定了界面集成的标准-CCOW,希望通过该标准让不同的应用系统共同配合工作,自动同步显示需要的数据。但CCOW在实际使用中还是碰到了很多问题,使用十分复杂,在实际中很少有医院使用。

图5. 应用集成的不同层次

从应用集成的系统集成结构来划分,可以分为三种结构,分别是点对点的结构[图6]、消息代理结构[图7]和过程代理结构[图8]。
   
图6. 点对点结构         图7. 消息代理结构        图8. 过程代理结构图

点对点方式是传统的系统互连方式。实际上,HL7是基于点对点方式制定的互连标准。消息代理方式使用集成代理中间件实现。基于HL7的点对点集成方法只能够解决互连标准化问题,不能够简化接口数量[图9]。理论上讲,如果需要互联的子系统有N个,则完全互连的接口数量为(N-1)*N。如果使用集成代理中间件,则接口数量可以减少为N*2个[图10]。集成代理中间件可以分成消息代理和过程代理两种模式。消息代理模式通过消息传递机制实现系统互连,过程代理模式能够支持系统的过程集成,可以通过过程代理中间件配置流程。当然,这种流程控制能力受限于应用逻辑和集成应用系统的设计,并不能达到任意配置的愿望。


图9. 点对点互连模型                         图10. 集成代理中间件集成模型
3.2.        EAI工具
我们以微软公司的BizTalk Server为例介绍EAI工具。BizTalk Server 包括接收和发送适配器、接收和发送管道、编排组件、BizTalk Server 消息框和业务规则引擎[图11]。在集成平台中商务流程处于核心地位。在商务过程中需要进行信息交换,交换会在流程服务、MessageBox、连接应用的适配器之间进行。MessageBox是消息出版与订阅的核心。BizTalk Server通过Adapter(适配器)与发送/接收管道以某种通讯协议发生实际的交互。通过BizTalk Server的消息机制,可以实现数据、过程集成,也支持Web Service的服务集成。
当然,类似的工具产品很多,如IBM的WebSpere、Web Logic、SeeBeyond等公司,都有类似的集成工具。

图11. BizTalk Server工作原理图

3.3.        ETL和EII技术简介
ETL技术主要面向数据仓库的需求,将数据从多种数据源抽取、转换和装载到另一个数据库中,包括数据集市和数据仓库。但是,这种数据转换整理的过程耗费大量的人力物力,否则很难适应复杂的数据分析需求。
下载地址
 下载地址1
按字母检索

下载须知:
大部份资源无需注册即可下载
需要积分的资源要在会员中心注册会员并用 积分体系中提示的方法赚取积分才能下载。

免责声明:
所有资源只能用于参考学习,不能用于任何商业用途,否则后果自负!