iven/hms
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
087e23e57b60faa4e4d2cf9841365b58eb02a434
hms/docs/discussions/2026-05-01-tri-platform-integration-audit.md
iven d712ad78c3 docs: 审计报告(8 份) + 讨论记录(4 份) 
审计报告: 基线快照/功能清单/后端完整性/事件系统/参数配置/
差距模式/错误处理/测试覆盖/审计总结报告
讨论记录: 设备管线/端到端测试/三端审计/工作台重构
2026-05-03 19:32:15 +08:00

15 KiB
Raw Blame History

三端联调深度审计报告

日期: 2026-05-01 | 参与者: Claude + iven 目标: 记录项目最真实的状况，从全局/用户/管理者三重角度审视系统

1. 基础设施状态

1.1 编译与构建

检查项 状态 详情
cargo check 通过（修复后） 修复了 2 个编译错误：HealthError::DatabaseError → DbError，approval_status move 问题
cargo test --workspace 失败 erp-plugin 测试编译失败：parse_manifest 未导入（#[cfg(test)] 缺少 use crate::manifest::parse_manifest）
pnpm build (Web) 通过 耗时 33.67s，antd chunk 1.5MB 过大
pnpm build:weapp (小程序) 通过 Sass @import deprecation 警告，pkg-health 分包 352KB 超限

1.2 数据库数据分布

表 记录数 评估
patient 32 有测试数据
doctor_profile 8 有测试数据
appointment 12 有测试数据
doctor_schedule 15 有测试数据
follow_up_task 12 有测试数据
follow_up_record 3 较少
consultation_session 4 有测试数据
consultation_message 7 有测试数据
article 5 有测试数据
alert_rules 10 有测试数据
ai_prompt 4 有测试数据
offline_event 7 有测试数据
health_record 1 极少
lab_report 2 较少
ai_analysis 0 空表
ai_suggestion 0 空表
alerts 0 空表
daily_monitoring 0 空表
device_readings 0 空表
critical_alert 0 空表
dialysis_prescription 0 空表
patient_family_member 0 空表
patient_tag_relation 0 空表
medication_reminder 0 空表
medication_record 0 空表
domain_events 1166 大量事件堆积

关键发现: 32 个表中 12 个完全空表（37.5%），说明很多功能从未被端到端使用过。

2. 后端完整性

2.1 API 路由统计

模块 路由端点数 CRUD 完整领域数
erp-health 98 15/15 全部完整
erp-ai 13 管理类全覆盖
erp-dialysis 8 2/2 完整
总计 119 —

2.2 后端已实现但无前端 UI 的端点（功能孤岛）

分类 端点数 具体内容
AI 分析 SSE 触发 4 lab-report/trends/checkup-plan/report-summary，无管理界面入口
危急值告警体系 4 列表/详情/确认/阈值配置，Web 端完全无页面
行动收件箱 2 列表/线程查看，无前端消费
统计数据 5 dashboard/lab-reports/appointments/vital-signs-report-rate/health-data
趋势生成 1 POST /trends/generate 无手动触发入口
合计 16 约 13% 的后端路由为"死端点"

2.3 Service 层健康度

  • Service → Handler → Router 映射链路: 100% 完整
  • 内部 Service（定时任务/事件消费者/工具函数）: 均有合理调用方
  • 所有实体领域达到完整 CRUD 覆盖

3. Web 前端完整性

3.1 路由与页面

  • 健康管理路由: 30 条
  • 基础 ERP 路由: 17 条
  • 健康模块共享组件: 11 个
  • API 服务文件: 12 个 health + 4 个 AI

3.2 页面功能抽样评审

