wangyizhe/his
1
3
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
2,066 Commits 26 Branches 3 Tags
d9ad63397bd7d5ae46764ff658134a0cac3bb20a
Commit Graph

618 Commits

Author SHA1 Message Date
赵云
fd9309f125 Fix Bug #494: 住院医生工作站-检查申请：申请单名称显示为通用名称，未展示具体检查项目名称 
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 15:19:00 +08:00
关羽
a282234bb0 Fix Bug #497: 【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑 
根因分析：
1. SQL CASE 映射不完整：status_enum=3(COMPLETED) 直接映射为应用状态 4(已接收)，
   跳过了 2(已校对) 和 3(待接收)
2. status_enum=8 在数据中存在但枚举类中缺失定义
3. 前端已完整实现状态列和交互逻辑，问题在后端返回的状态值不正确

修复内容：
- RequestFormManageAppMapper.xml: 重构 SQL CASE 语句
  - status_enum=3 + performer_check_id 有值 → 2(已校对)，利用护士校对标记区分
  - status_enum=3 + performer_check_id 为空 → 4(已接收)
  - status_enum=4(ON_HOLD) → 3(待接收)
  - status_enum=5/6/7 → 7(已作废)
  - status_enum=8 → 6(已出报告)
- RequestStatus.java: 补充 COMPLETED_REPORT(8) 枚举值

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 14:26:38 +08:00
关羽
0bd1277307 Fix Bug #495: 【医嘱闭环】已校对医嘱无法流转至"医嘱执行"界面，导致费用无法提交执行 
Root cause: In getInpatientAdvicePage(), encounterIds and exeStatus were nullified
before buildQueryWrapper to prevent auto-generated SQL conditions, but requestStatus
was NOT nullified. HisQueryUtils.buildQueryWrapper uses reflection to add eq conditions
for ALL non-null fields, so requestStatus: 3 became an extra SQL filter
"AND request_status = 3" that was not intended for the 医嘱执行 page.

The 医嘱执行 page uses exeStatus (not requestStatus) for execution state filtering.
The SQL already handles verified/unverified order filtering via a CASE condition
on status_enum and performer_check_id. The requestStatus parameter is only meant
for frontend tab selection and should not be used as a SQL filter here.

Fix: Nullify requestStatus before buildQueryWrapper, same as encounterIds/exeStatus.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 14:14:56 +08:00
赵云
e0e4c2bcc6 Fix Bug #471: 手术管理-门诊手术安排：手术申请查询结果中混入住院检验申请单数据（脏数据） 
根因：门诊手术安排查询弹窗调用 /reg-doctorstation/request-form/get-surgery-page 接口，
SQL 过滤 type_code = '24'，但实际手术申请单的 type_code 存储为 'SURGERY'（非'24'），
导致查询返回0条手术记录。同时检验申请单(type_code='22')使用 PAR 前缀处方号，在缺少
type_code 有效过滤时可能混入结果。

修复：将 SQL 过滤器从 type_code = #{typeCode} 改为 type_code IN (#{typeCode}, 'SURGERY')，
兼容两种 type_code 值，确保只返回手术申请单，排除检验/检查申请单数据。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 13:13:47 +08:00
关羽
12382503f4 Fix Bug #489: 【医嘱闭环】医生站签发单条长期药品医嘱，护士校对界面生成重复（两条）待校对记录 
Root cause: The SQL query in AdviceProcessAppMapper.xml used a plain LEFT JOIN with
med_medication_dispense on med_req_id. When a single medication request had multiple
dispense records (e.g., from repeated executions or summary operations), the JOIN
produced multiple rows per request — up to 222 rows for one request. SELECT DISTINCT
could not deduplicate because dispense_status values differed across rows.

Fix: Replace the plain LEFT JOIN with LEFT JOIN LATERAL (subquery ORDER BY create_time
DESC LIMIT 1) to fetch only the most recent dispense record per medication request.
This ensures exactly one row per request regardless of how many dispense records exist.

Verified: SQL query now returns 0 duplicate rows across all medication requests.
 2026-05-14 13:10:51 +08:00
