Compare commits
76 Commits
0eee5284b4
...
guanyu
| Author | SHA1 | Date | |
|---|---|---|---|
| 7adb3b3ea4 | |||
| 1e6704928a | |||
| 75e49f0237 | |||
| 798c5e19e2 | |||
| fa18e94cd9 | |||
| 69bb887d19 | |||
| 2b6b00b6c2 | |||
| 1ddf8a2ccd | |||
| b89f41048b | |||
| 0a37b05aab | |||
| e13e328627 | |||
| 20817d6dc4 | |||
| 9cac8c3e41 | |||
| d7ca64e023 | |||
|
|
0e974129eb | ||
| 4972ca64da | |||
| 1b0028e62f | |||
| c8876dd890 | |||
| 707cfc63df | |||
| 2cddc00d22 | |||
| ea5da8d2bc | |||
| 09353c11ca | |||
| c49ec61e18 | |||
| 8081f3ac7f | |||
| 5bdedd84e0 | |||
| 69ac346ff3 | |||
| 549d2529bc | |||
| 9d3f44bafc | |||
| 0228cba94e | |||
| 3a97f5ce02 | |||
| 0fc7a8623e | |||
| ada292405a | |||
| a4370b00db | |||
| f741a1f70d | |||
| e67d3b78d7 | |||
|
|
40ca304342 | ||
|
|
3a40740538 | ||
| 7c0d103409 | |||
| ad85e4d284 | |||
| 8b6af8dd61 | |||
| e330372355 | |||
| f72bee6c95 | |||
| 6b347e9136 | |||
|
|
58e391bd2c | ||
| 9f615df3f9 | |||
| d47353a711 | |||
| dbe9fdadc1 | |||
| 7ae7cfa35c | |||
| 01da7b942a | |||
| b8666e535b | |||
| 1f7d637265 | |||
| 910f59ce9d | |||
| 0328f9642f | |||
| e6a61ea5aa | |||
| 4809b3571d | |||
| bfe544cfb3 | |||
| 37c2377b66 | |||
| 89ca306348 | |||
| 31f7950779 | |||
| ce1161caea | |||
| 046a3e4703 | |||
| e245f4ec02 | |||
| 37963dde1d | |||
| 4b2690d1ad | |||
| 8bfe4f2c23 | |||
| 08ccf9aba8 | |||
| 2d43b1cddc | |||
| 327b750c6e | |||
| 3c1087a2d1 | |||
| 4e2ee57274 | |||
| eee65a4517 | |||
| d30673ad51 | |||
| f369ea419e | |||
| 5db20ddcc2 | |||
| 1488b707e8 | |||
| 07a8e55895 |
@@ -1,36 +0,0 @@
|
||||
# Bug #401 分析报告
|
||||
|
||||
## 问题描述
|
||||
门诊完诊审计日志错误:div_log 表中 pool_id 与 slot_id 存值与设计规范不符。
|
||||
|
||||
## 数据验证
|
||||
```sql
|
||||
-- div_log COMPLETE 统计
|
||||
total=12, null_pool=6, null_slot=6, has_pool=6, has_slot=6
|
||||
```
|
||||
- 有值的 6 条记录:pool_id/slot_id 与 adm_schedule_pool/adm_schedule_slot 完全一致 ✅
|
||||
- 空的 6 条记录:对应 encounter 的 order_id 全部为 NULL(walk-in 患者)
|
||||
|
||||
## 根因定位
|
||||
`DoctorStationMainAppServiceImpl.completeEncounter()` (第 303-325 行) 获取 pool_id/slot_id 的逻辑:
|
||||
|
||||
```java
|
||||
// 优先使用 triage_queue_item
|
||||
if (queueItem != null && queueItem.getPoolId() != null && queueItem.getSlotId() != null) {
|
||||
divPoolId = queueItem.getPoolId();
|
||||
divSlotId = queueItem.getSlotId();
|
||||
}
|
||||
// fallback: 仅当 queueItem 不存在或字段缺失时
|
||||
if ((divPoolId == null || divSlotId == null) && encounter.getOrderId() != null) {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
**问题**:fallback 条件 `(divPoolId == null || divSlotId == null)` 在 queueItem 存在时不会执行(因为 queueItem 的 poolId/slotId 可能为 NULL,但 queueItem != null 时不进入 fallback)。实际上,对于有 encounter.orderId 的患者(挂号患者),应该始终通过 order → schedule_slot 获取权威的 pool_id/slot_id。
|
||||
|
||||
## 修复方案
|
||||
调整 fallback 逻辑:只要有 encounter.orderId,就通过 order → schedule_slot 获取 pool_id/slot_id,不再依赖 queueItem 的字段值。queueItem 仅用于确定是否需要写审计日志的时机判断。
|
||||
|
||||
## 影响范围
|
||||
- 修改文件:`DoctorStationMainAppServiceImpl.java`(约 10 行调整)
|
||||
- 不涉及数据库 DDL 变更
|
||||
@@ -1,40 +0,0 @@
|
||||
# Bug #512 分析报告
|
||||
|
||||
## Bug 描述
|
||||
[住院护士站-汇总发药申请] "全选"开关功能失效,点击后下方医嘱明细未能联动勾选
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 问题定位
|
||||
`index.vue` 的 `handelSwicthChange` 函数(第176-186行)和 `handleExecute` 函数(第200-202行)。
|
||||
|
||||
### 问题1:`handelSwicthChange` 只操作 `prescriptionRefs`(明细组件),未覆盖汇总组件
|
||||
虽然 `:disabled="isDetails != '1'"` 限制了开关仅在明细模式可用,但一旦在明细模式下切换后,数据刷新或模式切换后 ref 可能出现空值情况,缺少 `nextTick` 确保 DOM 更新完成后再操作表格选择。
|
||||
|
||||
### 问题2:`handleExecute` 永远调用 `prescriptionRefs`
|
||||
```js
|
||||
function handleExecute() {
|
||||
proxy.$refs['prescriptionRefs'].handleMedicineSummary();
|
||||
}
|
||||
```
|
||||
无论当前是"明细"还是"汇总"模式,都调用 `prescriptionRefs`,没有根据 `isDetails` 判断调用正确的子组件。
|
||||
|
||||
### 问题3:`summaryMedicineList.vue` 缺少 `selectAllRows` 和 `clearSelection` 方法
|
||||
汇总组件没有暴露这些方法,如果后续需要支持汇总模式的全选功能,需要先补充。
|
||||
|
||||
## 修复方案
|
||||
1. 在 `handelSwicthChange` 中添加 `nextTick` 确保 DOM 更新后再操作表格
|
||||
2. 修复 `handleExecute` 根据 `isDetails` 判断调用正确的子组件
|
||||
3. 为 `summaryMedicineList.vue` 添加 `selectAllRows` 和 `clearSelection` 方法
|
||||
|
||||
## 修复结果:✅ 成功,33行改动
|
||||
|
||||
### 修改内容
|
||||
1. `index.vue` - `handelSwicthChange` 改为 async 函数,添加 `nextTick` 确保 DOM 更新后再调用表格选择方法
|
||||
2. `index.vue` - `handelSwicthChange` 增加 `isDetails` 判断分支,覆盖明细和汇总两种模式
|
||||
3. `index.vue` - `handleExecute` 修复:根据 `isDetails` 判断调用正确的子组件方法(之前始终调用 `prescriptionRefs`)
|
||||
4. `index.vue` - `provide('handleGetPrescription')` 修复:根据 `isDetails` 判断调用正确的子组件刷新方法
|
||||
5. `index.vue` - 导入 `nextTick` from vue
|
||||
|
||||
### 构建验证
|
||||
`vite build --mode dev` 通过,无编译错误。
|
||||
@@ -1,78 +0,0 @@
|
||||
# Bug #526 分析报告
|
||||
|
||||
## Bug 描述
|
||||
[手术管理-门诊手术安排-计费] 勾选待签发状态的项目后上方签发按钮仍置灰不可用
|
||||
|
||||
## 根因定位
|
||||
|
||||
**文件**: `openhis-ui-vue3/src/views/clinicmanagement/bargain/component/prescriptionlist.vue`
|
||||
|
||||
### 签发按钮控制逻辑
|
||||
```vue
|
||||
<el-button type="primary" @click="handleSave()" :disabled="handleSaveDisabled"> 签发 </el-button>
|
||||
```
|
||||
`handleSaveDisabled` 是一个 `ref(false)`(第408行)。
|
||||
|
||||
### 两个更新机制都存在缺陷
|
||||
|
||||
**机制1:watcher(第458-475行)**
|
||||
```js
|
||||
watch(() => prescriptionList.value, (newValue) => {
|
||||
let saveList = prescriptionList.value.filter(item =>
|
||||
item.check && item.statusEnum == 1 && (Number(item.bizRequestFlag)==1 || !item.bizRequestFlag)
|
||||
)
|
||||
handleSaveDisabled.value = saveList.length == 0
|
||||
}, { immediate: true, deep: false }); // ← deep: false!
|
||||
```
|
||||
`deep: false` 意味着 watcher 只能检测到数组引用变化(push/splice),**无法检测到数组元素的 `check` 属性变化**。用户勾选/取消勾选checkbox时,watcher 不会触发。
|
||||
|
||||
**机制2:changeCheck 函数(第986-1019行)**
|
||||
```js
|
||||
groupList.value.map(k => {
|
||||
if(k.check) {
|
||||
if(k.statusEnum == 1) {
|
||||
// 待签发:设置 handleSaveDisabled = false
|
||||
}
|
||||
if(k.statusEnum == 2) {
|
||||
// 已签发:设置 handleSaveDisabled = true
|
||||
}
|
||||
}
|
||||
})
|
||||
```
|
||||
问题:
|
||||
1. **用 `.map()` 遍历逐个设置按钮状态**,后面的项会覆盖前面项的设置
|
||||
2. 如果列表中先有"待签发"项(设置 `handleSaveDisabled = false`),后面遍历时碰到一个不满足 `bizRequestFlag` 条件的项,会被覆盖为 `true`
|
||||
3. 当取消勾选最后一个项目时,`groupList` 为空,`.map()` 不执行任何操作,按钮状态保持原样
|
||||
|
||||
### 数据流
|
||||
1. `getListInfo()` 从后端加载数据 → `prescriptionList.value` 被赋值
|
||||
2. 用户勾选checkbox → `scope.row.check` 变为 true(v-model 自动)
|
||||
3. `@change` 触发 `changeCheck()` → 更新 `groupIndexList` 和 `groupList`
|
||||
4. **但 `changeCheck` 中逐个遍历设置按钮状态的逻辑不可靠** → 签发按钮可能仍为 disabled
|
||||
|
||||
## 修复方案
|
||||
|
||||
将 `handleSaveDisabled` 和 `handleSingOutDisabled` 从 `ref` + 手动管理改为 **`computed` 属性**,直接从 `prescriptionList.value` 实时计算按钮状态:
|
||||
|
||||
```js
|
||||
const handleSaveDisabled = computed(() => {
|
||||
return !prescriptionList.value.some(item =>
|
||||
item.check && item.statusEnum == 1 && (Number(item.bizRequestFlag) === 1 || !item.bizRequestFlag)
|
||||
)
|
||||
})
|
||||
|
||||
const handleSingOutDisabled = computed(() => {
|
||||
return !prescriptionList.value.some(item =>
|
||||
item.check && item.statusEnum == 2 && item.chargeStatus != 5 &&
|
||||
(Number(item.bizRequestFlag) === 1 || !item.bizRequestFlag)
|
||||
)
|
||||
})
|
||||
```
|
||||
|
||||
**优势**:
|
||||
- 响应式自动计算,任何 `check`、`statusEnum` 变化都会触发重新计算
|
||||
- 不需要 watcher(删除 deep: false 的那个)
|
||||
- 不需要在 changeCheck 中手动管理按钮状态
|
||||
- 逻辑与 `handleSave` 和 `handleSingOut` 中的筛选条件一致
|
||||
|
||||
同时从 `changeCheck` 函数中移除按钮状态管理代码(第986-1019行的 `.map()` 部分)。
|
||||
@@ -1,55 +0,0 @@
|
||||
# Bug #443 分析报告
|
||||
|
||||
## Bug 描述
|
||||
手术计费:点击"签发"耗材时异常报错
|
||||
|
||||
## 复现步骤
|
||||
1. 以"手术室护士"角色登录
|
||||
2. 进入【门诊手术安排】→ 点击【计费】
|
||||
3. 勾选一条状态为"待签发"的耗材项目
|
||||
4. 点击【签发】按钮
|
||||
|
||||
## 预期 vs 实际
|
||||
- 预期:提示"签发成功",状态变为"已签发"
|
||||
- 实际:弹出"后端程序异常"报错
|
||||
|
||||
## 代码分析
|
||||
|
||||
### 前端流程
|
||||
1. `surgicalschedule/index.vue` → `handleChargeCharge()` 打开计费弹窗
|
||||
2. 弹窗中使用 `prescriptionlist.vue` 组件,传入 `generateSourceEnum=6`, `sourceBillNo=operCode`
|
||||
3. 用户勾选"待签发"项目 → 点击"签发" → 触发 `handleSave()`
|
||||
4. `handleSave()` 过滤 `item.check && item.statusEnum == 1 && (Number(item.bizRequestFlag)==1||!item.bizRequestFlag)`
|
||||
5. 构造请求体:解析 `contentJson` + 补充顶层字段(encounterId, patientId, adviceType 等)
|
||||
6. 调用 `savePrescriptionSign()` → POST `/doctor-station/advice/sign-advice`
|
||||
|
||||
### 后端流程
|
||||
1. `DoctorStationAdviceController.signAdvice()` → `saveAdvice(param, SIGN_ADVICE)`
|
||||
2. `saveAdvice()` 校验 encounterId/patientId 非空
|
||||
3. 按 adviceType 分类:药品(1)、耗材(2)、诊疗(3)
|
||||
4. 耗材走 `handDevice(deviceList, curDate, adviceOpType)` 处理
|
||||
5. 签发后更新 DeviceRequest 状态为 ACTIVE(2)
|
||||
6. 更新 ChargeItem 状态:DRAFT(0)→PLANNED(1) 或 BILLABLE(2)→PLANNED(1)
|
||||
|
||||
### 可能根因
|
||||
|
||||
**根因1:dbOpType 语义错误**
|
||||
- 前端 `handleSave()` 对已存在的耗材发送 `dbOpType: '1'` (INSERT)
|
||||
- 后端 `handDevice` 中 `insertOrUpdateList` 通过 `requestId != null` 过滤包含这些项
|
||||
- 但对于 INSERT 操作,如果 DeviceRequest 已存在,`saveOrUpdate` 走 UPDATE 路径
|
||||
- 问题在于:INSERT 语义下某些字段(如 `bus_no`)仅在 `is_save=true` 时设置
|
||||
|
||||
**根因2:contentJson 数据一致性**
|
||||
- 前端将 `contentJson` 解析后 spread 回对象,再序列化为新的 JSON 发送
|
||||
- 后端 `handDevice` 直接将该 JSON 存入 `content_json` 字段
|
||||
- 如果原始 `content_json` 中的字段名与 `AdviceSaveDto` 不匹配(如 snake_case vs camelCase),可能导致数据丢失
|
||||
|
||||
**根因3:缺少空列表校验**
|
||||
- `handleSave()` 未校验 `saveList.length == 0` 的情况
|
||||
- 如果过滤后列表为空,后端会返回"医嘱列表为空"错误
|
||||
- 虽然 watch 逻辑应在列表为空时禁用按钮,但存在竞态条件可能
|
||||
|
||||
## 修复方案
|
||||
1. 前端 `handleSave()` 添加 `saveList.length == 0` 校验(防御性编程)
|
||||
2. 前端 `handleSave()` 对已存在记录(requestId 不为空)使用 `dbOpType: '2'` (UPDATE) 而非 '1' (INSERT)
|
||||
3. 前端 `handleSave()` 确保关键字段(quantity, unitCode)从顶层补充
|
||||
44
bug444_analysis.md
Normal file
44
bug444_analysis.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Bug #444 分析报告
|
||||
|
||||
## Bug 描述
|
||||
【手术管理-门诊手术安排】生成临时医嘱界面,"已引用计费药品"列表未正常显示药品详细名称信息,且错误地带出了非药品类的计费信息(如手术诊疗项目"小腿烧伤扩创交腿皮瓣修复术"、检查项目"心脏彩色多普勒超声")。
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 数据流
|
||||
1. 用户点击"医嘱"按钮 → `handleMedicalAdvice()` → 调用 `getPrescriptionList()` 获取计费数据
|
||||
2. 用户对数据进行过滤后展示在"已引用计费药品"列表
|
||||
3. 用户点击"引用计费"按钮 → `handleQuoteBilling()` → 再次调用 `getPrescriptionList()` 获取最新计费数据
|
||||
|
||||
### 根因定位
|
||||
**`handleQuoteBilling()` 方法(index.vue:1866-1877)缺少非药品关键词过滤逻辑。**
|
||||
|
||||
`handleMedicalAdvice()` 中有两层过滤:
|
||||
1. `adviceType !== 1` 过滤(只保留药品类型)
|
||||
2. **关键词排除过滤**(排除名称中包含"术"、"超声"、"检查"等非药品关键词的项目)
|
||||
|
||||
但 `handleQuoteBilling()` 中只有第一层过滤(`adviceType !== 1`),**缺少关键词排除过滤**。
|
||||
|
||||
当后端返回的计费数据中某些非药品项目被错误标注为 `adviceType=1` 时:
|
||||
- `handleMedicalAdvice()` 能通过关键词过滤排除这些项目
|
||||
- `handleQuoteBilling()` 无法排除,导致非药品项目出现在"已引用计费药品"列表中
|
||||
|
||||
### 代码对比
|
||||
|
||||
| 过滤条件 | handleMedicalAdvice (L1576-1597) | handleQuoteBilling (L1866-1877) |
|
||||
|---------|:---:|:---:|
|
||||
| encounterId 匹配 | ✓ | ✓ |
|
||||
| adviceType === 1 | ✓ | ✓ |
|
||||
| 名称非空 | ✓ | ✓ |
|
||||
| **关键词排除** | ✓ **有** | ✗ **缺失** |
|
||||
| requestId 过滤 | ✓ | ✓ |
|
||||
|
||||
## 修复方案
|
||||
|
||||
在 `handleQuoteBilling()` 方法的过滤逻辑中,添加与 `handleMedicalAdvice()` 一致的关键词排除逻辑:
|
||||
|
||||
```javascript
|
||||
// 🔧 修复 Bug #444: 排除名称中包含手术/检查/诊疗关键词的非药品项目
|
||||
const excludedKeywords = ['术', '超声', '多普勒', '检查', '检验', '彩超', 'X线', 'CT', 'MRI', '扫描', '造影'];
|
||||
if (excludedKeywords.some(kw => medicineName.includes(kw))) return false;
|
||||
```
|
||||
@@ -1,85 +0,0 @@
|
||||
# Bug #468 分析报告
|
||||
|
||||
## Bug 描述
|
||||
[住院医生工作站-检验申请] 列表页缺失【单据状态】列,无法闭环管理检验医嘱执行进度
|
||||
|
||||
## 阶段1:深度分析
|
||||
|
||||
### 数据流追踪
|
||||
|
||||
1. **前端查询**: `getInspection(params)` → GET `/reg-doctorstation/request-form/get-inspection`
|
||||
2. **后端控制器**: `RequestFormManageController.getInspectionRequestForm()` → 调用 `iRequestFormManageAppService.getRequestForm()`
|
||||
3. **后端服务**: `RequestFormManageAppServiceImpl.getRequestForm()` → 调用 `requestFormManageAppMapper.getRequestForm()`
|
||||
4. **SQL查询**: `RequestFormManageAppMapper.xml` 中的 `getRequestForm` 语句
|
||||
5. **状态计算**: SQL 使用 CASE WHEN 根据 `wor_service_request.status_enum` 计算 `computed_status`
|
||||
6. **前端渲染**: `parseBillStatus(scope.row.billStatus ?? scope.row.status)` 显示状态文本
|
||||
|
||||
### 状态映射关系
|
||||
|
||||
**后端 ServiceRequest.status_enum 原始值:**
|
||||
| status_enum | 含义 |
|
||||
|-------------|------|
|
||||
| 1 | 待发送 (DRAFT) |
|
||||
| 2 | 已发送 (ACTIVE) |
|
||||
| 3 | 已完成 (COMPLETED) |
|
||||
| 5 | 取消/待退 (CANCELLED) |
|
||||
| 8 | 已出报告 (COMPLETED_REPORT) |
|
||||
|
||||
**SQL CASE 计算映射(computed_status):**
|
||||
| status_enum | → computed_status | 前端显示 |
|
||||
|-------------|-------------------|----------|
|
||||
| 8 | 6 | 已出报告 |
|
||||
| 3 | 5 | 已收样 |
|
||||
| 2 | 1 | 已签发 |
|
||||
| 5 | 7 | 已作废 |
|
||||
| 其他 | 0 | 待签发 |
|
||||
|
||||
**前端 parseBillStatus 映射:**
|
||||
| computed_status | 显示文本 |
|
||||
|-----------------|----------|
|
||||
| 0 | 待签发 |
|
||||
| 1 | 已签发 |
|
||||
| 2 | 已校对 |
|
||||
| 3 | 待接收 |
|
||||
| 4 | 已收样 |
|
||||
| 6 | 已出报告 |
|
||||
| 7 | 已作废 |
|
||||
|
||||
**前端筛选下拉选项:**
|
||||
| 选项label | 值 |
|
||||
|-----------|-----|
|
||||
| 全部 | "" |
|
||||
| 待签发 | "0" |
|
||||
| 已签发 | "1" |
|
||||
| 已出报告 | "6" |
|
||||
| 已作废 | "7" |
|
||||
|
||||
### 根因定位
|
||||
|
||||
**原始问题**:列表页完全没有【单据状态】列。
|
||||
|
||||
**已有修复**(已在 develop 分支合并):
|
||||
1. 新增 `el-table-column` 单据状态列(位于申请单号之后)
|
||||
2. 新增 `parseBillStatus()` 函数用于状态码→文本转换
|
||||
3. 新增筛选表单中的单据状态下拉选择
|
||||
4. 后端 SQL 新增 `computed_status` 动态计算逻辑
|
||||
5. 前端使用 `scope.row.billStatus ?? scope.row.status` 兼容字段名
|
||||
|
||||
## 修复结果
|
||||
|
||||
✅ 成功,Bug #468 已在 develop 分支修复并合并。
|
||||
|
||||
当前 guanyu 分支与 develop 分支代码完全一致(diff 为空),无需额外代码改动。
|
||||
|
||||
已有提交记录:
|
||||
- a95c9c9f - 列表页新增单据状态列
|
||||
- ae50a704 - 列表页新增【单据状态】列
|
||||
- 02b9dc87 / e694b758 / a99ecaee - 修复前后端状态码映射不一致
|
||||
|
||||
验证通过:
|
||||
- ✅ 表格列存在(line 92-96)
|
||||
- ✅ 列位置正确(申请单号之后)
|
||||
- ✅ parseBillStatus 覆盖所有后端状态
|
||||
- ✅ 筛选表单支持状态过滤
|
||||
- ✅ 操作列按状态动态显示按钮
|
||||
- ✅ 后端 SQL computed_status 计算正确
|
||||
@@ -1,56 +0,0 @@
|
||||
# Bug #491 分析报告
|
||||
|
||||
## Bug 信息
|
||||
- **标题**: 【执行科室配置】保存配置时系统报错
|
||||
- **报错信息**: `Cannot invoke "com.openhis.administration.domain.Organization.getName()" because the return value of "com.openhis.administration.service..." is null`
|
||||
- **严重程度**: 3 | **优先级**: 3 | **类型**: codeerror
|
||||
|
||||
## 复现步骤
|
||||
1. 登录 HIS 系统 → 【系统管理】→【业务规则配置】→【执行科室配置】
|
||||
2. 左侧选择科室(如"超声诊断科")
|
||||
3. 新增或修改某行的时间区间
|
||||
4. 点击【保存】按钮
|
||||
5. 顶部弹出红色错误提示(NPE)
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 文件定位
|
||||
- `openhis-server-new/.../appservice/impl/OrganizationLocationAppServiceImpl.java`(第161-175行)
|
||||
|
||||
### 根本原因
|
||||
在 `addOrEditOrgLoc` 方法中,保存时会检查时间冲突。当发现冲突时,代码需要获取冲突记录的科室名称用于错误提示:
|
||||
|
||||
```java
|
||||
// 第171-172行
|
||||
Organization org = organizationService.getById(organizationLocation.getOrganizationId());
|
||||
String organizationName = org.getName(); // NPE 这里!
|
||||
```
|
||||
|
||||
**问题**:`organizationService.getById()` 可能返回 `null`(当冲突记录的 `organizationId` 指向已被删除的机构时),直接调用 `.getName()` 导致 NPE。
|
||||
|
||||
### 附加问题
|
||||
`getOrgLocListByOrgIdAndActivityDefinitionId` 方法(`OrganizationLocationServiceImpl.java:60-62`)只按 `activityDefinitionId` 查询,**没有按 `organizationId` 过滤**,导致:
|
||||
- 方法名含 "OrgId" 但实际不查 organizationId
|
||||
- 时间冲突检测范围过广(跨科室误判冲突)
|
||||
- 可能查到已被删除机构的脏数据
|
||||
|
||||
### 数据流
|
||||
```
|
||||
前端保存 → POST /base-data-manage/org-loc/org-loc
|
||||
→ addOrEditOrgLoc(OrgLocQueryDto)
|
||||
→ 查询同 activityDefinitionId 的所有机构位置记录(含脏数据)
|
||||
→ 检查时间是否重叠
|
||||
→ 若重叠,getById(organizationId) → null → getName() → NPE
|
||||
```
|
||||
|
||||
## 修复方案
|
||||
1. `OrganizationLocationAppServiceImpl.java` 第172行:增加 `org != null` 判空,回退为 `"未知科室"`
|
||||
2. `IOrganizationLocationService.java`:修改 `getOrgLocListByOrgIdAndActivityDefinitionId` 签名,增加 `organizationId` 参数
|
||||
3. `OrganizationLocationServiceImpl.java`:查询条件增加 `.eq(OrganizationLocation::getOrganizationId, organizationId)`
|
||||
4. `OrganizationLocationAppServiceImpl.java` 第162行:调用时传入 `orgLoc.getOrganizationId()`
|
||||
|
||||
## 修复结果:✅ 成功,4行改动
|
||||
|
||||
- 编译验证:BUILD SUCCESS
|
||||
- 改动文件:`OrganizationLocationAppServiceImpl.java`、`IOrganizationLocationService.java`、`OrganizationLocationServiceImpl.java`
|
||||
- 已提交并推送到远程分支 guanyu
|
||||
@@ -1,53 +0,0 @@
|
||||
## Bug #530 分析报告
|
||||
|
||||
**标题**: [住院护士站-医嘱校对] 患者查询触发 SQL 类型匹配错误,导致勾选患者列表后后端报错
|
||||
|
||||
### 数据流追踪
|
||||
|
||||
1. `patientList.vue` → 树节点勾选触发 `handleCheckChange`
|
||||
2. `handleCheckChange` → `updatePatientInfoList(checkedPatients)` 存储选中的患者节点
|
||||
3. `handleGetPrescription()` 被触发 → `prescriptionList.vue` 的 `handleGetPrescription`
|
||||
4. 前端构造 encounterIds: `patientInfoList.value.map((i) => i.encounterId).join(',')`
|
||||
5. 后端解析: `Arrays.stream(encounterIds.split(",")).map(Long::parseLong).toList()`
|
||||
6. SQL 执行: `SELECT ... FROM ... WHERE ii.encounter_id IN (?, ?, ...)`
|
||||
|
||||
### 根因定位
|
||||
|
||||
**`patientList.vue` 第122行**:患者数据格式化时
|
||||
```javascript
|
||||
const patients = records.map((item) => ({
|
||||
id: item.id || item.encounterId, // 问题行
|
||||
name: item.patientName || '',
|
||||
leaf: true,
|
||||
...item,
|
||||
}));
|
||||
```
|
||||
|
||||
而后端 `AdmissionPatientPageDto` 中**没有 `id` 字段**(只有 `encounterId`、`patientId` 等),所以 `item.id` 为 `undefined`,此时 `item.id || item.encounterId` 回退到 `item.encounterId`。
|
||||
|
||||
但在 `prescriptionList.vue` 第186行提取 encounterId 时:
|
||||
```javascript
|
||||
let encounterIds = patientInfoList.value.map((i) => i.encounterId).join(',');
|
||||
```
|
||||
|
||||
如果 `patientInfoList` 中的某个对象其 `encounterId` 因任何原因为 `undefined`、`null` 或空字符串,`join(',')` 会产生类似 `"123,,456"` 的字符串。
|
||||
|
||||
后端解析时:
|
||||
```java
|
||||
List<Long> encounterIdList = Arrays.stream(encounterIds.split(",")).map(Long::parseLong).toList();
|
||||
```
|
||||
|
||||
`Long.parseLong("")` 会抛出 `NumberFormatException`,导致后端报错。
|
||||
|
||||
### 修复方案
|
||||
|
||||
在 `prescriptionList.vue` 的 `handleGetPrescription` 函数中,过滤掉无效的 encounterId 值:
|
||||
- 过滤 `undefined`、`null`、空字符串
|
||||
- 如果过滤后无有效 encounterId,提示用户并阻止请求
|
||||
|
||||
### 验证门禁
|
||||
|
||||
- [x] Gate A:根因已定位到 `prescriptionList.vue` 第186行,未过滤无效 encounterId
|
||||
- [x] Gate B:已读取前后端所有相关文件,理解完整数据流
|
||||
- [x] Gate C:修复方案与验收标准一致(前端防御性处理 + 正常查询)
|
||||
- [x] Gate D:不涉及数据库字段变更
|
||||
30
md/bug-analysis/bug444-analysis.md
Normal file
30
md/bug-analysis/bug444-analysis.md
Normal file
@@ -0,0 +1,30 @@
|
||||
# Bug #444 分析报告
|
||||
|
||||
## Bug 描述
|
||||
生成临时医嘱界面,"已引用计费药品"列表未正常显示药品详细名称信息。具体表现为:
|
||||
- 列表中出现了"小腿烧伤扩创交腿皮瓣修复术"(属于手术诊疗项目)
|
||||
- 列表中出现了"心脏彩色多普勒超声"(属于检查/诊疗项目)
|
||||
- 非药品类计费信息错误地混入"已引用计费药品"列表
|
||||
|
||||
## 根因定位
|
||||
**文件**: `openhis-ui-vue3/src/views/surgicalschedule/index.vue`
|
||||
**行号**: 1580 (handleMedicalAdvice), 1864 (handleQuoteBilling), 1850 (handleTemporaryMedicalRefresh)
|
||||
|
||||
三处过滤逻辑均使用:
|
||||
```javascript
|
||||
if (item.adviceType !== 1) return false;
|
||||
```
|
||||
|
||||
**问题1(主因)**: `adviceType` 字段命名兼容不完整。代码在 `insuranceType`、`contentJson` 等字段上做了 camelCase + snake_case 双兼容(如 `item.insuranceType || item.insurance_type`),但 `adviceType` 只检查了 camelCase。若后端返回 snake_case 数据(`advice_type`),`item.adviceType` 为 `undefined`,`undefined !== 1` 为 `true`,导致所有非药品项目全部放行。
|
||||
|
||||
**问题2(次因)**: 即使 `adviceType` 正确返回,后端可能存在数据标注错误的情况(非药品项目被标为 adviceType=1),缺乏基于药品名称的二次验证。
|
||||
|
||||
## 修复方案
|
||||
1. `adviceType` 检查增加 snake_case 回退:`const at = item.adviceType ?? item.advice_type; if (at !== 1) return false;`
|
||||
2. 增加药品名称关键字二次过滤:排除名称中包含"术"、"检查"、"超声"、"多普勒"等关键词的非药品项目
|
||||
|
||||
## 验收标准
|
||||
1. "已引用计费药品"列表中只显示药品类项目
|
||||
2. 不显示手术诊疗项目(如"小腿烧伤扩创交腿皮瓣修复术")
|
||||
3. 不显示检查项目(如"心脏彩色多普勒超声")
|
||||
4. 药品名称正常显示
|
||||
@@ -132,7 +132,22 @@ temporaryAdvices.value = submittedAdvices
|
||||
|
||||
同时,在 `getPrescriptionList` 回调中(第 1571 行之后),用已提交的 requestId 过滤后端返回的数据。
|
||||
|
||||
## 总结
|
||||
## 修复结果
|
||||
|
||||
- **根因**:`handleMedicalAdvice` 每次打开都清空 `temporaryAdvices`,然后从后端重新拉取数据。但后端返回的新创建医嘱项可能没有 `requestId`,导致无法过滤。
|
||||
- **修复**:保留已提交(有 requestId)的医嘱数据,不清空;同时用这些 requestId 过滤后端返回的新数据。
|
||||
### 实际根因
|
||||
`handleQuoteBilling` 函数中:
|
||||
1. **第1856行**:在调用 `getPrescriptionList` 之前先清空了 `temporaryAdvices.value = []`
|
||||
2. **第1997-2019行(旧代码)**:ID 匹配过滤逻辑依赖已被清空的 `temporaryAdvices.value`,因此过滤形同虚设
|
||||
3. 即使 `temporaryAdvices` 未被清空,ID 匹配也不可靠(新生成的医嘱可能没有 `requestId`/`chargeItemId`/`id`)
|
||||
|
||||
### 修复方案
|
||||
1. 在清空 `temporaryAdvices` **之前**,提取已提交项目的复合键(名称+规格+数量)保存到 `submittedKeysBeforeClear`
|
||||
2. 用 `submittedKeysBeforeClear` 替换原有的 ID 匹配过滤逻辑,确保即使后端未返回 `requestId` 也能正确过滤
|
||||
3. 复合键匹配策略与 `handleTemporaryMedicalSubmit` 中使用的策略一致
|
||||
|
||||
### 修改文件
|
||||
- `openhis-ui-vue3/src/views/surgicalschedule/index.vue`
|
||||
- 第1853-1864行:新增 `submittedKeysBeforeClear` 提取逻辑
|
||||
- 第1997-2004行:替换 ID 匹配为复合键匹配
|
||||
|
||||
### 修复结果:✅ 成功,~20行改动(+20/-21)
|
||||
|
||||
@@ -169,7 +169,7 @@ public class OrganizationLocationAppServiceImpl implements IOrganizationLocation
|
||||
if (DateTimeUtils.isOverlap(organizationLocation.getStartTime(), organizationLocation.getEndTime(),
|
||||
orgLoc.getStartTime(), orgLoc.getEndTime())) {
|
||||
Organization org = organizationService.getById(organizationLocation.getOrganizationId());
|
||||
String organizationName = org != null && org.getName() != null ? org.getName() : "未知科室";
|
||||
String organizationName = org != null ? org.getName() : ("科室[" + organizationLocation.getOrganizationId() + "]已删除");
|
||||
return R.fail("当前诊疗:" + activityName + CommonConstants.Common.DASH + orgLoc.getStartTime()
|
||||
+ CommonConstants.Common.DASH + orgLoc.getEndTime() + "与" + organizationName + "时间冲突");
|
||||
}
|
||||
|
||||
@@ -244,6 +244,8 @@ const getList = async () => {
|
||||
const handleSearch = () => {
|
||||
// 搜索时保持已选中的项目不受影响
|
||||
};
|
||||
// 编辑初始化标志:避免 applyEditTransferSelection 设置 transferValue 时触发 projectWithDepartment 覆盖 descJson 中的科室值
|
||||
const isInitializing = ref(false);
|
||||
const transferValue = ref([]);
|
||||
const form = reactive({
|
||||
// categoryType: '', // 项目类别
|
||||
@@ -341,6 +343,7 @@ const projectWithDepartment = (selectProjectIds, type) => {
|
||||
watch(
|
||||
() => transferValue.value,
|
||||
(newValue) => {
|
||||
if (isInitializing.value) return;
|
||||
projectWithDepartment(newValue, 1);
|
||||
}
|
||||
);
|
||||
@@ -377,7 +380,10 @@ const applyEditTransferSelection = () => {
|
||||
}
|
||||
}
|
||||
const uniq = [...new Set(selectedIds)]
|
||||
// 设置初始化标志,防止 transferValue 变化触发 projectWithDepartment 覆盖 descJson 中的科室值
|
||||
isInitializing.value = true
|
||||
transferValue.value = uniq
|
||||
isInitializing.value = false
|
||||
if (newData.requestFormDetailList.length && uniq.length === 0) {
|
||||
console.warn(
|
||||
'[LaboratoryTests] 申请单明细未能在项目字典中匹配到项,请核对 activityId / 项目名称',
|
||||
@@ -427,7 +433,9 @@ watch(
|
||||
selectedIds.push(matched.adviceDefinitionId);
|
||||
}
|
||||
});
|
||||
isInitializing.value = true;
|
||||
transferValue.value = selectedIds;
|
||||
isInitializing.value = false;
|
||||
}
|
||||
);
|
||||
|
||||
|
||||
@@ -348,7 +348,8 @@ const adviceTypeList = computed(() => {
|
||||
return val === 3 || val === 4;
|
||||
}).map(item => ({
|
||||
label: item.label,
|
||||
value: parseInt(item.value)
|
||||
// drord_doctor_type 中耗材是 4,但 /advice-base-info 后端耗材类型是 2
|
||||
value: parseInt(item.value) === 4 ? 2 : parseInt(item.value)
|
||||
}));
|
||||
return [...filtered, { label: '全部', value: '' }];
|
||||
}
|
||||
@@ -483,8 +484,9 @@ watch(
|
||||
(visible) => {
|
||||
if (visible) {
|
||||
executeTime.value = formatDateStr(new Date(), 'YYYY-MM-DD HH:mm:ss');
|
||||
// 弹窗打开时重新加载科室和位置选项,确保数据最新
|
||||
// 弹窗打开时按当前患者科室重新加载,避免复用上一次患者/登录科室的结果
|
||||
loadDepartmentOptions();
|
||||
getAdviceBaseInfos();
|
||||
getDiseaseInitLoc(16);
|
||||
} else {
|
||||
resetData();
|
||||
@@ -565,6 +567,8 @@ function getAdviceBaseInfos() {
|
||||
queryParams.value.adviceTypes = [1, 2, 3];
|
||||
}
|
||||
queryParams.value.organizationId = orgId.value;
|
||||
queryParams.value.adviceTypes = normalizeAdviceTypesForQuery(adviceType.value);
|
||||
queryParams.value.organizationId = props.patientInfo.organizationId || orgId.value;
|
||||
queryParams.value.pricingFlag = 1; // 划价标记
|
||||
getAdviceBaseInfo(queryParams.value)
|
||||
.then((res) => {
|
||||
@@ -620,6 +624,12 @@ function getItemType_Text(type) {
|
||||
const map = { 2: '耗材', 3: '诊疗' };
|
||||
return map[type] || '其他';
|
||||
}
|
||||
function normalizeAdviceTypesForQuery(type) {
|
||||
if (type === '' || type === undefined || type === null) {
|
||||
return '2,3';
|
||||
}
|
||||
return Number(type) === 4 ? 2 : type;
|
||||
}
|
||||
function getUnitCodeOptions(row) {
|
||||
const unitCodes = [];
|
||||
// 大单位:优先用 code,code 缺失时用字典文本兜底
|
||||
|
||||
@@ -1576,12 +1576,18 @@ function handleMedicalAdvice(row) {
|
||||
const filteredItems = res.data.filter(item => {
|
||||
// 匹配 encounterId
|
||||
if (item.encounterId !== row.visitId) return false;
|
||||
// 只保留药品类型(adviceType=1),过滤掉耗材(2)和诊疗项目(3)
|
||||
if (item.adviceType !== 1) return false;
|
||||
// 只保留药品类型(adviceType=1),过滤掉耗材(2)和诊疗项目(3/6)
|
||||
// 🔧 修复 Bug #444: 使用 Number() 显式转换,避免字符串 "1" 被 !== 1 放行
|
||||
const at = Number(item.adviceType ?? item.advice_type);
|
||||
if (at !== 1) return false;
|
||||
// 过滤掉名称为空的项目
|
||||
const medicineName = item.adviceName || item.advice_name;
|
||||
if (!medicineName || medicineName.trim() === '') return false;
|
||||
// 🔧 修复 Bug #445: 过滤掉已生成医嘱的项目(已有 requestId 的不应出现在"待生成"列表)
|
||||
// 🔧 修复 Bug #444: 二次过滤,排除名称中包含手术/检查/诊疗关键词的非药品项目
|
||||
// 某些计费项目可能在 adm_charge_item 中被错误标注为 adviceType=1
|
||||
const excludedKeywords = ['术', '超声', '多普勒', '检查', '检验', '彩超', 'X线', 'CT', 'MRI', '扫描', '造影'];
|
||||
if (excludedKeywords.some(kw => medicineName.includes(kw))) return false;
|
||||
// 🔧 修复 Bug #445: 过滤掉已生成医嘱的项目(已有 requestId 的不应出现在"待生成"列表中)
|
||||
if (item.requestId) return false;
|
||||
// 根据药品请求ID去重,避免重复显示
|
||||
const itemId = item.requestId || item.id;
|
||||
@@ -1848,6 +1854,21 @@ function handleTemporaryMedicalRefresh() {
|
||||
function handleQuoteBilling() {
|
||||
// 重新拉取计费药品数据
|
||||
if (temporaryPatientInfo.value.visitId) {
|
||||
// 🔧 修复 Bug #445: 在清空之前提取已提交项目的复合匹配键
|
||||
// 原因:后续的 ID 匹配过滤依赖 temporaryAdvices,但 temporaryAdvices 会被先清空
|
||||
// 新医嘱没有 requestId/chargeItemId,需用名称+规格+数量的复合键匹配
|
||||
const submittedKeys = new Set(
|
||||
(temporaryAdvices.value || [])
|
||||
.map(a => {
|
||||
const om = a.originalMedicine || {}
|
||||
const name = om.medicineName || om.adviceName || a.adviceName || ''
|
||||
const spec = om.specification || om.volume || ''
|
||||
const qty = om.quantity ?? 0
|
||||
return `${name}|||${spec}|||${qty}`
|
||||
})
|
||||
.filter(k => k !== '|||0')
|
||||
)
|
||||
|
||||
temporaryMedicalLoading.value = true // 🔧 新增:开始加载
|
||||
getPrescriptionList(temporaryPatientInfo.value.visitId, 6, temporaryPatientInfo.value.operCode).then((res) => {
|
||||
if (res.code === 200 && res.data) {
|
||||
@@ -1855,16 +1876,22 @@ function handleQuoteBilling() {
|
||||
temporaryBillingMedicines.value = []
|
||||
temporaryAdvices.value = []
|
||||
|
||||
// 🔧 修复 Bug #445: 只保留药品类型(adviceType=1),过滤掉耗材(2)和诊疗项目(3)
|
||||
// 同时过滤掉已有 requestId 的项目(已生成医嘱的不需要再次显示在"待生成"列表中)
|
||||
// 🔧 修复 Bug #444: 统一过滤逻辑,与 handleMedicalAdvice 保持一致
|
||||
// 1. 使用 Number() + snake_case 回退,避免类型转换导致过滤失效
|
||||
// 2. 增加关键词二次过滤,排除手术/检查/诊疗等非药品项目
|
||||
const filteredItems = res.data.filter(item => {
|
||||
// 匹配 encounterId
|
||||
if (item.encounterId !== temporaryPatientInfo.value.visitId) return false;
|
||||
// 只保留药品类型(adviceType=1),过滤掉耗材(2)和诊疗项目(3)
|
||||
if (item.adviceType !== 1) return false;
|
||||
// 只保留药品类型(adviceType=1),过滤掉耗材(2)和诊疗项目(3/6)
|
||||
// 🔧 修复 Bug #444: 使用 Number() 显式转换,增加 snake_case 回退
|
||||
const at = Number(item.adviceType ?? item.advice_type);
|
||||
if (at !== 1) return false;
|
||||
// 过滤掉名称为空的项目
|
||||
const medicineName = item.adviceName || item.advice_name;
|
||||
if (!medicineName || medicineName.trim() === '') return false;
|
||||
// 🔧 修复 Bug #444: 二次过滤,排除名称中包含手术/检查/诊疗关键词的非药品项目
|
||||
const excludedKeywords = ['术', '超声', '多普勒', '检查', '检验', '彩超', 'X线', 'CT', 'MRI', '扫描', '造影'];
|
||||
if (excludedKeywords.some(kw => medicineName.includes(kw))) return false;
|
||||
// 🔧 修复 Bug #445: 过滤掉已生成医嘱的项目(已有 requestId)
|
||||
if (item.requestId) return false;
|
||||
return true;
|
||||
@@ -1981,27 +2008,57 @@ function handleQuoteBilling() {
|
||||
})
|
||||
|
||||
// 🔧 修复 Bug #445: 过滤掉已生成医嘱的项目,避免"引用计费"后已提交项目重新出现在"待生成"列表
|
||||
// 原因:后端返回的计费数据中,已生成医嘱的项目可能没有 requestId 字段
|
||||
// 方案:用 chargeItemId/requestId/id 与已有的 temporaryAdvices 做匹配,排除已生成项目
|
||||
if (temporaryAdvices.value.length > 0) {
|
||||
const existingAdviceIds = new Set()
|
||||
temporaryAdvices.value.forEach(a => {
|
||||
const om = a.originalMedicine || {}
|
||||
if (om.requestId) existingAdviceIds.add(String(om.requestId))
|
||||
if (om.chargeItemId) existingAdviceIds.add(String(om.chargeItemId))
|
||||
if (om.id) existingAdviceIds.add(String(om.id))
|
||||
// 使用清空前提取的 submittedKeys(名称|||规格|||数量复合键)进行匹配
|
||||
if (submittedKeys.size > 0) {
|
||||
temporaryBillingMedicines.value = temporaryBillingMedicines.value.filter(m => {
|
||||
const key = `${m.medicineName || ''}|||${m.specification || ''}|||${m.quantity ?? 0}`
|
||||
return !submittedKeys.has(key)
|
||||
})
|
||||
// 同步更新 temporaryAdvices,保持两份数据一致
|
||||
temporaryAdvices.value = temporaryBillingMedicines.value.map((medicine, index) => {
|
||||
const specMatch = medicine.specification ? medicine.specification.match(/(\d+)(\D+)/) : null
|
||||
const specValue = specMatch ? parseInt(specMatch[1]) : 1
|
||||
const specUnit = specMatch ? specMatch[2] : 'ml'
|
||||
const dosage = specValue * (medicine.quantity || 1)
|
||||
let usageCode = 'iv'
|
||||
let usageLabel = '静脉注射'
|
||||
try {
|
||||
const jsonContent = medicine.contentJson || medicine.content_json;
|
||||
if (jsonContent) {
|
||||
const contentData = JSON.parse(jsonContent);
|
||||
if (contentData.methodCode) {
|
||||
usageCode = contentData.methodCode;
|
||||
usageLabel = getUsageLabel(contentData.methodCode);
|
||||
}
|
||||
}
|
||||
} catch (e) {}
|
||||
if (!usageCode || usageCode === 'iv') {
|
||||
if (medicine.medicineName && medicine.medicineName.includes('注射液')) {
|
||||
usageCode = 'iv'; usageLabel = '静脉注射';
|
||||
} else if (medicine.medicineName && medicine.medicineName.includes('片')) {
|
||||
usageCode = 'po'; usageLabel = '口服';
|
||||
} else if (medicine.medicineName && medicine.medicineName.includes('胶囊')) {
|
||||
usageCode = 'po'; usageLabel = '口服';
|
||||
}
|
||||
}
|
||||
return {
|
||||
id: index + 1,
|
||||
adviceName: medicine.medicineName || '',
|
||||
dosage,
|
||||
unit: specUnit,
|
||||
usage: usageCode,
|
||||
usageLabel,
|
||||
frequency: '临时',
|
||||
executeTime: new Date().toLocaleString('zh-CN'),
|
||||
originalMedicine: {
|
||||
...medicine,
|
||||
medicineName: medicine.medicineName,
|
||||
specification: medicine.specification,
|
||||
quantity: medicine.quantity,
|
||||
encounterId: temporaryPatientInfo.value.visitId
|
||||
}
|
||||
}
|
||||
})
|
||||
if (existingAdviceIds.size > 0) {
|
||||
temporaryBillingMedicines.value = temporaryBillingMedicines.value.filter(m => {
|
||||
const mRequestId = m.requestId != null ? String(m.requestId) : null
|
||||
const mChargeItemId = m.chargeItemId != null ? String(m.chargeItemId) : null
|
||||
const mId = m.id != null ? String(m.id) : null
|
||||
if (mRequestId && existingAdviceIds.has(mRequestId)) return false
|
||||
if (mChargeItemId && existingAdviceIds.has(mChargeItemId)) return false
|
||||
if (mId && existingAdviceIds.has(mId)) return false
|
||||
return true
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
temporaryMedicalLoading.value = false // 🔧 新增:加载完成
|
||||
|
||||
Reference in New Issue
Block a user