feat(health+core+ai): 业务流程全面修复 Phase 4-6 + 集成测试修复
Phase 4 — Dead-letter 重试 + 内容推送 + 安全加固: - erp-core: retry_dead_letters() 定时重试 + PII payload 脱敏 - erp-core: audit_service 哈希链定时验证 + 写入失败告警 - erp-health: article.published 消费者匹配 patient_tag 推送消息 - erp-health: care_plan 事件消费者 (激活通知 + 完成积分) Phase 5 — 患者批量操作 + 咨询增强 + 护理事件: - patient: batch_import_patients + bind_by_phone + refer_patient - consultation: rate_session 满意度评价 (rating + feedback) - consent: patient_sign_consent 患者端签署 - validation: source 枚举 (7值) + relationship 枚举 (7值) + 12 单元测试 Phase 6 — 咨询文件上传 + AI 引用标注: - consultation_message: media_id 附件上传端点 - ai_suggestion: references JSONB + [ref:id] 格式引用标注 - AI system prompt 增加引用指令 + output_parser 提取逻辑 迁移: 000161 (media_id + references) + 000162 (rating + feedback) 集成测试: consultation/follow_up/pii_encryption 新字段同步修复 讨论文档: 2026-05-20-business-process-brainstorm.md (10域审核报告)
This commit is contained in:
289
docs/discussions/2026-05-20-business-process-brainstorm.md
Normal file
289
docs/discussions/2026-05-20-business-process-brainstorm.md
Normal file
@@ -0,0 +1,289 @@
|
||||
# HMS 全业务流程合理性审核 — 多专家组头脑风暴
|
||||
|
||||
> 日期: 2026-05-20 | 参与者: 6 专家组(患者管理/预约排班/健康数据与告警/随访咨询积分/AI内容透析/跨流程整合与合规)
|
||||
|
||||
## 1. 背景
|
||||
|
||||
HMS 健康管理平台已完成核心功能开发(59 业务实体、376+ API 端点、990+ 测试),进入 V1 CONDITIONAL GO 阶段。在投入试运行前,需要从**真实医疗业务场景**角度审视所有业务流程的合理性和完整性,而非仅关注技术实现质量。
|
||||
|
||||
核心问题:**这些流程是否真正满足体检中心/血透中心/社区卫生中心的日常运营需求?**
|
||||
|
||||
## 2. 审核方法
|
||||
|
||||
6 个专家组并行工作,每位专家深入阅读实际代码(handler/service/dto/前端页面/小程序页面),从以下维度审核:
|
||||
|
||||
- 流程完整性(端到端是否闭合)
|
||||
- 真实场景覆盖度(体检/血透/社区/多科室)
|
||||
- 业务规则合理性(状态机/并发/权限)
|
||||
- 缺失功能清单(按 P0/P1/P2 分级)
|
||||
|
||||
## 3. 综合评分矩阵
|
||||
|
||||
| 业务域 | 评分 | 核心优势 | 最大缺失 |
|
||||
|--------|------|----------|----------|
|
||||
| 患者管理 | **7.5** | PII 加密+盲索引+知情同意体系 | 无批量导入、无自助绑定、无转诊流程 |
|
||||
| 预约排班 | **6.5** | CAS 原子并发控制+状态机 | 无排班模板、无改期、无候补 |
|
||||
| 健康数据采集 | **7.0** | 双链路摄入+三层降采样+BLE 4 适配器 | 两套告警系统不互通 |
|
||||
| 告警系统 | **7.0** | 规则引擎 3 条件+降噪+升级机制 | 通知渠道单一(仅站内) |
|
||||
| 随访管理 | **7.0** | 闭环完整+批量操作+5 种方式 | 模板与任务关联断裂 |
|
||||
| 咨询管理 | **7.5** | 长轮询+PII 加密+咨询→随访联动 | 缺文件上传流程、缺满意度评价 |
|
||||
| 积分商城 | **8.0** | FIFO 消费+CAS 防超卖+活动联动 | 积分触发点太少(仅签到) |
|
||||
| AI 智能分析 | **7.5** | ReAct Agent+9 Tool+角色沙箱 | 缺引用来源、Token 计量不精确 |
|
||||
| 内容管理 | **8.0** | 审核状态机+媒体库安全+轮播图 | 缺内容推送机制 |
|
||||
| 透析管理 | **6.5** | 数据字段完整+KDIGO 规则引擎 | 无排位管理、无 Kt/V 计算、无小程序端 |
|
||||
| 跨流程整合 | **7.5** | 事件驱动+Outbox+幂等消费 | 49% 事件无消费者 |
|
||||
| 安全合规 | **7.0** | AES-256-GCM+KEK/DEK+哈希链审计 | 知情同意未在数据访问层强制执行 |
|
||||
| 多角色协作 | **7.5** | 四级数据权限+AI 建议闭环 | 护士角色在事件流中缺失 |
|
||||
| 异常处理 | **6.5** | Dead-letter+幂等+乐观锁 | Dead-letter 无自动重试 |
|
||||
|
||||
**综合评分: 7.1 / 10 (B)**
|
||||
|
||||
---
|
||||
|
||||
## 4. 各域详细审核结论
|
||||
|
||||
### 4.1 患者管理 (7.5/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- PII 加密体系(AES-256-GCM + HMAC 盲索引)设计优秀,身份证/过敏史/病史/紧急联系人全覆盖
|
||||
- 盲索引去重机制防止跨系统重复建档
|
||||
- 患者与用户账号解耦(先建档后绑定),符合体检中心实际
|
||||
- 家庭成员管理完善,支持多级访问控制(summary/full/limited)
|
||||
- 知情同意 6 种类型,授权/撤回完整流程
|
||||
- 标签系统多对多关系,事务保证一致性
|
||||
|
||||
**P0 缺失:**
|
||||
- **无批量导入** — 体检中心每天 200-500 人,只有单条创建不可接受
|
||||
- **无患者自助绑定** — 患者无法通过手机号+验证码匹配已有档案
|
||||
- **无转诊流程** — 只有添加/删除医生关系,无"转诊"语义
|
||||
|
||||
**P1 缺失:**
|
||||
- 患者本人电话号码字段缺失(DTO 和 Entity 均无 phone 列)
|
||||
- source 字段无枚举校验
|
||||
- 列表搜索不支持电话号码
|
||||
- 小程序知情同意缺少签署入口
|
||||
|
||||
### 4.2 预约排班 (6.5/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- CAS 原子并发控制,事务内 `UPDATE current + 1 WHERE current < max`,取消反向释放
|
||||
- 预约状态机(pending→confirmed→completed/cancelled/no_show)完善
|
||||
- 乐观锁保护(排班/预约均带 version)
|
||||
- 前端排班余量实时显示
|
||||
|
||||
**P0 缺失:**
|
||||
- **无排班模板** — 没有周期性排班能力,必须逐天手动创建
|
||||
- **无批量排班** — 只有单条创建
|
||||
- **无改期功能** — 只能取消再重新预约,存在中间态风险
|
||||
|
||||
**真实场景覆盖度:**
|
||||
- 体检套餐预约:未覆盖(模型是单医生+单时段)
|
||||
- 血透固定排位:未覆盖(无周期性预约)
|
||||
- 候补排队:未覆盖
|
||||
- 当天加号:未覆盖
|
||||
|
||||
### 4.3 健康数据与告警 (7.0/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- 双链路数据摄入(手动录入 + BLE 设备同步)独立运行
|
||||
- 三层降采样(原始→小时聚合→日聚合含 P95)
|
||||
- 规则引擎 3 条件类型(single_threshold / consecutive / trend)
|
||||
- 告警降噪(患者级升级 + 系统级聚合抑制),critical 不抑制
|
||||
- 危急值阈值差异化配置(科室/年龄维度)
|
||||
- 告警→随访闭环(critical 1 天内、warning 3 天内)
|
||||
- 告警→咨询智能关联
|
||||
|
||||
**最严重问题 — 两套告警系统不互通:**
|
||||
- 链路一(手动录入)→ `critical_value_threshold` → `critical_alert` 表
|
||||
- 链路二(设备同步)→ `alert_rules` → `alerts` 表
|
||||
- 两张表、两套检测逻辑、两个生命周期
|
||||
- 设备同步双写 `vital_signs` 后不触发危急值检测
|
||||
- 手动录入不走规则引擎的 consecutive/trend 评估
|
||||
|
||||
### 4.4 随访管理 (7.0/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- 模板字段自定义(7 种类型:text/number/date/select/checkbox/textarea/scale)
|
||||
- 5 种随访方式(phone/outpatient/home_visit/online/wechat)
|
||||
- 批量操作(批量创建/分配/完成,上限 100)
|
||||
- 闭环完整:创建→执行→完成→自动创建后续→逾期催办
|
||||
- 随访记录 PII 加密
|
||||
- 工作流事件驱动自动完成
|
||||
|
||||
**核心断裂 — 模板与任务关联断裂:**
|
||||
- `follow_up_task` 无 `template_id` 外键
|
||||
- `follow_up_record` 无 JSONB 字段存储结构化表单答案
|
||||
- 模板定义了字段但任务/记录无法使用
|
||||
- 缺少周期性随访计划规则
|
||||
|
||||
### 4.5 咨询管理 (7.5/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- 会话生命周期(waiting→active→closed)完整
|
||||
- 长轮询 + EventBus 混合模式
|
||||
- 消息 PII 加密
|
||||
- 双端未读计数(独立计数 CAS 更新)
|
||||
- 咨询→随访联动 + 咨询→AI 分析联动
|
||||
- sender_role 服务端推导(不信任客户端)
|
||||
- 医生仪表盘 7 项指标聚合
|
||||
|
||||
**缺失:**
|
||||
- 消息附件上传流程未实现(DTO 支持 image/file/voice 但无上传链路)
|
||||
- 满意度评价缺失
|
||||
- 多人会诊不支持
|
||||
- 咨询转介不支持
|
||||
|
||||
### 4.6 积分商城 (8.0/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- FIFO 积分消费(最早到期的先扣)
|
||||
- CAS 防超卖(商品库存 + 积分余额)
|
||||
- 阶梯签到奖励(7/14/30 天)
|
||||
- 订单核销(QR 码 + 扫码验证)
|
||||
- 线下活动联动(报名+签到+自动积分发放)
|
||||
- 积分过期清理(每 24h)
|
||||
|
||||
**核心缺失 — 积分触发点太少:**
|
||||
- `earn_points` 通用方法已就绪但只在 `daily_checkin` 调用
|
||||
- 缺少:上报体征→积分、完成随访→积分、上传化验→积分
|
||||
- 这是"积分激励持续上报数据"核心价值的前提
|
||||
|
||||
### 4.7 AI 智能分析 (7.5/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- ReAct Agent + 9 Tool + 角色沙箱
|
||||
- 多 Provider + fallback chain(claude→openai→ollama)
|
||||
- 配额管理(租户月 Token + 患者日分析次数)
|
||||
- 事件驱动自动分析(化验→解读、告警→趋势、透析→KDIGO)
|
||||
- 知识库上下文注入
|
||||
- AI 建议→审批→执行→反馈闭环
|
||||
|
||||
**缺失:**
|
||||
- AI 输出无临床引用来源标注
|
||||
- 药物相互作用检查 Tool 缺失
|
||||
- Token 用量估算不精确(SSE 模式 `len/4` 估算,输入记 0)
|
||||
- Ollama FC 降级丢失 Tool 能力
|
||||
|
||||
### 4.8 内容管理 (8.0/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- 审核状态机(draft→pending_review→published/rejected)完善
|
||||
- 权限分离(编辑 vs 审核)
|
||||
- 媒体库安全(MIME 白名单 + 路径遍历防护 + 10MB 限制)
|
||||
- 缩略图自动生成 + 手动裁剪
|
||||
- 轮播图公开端点 + 时间范围过滤
|
||||
|
||||
**核心断裂 — 无内容推送机制:**
|
||||
- `article.published` 事件已发布但无消费者
|
||||
- 无法自动将文章推送给标签匹配的患者
|
||||
|
||||
### 4.9 透析管理 (6.5/10)
|
||||
|
||||
**已实现且合理:**
|
||||
- 数据字段完整(透前/透后体重、血压、心率、超滤量、血流量、时长、症状)
|
||||
- 透析处方管理(透析器、膜面积、透析液配方、抗凝剂、血管通路)
|
||||
- KDIGO 风险评估 12 条规则 + CKD 分期
|
||||
- 统计报表完整
|
||||
|
||||
**P0 缺失:**
|
||||
- **无排位管理** — 血透中心运营核心能力完全缺失
|
||||
- **Kt/V 和 URR 不自动计算** — 透析充分性指标需手动输入
|
||||
- **小程序端零入口** — 患者无法查看自己的透析记录
|
||||
- **透析记录与处方无关联** — 无法追溯"这次透析按哪个处方执行"
|
||||
- **透析记录与预约无整合** — 透析预约未走统一排班系统
|
||||
|
||||
---
|
||||
|
||||
## 5. 全系统 TOP 20 改进建议
|
||||
|
||||
### P0 — 影响核心业务可用性(建议 V1 前完成)
|
||||
|
||||
| # | 建议 | 域 | 工时 | 影响 |
|
||||
|---|------|-----|------|------|
|
||||
| 1 | **统一两套告警系统** — 合并 `critical_alert` 和 `alerts` 为单一管线 | 告警 | 5d | 消除告警漏报风险 |
|
||||
| 2 | **患者批量导入** — CSV/JSON 上传 + 异步处理 + 去重合并 | 患者 | 3d | 体检中心基本需求 |
|
||||
| 3 | **患者自助绑定** — 手机号+验证码匹配已有档案 | 患者 | 2d | 患者端核心链路 |
|
||||
| 4 | **排班模板+批量排班** — 周期性模板 + 批量创建 + 复制到下周 | 排班 | 5d | 排班管理基本需求 |
|
||||
| 5 | **透析排位管理** — 床位/机位 + 固定/临时排位 + 周期性分配 | 透析 | 5d | 血透中心运营核心 |
|
||||
| 6 | **知情同意数据访问拦截** — service 层校验 consent 状态 | 合规 | 3d | 医疗合规底线 |
|
||||
| 7 | **随访模板关联** — task 增加 template_id + record 增加 form_data JSONB | 随访 | 3d | 随访表单核心能力 |
|
||||
| 8 | **积分触发扩展** — 上报体征/完成随访/上传化验 均触发积分 | 积分 | 2d | 积分激励价值前提 |
|
||||
|
||||
### P1 — 影响日常使用效率(建议 V1.1 完成)
|
||||
|
||||
| # | 建议 | 域 | 工时 |
|
||||
|---|------|-----|------|
|
||||
| 9 | **预约改期+去重+候补** — 原子改期 + 重复预约检测 + 候补队列 | 排班 | 3d |
|
||||
| 10 | **咨询文件上传** — 集成媒体库,支持图片/语音/文件消息 | 咨询 | 2d |
|
||||
| 11 | **Kt/V + URR 自动计算** — 后端从 BUN 自动计算充分性指标 | 透析 | 3d |
|
||||
| 12 | **透析小程序端** — 患者查看记录/趋势,医护查看排位/审阅 | 透析 | 5d |
|
||||
| 13 | **Dead-letter 自动重试** — 后台任务定期扫描 + 指数退避 | 可靠性 | 2d |
|
||||
| 14 | **内容推送闭环** — article.published → 匹配 patient_tag → 推送 | 内容 | 3d |
|
||||
| 15 | **患者电话号码+搜索** — Entity 新增 phone + 盲索引 + 搜索支持 | 患者 | 2d |
|
||||
|
||||
### P2 — 影响特定场景(建议 V2 完成)
|
||||
|
||||
| # | 建议 | 域 | 工时 |
|
||||
|---|------|-----|------|
|
||||
| 16 | **AI 引用来源标注** — 知识库注入后要求 LLM 标注 reference_id | AI | 4d |
|
||||
| 17 | **告警多渠道通知** — critical 级别增加微信模板消息+短信 | 告警 | 3d |
|
||||
| 18 | **生产 KEK 防护** — dev_default 添加编译守卫,运行时检测 | 安全 | 0.5d |
|
||||
| 19 | **满意度评价** — 咨询关闭后 1-5 星 + 文字评价 | 咨询 | 2d |
|
||||
| 20 | **护理计划事件消费者** — care_plan 激活→通知医护+积分 | 协作 | 2d |
|
||||
|
||||
---
|
||||
|
||||
## 6. 三个核心架构问题
|
||||
|
||||
### 问题一:两套告警系统并行(影响最大)
|
||||
|
||||
**现状:** 手动录入走 `critical_value_threshold` → `critical_alert`,设备同步走 `alert_rules` → `alerts`。两套检测逻辑、两张表、两个生命周期。
|
||||
|
||||
**风险:** 设备同步的血压 200mmHg 可能不触发任何告警(如果没配 alert_rules);医护需要看两个告警列表。
|
||||
|
||||
**建议:** 统一为单一告警管线,所有数据摄入点先做危急值阈值检测(fast path),再做规则引擎评估(slow path),输出到统一的 `alerts` 表。
|
||||
|
||||
### 问题二:49% 事件无业务消费者
|
||||
|
||||
**现状:** 51 个事件中 25 个为 FIRE-AND-FORGET,auth/config/workflow 模块的 17 个事件完全没有消费者。care_plan/care_action 4 个事件已定义常量但无消费者。
|
||||
|
||||
**风险:** 用户删除后相关数据不清理、角色权限变更后缓存不失效、护理计划激活无后续动作。
|
||||
|
||||
**建议:** 按影响分批升级。P0:`appointment.cancelled`(号源回补)、`consent.revoked`(数据阻断)。P1:`user.deleted`/`role.*`(缓存失效)。P2:care_plan/care_action。
|
||||
|
||||
### 问题三:知情同意未在数据访问层强制执行
|
||||
|
||||
**现状:** `consent_service` 实现了同意的 CRUD,但其他 service 在返回患者数据时不检查同意状态。撤回同意后,AI 分析、统计、导出仍可访问该患者数据。
|
||||
|
||||
**风险:** 违反《个人信息保护法》"单独同意"要求和医疗数据使用授权原则。
|
||||
|
||||
**建议:** 在 `patient_service`/`health_data_service`/`lab_report_service` 的查询层添加 consent 状态校验,`consent.revoked` 后阻断敏感数据访问。
|
||||
|
||||
---
|
||||
|
||||
## 7. 结论与行动计划
|
||||
|
||||
### 综合评估
|
||||
|
||||
HMS 平台的**技术实现质量较高**(CAS 并发控制、PII 加密、事件 Outbox、审计哈希链),但**业务流程覆盖深度不足**,尤其在面向真实医疗场景时暴露了多个核心流程断裂。
|
||||
|
||||
**整体评分:7.1/10 (B)**
|
||||
|
||||
- ✅ **做得好的:** 安全基础设施、事件驱动架构、数据加密、并发控制
|
||||
- ❌ **做得不够的:** 透析排位、批量导入、排班模板、告警统一、内容推送、知情同意执行
|
||||
|
||||
### 行动建议
|
||||
|
||||
**阶段一:V1 上线前(P0,约 28 人天)**
|
||||
- 统一告警系统(5d)+ 知情同意拦截(3d)+ Dead-letter 重试(2d)= 可靠性 10d
|
||||
- 患者批量导入(3d)+ 自助绑定(2d)+ 电话号码(2d)= 患者 7d
|
||||
- 排班模板(5d)= 排班 5d
|
||||
- 积分触发扩展(2d)+ 随访模板关联(3d)+ 内容推送(1d)= 流程闭环 6d
|
||||
|
||||
**阶段二:V1.1(P1,约 28 人天)**
|
||||
- 透析排位(5d)+ Kt/V 自动计算(3d)+ 透析小程序(5d)= 透析 13d
|
||||
- 预约改期+候补(3d)+ 咨询文件上传(2d)+ 满意度(2d)= 交互 7d
|
||||
- AI 引用来源(4d)+ 告警多渠道(3d)+ 生产 KEK 防护(0.5d)= 增强 7.5d
|
||||
|
||||
**阶段三:V2 持续优化(P2)**
|
||||
- 周期性随访计划、多人会诊、药物交互检查、SpO2/体温监测入口、设备心跳保活等
|
||||
Reference in New Issue
Block a user