51 lines
2.2 KiB
Markdown
51 lines
2.2 KiB
Markdown
# 实时体征采集与智能告警系统 — 发散式探讨记录
|
||
|
||
> 日期: 2026-04-26 | 参与者: 用户 + Claude
|
||
|
||
## 背景
|
||
|
||
围绕 HMS 健康管理平台的技术纵深方向展开发散式探讨，最终聚焦到"医疗 IoT 实时监控"方向，并输出完整的设计规格文档。
|
||
|
||
## 讨论要点
|
||
|
||
### 方向选择
|
||
- 从产品/技术/架构/效能四个维度出发，用户选择了**技术纵深**
|
||
- 在技术纵深中选择了**实时数据管道**
|
||
- 在实时数据管道中选择了**医疗 IoT 实时监控**方向
|
||
|
||
### 核心技术决策
|
||
|
||
1. **设备选择：健康手环（而非血压计/血糖仪）**
|
||
- 理由：数据频率高（24h 持续）、用户粘性强（被动采集）、协议通用性好
|
||
- 关键挑战：数据量爆炸（每天 86000 条心率数据），需要降采样策略
|
||
|
||
2. **接入策略：先定义统一接口协议，再逐设备精准适配**
|
||
- DeviceAdapter Trait 统一抽象，屏蔽设备碎片化
|
||
- 首版支持小米手环，后续扩展华为/OPPO 等
|
||
|
||
3. **数据通道：小程序 → REST API 批量提交**
|
||
- 手环本地缓存 → 打开小程序时定时批量同步
|
||
- 实时性依赖患者操作频率（每天 1-2 次），非 ICU 级实时
|
||
|
||
4. **告警引擎：规则引擎 + 滑动窗口**
|
||
- 三层规则：单次阈值 / 连续超标 / 趋势恶化
|
||
- 基于 PostgreSQL 窗口函数实现，不需要时序数据库
|
||
|
||
5. **数据模型：device_readings（高频分区表）与 vital_signs（现有日级表）并存**
|
||
- 原始数据 90 天保留，按月分区
|
||
- 小时级降采样长期保留
|
||
|
||
### Spec Review 修复
|
||
- EventBus publish 签名需传 db 参数（outbox 持久化）
|
||
- SSE 扩展改为全量 subscribe + 自行过滤（前缀不同）
|
||
- patient_devices 表补充标准字段（created_by/version/deleted_at）
|
||
- alert_rules FK 添加 ON DELETE RESTRICT
|
||
- 摄入 API 补充设备绑定校验步骤
|
||
|
||
## 结论
|
||
|
||
- 输出完整设计规格文档：`docs/superpowers/specs/2026-04-26-realtime-vital-signs-pipeline-design.md`
|
||
- 评审通过（APPROVED），High/Medium 问题已修复
|
||
- 分三阶段实施：Phase 1 数据管道 → Phase 2 告警推送 → Phase 3 扩展设备
|
||
- 下一步：进入 writing-plans 创建实施计划
|