荀彧
feb033b857 Fix Bug #462: [目录管理-诊疗目录] 编辑弹窗中"所需标本"下拉框数据加载失败，显示为"无数据" Fix: selectDictDataByType方法移除Redis缓存读取逻辑，直接查询数据库避免缓存为空数据导致前端下拉框无数据 2026-05-14 12:15:47 +08:00
wangjian963
79cce458ee Merge remote-tracking branch 'origin/develop' into develop 
# Conflicts:
#	openhis-server-new/openhis-application/src/main/java/com/openhis/web/clinicalmanage/dto/OpScheduleDto.java
 2026-05-14 12:01:33 +08:00
wangjian963
1140912f3a Fix Bug #437: 【门诊手术计费】保存签章TOCTOU竞态致重复提交，且耗材计费项目缺失/重复、手术单号未关联 
Fix: 频次总量计算改用字典store动态读取，el-input-number新增@input实时计算
 2026-05-14 12:00:18 +08:00
yangkexiang
250f9ce258 Merge remote-tracking branch 'origin/develop' into develop 2026-05-14 11:48:42 +08:00
yangkexiang
0d6f891b47 fix bug434:门诊手术安排：编辑弹窗中“切口类型”字段未正确回显数据 
bug426:门诊医生站-检查开立：已选择列表应支持树形展开，显示套餐明细
bug439:领用出库：选择领用药品后“总库存数量”列数据未显示
bug457:门诊收费：已签发的手术类医嘱在门诊收费列表中不显示项目名称
 2026-05-14 11:48:22 +08:00
Ranyunqiao
eab0119c19 bug362 413 498 504 507 2026-05-14 11:47:18 +08:00
关羽
d43a06c343 Fix Bug #475: 【住院医生工作站】开立检查申请单报错后仍生成申请记录 
根因：saveRequestForm方法的预校验循环和主循环分别独立查询activityOrganizationConfig获取positionId，
存在数据不一致风险——预校验通过但主循环中positionId查找失败时，RequestForm已被保存导致脏数据。

修复：将预校验循环中查到的positionId缓存到Map中，主循环直接使用缓存结果，
避免重复查询导致的数据不一致问题。确保所有校验通过后再执行任何数据库操作。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 11:15:20 +08:00
赵云
444397e868 Fix Bug #435: 门诊手术安排：编辑弹窗中"费用类别"字段数据未回显 
根因：OpCreateScheduleDto 缺少 feeType 字段，导致新建手术安排时 BeanUtils.copyProperties 无法复制该字段，
保存到数据库后 fee_type 为空字符串/null，编辑时详情查询返回 null 导致前端不显示。

修复：在 OpCreateScheduleDto 新增 feeType 字段，使创建流程完整传递费用类别数据。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 10:28:48 +08:00
赵云
1a770ca0ee Fix Bug #402: 住院医生站诊断录入：点击保存诊断后，列表出现重复记录且部分条目元数据缺失 
根因分析：
1. 前端保存按钮无防重复点击保护，连续点击会发送多个请求
2. 保存成功后前端使用本地排序数据更新，未从服务器重新加载，导致前后端数据不一致
3. 后端 saveDoctorDiagnosis 保存后未回写 encounterDiagnosisId，后续保存无法正确更新已有记录

修复方案：
- 前端：在 handleSaveDiagnosis 入口增加 isSaving 守卫，防止重复提交
- 前端：保存成功后调用 getList() 从服务器重新加载数据，确保前后端一致
- 后端：saveOrUpdate 后回写 encounterDiagnosisId 到返回参数，前端可跟踪记录ID

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 09:11:12 +08:00
关羽
ba9c18b6a4 Fix Bug #443: 手术计费：点击"签发"耗材时异常报错 
根因分析：getRequestBaseInfo SQL查询的UNION 2（门诊术中计费耗材）缺少generate_source_enum过滤条件，导致手术计费弹窗显示所有来源的耗材（包括医生站开立的项目）。当用户尝试签发非手术计费创建的耗材时，后端handDevice处理失败。

修复内容：
1. 后端SQL：在UNION 2的WHERE子句中添加generate_source_enum过滤，确保手术计费弹窗仅显示手术计费来源的耗材
2. 前端JS：handleSave函数补充.then/.catch错误处理，避免显示笼统的"后端程序异常"，改为展示具体错误信息

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 09:03:38 +08:00
荀彧
164ac604fb Fix Bug #401: 门诊完诊审计日志错误：div_log 表中 pool_id 与 slot_id 存值与设计规范不符 
根因：completeEncounter 方法中先将队列状态更新为 COMPLETED，再用内存中
的 queueItem.getStatus() 判断是否已完诊，导致 queueAlreadyCompleted 始终为 true，
div_log 审计日志永远不会被写入。

