InterSystems开发者社区汇集了大量有用、有趣的实践探讨。我们今天推荐的是InterSystems中国技术总监乔鹏的一篇长文：漫谈应用集成的现在与未来。

全文很长，分为五部分。包括：

1.什么是应用集成？

2.如何做应用集成？

3.什么是集成平台？

4.集成方案与评价

5.应用集成的发展

为便于阅读，我们将长文分为上、中、下三篇进行推送：

上篇-什么是应用集成？互操作≠集成

中篇-什么是集成平台？集成平台概念辨析与定义

下篇-集成方案与评价，以及应用集成的发展

-以下为正文-

上篇|什么是应用集成？互操作≠集成

 

关注FHIR的大侠们估计都注意到了，FHIR更新了它支持的互操作范式，除了消息、文档、服务、API这4种，增加了2个：资源仓库、订阅。前面4个好理解，为什么资源仓库和订阅会成为FHIR的新的互操作范式？互操作与应用集成是什么关系？

这里借FHIR的新互操作范式，聊聊应用集成，看看集成平台是什么？有什么样的集成方案？以及怎么评价不同的方案。

01

什么是应用集成？

集成的概念应用广泛，往往被滥用和误用。例如数据集成，传统意义上是指通过ETL（数据抽取、转换和加载）实现的数据集中；界面集成是指通过单点登录解决人工用户跨应用访问的问题。它们都和我们讲的应用集成是两码事。

那什么是应用集成？

应用是一系列业务功能的组合。传统应用基本都是单体架构应用，无论是哪种软件架构开发的。单体架构应用的特点是独立运行、业务功能边界清晰。正因为不依赖于其它应用就可以完成业务边界内的功能，通常单体架构应用并不具有完善的应用交互能力，例如完善的接口。当单体应用间在特定业务流程上需要协同工作时，例如医生站下达的检验医嘱需要立刻通知到检验科信息系统，就需要把这2个或多个应用集成在一起自动实现业务流程协同工作，这就是应用集成。

要实现应用集成，双方应用必须解决接口问题、采用同步还是异步通讯问题、数据格式互相理解问题、术语统一问题、出现数据与业务异常如何表达异常问题、互相调用接口出现网络等错误时是否重试以及如何重试问题...所以完善的应用集成并非易事。

早期解决这些问题是通过点对点的方式，从《2019-2020年度中国医院信息化状况调查报告》来看，即便在互联互通成熟度标准化评测已经开展了8年的今天，在经济发达地区，点对点集成的方式仍占比高达55.81%（34.6%+21.21%)。

 

《2018-2019年度中国医院信息化状况调查报告》揭示了更详细的应用集成方式统计：

由于没有中间层，点对点集成的双方必须事先同意接口方式、同步/异步通讯方式、数据格式、术语、响应异常代码等，同时要处理包括通讯异常在内的各种连接故障和异常。而且对于复杂的业务流程，一个应用可能需要同时与多个应用对接以交换数据、调用接口，开发变得非常复杂。在应用数量不多的情况下还能勉强支撑，对于动辄数十甚至上百个业务系统的行业环境，点对点的开发成本、运行风险、排故难度都非常高，而灵活性很低。这也是集成平台诞生的原因。

02

如何做应用集成？

无论什么应用集成方式，重要的都是梳理和实现应用集成的三个要素：事件、上下文、流程。

2.1集成三要素

2.1.1事件

事件是数字化表达的业务行为记录，是应用间业务流程的触发点。它在业务节点上，触发应用之间集成的流程。通常事件是由上游业务系统的操作触发的，例如医生在医生站下达药嘱，即药嘱事件。

仅由这些基础业务系统的事件驱动业务，往往是不够的。例如如果这个药嘱有用药风险，是不是要提示，这个提示其实是一个临床决策事件。灵活的应用集成方案应具有事件生成能力：基于基础业务事件产生决策事件的能力。

基础业务事件需要梳理，要具有足够的业务覆盖度，且应该与被集成的应用无关。也就是业务决定了业务事件，更换任何一家厂商的应用，都不会影响医院有这个业务和相应的业务事件。行业集成标准通常都梳理了基础业务事件，例如HL7 V2、HL7 V3消息里都定义了业务事件。

在项目方案中，集成平台如何实时捕获这些业务事件？这些事件通常是业务变化时在应用中可以捕获的信息变化，集成平台通常可以通过这些方式得到这些信息变化：

• 应用主动通知，例如应用调用集成平台发布的SOAP服务。这种方式说明被集成的应用具有基于标准的接口能力，或需要在项目现场改造。

• 被动由集成平台发现，例如平台通过SQL适配器发现应用后台数据库的数据变更。

2.1.2上下文

被集成应用间，需要传递的不仅仅是数据，而是能表达业务行为的完整信息，我们称之为上下文，或者语义。就像只给一个值为39的数据是没有意义的，需要完整表达患者的额温是39摄氏度这样的信息。这仅仅是数据项，还需要通过数据模型表达数据项之前的关系和完整度，例如表达体征记录事件的数据模型，不仅要包含体征的信息，还要表达是哪个患者的、是发生在哪次就诊过程的。

 

能完整表达这些信息的数据模型才是我们说的上下文。

