2. 健康数据采集与接入架构

健康数据采集与接入架构是数字健康管理平台的数据入口层,它决定了平台能获取什么类型的数据、以多快的速度获取、以及数据在进入存储与分析环节之前是否已经完成标准化。与传统的业务系统不同,健康数据采集面对的是高度异构的数据源:可穿戴设备通过蓝牙或网关上报心率、血氧、睡眠分期;家用医疗设备如血压计、血糖仪通过蓝牙或Wi-Fi上传测量值;移动端App通过SDK采集步数、位置与用户主动录入的症状;问卷系统则产生结构化的量表评分。这些数据在格式、频率、精度和语义上差异巨大,接入架构的核心任务就是把这些异构流统一为平台可消费的标准事件。

多源设备接入的三种典型通道

从工程实现角度看,多源设备接入通常收敛为三条通道。第一条是设备直连通道,适用于具备蜂窝网络或Wi-Fi能力的设备,设备通过MQTT或HTTPS直接向平台网关推送数据,平台需要为每个设备分配唯一设备标识与密钥,并在接入层完成鉴权、限流与协议解析。第二条是网关汇聚通道,适用于蓝牙低功耗设备,手机或家庭网关作为代理,先与设备建立GATT连接,读取特征值后再通过移动网络转发到平台。第三条是平台拉取通道,适用于第三方健康数据平台,平台通过OAuth授权后定期调用其开放接口拉取用户授权的数据。

三条通道的差异不仅体现在网络路径上,还体现在数据完整性与时效性上。直连通道的延迟最低,但设备功耗和网络成本最高;网关通道依赖手机在线,存在数据缓存与补传问题;拉取通道的时效性最差,通常以小时或天为周期,但覆盖面广,能补充平台自有设备无法采集的数据。

健康数据采集与接入架构总览 数据源层 可穿戴设备 心率/血氧/睡眠/步数 家用医疗设备 血压/血糖/体脂/心电 移动端App 步数/位置/主动录入 问卷与量表 PHQ-9/GAD-7/症状 第三方健康平台 授权拉取/历史数据 接入通道层 直连通道 MQTT / HTTPS 设备鉴权 + 限流 网关汇聚通道 BLE GATT 读取 手机/家庭网关代理 平台拉取通道 OAuth 2.0 授权 定时轮询 / Webhook 人工录入通道 表单校验 + 时间戳 操作人/来源标记 平台接入与处理层 统一接入网关 协议适配 · 鉴权 · 限流 · 消息路由 数据标准化与语义映射 单位换算 · 编码对齐 · 缺失值标记 频率与实时性调度 实时流 · 准实时 · 批量补传 数据质量校验 范围检查 · 时间戳校验 · 重复剔除 标准健康事件存储 时序库 · 对象存储 · 消息队列 下游消费:分析 · 预警 · 档案 数据源 → 接入通道 → 统一网关 → 标准化 → 频率调度 → 质量校验 → 标准事件存储 → 下游消费

可穿戴设备协议与移动端SDK

可穿戴设备协议的选择直接影响接入架构的复杂度。目前主流方案分为两类:一类是厂商私有协议,设备通过蓝牙GATT暴露自定义服务与特征值,数据格式由厂商定义,接入方需要针对每个品牌单独适配;另一类是标准协议,如蓝牙SIG定义的GATT健康服务(HRS、PLX、BAS等),以及医疗领域的IEEE 11073个人健康设备标准。在实际项目中,平台通常同时支持两类协议:对标准协议直接解析,对私有协议则通过设备适配层做转换。

移动端SDK是网关汇聚通道的核心组件。一个设计良好的健康数据SDK需要完成四件事:第一,管理蓝牙连接生命周期,包括扫描、配对、订阅通知与断线重连;第二,在本地做初步的数据缓存与去重,避免手机短暂离线导致数据丢失;第三,按照平台约定的数据模型将原始字节流转换为标准事件;第四,处理权限与隐私合规,确保用户授权后才上传。以下是一个简化的SDK数据上报结构示例:

{
  "deviceId": "BLE-A1B2C3D4",
  "deviceType": "wearable_band",
  "userId": "u_102938",
  "timestamp": "2025-03-18T08:12:33+08:00",
  "metrics": [
    {"name": "heart_rate", "value": 72, "unit": "bpm"},
    {"name": "spo2", "value": 98, "unit": "%"},
    {"name": "steps", "value": 3421, "unit": "count"}
  ],
  "source": "ble_gatt",
  "quality": "valid"
}

这个结构的关键在于timestamp必须由设备或SDK在采集时刻生成,而不是由平台接收时刻生成,否则补传数据会出现时间错位。quality字段用于标记数据是否通过本地校验,平台侧可以据此决定是否进入质量复核流程。

问卷与人工录入的接入设计

问卷与人工录入虽然不涉及设备协议,但在接入架构中同样需要标准化。问卷数据的特点是结构化程度高、频率低、但语义复杂。例如PHQ-9抑郁量表包含9个条目,每个条目0到3分,总分27分,平台需要把每个条目的得分、总分、评估时间、评估人(自评或他评)都作为独立字段存储,而不是只存一个总分。人工录入则常见于基层随访场景,录入人员可能是医生、护士或健康管理师,数据需要附带操作人标识和录入来源,以便后续追溯。

在接入层,问卷和人工录入通常走HTTPS表单提交或批量导入通道。与设备数据不同,这类数据需要更强的校验规则:必填项检查、数值范围检查、逻辑一致性检查(如收缩压不应低于舒张压)、以及重复提交判断。校验不通过的数据不应直接进入标准事件库,而应进入待修正队列,由录入人员确认后再入库。

数据采集频率与实时性设计

采集频率与实时性是接入架构中最需要权衡的设计参数。不同健康指标对时效性的要求差异很大:心率异常需要秒级发现,血压和血糖通常分钟级即可,睡眠分期和步数可以小时级汇总,而问卷和随访数据天级处理也能满足业务需求。如果所有数据都按实时流处理,平台的计算和存储成本会急剧上升;如果全部按批量处理,又会错过需要及时干预的异常事件。

一种可行的分层策略是:将数据分为实时流、准实时和批量补传三个等级。实时流用于心率、血氧、跌倒检测等需要立即响应的指标,通过MQTT或WebSocket推送,端到端延迟控制在3秒以内;准实时用于血压、血糖、体温等,允许1到5分钟的延迟,通过消息队列异步处理;批量补传用于设备离线期间缓存的数据,以及第三方平台拉取的历史数据,按小时或天级批量入库。平台在接入层为每个数据源配置采集频率和时效等级,并在数据标准化阶段保留原始时间戳和接收时间戳,以便后续分析时区分“采集时间”和“入库时间”。

在设计采集频率时,建议先明确每个指标的业务响应时限,再反推技术方案。例如“心率异常需在30秒内触发预警”,则从设备采集到预警引擎的整条链路预算应控制在30秒内,接入层、消息队列、规则引擎各环节的延迟都需要纳入计算。

接入架构的落地检查要点

在实际落地时,接入架构需要重点检查以下方面:设备标识是否全局唯一且可追溯;协议适配层是否覆盖了目标设备型号;SDK是否处理了断线重连与本地缓存;问卷和人工录入是否有完整的校验与修正流程;采集频率配置是否与业务响应时限匹配;数据质量校验规则是否覆盖了范围、时间戳、重复和逻辑一致性。这些检查点直接决定了平台数据入口的可靠性和后续分析的可信度。