iven/hms

Files

iven 2afe3a8848 docs: IoT 设备采集 + FHIR 开放平台生态设计规格

发散式探讨产出：BLE 适配器 + 设备网关混合架构，HL7 FHIR R4 输出，
OAuth2 合作伙伴认证，渐进演进 V1-V3 路线图。

Spec review 发现大量已有基础设施（device_readings/alert_engine/SSE/BLE），
设计已据此修正为"增强现有 + 新增 FHIR 层"策略。

2026-05-04 01:08:01 +08:00

3.0 KiB

Raw Permalink Blame History

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 哈希（与现有密码策略一致）

结论

架构方案 C（混合）确认 — BLE 统一适配器 + 设备网关扩展点
渐进演进：V1（12周）→ V2a → V2b → V3
大量基础设施已存在 — V1 的核心工作量在 FHIR API 层和合作伙伴认证，而非设备采集
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

3.0 KiB Raw Permalink Blame History Unescape Escape