# 设备数据全链路发散式探讨 > 日期: 2026-04-28 | 参与者: 用户 + Claude ## 背景 客户提出血压计、血糖仪需要支持自动上传数据。项目已有实时体征管线设计(`docs/superpowers/specs/2026-04-26-realtime-vital-signs-pipeline-design.md`),Phase 1(手环数据管线)和 Phase 2(告警引擎 + SSE)已基本实现,但血压计/血糖仪 BLE 适配器被设计规格明确放在了 Phase 3。 本次探讨从客户需求出发,延伸到 AI 趋势分析、医生端仪表盘、告警通知渠道等方向。 ## 讨论要点 ### 1. 血压计/血糖仪 BLE 适配器设计 客户接受蓝牙标准协议(Bluetooth SIG),不需要按品牌逐个对接。 **已完成的底层管线:** - `device_readings` 分区表 + Entity(已实现) - `patient_devices` 设备绑定表(已实现) - `alert_rules` + `alerts` 告警表(已实现) - 批量上传 API、小时级降采样、告警引擎(3 种条件类型)、SSE 推送、EventBus 集成 - 小程序 BLE 基础架构(BLEManager + DeviceAdapter 接口 + 小米手环适配器) - 集成测试(8 个) **6 个关键决策:** | 决策点 | 结论 | 理由 | |--------|------|------| | 设备协议 | Bluetooth SIG 标准协议(0x1810 血压 / 0x1808 血糖) | 一个适配器兼容所有标准设备 | | 数据模型 | 多行拆分 + `metric` 字段 | 一条血压测量 → 3 行(systolic/diastolic/map),告警引擎直接用 value 比较 | | BLE 读取 | Indicate(实时)+ RACP(历史读取)一起做 | 血糖仪患者一天测多次,批量上传是刚需 | | 数据路由 | 双写:`device_readings` + 自动写入 `vital_signs` | 设备数据自动成为正式体征记录,患者不需手动录入 | | 告警阈值 | 临床标准值,租户可自定义覆盖 | 医疗标准 + 灵活性 | | 患者体验 | 极简式:首页设备卡片,点击连接,测完自动上传 | 类似小米运动体验,降低操作门槛 | **已知管线缺陷(本次不修但需记录):** - 批量插入缺少 ON CONFLICT 去重 - SSE 告警是租户广播,未按主治医生过滤 - 小程序无离线缓存(杀进程数据丢失) - 小米手环适配器只支持实时 notify,不支持历史读取 - 无数据保留清理任务(90 天分区自动删除) ### 2. AI 趋势分析 设备数据 + AI = 可行动的临床洞察。从"数字"变成"建议"。 **技术路线:混合方案** - 统计引擎(纯 Rust):移动平均、变化率、Z-score 异常检测、基线比较 → 产出确定性结构化中间结果 - LLM(Claude API):基于统计结果 + 患者档案 + 用药信息 → 生成自然语言医生建议 - 统计层作为 LLM 护栏,防止幻觉 **架构愿景(通用管线):** ``` 设备数据 → 统计引擎(通用)→ 结构化中间结果 → LLM 上下文合成 → 自然语言洞察 ``` 适用于血压、血糖、心电图、体温连续监测、体重变化等所有体征数据。 **erp-ai 模块现状:** 3 个 Entity 已创建(`ai_analysis`、`ai_report`、`ai_model_config`),但 Phase 1 化验单解读使用占位数据,需要真实化。 ### 3. 医生端告警仪表盘 **核心模式:告警驱动** - 登录即看到按严重级排序的告警时间线 - 80% 的告警通过侧滑抽屉(Drawer)处理,不需要跳转页面 - 处理完后切换到"患者列表"视图(按风险等级排序) **三层信息架构:** 1. 全局态势 — 统计卡片(新告警数/高危数/活跃患者/处理率)+ 告警时间线 2. 患者快照 — 最新体征 + AI 摘要 + 用药清单 + 快捷操作 3. 患者详情 — 完整趋势图 + 设备数据 + AI 分析报告 + 病历 **告警处置:结构化处理** - 医生必须选择处置方式(已电话联系/已调整用药/已转诊/继续观察)+ 备注 - 形成完整医疗记录和审计追溯 - 告警生命周期:触发 → 通知 → 响应 → 处置 → 关闭 → 记录 **与现有 UI/UX 重构的对接:** `2026-04-28-ui-ux-overhaul-design.md` 已有角色自适应仪表盘和表单抽屉策略,可以复用。 ### 4. 告警通知渠道 SSE 只在医生浏览器打开时有效。critical/urgent 告警可能出现在凌晨。 **通知链路:** ``` 告警触发 (alert_engine) → EventBus: alert.triggered → SSE: 医生在线时即时推送 → 微信模板消息: 跳转到小程序告警详情页 → 短信: critical/urgent 级别兜底通知(需对接短信服务商) ``` ## 结论 / 待定 ### 达成的共识 1. **设备对接**使用 Bluetooth SIG 标准协议,一套适配器覆盖所有标准血压计/血糖仪 2. **数据管线**复用已有基础设施(BLEManager、DeviceAdapter、批量上传 API、告警引擎) 3. **AI 分析**采用统计引擎 + LLM 混合方案 4. **医生端**采用告警驱动仪表盘 + 结构化处置 5. **通知渠道**先做微信模板消息 + 短信 ### 3 个潜在设计规格方向 1. **血压计/血糖仪 BLE 适配器** — 技术设计,可独立成 spec,实现范围最明确 2. **医生端告警仪表盘** — UI/UX + 产品设计,对接现有 UI 重构 3. **AI 趋势分析引擎** — 架构设计,连接 erp-ai + erp-health ### 待定问题 - 血糖采样类型(空腹/餐后/随机)在 `metric` 字段中的编码方式 - 微信模板消息需要申请哪些模板 ID - 短信服务商选择(阿里云 vs 腾讯云) - 是否需要修复现有管线缺陷作为本次工作的前置任务 - AI 趋势分析的触发频率和成本控制