📚 课程目录第4章病区物联网感知层架构

4. 病区物联网感知层架构

感知层是智慧病区平台的数据源头，它决定了上层临床决策、护理管理和质控分析能拿到什么样的原始数据。感知层并不是简单地“把设备连上网”，而是要解决三类异构对象的接入问题：医疗设备（监护仪、输液泵、呼吸机等）、穿戴设备（腕带、心电贴、体温贴等）和环境传感器（温湿度、空气质量、门磁、床压等）。这三类对象在接口形态、协议栈、数据频率和供电方式上差异极大，因此感知层架构必须按“接入—采集—边缘处理—上送”四段来分层设计，而不是用一套统一方案硬套。

一、三类对象的接入协议选择

医疗设备以有线为主、协议封闭。监护仪常见接口是 RS-232 串口或网口，输出 HL7 v2.x 消息或厂商私有协议；输液泵、呼吸机多通过 RS-232/RS-485 或 USB 转串口输出状态帧。这类设备的关键约束是：不能改动设备固件，不能影响其临床功能，因此接入侧通常采用“串口服务器/协议网关”做物理转接，把 RS-232 转为 TCP，再由采集服务解析私有帧。对于支持 HL7 的设备，可直接用 MLLP（Minimum Lower Layer Protocol）监听端口，按段解析 MSH、OBX 等字段。

穿戴设备以低功耗无线为主。体温贴、心电贴常用 BLE（蓝牙低功耗）GATT 服务，腕带定位常用 BLE 信标或 UWB。BLE 的接入要点是：每个厂商的 GATT 服务 UUID 和特征值不同，需要为每类设备维护一份“设备型号—服务 UUID—数据解析规则”的映射表。例如某体温贴的温度特征值返回 2 字节小端整数，需除以 100 得到摄氏度。穿戴设备的数据频率通常为 1 次/分钟到 1 次/秒，适合用网关集中扫描后统一上送，而不是每台设备直连服务器。

环境传感器以标准工业协议为主。温湿度、CO₂、PM2.5 传感器多支持 Modbus RTU（RS-485）或 Modbus TCP，也有部分支持 MQTT。门磁、床压等开关量传感器常用干接点或 Zigbee。Modbus 的接入关键是寄存器地址映射：例如温度值在保持寄存器 40001，读取后需按“寄存器值 × 0.1”换算。Zigbee 设备则需通过协调器组网，再经 MQTT 上送。

二、数据采集的关键设计

采集不是“收到就转发”，而是要解决三个问题：时间对齐、单位统一、异常过滤。医疗设备的时间戳往往来自设备本地时钟，不同设备之间可能相差数秒甚至数分钟，因此采集服务在收到数据后应打上网关侧的统一时间戳（NTP 同步），并保留设备原始时间戳作为参考字段。单位统一方面，体温统一为摄氏度、血压统一为 mmHg、输液速度统一为 mL/h，换算规则在采集配置中显式声明，而不是散落在代码里。

异常过滤要区分“设备异常”和“患者异常”。例如监护仪某次心率读数为 0，可能是导联脱落而非心脏停搏，采集层应结合设备状态位判断，而不是直接触发临床告警。对于穿戴设备，信号弱导致的丢包应标记为“数据缺失”而非“数值为 0”，避免污染趋势分析。

三、边缘计算节点的设计要点

边缘节点部署在病区弱电间或护士站，承担四类任务：协议解析与标准化、本地告警判断、断网缓存、数据聚合。以某病区为例，一个边缘节点可接入 30～50 台设备，CPU 4 核、内存 8GB、SSD 128GB 即可满足。节点上运行采集服务、规则引擎和本地 MQTT Broker，通过 Docker 部署便于升级。

本地告警判断是边缘计算的核心价值。例如体温贴数据超过 38.5℃ 持续 2 分钟，边缘节点直接触发本地声光告警，同时上送平台，避免网络延迟影响响应。断网缓存则要求节点在平台不可达时把数据写入本地队列，恢复后按时间顺序补传，队列容量按“断网 4 小时”估算，约需 2GB 空间。

边缘节点的规则引擎建议用“条件—动作”表配置，而不是硬编码。例如：条件为“设备类型=体温贴 AND 温度>38.5 AND 持续时长>120s”，动作为“本地告警+上送平台+记录事件”。这样临床科室可自行调整阈值，无需改代码。

四、一个可参考的采集配置示例

下面是一段采集配置的示例结构，用于说明如何把设备型号、协议、解析规则和上送主题绑定在一起。参数为教学示例，实际部署需按设备手册核对。

{
  "deviceModel": "TempPatch-T1",
  "protocol": "BLE",
  "serviceUUID": "00001809-0000-1000-8000-00805f9b34fb",
  "charUUID": "00002a1c-0000-1000-8000-00805f9b34fb",
  "parse": {
    "type": "int16_le",
    "scale": 0.01,
    "unit": "℃"
  },
  "sampleInterval": 60,
  "mqttTopic": "ward/301/patient/12/temperature",
  "edgeRule": {
    "highThreshold": 38.5,
    "durationSec": 120,
    "action": ["localAlarm", "publish"]
  }
}

这段配置的含义是：该体温贴通过 BLE 上报，温度特征值按小端 16 位整数解析，乘以 0.01 得到摄氏度，每 60 秒采样一次，数据上送到指定 MQTT 主题；边缘节点同时判断是否超过 38.5℃ 并持续 120 秒，若满足则触发本地告警并上送。实际部署时，serviceUUID 和 charUUID 必须与设备厂商文档一致，scale 因子也要用标准温度计比对验证。

五、接入协议选择的判断依据

面对一台新设备，接入协议的选择可按以下顺序判断：先看设备是否已有网口和标准协议（HL7、Modbus TCP），有则优先走网络直连；若只有串口，则用串口服务器转 TCP，再由采集服务解析；若设备是低功耗无线，则用网关集中扫描，避免每台设备单独配网；若设备完全封闭且无对外接口，则考虑通过其配套的厂商中间件或数据库视图间接采集，但需评估实时性和合规性。

感知层设计中最容易被忽视的是“设备身份与患者绑定”。同一型号的体温贴可能贴在不同患者身上，若绑定关系错误，数据就会串人。建议在接入时用腕带二维码或床旁扫码完成“设备 ID—患者 ID—床位”三元组绑定，并在边缘节点校验绑定关系后再上送。

总体来看，病区感知层的架构设计不是追求协议统一，而是承认异构、分层适配：接入层解决“连得上”，采集层解决“读得懂”，边缘层解决“反应快、断网不丢”，平台层解决“用得好”。四层各司其职，才能让医疗设备、穿戴设备和环境传感器的数据真正汇入临床流程。