# HMS 平台基座回顾与演进 — 多专家评审讨论

> 日期: 2026-04-26 | 参与者: 用户 + AI (三专家视角评审)

## 背景

HMS 健康管理平台经过 17 天密集开发（4/10-4/26），从 ERP 底座演进到包含 16 个 Rust crate、62 个前端页面、27 个小程序页面的综合医疗 SaaS 平台。用户希望对项目的迭代开发过程进行回顾总结，验证基座设计是否合理，并讨论后续演进方向。

## 讨论要点

### 1. 项目演进脉络

- **Phase 1-6（4/10-4/16）**：ERP 底座搭建 — core/auth/config/workflow/message 全部原生 Rust 模块
- **WASM 插件实验（4/13-4/18）**：设计并实现插件系统，落地 CRM/Inventory/Freelance/ITOps 4 个插件
- **HMS 分叉（4/23-4/26）**：健康模块因 5 个硬限制（强类型/加密/文件/后台任务/外部 API）选择原生开发
- **快速迭代**：18+ 健康实体、AI 模块、微信小程序、按钮级权限控制

### 2. 基座设计验证

**验证通过的设计：**
- 星形依赖拓扑（零循环依赖）
- ErpModule trait 统一接口（生命周期/权限/事件/健康检查）
- 事件总线基础设施（broadcast + outbox 持久化 + 前缀过滤）
- JWT → TenantContext 多租户全链路贯通
- ModuleRegistry 拓扑排序（Kahn 算法 + 循环检测）

**存在问题的设计：**
- 事件消费侧不完整（13 个事件只有 3 个被消费）
- 路由手动合并（不在 trait 中，每个新模块需手动接线）
- erp-message 全量订阅（性能隐患）
- 事件注册双路径（`register_event_handlers` vs `on_startup`）

### 3. 四个关键张力

#### 张力 1：双轨并行 — 插件 vs 原生

两条截然不同的模块开发范式并存，没有明确的判断框架。

**插件路径**：plugin.toml → Guest trait → WASM → 自动路由/动态表/沙盒隔离
**原生路径**：Rust crate → ErpModule trait → 手动路由/强类型/完全能力

结论：HMS 核心业务（健康/AI/透析/积分）全部需要原生，插件只适用于 CRUD 密集型通用 ERP 模块。

#### 张力 2：事件消费缺口

erp-health 发布 13 种事件，消费侧严重不足：
- `health_data.critical_alert` 无消费者（危急体征无人响应）
- `follow_up.overdue` 无消费者（逾期随访无催办）
- `patient.created/updated`、`lab_report.uploaded`、`consultation.opened/closed` 等全部空转

#### 张力 3：租户隔离最后一公里

应用层隔离完整但缺兜底：
- 无 PostgreSQL RLS policy
- 无强制 tenant_id 过滤机制
- 微信登录硬编码 default_tenant_id

#### 张力 4：健康模块复杂性

erp-health 已成为子平台：加密子系统、脱敏管道、积分体系、AI 数据提供者、后台调度、小程序 API。积分系统（8 实体/12+ 路由）不属于健康模块。

### 4. 三专家评审

#### 专家 1：高级系统架构师

- 诊断准确度 7/10，优先级有偏差
- 发现 EventBus 无重放机制（服务重启丢事件）、overdue 事件无幂等保护
- RLS 不是 P0，多租户集成测试才是
- 积分系统不应在 health 内
- 核心原则：先补测试再重构，先修事件再上功能，先验证再加固

#### 专家 2：医疗信息化专家

发现比原始诊断更深层的风险：
- 危急值阈值全部硬编码（不可配置，无法适应不同科室）
- `daily_monitoring` 表体征数据不经过危急值检测（合并遗留问题）
- 过敏史更新直接覆盖，无变更历史
- 知情同意完全缺失（搜索 consent/同意/授权/隐私 零结果，违反 PIPL 第29条）
- 只有身份证号加密，姓名/过敏史/诊断/咨询内容明文
- 审计日志不完整（只有预约状态变更记录前后值）
- ip_address 和 user_agent 从未被填充
- 读操作完全没有审计记录

#### 专家 3：产品策略专家

- 17 天 237 提交不可持续但不必恐慌，fix 提交占 21.6%
- 41% Rust 代码在插件系统，对核心业务贡献接近零（最大 ROI 失衡）
- 单人+AI 的"速度幻觉"：68 提交/天 = 审查不足
- 测试正确水位：关键路径 50-80 用例，3-4 天投入
- V2 血透路线图：技术储备够，但缺市场验证，建议先做 3-5 家客户调研

### 5. 三专家共识

| 共识 | 说明 |
|------|------|
| 危急值告警闭环是 P0 | 三方一致，错误的血糖阈值可致患者昏迷 |
| 知情同意缺失是法律红线 | PIPL 违规可罚 5000 万 |
| 积分系统不属于 health | 三方独立得出相同结论 |
| 测试覆盖是所有后续工作的前提 | 先有测试才能放心重构 |
| 插件系统应冻结 | 保留代码，不再投入 |
| EventBus 可靠性需增强 | 无重放 + 无幂等 |

### 6. 重新排序的优先级

**P0（2-3 周，上线前必修）：**
1. 危急值告警消费者（1天）
2. 危急值阈值可配置化（2天）
3. daily_monitoring 合并后告警验证（1天）
4. 随访逾期通知 + 幂等保护（1天）
5. 知情同意记录（3天）
6. 审计日志补全（3天）
7. EventBus 持久化增强（2天）

**P1（2-4 周，治理）：**
8. 积分系统剥离（5天）
9. 关键路径测试 50-80 用例（4天）
10. 插件系统冻结声明（0.5天）
11. erp-message 改用 subscribe_filtered（1天）
12. 统一事件消费模式（2天）
13. 过敏史变更历史（1天）

**P2（后续迭代，扩展）：**
14. PostgreSQL RLS
15. 血透专科（先客户调研）
16. OCR / IM（血透验证后）
17. health 模块按子域重组
18. 动态菜单系统

## 结论 / 待定

### 达成的共识

1. **基座设计方向正确** — 星形依赖、trait 抽象、事件总线经受住了实践检验
2. **插件系统从核心战略降级为实验性功能** — 保留但冻结
3. **临床安全和合规是最高优先级** — 危急值闭环和知情同意必须先于功能扩展
4. **积分系统应从 health 模块拆出** — 降低合规复杂度
5. **单人+AI 开发需要节奏控制** — 每日提交上限、ADR 强制化、医疗安全代码外部 review

### 遗留问题

1. **知情同意的具体实现方案** — 需要单独讨论：同意类型（数据收集/共享/研究使用）、获取时机（建档时/首次使用时）、存储结构
2. **积分系统拆分的接口设计** — 事件总线通信还是共享 trait？
3. **血透专科的市场验证** — 需要用户确认是否已做客户调研
4. **PostgreSQL RLS 的实施策略** — 全量 RLS 还是只覆盖敏感表？
5. **合规审计的准备** — 是否有外部合规审计计划？

### 关联文档

- 设计规格：`docs/superpowers/specs/2026-04-26-platform-retrospective-and-evolution-design.md`
- 插件系统设计：`docs/superpowers/specs/2026-04-13-wasm-plugin-system-design.md`
- 健康模块设计：`docs/superpowers/specs/2026-04-23-health-management-module-design.md`
- 插件平台讨论：`docs/discussions/2026-04-18-plugin-platform-brainstorm.md`