修复：在更新队列状态之前记录原始完成状态（queueWasAlreadyCompleted），
用该值判断是否需要写入 div_log，确保完诊时正确生成审计日志。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 08:52:04 +08:00
关羽
49889e9140 Fix Bug #507: [住院护士站-住院记账-补费] 项目单位未获取、执行科室显示内码且缺乏默认/模糊搜索逻辑 
后端SQL修复: DoctorStationAdviceAppMapper.xml 中诊疗项 min_unit_code 硬编码为空字符串,
改为使用 permitted_unit_code,使前端单位下拉框有可用选项

前端修复:
1. api.js getOrgList 添加 pageSize:100 参数,确保获取足够科室数据
2. FeeDialog.vue loadDepartmentOptions 增加回退逻辑:当树形结构无children时使用扁平records

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 06:13:56 +08:00
荀彧
02f2a14178 Fix Bug #497: 【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑 
根因：SQL 查询使用 CASE MIN(wsr.status_enum) 计算状态，但聚合函数 MIN() 出现在 WHERE 子句中，
PostgreSQL 语法错误导致状态筛选时查询失败。且计算状态仅映射 5 种值（缺少"待接收"=3、"已出报告"=6）。

修复：改为直接使用 doc_request_form.status 字段（数据库已存在该列），
SELECT 和 WHERE 均使用 drf.status，支持完整 0-7 状态流转。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 05:43:07 +08:00
赵云
6dc9788d8c Fix Bug #487: 【临床医嘱】诊疗类医嘱签发后，列表状态未实时刷新为"已签发" 
根因分析：诊疗类(活动)医嘱签发时，后端handService()的批量状态更新
未区分签发/保存场景，导致statusEnum字段在签发时可能未被正确更新为
ACTIVE(2)；前端依赖后端刷新，缺乏乐观更新机制。

修复方案：
- 前端：签发成功后立即将saveList中对应医嘱的statusEnum设为2（乐观更新），
  再执行getListInfo从后端刷新
- 后端：handService()中分离签发/保存的批量更新逻辑，签发时显式设置
  statusEnum=ACTIVE、authoredTime和signCode，并添加日志

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 04:44:10 +08:00
关羽
6907c7dbc8 Fix Bug #481: [住院护士站-医嘱执行] 药品库存充足但执行时提示库存不足 
根因: AdviceUtils.checkExeMedInventory() 中硬编码 performLocation == locationId 的匹配条件，
当医嘱的 performLocation 指向的药房没有该药品库存时（库存实际在其他药房），匹配失败导致"库存不足"错误。

修复策略: 采用两步匹配法 -
1. 先按 performLocation 匹配指定药房的库存（添加 null 容错）
2. 若指定药房无匹配，则放宽条件跨所有药房聚合库存

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 03:14:30 +08:00
关羽
56b8d0e98d Fix Bug #475: 【住院医生工作站】开立检查申请单报错"请先配置当前时间段的执行科室"后，系统仍生成申请记录 
- 将requestFormId判空改为requestFormId != null && requestFormId != 0L，防止前端空字符串反序列化为0L误入编辑场景
- 在循环中逐个校验activityList中的项目是否都配置了执行科室，将所有校验前置到任何数据库操作之前，避免部分通过后在save中途抛异常
- 统一使用isEdit标志变量替代重复的null检查

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 02:12:06 +08:00
关羽
55eba1a0b1 Fix Bug #443: 手术计费：点击"签发"耗材时异常报错 
**根因分析**：
前端 handleSave 签发时，仅从 contentJson 解析数据后发送，缺少 encounterId、patientId、locationId 等关键字段。这些字段在 API 响应顶层（不在 contentJson 中），导致后端签发时字段为空。

**修复方案**：
- 前端：在 handleSave 的 saveList 映射中补充 encounterId、patientId、locationId（对应 positionId）、adviceType 等顶层关键字段
- 后端：handDevice 中 locationId 为空时，优先查询已有 DeviceRequest 的 performLocation 作为回退，避免覆盖为默认科室
 2026-05-14 00:11:29 +08:00
