医院在进行信息化建设时普遍会以HIS系统为主系统建立框架，辅以服务于医院的各专科部门的子系统模块，然而这样的信息化的系统产品仍然不能完全满足医院要求。因为这种系统对信息的集成，传输，交互，用户体验以及数据中心的应用做的不够到位，同时子系统的功能重叠，模块组成不清晰，对医院造成很大困扰。

在这个基础上，为了进一步达成消息的传输和数据共通，推动医院的信息化建设。医院通常会用到以下三种产品，即ESB,集成引擎 (Integration Engine) 和ETL。我们如何在其中进行甄别，选出最适合当前医院场景和需求的产品？

ESB企业服务总线，是一种提供应用程序和服务集成的软件架构。在ESB的软件架构中，组件之间的交互以及通信通过总线提供的服务来实现。而ESB这个软件架构，是构建基于面向服务体系结构(SOA)解决方案时所使用基础架构的关键部分。ESB的主要贡献就是简化了不同系统或应用程序之间的数据集成。

过去医院采用的是点对点模式 (如图1)，在那个模式下几乎所有模块都需要进行相互对接以保证数据能够在不同系统之间进行传输和共享。

随着企业的发展，使用传统的点对点模式已完全不能满足医疗信息化的发展需求。ESB 在帮助医院在进行数据集成时，系统内的应用可以直接调用ESB内的服务 (如图2)，能大大减少接口接入的复杂度和工作量，大幅降低实施难度和实施成本，因而得到了医院的青睐。

ESB的侧重点:

1. 提供服务: 可根据客户的请求和事件提供路由，数据转换，翻译。

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

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

虽然说ESB能够支持不同的接入系统和传输模式而且传输效率高，能够简化企业整个信息系统的复杂性，提高信息系统架构的灵活性，降低企业内部信息共享的成本。然而通用的ESB 对于国际医疗标准缺乏支持，需要添加额外的组件，需要做大量的开发工作。因此在医疗行业中，单单运用通用的ESB软件在解决医疗场景需求时经常耗时耗力，实施成本高。

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

集成引擎具有以下特点：

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

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

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

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

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

也许有人会问了，那既然集成引擎是针对医疗行业的专用产品，为什么国外还有这么多医院还会在用集成引擎的同时还在用ESB呢？一般来说，医院在建立数据集成时的需求有很多，但是有几点需求是非常关键的：

1. 全面医疗行业标准以及各标准间的转换

ESB和集成引擎虽然都可以完成这些要求，但是完成的代价是不一样的。集成引擎是专门针对医疗行业设计的，所以标准支持会更多，而ESB往往需要花费更多代价去研发和配置以支持医疗标准。实际案例中某医院利用通用ESB产品实现了HL7 的落地，但反馈是需要自行开发添加HL7标准库并对其进行支持。再加上由于初期对HL7标准的了解有限，增加了开发的难度。总体来看，复杂度高周期长。

2. 消息的保证传输

集成引擎在最初设计时就已经从产品上实现了这个需求。ESB虽然也能实现保证传输，但需要借助其他组件共同完成，比如需要消息库来做各个节点的落盘存储，需要消息队列来实现消息处理的顺序，需要缓存组件来提高处理效率等等。然而将这些系统和ESB都集成调试好所需的代价很高。某医院（同上例）在通用ESB基础上加入了额外的数据库来存储消息，并加入了队列机制，花费了大量的时间进行开发工作，稳定性和可靠性仍差强人意。

3. 大数据量传输， 衔接5G，云计算等新时代技术产品

传统的集成引擎能实现部门级的应用，但传输的效率难以支持大数据量的传输，衔接5G，云计算等新时代技术产品也很困难。例如，某医院利用传统集成引擎产品实现全院集成并提供数据服务，但在日门诊量超过6000后经常出现系统不稳，性能不佳的现象，有时甚至出现系统死机的情况。

因此，有些医院会同时购买集成引擎与ESB,并根据不同情况对数据的传输模式进行调整。这确实满足了医院的需求，但这就意味着医院需要购买并维护两套设备，学习使用两种不一样的产品，导致产品花费多，维护成本高，项目周期长。

ETL是Extract(抽取)，Transform(转换)和Load(加载)这三个过程的简写。

在ETL中，抽取(Extract)是第一步。ETL需要将同一数据源或不同数据源中数据进行提取，实际操作中我们需要考虑很多潜在问题，包括哪几个系统中的数据需要提取，各自使用什么数据库，是否有手工数据，数据是结构化，半结构化还是非结构化的等等。

第二步则是数据的转换(Transform)通过数据清洗处理数据并将其转换为适当的存储格式/结构，以便用于查询和分析。数据清理就是仅将适当的数据传递给目标，将不满足要求的数据进行过滤。数据格式的转化则主要包括数据一致性的转换（将不同系统的相同类型数据进行整合统一）、数据的细化程度转换（数据粒度转换），以及不同规则下的数据标准/编码的转换计算等。

最后一步则是加载(Load), 就是将整合完的数据插入到最终目标数据库，如数据仓库，数据湖等，然后就能随时进行调用和分析了。

场景一：

根据HL7的医疗卫生标准，病人的信息必须要按顺序进行传输，比如病人的门诊挂号消息应该发送到检验系统，然后再将检验申请消息发送给检验系统。在这种情况下，传统集成引擎就是一个更匹配的解决方案，因为它能保证消息的传输顺序且满足国际通用医疗卫生标准

场景二：：

某病人在网上查询开通挂号的医生及时间段进行预约挂号， 而同时有很多其他病人也在进行查询和预约挂号。这种高并发性无顺序需求的查询服务请求使用ESB来处理就非常适合。

场景三：

某医院需要每晚向卫生局上报当日的医疗信息，包括门诊信息，住院信息，病人信息，相关检验检查等等。这些数据总量非常大，集成引擎或ESB并不适合处理这种情况。这时就需要使用ETL的特性来将海量数据从医院导入卫生局的数据库中。

Integration Engine (集成引擎): 能实现不同部门之间的基于HL7消息的集成。集成引擎专为医疗数据交换而设计，也易于实施使用，但是难以随着客户需求和流量的增加而扩展。而且，传统的集成引擎也存在下列隐患：有单点故障隐患；高并发、大流量处理时有时会出现功能瓶颈，严重时甚至会宕机。

ESB (企业服务总线): 能实现机构之间和区域中的服务协同。ESB是用于服务协调、编排的一个很好的通用解决方案，但缺乏对医疗标准的支持，从而导致实施代价很高。

ETL (抽取，转换，加载): 能进行数据同步以供生成报告和实现商业智能应用。但完整成熟的ETL产品价格比较昂贵，通常对医疗机构来讲是一种浪费。

现在大家对于ETL,集成引擎和ESB都有了一定的了解，但是不论是ETL,ESB抑或是集成引擎，都有对应的缺点和不足，而三者同时购买所耗费的成本又太高。对于医院来说，如何在其中进行甄别，选出最适合当前医院场景和需求的产品，就是一件极为重要却又非常需要费心的事情了。因此，医疗机构迫切需要能够具备以上三个功能的集成产品。

• 集成引擎
• ESB
• ETL