1265935fa3
- docs/: 设计规格、讨论记录、销售数据、健康管理文档 - scripts/: 辅助脚本 - package.json + pnpm-lock.yaml: monorepo 根配置
153 lines
6.8 KiB
Markdown
153 lines
6.8 KiB
Markdown
# 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`
|