关羽
1525740ab5 Fix Bug #435: 门诊手术安排编辑弹窗费用类别字段数据未回显 
根因：op_schedule 表缺少 fee_type 字段，导致编辑时无法从数据库读取费用类别。
- 新增 fee_type 列到 op_schedule 表并回填历史数据
- OpSchedule 实体类新增 feeType 字段
- 详情查询SQL改为直接从 op_schedule.fee_type 读取，替代原脆弱的 fin_contract 关联链

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-14 00:06:34 +08:00
关羽
96102e8b64 Fix Bug #401: div_log 表中 pool_id 与 slot_id 存值不符 
根因分析：
1. 候选池API（getCurrentDayEncounter）未返回 poolId/slotId 字段，导致护士从候选池
   添加患者到队列时 poolId/slotId 始终为 null
2. triage_queue_item 中 pool_id/slot_id 为 null 后，完诊时 div_log 也写入 null 值
3. 医生站完诊和护士站完诊各自独立写入 div_log，导致同一患者产生两条 COMPLETE 记录

修复方案：
1. CurrentDayEncounterTencentDto 新增 poolId/slotId 字段
2. TencentAppMapper.xml 通过 encounter.order_id → order_main.slot_id →
   adm_schedule_slot.pool_id 链路获取正确的号源信息
3. DoctorStationMainAppServiceImpl 增加防重复逻辑：队列项已为 COMPLETED 状态时
   不再重复写入 div_log（说明护士站已处理过）

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 23:27:08 +08:00
关羽
49df72121f Fix Bug #412: 门诊医生站传染病报告卡保存失败，提示报错 
后端 saveInfectiousDiseaseReport 中 getCardNo().trim() 存在空指针异常风险，
增加 cardNo 空值校验避免 NPE 导致保存失败。
前端 buildSubmitData 中 diseaseCode 在 selectedClassA/B/C 为空时会变成 null，
增加从 selectedDiseases 兜底取值逻辑确保 diseaseCode 始终有值。
 2026-05-13 23:18:53 +08:00
关羽
e5cd7bd792 Fix Bug #497: 【住院医生工作站-检查申请】检查申请列表缺失"申请单状态"列及全流程闭环状态流转逻辑 
根因：/reg-doctorstation/request-form/get-check 接口只接收 encounterId 参数，前端传递的 startDate/endDate/status 筛选参数被后端完全忽略，导致日期范围和状态筛选不生效。
修复：Controller 增加 startDate、endDate、status、keyword 参数，透传至已有的重载 Service 方法（SQL 和 DTO 中 status 字段已存在）。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 20:08:41 +08:00
赵云
dc9f47c534 Fix Bug #489: 【医嘱闭环】医生站签发单条长期药品医嘱，护士校对界面生成重复（两条）待校对记录 
根因分析：
1. SQL查询JOIN倍增：selectInpatientAdvicePage 中多个LEFT JOIN（如adm_encounter_location、
   adm_encounter_participant、med_medication）可能产生重复行，外层查询无DISTINCT去重
2. 防重复逻辑缺陷：handMedication() 中仅对 DbOpType.INSERT 进行去重，若同一请求中包含
   INSERT 和 UPDATE（编辑后签发的医嘱），两者uniqueKey相同但UPDATE不受去重限制，
   导致 UPDATE 修改旧记录 + INSERT 创建新记录 = 两条数据

修复方案：
1. 在AdviceProcessAppMapper.xml的UNION两侧子查询中添加SELECT DISTINCT，防止JOIN倍增
2. 在AdviceManageAppServiceImpl.java中移除dbOpType限制，对所有医嘱（INSERT+UPDATE）
   统一按uniqueKey去重，确保同一业务医嘱只处理一次

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 19:19:47 +08:00
赵云
0f85e95d24 Fix Bug #475: 【住院医生工作站】开立检查申请单报错"请先配置当前时间段的执行科室"后，系统仍生成申请记录 
根因：saveRequestForm 方法中，执行科室配置校验（activityOrganizationConfig.isEmpty）位于 saveOrUpdate(requestForm) 之后，导致即使校验失败抛出异常，RequestForm 记录已被写入数据库。
修复：将校验逻辑移至方法开头，在任何数据库操作之前执行，确保校验失败时不产生任何脏数据。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 18:13:10 +08:00
荀彧
2d7228ca5d Fix Bug #470: 住院医生工作站-手术申请单加载手术项目耗时过长，影响医生开单效率 
性能优化:
1. 数据库层: 为 wor_activity_definition 表添加手术项目专用覆盖索引 (idx_wor_activity_def_surgery_covering)
   - 查询从 Index Scan + Filter 改为 Index Only Scan
   - 执行时间从 4.6ms 降至 0.67ms (约7倍提升)
