116 lines
5.4 KiB
Markdown
116 lines
5.4 KiB
Markdown
# 设备数据全链路发散式探讨
|
||
|
||
> 日期: 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 趋势分析的触发频率和成本控制
|