Files
his/MD/bugs/BUG_719_ANALYSIS.md

148 lines
5.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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. 医生端已对某医嘱进行"停嘱"操作(如:注射用头孢哌酮舒巴坦钠)
2. 登录护士端进入"住院护士站" > "医嘱校对"
3. 在查询页签中点击"已停止"标签
4. 查看对应医嘱记录的"频次/用法"及"停嘱医生"两列
**结果**: 列表中"频次/用法"及"停嘱医生"列内容为空,未显示任何数据。
**期望**: 列表对应的"频次/用法"及"停嘱医生"列应正确显示数据,且与临床医生端显示内容一致(如:每日一次 静脉滴注、内科医生1
### 附图关键信息
- **图2513**(护士站"已停止"标签页):两条已停医嘱记录中,"频次/用法"列和"停嘱医生"列均为空白。图中用红色标注"频次/用法 和停嘱医生未回写"。
- **图2512**(医生站视图):同一医嘱显示"频次/用法"为"每日一次 静脉滴注""停嘱医生"为"内科医生1"。
### 综合总结
护士在医嘱校对的"已停止"列表中查看已停医嘱时,"频次/用法"和"停嘱医生"两个字段显示为空。这两个字段在医生端正常显示。问题出在护士站查询已停止医嘱时数据源SQL查询或Java处理未能正确返回这两个字段的值。
---
## 二、根因分析
### 根因1停嘱医生字段 —— `stopper_name` 映射到 `update_by` 被覆盖
**核心问题链路**
1. **医生停嘱** (`AdviceManageAppServiceImpl.stopRegAdvice`): 设置 `update_by = SecurityUtils.getNickName()`(医生昵称)
- 此时 `update_by = "内科医生1"`
- **但未设置 `stopper_id`**(虽然 V41 迁移已添加此列)
2. **护士校对** (`AdviceProcessAppServiceImpl.adviceVerify`): 设置 `update_by = SecurityUtils.getNickName()`(护士昵称)
- 此时 `update_by` 被覆盖为护士名
- 如果护士昵称为空/NULL → `update_by = NULL`
3. **SQL 查询** (`AdviceProcessAppMapper.xml`):
```sql
NULL::bigint AS stopper_id, -- 硬编码 NULL
T1.update_by AS stopper_name -- 使用 update_by已被覆盖
```
4. **Java 处理**:
```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`
```java
// 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` 获取医生姓名
```sql
-- 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 分析决策
> ⚠️ 修复人员请先验证以上分析是否正确,再执行修复。