2. Java服务层: 过滤 chargeItemDefinitionIdList 中的 null 值
   - 手术项目无定价定义,原逻辑会将 null 传入批量查询造成浪费
   - 同时跳过 childCharge 批次定价查询(仅药品/耗材需要)

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 18:10:44 +08:00
关羽
a447e55d43 Fix Bug #471: 手术管理-门诊手术安排：手术申请查询结果中混入住院检验申请单数据（脏数据） 
根因：getSurgeryRequestFormPage 接口构建 RequestFormDto 时 typeCode 传了 null，
导致 SQL 中 type_code 过滤条件被跳过，查出所有申请单（包括 typeCode=22 的住院检验申请单）。
修复：传入 ActivityDefCategory.PROCEDURE.getCode()（值为"24"）作为 typeCode，
确保只查询手术类型的申请单。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 18:06:09 +08:00
xiaoming
1be0dc2417 bug515 [住院医生站-临床医嘱] 点击“签发”检验医嘱后系统陷入死循环，Loading无法消失 后端advice_type映射错误 2026-05-13 17:49:27 +08:00
关羽
480663f716 Fix Bug #454: 门诊医生站-医嘱页签：删除"待签发"状态的检验项目时，错误触发"执行科室"校验导致删除失败 
在handService的执行科室校验中增加dbOpType DELETE跳过条件，作为BugFix#454过滤器的第二层防御。
同时修复handMedication和handService中重复声明requestId变量导致的编译错误。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 16:12:38 +08:00
关羽
cc484d5f10 Fix Bug #442: 手术计费：点击"删除"待签发耗材时异常报错，导致操作失败 
根因：手术计费场景中"待签发"耗材的 requestId 来自 adm_charge_item.service_id，
当 service_id 为 null 或对应的 wor_device_request 记录不存在时，
后端 removeById(null) 或 removeById(不存在ID) 会抛出异常导致删除失败。

修复策略：
- 前端(prescriptionlist.vue): handleDelete 中增加 requestId 有效性校验，
  过滤掉 requestId 为 null/undefined/空的项，避免发送无效删除请求
- 后端(DoctorStationAdviceAppServiceImpl.java): handMedication/handDevice/handService
  三个删除路径增加 requestId null check，跳过无效记录而非抛出异常

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 15:16:45 +08:00
关羽
fc1ed6c4ce Fix Bug #401: 门诊完诊审计日志错误：div_log 表中 pool_id 与 slot_id 存值与设计规范不符 
根因：DoctorStationMainAppServiceImpl.completeEncounter() 中获取 pool_id/slot_id 的逻辑有两处缺陷：
1. 当 queueItem 存在但 poolId 或 slotId 为 null 时，else if 分支因 queueItem != null 而跳过，
   导致未进入回退链路，最终 divPoolId 和 divSlotId 均为 null。
   修复：将 else if 拆为独立的 if 判断，确保 queueItem 值缺失时能正确回退。
2. 回退路径中先将 order.getSlotId() 赋给 divSlotId，再查询 ScheduleSlot 获取 poolId。
   若 Slot 查询失败（返回 null），则 divSlotId 有值但 divPoolId 为 null，产生不完整审计记录。
   修复：先查 Slot，成功后同时用 slot.getId() 和 slot.getPoolId() 赋值，保证数据一致性。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 14:07:15 +08:00
赵云
818564f5ba Fix Bug #400: 门诊医生站点击【完诊】后，triage_queue_item 表 status 字段未按规范更新为 30 
根因分析：
triage_queue_item.status 字段在 DDL 中定义为 VARCHAR(50)，但 Java 实体
TriageQueueItem.status 为 Integer 类型，应用层使用 TriageQueueStatus 枚举值
(0/10/20/30/40) 进行读写。数据类型不匹配导致 MyBatis-Plus 无法正确映射 status 字段，
完诊时使用 LambdaUpdateWrapper 更新 status=30 操作失败。

