wangyizhe/his

Fork 0

Files

华佗 de3d8ad567 docs(bug): 诸葛亮分析报告 Bug #719

2026-06-13 02:11:14 +08:00

5.9 KiB

Raw Blame History

Bug #719 诸葛亮分析报告

文档类型: Bug分析 分析时间: 2026-06-13 02:11:11 分析模型: mimo-v2.5 (LLM深度分析)

基本信息

Bug #: 719
标题: 【护士站-医嘱校对】已停止列表：频次/用法及停嘱医生字段未回写显示
模块: 病区护士工作站
提出人: 陈显精

Now I have a complete understanding of the bug. Let me provide the analysis.

一、Bug 理解

禅道 Bug 原文

标题: 【护士站-医嘱校对】已停止列表：频次/用法及停嘱医生字段未回写显示

重现步骤:

医生端已对某医嘱进行"停嘱"操作（如：注射用头孢哌酮舒巴坦钠）
登录护士端进入"住院护士站" > "医嘱校对"
在查询页签中点击"已停止"标签
查看对应医嘱记录的"频次/用法"及"停嘱医生"两列

结果: 列表中"频次/用法"及"停嘱医生"列内容为空，未显示任何数据。

期望: 列表对应的"频次/用法"及"停嘱医生"列应正确显示数据，且与临床医生端显示内容一致（如：每日一次静脉滴注、内科医生1）。

附图关键信息

图2513（护士站"已停止"标签页）：两条已停医嘱记录中，"频次/用法"列和"停嘱医生"列均为空白。图中用红色标注"频次/用法和停嘱医生未回写"。
图2512（医生站视图）：同一医嘱显示"频次/用法"为"每日一次静脉滴注"，"停嘱医生"为"内科医生1"。

综合总结

护士在医嘱校对的"已停止"列表中查看已停医嘱时，"频次/用法"和"停嘱医生"两个字段显示为空。这两个字段在医生端正常显示。问题出在护士站查询已停止医嘱时，数据源（SQL查询或Java处理）未能正确返回这两个字段的值。

二、根因分析

根因1：停嘱医生字段 —— `stopper_name` 映射到 `update_by` 被覆盖

核心问题链路：

医生停嘱 (AdviceManageAppServiceImpl.stopRegAdvice): 设置 update_by = SecurityUtils.getNickName()（医生昵称）
- 此时 update_by = "内科医生1" ✓
- 但未设置 stopper_id（虽然 V41 迁移已添加此列）
护士校对 (AdviceProcessAppServiceImpl.adviceVerify): 设置 update_by = SecurityUtils.getNickName()（护士昵称）
- 此时 update_by 被覆盖为护士名
- 如果护士昵称为空/NULL → update_by = NULL

SQL 查询 (AdviceProcessAppMapper.xml):

NULL::bigint AS stopper_id,  -- 硬编码 NULL！
T1.update_by AS stopper_name -- 使用 update_by，已被覆盖

Java 处理:

e.setStopperName(e.getStopperName()); // 这是空操作！

结论: stopper_name 取自 update_by，而 update_by 被护士校对操作覆盖。若护士昵称为空，该字段为 NULL。V41 迁移添加了 stopper_id 列但 Java 实体和查询均未使用。

涉及文件:

AdviceProcessAppMapper.xml (L209-210, L355-356): NULL::bigint AS stopper_id + T1.update_by AS stopper_name
AdviceProcessAppServiceImpl.java (L318): e.setStopperName(e.getStopperName()) — 空操作
AdviceManageAppServiceImpl.java (L1127): .set(MedicationRequest::getUpdateBy, stopUserName) — 未设 stopper_id
MedicationRequest.java: 缺少 stopperId 字段
ServiceRequest.java: 缺少 stopperId 字段

根因2：频次/用法字段 —— 需要进一步排查

SQL 查询正确选取了 T1.rate_code 和 T1.method_code，Java 代码也正确计算了 frequencyUsage。但两个停嘱医嘱都为空，可能是：

数据库中这两条医嘱的 rate_code/method_code 为 NULL（创建时未设置）
或 DictUtils.getDictLabel 返回空字符串

需验证: 检查 med_medication_request 表中对应记录的 rate_code 和 method_code 值。

三、修复方案

修复1：停嘱医生字段（核心修复）

Step 1: 给 MedicationRequest 和 ServiceRequest 实体添加 stopperId 字段

Step 2: 更新医生站停嘱逻辑，设置 stopper_id

// AdviceManageAppServiceImpl.stopRegAdvice
// 获取停嘱医生的 practitionerId
Long practitionerId = SecurityUtils.getLoginUser().getPractitionerId();
// 药品
.set(MedicationRequest::getStopperId, practitionerId)
.set(MedicationRequest::getUpdateBy, stopUserName)
// 诊疗
.set(ServiceRequest::getStopperId, practitionerId)
.set(ServiceRequest::getUpdateBy, stopUserName)

Step 3: 更新护士站 SQL 查询，用 stopper_id 关联 adm_practitioner 获取医生姓名

-- AdviceProcessAppMapper.xml 中 MedicationRequest UNION:
-- 修改前:
NULL::bigint AS stopper_id,
T1.update_by AS stopper_name
-- 修改后:
T1.stopper_id AS stopper_id,
COALESCE(practitioner_stop.name, T1.update_by) AS stopper_name
-- 并增加 LEFT JOIN:
LEFT JOIN adm_practitioner practitioner_stop ON T1.stopper_id = practitioner_stop.id AND practitioner_stop.delete_flag = '0'

对 ServiceRequest UNION 同理修改。

Step 4: 更新护士站校对逻辑，停嘱单校对时不应覆盖 update_by（或同时保留 stopper 信息）

修复2：频次/用法字段

先验证数据：检查 med_medication_request 表中 rate_code 和 method_code 是否为 NULL。如果为 NULL，需检查订单创建流程是否正确设置了这两个字段。

四、路由决策

FIXER: guanyu（后端开发）+ zhaoyun（前端开发）

REASON: 根因在后端（SQL 查询 stopper_name 映射错误 + 实体缺少 stopperId + 停嘱逻辑未设 stopper_id），需 guanyu 修复实体类、Mapper XML、Service 层。频次/用法需排查数据库数据，也属后端。前端可能需确认"频次/用法"为空时的展示逻辑，属 zhaoyun 范围。

路由决策

FIXER_ID: guanyu
修复 Agent: guanyu（后端）
原因: LLM 分析决策

⚠️ 修复人员请先验证以上分析是否正确，再执行修复。

5.9 KiB Raw Blame History Unescape Escape