前言

我们医生端的基础业务，是以接诊工作台、电子病历、处方管理、患者档案、接诊统计为骨架来搭的；在此之上，本地智能体侧重提供标准病历模板生成、常规病史摘要汇总、基础用药参考、固定话术填充等自动化辅助，与上述核心业务形成“人做主流程、模型做提效”的分工。

本周我主要围绕工作台执行逻辑、患者档案管理、接诊统计以及整体医生权限下刀，把医生端这一层的整体架构大致拉通。由于同组其他成员本周进展有限，我在此基础上又往前推了一截，把一阶段里该落地的基本功能与业务逻辑尽量补全、跑顺，方便后续接智能体能力与患者端联调时少踩坑。

下文按模块做技术向记录，便于复盘与交接；个人周结放在文末结语。

---

目录

1. 背景与目标
2. 患者档案：查看、个人信息只读、病情可改
3. 医生档案：名单与个人主页、变更审批
4. 电子病历：状态、排序与 P1 校验
5. 处方：一单病历一张处方与过敏风险提示
6. 接诊统计与工作台
7. 权限与数据范围总览
8. 数据库与图形化客户端运维要点
9. 结语

---

1. 背景与目标

临床与信息科常见诉求可以概括为：

患者：医生要能看全量业务上该看的档案，但不能随意改身份与联系方式；对自己接诊过的患者，应能维护病情与健康类字段（过敏史、慢病、家族史、血型、身高体重、备注等）。

医生人事档案：核心人事字段仅管理员维护；对外展示类信息（照片、简介、个签、出诊说明等）走申请 + 管理员审批，未通过前对外仍显示已生效数据。

体验：医生端不展示无权限按钮；医生在“医生档案”菜单下更接近只读名单 + 我的主页。

业务闭环：病历状态清晰、处方与病历约束清晰、统计与工作台有真实数字而非占位符。

下文按模块记录已实现逻辑与仍属规划项的边界，便于读者对照自己仓库版本。

先展示一下我修改后的接诊台界面：

---

2. 患者档案：查看、个人信息只读、病情可改

2.1 接口与权限

全量修改 PUT /clinic/patient：依赖 clinic:patient:edit（主要给管理员等角色）。

病情 PATCH PUT /clinic/patient/clinical：依赖 clinic:patient:clinicalEdit，请求体仅含病情相关字段。

非管理员 PATCH 时：后端根据 med_case 判断当前用户是否在 doctor_id 或 user_id 上接诊过该患者，否则拒绝。

2.2 数据范围：避免“写了病历却查不到档案”

在系统自带的角色数据范围（按建档人、部门等）之上，为患者档案增加扩展条件：原范围 ∪ patient_id 出现在当前用户接诊过的病历中（med_case.patient_id 非空且 doctor_id/user_id 匹配）。这样医生既能看到本科室规则内的档案，也能看到别科建档、但已由自己接诊的患者，与病历数据一致。

2.3 前端交互

查看：具备 clinic:patient:query 时可打开只读完整档案（个人信息区禁用编辑，就诊病历 Tab 仍可浏览）。

修改病情：具备 clinicalEdit 时可进入病情编辑流程；工具栏/表格按权限整块隐藏无权限按钮，无批量需求时隐藏多选列。

角色菜单：医生角色在库中通过 sys_role_menu回收患者档案的“新增 / 修改 / 删除”等按钮权限，仅保留列表、查询、病情修改等与角色匹配的项（以实际 menu_id 为准）。

---

3. 医生档案：名单与个人主页、变更审批

医生端：

管理端：

3.1 医生端与管理端界面

医生：无 clinic:doctor:add|edit|remove 时，列表不展示新建/修改/删除及多选、行内操作列，页面接近只读名单；有个人主页菜单时进入**“我的医生主页”**。

管理员：保留完整维护能力与档案变更审批入口（待审列表、通过/驳回）。

3.2 变更申请与审批

独立表存储申请：payload_json、状态（待审/通过/驳回）、审批人、时间等。

申请：医生提交白名单字段（展示类），禁止改绑定用户、工号等核心人事字段。

通过：将 payload 合并写入医生主表；驳回仅更新申请单。

个签等字段在医生实体与表单中扩展，与主页展示一致。

3.3 实时提醒