页面 完整度 关键缺陷
PatientList 8/10 缺空状态、批量操作未实现
PatientDetail 9/10 作为核心枢纽页表现优秀
AppointmentList 8/10 无法编辑预约内容
AlertList 7/10 搜索未传后端、resolve 无入口、权限码拼写错误已修
FollowUpTaskList 7/10 负责人筛选器空、无法编辑任务
AiAnalysisList 7/10 无患者关联导航、无法触发分析
DialysisManageList 8/10 无 PatientDetail 入口
ConsultationList 7/10 缺患者搜索

3.3 跨页面导航（功能关联性）

当前关联度: 中等偏低（50%）

导航路径 状态
PatientList → PatientDetail ✅ 行点击
ConsultationList → ConsultationDetail ✅ 行点击
AlertList → PatientDetail ✅ 单向 Link
PatientDetail → AppointmentList ❌ 无入口
PatientDetail → ConsultationList ❌ 无入口
PatientDetail → DialysisManageList ❌ 无入口
AiAnalysisList → PatientDetail ❌ 只显示截断 ID
PatientDetail → 全局随访任务 ❌ 无跳转

3.4 死 API（已定义但无页面使用）

API 方法 文件
patientApi.manageTags patients.ts
patientApi.listFamilyMembers/createFamilyMember/updateFamilyMember/deleteFamilyMember patients.ts (4个)
alertApi.resolve alerts.ts
articleApi.view articles.ts
suggestionApi.getComparison suggestions.ts

4. 微信小程序完整性

4.1 规模

  • 主包页面: 15 个路由
  • 分包页面: 约 47 个路由
  • 页面总计: 约 62 个
  • Service 文件: 17 个（患者端 14 + 医护端 7）
  • TabBar: 4 个（首页/健康/消息/我的）

4.2 患者端核心流程覆盖

核心流程 覆盖度
微信登录 → 手机号绑定 100%
建档（就诊人管理） 100%
体征录入（8 种指标） 95%
趋势图 80%（Web 有更丰富图表）
蓝牙设备同步（BLE） 100%（Web 端没有）
预约挂号 100%
随访管理 100%
在线咨询 100%
积分系统 100%
AI 分析 100%
健康资讯 100%
线下活动 100%
通知 Tab 0%（空壳，数据写死空数组）

4.3 小程序独有功能

功能 说明
BLE 蓝牙设备同步 血压计/血糖仪/小米手环 3 种适配器
微信一键登录 wx.login + getPhoneNumber
微信订阅消息 5 种模板消息推送

5. 系统统一性分析

5.1 功能孤岛效应

从全局角度审视，系统存在以下孤岛效应：

A. AI 分析 — "有脑无手"

  • 后端 4 个 SSE 分析端点 + 建议审批 + 行动收件箱 全部就绪
  • 前端只有"查看历史"能力，无法触发分析
  • AI 分析 → 建议 → 审批 → 行动 的闭环在后端完整，前端断裂
  • 影响: AI 模块的投资回报率极低，能力已实现但无法被用户触及

B. 危急值告警 — "有声无窗"

  • 后端告警引擎 + 规则配置 + 阈值管理 + 危急值确认 全部就绪
  • Web 前端只有普通告警列表，危急值体系完全无 UI
  • 小程序有告警查看但无危急值专属页面
  • 影响: 医疗安全相关功能缺口，危急值发现后可能无法及时处理

C. 统计仪表盘 — "有数无图"

  • 后端 9 个统计端点就绪（患者/咨询/随访/化验/预约/体征上报率/透析等）
  • Web 前端只有 StatisticsDashboard 一个页面，仅消费了部分端点
  • 小程序只有医护仪表盘（6 指标卡片），无完整统计
  • 影响: 管理者视角缺失，无法通过数据驱动决策

D. 患者详情 — "有门无路"

  • PatientDetail 作为核心枢纽页有 8 个 Tab，数据展示完善
  • 但从 PatientDetail 无法跳转到预约、咨询、透析、全局随访等关联功能
  • AI 分析列表也不提供到 PatientDetail 的导航
  • 影响: 用户需要在多个页面间手动切换，无法形成工作流闭环

