编辑推荐:
新型冠状病毒肺炎(COVID-19)大流行暴露了全球医疗系统中的关键脆弱性,使医护人员(HCWs)因与患者直接接触而面临严重感染风险。流行病学数据证实,HCWs 发生重症 COVID-19 的可能性约为其他职业人群的 7 倍,截至 2020 年年中,全球记录在
新型冠状病毒肺炎(COVID-19)大流行暴露了全球医疗系统中的关键脆弱性,使医护人员(HCWs)因与患者直接接触而面临严重感染风险。流行病学数据证实,HCWs 发生重症 COVID-19 的可能性约为其他职业人群的 7 倍,截至 2020 年年中,全球记录在案的 HCW 死亡人数已超过 7000 人。本文提出了一种基于物联网(IoT)的远程患者监测系统原型——基于物联网(IoT)的隔离病房监测系统原型——的设计方案及实验室概念验证(proof-of-concept validation),其目标是在保持连续、实时生理监测的同时,消除不必要的患者—HCW 身体接触。该系统集成了由 AD8232 心电图(ECG)模块、MAX30100 脉搏血氧仪、负温度系数(NTC)热敏电阻以及 MQ-135 传感器构成的多传感器硬件。上述传感器与 Arduino UNO 连接以执行数据采集,而局部边缘计算(edge computing)则在 Raspberry Pi 3B 上完成。研究人员基于 MIT-BIH 心律失常数据库训练卷积神经网络(CNN),将心搏划分为 5 种不同类别。通过对 109,446 个样本采用合成少数类过采样技术(SMOTE)重采样,网络在设备端实现了低于 200 ms 的推理时延。传感器数据通过经身份认证的表述性状态转移(REST)应用程序接口(API)传输至 Firebase 实时数据库(Realtime Database),并在两个前端界面间实现数据同步:一个用于临床监管的 LabVIEW 桌面仪表板,以及一个用于移动监测的跨平台 Flutter 移动应用程序。在受控实验室条件下进行的端到端技术验证证实,系统云端往返时延为 300–800 ms,阈值告警生成无误,集成聊天工具的时延低于 1 s。所提出系统将硬件传感、基于机器学习(ML)的 ECG 分类、云存储、LabVIEW 医师仪表板以及双向医患移动通信独特地整合到单一统一的低成本平台中。
该论文发表于《Sensors》,围绕传染病隔离场景下的远程患者监护需求,构建并验证了一套低成本、可集成的基于物联网(IoT)的隔离病房监测系统原型。研究背景在于 COVID-19 大流行期间,医护人员(HCWs)因频繁接触患者而承受显著更高的感染与重症风险,医疗系统尤其是重症监护相关资源承压严重。现有远程监测研究虽然已分别涉及多传感器采集、LabVIEW 可视化、移动端监护、边缘机器学习(ML)诊断等方向,但往往只覆盖其中部分能力,缺少一个能够同时整合硬件感知、边缘端 ECG 智能分类、医生桌面监护界面及医患双向通信的统一架构。正因如此,开展该研究具有明确意义:其目标并非直接形成临床部署产品,而是在受控实验条件下验证一种可降低不必要接触、维持连续生理监测、并具备后续临床转化潜力的系统架构可行性。
研究人员据此设计了一个四层式 IoT 监测框架,包含感知与执行层、边缘处理层、云数据层和应用层。系统以前端多参数生理传感器为基础,通过 Arduino UNO 实现数据采集,再由 Raspberry Pi 3B+ 作为边缘节点执行数据处理与卷积神经网络(CNN)心律失常分类,之后将结果上传至 Firebase 云端,并由 LabVIEW 医师端桌面应用与 Flutter 跨平台移动端共同调用,实现医生监护、患者查看与双向消息交流。论文最终得出的核心结论是:该原型系统在实验室台架环境中完成了从传感采集到边缘推理、云同步和双终端显示的全链路功能集成,并在时延、阈值告警、数据完整性及移动通信方面表现出良好的工程可行性,表明低成本开放式硬件架构在应急隔离场景下具有构建初步、非诊断性态势感知平台的潜力。这一研究的重要意义在于为未来面向临床试验的医用级升级与规范化验证奠定了系统架构基础,同时也为资源受限条件下的快速部署提供了概念验证路径。
研究人员采用的关键技术方法主要包括以下几方面:首先,基于 AD8232、MAX30100、NTC 热敏电阻和 MQ-135 构建多参数传感硬件,并通过 Arduino UNO 采集 ECG、心率、血氧饱和度、体温及气体相关信息;其次,以 Raspberry Pi 3B+ 为边缘计算节点,部署经 TensorFlow Lite 转换的 1D-CNN 心搏分类模型;再次,利用 Firebase Realtime Database、Cloud Firestore 与 Authentication 组成云端数据同步、身份认证及聊天消息管理体系;最后,构建 LabVIEW 医师端监护界面与 Flutter 医患移动应用。样本来源方面,机器学习训练数据来自 MIT-BIH Arrhythmia Database,系统硬件验证则基于 N = 3 名健康成年志愿者的实验室受控测试队列。
在研究结果部分,论文按照多个子模块对系统性能进行了验证与分析。
4.1. Hardware Sensor Performance Analysis
该部分主要评估感知层硬件的稳定性与误差表现。研究人员在 3 名健康成年志愿者中开展结构化实验,每位受试者在静息、运动后和恢复三个阶段完成 15 min 标准化测试,并在 48 h 内重复多个测量区块。结果显示,NTC 热敏电阻在 36.0–37.5 °C 生理范围内与参考体温计的最大偏差为 ±0.5 °C;MAX30100 所测 SpO
2 在室内空气条件下为 95–99%,与临床血氧仪差异控制在 ±1.5% 内,心率方差维持在 ±3 BPM;MQ-135 可对呼气接近导致的 CO
2 相对变化作出响应,但作者明确指出其输出仅可视为室内空气质量(IAQ)趋势和呼气接近的定性指标,而非临床可用的定量呼吸末二氧化碳参数;AD8232 单导联 ECG 前端在软件化 Pan–Tompkins QRS 检测下,于 15 次实验室试验中达到平均 96.43% 的 QRS 检测敏感度,漏检主要出现在运动后伪影阶段。该部分说明所构建传感套件在受控台架环境下能够提供稳定且具生理合理性的遥测数据。
4.2. Machine Learning ECG Classification Performance
该部分聚焦于基于 MIT-BIH 数据库的 ECG 分类模型。研究人员构建了 1D-CNN,对 109,446 个心搏样本进行五分类,包括正常(N)、室上性异位(S)、室性异位(V)、融合搏动(F)和未知/起搏(Q)。训练前,研究人员采用 SMOTE 处理类别不平衡问题,并通过加入加性高斯白噪声(AWGN)提升模型对真实噪声的鲁棒性。在边缘部署前,又针对 AD8232 与 MIT-BIH 之间的域偏移问题增加标准化信号处理流程,包括 Butterworth 带通滤波、Pan–Tompkins R 峰检测、固定窗口截取、三次样条重采样和最小—最大归一化。结果表明,量化后的 TensorFlow Lite 模型在独立测试集上的总体准确率达到 94.20%,并在 Raspberry Pi 3B+ 上实现平均 163 ms/186 样本窗的设备端推理时延,满足实时监测需要。该结果说明边缘端 ECG 智能判别在该低成本架构下具备工程实现性。
4.3. Firebase Cloud Transmission and Synchronization
该部分验证云端数据链路的时延与完整性。研究人员在 10 Mbps Wi-Fi 条件下进行 50 次连续上传测试,记录到 Firebase 往返时延为 310–790 ms,平均为 490 ms,标准差为 126 ms;所有数据均在采集后 1 s 内显示于 Firebase 控制台以及 LabVIEW、Flutter 两个应用层客户端。研究人员进一步对 200 个数据点进行 Raspberry Pi 端与前端展示值的比对,未发现数据损坏,表明当前系统在实验室网络条件下具备稳定的实时同步能力。作者同时指出,离线持久化与断网缓存恢复尚未测试,是未来部署环境中值得补充的能力。
4.4. LabVIEW Physician Dashboard Performance
该部分关注医生桌面端界面的认证、刷新与报警表现。研究人员基于 Firebase REST API 实现登录、注册和密码重置流程,在 20 次登录循环中有效凭据认证成功率达到 100%,且对无效输入可给出正确错误提示。持续 HTTP 连接策略较多次新建连接显著降低单次刷新时延,平均为 71 ms,对比基线的 340 ms 具有明显优势。系统能够在滚动波形图上实时显示 ECG 波形,并将体温、SpO
2、心率、CO
2 及机器学习分类标签同步展示。通过向 Firebase 测试节点注入异常值,SpO
2 < 90% 和 HR > 120 BPM 的阈值报警均达到 100% 触发准确率,并在 15 s 内完成电子邮件通知。该部分说明 LabVIEW 医师端具备可靠的实时监测与规则告警能力。
4.5. Flutter Mobile Application Performance
该部分评估移动应用在实际设备与模拟器上的表现。研究人员在 Android 11 真机和 Android 12 模拟环境下测试应用冷启动、登录后数据加载及消息传输功能。结果显示,真机从冷启动到主界面约需 1.7 s,登录后生命体征数据约 1.4 s 完成加载;6 项监测参数均能正确显示并持续更新。医患双向聊天功能在 30 次消息交换测试中,于 LTE 下平均 0.8 s、在局域网 Wi-Fi 下平均 0.4 s 完成交付,满足亚秒级实时通信要求。基于 Firestore onSnapshot 监听机制,用户界面可在消息到达时自动刷新,无需手动更新。该部分说明 Flutter 客户端在跨平台移动监护与通信方面实现了预期功能。
4.6. Integrated End-to-End System Validation
这一部分对完整闭环进行综合评估。研究人员令健康志愿者同时佩戴全部传感器,完成从传感采集、Arduino 数字化、UART 串行传输、Raspberry Pi 处理与 ML 分类、Firebase 上传,到 LabVIEW 和 Flutter 双界面显示的全链路测试。结果显示,单次完整监测周期平均总时延为 1.2 s,其中 Arduino 采样约 80 ms,UART 传输约 10 ms,Raspberry Pi 处理与推理约 200 ms,Firebase 上传约 490 ms,应用层获取与渲染约 420 ms。作者据此认为,该时延水平适用于连续生理监护。此外,论文在综合讨论中强调,本研究最主要的科学贡献在于将以往多分散存在的四项能力——可穿戴多参数感知、设备端 ML ECG 分类、LabVIEW 医师监护和 Flutter 医患通信——整合进单一低成本平台,从而实现了系统层面的协同验证。
在讨论部分,研究人员强调了系统的创新性、应用边界与现实限制。创新性在于系统同时整合多传感器采集、边缘机器学习推理、云端存储同步、医生桌面监护和患者移动通信,而文献中以往方案大多仅覆盖其中若干模块。研究人员指出,将 ECG 分类推理部署于 Raspberry Pi 边缘端而非云端,可将分类时延降至 200 ms 以内,同时减少对网络连通性的依赖,并避免将原始 ECG 波形上传至云端机器学习终端。然而,作者同样明确限定了该原型的工程成熟度:首先,系统仅在实验室台架与健康志愿者条件下验证,尚无临床患者试验;其次,Arduino、Raspberry Pi、AD8232、MAX30100 等均为研究或原型开发级组件,不具备临床诊断所需认证;再次,系统尚未完成 IEC 60601-1 等医疗电气安全标准及电磁兼容(EMC)测试;此外,ECG 仍为单导联配置,MQ-135 仅具定性意义,系统也缺少无创血压(NIBP)监测模块;云端链路尚未验证断网缓存和高负载压力场景;网络安全与隐私保护目前主要依赖 Firebase 原生认证和 SSL/TLS,尚未达到医疗数据合规要求。作者因此将该系统定位为一种用于资源受限、临时隔离环境中的初步、非诊断性态势感知架构模型,而非医院认证监护设备替代品。
研究结论部分可译述如下:本文成功完成了一种低成本、多层级 IoT 远程患者监测框架的体系结构设计、物理原型实现与端到端功能集成。通过将硬件传感数据采集、用于本地 ECG 分类的边缘计算卷积神经网络、Firebase 实时云端骨干、LabVIEW 临床桌面用户界面以及跨平台 Flutter 移动应用统一起来,本研究证明了并发多参数数据路由的工程可行性。在健康志愿者队列和受控实验室环境下的实验测试验证了系统基础技术可行性:边缘节点能够稳定执行优化后的机器学习推理,数据链路在无数据丢失情况下保持低时延亚秒级特征,并在各用户界面间实现稳定的阈值告警同步。然而,这些台架结果所证明的是技术与功能互操作性,而非临床有效性或真实医院部署准备度。由于现有现成式原型并不具备医用级制造认证、长期临床可靠性指标及 IEC 60601-1 等强制安全符合性标准,因此在该平台能够安全部署于实际医院隔离设施或新生儿病房之前,仍必须开展大量后续工作,包括升级为医用级光学传感器、以符合 HIPAA 的高级加密标准增强数据遥测链路,并在机构审查委员会(IRB)监督下开展严格的前瞻性临床验证试验,以评估其在真实患者群体中的诊断准确性与安全性。