# IoT 设备采集 + FHIR 开放平台生态 — 发散式探讨

> 日期: 2026-05-04 | 参与者: 用户 + Claude

## 背景

HMS 项目已进入功能基本完整阶段（575 次提交，B+ 架构评分）。Q2 路线图聚焦技术债清理和 AI 前端补全。用户希望探讨更长远的新功能方向：实时体征 + IoT 设备采集 与 平台生态扩展的融合。

## 讨论要点

### 1. 平台定位

- HMS 作为"健康数据枢纽" — 设备数据流入，通过标准接口流出
- 选择**渐进演进**策略：先修炼 IoT 采集内功，再开放 API 给外部系统
- 设备范围：**全场景覆盖**（穿戴 + 居家医疗 + 专业设备），但分阶段实施

### 2. 架构方案论证

比较了三种设备集成架构：

| 方案 | 优点 | 缺点 |
|------|------|------|
| A: 统一适配器 | 上层逻辑一致 | 穿戴和医疗设备差异太大，抽象变"最低公分母" |
| B: 分通道 | 各通道独立优化 | 校验/存储逻辑重复，代码分散 |
| **C: 混合（采纳）** | BLE 统一适配器 + 网关扩展，平衡 MVP 速度和扩展性 | 两套模式需维护 |

### 3. 数据输出标准

- 选择 **HL7 FHIR R4** — 国际医疗互操作标准，合作方无需学习私有接口
- 输出方式：**拉取 + 推送分层** — V1 API 拉取，V2 Webhook 推送
- 接入策略：**合作伙伴专属** — 审核制，多层隔离

### 4. Spec Review 发现

代码库中已存在大量设计为"新增"的功能：

| 已存在 | 位置 |
|--------|------|
| device_readings 表 + 批量摄入 | erp-health entity + service |
| vital_signs_hourly 小时聚合 | erp-health entity |
| alert_rules + alert_engine（3 种规则） | erp-health entity + service |
| BLE 适配器框架 + 3 个适配器（TypeScript） | miniprogram services/ble/ |
| SSE 推送（vital_update + alert） | erp-message handler |
| EventBus 事件 + 消费者 | erp-health event.rs |

真正新增的只有：FHIR API 层、OAuth2 合作伙伴认证、日聚合表、设备网关 trait（V2）

### 5. 设计决策

- 保持现有 `device_type`（8种）+ JSONB `raw_value` 模式，不引入 ReadingType 拆分
- BLE 适配器继续用 TypeScript（小程序端），不在 Rust 后端定义设备交互 trait
- FHIR 路由使用 `/fhir/R4/` 前缀（合规性要求），豁免于 `/api/v1/` 约定
- client_secret 使用 Argon2 哈希（与现有密码策略一致）

## 结论

1. **架构方案 C（混合）确认** — BLE 统一适配器 + 设备网关扩展点
2. **渐进演进：V1（12周）→ V2a → V2b → V3**
3. **大量基础设施已存在** — V1 的核心工作量在 FHIR API 层和合作伙伴认证，而非设备采集
4. **Q2 路线图协同** — 建议顺延至 Q3 启动 IoT V1，Q2 专注现有技术债

## 关联文档

- 设计规格：`docs/superpowers/specs/2026-05-04-iot-fhir-platform-ecosystem-design.md`
- 已有实时体征设计：`docs/superpowers/specs/2026-04-26-realtime-vital-signs-pipeline-design.md`
- Q2 路线图：`docs/superpowers/specs/2026-05-03-q2-roadmap-design.md`