5.2 数据一致性

问题 严重度 说明
domain_events 堆积 1166 条 LOW outbox 模式未清理已消费事件
12 个空表 MEDIUM 大量功能未被端到端验证
通知 Tab 空壳 HIGH 小程序消息页"通知"Tab 数据写死空数组
erp-plugin 测试编译失败 MEDIUM parse_manifest 在 #[cfg(test)] 中未导入

5.3 过度开发 vs 欠开发

过度开发（后端就绪但无前端）：

  • 危急值告警体系（4 端点）— 后端完整，前端零页面
  • AI SSE 分析（4 端点）— 后端完整，前端零触发
  • 行动收件箱（2 端点）— 后端完整，前端零消费
  • 统计数据（5 端点）— 后端完整，前端部分消费

欠开发（设计目标未达成）：

  • 小程序通知系统 — 完全未实现（空壳）
  • 患者详情关联导航 — 跨功能跳转缺失
  • 家属管理 UI — 4 个 API 就绪但无页面

6. 三端覆盖度矩阵

功能领域 后端 Web 前端 小程序 完整度
患者 CRUD 100% 100% 100% ✅ 完整
体征数据 100% 90% 95% ✅ 基本完整
化验报告 100% 100% 100% ✅ 完整
健康档案 100% 100% 100% ✅ 完整
预约排班 100% 95% 100% ✅ 基本完整
随访管理 100% 90% 100% ✅ 基本完整
咨询管理 100% 95% 100% ✅ 基本完整
健康资讯 100% 100% 100% ✅ 完整
积分商城 100% 100% 100% ✅ 完整
线下活动 100% 100% 100% ✅ 完整
告警系统 100% 70% 80% ⚠️ Web 缺危急值/resolve
AI 分析 100% 40% 60% ❌ SSE 无触发入口
危急值告警 100% 0% 0% ❌ 完全无 UI
统计仪表盘 100% 50% 30% ⚠️ 端点就绪但消费不足
行动收件箱 100% 0% 0% ❌ 完全无 UI
设备管理 100% 60% 100% ⚠️ Web 端缺 BLE 能力
透析管理 100% 80% 100% ✅ 基本完整
通知系统 80% 50% 0% ❌ 小程序空壳
家属管理 100% 0% 0% ❌ API 就绪无 UI

7. 优先行动建议

P0 — 功能断裂（影响核心用户体验）

  1. AI 分析闭环打通 — 在患者详情或独立页面增加"发起 AI 分析"按钮，让 SSE 能力被触及
  2. 患者详情关联导航 — 增加"查看该患者预约/咨询/透析"快捷入口
  3. 小程序通知 Tab — 对接后端通知 API，不再写死空数据

P1 — 医疗安全

  1. 危急值告警 Web UI — 至少增加危急值列表页 + 确认操作
  2. erp-plugin 测试修复 — 补充 use crate::manifest::parse_manifest 导入

P2 — 管理者视角

  1. 统计仪表盘完善 — 消费已就绪的 5 个统计端点
  2. 家属管理 UI — 在 PatientDetail 增加"家庭成员"Tab
  3. AI 建议前后对比 — 集成 suggestionApi.getComparison

8. 实际验证发现的修正（2026-05-01 浏览器 + 代码验证）

8.1 报告修正

