df1d85bfde
- T40 UI 审计计划和结果文档（docs/qa/） - wiki 更新：miniprogram 设计系统合规审计记录 + index 关键数字更新 - 审计 V2 完整报告（docs/audits/v2/） - 讨论记录文档（docs/discussions/） - 设计规格和实施计划（docs/superpowers/） - 角色测试计划和结果（docs/qa/role-test-*） - Docker 生产部署配置
330 lines
13 KiB
Markdown
330 lines
13 KiB
Markdown
# V2 审计 — 多角色专家评审
|
||
|
||
> 日期: 2026-05-04 | 方法: 5 角色专家审视，按 10 维度评分
|
||
|
||
## 一、评审概述
|
||
|
||
本报告由 5 个专家角色分别审视 HMS 系统的 20 个功能域，按统一评分框架打分。每个角色关注不同维度，最终汇总为系统级评价。
|
||
|
||
### 评审角色
|
||
|
||
| 角色 | 关注维度 | 权重 |
|
||
|------|---------|------|
|
||
| 产品经理 | D1 目标 + D3 连通 + D10 UX | 25% |
|
||
| 技术架构师 | D2 代码 + D4 数据流 + D8 性能 | 25% |
|
||
| 安全专家 | D5 安全 + D6 错误处理 | 20% |
|
||
| DevOps 工程师 | D7 日志 + D8 性能 + D9 测试 | 15% |
|
||
| 医疗领域专家 | D1 目标 + D4 数据流 + D10 UX | 15% |
|
||
|
||
### 评分方法
|
||
|
||
- 每个角色对每个功能域给出 0-100 分
|
||
- 系统总分 = 各角色加权平均
|
||
- 评级: A(90+) / B(80-89) / C(70-79) / D(60-69) / F(<60)
|
||
|
||
---
|
||
|
||
## 二、系统级总评
|
||
|
||
| 角色 | 评分 | 评级 |
|
||
|------|------|------|
|
||
| 产品经理 | 78 | C |
|
||
| 技术架构师 | 70 | C |
|
||
| 安全专家 | 65 | D |
|
||
| DevOps 工程师 | 68 | D |
|
||
| 医疗领域专家 | 75 | C |
|
||
| **加权总分** | **72** | **C** |
|
||
|
||
> V1 审计未做专家评审，无法对比。72 分反映"后端完整但前端未接入、安全有漏洞、测试覆盖不足"的现状。
|
||
|
||
---
|
||
|
||
## 三、产品经理评审（78/C）
|
||
|
||
### 3.1 功能完整性 vs 客户需求
|
||
|
||
**已交付的核心价值链**（覆盖血透中心主要工作流）：
|
||
- 透析治疗全流程：预约→透析记录→KDIGO 风险评估（后端完整，前端部分接入）
|
||
- 健康监测闭环：体征录入→阈值告警→SSE 推送→行动收件箱
|
||
- 患者触达：小程序体征录入/查看/咨询/随访完成
|
||
- AI 辅助决策：趋势分析 SSE + 建议系统（后端完整）
|
||
|
||
**未交付的关键体验**：
|
||
- 护理计划/班次/BLE 网关/家庭代理 — 4 个模块 34 条路由完全无 UI，无法交付给客户
|
||
- AI 前后对比功能 — 关怀闭环的核心价值，目前仅日志
|
||
- MP 适老化不足 — 15 处字号低于 22px 阈值，老年患者体验差
|
||
|
||
### 3.2 MVP 边界评估
|
||
|
||
| 功能 | MVP 必须 | 当前状态 | 缺口 |
|
||
|------|---------|---------|------|
|
||
| 透析全流程 | 是 | 85% | 风险评分未自动串联 |
|
||
| 健康监测 | 是 | 90% | 危急值阈值管理页缺失 |
|
||
| 告警推送 | 是 | 80% | 双路径可能重复 |
|
||
| 护理计划 | 否（P1） | 50%（仅后端） | 全部前端 |
|
||
| 家庭代理 | 否（P2） | 50%（仅后端） | 全部前端 |
|
||
| AI 报告 | 是 | 70% | 前后对比缺失 |
|
||
|
||
### 3.3 按域评分
|
||
|
||
| 域 | 分数 | 说明 |
|
||
|----|------|------|
|
||
| F1-F6 核心医疗 | 85 | 目标清晰，三端覆盖较好 |
|
||
| F7-F8 内容/积分 | 75 | 非核心但完善 |
|
||
| F9 告警 | 80 | 功能完整，UX 可优化 |
|
||
| F10 AI | 70 | 后端强，前端弱，对比缺失 |
|
||
| F11 透析 | 88 | MP 100% 覆盖，流程顺畅 |
|
||
| F12 仪表盘 | 75 | 统计维度够但展示偏简 |
|
||
| F13 行动收件箱 | 78 | SQL 注入风险影响交付 |
|
||
| F14-F17 孤立模块 | 30 | 后端完整但无法交付 |
|
||
| F18-F19 FHIR/OAuth | 55 | 基础设施，非 MVP 必需 |
|
||
| F20 日聚合 | 72 | 数据层完整，展示层不足 |
|
||
|
||
---
|
||
|
||
## 四、技术架构师评审（70/C）
|
||
|
||
### 4.1 架构优势
|
||
|
||
1. **模块边界清晰** — 18 crate 严格通过 EventBus + trait 通信，无跨 crate 直接依赖
|
||
2. **SeaORM Entity 统一标准** — 所有实体含 tenant_id/version/软删除/审计字段
|
||
3. **事件驱动** — 51 个事件类型，outbox 模式保证可靠投递
|
||
4. **PII 加密完备** — AES-256-GCM + HMAC 盲索引，覆盖所有敏感字段
|
||
5. **服务拆分合理** — health_data_service 拆为 vital_signs/alert/daily_monitoring 等子模块
|
||
|
||
### 4.2 架构风险
|
||
|
||
| 风险 | 严重度 | 说明 |
|
||
|------|--------|------|
|
||
| SQL 注入 | **CRITICAL** | action_inbox_service.rs:272-306 format! 拼接 |
|
||
| BLE 双写无事务 | **HIGH** | vital_signs 与 device_readings 可能不一致 |
|
||
| 护理计划无事务 | **HIGH** | 三表写入无包裹，中间失败致孤立记录 |
|
||
| SSE unbounded | MEDIUM | 告警风暴时内存压力 |
|
||
| 串行处理多患者 | MEDIUM | BLE 网关 for 循环，延迟线性增长 |
|
||
| 护理计划状态无枚举 | LOW | 自由字符串可写入非法状态 |
|
||
|
||
### 4.3 微服务拆分准备度
|
||
|
||
| 维度 | 准备度 | 说明 |
|
||
|------|--------|------|
|
||
| 模块独立性 | 90% | EventBus 解耦良好 |
|
||
| 数据库拆分 | 70% | 共享 PostgreSQL，需 schema 分离 |
|
||
| 认证独立 | 85% | JWT + middleware 已解耦 |
|
||
| API 网关 | 40% | 无统一网关层 |
|
||
| 服务发现 | 0% | 单体架构，未规划 |
|
||
|
||
### 4.4 按域评分
|
||
|
||
| 域 | 分数 | 说明 |
|
||
|----|------|------|
|
||
| F1-F6 核心医疗 | 78 | 代码结构好，数据流有缺口 |
|
||
| F9 告警 | 72 | 双路径复杂度高 |
|
||
| F10 AI | 68 | 缓存未启用，前后对比缺失 |
|
||
| F13 行动收件箱 | 55 | SQL 注入拉低 |
|
||
| F14-F17 孤立模块 | 40 | 代码存在但架构断裂 |
|
||
| F18 FHIR | 50 | allowed_patient_ids 越权 |
|
||
| F19 OAuth | 45 | 权限缺失 + JWT fallback |
|
||
|
||
---
|
||
|
||
## 五、安全专家评审（65/D）
|
||
|
||
### 5.1 安全合规状态
|
||
|
||
| 检查项 | 状态 | 说明 |
|
||
|--------|------|------|
|
||
| SQL 注入防护 | **FAIL** | action_inbox_service.rs format! 拼接 patient_id/user_id |
|
||
| PII 加密 | **PASS** | AES-256-GCM，8 个实体全覆盖 |
|
||
| 多租户隔离 | **PASS** | 应用层 tenant_id + PostgreSQL RLS |
|
||
| 权限码完整性 | **WARN** | 53 个 Descriptor 声明，OAuth 5 端点缺失 |
|
||
| API Key 安全 | **PASS** | SHA-256 哈希 + OsRng 随机生成 |
|
||
| XSS 防护 | **PASS** | 未发现 dangerouslySetInnerHTML |
|
||
| SSE 认证 | **PASS** | JWT query param + tenant_id 验证 |
|
||
| JWT Secret | **WARN** | 硬编码 fallback "dev-secret-key" |
|
||
| FHIR 越权 | **FAIL** | allowed_patient_ids 未在查询层执行 |
|
||
| 速率限制 | **WARN** | 已建模未执行 |
|
||
|
||
### 5.2 合规风险评估
|
||
|
||
**《个人信息保护法》合规**:
|
||
- PII 加密: 合规（AES-256-GCM）
|
||
- 数据最小化: 基本合规（脱敏查看支持）
|
||
- 第三方数据共享: 风险（FHIR allowed_patient_ids 未强制执行）
|
||
- 审计日志: 合规（140+ 处审计记录）
|
||
|
||
**《健康医疗数据安全指南》合规**:
|
||
- 数据分类分级: 部分合规（加密字段覆盖全，但分类标签缺失）
|
||
- 数据出境: 不适用（私有部署）
|
||
- 应急响应: 不合规（无安全事件自动告警机制）
|
||
|
||
### 5.3 按域评分
|
||
|
||
| 域 | 分数 | 关键问题 |
|
||
|----|------|---------|
|
||
| F13 行动收件箱 | 40 | SQL 注入（SEC-01） |
|
||
| F18 FHIR | 50 | allowed_patient_ids 越权（SEC-03） |
|
||
| F19 OAuth | 45 | 权限缺失（SEC-02）+ JWT fallback（SEC-04） |
|
||
| F1-F6 核心医疗 | 85 | 权限+PII 完善 |
|
||
| F9 告警 | 75 | SSE 认证 OK，无特殊风险 |
|
||
| F16 BLE 网关 | 70 | API Key 安全 OK，HTTPS 需反向代理 |
|
||
|
||
---
|
||
|
||
## 六、DevOps 工程师评审（68/D）
|
||
|
||
### 6.1 可观测性评估
|
||
|
||
| 维度 | 状态 | 说明 |
|
||
|------|------|------|
|
||
| tracing 覆盖 | **70%** | 17 个 service 文件 116 处 tracing，4/6 新增 service 零覆盖 |
|
||
| 审计日志 | **85%** | 140+ 处，覆盖所有关键操作 |
|
||
| 错误监控 | **60%** | AppError 统一响应，但无外部告警（Sentry/Datadog） |
|
||
| 性能指标 | **30%** | 无 Prometheus/Grafana 集成 |
|
||
| 分布式追踪 | **0%** | 无 OpenTelemetry |
|
||
|
||
### 6.2 部署复杂度
|
||
|
||
| 组件 | 复杂度 | 说明 |
|
||
|------|--------|------|
|
||
| 后端服务 | 中 | 单 Axum 进程，cargo run 即可 |
|
||
| 数据库 | 低 | PostgreSQL + SeaORM 自动迁移 |
|
||
| 前端 Web | 低 | Vite SPA，pnpm build |
|
||
| 小程序 | 中 | Taro 编译 + 微信审核 |
|
||
| 插件系统 | 高 | WASM 编译 + 热加载 |
|
||
| 基础设施 | 中 | Docker Compose 一键启动 |
|
||
|
||
### 6.3 测试覆盖评估
|
||
|
||
| 层 | 覆盖率 | 说明 |
|
||
|----|--------|------|
|
||
| 后端单元+集成 | **80%+** | 772 测试函数，97.5% 通过 |
|
||
| Web 前端 | **15%** | 62 文件，但断言深度未知 |
|
||
| MP 小程序 | **0%** | 40+ 页面零测试 |
|
||
| E2E | **5%** | 仅 5 个 Playwright spec |
|
||
| 新增模块 | **0%** | care_plan/shift/ble_gateway/family_proxy 零测试 |
|
||
|
||
### 6.4 按域评分
|
||
|
||
| 域 | 分数 | 说明 |
|
||
|----|------|------|
|
||
| F1-F6 核心医疗 | 72 | 后端测试好，前端弱 |
|
||
| F14-F17 新增模块 | 30 | 零测试+零日志 |
|
||
| F10 AI | 55 | 集成测试有，E2E 无 |
|
||
| F18 FHIR | 25 | 零测试 |
|
||
| F19 OAuth | 30 | 零测试 |
|
||
|
||
---
|
||
|
||
## 七、医疗领域专家评审（75/C）
|
||
|
||
### 7.1 临床工作流合理性
|
||
|
||
**透析全流程**（核心工作流）:
|
||
- 预约→透析记录→干体重/超滤量/血流量记录 → 合理
|
||
- KDIGO 风险评分 → 有价值，但未自动串联 → 效率低
|
||
- 透析间期监测（体征录入）→ 合理，MP 支持好
|
||
|
||
**随访工作流**:
|
||
- 随访任务创建→分配→执行→记录 → 标准化流程，合理
|
||
- AI 建议关联随访 → 设计好，但前后对比未实现，闭环断裂
|
||
- 批量随访操作后端有但前端未调用 → 限制效率
|
||
|
||
**护理工作流**:
|
||
- 护理计划→项目→预后 → 概念正确
|
||
- 班次→交接班 → 血透中心刚需
|
||
- 但两个模块完全无 UI → 无法使用
|
||
|
||
### 7.2 FHIR 标准合规性
|
||
|
||
| R4 要求 | 状态 | 说明 |
|
||
|---------|------|------|
|
||
| 资源类型覆盖 | **60%** | Patient/Observation/Encounter/Device，缺少 Condition/MedicationRequest |
|
||
| Bundle 结构 | **70%** | 缺 link 字段 |
|
||
| 搜索参数 | **50%** | 仅支持 gt/lt，缺 eq/ge/le |
|
||
| $everything 操作 | **40%** | 无分页限制，血压 ID 重复 |
|
||
| OAuth2 保护 | **60%** | Client Credentials OK，缺 Authorization Code |
|
||
|
||
### 7.3 患者安全评估
|
||
|
||
| 风险 | 严重度 | 说明 |
|
||
|------|--------|------|
|
||
| 告警延迟/丢失 | 中 | SSE 无背压，告警风暴可能丢失 |
|
||
| 体征数据不一致 | 高 | BLE 双写无事务，可能影响临床决策 |
|
||
| 危急值阈值管理 | 中 | 后端有阈值配置，但 Web 无管理页 |
|
||
| 适老化不足 | 中 | 15 处字号低于 22px，老年患者操作困难 |
|
||
|
||
### 7.4 按域评分
|
||
|
||
| 域 | 分数 | 说明 |
|
||
|----|------|------|
|
||
| F11 透析 | 85 | 流程完整，MP 覆盖好 |
|
||
| F4 预约 | 88 | 三端 100%，血透刚需 |
|
||
| F5 随访 | 82 | 流程合理，对比功能缺失 |
|
||
| F3 健康数据 | 78 | 数据完整，BLE 有风险 |
|
||
| F14 护理计划 | 35 | 概念好但无法使用 |
|
||
| F18 FHIR | 40 | R4 合规不足 |
|
||
|
||
---
|
||
|
||
## 八、综合结论与 Top 5 必修项
|
||
|
||
### 8.1 各角色共识
|
||
|
||
5 个专家角色一致认同以下结构性问题：
|
||
|
||
1. **安全基础不牢** — SQL 注入 + FHIR 越权 + OAuth 权限缺失，不修复不能上线
|
||
2. **5 个模块孤立** — 后端投入产出为零（34 条路由无 UI），需明确交付计划
|
||
3. **测试覆盖严重不足** — MP 零测试 + 新增模块零测试，回归风险极高
|
||
4. **AI 关怀闭环断裂** — 前后对比未实现，"AI 驱动主动关怀"定位不成立
|
||
5. **可观测性缺口** — 4/6 新增 service 零 tracing，生产排障困难
|
||
|
||
### 8.2 Top 5 必修项（Phase 2 前必须完成）
|
||
|
||
| # | 问题 | 角色共识度 | 工作量 |
|
||
|---|------|-----------|--------|
|
||
| 1 | **C1: SQL 注入修复** — action_inbox_service.rs 参数化查询 | 5/5 | 2h |
|
||
| 2 | **C2: FHIR allowed_patient_ids 强制执行** — 查询层过滤 | 4/5 | 4h |
|
||
| 3 | **H5: OAuth handler require_permission** — 5 端点权限 | 4/5 | 1h |
|
||
| 4 | **M3: JWT Secret 移除硬编码 fallback** — 启动时校验 | 4/5 | 1h |
|
||
| 5 | **H2: AI 前后对比功能实现** — 关怀闭环核心 | 4/5 | 8h |
|
||
|
||
**总工作量: ~16h**
|
||
|
||
### 8.3 Phase 2 前置条件评估
|
||
|
||
| 条件 | 状态 | 说明 |
|
||
|------|------|------|
|
||
| P0 安全修复完成 | **未开始** | C1/C2/H5/M3 四项 |
|
||
| AI 关怀闭环通 | **未开始** | H2 前后对比 |
|
||
| 核心模块有测试 | **部分** | 后端 80%，前端/MP 不足 |
|
||
| 日志覆盖 80%+ | **未达标** | 4/6 新 service 零 tracing |
|
||
|
||
**结论**: Phase 2（患者体验重构）可规划，但需先完成 P0 安全修复（~8h）和 AI 闭环（~8h）。安全基础不牢则生产部署风险不可接受。
|
||
|
||
---
|
||
|
||
## 九、专家评审按域评分汇总
|
||
|
||
| 功能域 | 产品 | 架构 | 安全 | DevOps | 医疗 | 加权均 |
|
||
|--------|------|------|------|--------|------|--------|
|
||
| F1 患者 | 85 | 78 | 85 | 72 | 80 | **81** |
|
||
| F2 医生 | 82 | 80 | 85 | 70 | 78 | **80** |
|
||
| F3 健康数据 | 80 | 75 | 85 | 68 | 78 | **78** |
|
||
| F4 预约 | 88 | 82 | 85 | 75 | 88 | **85** |
|
||
| F5 随访 | 82 | 78 | 80 | 72 | 82 | **80** |
|
||
| F6 咨询 | 85 | 80 | 85 | 72 | 80 | **81** |
|
||
| F7 内容 | 75 | 72 | 80 | 65 | 70 | **73** |
|
||
| F8 积分 | 72 | 70 | 80 | 60 | 65 | **70** |
|
||
| F9 告警 | 80 | 72 | 75 | 68 | 78 | **76** |
|
||
| F10 AI | 70 | 68 | 78 | 55 | 72 | **69** |
|
||
| F11 透析 | 88 | 78 | 80 | 75 | 85 | **82** |
|
||
| F12 仪表盘 | 75 | 72 | 78 | 65 | 70 | **73** |
|
||
| F13 行动收件箱 | 78 | 55 | 40 | 68 | 75 | **61** |
|
||
| F14 护理计划 | 30 | 40 | 78 | 30 | 35 | **41** |
|
||
| F15 班次 | 30 | 40 | 78 | 30 | 35 | **41** |
|
||
| F16 BLE 网关 | 30 | 45 | 70 | 25 | 30 | **41** |
|
||
| F17 家庭代理 | 30 | 40 | 78 | 30 | 35 | **41** |
|
||
| F18 FHIR | 55 | 50 | 50 | 25 | 40 | **46** |
|
||
| F19 OAuth | 55 | 45 | 45 | 30 | 40 | **45** |
|
||
| F20 日聚合 | 72 | 65 | 80 | 55 | 70 | **69** |
|