# HMS 系统全景梳理与多专家头脑风暴

> 日期: 2026-04-28 | 参与者: iven, Claude (多专家角色)

## 背景

系统经过快速迭代，代码库规模已显著增长（18 crate, 77k 行 Rust, 163 前端文件, 409 次提交）。wiki 数据严重滞后于实际状态。本次全面梳理后召开多专家头脑风暴，确定下一阶段方向。

## 系统现状全景

### 关键数据（实际值 vs 之前 wiki 值）

| 指标 | wiki 更新前 | 实际值 |
|------|------------|--------|
| Rust crate | 15 | **18** |
| 数据库迁移 | 72 | **76** |
| erp-health 实体 | 34 | **44** |
| Web 前端文件 | 133 | **163** |
| Rust 代码行 | ~63k | **~77k** |
| Git 提交 | 301 | **409** |
| 后端测试 | 119 | **384**（225 单元 + 159 集成） |

### 架构优势

1. 模块化设计优秀 — ErpModule trait + 拓扑排序 + 依赖注入
2. 事件驱动完整 — EventBus + Outbox + LISTEN/NOTIFY + 幂等消费 + Dead Letter
3. 安全体系完善 — PII 加密(KEK/DEK) + HMAC 盲索引 + RLS + 审计哈希链
4. 健康模块业务域覆盖全面 — 44 实体覆盖患者/体征/预约/随访/咨询/告警/积分/透析等

### 主要风险

1. **P1**: AI 模块使用 placeholder 数据，HealthDataProviderImpl 全部 stub
2. **P1**: erp-dialysis 已拆分但 erp-server 未注册激活
3. **P2**: 4 个核心模块（config/message/workflow/ai）零单元测试
4. **P2**: i18n 未实现，所有前端文本硬编码中文

## 议题 A：erp-dialysis 模块归属决策

### 现状审计

- erp-dialysis crate：17 个源文件，~1,490 行 Rust
  - 2 个实体（dialysis_record, dialysis_prescription）
  - 完整的 entity/service/handler/dto 四层架构
  - DialysisModule 已实现 ErpModule trait
  - 4 个权限码（但用了 `health.health-data.list/manage` 而非专用 `health.dialysis.*`）
  - 依赖仅 erp-core，无其他业务依赖
- erp-health 中已无 dialysis 的 entity/service/handler（已完全迁出）
- erp-health 中残留：stats 端点引用透析统计、validation 中引用透析验证
- erp-server 中未注册 DialysisModule
- 集成测试在 erp-server/tests/ 下（2 个文件）

### 决策

**接入并激活**。代码已完整拆分，只需在 erp-server 注册 DialysisModule、挂载路由、修复权限码和测试引用。约 2 小时工作量。

### 待办

- [ ] erp-server/Cargo.toml 添加 erp-dialysis 依赖
- [ ] erp-server/main.rs 注册 DialysisModule
- [ ] 修复权限码：使用 `health.dialysis.list/manage` 替代借用的 `health.health-data.*`
- [ ] 迁移集成测试引用
- [ ] 清理 erp-health 中的残留引用

## 议题 B：测试覆盖率提升路径

### 现状

| Crate | 单元测试 | 集成测试 | 覆盖评估 |
|-------|---------|---------|---------|
| erp-health | 104 | 159 | 良好 |
| erp-core | 42 | - | 良好 |
| erp-auth | 38 | 3 | 中等 |
| erp-plugin | 31 | 2 | 中等 |
| erp-dialysis | 10 | - | 中等 |
| **erp-config** | **0** | - | 缺失 |
| **erp-message** | **0** | - | 缺失 |
| **erp-workflow** | **0** | - | 缺失 |
| **erp-ai** | **0** | - | 缺失 |

### 决策

**按风险排序**。优先补充业务风险最高、影响面最大的模块。

### 优先级

1. **P0 erp-workflow** — BPMN 引擎是业务核心，parser + executor + expression evaluator 零测试
2. **P1 erp-ai** — AI 输入脱敏 + Prompt 模板注入风险高
3. **P2 erp-message** — SSE 推送 + 事件消费者影响通知可靠性
4. **P3 erp-config** — CRUD 为主，风险最低

## 议题 C：AI 集成破局

### 现状

- erp-ai 4 个 SSE 分析端点（lab_report, trends, checkup_plan, report_summary）全部使用 placeholder 数据
- HealthDataProviderImpl 4 个方法全部 stub
- HealthDataProvider trait 定义在 erp-core，桥接实现放在 erp-health/src/health_provider_impl.rs
- AI 模块依赖 erp-health 但无法获取真实数据

### 决策

**数据桥接优先**。先实现 HealthDataProvider trait 的 4 个方法，从真实数据替换 placeholder。

### 数据桥接方向

1. **化验单解读** (lab_report) — 查询患者的 lab_report + vital_signs，构造结构化输入给 Claude
2. **趋势分析** (trends) — 查询时间序列体征数据（vital_signs + vital_signs_hourly），生成趋势描述
3. **体检方案** (checkup_plan) — 查询患者基本信息 + 诊断 + 体征，生成个性化体检建议
4. **报告摘要** (report_summary) — 查询健康档案 + 化验 + 诊断，生成综合健康报告

### 安全要求

- AI 输入必须经过 sanitization 模块脱敏
- AI 输出不可直接存入数据库，必须经过审核流程
- 患者数据跨模块传输通过 trait 接口，不直接依赖

## 议题 D：3 个月产品路线图

### 决策

**AI 驱动路线**。以 AI 数据桥接为核心主线，其他工作围绕它展开。

### Phase 1：基础准备（第 1-2 周）

- 激活 erp-dialysis 模块（2 小时）
- 补充 erp-workflow 单元测试（P0）
- wiki 全面更新（已完成）

### Phase 2：AI 数据桥接（第 3-6 周）

- 实现 HealthDataProviderImpl 4 个方法
- 替换所有 placeholder 数据为真实患者数据
- 补充 erp-ai 单元测试（Mock Claude API）
- AI 输入/输出安全脱敏完善

### Phase 3：前端 AI 体验（第 7-8 周）

- AI 分析页面交互优化（流式响应 UI）
- 化验单解读结果展示组件
- 趋势图表 + AI 解读联动

### Phase 4：小程序医护端（第 9-10 周）

- 医护端工作台完善
- 患者列表/详情/报告查看优化
- 随访管理流程打通

### Phase 5：安全加固（第 11-12 周）

- 补充 erp-message 单元测试
- RLS 全面验证（多租户隔离测试）
- 安全扫描 + 修复

## 结论

4 个议题均已达成决策：
1. **dialysis** → 接入激活（2 小时工作量）
2. **测试** → 按风险排序（workflow > ai > message > config）
3. **AI** → 数据桥接优先，实现 HealthDataProvider 4 个方法
4. **路线图** → AI 驱动路线，3 个月分 5 个 Phase

## 产出物

- wiki 9 个文件更新（index/erp-health/erp-server/architecture/testing/database/frontend/erp-core + CLAUDE.md scope 表）
- 本讨论记录
- 后续：按路线图分阶段执行