3. 多源健康数据采集工程

家庭健康管理平台的数据来源天然是“多源异构”的：可穿戴设备以高频、低精度、连续采样为特征；家用医疗仪器以低频、高精度、单次测量为特征；手工录入补充主观感受与缺失场景；第三方健康API则提供跨平台的历史数据与聚合视图。四类数据在采样频率、精度、协议、时延、可信度上差异巨大，如果直接混入同一张表，后续的指标计算、趋势分析和告警判断都会失真。因此，采集工程的核心任务不是“把数据收上来”，而是在接入层完成标准化、时间对齐、质量标记与来源溯源，让下游只面对一种统一的数据契约。

四类数据源的接入特征与工程约束

先明确每类源的真实接入方式，再决定采集策略。可穿戴设备通常通过蓝牙低功耗（BLE）与手机App通信，再由App经HTTPS上报；部分设备支持厂商云回调。其数据是“批量+连续”的，例如心率每5分钟一个点、睡眠分期每晚一段。家用医疗仪器如电子血压计、血糖仪、体脂秤，多数通过BLE GATT服务读取单次测量记录，也有通过USB串口或厂商私有协议导出的。手工录入是用户在App或Web表单中填写，字段自由度高但易错。第三方健康API（如运动步数、睡眠、体重聚合服务）一般提供OAuth2授权后的REST接口，支持按时间范围分页拉取。

这四类源在工程上对应四种接入通道：BLE直连采集、文件/串口导入、表单提交、API轮询与Webhook。它们最终都要汇入同一个“原始数据落地区”，再经过清洗进入标准指标库。

统一数据契约：采集层必须落地的字段

无论数据来自哪条通道，进入原始落地区时都必须携带一组最小公共字段，否则后续无法做时间对齐和来源判断。建议的原始记录结构如下（示例字段，非实测）：

{
  "record_id": "raw_20240612_000871",
  "user_id": "u_10237",
  "source_type": "wearable | medical_device | manual | third_party_api",
  "source_name": "Mi Band 8 | Omron HEM-7361T | App表单 | HealthKit",
  "device_id": "dev_ble_88a1",
  "metric_code": "heart_rate",
  "raw_value": 72,
  "raw_unit": "bpm",
  "measured_at": "2024-06-12T08:15:00Z",
  "ingest_time": "2024-06-12T08:16:12Z",
  "quality_flag": "valid | suspect | missing | duplicate",
  "trace_id": "trace_9f3c2a"
}

其中 measured_at 必须统一为UTC，避免用户跨时区或设备时区设置错误导致趋势错位；raw_value 与 raw_unit 保留原始值，换算放到标准化层，这样即使换算规则调整也能重放；quality_flag 是采集层对数据可信度的第一道判断，例如血压计袖带过松导致读数异常偏高，可标记为 suspect。

时间对齐与去重：多源数据最容易出错的地方

同一时刻，手环记录的心率、血压计测量的血压、用户手工录入的“头晕”症状，三者的时间戳精度不同：手环可能是整5分钟对齐，血压计是精确到秒，手工录入可能只精确到分钟。如果直接按时间戳相等做关联，几乎无法匹配。工程上通常采用时间窗口对齐：以目标指标（如“晨间血压”）为中心，向前后各取15分钟窗口，窗口内同一 metric_code 的多条记录按来源可信度排序，取最高可信度的一条作为主记录，其余作为佐证保留。

去重则要区分“真重复”和“多源同指标”。同一设备因网络重试上报两次，属于真重复，按 device_id + metric_code + measured_at 去重；手环和第三方API都提供了同一天的步数，属于多源同指标，不应简单去重，而应保留两条并标记来源，由下游按可信度策略选择或加权。可信度分级建议：医疗仪器 > 手工录入（有校验） > 可穿戴设备 > 第三方API聚合值。

异常值与缺失处理：采集层的第一道质量闸门

采集层不做复杂医学判断，但必须做基础范围校验。以血压为例，收缩压合理范围可设为 60–260 mmHg，舒张压 30–160 mmHg，超出范围标记 suspect 并保留原值，不直接丢弃。心率可设 30–220 bpm。血糖需区分空腹与餐后，单位可能是 mmol/L 或 mg/dL，采集层只记录原始单位，标准化层再换算。缺失字段如 measured_at 为空，则用 ingest_time 兜底并标记 missing，同时触发补录提醒。

接入通道的工程实现要点

BLE直连采集的关键是手机网关的稳定性：设备广播、连接、订阅GATT特征值、断线重连、数据缓存与批量上报，任一环节失败都会丢数据。建议在App侧维护本地队列，网络恢复后按 measured_at 顺序补传，服务端按 trace_id 幂等接收。文件/串口导入适合血糖仪、体脂秤等支持导出的设备，重点是解析厂商格式并映射到 metric_code，例如将“SYS”“DIA”“PUL”映射为 systolic_bp、diastolic_bp、pulse。表单提交要在前端做单位选择和必填校验，后端做二次范围校验。第三方API接入要处理OAuth2令牌刷新、分页游标、增量同步时间戳，以及接口限流下的退避重试。

一个可执行的采集验收检查清单

接入完成后，用以下清单逐项验证，避免“数据能进来但不可用”：

• 每条记录是否都有 source_type、measured_at（UTC）、raw_unit、quality_flag、trace_id；
• 同一设备重复上报是否被幂等去重，且不误删多源同指标记录；
• 超出合理范围的读数是否标记为 suspect 而非直接丢弃；
• 缺失时间戳的记录是否用 ingest_time 兜底并标记 missing；
• 第三方API增量同步是否按 updated_at 游标拉取，避免全量重复；
• 手工录入是否做了单位选择和范围提示，减少明显错误；
• 原始层是否保留原值，标准化层是否可独立重放。

完成以上工作后，平台才具备“多源数据可比较、可追溯、可重算”的基础。采集工程的价值不在于接入了多少设备，而在于每一条数据进入平台时，它的来源、时间、单位、质量都是明确的——这是后续健康趋势分析、异常提醒和个性化建议能够成立的前提。