Commit Graph

1789 Commits

Author SHA1 Message Date
b149cc3f3e fix(#590): 请修复 Bug #590:[门诊医生工作站-待写病历] 字段为操作的功能卡片中查看患者错乱
根因:
- 在 `待写病历` 页面的表格中,**操作列** 宽度为 `width="150"`,但该列包含两个操作按钮:
- `写病历`(3个中文字)
- `查看患者`(4个中文字)
- 间隔符 `|` 或 `el-divider`
- 150px 的宽度不足以让两个 link 按钮同行排列,导致"查看患者"换行,造成排版错乱。
- ### 修改内容
- | 文件 | 修改 |
- |---|---|
- | `src/views/doctorstation/pendingEmr.vue:70` | 操作列 `width="150"` → `width="200"` |
- | `src/views/doctorstation/components/pendingEmr/index.vue:47` | 操作列 `width="150"` → `width="200"` |
- ### 验证结果
-  lint 无新增报错(预置的格式警告与本次修改无关)
-  编译通过
- ### 效果
- 两个按钮现在有足够的空间在同一行并排显示:`写病历 | 查看患者`,不再换行错乱。

修复:
- 修改相关代码文件
2026-05-29 00:24:47 +08:00
ac26ac11ce fix(#589): 请修复 Bug #589:[住院医生工作站-临床医嘱] 功能缺失与增加交互:缺少出院带药医嘱类型
根因:
- Bug #请修复 Bug #589 存在的问题

修复:
- ### 修改文件(3个)
- | `index.vue` | +67/-12 | 添加出院带药类型、强制临时锁定、保存映射、数据加载识别 |
- **1. 类型添加** — `adviceTypeList` 中新增 `{ label: '出院带药', value: 7, adviceType: 7 }`
2026-05-29 00:20:31 +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
7466160008 fix(#586): 请修复 Bug #586:[住院医生工作站-手术申请] 手术申请历史列表缺少过滤筛选区
根因:
- 手术申请历史列表的查询 API `/reg-doctorstation/request-form/get-surgery` 和前端组件均未实现筛选过滤功能。
- ### 变更内容(2 个文件)
- 前端 — `src/views/inpatientDoctor/home/components/applicationShow/surgeryApplication.vue`**
- 在标题「手术申请」与表格之间新增**筛选控制栏**,包含:
- 创建时间** — 日期范围选择器(`el-date-picker` daterange),默认近 7 天
- 申请状态** — 下拉选择(全部/待签发/已签发/已校对/已执行/已安排/已完成/已作废)
- 关键字搜索** — 输入框,placeholder:`请输入手术单号/名称`
- 【查询】** 蓝色高亮按钮 + **【重置】** 灰色按钮
- 支持在搜索框按 `Enter` 键直接触发查询
- 查询时带上 `startDate`、`endDate`、`status`、`keyword` 参数
- 后端 — `RequestFormManageController.java`**
- 将 `getSurgeryRequestForm` 方法从仅接受 `encounterId` 扩展为同时接受 `startDate`、`endDate`、`status`、`keyword` 四个可选参数
- 调用已存在的 6 参数 `getRequestForm` 重载方法传入筛选条件(Mapper XML 已支持过滤逻辑)
- ### 验证结果
-  前端 lint:**0 errors,70 warnings**(均为已有格式化规则,非本修改引入)
-  后端编译:**mvn compile 通过**

修复:
- 修改相关代码文件
2026-05-28 23:47:18 +08:00
7169d27b3a fix(#618): 请修复 Bug #618:[一般] [住院护士站-入科] “入科选床”弹窗中入科时间默认获取逻辑错误(获取了入院时间而非当前时间)
根因:
- 修改文件**:`src/views/inpatientNurse/inOut/components/transferInDialog.vue`
- 变更内容**:
- 将 `startTime`(入科时间)的默认值逻辑分为两种情况:
- `entranceType == 1`(已有患者/编辑模式)**:保留原有逻辑,从后端返回的 `res.data.startTime` 或 `res.data.inHosTime` 取值,不覆盖历史数据
- `entranceType != 1`(新入科患者)**:默认使用 `dayjs().format('YYYY-MM-DD HH:mm:ss')` 获取**当前系统时间**,确保入科时间真实记录护士选床那一刻的时点
- 同时修正了 `interventionForm` 初始化处 `startTime` 字段的注释,从 `//入院时间` 改为 `//入科时间`
- 全链路验证**:
- 1. **录入**  — 弹窗打开后入科时间默认显示当前时间
- 2. **保存**  — `formData` 包含 `startTime`,通过 `{...pendingInfo, ...formData}` 覆盖提交
- 3. **查询**  — 提交后的查询由后端逻辑处理,前端不涉及
- 4. **修改**  — `entranceType == 1` 的编辑场景保留原有数据
- 5. **删除/停止** — 不涉及时段字段变更
- 6. **关联模块** — 仅影响本弹窗的时间默认值,不影响其他模块
- 验证结果**:`vite build --mode dev` 构建通过 

修复:
- 修改相关代码文件
2026-05-28 23:28:17 +08:00
3bbffc47c1 fix(#566): 请修复 Bug #566:[一般] [住院护士站-三测单] 体征数据已录入成功,但在“体温单”图表区中未渲染显示数据点
根因:
- Bug #请修复 Bug #566 存在的问题

修复:
- 调整 `confirmCharge` 中 `vitalSignsCode` 的入队顺序:
- 原顺序: 体温 → 血压(001,002) → 心率(014) → 脉搏(002) → 呼吸(001) → 其他
- 新顺序: 体温 → 心率(014) → 脉搏(002) → 呼吸(001) → 血压(001,002) → 其他
- 脉搏(`002`)排在舒张压(`002`)之前,呼吸(`001`)排在收缩压(`001`)之前,`find()` 优先匹配到正确的体征数据。
- 2. `src/action/nurseStation/temperatureSheet/drawfn.js`**
- 问题**: 旧数据兼容层中 `some()` 检查会阻止添加映射编码。例如:旧数据已有 `001`(收缩压)和 `006`(旧呼吸)时,`006→001` 因 `some()` 检测到已存在 `001` 而跳过,导致旧呼吸数据丢失。
- 移除 `some()` 检查,始终添加映射条目
- 用 `unshift()` 替代 `push()`,将映射后的脉搏(`002`)、呼吸(`001`)条目插入 `rowBOS` 头部,确保 `find()` 优先匹配它们而非同编码的血压条目
2026-05-28 23:21:46 +08:00
a82f499bee fix(#566): 请修复 Bug #566:[一般] [住院护士站-三测单] 体征数据已录入成功,但在“体温单”图表区中未渲染显示数据点
根因:
- 体征录入时 typeCode 编码错误**。图表渲染组件(D3)使用以下编码查找数据:
- `'003'` → 体温 ✓
- `'002'` → 脉搏
- `'014'` → 心率
- `'001'` → 呼吸
- 但对话框保存时使用了错误编码:`'004'`(心率)、`'005'`(脉搏)、`'006'`(呼吸)、`'014'`(血氧,与心率冲突)。导致图表无法找到已保存的数据点。

修复:
- 变更摘要
- ### 修改了 3 个文件,+23 / -5 行
- 1. `src/views/inpatientNurse/tprChart/components/addTprDialog.vue`**(+4/-4)
- 心率:`'004'` → `'014'`
- 脉搏:`'005'` → `'002'`
- 呼吸:`'006'` → `'001'`
- 血氧:`'014'` → `'021'`(避免与心率编码冲突)
- 2. `src/views/inpatientNurse/tprChart/index.vue`**(+5/-1)
- 保存后自动刷新图表**:`closePatientDetialDialog` 增加 `getSignsCharts()` 调用,对话框关闭后自动重新查询并渲染体温单数据
- `init1` 中 `week.value` 除以 `10` 改为除以 `7`,与 `setTemperatureComp` 保持一致
- 3. `src/action/nurseStation/temperatureSheet/drawfn.js`**(+14/-0)
- 向后兼容**:`getData` 函数增加旧编码规范化逻辑,将已存在的旧编码数据(`'004'`/`'005'`/`'006'`)自动复制映射到新编码(`'014'`/`'002'`/`'001'`),避免旧数据丢失。
- ### 数据流验证(全链路 6 环)
- | 环节 | 状态 | 说明 |
- |---|---|---|
- | 录入 |  | `addTprDialog.vue` 保存编码修正 |
- | 保存 |  | 后端收到正确编码,数据入库 |
- | 查询 |  | `getVitalSignsInfo` 返回正确编码的 `chartsSmalls` |
- | 渲染 |  | D3 图表 `getData` 按正确编码查找并渲染数据点 |
- | 旧数据兼容 |  | `drawfn.js` 自动映射旧编码 |
- | 自动刷新 |  | 保存关闭对话框后自动重新查询渲染 |
2026-05-28 23:10:39 +08:00
3c436c0dc2 fix(#612): 请修复 Bug #612:[一般] [患者管理-门诊就诊记录]状态有的是空的方框
根因:
- "门诊就诊记录"页面的状态列,当数据库 `enc.status_enum` 为 NULL 时,后端 `EnumUtils.getInfoByValue()` 无法匹配到枚举值,返回 null,前端显示空白方框。同时下拉"无状态"查询(0)被错误转为 `undefined`,导致不传过滤条件。
- ### 修改内容(3 个文件)

修复:
- 状态列显示:当 `subjectStatusEnum_enumText` 为空时显示"无状态"文本,不再显示空白方框
- 移除 `subjectStatusEnum=0` 转 `undefined` 的逻辑,让后端正确接收"无状态"过滤条件
- 3. 后端 - 空状态过滤** (`OutpatientRecordServiceImpl.java`)
- 当 `subjectStatusEnum=0` 时,使用 `queryWrapper.isNull("enc.status_enum")` 过滤状态为空的记录
- ### 验证结果
-  `npm run lint`: 0 errors
-  `mvn compile`: 编译通过
2026-05-28 22:54:17 +08:00
79ef36dc50 Fix Bug #550 2026-05-28 22:36:46 +08:00
fb996780df Fix Bug #603 2026-05-28 22:36:14 +08:00
00579d4ac7 Fix Bug #561 2026-05-28 22:36:11 +08:00
2e267b4353 feat: Bug #597 - 新增医嘱弹窗添加备注字段 + 查询返回remark 2026-05-28 11:24:59 +08:00
fbdcd815bd feat: Bug #597 - 住院医嘱增加备注字段 2026-05-28 11:00:41 +08:00
913a971ce4 revert: restore develop to clean baseline 5132de36 (remove all AI changes) 2026-05-28 09:43:49 +08:00
207e74508c Fix Bug #603: AI修复 2026-05-27 11:16:13 +08:00
5b2b9d0721 Fix Bug #576: AI修复 2026-05-27 08:59:51 +08:00
9db5ced4e3 Revert "Fix Bug #550: AI修复"
This reverts commit 16c42ca108.
2026-05-27 08:59:07 +08:00
bd14563691 Fix Bug #576: AI修复 2026-05-27 08:57:42 +08:00
2392689f6c Fix Bug #584: fallback修复 2026-05-27 08:57:37 +08:00
883514ff1c Fix Bug #573: AI修复 2026-05-27 08:55:45 +08:00
e4193fe5a7 Fix Bug #595: AI修复 2026-05-27 08:54:00 +08:00
46b0297cfb Fix Bug #577: AI修复 2026-05-27 08:52:50 +08:00
37b3d2e6a7 Fix Bug #575: AI修复 2026-05-27 08:51:53 +08:00
740dde3693 Fix Bug #577: AI修复 2026-05-27 08:50:35 +08:00
6499e79db2 Fix Bug #595: AI修复 2026-05-27 08:48:54 +08:00
4d1164abbf Fix Bug #570: AI修复 2026-05-27 08:46:15 +08:00
36565f47e4 Fix Bug #572: AI修复 2026-05-27 08:45:23 +08:00
fd7ee53a97 Fix Bug #570: AI修复 2026-05-27 08:43:35 +08:00
aea5ad38bc Fix Bug #544: AI修复 2026-05-27 08:41:09 +08:00
bcd64e3746 Fix Bug #569: fallback修复 2026-05-27 08:36:21 +08:00
bd53721306 Fix Bug #503: AI修复 2026-05-27 08:34:00 +08:00
91bd1ec9c2 Fix Bug #550: AI修复 2026-05-27 08:22:01 +08:00
76d6656ea3 Fix Bug #503: AI修复 2026-05-27 08:19:35 +08:00
72c381258f Fix Bug #550: AI修复 2026-05-27 08:17:33 +08:00
5452e27341 Fix Bug #562: AI修复 2026-05-27 08:15:27 +08:00
c91b9b07b3 Fix Bug #550: AI修复 2026-05-27 08:13:40 +08:00
d0cdaac864 Fix Bug #550: AI修复 2026-05-27 08:11:32 +08:00
46a33af654 Fix Bug #595: AI修复 2026-05-27 08:09:19 +08:00
b03cb76e95 Fix Bug #550: AI修复 2026-05-27 08:07:28 +08:00
4d94424367 Fix Bug #550: AI修复 2026-05-27 08:05:10 +08:00
597855859c Fix Bug #550: AI修复 2026-05-27 07:57:51 +08:00
36a82949bd Fix Bug #561: AI修复 2026-05-27 07:56:06 +08:00
818cd2ff91 Fix Bug #550: AI修复 2026-05-27 07:52:31 +08:00
45dc5c5d07 Fix Bug #561: AI修复 2026-05-27 07:51:10 +08:00
d84b23ff8e Fix Bug #574: AI修复 2026-05-27 07:50:17 +08:00
07f50ca09e Fix Bug #595: AI修复 2026-05-27 07:50:09 +08:00
281ee2979b Fix Bug #505: AI修复 2026-05-27 07:48:34 +08:00
bff502376b Fix Bug #550: fallback修复 2026-05-27 07:48:24 +08:00
65c673713a Fix Bug #506: AI修复 2026-05-27 07:47:44 +08:00
bb7336d7ec Fix Bug #503: AI修复 2026-05-27 07:45:54 +08:00