e1cb88e47e
feat(home): 优化首页界面并实现收入统计功能
...
- 添加欢迎区域背景动效和视觉优化
- 实现今日收入统计及同比数据显示
- 重构待办事项和日程的双栏布局
- 修复路由权限检查并添加无权限提示
- 更新快捷功能入口和统计卡片样式
- 集成财务模块收入查询接口
- 添加数据库配置备份文件
2026-06-02 14:38:51 +08:00
wangjian963
cde58cf18f
581 【住院医生站-临床医嘱-手术】手术申请单缺失多项核心业务字段与强拦截逻辑，导致医疗安全制度无法落地且阻断手术室排班闭环
2026-06-02 13:22:09 +08:00
wangjian963
5a970cf492
503
...
【住院发退药】发药明细与发药汇总单数据触发时机不一致，存在业务脱节风险
2026-06-02 10:05:41 +08:00
wangjian963
275e7f5978
597 【住院医生工作站-临床医嘱】临床医嘱需增加“备注”字段支持
2026-06-01 14:41:12 +08:00
wangjian963
76c623ba1d
467
...
[住院医生工作站-检验申请] 列表显示信息不规范：标题术语错误且单据名称未展示具体检验项目
466 [住院医生工作站-检验申请] 申请单界面缺失核心质控字段（申请类型、标本类型、执行时间）及联动逻辑
2026-06-01 14:15:59 +08:00
5c29c0f09e
fix( #613 ): 医生端医嘱列表增加退回原因展示列
...
根因（全链路6环分析）：
- ① 前端/页面 ❌ 医生端医嘱列表无退回原因列 → 无法展示护士填写的退回原因
- ② Controller ❌ 不涉及 — 纯转发层
- ③ Service ❌ getRequestBaseInfo() 未填充 reasonText 字段
- ④ Mapper/XML ❌ UNION ALL 查询未选取 back_reason/reason_text 字段
- ⑤ DB ✅ med_medication_request.back_reason 列已存在（上一次修复已迁移）
- ⑥ 关联模块 ⚠️ wor_service_request.reason_text 已存在但未在查询中暴露
修复：
1. RequestBaseDto.java: 新增 reasonText 字段（映射退回原因）
2. DoctorStationAdviceAppMapper.xml: 5 个 UNION ALL 分支各自选取 reason_text
- med_medication_request → T1.back_reason
- charge item 回补 → T2.back_reason
- device_request（2 处）→ NULL（无退回原因字段）
- wor_service_request → T1.reason_text
3. prescriptionlist.vue: 在诊断列前新增退回原因列
全链路状态流转：
护士端弹窗→输入原因→API传backReason→DB保存→医生端列表展示
↑ 本次修复打通最后一环 ↑
2026-05-29 15:55:55 +08:00
e3c0e700a5
chore: 删除误提交的 .bak 文件
2026-05-29 15:04:11 +08:00
a3378b7fbf
fix: EncounterDiagnosisMapper selectOne() LIMIT 1 防重复数据报错
...
根因：getEncounterDiagnosisByEncounterConDefId 使用 selectOne() 查询，
但 SQL 可能返回多条（同就诊同诊断定义多条记录），导致 MyBatis 抛出
'Expected one result but found 2' 异常。
修复：SQL 增加 LIMIT 1，确保最多返回一条。
2026-05-29 15:04:03 +08:00
wangjian963
c6ac8d1cb1
565 [库房管理-调拨] 调拨单明细中“源仓库库存数量”未正确读取库存值，始终显示为0
...
600 【住院护士站-医嘱执行】数据一致性：医嘱执行成功后，在“已执行”列表中无法查询到该医嘱记录
2026-05-29 13:52:27 +08:00
3997c02564
fix(doctorstation): 修正医嘱备注字段查询错误
...
- 将备注字段来源从 T1.content_json 修改为 T2.content_json
- 确保从正确的表获取医嘱备注信息
- 修复因表关联导致的数据查询不准确问题
2026-05-29 13:25:31 +08:00
7b5c61970a
fix(doctorstation): 修复数据库查询中的SQL语法错误
...
- 移除了med_medication_request查询中多余的逗号
- 移除了wor_device_request查询中多余的逗号
- 修复了wor_service_request查询中字段位置错误的问题
- 确保所有AS别名语法的一致性
- 修复了可能导致数据库查询失败的语法问题
2026-05-29 13:14:54 +08:00
a9ed53a949
refactor(examination): 优化检查申请界面结构和数据传输对象
...
- 移除检查项目套餐明细的冗余代码块
- 修复检查方法套餐明细显示逻辑中的重复条件判断
- 修正界面组件结构层级以改善渲染性能
- 更新仪器管理初始化数据传输对象的注解配置
- 替换 Lombok 注解从 @Data 为 @Getter/@Setter
- 修复数据库映射文件中字段定义的语法错误
- 统一 SQL 查询语句的格式化风格
2026-05-29 11:40:18 +08:00
b98ffaf283
fix(#SQL-UNION): AdviceManageAppMapper UNION 查询列顺序不一致导致类型不匹配
...
根因：
- 第一分支（用药医嘱）的列顺序为 start_time, therapyEnum, sort_number
- 第二/三分支（设备/服务医嘱）的列顺序为 therapyEnum, sort_number, start_time
- UNION 时 PostgreSQL 校验第 30 位列发现 timestamp vs integer 类型冲突
修复：
- 将第一分支的 start_time 移到 therapyEnum 和 sort_number 之后
- 三个分支列顺序现在完全对齐
报错：
UNION types timestamp with time zone and integer cannot be matched
2026-05-29 11:19:32 +08:00
75f38dfd1c
fix(AdviceManageAppMapper): 补充 3 处 SQL 缺失逗号 — UNION ALL 查询中 advice_definition_id 后缺少逗号
...
根因：
- Bug #613 修复时在 AdviceManageAppMapper.xml 中新增了 advice_definition_id 字段
- 3 处 UNION ALL 子查询中该字段后缺少逗号，导致 SQL 语法错误
- Spring 启动时报 PersistenceException，系统无法启动
修复：
- 第 1 子查询: medication_id AS advice_definition_id 后补逗号
- 第 2 子查询: device_def_id AS advice_definition_id 后补逗号
- 第 3 子查询: activity_id AS advice_definition_id 后补逗号
2026-05-29 11:08:02 +08:00
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