原报告结论 实际验证结果 修正
登录页标题"HMS" 登录页显示 "HMR Platform"，与侧边栏 "HMS 健康" 不一致 新增：品牌命名不统一
患者数据 32 条 30 条是 E2E 自动化测试生成的 E2E患者_*，仅 2 条真实数据 修正：系统几乎没有被真实使用过
统计端点"部分覆盖" API 验证患者统计、化验报告统计、预约统计、体征上报率、仪表盘统计 全部返回正常数据 修正：后端统计能力完整，仅前端消费不足
危急值告警"后端完整" GET /health/critical-alerts 返回 500 Internal Server Error 修正：危急值端点有 bug，后端也不完整
透析管理"完整 CRUD" GET /health/dialysis-records 返回 405（只接受 POST），必须按患者查询 修正：透析记录没有全局列表，必须先选患者
小程序咨询"100% 覆盖" 首页/健康页/个人中心 均无入口 跳转到在线咨询页 修正：咨询功能是"页面孤岛"，用户无法发现
AI SSE "无触发入口" POST /ai/analyze/lab-report 端点存在且返回验证错误（需真实数据） 确认：端点可用但前端无调用入口
行动收件箱"0 数据" API 返回 total=0 ✅ 确认

8.2 新发现（验证前未识别）

A. 品牌一致性

  • 登录页标题 "HMR Platform"，侧边栏 "HMS 健康"，版权 "HMR Platform · ©汕头市智界科技有限公司"
  • 产品名称在 HMR/HMS 之间摇摆

B. 数据质量 — 测试污染

  • 32 个患者中 30 个是 E2E 自动化测试创建的 E2E患者_*
  • domain_events 表堆积 1166 条未清理
  • 建议清理测试数据或建立独立测试租户

C. 小程序 AI 建议跳转错误

  • 健康页 AI 建议卡片识别出 appointment/followup 类型建议后
  • 点击统一跳转到 设置页（/pages/pkg-profile/settings/index）
  • 而非预期的预约创建页或随访详情页 — 设计缺陷

D. 小程序咨询功能完全孤立

  • /pages/consultation/index 已注册，页面存在
  • 但首页/健康页/个人中心均无入口指向它
  • 唯一入口在消息 Tab 的"咨询"子 Tab
  • 用户极难发现这个功能

E. Web 告警页面已存在但侧边栏无入口

  • /health/alerts 可直接 URL 访问，页面功能完整
  • 但侧边栏菜单中 没有告警管理入口（未出现在菜单配置中）
  • 同理 /health/alert-dashboard 和 /health/alert-rules 也无菜单入口

F. Web 侧边栏缺少多个页面入口

已注册路由 侧边栏入口 状态
/health/alerts 无 需手动输入 URL
/health/alert-dashboard 无 需手动输入 URL
/health/alert-rules 无 需手动输入 URL
/health/dialysis 有（"透析管理"） ✅
/health/devices 有（"设备管理"） ✅
/health/articles 有（"资讯管理"） ✅

9. 总结

项目整体完成度评估: 75%（实际验证后从 78% 下调）

  • 后端 (93%): 119 个路由、CRUD 全覆盖，但危急值告警端点有 500 错误
  • Web 前端 (68%): 核心页面功能完整，但存在隐性问题：告警页面有路由无菜单入口、AI/统计孤岛、跨模块导航断裂
  • 小程序 (80%): 患者端覆盖度高，但咨询功能孤立（用户无法发现）、AI 建议跳转错误、通知空壳
  • 数据质量 (35%): 30/32 患者为 E2E 测试数据，12/32 表完全空，系统几乎未经真实使用

最突出的矛盾: 后端能力远超前端消费速度，约 13% 的路由为"死端点"。而已经暴露给用户的功能中，又有多个存在导航断裂和入口缺失，形成了"有能力但不可达"的双重问题。

新发现的系统性问题:

  1. 品牌不一致 — HMR/HMS 混用
  2. 菜单配置缺失 — 告警相关 3 个页面有路由无菜单
  3. 小程序导航断裂 — 咨询功能孤立、AI 建议跳转到设置页
  4. 测试数据污染 — E2E 测试未清理导致数据不可信

变更记录

日期 变更
2026-05-01 初始版本 — 三端联调深度审计
2026-05-01 实际验证修正 — 浏览器+API+代码分析，6 项报告修正 + 6 项新发现，完成度从 78% 下调至 75%
Reference in New Issue View Git Blame Copy Permalink