这个数据模型应该具有业务场景的普适性，即这个模型应该能普遍表达业务场景里业务实体的数据，而不是特定应用要求的那些数据。例如在医疗行业，共享和交换患者的基本信息，它的模型应该能满足大部分业务场景对患者的数据需求，而且应该尽可能只通过一个患者模型就可以满足多数场景的需求。原则是不能仅根据项目需求去谈数据需求，否则模型大概率会随业务需求的轻微变化而发生重大变化，从而影响整个集成环境的稳定。

2.1.3流程

流程是被集成的应用边界之间的信息流程。梳理流程是做应用集成的基础。例如，医生站下达的药嘱，要先给药品知识库系统判断风险，在没有用药风险后再发给发药系统，这就是典型的应用间集成的流程。随着越来越多决策支持系统的应用、流程闭环需求的增加，跨应用流程建模与管理越来越重要。

流程可以通过改造各个应用，由各个应用实现，但这样流程被割裂在各个应用中，难于理解和再造。因此流程通常会由集成平台实现，从而实现：

• 流程的统一建模与管理

• 图形化、直观

• 灵活的流程调整和再造

流程如何建模？可能完全通过代码实现、可能通过设置消息路由规则、也可能通过图形化的业务流程建模。建立流程，还要考虑调用是同步还是异步？使用什么流程架构，例如通过事件驱动架构（EDA），来实现更灵活、松耦合的应用集成流程？

另外，在应用系统边界之间，特定的流程节点可能需要人工干预，例如新冠大流行期间，门诊分诊时对没有24小时核酸的患者，护士需对其进行抗原检测，这个流程并不在HIS系统中存在，是当前应用之外的人工工作节点。这些人工工作，也应该被流程建模实现。

2.2应用集成的级别

业务集成，可以做得非常简单、也可以做得更完善，取决于集成的目标——要做到什么级别的应用集成。

HIMSS将应用集成定义为4个不同的级别。

 

基础级别，仅仅打通了系统间进行数据通讯的通道，也就是接口。

结构级别，在基础级别上，定义了数据交换的格式和语法；在这个级别上，通常这些交换的格式和语法是集成的双方坐一起讨论出来的，换一家应用集成，大概率格式语法就不同了。

语义级别，建立在行业通用的基础模型和数据编码上，使用标准化的行业语义来定义数据元素、使用标准的值集。语义级别的信息集成是全行业可以理解，并有确定行业意义的信息集成级别。或者说语义级别的信息集成才是基于标准的信息集成。

在应用集成领域还经常说“互操作”这个词，语义级别的应用集成就是互操作。这也是互操作和应用集成的差异！后面我们会更多使用互操作这个词，表达语义级的集成。

 

组织级别，通常都是由国家、国际行业协会和行业标准开发组织开发的。它加入了政策、社会、法律等方面的考虑，分析了通用的业务流程和工作流，在此基础上设定了参与信息集成各方的角色、权限和知情同意策略等。我们的互联互通成熟度标准，就是组织级别的互操作。

2.3行业互操作标准在集成中的价值和作用

在医疗行业，通常需要的信息集成要达到语义级别，才能保障医疗信息准确和医疗行为安全。

要达到语义级和以上级别的信息集成，需要基于或参考标准。这些标准应该是行业级的、五位一体的标准：

 

• 词汇/术语标准：相互通信的健康信息系统依靠结构化的词汇、术语、代码集和分类系统来表示健康概念。词汇/术语标准就是表达健康概念的标准，例如世界卫生组织国际疾病分类标准：ICD-10,ICD-11。

• 内容标准，描述信息交换中，数据内容的结构和组织。它还包括通用数据集的定义。CDA、HL7 V2消息都是内容标准。

• 传输标准定义了计算机系统、文档架构、临床模板、用户界面和患者数据链接之间交换的信息格式和传输方式。传输方式确定了健康信息交换的“推”和“拉”方式。DICOM、IHE等规定了传输标准。

• 隐私和安全标准是确定谁、何时、出于何种目的、使用哪种个人健康信息的权利，以及如何维护健康信息的机密性、可用性和完整性的标准。美国的HIPAA和欧洲的GDPR都是关于隐私和安全的标准。

• 标识符标准是用来唯一标识患者、机构、医护、设备等实体的方法。例如咱们互联互通里用到的OID。

行业互操作标准由行业标准化组织发布，是基于对行业业务的梳理与分析，构建用于行业集成的标准。因此这些标准在表达业务上下文的完整程度、业务事件的归纳、业务流程的梳理与适配、可扩展能力通常都比较好，也就是对集成三要素的抽象更加完整和适用。由于行业采纳度上较高，通过这些标准的推行可以达到更一致的建设效果和通用性。

医疗行业的互操作标准还不少，例如DICOM的影像学互操作标准、HL7 V2、V3的临床消息标准、HL7 CDA的共享文档标准、HL7最新的FHIR、IHE的服务标准，还有我们自己的互联互通成熟度标准。

 

图：医疗行业常见标准出现的历史

11月30日（下周三）将推出“中篇”，敬请期待！

什么是集成平台？集成平台概念辨析与定义

集成平台并非是一种技术或一个方法论，而是整合后的一系列与应用集成相关的技术和特性的工具箱。对集成平台特性的不同理解也造成了市面上对于集成平台以偏概全或不准确的误读，例如集成平台就是消息引擎、集成平台就是ESB、集成平台就是中间件......这里试着讨论集成平台功能的同时，将这些不同技术、概念与集成平台区分开。

点击此处加入InterSystems开发者社区（中文版）查看全文