hms/docs/superpowers/specs/2026-04-25-health-module-business-analysis-design.md

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 审计计划 的发现高度重叠，以下是交叉对照:

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 + 路线图