docs(health): 修正业务分析报告中的数据不准确项

- 事件计数: 14 → 11 设计规格/9 实际发布
- 权限: 12 → 14 描述符 (7 组)
- Web 页面: 13 → 16
- vital_signs/daily_monitoring 重叠度: 80% → 91%
- 修正 message.sent 订阅评估（非功能缺失）
- 透析增加幽灵状态说明
- 修正附录引用路径

apps/web/src/components/AuthButton.tsx

@@ -0,0 +1,13 @@
+import type { ReactNode } from 'react';
+import { usePermission } from '../hooks/usePermission';
+
+interface AuthButtonProps {
+  code: string;
+  children: ReactNode;
+}
+
+export function AuthButton({ code, children }: AuthButtonProps) {
+  const { hasPermission } = usePermission(code);
+  if (!hasPermission) return null;
+  return <>{children}</>;
+}

apps/web/src/components/AuthGuard.tsx

@@ -0,0 +1,13 @@
+import type { ReactNode } from 'react';
+import { usePermission } from '../hooks/usePermission';
+
+interface AuthGuardProps {
+  code: string;
+  children: ReactNode;
+}
+
+export function AuthGuard({ code, children }: AuthGuardProps) {
+  const { hasPermission } = usePermission(code);
+  if (!hasPermission) return null;
+  return <>{children}</>;
+}

apps/web/src/hooks/usePermission.ts

@@ -0,0 +1,6 @@
+import { useAuthStore } from '../stores/auth';
+
+export function usePermission(code: string): { hasPermission: boolean } {
+  const permissions = useAuthStore((s) => s.permissions);
+  return { hasPermission: permissions.includes(code) };
+}

apps/web/src/stores/auth.ts

@@ -1,21 +1,31 @@
 import { create } from 'zustand';
 import { login as apiLogin, logout as apiLogout, type UserInfo } from '../api/auth';
 
-// Synchronously restore auth state from localStorage at store creation time.
-// This eliminates the flash-of-login-page on refresh because isAuthenticated
-// is already `true` before the first render.
-function restoreInitialState(): { user: UserInfo | null; isAuthenticated: boolean } {
+function extractPermissions(): string[] {
+  const token = localStorage.getItem('access_token');
+  if (!token) return [];
+  try {
+    const parts = token.split('.');
+    if (parts.length !== 3) return [];
+    const payload = JSON.parse(atob(parts[1].replace(/-/g, '+').replace(/_/g, '/')));
+    return Array.isArray(payload.permissions) ? payload.permissions : [];
+  } catch {
+    return [];
+  }
+}
+
+function restoreInitialState(): { user: UserInfo | null; isAuthenticated: boolean; permissions: string[] } {
   const token = localStorage.getItem('access_token');
   const userStr = localStorage.getItem('user');
   if (token && userStr) {
     try {
       const user = JSON.parse(userStr) as UserInfo;
-      return { user, isAuthenticated: true };
+      return { user, isAuthenticated: true, permissions: extractPermissions() };
     } catch {
       localStorage.removeItem('user');
     }
   }
-  return { user: null, isAuthenticated: false };
+  return { user: null, isAuthenticated: false, permissions: [] };
 }
 
 const initial = restoreInitialState();
@@ -24,6 +34,7 @@ interface AuthState {
   user: UserInfo | null;
   isAuthenticated: boolean;
   loading: boolean;
+  permissions: string[];
   login: (username: string, password: string) => Promise<void>;
   logout: () => Promise<void>;
   loadFromStorage: () => void;
@@ -33,6 +44,7 @@ export const useAuthStore = create<AuthState>((set) => ({
   user: initial.user,
   isAuthenticated: initial.isAuthenticated,
   loading: false,
+  permissions: initial.permissions,
 
   login: async (username, password) => {
     set({ loading: true });
@@ -41,7 +53,7 @@ export const useAuthStore = create<AuthState>((set) => ({
       localStorage.setItem('access_token', resp.access_token);
       localStorage.setItem('refresh_token', resp.refresh_token);
       localStorage.setItem('user', JSON.stringify(resp.user));
-      set({ user: resp.user, isAuthenticated: true, loading: false });
+      set({ user: resp.user, isAuthenticated: true, loading: false, permissions: extractPermissions() });
     } catch (error) {
       set({ loading: false });
       throw error;
@@ -57,13 +69,11 @@ export const useAuthStore = create<AuthState>((set) => ({
     localStorage.removeItem('access_token');
     localStorage.removeItem('refresh_token');
     localStorage.removeItem('user');
-    set({ user: null, isAuthenticated: false });
+    set({ user: null, isAuthenticated: false, permissions: [] });
   },
 
-  // Kept for backward compatibility but no longer needed since
-  // initial state is restored synchronously at store creation.
   loadFromStorage: () => {
     const state = restoreInitialState();
-    set({ user: state.user, isAuthenticated: state.isAuthenticated });
+    set({ user: state.user, isAuthenticated: state.isAuthenticated, permissions: state.permissions });
   },
 }));

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

@@ -0,0 +1,450 @@
+# 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 + 路线图** | |