From 78647d6cc4ed10031b29381e763541a1c0b24e2b Mon Sep 17 00:00:00 2001 From: iven Date: Sat, 25 Apr 2026 23:22:14 +0800 Subject: [PATCH] =?UTF-8?q?docs(health):=20=E5=81=A5=E5=BA=B7=E7=AE=A1?= =?UTF-8?q?=E7=90=86=E6=A8=A1=E5=9D=97=E4=B8=9A=E5=8A=A1=E6=B5=81=E7=A8=8B?= =?UTF-8?q?=E5=90=88=E7=90=86=E6=80=A7=E5=88=86=E6=9E=90=E6=8A=A5=E5=91=8A?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 三专家组（临床业务 + 运营管理 + 产品架构）并行深度审查， 覆盖患者全生命周期、医疗数据管理、预约排班、随访管理、 透析管理、咨询管理、临床决策支持、积分激励、多租户适配、 竞品对比等维度，发现 P0 问题 6 个、P1 缺失 8 个。 --- ...-health-module-business-analysis-design.md | 450 ++++++++++++++++++ 1 file changed, 450 insertions(+) create mode 100644 docs/superpowers/specs/2026-04-25-health-module-business-analysis-design.md diff --git a/docs/superpowers/specs/2026-04-25-health-module-business-analysis-design.md b/docs/superpowers/specs/2026-04-25-health-module-business-analysis-design.md new file mode 100644 index 0000000..125f435 --- /dev/null +++ b/docs/superpowers/specs/2026-04-25-health-module-business-analysis-design.md @@ -0,0 +1,450 @@ +# HMS 健康管理模块业务流程合理性分析 + +> 日期: 2026-04-25 +> 状态: Draft +> 分析方法: 三专家组并行深度审查（临床业务 + 运营管理 + 产品架构） + +--- + +## 执行摘要 + +HMS 健康管理模块已完成初始实现，包含 27 个数据库实体、12 个权限分组、13 个 Web 页面、21 个小程序页面。本次分析从**临床业务流程、运营管理有效性、产品架构竞争力**三个维度进行深度审查。 + +### 核心结论 + +**工程基础设施达到生产级水准。** 多租户隔离、CAS 并发控制、乐观锁、事件驱动架构、数据加密（AES-256 + HMAC）、审计日志等能力一应俱全。 + +**业务深度存在三个核心缺口：** + +| 缺口 | 影响 | 紧急度 | +|------|------|--------| +| 诊断编码缺失 | 随访/趋势分析/统计报表缺乏医学语义锚点，与 HIS/LIS 无法对接 | P0 | +| 统计数据造假 | Dashboard 硬编码 0 值，管理者无法做运营决策 | P0 | +| 消息推送未集成 | 14 种事件定义了但未发布，患者触达手段严重不足 | P0 | + +### 发现总计 + +- **P0 关键问题**: 6 个（产品可信度 + 患者安全） +- **P1 核心缺失**: 8 个（业务能力补全） +- **P2 运营增强**: 7 个（差异化竞争力） +- **P3 长期规划**: 7 个（市场准入 + 技术领先） + +### 差异化竞争优势 + +1. **Rust 技术性能壁垒** — 高并发预约场景显著优势，单体二进制部署比竞品微服务架构简单一个数量级 +2. **血透专科深度** — 竞品中少有的专科化设计，补全方案/通路/充分性后更具竞争力 +3. **患者运营闭环** — 积分商城+签到+活动+资讯，医疗 SaaS 中罕见的互联网运营思维 +4. **多租户原生设计** — 从第一天内置隔离，竞品多为后期改造 + +--- + +## 1. 临床业务流程评估 + +> 专家角色: 资深临床医疗信息化专家（15 年医院信息系统设计经验） + +### 1.1 患者全生命周期 + +**评分: 6/10 — "两头有、中间空"** + +已覆盖的环节: +- 建档阶段扎实：加密存储、标签分类、实名认证状态流转、家庭关系、医患关联 +- 健康摘要 API (`get_health_summary`) 聚合最新体征/化验/预约/随访，提供一站式概览 + +缺失的关键环节: + +| 环节 | 说明 | 影响 | +|------|------|------| +| 分诊 (Triage) | 无主诉、分诊科室、紧急程度的记录 | 预约直接绑定医生，跳过分诊 | +| 诊疗记录 (EMR) | `health_record` 仅含 `overall_assessment` + 文件 URL | 缺主诉、现病史、体格检查、诊断、处方 | +| 诊断编码 (ICD) | 无 ICD-10/ICD-11 支持 | 随访/趋势分析缺乏医学语义锚点 | +| 转诊流程 | 无科室间/院间转诊记录和追踪 | 多学科协作无法支撑 | +| 入组/出组管理 | 只有标签这一非结构化方式 | 健康管理项目无法规范化 | + +### 1.2 医疗数据管理 + +**评分: 5/10 — 基本可用但临床精细度不足** + +优点: +- 体征数据晨/晚血压区分符合慢病管理实践 +- 化验报告 V2 JSON 结构 `[{name, value, unit, reference_low, reference_high, is_abnormal}]` 灵活实用 +- 透析记录覆盖干体重、超滤量、血流量、透析类型 (HD/HDF/HF) + +关键缺失: + +| 问题 | 说明 | +|------|------| +| `vital_signs` 与 `daily_monitoring` 字段 80% 重叠 | 数据冗余，趋势分析查询混乱，应合并 | +| 缺乏采集时间精度 | 只有 `record_date`，血压需精确到分钟，血糖需标注空腹/餐后 | +| 缺乏体温和 SpO2 | 透析感染监测和呼吸系统疾病管理的必备指标 | +| 血糖无类型标记 | 空腹/餐后/随机/OGTT 混在一起，参考范围完全不同 | +| 无用药记录 | 小程序有 `profile/medication` 页面但后端无对应实体 | +| 化验指标未标准化 | "肌酐"/"CREA"/"Creatinine" 多种写法影响趋势分析 | +| 出入量记录过于简单 | 仅有饮水量和尿量，临床需区分口服/静脉/引流/失血 | + +### 1.3 预约排班 + +**评分: 7/10 — 核心流程优秀，运营辅助不足** + +优点: +- CAS 原子操作防超额预约，取消时自动释放名额，事务保证一致性 +- 状态机完整: pending → confirmed → completed/no_show/cancelled +- 5 种预约类型覆盖主要场景（透析/复诊/门诊/体检/咨询） + +缺失: +- 无资源维度绑定（透析机位、检查室） +- 无批量排班/排班模板（透析中心需周期性排班） +- 无候补机制（号源满后直接拒绝） +- no_show 无自动触发（定时任务缺失） +- 排班不区分节假日 + +### 1.4 随访管理 + +**评分: 6/10 — 基础流程完整，临床实用性不足** + +优点: +- 逾期自动检查 (`check_overdue_tasks`) + 自动创建后续任务（`next_follow_up_date` 机制） +- 乐观锁保护所有更新操作 + +缺失: +- 无结构化随访模板（`content_template` 是纯文本） +- 随访结果无结构化（`result`/`patient_condition`/`medical_advice` 均为自由文本） +- 无随访到期提醒通知 +- 无随访方案模板（一次性生成 1/3/6/12 月任务组） +- 无优先级字段 +- **前后端类型不一致**: 后端 `phone`/`face_to_face`/`online`，前端 `phone`/`outpatient`/`home_visit`/`wechat` + +### 1.5 透析管理 + +**评分: 4/10 — "透析记录本"而非"透析管理系统"** + +已实现: 透析记录覆盖核心物理参数（体重变化/血压/超滤/血流量），审阅流程 (draft → reviewed)。 + +三大核心支柱缺失: + +| 支柱 | 说明 | 临床影响 | +|------|------|---------| +| 透析方案 (Prescription) | 无透析器型号、透析液配方、抗凝方案、目标超滤、血管通路类型 | 每次透析需重新输入相同参数 | +| 血管通路管理 | 无通路类型/位置/评估/并发症/手术史 | 通路是透析患者的"生命线" | +| 充分性评估 | 无 Kt/V 和 URR 计算 | 无法评估透析质量 | + +其他缺失: 透析中动态监测、透析药物管理 (EPO/铁剂/磷结合剂)、症状/并发症未结构化。 + +### 1.6 咨询管理 + +**评分: 5/10 — 适合"留言板"，无法支撑"在线问诊"** + +优点: 消息模型合理（text/image/voice/file 四种类型、CAS 未读计数、会话状态机 waiting → active → closed）。 + +缺失: +- **无实时推送**: 只有 HTTP API，无 WebSocket/SSE +- 消息已读标记 API 缺失 +- 无会话超时自动关闭 +- 无满意度评价 +- 无智能分配机制（轮转/科室匹配） +- 无关联健康数据展示 + +### 1.7 临床决策支持 + +**评分: 3/10 — "概念验证"阶段** + +已实现: 趋势分析框架、异常值基本检测（心率 60-100、血糖 3.9-11.1、血压 90-140/60-90）、化验 `is_abnormal` 标记。 + +关键问题: +- **阈值硬编码** — 不考虑患者个体差异（老年/糖尿病/透析/儿童不同目标） +- **血糖阈值不一致** — 趋势分析用 3.9-11.1，小程序摘要用 3.9-6.1 +- **无实时预警** — 趋势分析是手动触发，血压 180/110 不会自动报警 +- **不整合化验数据** — 肌酐/eGFR/血红蛋白/电解质趋势同样重要 +- **无风险评分** — Framingham/KDOQI/MNA 等临床评分模型完全缺失 + +--- + +## 2. 运营管理评估 + +> 专家角色: 资深健康管理运营专家（10+ 年体检中心/健康管理机构运营经验） + +### 2.1 积分激励体系 + +**评分: 6/10 — 架构优秀，激励有效性不足** + +优点: +- 事件驱动积分发放，`daily_cap` 每日上限，FIFO 消费模型，12 个月过期 +- 连续签到阶梯奖励 (7/14/30 天) +- 全链路 CAS 并发安全 + +关键问题: + +| 问题 | 影响 | +|------|------| +| 事件类型有限 | 只有 6 种行为获积分，缺少 `vital_signs_input`/`annual_checkup`/`followup_adherence` 等真正驱动健康行为的激励点 | +| 积分通胀无控制 | 无发放/消费比率监控、无月度预算上限 | +| 积分过期未清理 | `expires_at` 字段写入后无定时检查，`total_expired` 永远为 0 | +| 订单过期未取消 | 兑换订单 30 天过期但无定时任务退还积分 | +| 无过期提醒 | 患者无法得知积分即将过期 | +| 无补签机制 | 中断一天即重置，缺少积分兑换补签卡 | + +### 2.2 患者参与度 + +**评分: 4/10 — 触达手段严重不足** + +已有渠道: 每日打卡、积分商城、线下活动、咨询管理、随访任务、体征上报。 + +缺失的关键互动: + +| 互动方式 | 状态 | 影响 | +|----------|------|------| +| 消息推送 (Push) | 未集成 erp-message | 随访/积分/报告/预约提醒全部缺失 | +| 健康目标与挑战 | 无 | 无法设定"30 天降压"目标，无社区排行 | +| 成就体系 (Badge) | 无 | 无"连续打卡 30 天"等徽章激励 | +| 社交互动 | 无 | 家庭成员表仅记录信息，无家庭健康管理联动 | +| 内容运营 | 基础 | 文章有 CRUD 但无推荐/阅读积分/分享积分 | + +### 2.3 随访管理运营 + +**评分: 5/10 — 单条操作效率低** + +**核心问题: 不支持批量操作。** 实际体检中心一个护士每天要处理 30-50 个随访任务，逐个操作效率极低。 + +缺失: +- 批量创建（按患者标签/疾病类型） +- 批量分配负责人 +- 批量标记完成 +- 随访工作量统计（按护士维度的完成率/响应时间） +- 随访计划模板（按疾病类型的标准化方案） + +### 2.4 健康干预闭环 + +**评分: 4/10 — 闭环完整度约 40%** + +``` +数据采集 → 异常识别 → 干预建议 → 执行跟踪 → 效果评估 + 80% 20% 0% 30% 0% +``` + +- 数据采集基本完整（体征/化验/透析） +- 异常识别仅有简单阈值判断，无实时预警 +- 干预建议完全缺失（`medical_advice` 是自由文本，无标准化方案库） +- 执行跟踪仅有随访链式创建 +- 效果评估完全缺失（无 Health Score、无干预前后对比） + +### 2.5 数据分析与报表 + +**评分: 2/10 — 不可用于运营决策** + +**严重问题: Dashboard 数据大部分是假的。** + +| 指标 | 实现方式 | 可信度 | +|------|---------|--------| +| 患者总数 | `list?page_size=1` 取 total | 部分 | +| 本月新增 | 硬编码 `0` | 不可信 | +| 本周新增 | 硬编码 `0` | 不可信 | +| 本月活跃 | 硬编码 `0` | 不可信 | +| 随访完成率 | 硬编码 `0` | 不可信 | +| 咨询总量 | `list?page_size=1` 取 total | 部分 | +| 积分统计 | SQL 聚合 | 可信 | +| 积分排行 | SQL 排序 | 可信 | + +缺失的关键运营指标: 患者覆盖率、随访完成率趋势、积分使用率、活动参与率、患者留存率、医生工作量分布。无时间维度分析，无数据导出能力。 + +### 2.6 多角色协作 + +**评分: 5/10 — 职责边界模糊** + +| 问题 | 说明 | +|------|------| +| 护士/健康管理师无独立 profile | 随访 `assigned_to` 指向医生选择器，但护士才是随访主力 | +| 职责边界不清 | `patient_doctor_relation` 只有 `primary`/`consulting`，无"健康管理师"角色 | +| 前台核销不流畅 | 需手动输入 UUID，无扫码枪集成 | +| 无转诊协作机制 | 无医生间转诊流程，无 MDT 任务分配 | +| 无智能工作负载分配 | 随访任务完全手动分配 | + +### 2.7 商业变现能力 + +**评分: 4/10 — 基础模型在，变现工具缺失** + +积分商城当前只有获取+兑换的基础闭环。缺失: +- 积分充值通道（现金购买） +- 会员等级体系 (VIP/SVIP) +- 营销工具（优惠券/限时活动/邀请有礼/满减） +- 供应商管理（商品采购成本/物流） +- 数据分析（商品热度/用户分层 RFM） + +--- + +## 3. 产品架构评估 + +> 专家角色: 资深医疗 SaaS 产品架构师（10+ 年医疗信息化产品设计经验） + +### 3.1 模块边界与耦合 + +**评分: 8/10 — 边界清晰，事件契约有进步空间** + +优点: +- 对 erp-core 仅依赖共享类型（AppError/EventBus/PaginatedResponse） +- 对 erp-auth 通过 `user_id` 外键松耦合，`Option` 允许患者先建档后绑定 +- 声明 `dependencies() = vec!["auth"]` 语义明确 + +关键问题: +- **事件发布未实现**: 设计规格定义 14 种事件，实际发布不完整 +- **message.sent 订阅为空操作**: 只打 `tracing::info`，`consultation_session.last_message_at` 不更新 +- 缺少密钥轮换机制 + +### 3.2 数据模型完整性 + +**评分: 6/10 — 覆盖核心域，存在医疗级缺口** + +已覆盖（27 实体）: 患者管理（完整）、医护管理（基本完整）、健康数据（完整）、预约排班（完整）、随访管理（完整）、咨询管理（完整）、专科血透（扩展完整）、患者运营（超预期）。 + +缺失的核心实体（按重要性排序）: + +| 实体 | 优先级 | 理由 | +|------|--------|------| +| 诊断记录 (Diagnosis) | P0 | ICD-10 编码，所有临床活动的锚点 | +| 用药记录 (Medication) | P1 | 慢病管理核心数据，小程序页面已存在 | +| 处方/医嘱 (Prescription) | P1 | 结构化处方是慢病管理核心 | +| 健康计划 (Care Plan) | P2 | 从"数据记录"到"主动干预"的关键 | +| 过敏详细记录 (Allergy) | P2 | 药物过敏交叉检查需要结构化数据 | + +### 3.3 API 设计质量 + +**评分: 7/10 — RESTful 规范，高级特性缺失** + +优点: 统一分页 `PaginatedResponse`、乐观锁 `DeleteWithVersion`、状态机校验、管理端/患者端路由分离。 + +不足: +- 无批量操作 API +- 排序参数未暴露（硬编码 `order_by_desc(CreatedAt)`） +- 日期范围过滤缺失（预约只有单日过滤） +- 统计 API 不专业（用 `list?page_size=1` 模拟） +- 咨询无实时机制 +- 导出功能单一 + +### 3.4 前端架构 + +**评分: 7/10 — 组件化程度高，全局状态管理缺失** + +Web 前端优点: API 层按领域拆分（8 个 TS 文件）、12 个共享组件、Tab 化详情页、主题适配。 + +不足: +- 无 Zustand 全局状态（健康模块共享数据如当前患者、名称缓存无法跨页面） +- StatisticsDashboard 数据质量低 +- 日期处理类型不够安全 + +小程序优点: 27 页面覆盖全面、服务层与 Web 端一一对应。 + +不足: 无离线缓存策略、无统一错误处理/重试。 + +### 3.5 多租户适配 + +**评分: 8/10 — 基础隔离完整，差异化配置不足** + +已实现: 全实体 `tenant_id` 过滤、租户生命周期钩子（seed/soft_delete）、AES-256-GCM 加密 + HMAC 索引、数据脱敏、行级数据权限。 + +缺失: 不同医疗机构类型（体检中心/社区中心/血透中心/专科诊所）的差异化配置能力。`patient` 模型是"大一统"设计，无法自定义采集项、评估量表、报告模板。 + +### 3.6 扩展性与可配置性 + +**评分: 5/10 — 架构级良好，业务层不足** + +架构级（良好）: ErpModule trait 注册、EventBus 解耦、WASM 插件保留、SeaORM Entity + Migration 扩展。 + +业务层（不足）: 无自定义表单（EAV 或 JSONB + Schema）、无自定义工作流模板、无报告模板。积分规则和标签系统是系统中少有的可配置业务模块。 + +### 3.7 竞品对比 + +| 维度 | HMS | 杏树林 | 微医 | 平安好医生 | +|------|-----|--------|------|-----------| +| 技术性能 | 极高 (Rust) | 中等 (Java) | 中等 | 中等 | +| 多租户 | 原生支持 | 后期改造 | 有限 | 有限 | +| 患者运营 | 有（积分+商城） | 无 | 无 | 有 | +| 血透专科 | 有（待完善） | 无 | 无 | 无 | +| AI 能力 | 开发中 | 成熟 | 部分 | 成熟 | +| 实时通讯 | 无 | 音视频 | 音视频 | 音视频 | +| 医疗标准 | 无 | 有 (ICD) | 有 | 有 | +| 影像管理 | 无 | 有 | 有 | 无 | +| 合规认证 | 无 | 等保三级 | 等保三级 | 等保三级 | + +**核心差距**: AI 能力、实时通讯、医疗数据标准、影像管理、合规认证。 + +--- + +## 4. 综合改进路线图 + +### Phase 1: 产品可信度修复 (P0, 2-3 人天) + +> 影响: 管理者无法决策、患者安全风险、跨模块联动断裂 + +| # | 改进项 | 涉及文件 | 复杂度 | +|---|--------|---------|--------| +| 1 | 修复 Dashboard 统计数据 | `points.ts` + `points_service.rs` + `StatisticsDashboard.tsx` | 中 | +| 2 | 补全事件发布（至少 4 个关键事件） | `event.rs` + 各 service 文件 | 中 | +| 3 | 合并 vital_signs 和 daily_monitoring | entity + service + DTO + migration | 中 | +| 4 | 增加实时异常预警 | `health_data_service.rs` + `trend_service.rs` | 中 | +| 5 | 增加 ICD-10 诊断编码支持 | 新建 entity + migration + service | 中 | +| 6 | 实现积分过期清理定时任务 | `points_service.rs` + `module.rs` | 低 | + +### Phase 2: 核心业务能力补全 (P1, 5-7 人天) + +> 影响: 临床实用性不足、患者参与度低、运营效率差 + +| # | 改进项 | 复杂度 | +|---|--------|--------| +| 7 | 结构化随访模板系统 | 高 | +| 8 | 用药记录实体 | 中 | +| 9 | 透析方案管理 | 中 | +| 10 | 体征增加体温/SpO2/血糖类型 | 低 | +| 11 | 消息推送集成 | 中 | +| 12 | 批量随访操作 | 中 | +| 13 | 修复随访类型前后端不一致 | 低 | +| 14 | 咨询 WebSocket 实时推送 | 高 | + +### Phase 3: 运营增强 (P2, 5-7 人天) + +> 影响: 差异化竞争力、患者留存、商业变现 + +| # | 改进项 | 复杂度 | +|---|--------|--------| +| 15 | 患者健康评分体系 (Health Score) | 中 | +| 16 | 会员等级和营销工具 | 中 | +| 17 | 预约资源绑定 | 中 | +| 18 | 个性化异常阈值配置 | 中 | +| 19 | 化验指标标准化字典 (LOINC) | 中 | +| 20 | 批量排班/排班模板 | 中 | +| 21 | 小程序分析埋点后端 | 低 | + +### Phase 4: 长期竞争力 (P3, 路线图) + +| # | 改进项 | +|---|--------| +| 22 | 血管通路管理 | +| 23 | 疾病风险评分模型 | +| 24 | AI 辅助诊断 (erp-ai 集成) | +| 25 | 可配置表单能力 | +| 26 | 影像管理集成 (DICOM/PACS) | +| 27 | 合规认证 (等保三级) | +| 28 | HL7 FHIR R4 数据互操作 | + +--- + +## 附录 A: 与 QA 审计计划的交叉引用 + +本分析与 [QA 审计计划](../../plans/qa-review-sop-hidden-marshmallow.md) 的发现高度重叠，以下是交叉对照: + +| QA 审计编号 | 业务分析对应 | 状态 | +|------------|-------------|------| +| 1.1 逾期随访检查器未启动 | §1.4 随访管理 — 逾期自动检查已实现但需修复 | 需修复 | +| 1.2 积分并发余额损坏 | §2.1 积分激励体系 — CAS 并发安全 | 需修复 | +| 2.4 HealthDataProvider 全 stub | §1.7 临床决策支持 — AI 集成依赖 | 需决策 | +| 2.6 小程序 DTO 不匹配 | §1.2 医疗数据管理 — 数据模型对齐 | 需修复 | +| 3.1 咨询列表显示截断 UUID | §3.4 前端架构 — 名称缓存 | 已修复 | +| 3.2 积分订单列表显示 UUID | §3.4 前端架构 — 需名称解析 | 待修复 | +| 3.4 预约状态变更无确认 | §1.3 预约排班 — 已在 AppointmentList 中实现 | 已修复 | + +## 附录 B: 工作量估算 + +| 阶段 | 人天 | 优先级 | +|------|------|--------| +| Phase 1: P0 可信度修复 | 2-3 | 立即 | +| Phase 2: P1 核心能力 | 5-7 | 本迭代 | +| Phase 3: P2 运营增强 | 5-7 | 下迭代 | +| Phase 4: P3 长期竞争力 | 路线图 | Q3-Q4 | +| **合计** | **12-17 + 路线图** | |