iven/hms

Files

iven 1265935fa3 chore: 设计规格文档 + 销售数据 + 脚本工具 + 根目录 monorepo 配置

- docs/: 设计规格、讨论记录、销售数据、健康管理文档
- scripts/: 辅助脚本
- package.json + pnpm-lock.yaml: monorepo 根配置

2026-04-28 00:20:37 +08:00

6.8 KiB

Raw Blame History

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天）
危急值阈值可配置化（2天）
daily_monitoring 合并后告警验证（1天）
随访逾期通知 + 幂等保护（1天）
知情同意记录（3天）
审计日志补全（3天）
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. 动态菜单系统

结论 / 待定

达成的共识

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

遗留问题

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

关联文档

设计规格：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

6.8 KiB Raw Blame History Unescape Escape