wangyizhe/his

Fork 0

Files

华佗 4b2b1b4d14 docs(bug): 诸葛亮分析报告 Bug #728

2026-06-13 01:00:18 +08:00

7.1 KiB

Raw Blame History

Bug #728 诸葛亮分析报告

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

基本信息

Bug #: 728
标题: 【住院护士站-医嘱校对】转科医嘱核对通过后原床位被提前释放，导致转科前待处理事项无法执行
模块: 病区护士工作站
提出人: 陈显精

分析完成。以下是完整的 Bug 分析报告：

一、Bug 理解

禅道标题： 【住院护士站-医嘱校对】转科医嘱核对通过后原床位被提前释放，导致转科前待处理事项无法执行

重现步骤：

医生端为患者（002床不知道）开立转科预嘱并签发
登录住院护士站，在【医嘱校对】页面"未校对-临时医嘱"中找到该患者的"转科"医嘱
选中该医嘱，点击【核对通过】，提示"校对成功"
切换至其他菜单（医嘱执行、汇总领药等）

结果：

护士核对通过转科医嘱后，系统立即释放并清退了该患者的原床位（床号显示为 -:-，非在科状态）
患者从左侧在科患者列表中消失，护士无法在【医嘱执行】【汇总领药】等界面选中该患者
转科前尚未完成的带药、治疗等医嘱无法执行

期望：

核对通过转科医嘱后，应保留原床位占用和在科状态
允许护士继续处理转科前所有待执行医嘱
只有护士在【入出转管理】页面确认执行【转科】或【清床】操作后，才正式释放床位

附图关键信息：

图2527：校对页面，红框标注"核对通过"按钮和转科医嘱
图2526/2529：入出转管理页面，床号显示 -:-，患者已标记"待转科"，仍显示"待取药/待退药"和"待处理执行单"
图2528：校对页面，患者"不知道"已从左侧列表消失，红框注释"转科医嘱护士校对通过后待转科的患者床位应该保留"

综合总结： 护士在医嘱校对页面核对通过转科医嘱后，系统过早触发了床位释放和在科状态变更，导致患者从在科列表中消失，护士无法继续执行转科前遗留的待办医嘱。正确行为应是核对通过仅更新医嘱状态，保留床位和在科状态，待护士在入出转管理页面手动执行转科时才释放资源。

二、根因分析

核心问题代码： AdviceProcessAppServiceImpl.adviceVerify() 方法（第 465-472 行）

// 处理转科/出院等特殊医嘱
for (ServiceRequest serviceRequest : normalRequests) {
    if (ActivityDefCategory.TRANSFER.getValue().equals(serviceRequest.getCategoryEnum())) {
        encounterService.updateEncounterStatus(serviceRequest.getEncounterId(),
                EncounterZyStatus.PENDING_TRANSFER.getValue());  // ← BUG：校对时立即改变患者状态
    } else if (ActivityDefCategory.DISCHARGE.getValue().equals(serviceRequest.getCategoryEnum())) {
        encounterService.updateEncounterStatus(serviceRequest.getEncounterId(),
                EncounterZyStatus.AWAITING_DISCHARGE.getValue());
    }
}

根因链条：

adviceVerify（校对通过） 在处理转科医嘱时，直接调用 encounterService.updateEncounterStatus() 将患者 encounter 状态改为 PENDING_TRANSFER（6）
同时，转科医嘱的 ServiceRequest 状态被设为 COMPLETED（3）
这触发了系统级联反应——患者状态变更导致床位信息被释放（encounter_location 中 BED 类型的记录状态被联动修改），患者从在科患者列表中消失
实际的转科操作 由 ATDManageAppServiceImpl.transferDepartment() 执行，这才是应该执行床位释放、状态变更的地方

正确的时序设计：

校对通过 → 仅更新医嘱状态（转科医嘱→COMPLETED），不改变患者 encounter 状态
入出转管理→转科 → 执行床位释放、状态变更、新病区分配

涉及文件：

AdviceProcessAppServiceImpl.java — adviceVerify() 方法，第 465-472 行
ATDManageAppServiceImpl.java — transferDepartment() 方法（正确的转科执行逻辑）
EncounterLocationServiceImpl.java — updateEncounterLocationStatus() 方法（床位状态更新）

三、修复方案

修复步骤

步骤 1：修改 AdviceProcessAppServiceImpl.adviceVerify() 方法

文件： healthlink-his-server/healthlink-his-application/src/main/java/com/healthlink/his/web/inhospitalnursestation/appservice/impl/AdviceProcessAppServiceImpl.java

修改内容： 删除校对通过时对转科医嘱的 encounter 状态更新

将第 463-472 行：

// 处理转科/出院等特殊医嘱
for (ServiceRequest serviceRequest : normalRequests) {
    if (ActivityDefCategory.TRANSFER.getValue().equals(serviceRequest.getCategoryEnum())) {
        encounterService.updateEncounterStatus(serviceRequest.getEncounterId(),
                EncounterZyStatus.PENDING_TRANSFER.getValue());
    } else if (ActivityDefCategory.DISCHARGE.getValue().equals(serviceRequest.getCategoryEnum())) {
        encounterService.updateEncounterStatus(serviceRequest.getEncounterId(),
                EncounterZyStatus.AWAITING_DISCHARGE.getValue());
    }
}

改为：

// 转科/出院医嘱核对通过时，不立即改变患者 encounter 状态
// 状态变更推迟到入出转管理页面执行转科/出院操作时触发（ATDManageAppServiceImpl.transferDepartment）
// 校对通过仅更新医嘱状态（已在上方 COMPLETED 处理），保留原床位和在科状态

说明：

转科医嘱的 ServiceRequest 状态已在上方通过 updateCompleteRequestStatus 设为 COMPLETED（3），这是正确的
删除的是 encounter 状态的联动更新，不影响医嘱本身的校对完成
出院医嘱同理删除（AWAITING_DISCHARGE 状态应推迟到出院操作时设置）

步骤 2：编译验证

mvn clean compile -DskipTests -pl healthlink-his-server/healthlink-his-application
mvn test -pl healthlink-his-server/healthlink-his-application -Dtest="NurseStationTest" -Dsurefire.failIfNoSpecifiedTests=false

步骤 3：前端确认（无需修改）

前端【医嘱校对】页面无需修改，因为：

医嘱校对接口返回"校对成功"后，前端刷新医嘱列表，转科医嘱状态正确更新为"已完成"
患者在科列表的刷新由后端 selectInpatientPage 查询驱动，患者 encounter 状态不变 → 列表中继续显示

四、路由决策

FIXER: guanyu（关羽 — 后端开发）

REASON: 修复涉及 Java 后端 Service 层逻辑修改（AdviceProcessAppServiceImpl.adviceVerify 方法），属于纯后端业务逻辑调整，无前端改动，由后端开发 Agent 执行最合适。

路由决策

FIXER_ID: guanyu
修复 Agent: guanyu（后端）
原因: ** 修复涉及 Java 后端 Service 层逻辑修改（AdviceProcessAppServiceImpl.adviceVerify 方法），属于纯后端业务逻辑调整，无前端改动，由后端开发 Agent 执行最合适。

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

7.1 KiB Raw Blame History Unescape Escape