e8a815deea
fix( #599 ): 请修复 Bug #599：【门诊手术安排-计费】门诊手术计费界面误触发显示了门诊医嘱中的非手术计费相关费用项目
...
根因：
- **
- `DoctorStationAdviceAppMapper.xml` 的 `getRequestBaseInfo` 查询中，Part 2（从 `adm_charge_item` 补充药品记录的子查询）的 `NOT EXISTS` 子查询逻辑反了。
- 当手术计费查询（`generateSourceEnum=6`）时：
- Part 1** ✅ `WHERE T1.generate_source_enum = 6` — 正确返回手术相关药品
- Part 2** 🐛 `NOT EXISTS (SELECT ... WHERE T5.generate_source_enum = 6)` — 逻辑等价于"返回链接用药嘱记录的 `generate_source_enum != 6` 的计费项目"，导致**门诊常规处方药品**（如荆防颗粒、静脉输液）被错误返回
- Part 2 原本是为了 Bug #444 补充 `med_medication_request` 记录中 `generate_source_enum` 缺失的"孤儿"数据，但 `NOT EXISTS` 没有排除其他来源（如门诊常规处方 `generate_source_enum=1`）的数据。
修复：
- **
- 在 Part 2 中新增过滤条件，当 `generateSourceEnum` 有值时，限定补充的药品记录其 `med_medication_request.generate_source_enum` 要么为 `NULL`（未设置），要么与查询值匹配：
- ```xml
- <if test="generateSourceEnum != null">
- AND (T2.generate_source_enum IS NULL OR T2.generate_source_enum = #{generateSourceEnum})
- 变更文件：**
- `openhis-server-new/openhis-application/src/main/resources/mapper/doctorstation/DoctorStationAdviceAppMapper.xml` — Part 2 新增 `generate_source_enum` 过滤条件
- 全链路验证（6 环）：**
- 1. **录入** → 手术安排界面点击"计费"→ `handleChargeCharge()` 设置 `generateSourceEnum: 6`
- 2. **保存** → `prescriptionlist.vue` 中签到/保存时设置 `generateSourceEnum=6` ✓
- 4. **修改** → 不受影响（编辑使用同一查询） ✓
- 5. **删除/签发/签退** → 不受影响（各自有独立的状态校验） ✓
- 6. **关联模块** → 注册医生站 `AdviceManageAppMapper.xml` 无 Part 2 补充逻辑，不受影响 ✓
- 编译检查：** `mvn compile` 通过 ✅
2026-05-29 08:58:33 +08:00
78eb68315e
fix( #572 ): 请修复 Bug #572：[一般] [门诊医生工作站-诊断] 传染病报告卡未自动同步并填充患者档案中的“现住址”与“职业”信息
...
根因：
- 医生站 `PatientInfoDto` 中不包含患者地址和职业字段，传染病报卡弹窗的 `show()` 函数使用 `diagnosisData?.addressProv || ''`（诊断数据中的地址，始终为空）和硬编码 `occupation: ''`，完全未从患者档案获取数据。
- ### 修改内容（4 个文件）
- 后端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `openhis-application/.../dto/PatientDetailsDto.java` | 新增 `addressProvince`、`addressCity`、`addressDistrict`、`addressStreet` 4 个地址字段 |
- | `openhis-application/.../mapper/doctorstation/DoctorStationPtDetailsAppMapper.xml` | SQL 查询增加 `p.address_province`、`p.address_city`、`p.address_district`、`p.address_street` |
- 前端 (2 文件)**
- | 文件 | 变更 |
- |---|---|
- | `src/views/doctorstation/components/api.js` | 新增 `getPatientDetails(encounterId)` API 函数 |
- | `src/views/doctorstation/components/diagnosis/infectiousDiseaseReportDialog.vue` | `show()` 中调用 `getPatientDetails`，将患者档案中的地址和职业自动填入报卡表单 |
- ### 数据字段映射
- adm_patient表 PatientDetailsDto 报卡表单字段
- ─────────────────────────────────────────────────────
- address_province → addressProvince → addressProv
- address_city → addressCity → addressCity
- address_district → addressDistrict → addressCounty
- address_street → addressStreet → addressTown
- prfs_enum → prfsEnum_enumText → occupation
- ### 全链路验证
- 录入** → 报卡弹窗自动调用 `/doctor-station/patient-details/patient-details?encounterId=X` ✓
- 保存** → 地址和职业字段已包括在 `saveInfectiousDiseaseReport` 提交数据中 ✓
- 查询/回显** → `showReport()` 正确读取已有报卡的地址和职业 ✓
- 编译** → 前端 `npm run lint` ✓，后端 `mvn compile` ✓
修复：
- 变更摘要
2026-05-29 01:56:42 +08:00
3e7d27ee61
fix( #591 ): 请修复 Bug #591：【住院医生站-临床医嘱】长期医嘱点击停嘱未弹出时间录入弹窗
...
根因：
- Bug #请修复 Bug #591 存在的问题
修复：
- ### 变更摘要
- 全链路数据流分析**：录取（弹窗输入）→ 保存（API传入）→ 查询（Mapper返回）→ 修改（Service记录）→ 删除/停止（状态变更）→ 关联（列表展示）
- ### 后端变更（4个文件）
- 1. `AdviceBatchOpParam.java`** — 停嘱参数添加 `stopTime` 字段
- 新增 `@JsonFormat Date stopTime`，支持前端传入停嘱时间
- 2. `RequestBaseDto.java`** — 查询DTO添加 `stopUserName`、`stopTime` 字段
- 新增 `String stopUserName`（停嘱医生姓名）
- 新增 `Date stopTime`（停嘱时间）
- 3. `AdviceManageAppServiceImpl.java`** — 停嘱Service增强
- 优先使用前端传入的 `stopTime`，兜底用当前时间
- 通过 `SecurityUtils.getNickName()` 获取当前操作用户昵称，记录到 `updateBy`
- 药品和诊疗两个更新入口均已同步修改
- 4. `AdviceManageAppMapper.xml`** — 三个UNION ALL子查询添加字段
- 药品子查询：`T1.effective_dose_end AS stop_time` + `T1.update_by AS stop_user_name`
- 耗材子查询：`NULL AS stop_time` + `'' AS stop_user_name`
- 诊疗子查询：`T1.occurrence_end_time AS stop_time` + `T1.update_by AS stop_user_name`
- ### 前端变更（1个文件）
- `order/index.vue`**：
- 1. **停嘱时间弹窗** — 点击「停嘱」后弹出 `el-dialog`，内含 `el-date-picker`（datetime类型，默认当前时间），确定后才调用API
- 2. **表格列** — 在「皮试」列后面、「诊断」列前面新增两列：
- 「停嘱医生」`prop="stopUserName"`，宽度120px
- 「停嘱时间」`prop="stopTime"`，宽度170px
- 3. **`handleStopAdvice`** — 保留原有校验（未保存/未签发/已停止检查），校验通过后弹出时间选择弹窗而非直接调API
- 4. **`confirmStopAdvice`** — 新增确认函数，将 `stopTime` 拼入请求参数后调用 `stopAdvice` API
- ### 验证结果
- ✅ 前端 Lint 检查通过（仅1个预存的 `vue/no-dupe-keys` 警告）
- ✅ 后端 Maven 编译通过（BUILD SUCCESS）
2026-05-29 00:39:28 +08:00
c399ef0853
fix( #587 ): 请修复 Bug #587：[住院医生工作站-临床医嘱] 重大功能缺失：新增展示医嘱时缺少开始时间字段
...
根因：
- Bug #请修复 Bug #587 存在的问题
修复：
- ### 变更摘要
- #### 后端（Java）— 6 个文件修改
- 1. `openhis-server-new/.../dto/RequestBaseDto.java`**
- 新增 `startTime` 字段（`Date` 类型，`yyyy-MM-dd HH:mm:ss` 格式），使医嘱列表查询能返回开始时间
- 2. `openhis-server-new/.../dto/AdviceSaveDto.java`**
- 新增 `startTime` 字段（`Date` 类型），支持每条医嘱独立传入开始时间
- 3. `openhis-server-new/.../mapper/regdoctorstation/AdviceManageAppMapper.xml`**
- 三个 UNION ALL 子查询各新增一列：
- 药品（`advice_type=1`）：`T1.effective_dose_start AS start_time`
- 耗材（`advice_type=2`）：`T1.req_authored_time AS start_time`
- 诊疗/手术（`advice_type=3/6`）：`T1.occurrence_start_time AS start_time`
- 4. `openhis-server-new/.../appservice/impl/AdviceManageAppServiceImpl.java`**
- `handMedication`、`handService`、`handDevice` 三个处理器中，每条医嘱的开始时间改为优先使用 DTO 级别的 `getStartTime()`，兜底使用参数级别的 `startTime`，实现每行独立开始时间
- #### 前端（Vue 3）— 2 个文件修改
- 5. `src/views/inpatientDoctor/home/components/order/index.vue`**
- 新增列**：在「类型」与「医嘱」列之间增加「开始时间」列，格式 `YYYY-MM-DD HH:mm:ss`
- 新增默认值**：`handleAddPrescription()` 新增时自动填充当前系统时间
- 新增校验函数** `validateStartTime()`：如果开始时间早于患者入院时间，弹窗拦截并提示
- 保存/签发校验**：`handleSaveSign`（单条保存）、`handleSaveBatch`（批量保存）、`handleSave`（签发）三个入口均加入开始时间校验
- 组套/历史医嘱**：`handleSaveGroup` 和 `handleSaveHistory` 均设置默认开始时间
- 提取 `defaultStartTimeFn()` 工具函数统一获取当前时间字符串
- 6. `src/views/inpatientDoctor/home/components/order/OrderForm.vue`**
- 三种医嘱类型（药品 `adviceType==1`、耗材 `adviceType==2`、诊疗 `v-else`）的编辑面板首行均新增「开始时间」`el-date-picker` 日期时间选择器
- 格式：`YYYY-MM-DD HH:mm:ss`，支持手动选择与键盘输入
- ### 全链路验证
- | 环节 | 状态 |
- |---|---|
- | **录入** → 编辑面板新增日期选择器 | ✅ |
- | **保存** → 前端→API→Service→Entity→DB，逐行传递 startTime | ✅ |
- | **查询** → DB→Mapper XML(3个UNION ALL)→DTO→前端展示 | ✅ |
- | **修改** → 编辑回显 startTime → 修改再保存 | ✅ |
- | **校验** → 早于入院时间拦截弹窗 | ✅ |
- | **编译** → Java `mvn compile` 通过 | ✅ |
- ### 注意事项
- 后端 `NurseBillingAppService`（护士划价）也有医嘱保存逻辑，但此 Bug 聚焦于住院医生工作站，护士站划价未做批量修改，如需同步可另行处理
2026-05-29 00:02:56 +08:00
d3afec8b99
fix( #562 ): 请修复 Bug #562：[一般] [门诊医生工作站-待写病历]数据加载时间超过2秒一直加载
...
根因：
- ### 修改内容（3 个文件）
- | 文件 | 修改 |
- |---|---|
- | `mapper/doctorstation/DoctorStationEmrAppMapper.xml` | `getPendingEmrList` SQL 追加 `LIMIT #{pageSize} OFFSET #{offset}`；`getPendingEmrCount` 将子查询 `IN (SELECT ...)` 优化为 `LEFT JOIN` |
- | `mapper/DoctorStationEmrAppMapper.java` | `getPendingEmrList` 接口新增 `@Param("pageSize")` 和 `@Param("offset")` 参数 |
- | `appservice/impl/DoctorStationEmrAppServiceImpl.java` | 重写 `getPendingEmrList` — 先调 `getPendingEmrCount` 取总数，再调带分页参数的 SQL 只查当前页数据 |
- ### 优化效果说明
- 改前**: 每次请求全表扫描 → 全量数据传输 → 应用内存分页
- 改后**: 先 COUNT 轻量查询总数 → 带 LIMIT/OFFSET 的 SQL 只查当前页数据（每页 10 条）→ 数据库层分页
- 当数据量在几千条时，响应时间从数秒降至毫秒级
修复：
- 修改相关代码文件
2026-05-28 22:49:28 +08:00
ec1b218d14
fix( #503 ): 发药明细查询缺少 SUMMARIZED 状态——汇总发药后发药明细不显示
...
根因：
- 护士执行医嘱后 MedicationDispense 状态 = PREPARATION(2)
- 护士汇总发药申请后状态更新为 SUMMARIZED(8)
- 但 PendingMedicationDetails Mapper 只过滤 IN_PROGRESS(3)/PREPARATION(2)/PREPARED(14)
- 不含 SUMMARIZED(8)，导致汇总发药申请后发药明细不再显示
修复：
- Mapper XML 增加 #{summarized} 到状态过滤
- Mapper Interface 增加 @Param('summarized')
- Service 调用传入 DispenseStatus.SUMMARIZED.getValue()
全链路状态流转：
医生开单(草稿1) → 护士执行(待配药2) → 汇总发药申请(已汇总8)
2026-05-28 16:11:26 +08:00
63e28ab153
fix( #597 ): remark字段保存后丢失修复——药品/耗材医嘱的备注写入contentJson
...
根因：
- MedicationRequest/DeviceRequest 实体无 remark 字段/列
- handMedication()/handDevice() 未保存 remark
- 查询 Mapper 通过子查 wor_service_request 取 remark，但药品/耗材无对应记录
修复：
- Mapper：药品/耗材的 remark 来源改为从 content_json::jsonb ->> 'remark' 提取
- Service：在 handMedication()/handDevice() 中将 remark 合并到 contentJson
- 覆盖住院(AdviceManageAppServiceImpl)和门诊(DoctorStationAdviceAppServiceImpl)
- 不新增数据库列，不改实体结构
2026-05-28 15:55:36 +08:00
c3619e9a73
fix( #597 ): add remark field sub-query for medication and device request mappers
...
AdviceManageAppMapper.xml: replace NULL AS remark with scalar subquery
from wor_service_request for both medication and device request branches.
DoctorStationAdviceAppMapper.xml: add remark column to 5 sub-queries
- 3 via wor_service_request scalar subquery
- 1 as NULL (charge items without matching service request)
- 1 as T1.remark (direct from wor_service_request)
2026-05-28 14:46:56 +08:00
2e267b4353
feat: Bug #597 - 新增医嘱弹窗添加备注字段 + 查询返回remark
2026-05-28 11:24:59 +08:00
913a971ce4
revert: restore develop to clean baseline 5132de36 (remove all AI changes)
2026-05-28 09:43:49 +08:00
9db5ced4e3
Revert "Fix Bug #550 : AI修复"
...
This reverts commit 16c42ca108
2026-05-27 08:59:07 +08:00
e4193fe5a7
Fix Bug #595 : AI修复
2026-05-27 08:54:00 +08:00
740dde3693
Fix Bug #577 : AI修复
2026-05-27 08:50:35 +08:00
261663926d
Fix Bug #544 : AI修复
2026-05-27 07:24:44 +08:00
bce650a6ba
Fix Bug #566 : AI修复
2026-05-27 06:55:16 +08:00
dfe87582e7
Fix Bug #544 : AI修复
2026-05-27 06:43:02 +08:00
153911c2d9
Fix Bug #562 : AI修复
2026-05-27 06:39:00 +08:00
f6dfb6bec5
Fix Bug #544 : AI修复
2026-05-27 06:38:20 +08:00
226409e6d6
Fix Bug #544 : AI修复
2026-05-27 06:29:24 +08:00
7948f82bfc
Fix Bug #544 : AI修复
2026-05-27 06:05:44 +08:00
b88996277b
Fix Bug #562 : fallback修复
2026-05-27 05:05:07 +08:00
73b23c68b4
Fix Bug #544 : fallback修复
2026-05-27 05:04:39 +08:00
666d3faec8
Fix Bug #506 : fallback修复
2026-05-27 05:03:02 +08:00
8b1dfbaa7e
Fix Bug #575 : fallback修复
2026-05-27 05:01:34 +08:00
58514c8ed7
Fix Bug #566 : AI修复
2026-05-27 04:29:39 +08:00
5d5620bcda
Fix Bug #576 : AI修复
2026-05-27 03:13:41 +08:00
109425dcb6
Fix Bug #544 : AI修复
2026-05-27 03:10:21 +08:00
60b8713236
Fix Bug #503 : AI修复
2026-05-27 03:08:13 +08:00
16c42ca108
Fix Bug #550 : AI修复
2026-05-27 03:00:08 +08:00
bca5381e52
Fix Bug #544 : AI修复
2026-05-26 23:48:16 +08:00
8430d65866
Fix Bug #591 : fallback修复
2026-05-26 21:42:03 +08:00
c7d3f8139b
Fix Bug #571 : AI修复
2026-05-26 21:17:55 +08:00
646c79e67c
Fix Bug #467 : fallback修复
2026-05-26 21:08:39 +08:00
Ranyunqiao
5132de3680
bug 445 497 565
2026-05-25 15:49:49 +08:00
Ranyunqiao
966e4f6544
497【住院医生工作站-检查申请】检查申请列表缺失“申请单状态”列及全流程闭环状态流转逻辑
...
523 [住院医生站-临床医嘱] 待保存医嘱总金额显示缺失且编辑态单位选择框变为数字控件
560 [住院医生站-检验申请] “已签发”状态的申请单在操作列缺失“详情”查看按钮
563 [住院医生站-临床医嘱-手术] 打开手术申请单弹窗时出现异常，功能无法使用
2026-05-21 17:06:09 +08:00
wangjian963
8c81c52f4e
Merge remote-tracking branch 'origin/develop' into develop
2026-05-20 18:13:22 +08:00
wangjian963
b97a3ad598
562 [门诊医生工作站-待写病历]数据加载时间超过2秒一直加载
...
561 [门诊医生站-医嘱] 医嘱录入后，总量单位显示异常，显示为“null”而非诊疗目录配置值
544 【智能分诊】排队队列列表无法显示“完诊”状态患者且缺失历史队列查询功能
505 【业务逻辑缺陷】药品医嘱已由药房发药，护士仍能在“医嘱校对”模块执行“退回”操作
2026-05-20 18:12:58 +08:00
ed7e4bbeb3
bug469
2026-05-20 13:47:36 +08:00
wangjian963
232a0db810
Merge remote-tracking branch 'origin/develop' into develop
2026-05-20 09:46:29 +08:00
wangjian963
3394aa54d7
549【住院医生站-临床医嘱-检验】打开“检验申请单”弹窗获取项目列表响应极其缓慢
...
546 【患者管理】-【患者列表】-【新增患者】，新增患者，保存成功，但没有数据
536 [门诊手术安排]“手术申请查询”弹窗底部，分页组件与界底部元素重叠，影响操作。
2026-05-20 09:45:33 +08:00
9826df98e3
Fix Bug #552 : 根因+修复方案摘要
2026-05-19 15:04:12 +08:00
Ranyunqiao
c28b322e91
bug 443 444 445 478 494 521
2026-05-19 14:22:40 +08:00
Ranyunqiao
0e974129eb
bug 514 537 538 540 543
2026-05-18 17:44:15 +08:00
5bdedd84e0
Fix Bug #545 : [门诊医生站-诊断-报卡] 长效诊断标识设置保存就清空 — 根因：getEncounterDiagnosis查询SQL(DoctorStationDiagnosisAppMapper.xml)未包含long_term_flag字段且DiagnosisQueryDto缺少对应属性，导致保存成功后刷新列表时后端不返回longTermFlag值，前端接收后下拉框清空；修复：1) SQL新增T1.long_term_flag AS longTermField; 2) DTO新增longTermFlag属性
...
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-18 15:02:27 +08:00
37c2377b66
Fix Bug #532 : 【手术管理】点击"查看"或"编辑"按钮弹出 SQL 语法报错
...
根因：getSurgeryScheduleDetail SQL 查询中 cs.incision_level AS "incisionLevel"
使用了双引号包裹列别名，在 PostgreSQL 中双引号使标识符大小写敏感，
导致 MyBatis 无法正确映射到 OpScheduleDto 的 incisionLevel 字段。
修复：移除双引号，改为 cs.incision_level AS incisionLevel。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-17 23:16:00 +08:00
eee65a4517
Fix Bug #470 : 手术项目查询去除MyBatis Plus COUNT开销，改用直接LIMIT查询
...
根因：MyBatis Plus分页拦截器在执行手术项目查询时，先做COUNT全表扫描
(10,102条记录，~4ms)再查数据(~0.3ms)。前端el-transfer不需要精确total，
COUNT查询纯属多余开销。
修复：Mapper返回值改为List，XML添加LIMIT/OFFSET，Service手动构造Page。
数据库层面从~5ms降至~0.3ms。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-17 19:23:24 +08:00
赵云
414b37bfa7
Fix Bug #497 : 【住院医生工作站-检查申请】检查申请列表缺失状态列——动态计算状态修复
...
根因: doc_request_form.status 列在数据库中始终为默认值0，无任何代码更新它，
导致列表所有记录的"申请单状态"始终显示"待签发"。
修复方案:
1. SQL: 用 CASE WHEN EXISTS 从 wor_service_request.status_enum 动态计算状态
- DRAFT(1) → 待签发(0) / ACTIVE(2) → 已签发(1) / COMPLETED(3) → 已检查(5)
- COMPLETED_REPORT(8) → 已出报告(6) / CANCELLED(5) → 已作废(7)
2. 实体: 补全 RequestForm.status 字段完善领域模型
验证: Java编译通过 + XML格式正确 + SQL实测状态值正确区分
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-17 13:18:53 +08:00
赵云
06736e4246
Fix Bug #497 : 【住院医生工作站-检查申请】检查申请列表缺失申请单状态列——全链路验证
...
根因: SQL 使用复杂 CASE + MIN(wsr.org_id) 聚合表达式计算 desc_json,
但 doc_request_form 表已有 status 字段直接存储状态值。
CASE 表达式在聚合场景下不准确且冗余。
修复: 简化 SQL 为直接使用 drf.desc_json 字段,删除 CASE 表达式。
前端列顺序和状态标签已在之前修复中完成。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-17 12:57:20 +08:00
关羽
bd471223a4
Fix Bug #478 : 【住院医生工作站-检验申请】点击"详情"查看检验单时，"发往科室"字段回显异常（显示为"-"）
...
根因：desc_json 中 targetDepartment 存为空字符串，实际执行科室保存在 wor_service_request.org_id 中
修复：在 getRequestForm SQL 中用 CASE 表达式将 org_id 注入 desc_json，当前端已有值时不覆盖
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com >
2026-05-16 15:15:34 +08:00
关羽
ed644c4a91
Fix Bug #497 : 【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑
...
根因：
1. 列位置回归问题 — commit 718e7a90e65f1212noreply@anthropic.com >
2026-05-16 15:11:59 +08:00