WebSocket（如 /ws/clinic/notify）：Token 校验与登录态一致，仅允许具备审批权限的用户连接；推送待审数量变化等事件。

前端 WebSocket + 定时轮询双保险；Vite 开发代理需开启 ws: true。多进程部署时进程内连接池仅本进程广播，全集群需后续引入消息中间件。

3.4 个人主页照片

个人主页侧本地上传（统一走如 /common/upload 的图片上传组件），单图绑定 photoUrl，减少手填 URL；左侧头像对相对路径拼接 VITE_APP_BASE_API 显示。

---

4. 电子病历：状态、排序与 P1 校验

4.1 状态

约定：0 草稿 → 1 已保存 → 2 已归档（归档可视为“已完成接诊”类终态）。

已归档默认不可再改；可为管理员保留例外开关便于运维纠错。

4.2 列表排序与统计字段

支持按状态 + 就诊日 + 最近修改等组合排序策略；无就诊日时空值沉底，避免排序异常。

使用 doc_char_count 等字段支持按正文规模排序或统计。

4.3 必填分级（P1）

当状态为已保存或已归档时，后端强校验主诉、诊断非空；草稿阶段不强制，便于边写边存。

4.4 版本留痕

当前以 update_time / 操作人等常规审计字段为主；独立历史快照表可作为后续 P1.5 迭代。

---

5. 处方：一单病历一张处方与过敏风险提示

这个就不用页面展示了，下面解释一下逻辑：

同一 case_id 至多一张处方：保存前统计该病历是否已有处方（编辑时排除自身主键），否则拒绝并提示。

过敏史：患者档案存在过敏史时，前端弹窗提示；后端对青霉素族等与药品名做演示级关键字匹配，命中则硬拦截并返回明确错误信息（规则与前端可对齐，便于联调）。

患者与病历一致：校验病历存在且 patient_id 与处方所选患者一致。

---

6. 接诊统计与工作台

6.1 按日聚合接口

提供按日期区间的序列数据：例如每日接诊人次（病历侧不重复患者）、病历条数、处方张数、预约数等。

服务层采用固定多次 GROUP BY再按天填充，限制最大查询跨度，避免长区间拖垮数据库。

6.2 “按医生”与权限

普通医生默认统计本人；管理员或具备全院数据权限时，可通过参数指定其他医生查询（具体以后端“是否限制为当前医生”的解析逻辑为准）。

6.3 工作台三张卡片

今日接诊、待完善病历（未归档）、待发药处方（如草稿状态）等：后端聚合接口返回真实计数，前端工作台 onMounted 拉取并展示；仅在请求失败时回退占位符。

6.4 性能建议

生产环境建议在 med_case.visit_date、doctor_id、create_time 及 med_prescription 相关时间、医生字段上建立合适索引，并在预发压测验证 P95 延迟。

---

7. 权限与数据范围总览

模块	思路摘要
患者列表/详情/PATCH	角色数据范围 + 接诊病历 OR 条件
病历列表	当前登录医生过滤 doctor_id/user_id；管理员/全院权限可看全院
处方列表/校验	同上，避免误改他人处方
统计	医生默认本人；管理员可选医生维度
工作台	医生维度与管理员全院维度分支聚合

病历、处方侧的“当前医生”过滤与患者侧“接诊 OR”互补，形成接诊闭环下的权限一致性。

---

8. 数据库与图形化客户端运维要点

增量脚本中包含：菜单与按钮 INSERT IGNORE、角色菜单 DELETE + INSERT、医生个签字段、医生变更申请表等。

---

9. 结语

本周从结果上看，一是做了页面与交互上的优化（例如按权限隐藏无效入口、患者查看/病情分流、医生名单与管理端差异化展示），二是把医生端权限边界划清楚并与后端接口、菜单数据对齐；三是把接诊统计与工作台从占位推进到可依赖真实聚合数据，并开始与患者端挂号/预约等业务数据联动，形成“挂号—接诊—病历—处方—统计”上可叙述的闭环雏形。

同组其他同学本周产出不多，我这边先尽量把一阶段该稳住的底座打牢；接下来会在现有架构上继续迭代智能体辅助与联调细节。继续加油。

（延伸：若需更强性能，可对统计查询加索引或缓存；病历版本快照、跨节点实时通知等仍可作为下一阶段排期。）

目录添加的有问题，这次学会了，下篇再改吧