本文由浙江省台州医院刘祉呈撰写，详细说明了集成平台核心中间件集成引擎(IE)与ESB在医疗信息化场景中的各自特点及优劣，并辅以翔实的图文业务流程场景。看完之后能对ESB和集成引擎两者有更深入的了解，对于医院在集成平台建设中数据交换技术的选择提供了很好的参考和启示。

  在集成平台建设中，医院面临着各种数据交互和信息集成的场景，往往不知道该通过何种数据交换中间件技术来实现系统间的调用和数据的传输。比如：

  → 集成有多种对接形式和协议，如Web Service、数据库、HTTP、HL7等，如何选择？

  上述问题都可能会在项目实践中遇到，为了能用恰当的技术方法来解决这样一些问题，需要对集成平台的数据交换技术有一定了解。ESB（客户服务总线）和Integration Engine（集成引擎）都是用来实现集成平台对于数据传输和信息交互的核心中间件，在对实际应用场景做多元化的分析后，合理选择或结合应用这两种技术，能够很好地应对以上问题。然而，有一些时候大家对ESB和IE的应用会比较模糊，经常会出现误用的情况。ESB和IE的区别是什么？技术上各有哪些侧重点和优劣势呢？本文将结合台州医院的部分应用场景，对以上问题进行探讨。

  ESB 是用于服务协调、编排的一个很好的通用解决方案。在进行数据集成时，系统内的应用可以直接调用ESB内的服务，可大幅度减少接口接入的复杂度和工作量，大幅度降低实施难度和实施成本。

  快速并行处理消息：在无需保证消息或服务请求顺序的情况下，可同时处理不同请求，实现高性能请求应答模式。

  侧重于同步消息处理：收到外部系统调用服务请求后需要等待连接的应用系统处理请求，等处理完成后将结果返回给外部系统。如果外部系统调用服务失败，外部系统负责重试再次调用服务。

  优点：能够支持不同的接入系统和传输模式，传输效率高，易于实现集群架构，提高信息系统架构的灵活性，降低内部信息共享的成本。

  缺点：缺乏对医疗标准的支持，需要针对医疗行业的特殊性进行大量二次开发，因此导致实施代价和维护成本很高。

  相比ESB的通用性，集成引擎是专门针对医疗行业而设计的数据交换集成工具，突出的是医疗场景下的应用，其最大的目的是在不同系统或应用程序之间实现互操作，达成业务流程联通和数据共享，很典型的是面向消息的集成。

  保证消息传输：能记录整个消息处理流程和每个节点的消息，这一些内容将保存一定的时间，以供用户查看或修正后重新处理。

  侧重于消息的异步处理：收到外部系统请求后，集成引擎可对外部系统立即应答，外部系统即完成工作，集成引擎负责消息后续处理。如果消息后续处理失败，集成引擎会负责重新尝试给信息的接收方传输消息。

  保证消息传输的顺序：在医疗行业，消息的顺序很重要。在保证消息传输顺序时需要单线程逐一处理接收的消息。

  支持的医疗标准：传统集成引擎作为专为医疗行业而设计的产品，支持的医疗标准更加全面，如HL7、CDA、FHIR等。

  易用性：部分集成引擎产品是配置型产品，具备行业特征，内嵌医疗场景下的常用功能，省去了进一步编码的过程，可缩短项目周期。

  优点：能实现不同部门之间的基于HL7消息的集成。集成引擎专为医疗数据交换而设计，也易于实施使用。

  缺点：传统集成引擎难以实现集群架构，有单点故障隐患，因此在高并发、大流量环境下时常出现功能瓶颈，严重时甚至会宕机。仅使用集成引擎的医院，信息部门技术人员会为平台的稳定性和可用性困扰。

  号源查询：需要对外统一的预约信息查询接口，同时能为院内自助机及服务台、患者的移动App以及外部预约平台等提供号源查询服务。

  门诊预约服务：患者及家属可通过本院或第三方预约平台实现对集团下4家医院做在线预约挂号，并能够返回预约结果。

  号源查询要求响应速度快，有同步处理要求，响应时间不能超过3秒。对于查询的内容可以依据业务变更灵活调整。

  门诊预约和取消预约业务对于响应要求不高，但要保证消息的传输以及传输时的顺序，因此在应用端的预约和取消预约通过异步做处理，结果信息的接收可通过发短信或刷新实现查询。

  因此在这个场景中，号源查询业务适合通过ESB实现，而门诊预约和取消预约业务适合通过IE实现。在处理一个外部入口的所有请求时，应该要依据具体业务中数据的传输模式要求不断进行调整。

  此流程包括检验申请单提交通知、检验申请单计费确认通知、标本采集通知、标本送检通知、标本核收通知、标本退回通知、报告审核通知以及相对应的取消通知等。

  该场景下，流程和消息路径由消息头的关键词决定，通过业务编号对HIS和LIS数据库进行异步操作。

  在检验申请的业务场景中，由于检验相关的业务中保证消息的传输以及传输时的顺序很重要，因此IE是较为适用的该场景下数据传输模式的集成中间件。

  医院内部不同的系统都会有对外的接口供调用，这些接口客户端种类非常之多，包括电子病历、医疗、检查、检验等多个系统和客户端，被调用的接口也多种多样。一定要通过统一的内部接口来管理分发，这样子就能够更有效地管理内部接口，规范化交互标准。

  由于这一些数据调用的发生可能存在多个调用消费端及多个服务生产端，而且数据吞吐量大、并发高，还需要满足调用分发的要求，因此ESB更适合该场景下的数据传输模式，能实现并行处理、快速响应。

  可以看出，ESB与IE各有侧重，适用于医院不同的应用场景。ESB适合需要快速响应、同步处理消息、高并发、高数据吞吐量的场景；IE更适合对于消息请求响应速度要求不高，但要保证消息的传输以及传输顺序、异步处理消息的场景。

  当前，区域医疗、医联体、医共体建设不断推进，医院所扮演的角色和业务慢慢的变多。5G、混合云、物联网、容器化等新技术、新环境的出现，让应用的更新迭代速度慢慢的变快。医院内部或多院之间的数据交换会慢慢地加强，线上线下服务会也会更方便快捷。随之而来的是，医院将会面临更复杂、更多样的场景。

  因此，医院建设集成平台时选择何种数据交换技术，不应拘泥于一种技术形式，而应以场景需求和应用实践效果为出发点，结合自己真实的情况以及医院未来信息化方向，灵活使用各种技术，更好地发挥集成平台的价值，赋能临床业务发展。