摘要 本文汇总近期在患者档案 、 电子病历 、接诊统计 、工作台 、 医生档案等模块上的改造患者病情与个人信息分权、患者数据范围与病历联动、医生展示信息申请与审批、实时通知与轮询、个人主页本地上传、病历状态与校验、一单病历一张处方与过敏拦截、统计与工作台真实数据以及数据库角色菜单脚本在图形化客户端中的执行注意点。技术栈Vue3 前端、FastAPI 权限与数据范围体系、MySQL。关键词 智能诊疗数据权限FastAPIVue3电子病历处方接诊统计医生端架构前言我们医生端的基础业务是以接诊工作台、电子病历、处方管理、患者档案、接诊统计为骨架来搭的在此之上本地智能体侧重提供标准病历模板生成、常规病史摘要汇总、基础用药参考、固定话术填充等自动化辅助与上述核心业务形成“人做主流程、模型做提效”的分工。本周我主要围绕工作台执行逻辑、患者档案管理、接诊统计以及整体医生权限下刀把医生端这一层的整体架构大致拉通。由于同组其他成员本周进展有限我在此基础上又往前推了一截把一阶段里该落地的基本功能与业务逻辑尽量补全、跑顺方便后续接智能体能力与患者端联调时少踩坑。下文按模块做技术向记录便于复盘与交接个人周结放在文末结语。目录背景与目标患者档案查看、个人信息只读、病情可改医生档案名单与个人主页、变更审批电子病历状态、排序与 P1 校验处方一单病历一张处方与过敏风险提示接诊统计与工作台权限与数据范围总览数据库与图形化客户端运维要点结语1. 背景与目标临床与信息科常见诉求可以概括为患者医生要能看全量业务上该看的档案但不能随意改身份与联系方式对自己接诊过的患者应能维护病情与健康类字段过敏史、慢病、家族史、血型、身高体重、备注等。医生人事档案核心人事字段仅管理员维护对外展示类信息照片、简介、个签、出诊说明等走申请 管理员审批未通过前对外仍显示已生效数据。体验医生端不展示无权限按钮医生在“医生档案”菜单下更接近只读名单 我的主页。业务闭环病历状态清晰、处方与病历约束清晰、统计与工作台有真实数字而非占位符。下文按模块记录已实现逻辑与仍属规划项的边界便于读者对照自己仓库版本。先展示一下我修改后的接诊台界面2. 患者档案查看、个人信息只读、病情可改2.1 接口与权限全量修改PUT /clinic/patient依赖clinic:patient:edit主要给管理员等角色。病情 PATCHPUT /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/notifyToken 校验与登录态一致仅允许具备审批权限的用户连接推送待审数量变化等事件。前端 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、角色菜单DELETEINSERT、医生个签字段、医生变更申请表等。9. 结语本周从结果上看一是做了页面与交互上的优化例如按权限隐藏无效入口、患者查看/病情分流、医生名单与管理端差异化展示二是把医生端权限边界划清楚并与后端接口、菜单数据对齐三是把接诊统计与工作台从占位推进到可依赖真实聚合数据并开始与患者端挂号/预约等业务数据联动形成“挂号—接诊—病历—处方—统计”上可叙述的闭环雏形。同组其他同学本周产出不多我这边先尽量把一阶段该稳住的底座打牢接下来会在现有架构上继续迭代智能体辅助与联调细节。继续加油。延伸若需更强性能可对统计查询加索引或缓存病历版本快照、跨节点实时通知等仍可作为下一阶段排期。目录添加的有问题这次学会了下篇再改吧