山东大学软件学院创新实训（三）
关键词： 智能诊疗；数据权限；FastAPI；Vue3；电子病历；处方；接诊统计；医生端架构
前言
我们医生端的基础业务，是以接诊工作台、电子病历、处方管理、患者档案、接诊统计为骨架来搭的；在此之上，本地智能体侧重提供标准病历模板生成、常规病史摘要汇总、基础用药参考、固定话术填充等自动化辅助，与上述核心业务形成“人做主流程、模型做提效”的分工。
本周在完成工作台执行逻辑、患者档案、接诊统计、医生权限拉通的基础上，我继续往前推了一截：补全一阶段里易踩坑的权限边界、病历导出与处方隔离，并在前端优化了档案查看形态、病历/处方处理流程与诊间可读性（字号分档、列表列宽、开屏动效等），方便后续接智能体能力与患者端联调。
下文按模块做技术向记录，便于复盘与交接；个人感受放在文末结语。
目录
- 背景与目标
- 患者档案：查看分流、个人信息只读、病情可改
- 医生档案：名单、个人主页与变更审批
- 电子病历：状态、排序、校验与导出
- 处方：数据范围、一单病历一单、过敏与开具人
- 接诊统计与工作台
- 前端体验：档案/病历/处方查看与操作形态优化
- 权限与数据范围总览
- 数据库与运维要点
- 结语
此目录仅供方便阅读所用，不具备跳转能力。（我前面添加的有问题，这里就先这么用吧）。
1. 背景与目标
临床与信息科常见诉求可以概括为：
患者：医生能看业务上该看的档案；身份信息、联系方式等做只读或强管控；对自己接诊过的患者，能维护病情与健康类字段（过敏史、慢病、家族史、血型、身高体重、备注等）。
医生人事档案：核心人事由管理员维护；对外展示类信息走申请 + 审批；医生端列表接近只读名单 + 我的主页。
业务闭环：病历状态清晰；处方与病历约束清晰；统计与工作台是真实聚合数据而非长期占位。
工程现实：从 Gitee 拉取基线后，需解决下载头编码、演示账号误看全院处方、导出内容贴近纸质病历等问题，并与菜单/按钮权限对齐。
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 对齐，避免跨科建档但已由本人接诊的患者在档案列表中「消失」。
2.3 前端交互与查看形式优化
查看：具备 clinic:patient:query 时可打开档案；个人信息区只读，病情与健康类字段按权限进入编辑流；就诊病历 Tab 可浏览，与诊间上下文一致。
修改病情：具备 clinicalEdit 时进入病情编辑；无权限的按钮、批量能力整块隐藏，减少误触与无效入口。
角色菜单：医生角色在库中通过 sys_role_menu 回收与角色不匹配的新增/修改/删除等按钮权限，以实际 menu_id 为准。
3. 医生档案：名单、个人主页与变更审批
3.1 医生端与管理端界面
医生：无 clinic:doctor:add|edit|remove 时，列表不展示新建/修改/删除及多选、行内操作列，页面接近只读名单；有个人主页菜单时进入**「我的医生主页」**。
管理员：保留完整维护能力与变更审批入口（待审、通过/驳回）。
3.2 变更申请与审批
独立表存储申请：payload_json、状态、审批人、时间等。申请侧仅允许白名单展示字段；通过时合并写入医生主表；驳回只更新申请单。个签等字段与主页展示一致。
3.3 实时提醒
WebSocket（如 /ws/clinic/notify）与登录态一致；仅审批权限用户可连。前端可 WebSocket + 轮询双保险；Vite 代理需 ws: true。多进程时注意进程内广播局限，全集群后续可接消息中间件。
3.4 个人主页照片
统一走如 /common/upload，单图绑定 photoUrl；头像对相对路径拼接 VITE_APP_BASE_API 显示，减少手填 URL。
4. 电子病历：状态、排序、校验与导出
4.1 状态
约定：0 草稿 → 1 已保存 → 2 已归档。已归档默认不可再改（管理员可保留运维例外）。
4.2 列表排序与统计字段
支持状态 + 就诊日 + 最近保存等组合策略；无就诊日时空值沉底。可使用 doc_char_count 等支持按正文规模排序（列表展示是否保留「字数」列可按产品取舍；我们近期更倾向弱化该列，避免医生关注偏离临床）。
4.3 必填分级（P1）
状态为已保存/已归档时，后端强校验主诉、诊断非空；草稿不强制。
4.4 导出与打印（本轮重点）
HTTP 头：中文文件名若直接写在 Content-Disposition 的 filename="..." 中，Starlette 会按 latin-1 编码响应头，触发 UnicodeEncodeError。处理方式是：filename= 仅 ASCII 回退名，完整 UTF-8 名使用 filename*=UTF-8'' + 百分号编码。
版式：导出 Word/Excel 突出病情发展（主诉/现病史/既往史）与本次诊疗，并增加同一患者、同权限下的门诊时间线；已去掉段落字数统计图，更贴近真实病历打印需求。
5. 处方：数据范围、一单病历一单、过敏与开具人
5.1 业务规则（简述）
- 同一
case_id至多一张处方（编辑时排除自身主键），否则后端拒绝。 - 过敏史：前端提示 + 后端对青霉素族等与药品名做演示级关键字匹配，命中则硬拦截并返回明确错误。
- 患者与病历一致：病历存在且
patient_id与处方所选患者一致。
5.2 权限：演示医生「只能看本人处方」
若仍使用 resolve_clinic_doctor_restrict_user_id 一类逻辑，角色带 *:*:* 时可能 不再按医生过滤，演示账号容易看到全院处方。
本轮为处方列表/详情校验单独引入 resolve_prescription_doctor_restrict_user_id：
a:admin：不限定医生；
b:显式 clinic:data:all：可看全院（医务/管理按需分配）；
c:仅有 *:*:* 等宽泛权限：仍按当前登录用户与 doctor_id / user_id 匹配，避免误看他人开方。
5.3 开具人字段（prescriber_name）
库表 med_prescription 增加 开具人姓名快照，新增时写入当前登录用户名；修改处方时不覆盖，便于统计「谁开的」。需执行增量 SQL（如 med_clinic_p16_prescription_prescriber_name.sql）并重启后端。
6. 接诊统计与工作台(还是和之前差不多）
6.1 按日聚合
按日期区间返回每日：接诊人次（病历侧去重患者口径）、病历条数、处方张数、预约拆分等。服务层注意最大查询跨度，避免长区间拖垮库。
6.2 「按医生」与权限
普通医生默认本人；管理员或具备全院门诊数据权限时，可通过参数指定科室/医生（以后端解析为准）。
6.3 工作台卡片
今日接诊、待完善病历、处方草稿/已开具等：接口返回真实计数；失败再回退占位。工作台轮询间隔可按环境调整。
6.4 性能
在 med_case.visit_date、doctor_id、create_time 及 med_prescription 相关字段上建合适索引，预发压测关注 P95。
7. 前端体验：档案/病历/处方查看与操作形态优化
在「能跑」之上补了一层「好用」：
- 诊室上下文条：进入
/clinic/**后在内容区顶部固定患者上下文（档案/病历/预约），并放置 「字号」四档切换（小/中/大/极大），与 Element Plus 字号变量联动，本地持久化。 - 病历 / 处方列表工具栏：除顶栏外，在病历管理、处方管理按钮行增加同款字号入口，避免找不到设置。
- 列表列宽：患者名、主诉、诊断、疾病、摘要等列，按当前页最长文本与字号档位估算
min-width/width，并设上下限，减少「极大字 + 长串诊断」挤版。 - 接诊工作台开屏：同会话首次进入工作台时简短开屏动画（尊重系统「减少动态效果」设置）。
8. 权限与数据范围总览
| 模块 | 思路摘要 |
|---|---|
| 患者列表/详情/PATCH | 角色数据范围 ∪ 接诊病历 OR |
| 病历列表 | 医生 doctor_id/user_id；admin / APP_DEMO_MODE 等与 clinic:data:all 组合按你们最终定稿执行 |
| 处方列表 | 处方专用解析函数，*:*:* 不放宽到全院；admin / clinic:data:all 除外 |
| 统计 / 工作台 | 医生默认本人；管理员或全院权限分支聚合 |
病历、处方侧重「谁开的」、患者档案侧重「谁接诊过」，两者互补，形成接诊闭环下的一致性。
9. 数据库与运维要点
1.增量脚本：菜单按钮 INSERT IGNORE、角色菜单维护、医生个签/变更申请、处方 prescriber_name 等，可重复执行的片段按仓库规范来写。
2.拉代码后：执行新 SQL → 重启后端 → 清浏览器缓存/重新登录再验权限缓存。
3.开发期注意 前端代理端口 与后端 .env 中 APP_PORT 一致。
10. 结语
本周从结果上看：一是页面与交互上按权限隐藏无效入口，并把患者查看 以及病情修改、医生名单与管理端差异做清楚；二是把医生端权限与接口、菜单数据对齐，处方侧单独收紧数据范围，避免演示账号“看穿全院”；三是病历导出从“能下”做到“头编码正确 + 版式贴近临床”，统计与工作台继续依赖真实聚合；四是前端在档案与病历/处方列表上做了查看与操作形态的统一优化（字号、列宽、开屏），为后续智能体与患者端联调打底。
同组其他同学若进度不同步，建议以本文模块清单 + SQL + 权限字为交接锚点。下篇可将目录锚点与 CSDN 编辑器再对齐一遍（本篇目录已按章节标题成对列出，便于核对）。
医生端延伸：统计查询缓存、病历版本快照、跨节点实时通知等，可作为下一阶段排期。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
11
0- 0
已为社区贡献4条内容
所有评论(0)