层次化数据融合在智慧医疗中的应用

层次化数据融合用于智慧医疗

鲁斯泰姆·多托夫1*† ，萨尔瓦托雷·迪斯特凡诺1,2†和拉朱库马尔·布亚3†

引言

医疗是物联网技术广泛应用并持续改进的众多领域之一，这些技术被用于支持医疗机构的核心功能。通过这种方式，传统医院转变为下一代智能数字环境，广泛使用互联传感器系统以及（大数据）数据采集/处理技术。从这一角度来看，智慧医疗可被视为由智能空间（如医院病房、救护车、药店等）组成的复杂生态系统，该系统由强大的基础设施堆栈（包括边缘设备和传感器、有线和无线网络、云平台等）提供支持，并由推动医疗行业4.0的创新商业模式和法规驱动。

摘要

物联网（IoT）通过将现有环境转变为传感器丰富、以数据为中心且自动化程度不断提高的信息物理系统，推动智能空间的构建，从而催生工业4.0。在商业/工业场景中应用这一趋势，正在彻底改变我们日常生活的诸多方面，包括人们获取和接受医疗服务的方式。随着我们迈向医疗行业4.0，智慧医疗空间所依赖的物联网系统在规模和复杂性上不断增长，因此必须确保海量收集的数据能够按照既定要求得到妥善处理，以提供有价值的洞察和决策。本文聚焦于智慧医疗领域，探讨在由边缘设备、网络与通信单元以及云平台构成的物联网网络中的数据融合问题。我们提出一种分布式层次化数据融合架构，在该架构中，不同数据源在物联网分类体系的每一层级进行整合，以生成及时且准确的结果。

通过这种方式，在呈现的智慧医疗场景中，一旦必要信息被生成和收集，即可在最短时间延迟内做出关键任务决策。所提出的方案采用复杂事件处理技术实现，该技术原生支持层次化处理模型，并专注于“实时”处理流式数据——这对于存储受限的物联网设备和时间敏感的应用领域至关重要。初步实验表明，该方法能够在不同的数据融合层次实现细粒度决策，从而提升公共医疗服务的整体性能和响应时间，推动物联网技术在医疗行业4.0中的广泛应用。

关键词 ：智慧医疗, 工业4.0, 数据融合, 复杂事件处理, 分布式架构, 物联网, 边缘计算, 云计算

开放获取
© 作者 2019年。本文根据知识共享署名4.0国际许可协议（http://creativecommons.org/licenses/by/4.0/）的条款发布，该协议允许在任何介质中不受限制地使用、分发和复制，前提是适当注明原始作者和来源，提供知识共享许可协议的链接，并表明是否进行了修改。

研究
Dautov 等. 《大数据杂志》（2019）6:19 https://doi.org/10.1186/s40537-019-0183-6
*通讯作者：rdautov@it.kfu.ru
†鲁斯泰姆·多托夫、萨尔瓦托雷·迪斯特凡诺和拉朱库马尔·布亚对本文有同等贡献
1 喀山联邦大学，喀山，俄罗斯 作者信息完整列表见文章末尾

