基于ESB医院信息集成管理系统设计与开发.docVIP

基于ESB医院信息集成管理系统设计与开发 　　摘要：借由微软提供的企业服务总线（Enterprise Service Bus，简称ESB）组件，将原本各自独立的医疗医技等信息系统统合起来。首先分析了电子病历EMR和医院信息系统HIS两大软件系统形成主体架构环境，然后分析ESB项目的整体目标和方法，对服务改造分析、服务器硬件配置、Biztalk安全方案这几个关键点进行了详细阐述。选择医院系统中最为主要的电子病历系统（EMR）和医院信息系统（HIS）的消息传输接入来给出系统接入的实现方法，最后通过测试证明该方案切实可用。 　　关键词：医院信息管理；企业服务总线；电子病历 　　中图分类号：TP319文献标识码：A文章编号：1672-7800（2013）006-0073-03 　　作者简介：张逸鲁（1984-），男，硕士，复旦大学附属肿瘤医院技师，研究方向为软件开发、软件管理。 　　0引言 　　随着医疗技术水平的不断提升和发展，相关医疗信息管理成为刻不容缓的课题。借由微软提供的企业服务总线（Enterprise Service Bus，简称ESB）组件，将原本各自独立的医疗医技等信息系统统合起来，实现消息路由、验证、转换并且集中管理。通过各种模式的搭配和实践来进行简化原本复杂且庞大的消息架构，将来源不同的重要数据进行整合、收集以及再发布，正确提供给需要它们的对象，从而提高了工作效率，节省了劳力成本，满足了目标要求。从信息办公和职能操作的角度实现了行政工作与窗口服务的全局统一与集成。 　　本文主要通过分析BizTalk作为医院信息集成管理搭建架构的一种该平台，应用平台提供了一个基础架构，基于此可以灵活和安全地重复使用架构和商业服务，并具有协调原有的服务整合到新的端到端的业务流程中的能力。 　　1医院软件系统联系环境分析 　　由于早期各个科室的软件上线系统并不统一，所以几个主要的软件系统分别是由不同公司所编写的软件在支持。但是也正如前文所说，没有任何应用程序是完全孤立的，对于各个软件系统的统筹调用还是有相当的必要性。医院由电子病历EMR和医院信息系统HIS两大软件系统形成主体架构，其它系统看似各自独立但是都要通过这两大系统来实现信息的共享。从图1中可以看到，EMR和HIS作为医院软件系统的主要核心，将其它各个部分的软件系统都联系在了一起。同时也能发现，EMR和HIS之间的联系最深；EMR与其它各系统联系最多；HIS和其它各系统间的关联节点虽然也比较多但是关联程度不深，接口数量不多。 　　可以想象，一旦EMR或者HIS系统出现问题，除了会首先影响到对方正常工作外，还将有可能导致其它系统的瘫痪甚至是全院系统的瘫痪。万一发生这种情况，这对日门诊量已经达到3 000～4 000人的大型医院来说无疑是灾难性的。同时考虑到，将EMR和HIS系统作为架构主体，虽说原本EMR或HIS就是作为一个信息平台有其承担信息交互能力的系统，但是由于实际工作过程中的个别差异性以及该系统本身就承担有一定信息处理功能的前提下，为了分化压力，确保安全性以及提高软件运行速度效率的情况下，实行ESB软件集成平台应该是目前最行之有效的方法。 　　2ESB集成项目整体规划 　　一般来说，解决整合问题的最简单方法，就是独立的系统之间建立点对点的数据连接。有些数据整合可以建立在开箱即用的解决方案基础上，其它的则需要定制的代码开发。虽然这些解决方案都成功上线了，但是随着时间推移，这些定制的点对点导致系统的负载性明显增加，每一个业务系统都需要维护大量的数据连接，导致系统管理和维护的成本增加。随着组织的不断完善以及业务系统的不断增加，系统监控及系统错误响应的需求将会变得越来越重要。系统可控性及敏捷性的不足会导致软件供应商及开发人员寻找不同于点对点整合的、更好的解决方案。 　　在解决上述问题的过程中，经常会使用到上文提到过的企业应用整合（EAI）技术。由于企业应用整合（EAI）解决方案倾向于允许系统接入端点位置使用硬编码，这样每一个服务都与其后端系统之间紧密耦合在一起，这样接入端的修改，将导致企业应用整合（EAI）解决方案的部分甚至全体进行相应修改。 　　另一个解决问题的方式是考虑以面向服务的架构搭建系统。在大多数情况下，面向服务的应用程序的最终部署方式也和点对点的解决方案相同。随着时间推移，它们也会紧紧耦合在一起，像一个应用程序一样。如果一个地址发生改变，或者一个消息格式发生改变，同样会导致连接的另一端必须做出相应的改变。那么在这种情况下，整个系统将不再拥有面向服务架构所带来的任何优势，而在许多时候甚至更糟。 　　基于以上的要求，中间库的使用变得必要。 　　2.1服务改造分析 　　在介绍了医院已有多个独立信息系统基础上，了解了它们之间的主要关联以及变动会