医院信息化集成平台解决方案建议分享

　　今天整理和分享下多年前关于医院信息化集成平台建设的方案思考。虽然对于集成平台，ESB总线来说更多的是一个和业务无关的技术平台，但是在整理医院信息化集成平台解决方案的时候，仍然需要了解医院信息化的业务场景和业务架构，数据标准规范体系等。医院信息平台建设的必要性
　　建立医院信息平台就是为了提供建设规范和数据标准，形成全院级以电子病历为核心的病人主索引，实现医院内部不同时期的不同软件产品和不同业务系统的统一集成、互联互通和信息整合。并在此基础上实现对医院信息资源的二次利用，为患者提供公众服务，建立与外部系统互联的统一接口，满足区域的信息共享与协同以及医疗行为监管的要求。
　　根据业务梳理和分析，医院信息系统分为临床服务域、医院管理域以及平台应用域。其中临床服务域、医院管理域包括大量的医院基本业务系统。基于电子病历的医院信息平台需支持医院信息系统中纵向和横向的数据交换及信息共享。
　　从纵向看，在医院内部病人的电子病历信息，是一个纵向不断增加的信息集合，准确和连续的病历信息是高质量医疗活动的基础和保障。在医院外部，病人电子病历需要向区域卫生信息平台提供最新的治疗记录和检验报告，需要向上级医疗卫生部门上报重要的个案信息和管理统计信息。
　　从横向看，医院内部各科室使用的应用系统，也需要大量的信息交换，比如计费和门诊药房系统之间需要共享病人信息、交费记录、药品信息等。医生工作站系统需要和手术系统共享手术安排信息和病人体征信息等等。
　　医院信息协同的需求越来越普遍，医院和其他医疗相关机构之间的协同和信息交换、医院和病人的信息交换和沟通需求催生了许多新应用，如远程医疗、病人自我服务等。这些新应用需要在信息共享的基础上实现业务流程的整合和业务协同。通过平台的支持，达到对业务流程的有效监控管理及流程优化。
　　数据仓库和数据挖据是实现临床决策支持和管理决策支持的基础。要建立数据仓库需要从现有业务系统中抽取数据，经过加工处理形成全院的临床和管理数据仓库，在此基础上进行数据挖掘，为医疗服务质量改进和管理水平提升提供决策支持。总体业务架构和技术架构分析
　　通过对医院现状的分析，结合医院未来的发展需要，新型数字化医院业务架构包括：
　　医院IT基础设施升级：完善现有数据中心机房的服务器、存储和网络，实现全虚拟化的高可用方案，同时针对医院影像完成影像云的部署和迁移。
　　集成服务：以企业服务总线（ESB）为核心，建立医院集成平台，实现对现有业务系统的全面整合，同时构建基于ESB的基础服务、主数据管理、临床数据仓库及患者360°视图等集成应用，实现可扩展的信息化架构。
　　数据服务：构建全院级数据仓库，通过OLAP分析，实现关键业绩指标(KPI)展示、决策驾驶舱(DSS)中动态仪表盘、决策预警雷达等功能，为医院决策者提供全方位的决策警示和支持…
　　智慧应用：在集成服务的基础上，完成临床诊疗服务和电子病历服务的改造，实现电子医嘱和临床路径的结合，实现结构化电子病历的全院调阅和利用。
　　安全标准：以三级等级保护及国家、行业信息化标准为基础，建立符合国家各项评审所要求的信息化系统。
　　针对上述业务架构，进行合适的技术选型和架构设计是支撑整个项目的核心，通过同步集成、异步集成和数据ETL等方法针对不同的业务系统进行整合，再将数据封装进行二次利用，从而实现对原有信息系统和未来新建信息系统的全面兼容。
　　技术架构选择
　　针对上述业务架构，进行合适的技术选型和架构设计是支撑整个项目的核心，通过同步集成、异步集成和数据ETL等方法针对不同的业务系统进行整合，再将数据封装进行二次利用，从而实现对原有信息系统和未来新建信息系统的全面兼容。医院信息化应用集成
　　医院的应用基础架构异常复杂，可能包含数十个以致数百个的应用系统。这些应用有些是医院定制，有些是第三方厂商实施，所有应用的构架和运行环境都不尽相同，而各个应用内部的数据格式和接口协议也千差万别。他们通过不同的方法紧密地耦合在一起进行工作，互相之间的联系非常紧密，而使用ESB可以将这些应用解耦，让应用可以独立的处理自身的业务，而不用关心与其他系统之间的交互。
　　ESB是企业服务总线（Enterprise Service Bus）的缩写，是中间件技术与Web Service等技术结合的产物，也是SOA系统中的核心基础设施。ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：
　　解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。
　　服务中介 ：ESB平台作为中介提供服务交互中的基础服务。ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
　　服务编排 ：多个服务进行编排形成新的服务。ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。
　　从上面可以看到ESB的基本功能仍然是数据传输，消息协议转化，路由三大核心功能。有这三大核心功能也可以看到在进行异构系统的整合时候往往根据需要ESB提供这些功能。没有ESB时候也可以实现SOA，比如借助SCA和BPEL来实现SOA，当时却很难实现消息协议转化和动态路由。
　　ESB在发展过程中有从原有的消息中间件转化为ESB产品的，这类消息中间件和数据总线产品在原有的EAI企业应用集成中应用比较多。而SOA根据强调了基于服务的集成，以Web Service服务为基本的管理单元。一个服务的定位是关于如何把业务逻辑表现成为一组相互独立的，自描述的且能互操作的实体。
　　对于SOA关注的是服务全生命周期，通过服务实现业务价值。而ESB关注的是服务中介和服务的集成，是SOA的基础设施。SOA有两个核心组件，一个是ESB，一个是BPEL，而ESB是基础设施，BPEL是业务流程驱动下服务的集成和整合。离开了SOA，ESB将失去它所连接的服务，而仅仅是一个总线，同时也将变得毫无价值。Bobby做了一个比喻：路是没有任何价值的，除非你利用它把一个东西从一个地方移到另外一个地方。而离开SOA，ESB就像一个没人使用的道路。
　　做SOA的事情不要先上来建立一个大而全的ESB，相反是关注你的业务问题，找到用SOA的方法来解决业务上的需求，在解决这个问题的过程当中，你会看到一系列的业务服务。这些业务服务是会产生业务价值的。它可以灵活地组装，动态地解决你变化的业务需求。这是它的价值，只有这样才能使你的业务敏捷起来，随需应变起来。而在服务的组装过程中，你再去考虑利用ESB来把他们连接起来。医院信息集成平台建设方案