修复方案：
1. 修正 DDL：将 status 字段类型从 VARCHAR(50) 改为 INTEGER
2. 新增迁移 SQL：修改已有数据库表的 status 字段类型为 INTEGER

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 14:00:45 +08:00
Ranyunqiao
b7df71fd0b bug 362 428 436 2026-05-13 12:59:03 +08:00
陈琳
5bc8a8e517 Fix Bug #496: 【住院医生工作站-检查申请】检查申请列表字段命名不规范及单号生成规则不符合医疗行业标准 
1. 前端列标题：处方号 → 申请单号（表格列 + 详情弹窗）
2. 后端单号生成：原用 PAR 处方号前缀 → 改为 JCZ + yyMMdd + 5位顺序号
3. 新增 AssignSeqEnum.CHECK_APPLY_NO 枚举项（JCZ 前缀）

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 11:03:32 +08:00
xiaoming
0264fa9d58 Merge branch 'develop' of https://gitea.gentronhealth.com/wangyizhe/his into develop 2026-05-13 10:57:20 +08:00
xiaoming
cd12dd7a22 bug471 手术管理-门诊手术安排：手术申请查询结果中混入住院检验申请单数据（脏数据） 2026-05-13 10:45:33 +08:00
关羽
bfddf87b2c Fix Bug #496: 【住院医生工作站-检查申请】检查申请列表字段命名不规范及单号生成规则不符合医疗行业标准 
1. 前端 examineApplication.vue：列表表头和详情弹窗中"处方号"改为"申请单号"
2. 后端 RequestFormManageAppServiceImpl：检查申请单单号生成规则由 PAR+流水号 改为 JCZ+yyMMdd+5位顺序号（如：JCZ26051300001），其他类型申请单保持原有PAR规则不变

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 10:42:39 +08:00
关羽
84499d4ec1 Fix Bug #400: 门诊医生站点击【完诊】后，triage_queue_item 表 status 字段未按规范更新为 30 
根因：完诊时使用 triageQueueItemService.updateById(queueItem) 更新队列状态，
依赖 MyBatis Plus 的实体级更新策略，可能因字段级更新策略导致 status 字段未实际写入数据库。

修复策略：改用 LambdaUpdateWrapper 直接生成 UPDATE SQL，明确指定 SET status=30，
绕过实体级更新策略，确保 status 字段必定写入数据库。同时增加更新失败日志。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 10:37:02 +08:00
荀彧
01c5b62024 Fix Bug #401: 门诊完诊审计日志错误：div_log 表中 pool_id 与 slot_id 存值与设计规范不符 
调整完诊时 div_log 的 pool_id/slot_id 获取优先级：优先使用 triage_queue_item
（挂号时录入的号源信息，为权威来源），队列项不存在或值缺失时回退使用
encounter → order → slot → pool 链路

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 10:15:20 +08:00
张飞
3590a18adc Fix Bug #362: 住院护士站：入出转管理双击查看详情时，"入科时间"字段显示当前系统时间而非实际入科时间 
在 selectAdmissionPatientInfo SQL 中，startTime 原取自 bed.start_time（床位级别的位置记录），
当该 LEFT JOIN 无匹配记录时返回 NULL，前端 fallback 到当前系统时间。
改为 COALESCE(bed.start_time, ae.start_time)，无床位记录时回退到 encounter 的入院时间。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 01:03:24 +08:00
刘备
5539d4cc03 Fix Bug #489: 【医嘱闭环】医生站签发单条长期药品医嘱，护士校对界面生成重复（两条）待校对记录 
在住院医生站签发流程的 handMedication() 方法中增加去重逻辑，
与门诊医生站保持一致，使用 patientId+encounterId+adviceDefinitionId+dose+methodCode+rateCode
作为唯一键，防止前端重复提交导致数据库产生重复医嘱记录。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 00:13:32 +08:00
刘备
982e905990 Fix Bug #491: 【执行科室配置】保存配置时系统报错 - 修复Organization.getName()空指针异常 
根因分析：
1. organizationLocationInit() 中 Organization.getName() 未做空值过滤，若数据库存在name为null的科室记录会NPE
2. addOrEditOrgLoc() 中 activityDefinitionMapper.selectById().getName() 未对selectById返回null做防护
3. addOrEditOrgLoc() 缺少organizationId前置校验，空值传入可能导致后续流程异常