本文档由 funstory.ai 的开源 PDF 翻译库 BabelDOC v0.5.10 (http://yadt.io) 翻译，本仓库正在积极的建设当中，欢迎 star 和关注。

智慧医疗的基础是智能低功耗无线连接医疗设备。这些设备持续测量、处理、采集并保护由传感器收集的生物识别数据，包括体位、体重和活动、睡眠质量、血压、血氧饱和度、体温、心律和心率、血氧、疲劳程度、呼吸频率等。[3,33]这催生了医疗物联网（IoMT）[12, 20]。通过将传感器嵌入到内部空间和医院设备（如病床和轮椅）中，使其成为“医疗物品”，医院工作人员在执行日常工作时，可通过无线连接远程在其计算机和/或移动设备上接收和查看有价值的生物识别信息。这样，医生能够做出即时决策，从而可能挽救生命。然而，在大多数情况下，尽管所收集的信息及时且精确，但仅用于向医院工作人员展示，最终决策仍由他们基于接收到的信息负责作出。从这一角度来看，发现各种人体指标之间的潜在相关性——即融合来自多个源的数据——是由医生手动完成的，医生需运用其知识和经验来检测或预防潜在的危急情况。

事实上，单一信息源通常不足以做出可靠且合理的决策。因此，需要多种数据源的组合，无论是流式或静态数据。医生进行诊断便是这一背景下的典型示例——即医疗专业人员只能基于多项检查（如血液和尿液检测、血压、血液温度、心率等）来诊断疾病，而不仅仅依赖一项检查。诚然，仅检测到单一健康指标（如体温）的异常并不足以诊断疾病，因为体温升高的原因可能有很多。为此，医生通常会依据多项检查，并通过对这些多个数据源进行人工数据融合（通常越多越好），以尽量减少不确定性，最终得出精确有效的诊断。同样地，多源数据组合的原则也适用于自动数据融合，尤其是在智慧医疗场景中，来自空间分布位置的不同（大规模）数据流必须在实时约束下进行“融合”。

此外，在某些更复杂的情况下，单个医生可能没有足够的信息和/或经验来做出诊断。在这些情况下，为了诊断问题，需要由具有不同专业背景的医疗专业人员组成的医疗委员会讨论并关联各自的个人发现，然后由委员会负责人根据各个委员提供的输入做出最终决定。从这个角度来看，该医疗委员会类似于一个层级组织，其中下级成员向上级决策者提供信息。

然而，随着这些有前景的机遇而来的是新的挑战，即如何处理和管理由数百万个传感设备持续生成的海量数据。在这种情况下，一个尤为紧迫的问题是实现多组数据平滑地集成到一个一致、准确且有用的表现形式中——也就是说，进行数据融合[29]。更正式地说，数据融合的目标是

来自多源数据的相关信息合并为单一结果，以提供比任何单个数据源更准确的描述，并最小化不确定性[19]。

现有的实现物联网数据融合（包括智慧医疗领域）和处理的方法主要采用以云端为中心的模式，即边缘设备收集的原始数据被推送到云端，而云端被视为主要的处理位置[28]。然而，这种垂直卸载模式往往忽视或低估了边缘设备日益增长的计算资源在支持数据分析和处理（包括数据融合）方面的作用[10]。因此，一些相对简单的数据融合任务并未在本地立即完成，而是通过可能拥塞的公共网络被推送到云端服务器，从而引发若干问题。首先，由于未在本地处理简单任务，整体响应时间因网络延迟和带宽限制而显著增加。其次，通过公共网络传输潜在敏感数据会带来更高的安全风险，而采用额外的数据加密技术来应对这一挑战又会引入不必要的计算和网络负载。第三，由于未充分利用边缘设备的计算资源，该模式要求云端承担更大的（大数据）工作负载，这也可能导致租用和运行云端服务的整体成本上升。

因此，以上述考虑为参考，本文提出了一种面向智慧医疗生态系统的分层自动化数据融合架构，其中各个元素根据其背景知识和处理能力对多源数据执行数据融合。通过这种方式，较低层次的元素执行相对有限的数据融合，并将聚合信息传递给较高层次的元素，而这些元素在融合接收到的信息后，可进一步将新聚合的信息向上传递至层次结构中的上层元素。所提出的架构采用复杂事件处理（CEP）技术实现，该技术旨在原子事件流中检测复杂事件模式，并为在分布式物联网系统（如智能医院）中实现数据融合提供了一种潜在途径。[8, 9],部署在传感器数据源附近时，该架构力求尽可能利用本地处理能力，或将其余任务卸载至雾/云端计算——从而为多层分层数据融合方法铺平道路。正如后文将通过一个医疗用例场景进一步讨论和演示的那样，该方法能够在不同的数据融合层次实现细粒度决策，从而提高整体性能和响应时间。因此，本文的贡献主要体现在三个方面：（i）一种用于数字医疗中及时决策的细粒度分层数据融合方法；（ii）基于CEP技术的系统原型实现；（iii）对概念验证实现与现有集中式方法进行评估与基准测试。

因此，本论文的其余部分组织如下。在“背景”部分，研究了物联网生态系统和数据融合方法，以确定主要的处理架构和数据融合模式。接下来，在“方法”部分，将这些模式和物联网处理模型映射到智慧医疗领域的一种三层分级解决方案中。该部分还提供了将此解决方案应用于智慧医疗服务的示例，并展示了所提出的分级

背景

创新背景的工业4.0

工业4.0由多项技术支柱支撑，包括云计算、大数据分析、信息物理系统和物联网[24]。得益于网络技术、移动技术和嵌入式技术的最新进展，通过广泛部署智能传感器进行数据采集，这些技术有助于实现高度自动化的以数据为中心的面向服务的业务流程。因此，大量配备多种传感资源以及相对高级的计算、存储和通信能力（因而具备智能属性）的设备已普遍存在于人们的生活中，旨在提升生活质量。这些具备传感器功能的智能对象通过互联网连接，从而形成一个由远程可访问的数据源构成的全球网络，可供发现并集成到复杂的信息物理系统中。

因此，这一新范式为提高工业自动化水平和前所未有的商业模式开辟了道路。此外，工业4.0原则也正在彻底改变其他公共和社会领域（不一定与生产和制造相关），包括医疗系统，从而催生了类似的医疗4.0、医疗行业4.0以及智慧医疗等概念。这些新兴趋势的目标是“实现渐进式虚拟化，以便为患者、专业人员以及正式和非正式护理者提供健康与护理的个性化和实时支持”[36]。尽管这些概念通常与智能医院的概念相关联（智能医院仍然是医疗系统的核心），但医疗行业4.0和智慧医疗远远超出了单一医院的范围，涵盖多个医疗机构、公共管理机构、办公室、政府以及公共卫生服务。在此背景下，重要的是确保医疗4.0的实现不是通过旨在将孤立的诊所和医院单独‘智能化’的垂直且不可持续的解决方案，而是通过一种全面的智慧医疗解决方案，能够覆盖更广泛的场景，涉及多个组织和利益相关者。从这一角度来看，进一步实现（智慧）医疗行业4.0愿景需要一种全局性方法，并依赖于物联网、大数据分析和云计算等不同信息通信技术领域的技术融合。

目前，智慧医疗领域在数据管理和处理方面普遍采用的解决方案是将相关任务卸载到远程服务器，这些服务器通常位于数据中心和云平台，负责收集、存储和处理数据，从而推动物联网与云计算范式之间的交互[11]。在这方面，智慧医疗主要采用了“垂直”卸载范式，即由边缘设备收集原始传感器数据，并通过多个网络链路经由网络传输至中央处理位置。这不可避免地意味着原始生物特征数据在生成后立即被发送出去，从而对底层网络带宽产生严格依赖。因此，由于底层（无线）网络及相关（3G/4G）服务提供商的限制，这一要求往往显得难以承受或不可持续，这

影响整体处理延迟。尽管存在这一限制，（资源受限的）边缘设备仍不期望自行执行数据处理，而是必须通过网络拓扑推送收集的数据，即使它们可能已经具备足够的本地处理、存储和计算资源，这些资源可在传感器融合（例如过滤、预处理、本地分析）中加以利用，从而在性能和网络延迟方面带来优势。

此外，网络通信与处理单元（如移动边缘云 (MEC) 服务器和云粒）[37],通常具备足够的能力来支持此类计算。该模式由边缘/雾计算范式提出，旨在将智能推向网络拓扑的边缘[17]。在边缘/雾计算中，网络设备、物联网网关、交换机、路由器、服务器和云粒被广泛用于支持来自边缘节点的计算任务。这补充了传统的云端卸载方式，并克服了带宽限制，缓解了网络延迟和延迟问题。因此，通过利用并结合本地资源以及网络（即边缘/雾计算）和远程（即云计算）处理节点提供的资源，有可能实现一种能够在考虑边缘设备资源限制的同时最小化成本和延迟的解决方案。为此，下文将讨论有关基础设施和软件/数据管理解决方案的相关概念和见解，为有效融合的智慧医疗解决方案提供基础。

基础设施：物联网、边缘、雾和云端

从基础设施的角度来看，智慧医疗生态系统由多个互连的边缘设备、网络节点和（虚拟/物理）服务器组成。这些元素连接到物联网网络中，其能力各不相同，可根据表1中总结的分类法分为四类。在此分类法中，根据特定节点提供的资源确定了六个特征。“传感/执行”参数指的是传感器和执行器的存在，它们提供相应的功能。然后，基本网络连接功能称为“互联网设施”。其他特征与处理和内存/存储能力相关。“高级连接性”功能指转发和/或路由功能，以及对软件定义和虚拟化网络的支持。最后，“服务/资源供应”能力允许以面向服务的方式按需向第三方提供资源和服务。

表1 物联网资源类别

类别	属性	执感行知设互施联网处理存内储存，高连级接性服务， 资供源应
设备	X	– – * – –
传感器节点—基本网关	*	X – * – –
智能对象—智能网关	*	X X * – –
通信和处理‐ 单元	–	X X X X –
数据中心	–	X X X * X

基于这一系列特性，Device 可被视为具有感知与执行能力但不具备任何网络设施的简单节点，因此需要物理连接到接入点/网关以发送采集的数据。它可以具备一定的（有限的）存储能力，在发送前将多个测量数据聚合为批次，以最小化能耗（这对电池供电设备尤为重要）。例如各种生物识别传感器、执行器以及多种传感器板/扩展板。

基础节点网关 是一种负责将数据从边缘设备传输到互联网（即采集传感器数值），或反向传输（即发送执行命令）的节点。它可以配备自身的传感器和执行器，或者通过特定的（有线）接口连接到其引脚（例如 GPIO 引脚）。网关中可能具备存储设施，但通常在本地具有有限或没有处理能力。示例包括仅配备微控制器的开发板，例如 Arduino Uno 及类似设备。

智能对象 和 智能网关 是功能更强大的单元，配备了处理设施，从而允许对来自自身或引脚连接的传感器的探测数据进行板载（预）处理。示例包括带有微处理器的智能开发板和单板计算机，例如树莓派和Arduino Yun。

通信和处理单元 是具有高级连接性和处理能力的网络节点和服务器，通常不具备感知/执行功能。它们能够根据雾计算原则，支持由智能对象和网关卸载的数据处理任务（过滤、分析、数据融合等）。例如路由器、多接入边缘计算服务器、基站和云粒。

数据中心提供处理、存储和网络资源，以支持物联网医疗应用，可能通过基于云的供应模式实现。

根据此分类，物联网‐云生态系统中的数据处理可以在三个不同层级进行，如表 2所示：板载（即‘薄雾’或边缘计算）、通信与处理服务器及云粒（即雾计算），和/或远程数据中心（即云计算）。

表2 数据融合分类法

类别	分类法	低级别	中级别	高级别
处理阶段 [22]	Low	中级	High
抽象级别 [30]	Low	中等	High
数据粒度 [32]	原始数据处理	特征级别	决策级别
操作域 [39]	时间的	空间的	时间和空间的
语义 [16]	知识库构建	模式匹配	推理
源关系 [13]	互补的	冗余的	合作的
用户需求 [39]	本地/单节点	区域	全球/整体网络

通过查看表2中的分类法，可以识别出一种清晰的多层架构模式，其中各个层级以分层的方式逐层构建。具体而言，在所调研的分类法中，普遍采用三层模型（尽管有可能扩展为更多层级）。因此，概念上的三级数据融合模型可总结如下：
I. 低级别 包括通常应用于来自源的原始数据的数据融合特征，实现处理的第一阶段或在较低抽象级别上进行处理，执行局部操作，例如在时域中的操作，旨在构建知识库或与其他节点在互补活动上进行合作。
II. 中级别 包括更高级别的特征，可在预处理信息上执行，即前一处理阶段、局部计算或抽象级别的结果，例如获取特定区域的空间域参数估计，或实现特征提取、模式匹配或冗余计算。
III. 高级别 在全局域的最高抽象级别上实施最后的处理阶段，对来自较低层的数据进行推理或复杂推理与决策，或通过利用合作模式等方式实现时空融合。

关于与所提出的分层数据处理模型相契合的具体技术，一种可能具有前景的数据融合方法是在智慧医疗背景下可潜在应用的复杂事件处理（CEP）[27]。与传统的流处理不同，复杂事件处理不仅限于简单的数据查询或转换，而是旨在检测数据流中由较简单的原子事件构成的复杂事件模式。因此，从复杂事件处理的角度来看，持续到达的元组可被视为外部世界中发生的事件通知——例如体温升高或血压突然下降。该视角的重点在于检测代表高层级事件的低层级事件特定模式的发生。一个持续运行的复杂事件处理查询仅在检测到相应的低层级事件模式时才返回结果。例如，复杂事件处理系统常用于检测情境模式，其中一个原子事件严格发生在另一个之后。为实现这一点，复杂事件处理系统依赖于事件时间戳；它们通过扩展现有的查询语言，引入序列化操作符，以规定事件的时间顺序，即简单地说，一个事件在时间上发生于另一事件之前还是之后。

复杂事件处理对输入流进行数据融合的能力已应用于一些场景中，在这些场景下，数据从分布式网络持续推送，并在其到达时立即进行动态分析。更具体地说，已有多个网络入侵检测系统（IDSs）[5, 14, 23]采用复杂事件处理技术实现。这些入侵检测系统旨在集中收集和关联所有网络事件，以检测关键情况，这些关键情况通过预定义的复杂事件处理规则表示。在物联网系统领域，也有使用复杂事件处理技术的实例。类似地，其动机是在分布式物联网网络环境中实现运行时监控和数据融合[6, 15, 18, 38]。诚然，智慧医疗领域也面临着类似的挑战，即如何及时检测和响应所收集的传感器测量数据。

然而，现有文献尚未涉及两个主要方面。首先，现有方法倾向于仅在云端计算的最高层级实现复杂事件处理，从而忽略了在网络和边缘设备层级引入中级数据融合的可能性。其次，缺乏对双向通信的支持——即现有方法仅关注数据采集，而未考虑通过自上而下的方式修改数据融合策略来协调低层级设备。

智慧医疗中的大数据

智慧医疗的兴起引发了由数以百万计的嵌入式传感器持续生成的生物医学数据集的指数级增长，带来了新的技术挑战以及创新/商业机会 [12, 34]。

主要的生物医学数据源包括来自医疗服务提供者的电子病历（EMRs）和电子健康记录（EHRs），以及来自临床试验和制药公司的数据 [31]。为了应对这些海量数据，学术界和工业界致力于提供高效的解决方案，以从多个数据源收集、传输、存储、聚合和分析数据（即数据融合）。

虽然大型医疗数据的存储通过通用存储技术（例如由水平扩展和数据复制支持的关系型和NoSQL数据库）得到了相对成功的解决，但医疗数据集的处理与分析具有领域特异性。具体而言，可以区分出以下三个独立的大型医疗数据分析领域[4]：
- 图像处理 医学图像（例如断层扫描、磁共振成像、放射照相术等）是广泛用于诊断、治疗评估和治疗计划的重要数据来源。此类高分辨率图像若需长期保存，则需要大量的存储容量。在处理方面，医学图像尤其需要快速且准确的解释算法，特别是在图像用于辅助医疗人员进行人工决策时。此外，当此类基于图像的分析涉及其他信息源时，提供统一的存储和处理支持成为一项挑战，需要高级解决方案。近年来，这一挑战已通过应用人工智能技术和神经网络得到广泛关注和解决 [25]。
- 基因组学分析 基因组规模数据已由计算生物学研究广泛探讨，旨在为

临床环境。基因组数据集具有极高的密度，这使得其探索、发现和临床转化成为应用新型大数据分析方法的有吸引力的领域[21, 35]。
- 信号处理 由医疗传感器生成的信号具有数据量和速度的特点。这在医疗物联网（IoMT）背景下尤为具有挑战性，因为每位患者连接的大量监护仪会产生连续的多维传感器读数流[2]。此外，除了数据量和速度问题外，还需要解决生理信号的时空特性，以便通过考虑情境上下文使传感器信号的分析更具价值。这种上下文感知需要嵌入到连续监测和预测性医疗物联网系统中，以确保当前的传感器观测结果与情境相关联。传统上，现有的医疗保健系统往往关注单一信息源，而缺乏从更广泛、更全面的角度理解患者真实的生理状况的上下文。因此，有必要开发更完善、更全面的方法来融合多模态临床时间序列数据[2]——这一挑战目前超出了人类的手动处理能力。正如本论文进一步阐述的，为解决这些问题，我们提出了一种基于复杂事件处理（CEP）的数据融合方法。

方法

提出的方法

智慧医疗生态系统的数据融合架构可以通过将医疗机构内的物联网基础设施能力与现有的数据融合模型相匹配而自然地确定。受表2中分类体系的启发，三级数据融合模型确实天然契合表1中物联网处理单元的分类，将低级别层级配对并部署到边缘设备（即边缘计算），中等级层级配对并部署到通信和处理单元（即雾计算），高级别层级则配对并部署到远程数据中心（即云计算）。基于这一前提，自然可以思考如何利用边缘设备和网络节点来支持数据融合任务。鉴于物联网网络拓扑中不同类型的设备及其位置，以及数据融合模式，本文提出了一种面向物联网医疗系统中数据融合的分层多级架构。根据我们的方法，数据应尽可能首先在本地（即边缘设备上）进行处理，否则按照表2中的三级数据融合模式，逐级推送到通信和处理单元，最终推送至远程数据中心。如图1所示，所提出的架构因此包含三个概念层级，这些层级也可与收集物联网医疗数据的地理区域相对应：

I. 低层次数据融合（LDF） 应在智能对象上进行，这些智能对象通过网关从边缘设备收集数据，或直接来自智能设备本身——数据量相对较小，且数据融合可以在本地执行。LDF 的主要目标是检测个体患者的危急健康状况。通过将流式传感器数据（即 传感器融合）与患者的个人历史健康记录相结合，可以检测潜在的危急健康状况，向更高级别发送相应警报，并通知负责的医院工作人员。例如，通过收集看似‘健康’的传感器读数，LDF引擎能够将其与个人记录匹配，并发现对于该特定患者而言，所观察到的值实际上可能表明健康状况正在恶化。通过这种方式，数据融合——即将传感器读数和静态背景信息进行集成——在尽可能靠近数据源的位置发生，因此只有经过过滤/聚合的值才会传输到上层处理节点，而医院工作人员则会立即获得可能的诊断结果。

II. 中层数据融合（MDF） 是指对来自更广泛设备网络推送的信息进行更深入的分析。在物联网生态系统中，MDF 应在遵循雾计算原则的通信与处理单元上执行。中级别 MDF 在更大的感兴趣区域（如诊所或医院）内进行数据融合，旨在实现两个主要目标。首先，MDF 通过将来自病床传感器设备的关键数值映射到这些设备实际部署的物理位置，来检测或预防潜在的疾病暴发。通过这种方式，MDF 能够识别出可能存在疾病传播的医院病房和楼层。其次，通过识别医院内医疗需求增加的房间和楼层（包括流行性疾病情况），MDF 旨在更高效地组织和管理医护人员（例如，向当前观察到需求增加的特定楼层分配更多护士）。为此，MDF 需要依赖背景知识，即各个传感器设备与其所处房间/楼层之间的映射关系。通过对这些多源数据进行数据融合，系统不仅能够检测突发传染病的传播，还能根据当前需求高效地管理和调度医院人员。

III. 高层数据融合（HDF） 指的是数据融合的最高级别，可提供关于整个受管边缘设备和网络节点系统的全局视图。这涉及大量数据的处理，因此预期在远程数据中心或云端实现。HDF从所有
城市内的医院，并在整个管理的城市地区执行数据融合。首先，通过这种方式，HDF引擎能够提供各个医院及其他医疗机构当前利用率的全局实时视图，并相应地管理应急车辆。更具体地说，它可以将来自医院的流式信息和应急车辆的当前GPS位置，与附近的交通路线和医院位置的静态信息相结合。因此，应急车辆可能会被引导至一家并非距离最近但拥有更多可用医护人员、能够及时提供急救的医院。其次，来自多家医院的传入信息可以进行关联分析，以及时识别并预防区域范围内流行性疾病的疫情爆发——这在近期发生埃博拉病毒病和禽流感疫情的背景下是一项关键任务需求。

值得注意的是，现代物联网系统，尤其是与智慧医疗相关的系统，往往超越了“自下而上”的监控概念——即由边缘设备收集原始数据并通过网络传输——同时还实现了被管理与管理设备之间的“自上而下”反馈通信（例如用于执行指令）。作为此类双向通信的一部分，提出的方法引入了协调的概念，负责上述各层之间的通信。更具体地说，协调具有双重功能：一方面，它接收来自低层级设备的数据，并将其收集和分发到数据融合处理器和引擎，以及在需要时发送至更高层级；另一方面，根据变化的需求上传新处理规则，并修改或删除现有处理规则。

因此，通过在设备上部署并运行数据融合逻辑实例，构建多层级物联网系统，实现了所述的高层级概念性数据融合架构。该架构实现两大主要功能：（i）实际的数据融合，以及（ii）与位于物联网网络拓扑较低层级的设备进行通信，并对分布在低层级节点上的数据处理任务进行编排。图2所示的参考架构描绘了这种关注点的分离——所有三个层级均配备了专用数据融合（DF）引擎实例（即分别为低层级DF—LDF、中层级DF—MDF和高层级DF—HDF引擎），而其中上两个层级还包含协调组件（LDF和MDF协调器），负责低层级与高层级节点之间的双向通信，以及管理来自低层级节点的卸载请求。

这些组件之间的交互由图3中的工作流程表示。最初，智能对象生成的数据被收集并发送到LDF引擎，该引擎首先评估相关数据融合任务是否可以在本地处理，如果可以，则进行处理；否则，将任务拆分为n≥ 1个子任务，然后可在内部重新分配，和/或转发至边缘节点，并与其中层级对应模块（即LDF协调器）进行交互。类似地，该模块对（子）任务进行评估，若可处理则将其发送至MDF引擎。否则，将其分解并在内部重新分配（子）任务，或将其转发至运行在远程数据中心的高层级MDF协调器，和/或返回至LDF引擎。随后，MDF协调器实现了一个类似的过程——即首先评估传入的请求，如果可行，则通过HDF引擎进行处理；否则将请求划分为更简单的请求，重新提交给HDF层级，并通过MDF协调器返回到较低的MDF/LDF层级。

值得注意的是，层次结构中两个上层的存在是可选的，因为LDF引擎可以直接与MDF协调器交互，或者LDF协调器可以仅向MDF和LDF引擎分配请求。该方法在层次结构的层级数量上具有灵活性——即如有必要，可通过在更高层级部署两个或多个引擎和协调器（例如通信与处理单元和数据中心）来支持超过三个层级。

案例研究

智慧医疗领域中自动数据融合的主要目标包括：（i）通过整合多个数据源进行态势评估并最小化不确定性；（ii）支持及时的自动化决策；（iii）降低通过公共网络远程传输数据所带来的安全风险。一种有前景的解决方案是利用普遍存在于物联网网络中的智能对象的处理能力。然而，分布式物联网网络中的数据融合是一个多层面的问题，需要从多个角度加以解决。以表2中的分类法为参考，我们特别考虑智慧医疗领域中存在的以下三种类型的数据融合，并解释如何利用复杂事件处理（CEP）来实现这些融合。

时间数据融合 指的是对来自同一数据源但在不同时间点的数据进行聚合。它关注不同数值的时间顺序，试图在特定时间范围内发现它们之间的时间相关性。例如，需要对体温传感器读数应用时间数据融合，以检测短时间内体温的快速上升，这很可能表示发烧或类似的健康恶化情况。通过使用复杂事件处理（CEP），时间数据融合可以通过顺序操作符（即检测事件的精确时间顺序）和迭代操作符（即检测相对于先前到达值的变化）来实现。例如，前者操作符可以在体温升高严格跟随血压下降时检测到危急情况，而后者操作符则可以识别发烧症状，如体温突然升高和下降。

空间数据融合 是指将多个物理上和/或逻辑上分布的源聚合为一个统一表示。在智慧医疗中，可能需要对来自医院内不同房间的健康传感器的数据进行空间数据融合，以识别流行病模式。复杂事件处理通过条件对单个模式设置条件来支持空间数据融合。更具体地说，可以检查事件是否源自同一位置，或将事件来源与特定预定义位置进行比较。通过这种方式，可以根据数据所来自的医院房间/楼层对接收的传感器值进行分组，或仅提取来自特定（即匹配的）感兴趣区域的子集值。

语义数据融合 指的是物联网医疗领域中各种数据源（即物理和虚拟传感器）的异质性，这些数据源需要被统一表示和聚合，以支持进一步分析和模式检测。语义数据融合的一个示例是基于多个测量的身体指标（如体温、血压、心率等）进行疾病检测与诊断。复杂事件处理本身无法解决多个数据源的异质性问题——这一任务由具体的CEP实现来完成，该实现通过其编程模型提供通用数据表示和格式。也就是说，为了能够在单个CEP模式中处理例如体温、血压或心率等数据，需要将它们定义为编程类（可能是同一超类的子类），并配备相应的属性集合。当相应的传感器读数（可能以半结构化形式，如JSON或XML）进入系统后，它们会被序列化为对应的CEP类，并流式传输到实际的CEP引擎进行处理。

表3 不同医疗层级的数据融合用例示例

数据融合层级	目标	示例数据融合用例	数据融合类型	可使用的CEP操作符
LDF	检测突发健康恶化并向医护人员报告	将个体患者的生物识别信息传输至更高层级的数据融合系统，标明检测到的症状及位置（即房间和楼层）	检测单一身体指标（如体温）在给定时间范围内单调上升，且每个后续值均高于前一个值 检测多个身体指标（如体温、血压、心率）在给定时间范围内快速同时上升	时间、语义
MDF	为需求增加的楼层分配更多医院工作人员 检测医院内的潜在疾病暴发	检测来自同一房间/楼层的相同健康恶化症状	时间、空间、语义	条件检查以将流式值与房间/楼层位置进行映射
HDF	将救护车引导至负荷较轻的医疗机构 检测大都市区内的潜在疾病暴发	检测来自位于同一区域的医院的相同健康恶化症状	时间、空间、语义	条件检查以将医院和救护车与其地理位置进行映射

表3总结了数据融合层次、目标和类型，以及可在每一层次使用的潜在复杂事件处理模式。正如上文示例所示，在实际中，这三种数据融合类型通常以组合形式出现，这意味着相应的复杂事件处理技术也需要结合使用，以满足复杂的数据融合需求。为此，我们考虑了几种可利用复杂事件处理实现的数据融合模式。这些模式反映了样本智慧医疗场景，其中传感器丰富的智能病床持续收集与患者健康状况相关的多种异构数据，并在不同的数据融合层次进行分析和响应。

手动医疗流程的自动化，例如数据采集与融合，有望缩短建立诊断所需的时间。此外，对个体患者的危急健康状况进行及时检测，有可能促进关键任务活动的开展，例如医院工作人员和救护车的有效管理，以及在单个医院或整个大都市地区内对疾病暴发的及时检测。案例研究的最低层级由智能病床构成，这些病床配备了多种生物识别传感器，其中主要考虑血压、体温和心率。请注意，该用例场景仅用于验证所提出方法的可行性，因此相应地进行了简化。

为了验证提出的分层数据融合方法，首先实现了一个初步的概念验证原型。该原型采用Apache Flink1作为底层的CEP中间件。Flink CEP是更大模块化平台中可插拔模块之一，它是一个轻量级开源实现，结合了CEP表达能力（即事件的时间推理和感兴趣的滑动窗口）、相对较低的资源需求以及维护良好的客户端库。因此，Flink CEP组件被部署在分层式智慧医疗架构的三个层级上（如图4所示）。

因此，采用提出的方法和术语，并将复杂事件处理作为底层数据融合实现技术，我们确定了以下三层CEP层次结构。

低层级复杂事件处理（LCEP） 部署在多块 树莓派开发板 上，每块开发板对应一张智能床，因此负责单张床/单个患者的数据融合。在此场景中，Flink CEP 能够检测到一组复杂的 传感器事件（SE）模式，即三个关键指标（体温、血压和心率）均超过临界阈值。系统还会核对患者的个人健康档案，确认这些升高的数值对该患者是否确实构成危险，向指定医护人员提供初步诊断，并向上层发送一个更高层级的 设备事件（DE），传递至下一级复杂事件处理模块。

中层级复杂事件处理（MCEP）部署在服务器上，负责从整个医院范围内安装的多个树莓派设备收集数据，并在更大的感兴趣区域上执行数据融合。它接收来自设备事件的连续流作为输入，其中包含患者诊断结果和设备ID，并通过将流式数据与两种类型的背景知识相结合来进行复杂事件处理。首先，MCEP能够基于先前存储的流行病模式识别疾病传播。其次，它能够将各个传感器设备映射到其所在的医院病房。通过这种方式，系统不仅能够检测突发传染病的传播，还能根据当前需求高效地管理和调度医院人员。最后，MCEP将这些包含医院内潜在疾病信息以及人员当前利用率的聚合值作为医院事件（HE）发送到下一层级的复杂事件处理。

高层级复杂事件处理（HCEP） 部署在 Amazon EC22云端。它从城市内的管理的医院收集数据，并在整个大都市地区进行数据融合。通过将传入的医院事件与包含医院位置、地图和交通路线的静态知识库相结合，HCEP 能够（i）在区域范围检测疫情暴发，以及（ii）向应急车辆提供在线导航指令，引导它们前往负荷较轻的医院。

更具体地说，该案例研究实现了从医院病床到城市区域的三层分级复杂事件处理。为了形式化地描述三层复杂事件处理逻辑，采用了复杂事件逻辑（CEL）[7] 。据我们所知，复杂事件逻辑（CEL）是首次尝试为复杂事件处理领域提供一种形式化逻辑，但尚不完善。目前，诸如相关性和时间窗口等高级复杂事件处理选项和功能尚未实现，因此我们将尝试将示例置于当前的复杂事件逻辑（CEL）核心框架内。本案例研究假设所有设备均为全局同步，且环境中发生的事件均带时间戳。

为了正式描述智慧医疗的案例研究，我们首先需要在此场景中从三个层面定义涉及的复杂事件处理事件。

定义 1 LCEP 传感器事件 SE 由三元组定义
其中，T 是体温样本值；ts 是样本时间戳；id 是设备 ID，用于唯一标识生成该样本的 LCEP 设备。
SE={T, ts, id}

这样，运行在物联网智能对象网关（如表3中所定义）上的LCEP逻辑可以通过以下CEL公式描述（公式1）
捕捉体温突然升高的情况，即无发烧症状的患者（x.T<= 37 ）的体温突然上升（ y.T>x.T），达到发烧状态（z.T> 38 ），即在一分钟内（(z.ts −x.ts)=< 60）。

定义2 MCEP设备事件DE 由以下对定义
其中 SE 是根据公式(1)由LCEP触发的传感器事件集合；rid 是医院房间编号。
运行在雾节点或服务器上的MCEP逻辑由以下CEL公式（公式2）指定
在相同房间（x.rid == y.rid）内的至少两名患者（y.SE[j].id!= x.SE[i].id）在一分钟内（(z.SE[k].ts −x.SE[i].ts)=< 60）检测到类似的健康恶化模式（x.SE[i]>= 38, y.SE[j].T >= 38 ）。

定义3 HCEP 医院事件 HE 由三元组定义
其中 设备事件 是根据公式（2）由MCEP触发的设备事件集合；症状标识 用于识别症状；区域编号 是区域编号。
运行在云节点或服务器上的HCEP逻辑由以下CEL公式（公式2）指定
在城市地区（x.aid == y.aid）内，在一分钟内（(z.DE[p].SE[q].ts −x.DE[k].SE[h].ts)=< 60），检测到至少两名患者出现类似的健康恶化症状（x.sy== y.sy ==”Ebola”）（y.DE[i].SE[j].id!=x.DE[k].SE[h].id，z.DE[p].SE[q].id!= x.DE[k].SE[h].id在）实。现方面，下面我们以 Apache Flink 部署中的 Java 代码形式给出了这三个样本复杂事件处理模式。简而言之，清单1中的代码定义了公式（1）的局部复杂事件处理模式，其中携带包括体温在内的生理测量数据的初始事件之后跟随其他事件，使得在60秒的时间范围内，每一个后续的体温值都大于前一个值。通过这种方式，可以检测到患者体温迅速升高并达到38 ◦ ℃阈值的情况。

清单2定义了公式(2)中指定的MCEP模式，其中初始事件携带的体温值大于38，并且在过去的60秒内，来自同一医院病房的至少另一个事件也表现出升高的体温水平。通过这种方式，可以在医院内检测和定位某种快速健康恶化情况。

类似地，清单3定义了公式(3)中的HCEP模式，其中来自医院的初始事件表明存在埃博拉病毒病的症状，并且在过去的60秒内，来自同一城市地区（但不同医院）的至少另一个事件也表现出相同症状。通过这种方式，可以在城市内检测和定位快速的疫情爆发。

结果与讨论

所提出的分层数据融合方法与传统的将所有底层传感器读数发送至基于云的中央 CEP组件进行分析的方法进行了比较。这意味着多个传感器被配置为通过公共互联网连接直接将原始数据发送到云端。实验中的主要基准指标是时间延迟，即传感器数据首次生成时刻与基于这些数据得出有价值洞察时刻之间的时间差。在两种情况下，各个节点之间的通信均采用消息队列遥测传输（MQTT）协议实现。通信发生在局域网（用于LCEP和MCEP）或公共互联网（用于HCEP）。一条包含多个传感器读数的MQTT消息的平均大小约为1 kB。

所有三个测试平台的配置汇总于表4中，涵盖了硬件和网络规格。为了最小化延迟，GCC实例的物理位置设置在西欧。诚然，LDF和MDF配置有限的硬件能力被本地网络连接的高吞吐量和低延迟以及相对较小的数据处理量所弥补。相反，云 HDF配置的弹性资源则受到公共网络延迟增加的影响。传统集中式方法在医疗保健分析中同样存在这一问题。

表4 测试平台硬件规格和网络速度测试

硬件	上行链路，兆比特/ 秒	下行链路，兆比特/ 秒	往返 time, ms
LDF	树莓派3 (1.2 GHz ARM Cortex‐A53, 1 GB内存)	16.58	26.9
MDF	个人电脑 (2.00 GHz Intel Core i7‐4510U处理器, 16 GB内存)	16.58	26.9
HDF	Google Compute Engine n1-standard-1 (位于欧盟, 2.52 GHz虚拟CPU, 3.75 GB内存)	1.24	1.63
集方法中式	Google Compute Engine n1-standard-1 （位于欧盟，2.52 GHz虚拟CPU，3.75 GB内存）	1.24	1.63

该对比结果总结于图5中。从该图可得出的主要观察结论是，与集中式方法相比，提出的方法能够实现及时且细粒度的决策。也就是说，在数据融合层次结构的每一层，一旦收集到相关数据，就会立即做出决策。更具体而言，关于（i）个体患者的健康状况的决策可在66毫秒内完成，（ii）医院内的疾病传播及工作人员管理的决策可在311毫秒内完成，（iii）城市规模的疾病暴发及应急车辆管理的决策可在 5513毫秒内完成。最后一个数值略高于集中式方法对应的数值。然而，主要区别在于，集中式方法中所有类型的问题检测和决策过程的时间延迟是固定的。换句话说，即使是简单的诊断任务也可能需要超过5秒才能完成，并且还需要另外5秒将结果传回给医院工作人员。

值得注意的是，所提出的假设用例场景在一定程度上进行了简化，以证明该方法的总体可行性。在实际应用中，由于网络带宽、传输的网络数据包大小、传感器数量、病床数量以及医院数量等因素，基准测试的时间延迟预计会更高，因此可能导致在健康关键性决策时出现长达数分钟的固定时间延迟。如本文所述方法所示，通过实施分层数据融合（即决策）架构，可以实现更及时的操作。这种方式下，低层级的数据融合是在局域网内执行，因此不会受到网络拥塞和延迟增加的影响。

结论

新兴的医疗行业4.0依赖于无处不在的智能感知设备，以实现及时的数据采集和决策。为应对时间约束并处理日益增长的异构数据源数量，本文提出了一种分布式分层数据融合方法，利用智慧医疗生态系统中各个节点的处理能力，将数据融合任务分配给智能边缘设备（即边缘计算）、通信与处理单元（即雾计算）以及远程数据中心（即云计算）。这种三级处理模型自然地继承并符合现有的数据融合分类法，其中分层模式常被用于在不同层次上实现数据融合。复杂事件处理技术作为一种原生支持流式数据分层处理的使能技术，被应用于实现数据融合。通过一个智慧医疗案例研究，验证了所提出方法的可行性和有效性。在该案例中，整个物联网网络拓扑（包括配备传感器的病床、局域网处理单元和云数据中心）均集成了复杂事件处理功能，从而构建出一个三级分层复杂事件处理框架。结果表明，尽管在最高HCEP层级上的延迟相较于集中式独立云复杂事件处理解决方案更高，但在较低层级上表现出更高的有效性，决策速度可提升20×–90×倍——鉴于医疗相关决策关乎生命安全，这一成果具有重要意义。

为了使提出的方法更加灵活，我们渴望通过双向协调通道扩展其功能。也就是说，将可以通过基于云的管理界面以自上而下方式修改每一层级现有的复杂事件处理策略。这样一来，复杂事件处理规则库中的变更（即添加、修改、删除）将沿受管物联网拓扑向下传播，以反映新出现的需求。在这种情况下，确保参与设备上的复杂事件处理功能可远程访问和配置至关重要——这一需求可通过现有的容器化技术来实现，该技术支持通过网络以无缝且透明的方式远程动态“注入”系统更新[26]。

最后，除了智慧医疗之外，本文提出的思路和概念还有可能应用于更广泛的智能场景，例如智能交通系统、智能工厂或智能监控。在所有这些系统中，构成信息物理系统的传感器丰富的边缘设备会持续生成需要处理和分析的数据流。因此，为了满足严格的时间约束并实现近实时决策，可以利用CEP技术在不同层次上实施数据融合，从而最大限度地减少与远程（基于云）数据处理相关的网络延迟影响。