# HMS 健康管理模块业务流程合理性分析

> 日期: 2026-04-25
> 状态: Draft
> 分析方法: 三专家组并行深度审查（临床业务 + 运营管理 + 产品架构）

---

## 执行摘要

HMS 健康管理模块已完成初始实现，包含 27 个数据库实体、14 个权限描述符（7 组 .list/.manage）、16 个 Web 页面、21 个小程序页面。本次分析从**临床业务流程、运营管理有效性、产品架构竞争力**三个维度进行深度审查。

### 核心结论

**工程基础设施达到生产级水准。** 多租户隔离、CAS 并发控制、乐观锁、事件驱动架构、数据加密（AES-256 + HMAC）、审计日志等能力一应俱全。

**业务深度存在三个核心缺口：**

| 缺口 | 影响 | 紧急度 |
|------|------|--------|
| 诊断编码缺失 | 随访/趋势分析/统计报表缺乏医学语义锚点，与 HIS/LIS 无法对接 | P0 |
| 统计数据造假 | Dashboard 硬编码 0 值，管理者无法做运营决策 | P0 |
| 消息推送未集成 | 设计规格定义 11 种事件，代码发布 9 种（缺失 `follow_up.overdue` 等），患者触达手段严重不足 | 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` 字段 91% 重叠 | 数据冗余 + 命名不一致（`systolic_bp_morning` vs `morning_bp_systolic`），趋势分析只查 `vital_signs` 表，`daily_monitoring` 数据完全被忽略 |
| 缺乏采集时间精度 | 只有 `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/铁剂/磷结合剂)、症状/并发症未结构化。此外，entity 注释中定义了 `completed` 状态但无代码路径可达，存在"幽灵状态"问题。

### 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<Uuid>` 允许患者先建档后绑定
- 声明 `dependencies() = vec!["auth"]` 语义明确

关键问题:
- **事件发布不完整**: 设计规格定义 11 种事件，代码实际发布 9 种（含 2 种设计规格外的: `doctor.online_status_changed`/`lab_report.uploaded`）。缺失 `follow_up.overdue` 等关键事件
- **message.sent 订阅为空操作**: 只打 `tracing::info`，但 `consultation_session.last_message_at` 已在 `create_message` 方法中通过 CAS 直接更新，此事件订阅是预留扩展点而非功能缺失
- 缺少密钥轮换机制

### 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<T>`、乐观锁 `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 | 补全事件发布（至少 `follow_up.overdue`） | `event.rs` + `follow_up_service.rs` | 中 |
| 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-brainstorm-floofy-finch.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 + 路线图** | |