集成平台建设方案.doc

集成平台建设方案篇一：医院信息集成平台建设方案信息集成平台建设方案1 建设需求一个完善的医院信息系统通常由上百个子系统组成，牵涉众多的专业领域。这么庞大的系统需要非常专业化的软件开发分工，整合不同厂商有特色的专业系统是医院信息系统的发展趋势，医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经逐渐成为医院数字化发展亟待解决的主要问题。系统集成平台的构建主要面向两个核心问题：一个是为各种医疗应用提供统一的医疗数据访问服务，从而消除各种医疗应用系统与医疗数据中心的直接耦合性；另一个是为各种临床信息系统提供系统集成服务，系统集成服务基于系统集成模型，通过HL7和DICOM等标准通讯协议为各种医疗应用系统提供集成服务，确保各个临床信息系统在工作流整合的基础上实现交互协作，从而以数字化的形式完成各项医疗业务。2 建设目标系统间的整合、集成和扩展一直都是制约医院数字化发展的主要障碍，由于不同厂商之间的产品不兼容，使得医院整体信息化步履维艰。通过建设一个规范的系统集成平台，在IHE、DICOM、HL7等国际标准的基础上，制定覆盖医疗所有业务流程的系统集成规范，开发基于规范的系统集成平台，为遗留的、当前的以及将来的系统提供了一个统一且标准的数据交换和工作流协同的平台。 3 信息集成方法信息集成方法有三，即应用集成、数据集成、界面集成，这三种集成方式各解决不同方面的问题。应用集成指应用程序之间实时或异步交换信息和相互调用功能，可以采用HL7消息，Web Service，CORBA，EJB，DCOM， RPC等标准，采用消息中间件，BPM等中间件实现；数据集成是指应用系统的数据库系统之间的数据交换和共享，以及数据之间的映射变换，常采用ETL（Extract-Transform-Load）工具实现；界面集成含义是应用程序界面之间相互关联引用合成，采用技术包括ActiveX插件、Portlet、IFrame等。协同应用从早期单纯的点对点接口方式，发展到现如今的集成平台方式。各种方式中：? 点对点接口方式的复杂性在于要和不同的系统建立1：N的接口，假定有N个系统相互之间需要建立接口，则接口数为 N*(N-1)/2。? 集成平台方式中，在N个系统需要进行应用协同的情况下，只需要开发N个适配器接口即可，减少了集成平台的系统负荷。由于医院信息系统复杂性，我们根据不同的需求和应用场景，设计分别采用上述三种不同集成方法和手段进行信息集成。4 应用集成和医技辅诊科室信息系统（如PACS/RIS、LIS、MUSE等）的信息集成，这种场景，信息交互的数据量不大，实时性要求不高，且各信息系统各专业厂商实现方式相差较大，采用基于集成平台的应用集成方式是最优选择。集成平台体系结构如下图所示，集成平台对外提供支持多种方式的集成服务：包括WebService服务、TCP监听服务、文件监测服务、FTP服务、SQL监控服务等方式。医院信息系统在国际、国内广泛采用的有一套集成规范，即：医疗健康信息集成规范（IHE）规范。IHE规范未定义新的集成标准，而是采用了“标准协调”过程推动基于工业标准的医疗IT系统互操作性。在IHE中，消息传递采用的是HL7（2.x版本)标准，影像传递采用DICOM标准。本集成平台的集成严格参照该规范进行：信息集成平台在进行消息时采用HL72.4标准进行消息传递、在消息内部传递DICOM StudyUID，以满足后续DICOM图像应用时的需要。临床信息集成用于对各临床信息系统进行信息层面的集成事务处理。事务的定义参照IHE规范执行，消息的交互标准参照HL7 2.4标准执行。集成平台内部引擎本身由Ensemble集成平台基础之上进行二次开发而来，依托Ensemble本身对各种适配器的支持，集成平台对外能够提供多种接入服务方式：TCP、文件夹监听、FTP文件监听、自定义WebService、SQL监听等形式。以更多接入方式进行各种不同方式集成各业务系统。集成流程以业务流程可视化、可编辑化对外提供工作流程的制定与使用。集成引擎基于标准的业务流程执行语言（Business Process Execution Language）进行扩展应用，以描述交互应用。4.1 信息集成模块与示例信息集成组件主要由以下几部分组成Business Service业务服务、Business Process业务处理、Business Operation业务操作，这几部分共同作用下，将集成事务与消息传递进行完成。其中，Business Service主要负责进行消息的监听与接收；Business Process负责全局的消息路由转发、事务流程处理、消息匹配映射等工作职责；Business Operation负责将转换完成、最原子化的一个操作，发送/调用信息集成的目标端。同时在三者相互作用下，消息的反馈准确的返回到Business Process，由Process来讲反馈消息控制返回到消息发送方。示意图如下（后续对该示例进行说明）：4.1.1 业务服务监听与接收在当今医院中，存在各种各种的医疗业务系统，医疗业务系统的多样性，就将导致与其集成时，接入方式的多样性，如部分系统已实现TCP的发送传递；部分已实现文本输出等。集成平台作为医院信息系统的中转、适配角色，在接入方式的多样性成为必要条件。如前所述，在这方面，集成平台允许的接入方式有：TCP、FILE、FTP、SQL、SOAP(WebService)、HTTP、MAIL等多种方式与相应的适配器。在多种方式的接入过程中，将不同来源的消息通过统一的出口转交给业务处理部分，由其进行路由住转发、消息匹配映射、业务流程处理等相关的工作。 在本示例中，EMRS通过WebService的服务监听（BS.WS.EMRWS）方式将消息内容传递进集成平台，在通过验证后，将该消息转发给了业务处理模块中的路由模块。4.1.2 消息路由转发在一些应用场景中，如电子病历系统、重症监护系统、HIS系统三者进行信息传递时，部分信息是需要三者之间交互的，而部分信息仅仅需要两者之间交互，这在消息转发路由时，需要有一定的控制，起到闸门的作用。如：HIS系统进行入院登记时，需要将病人的信息发送到电子病历系统与重症监护系统；而在重症监护系统采集到病人生命体征信息时，仅仅将此信息发送到电子病历系统即可。因此，在集成平台中，引入消息路由转发的相关模块就显得比较重要。在本示例中，EMRCTLRouter这个消息路由者在接受到BS.WS.EMRWS的消息时，可能会转发至EMRPlaceOrder、EMROrderCA、BadMessageHandle三个相关的处理模块。而具体转发至何模块，由消息头定义中的相关信息具体定义。消息路由者起到解析与转发的作用。4.1.3 事务业务流程处理即时消息路由已经正确路由转发了消息到准确的端点，但是在对应的端点内，还会有一些业务流程需要进行处理。如在EMRS下达一个新的Order的时候，需要的一定的情况下产生不同的业务流程分支：如该病人为门诊病人或者住院病人，则有必要产生HL7 消息中的住院病人登记信息与门诊病人登记信息：ADTA01与ADTA04。在本示例中，BPEMRPlaceOrder的内部业务流程如下，每一个结点代表着一次逻辑处理过程：篇二：医院集成平台建设方案医院信息系统集成平台建设方案目录1.2. 背景 . 5 建设目标 . 62.1实现医疗信息资源整合与利用 . 62.2实现医院数据中心建设 . 62.3提供管理决策及临床决策支持 . 73. 设计原则 . 7实用性和先进性 . 8安全性和可靠性 . 8开放性、互连性和标准化 . 8灵活性与可扩展性 . 8经济性与投资保护 . 9易管理和易操作性 . 9整体设计和多种应用相匹配 . 94. 建设方案 . 104.1医院信息化建设面临的问题和难题 . 104.2医院集成平台总体框架 . 124.3标准化数据中心 . 144.3.1建立数据中心的意义 . 154.3.2基础信息库 . 164.3.3业务信息库 . 174.4.4交换信息库 . 184.3.5临床文档库(CDR) . 184.3.6临床数据中心构建方法 . 21操作数据存储ODS . 22数据仓库 . 23医学知识库 . 244.4数据交换总线平台 . 274.1.1. 数据交换总线技术特点 . 294.1.2. 数据交换总线功能特点 . 304.1.3. 基于数据交换服务总线的业务数据交互 . 324.1.4. 业务规则引擎 . 错误！未定义书签。4.1.5. 事件驱动引擎 . 错误！未定义书签。4.1.6. 集团化医院信息交换平台 . 334.5公共消息服务平台 . 344.1.7. 支持HL7引擎服务部件 . 354.1.8. 适配器服务部件 . 384.2. Ensemble集成平台中间件 . 404.2.1. Ensemble HIE 构成组件 . 404.2.2. Ensemble HIE 设计原则 . 434.2.3. Ensemble HIE 技术特点 . 444.2.4. Ensemble HIE 功能介绍 . 49病人主索引（MPI） . 524.2.5. 病人主索引功能 . 534.3. 统一身份认证授权平台 . 574.3.1. 统一身份认证授权平台主要功能 . 5. 单点登录 . 5. 身份管理 . 5. 授权管理 . 5. 安全审计 . 594.3.2. 统一身份认证授权实现方法 . 60医院决策分析平台 . 614.3.3. 决策支撑平台技术架构 . 634.3.4. 决策支撑平台数据架构 . 644.3.5. 指标加工逻辑架构 . 654.3.6. 系统工作内容及技术路线 . 6. 指标库构建与管理的工作内容要求 . 6. 指标库构建与管理的设计原则 . 7. 指标库构建与管理的技术路线 . 72短信服务平台 . 724.3.7. 短信平台架构 . 734.3.8. 短信平台功能模块 . 7. 通知功能 . 7. 查询功能 . 7. 信息管理 . 7. 语音信箱咨询功能 . 7. 医院信息查询功能 . 7. 投诉/举报/建议受理功能 . 7. 自动服务功能 . 7. 导医功能 . 75后台运维管理系统 . 754.3.9. 信息资源统一监控系统设计原则 . 784.3.10. 信息资源统一监控系统架构及技术实现 . 794.3.11. 信息资源统一监控系统管理模型 . 80安全保障体系 . 814.3.12. 隐私保护措施 . 814.3.13. 网络安全保障 . 844.3.14. 数据保密性 . 854.3.15. 数据完整性 . 864.3.16. 恶意代码防范 . 874.3.17. 性能保障措施 . 884.3.18. 运行环境保障措施 . 894.3.19. 信息安全与审计保障措施 . 905.平台扩展 . 错误！未定义书签。1. 建设背景我国医院信息系统建设已经有三十年的发展历史，早期有所谓的All in One的系统，所有的应用都由一个供应商提供，服务于不同目的的应用模块，包装在一个软件包中，所有的数据库都是开放给所有的应用的，不需要接口引擎的设计。然而，医疗卫生信息的复杂性决定了医院信息系统的应用越来越复杂，医院对信息的需求也不断扩展，任何一个HIT厂商不可能提供医院所需要的全线产品（也包括国外的HIS厂商），要实现真正一体化的医院信息系统，必须引进不同厂商的信息系统产品。因此在同一医院环境下，集成不同厂商的产品就成为医院信息化建设过程中必然遇到的问题。一开始几个厂商的产品要达到互连互通，往往是采用点对点的接口方式，因为这种方式简单、易行且成本低，例如，将一个医疗保险的结算系统与医院的住院及门诊病人的费用管理系统集成。然而，当医院的应用扩展到十几个乃至几十个应用系统时，问题就变得困难起来。医院信息化能够取得成功必须保证各个系统的有效集成和数据的高度共享。然而这些系统通常是随着医院的发展需求逐步建设的，它们来源于不同的厂家，基于不同的技术，缺乏统一的信息交换标准，这些系统的集成整合已经逐渐成为制约医院数字化发展的主要障碍。而如何把这些系统连接实现各部门各专业信息共享就成了医院信息化建设中面临的一大难题。如果以传统的方式在各系统之间做接口的话就将出现众多的接口，这将给医院信息系统的稳定性、安全性、可靠性、效率等带来巨大的隐患，同时以让医院的运行维护成本成倍增长，如果医院要对其中一个应用系统进行升级或更换就必须再做众多数据接口。随着国家新医改政策的实施落实，以医院为单位的管理模式已不能满足广大人民群众日益增长的医疗卫生需求，信息共享是实现信息价值最大化的重要途径之一，区域医疗信息共享是信息化发展的必然趋势，为了实现医疗信息的区域化共享，同样需要在医院内部把不同数据资源进行集成整合。在此背景下通过医院信息集成平台来代替原来数量众多的点到点数据接口，为医院信息化建设提供标准和规范，只要各应用系统都支持这些标准和规范，原篇三：系统集成平台项目详细实施方案-v1.0系统实施方案xx软件股份有限公司2013年11月目录第一章需求总体分析 . 61.总体需求描述 . 61.1应用服务器需求 . 61.2第三方软件产品需求 . 71.3项目实施进度要求 . 72.需求分析 . 7第二章系统详细设计方案 . 91.系统总体设计 . 92.设备配置表 . 10第三章系统实施方案 . 121.服务器安装调试方案 . 121.