修复内容：
- 第74行：stream中增加 .filter(organization -> organization != null && organization.getName() != null)
- 第136-138行：增加organizationId为null时的校验，返回友好错误提示
- 第145-147行：将activityDefinitionMapper.selectById结果先赋值再判空，避免NPE

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 00:12:42 +08:00
刘备
0600bbecbc Fix Bug #468: [住院医生工作站-检验申请] 列表页缺失【单据状态】列，无法闭环管理检验医嘱执行进度 
前后端完整链路修复：
- 后端 Mapper: LEFT JOIN wor_service_request 表，通过 CASE MIN(status_enum) 映射单据状态
- 后端 Mapper: 新增状态筛选和关键字搜索（申请单号/检验项目模糊匹配）
- 后端 Service/Controller: 新增 status 和 keyword 参数传递
- 前端 Vue: 列表页添加【单据状态】列，绑定 status 字段
- 前端 Vue: 移除中间状态选项（已采集/已收样），与后端 CASE 映射保持一致

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-13 00:02:47 +08:00
荀彧
d38efd15b3 Fix Bug #457: 门诊收费：已签发的手术类医嘱在门诊收费列表中不显示项目名称 
根因分析：门诊医生站处方列表查询（DoctorStationAdviceAppMapper.xml）中，
手术类医嘱（category_enum=4）的 advice_table_name 固定返回 'wor_activity_definition'，
而非 'cli_surgery'。当医生通过"签发"按钮处理手术医嘱时，handService() 据此创建
ChargeItem，导致 product_table = 'wor_activity_definition'，但 product_id 实际指向
cli_surgery 表中的手术记录。

门诊收费SQL查询的CASE语句仅匹配 product_table = 'cli_surgery' 的手术项，
因此这些手术医嘱无法匹配，item_name 返回 NULL。

修复方案：在 selectEncounterPatientPrescription 和 selectEncounterPatientPrescriptionWithPrice
的 item_name CASE 表达式中新增兜底分支：
  WHEN context_enum = #{activity} AND service_table = 'wor_service_request'
  THEN COALESCE(T9.surgery_name, wsr.content_json->>'surgeryName',
                wsr.content_json->>'adviceName', T2."name")

按优先级回退获取手术名称：cli_surgery表 → content_json手术名称 → content_json医嘱名称 → 诊疗定义名称

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-12 23:34:36 +08:00
华佗
4e71b861ab Fix Bug #442: 手术计费：点击"删除"待签发耗材时异常报错，导致操作失败 
根因：DoctorStationAdviceAppMapper.xml 中 getRequestBaseInfo SQL 的第二个 UNION 查询（手术计费耗材从 adm_charge_item 关联 wor_device_request）中，biz_request_flag 和 requester_id 使用了 CI.enterer_id（计费录入人），而非 DR.requester_id（设备申请创建人）。当录入人与当前操作人不一致时，biz_request_flag 为 '0'，导致删除操作被后端拒绝。

修复：将 CI.enterer_id 改为 COALESCE(DR.requester_id, CI.enterer_id)，优先使用 DeviceRequest 的 requester_id，确保 biz_request_flag 基于正确的创建人计算。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-12 23:08:08 +08:00
Ranyunqiao
460890e3c2 413 460 513 514 2026-05-12 17:27:25 +08:00
赵云
fbbe0e9248 Fix Bug #470: 住院医生工作站-手术申请单加载手术项目耗时过长，影响医生开单效率 
根因：getAdviceBaseInfo 后端接口在查询手术项目时，仍会执行与手术无关的库存查询
（getAdviceInventory）、全表扫描待发放记录（getAdviceDraftInventory）以及药房科室
配置查询（getMedLocationConfig），其中 getAdviceDraftInventory 对
med_medication_dispense 和 wor_device_dispense 做全表扫描，无任何过滤条件，
导致手术/诊疗场景下的额外数据库开销。

修复：在 DoctorStationAdviceAppServiceImpl.getAdviceBaseInfo() 中增加类型判断，
当 adviceTypes 不包含药品(1)或耗材(2)时跳过所有库存相关查询，因为这些查询对手术/
诊疗(3,6)项目无意义，且下游代码仅在药品/耗材处理分支中使用这些变量。

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
 2026-05-12 17:22:23 +08:00