2.2 KiB
2.2 KiB
实时体征采集与智能告警系统 — 发散式探讨记录
日期: 2026-04-26 | 参与者: 用户 + Claude
背景
围绕 HMS 健康管理平台的技术纵深方向展开发散式探讨，最终聚焦到"医疗 IoT 实时监控"方向，并输出完整的设计规格文档。
讨论要点
方向选择
- 从产品/技术/架构/效能四个维度出发，用户选择了技术纵深
- 在技术纵深中选择了实时数据管道
- 在实时数据管道中选择了医疗 IoT 实时监控方向
核心技术决策
-
设备选择：健康手环（而非血压计/血糖仪）
- 理由：数据频率高（24h 持续）、用户粘性强（被动采集）、协议通用性好
- 关键挑战：数据量爆炸（每天 86000 条心率数据），需要降采样策略
-
接入策略：先定义统一接口协议，再逐设备精准适配
- DeviceAdapter Trait 统一抽象，屏蔽设备碎片化
- 首版支持小米手环，后续扩展华为/OPPO 等
-
数据通道：小程序 → REST API 批量提交
- 手环本地缓存 → 打开小程序时定时批量同步
- 实时性依赖患者操作频率（每天 1-2 次），非 ICU 级实时
-
告警引擎：规则引擎 + 滑动窗口
- 三层规则：单次阈值 / 连续超标 / 趋势恶化
- 基于 PostgreSQL 窗口函数实现，不需要时序数据库
-
数据模型：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 创建实施计划