移除else分支中对orgId和positionName的条件判断，确保诊疗类医嘱的执行科室
始终使用患者就诊科室，不被诊疗目录配置的positionId覆盖。
之前的if (!orgId)条件导致目录已配置positionId时不会被覆盖，
若目录配置的ID不在机构树中则显示原始ID。
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
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:17 +08:00
2 changed files with 10 additions and 12 deletions
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
