docs(bug): 诸葛亮分析报告 Bug #718
This commit is contained in:
169
MD/bugs/BUG_718_ANALYSIS.md
Normal file
169
MD/bugs/BUG_718_ANALYSIS.md
Normal file
@@ -0,0 +1,169 @@
|
||||
# Bug #718 诸葛亮分析报告
|
||||
|
||||
> **文档类型**: Bug分析
|
||||
> **分析时间**: 2026-06-13 02:19:56
|
||||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||||
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **Bug #**: 718
|
||||
- **标题**: 【业务逻辑缺陷】医生端点击“停嘱”后医嘱直接变更为“已停止”，未流转至护士端进行停止核对
|
||||
- **模块**: 病区护士工作站
|
||||
- **提出人**: 陈显精
|
||||
|
||||
---
|
||||
|
||||
Now I have a thorough understanding of the entire flow. Let me compile my analysis.
|
||||
|
||||
---
|
||||
|
||||
## 一、Bug 理解
|
||||
|
||||
### 原文引用
|
||||
|
||||
**Bug 标题**：【业务逻辑缺陷】医生端点击"停嘱"后医嘱直接变更为"已停止"，未流转至护士端进行停止核对
|
||||
|
||||
**重现步骤**：
|
||||
1. 登录"住院医生工作站"，选择在科患者（如：刘潇凡）
|
||||
2. 找到一条已校对且正在执行的长期医嘱（如：注射用头孢哌酮舒巴坦钠）
|
||||
3. 选中该医嘱，点击界面上方的【停嘱】按钮
|
||||
4. 观察医生端该医嘱的状态变化
|
||||
5. 登录"住院护士站"，进入"医嘱核对"页面
|
||||
6. 依次查看【未校对】和【已停止】标签页
|
||||
|
||||
**期望结果**：
|
||||
1. 医生端点击"停嘱"后，医嘱状态应变更为【已停嘱】（中间状态），不能一步到位直接变成终态【停止】
|
||||
2. 该医嘱应流转并显示在护士端的【未校对】标签页内，供护士进行停嘱确认
|
||||
3. 只有当护士在"未校对"下选中该停嘱医嘱并点击【核对通过】后，医嘱状态才变更为【已停止】，并最终流转显示在【已停止】标签页中
|
||||
|
||||
**附图关键信息**：
|
||||
- 图1（医生端）：红色标注指出"停嘱成功的医嘱状态应该是'已停嘱'待核对，需要重新定义一个医嘱状态'已停嘱'记录已停嘱的医嘱"；列表中停嘱后医嘱状态显示为"停止"
|
||||
- 图2（护士端）：红色标注指出"已停嘱的医嘱应该显示在未校对标签页 待护士核对，核对后状态变成已停止"；未校对标签页中无停嘱待核对记录
|
||||
|
||||
### 综合总结
|
||||
|
||||
医生点击停嘱后，医嘱状态直接跳变为终态"停止"（或至少在显示上呈现为停止），护士端的【未校对】标签页未收到该停嘱待核对记录，护士无法执行核对确认。期望的流程是：医生停嘱→状态变为中间态"已停嘱"→流转至护士端未校对→护士核对通过→状态变为终态"停止"。
|
||||
|
||||
---
|
||||
|
||||
## 二、根因分析
|
||||
|
||||
通过代码审查，我追踪了完整的停嘱数据流链路：
|
||||
|
||||
### 后端代码（看似正确但存在显示链路断裂）
|
||||
|
||||
1. **医生停嘱接口** `AdviceManageAppServiceImpl.stopRegAdvice()`（第1100行）：将状态设为 `RequestStatus.PENDING_STOP(13, "已停嘱")` ✅
|
||||
2. **护士站查询** `AdviceProcessAppServiceImpl.getInpatientAdvicePage()`（第204-213行）：查询 ACTIVE(2) 时同时包含 PENDING_STOP(13) ✅
|
||||
3. **护士核对** `AdviceProcessAppServiceImpl.adviceVerify()`（第433-450行）：将 PENDING_STOP(13) 转为 STOPPED(6) ✅
|
||||
4. **枚举定义** `RequestStatus.java`：`PENDING_STOP(13, "pending_stop", "已停嘱")` ✅
|
||||
|
||||
### 根本问题：护士站前端状态显示映射缺失
|
||||
|
||||
`prescriptionList.vue` 中的 `REQUEST_STATUS_DISPLAY` 映射表**缺少 PENDING_STOP(13) 条目**：
|
||||
|
||||
```javascript
|
||||
// 第356-361行
|
||||
const REQUEST_STATUS_DISPLAY = {
|
||||
[RequestStatus.DRAFT]: '待签发', // 1 → '待签发'
|
||||
[RequestStatus.ACTIVE]: '已签发', // 2 → '已签发'
|
||||
[RequestStatus.COMPLETED]: '已校对', // 3 → '已校对'
|
||||
[RequestStatus.STOPPED]: '已停止', // 6 → '已停止'
|
||||
// ⚠️ 缺少 PENDING_STOP(13) 条目！
|
||||
};
|
||||
```
|
||||
|
||||
`getStatusDisplayText()` 的回退逻辑虽然最终能通过 `LEGACY_STATUS_TEXT` 或 `requestStatus_enumText` 返回正确的文本"已停嘱"，但**存在一个更严重的问题**：
|
||||
|
||||
对于药品医嘱，`getStatusDisplayText()` **优先使用 `dispenseStatus`**（发药状态）。如果停嘱前已存在发药记录（如 dispenseStatus=4 → "已发药"），则 PENDING_STOP 的停嘱状态会被发药状态**遮蔽**，护士看不到"已停嘱"状态。
|
||||
|
||||
### 涉及的关键文件
|
||||
|
||||
| 文件 | 问题 |
|
||||
|------|------|
|
||||
| `healthlink-his-ui/src/views/inpatientNurse/medicalOrderProofread/components/prescriptionList.vue` | `REQUEST_STATUS_DISPLAY` 缺少 PENDING_STOP 映射；`getStatusDisplayText` 对 PENDING_STOP 的优先级逻辑不当 |
|
||||
| `healthlink-his-ui/src/views/inpatientDoctor/home/components/order/index.vue` | 医生端模板已有 statusEnum==13→"已停嘱" 映射，**看似正确** |
|
||||
| `healthlink-his-server/.../AdviceManageAppServiceImpl.java` | 后端停嘱逻辑已正确设置 PENDING_STOP，**无需修改** |
|
||||
| `healthlink-his-server/.../AdviceProcessAppServiceImpl.java` | 护士站查询已包含 PENDING_STOP，核对逻辑已正确处理，**无需修改** |
|
||||
| `healthlink-his-server/healthlink-his-common/.../RequestStatus.java` | 枚举定义正确，PENDING_STOP(13) 已存在，**无需修改** |
|
||||
|
||||
---
|
||||
|
||||
## 三、修复方案
|
||||
|
||||
### 修复1：护士站前端状态显示映射（核心修复）
|
||||
|
||||
**文件**：`healthlink-his-ui/src/views/inpatientNurse/medicalOrderProofread/components/prescriptionList.vue`
|
||||
|
||||
**修改1a**：在 `REQUEST_STATUS_DISPLAY` 中添加 PENDING_STOP 映射
|
||||
|
||||
```javascript
|
||||
// 第356行后添加
|
||||
const REQUEST_STATUS_DISPLAY = {
|
||||
[RequestStatus.DRAFT]: '待签发',
|
||||
[RequestStatus.ACTIVE]: '已签发',
|
||||
[RequestStatus.COMPLETED]: '已校对',
|
||||
[RequestStatus.STOPPED]: '已停止',
|
||||
[RequestStatus.PENDING_STOP]: '已停嘱', // ← 新增
|
||||
};
|
||||
```
|
||||
|
||||
**修改1b**：修改 `getStatusDisplayText` 逻辑，确保 PENDING_STOP 优先级高于 dispenseStatus
|
||||
|
||||
PENDING_STOP 是停嘱的中间状态，应优先显示，不受旧的发药状态遮蔽：
|
||||
|
||||
```javascript
|
||||
const getStatusDisplayText = (row) => {
|
||||
// 0. 已停嘱(13)优先显示 —— 停嘱中间态必须醒目，不被旧发药状态遮蔽
|
||||
const requestCode = Number(row?.requestStatus);
|
||||
if (requestCode === RequestStatus.PENDING_STOP) {
|
||||
return '已停嘱';
|
||||
}
|
||||
// 1. 优先使用发药状态
|
||||
const dispenseCode = Number(row?.dispenseStatus);
|
||||
if (DISPENSE_STATUS_DISPLAY[dispenseCode]) {
|
||||
return DISPENSE_STATUS_DISPLAY[dispenseCode];
|
||||
}
|
||||
// 2. 使用行级别请求状态
|
||||
if (REQUEST_STATUS_DISPLAY[requestCode]) {
|
||||
return REQUEST_STATUS_DISPLAY[requestCode];
|
||||
}
|
||||
// 3. 兼容旧后端枚举文本
|
||||
return LEGACY_STATUS_TEXT[row?.requestStatus_enumText] || row?.requestStatus_enumText || '';
|
||||
};
|
||||
```
|
||||
|
||||
### 修复2：医生端 SQL 查询补充 stop_time/stop_user_name（优化）
|
||||
|
||||
**文件**：`healthlink-his-server/.../mapper/regdoctorstation/AdviceManageAppMapper.xml`
|
||||
|
||||
当前 SQL 中 stop_time 和 stop_user_name 仅在 `status_enum = 6`（STOPPED）时返回，PENDING_STOP(13) 时不返回，导致医生端停嘱时间/停嘱医生列为空。需将条件改为 `status_enum IN (6, 13)`：
|
||||
|
||||
```xml
|
||||
<!-- 修改前 -->
|
||||
CASE WHEN T1.status_enum = 6 THEN T1.effective_dose_end ELSE NULL END AS stop_time,
|
||||
CASE WHEN T1.status_enum = 6 THEN T1.update_by ELSE NULL END AS stop_user_name
|
||||
|
||||
<!-- 修改后 -->
|
||||
CASE WHEN T1.status_enum IN (6, 13) THEN T1.effective_dose_end ELSE NULL END AS stop_time,
|
||||
CASE WHEN T1.status_enum IN (6, 13) THEN T1.update_by ELSE NULL END AS stop_user_name
|
||||
```
|
||||
|
||||
（对 ServiceRequest 和 DeviceRequest 的 UNION 部分同样修改）
|
||||
|
||||
---
|
||||
|
||||
## 四、路由决策
|
||||
|
||||
**FIXER**: `guanyu`（后端开发）+ `zhaoyun`（前端开发）
|
||||
|
||||
**REASON**: 本 Bug 涉及前后端两个层面。核心修复在前端护士站的状态显示映射（`prescriptionList.vue` 的 `REQUEST_STATUS_DISPLAY` 和 `getStatusDisplayText`），属于 `zhaoyun` 的职责范围。次要修复在后端 Mapper XML 的 SQL 条件补充（`AdviceManageAppMapper.xml`），属于 `guanyu` 的职责范围。后端核心停嘱逻辑（`stopRegAdvice` 和 `adviceVerify`）**已正确实现**，无需修改。
|
||||
|
||||
---
|
||||
|
||||
## 路由决策
|
||||
- **FIXER_ID**: guanyu
|
||||
- **修复 Agent**: guanyu（后端）
|
||||
- **原因**: LLM 分析决策
|
||||
|
||||
> ⚠️ 修复人员请先验证以上分析是否正确，再执行修复。
|
||||
Reference in New Issue
Block a user