医院急诊科大概是全院节奏最快、信息最杂的地方。分诊台的护士一边问症状一边手写登记医生在诊室里翻着纸质病历找上一个病人的化验结果收费窗口排着长队留观室的床位情况全靠护士长脑内记忆——这些场景是我陪一位急诊科朋友值夜班时最直观的感受。也正因为亲眼看过这种混乱我后来才决定用 Spring Boot Vue 从零做一套医院急诊管理系统把从需求梳理、数据库建模、前后端联调到源码、数据库脚本、设计文档整理交付的全过程完完整整跑了一遍。这篇文章就把这套系统的设计思路、关键技术点和实操踩坑过程全部写出来给正在做同类课题的毕业生、实训项目团队以及想快速搭一套医疗管理后台的开发者做一个可以照着落地的参考范本。这套系统的核心价值在于它不是一个堆砌增删改查的玩具项目而是真正围绕急诊科“预检分诊 → 挂号接诊 → 诊断医嘱 → 收费统计”这条业务链路设计的信息化工具分诊护士、急诊医生、收费员三种角色各有一个极简工作台所有业务状态在系统里闭环流转。全文涉及的数据库表结构、后端接口设计、前端页面逻辑都是经过实际联调验证的方案不是只停留在概念层面的设计稿。1. 急诊科为什么需要一套独立系统业务痛点与设计目标1.1 急诊和门诊是两套完全不同的节奏很多第一次做医疗系统的同学最容易犯的一个认知错误就是把急诊管理系统做成“简化版门诊系统”。门诊的核心是预约和排队患者提前挂号、按时间段到场、科室固定、医生可以慢慢问诊。急诊完全不是这个逻辑患者是随机涌入的没有预约概念病情从普通感冒到急性心梗、脑卒中混在同一间候诊厅里所有信息必须在最短时间内被采集、流转、共享。急诊的业务链路大致是这样的预检分诊 → 挂号登记 → 医生接诊 → 开具检查检验或处方 → 执行处置 → 收费结算 → 留观或住院或离院。这条链路里分诊是第一道闸门也是通用医院信息系统中最薄弱的一环。护士需要在几分钟内完成患者基本信息采集、主诉录入和病情级别判定这些数据要实时推到医生端让医生还没见到人就知道候诊队列里哪个患者更紧急而不是等患者坐下之后再从头问一遍。1.2 通用医院信息系统在急诊场景下的尴尬大医院的医院信息系统功能确实全但操作非常重。一个急诊接诊流程往往要跨患者建档、挂号、医生站、护士站、收费、药房等多个子系统菜单层级深按钮多新人护士培训成本高。更麻烦的是通用医院信息系统的数据模型是按门诊和住院设计的急诊科特有的字段——比如分诊级别、来院方式、留观床号、抢救记录——常常无处安放只能塞进备注字段或者后续扩展表里。我在设计这套系统之前先给自己定了几条原则轻量、独立、贴合急诊科日常、一个页面干完一件完整的事。分诊台一个页面完成分诊和挂号医生一个页面完成看队列、写诊断、开医嘱收费员一个页面完成收费和退费。这套定位决定了它更适合作为科室级独立部署系统或者教学实训项目而不是和全院大系统抢地盘。1.3 系统的功能边界与用户角色明确场景之后我把系统用户划分为四种角色系统管理员、分诊护士、急诊医生、收费员。每种角色对应清晰的功能边界系统管理员用户管理、角色权限配置、基础数据维护科室、收费项目、药品目录、运营数据统计分诊护士患者登记、预检分诊、挂号操作、候诊队列管理急诊医生查看分诊队列、患者接诊、诊断录入、医嘱开立、留观治疗记录收费员费用查询、收费、退费、日结统计这套角色划分基本覆盖了急诊科日常信息化的核心闭环后续如果要扩展检验检查结果回传、叫号大屏、患者进度推送接口位置都已经预留了。2. 技术选型与架构设计Spring Boot Vue 为什么是黄金组合2.1 Spring Boot 的生态优势之所以选 Spring Boot不是因为它最潮而是因为它在 Java 后端这个领域里兼容性最好、资料密度最高。大多数高校课程和实训项目都以 Java 技术栈为基础Spring Boot 把传统 SSM 里繁杂的 XML 配置全干掉之后一个可运行的 Web 服务从创建到启动只花几分钟。做这种管理系统90% 的功能都是对数据库的增删改查Spring Boot MyBatis-Plus 能让开发效率提升非常明显。版本选择上我强烈建议毕业设计和实训项目用 Spring Boot 2.7.x JDK 8。这两个组合的兼容性问题最少网上能搜到的资料也最全大部分老教程的代码可以直接复用。如果你的机器装的是 JDK 17 以上那可以用 Spring Boot 3.x但要注意 3.x 里包名从 javax 改成了 jakarta很多老教程里import javax.servlet这类语句直接复制是编译不过的。2.2 Vue 在管理端场景的适配度管理后台的页面有一个典型特征表格多、表单多、状态多。Vue 的响应式数据绑定、组件化拆分和路由机制对于这种交互密集型场景非常合适。我实际使用的是 Vue 3 Element Plus如果你以前只写过 Vue 2 Element UI需要注意组件用法差异不小表格、表单、弹窗等核心组件的属性和事件命名都变了。为什么不用 React不是 React 不行而是 Vue Element Plus 的组合在国内后台管理系统中的生态太成熟了遇到任何 UI 问题几乎都能搜到现成答案。对于时间就是生命的项目来说这能省下大量调试时间。2.3 项目分层架构与目录规划后端采用经典的四层结构controller 只做参数接收和结果返回业务逻辑全部收敛在 service 层数据访问交给 mapper实体类负责映射表结构。src/main/java/com/er/emergency/ ├── controller/ # 接口层 ├── service/ # 业务逻辑层 ├── mapper/ # MyBatis数据访问层 └── entity/ # 实体类与VO对象前端 Vue 项目的目录按业务模块拆每个模块一个文件夹分诊台、医生工作站、收费管理、系统管理互不干扰。src/ ├── api/ # 统一封装的接口请求 ├── router/ # 路由配置 ├── store/ # 状态管理 ├── views/ # 页面组件 │ ├── triage/ # 分诊台 │ ├── doctor/ # 医生工作站 │ ├── charge/ # 收费管理 │ └── admin/ # 系统管理 └── utils/ # 通用工具方法前后端通过 RESTful JSON 交互后端统一返回{ code, message, data }结构前端 axios 拦截器统一处理 token 注入、超时和业务错误提示。这样不管是接入第三方还是出问题排查都只看一个数据结构心智负担很小。2.4 关键依赖版本对照最终锁定的核心版本如下照着配基本不会踩版本坑组件版本号说明JDK1.8兼容性最好绝大多数电脑可用Spring Boot2.7.182.x 系列最后的稳定版MyBatis-Plus3.5.5内置分页插件简化单表操作MySQL8.0开发与生产保持一致Vue3.4.x使用组合式 API 开发Element Plus2.7.xVue 3 配套组件库Node.js18前端构建与本地开发环境3. 数据库模型设计把急诊业务流映射成表结构3.1 核心业务实体梳理数据库是整个系统的地基我建议先梳理实体关系再动手建库不要边写代码边加表。这个项目核心表一共 10 张按业务域可以分为三类基础数据类用户、角色、科室、患者、业务流转类分诊记录、挂号登记、诊断医嘱、留观床位、费用结算类收费记录、收费项目。角色权限这里简单做成了用户-角色一对多的模型因为急诊科角色固定、职责清晰不需要引入复杂的权限体系。3.2 用户表、患者表和挂号表的设计先看用户表我用了 BCrypt 加密存储密码绝不存明文。角色字段直接关联角色表不做冗余设计。CREATE TABLE sys_user ( id bigint NOT NULL AUTO_INCREMENT, username varchar(50) NOT NULL COMMENT 登录账号, password varchar(255) NOT NULL COMMENT BCrypt加密密码, real_name varchar(50) COMMENT 真实姓名, role_id bigint COMMENT 角色ID, dept_id bigint COMMENT 所属科室ID, status tinyint DEFAULT 1 COMMENT 1启用 0禁用, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB COMMENT系统用户表;患者表重点关注过敏史和紧急联系人。急诊场景下这两个字段是关键时刻的救命信息很多患者本人已经无法说话必须靠家属或随行人员提供。CREATE TABLE patient ( id bigint NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL COMMENT 患者姓名, gender tinyint COMMENT 0女 1男, phone varchar(20) COMMENT 联系电话, id_card varchar(18) COMMENT 身份证号, emergency_contact varchar(50) COMMENT 紧急联系人, emergency_phone varchar(20) COMMENT 紧急联系电话, allergy_history varchar(255) COMMENT 过敏史, PRIMARY KEY (id) ) ENGINEInnoDB COMMENT患者信息表;挂号登记表是业务流转的核心它的字段体现的是“一次急诊就诊”的完整生命周期患者在分诊台登记后产生一条挂号记录此后这条记录被医生接诊、开医嘱、转归直到最后离院或住院才进入终态。CREATE TABLE registration ( id bigint NOT NULL AUTO_INCREMENT, reg_no varchar(30) NOT NULL COMMENT 挂号单号, patient_id bigint NOT NULL COMMENT 患者ID, triage_level tinyint COMMENT 分诊级别 1-4, doctor_id bigint COMMENT 接诊医生ID, status tinyint COMMENT 1待接诊 2就诊中 3已离院 4留观 5住院 6已取消, register_time datetime COMMENT 登记时间, end_time datetime COMMENT 结束时间, PRIMARY KEY (id), UNIQUE KEY uk_reg_no (reg_no), KEY idx_status_time (status, register_time) ) ENGINEInnoDB COMMENT挂号登记表;3.3 状态字段如何驱动业务闭环这个系统的难点不在 SQL 复杂度而在状态机的正确流转。我全程用一个 status 字段贯穿急诊接诊流程分诊护士登记患者后挂号记录为 1待接诊医生点击接诊改为 2就诊中医生完成处置后按转归方向改成 3离院、4留观或 5住院如果患者登记后等太久没接诊或者登记操作有误可以改成 6已取消。所有状态迁移都在后端 service 层做校验前端页面只能发起申请没有后端校验的状态变更一律拒绝。分诊级别我采用国内急诊常用的四级分诊标准数字越小越紧急1 级濒危患者需要立即抢救2 级危重患者优先处置3 级急症患者常规处理4 级非急症可适当等待。候诊队列展示时直接按级别排序1 级和 2 级用红色橙色标签醒目标注。3.4 索引与外键的取舍我在设计里刻意没有使用物理外键。原因是急诊场景里经常出现例外患者还没正式建档人已经被推进抢救室必须先产生诊疗行为之后再补建档信息。物理外键在这种场景下会成为录入阻塞。逻辑一致性靠 service 层业务代码保证宁可多写几行判断也不让数据库锁死业务流程。索引方面挂号表的 reg_no 建唯一索引保证单号不重复patient 表的 id_card 建普通索引用于快速查重挂号表的 status 和 register_time 建联合索引专门支撑候诊队列查询和统计报表。4. 核心功能模块逐段拆解分诊、接诊、医嘱、收费四段链路4.1 分诊模块四级分级与候诊队列分诊页面是护士操作频率最高的界面我把它设计成“左侧登记 右侧队列”的布局。左侧完成患者姓名、性别、电话、主诉、过敏史等信息采集右侧按分诊级别从高到低展示当前全部候诊患者。护士完成一条分诊登记后右侧队列立刻刷新医生端也能同步看到新患者出现。预检分诊的操作细节里有一个容易被忽略的需求如果患者是 1 级濒危系统应该允许跳过完整的挂号流程直接把患者加入抢救队列其他信息后续再补。为此我在分诊表单里加了“紧急模式”开关开启后只要求填写姓名和分诊级别即可提交其余字段允许留空。这个设计是跟急诊科护士聊出来的需求普通系统不会想到。4.2 挂号与接诊防重复与叫号衔接患者完成分诊后系统自动生成一条挂号记录挂号单号按照“日期 流水号”的规则生成保证唯一可读。这里有一个实际场景要处理同一个患者在同一天内可能因为病情反复二次就诊或者从留观状态转成正式就诊如果一刀切按身份证号禁止重复挂号反而会给患者和医生都添麻烦。我的处理方式是按身份证查重如果存在未完结的挂号记录弹窗提示护士“该患者已有未完成就诊记录”由护士人工判断是延续上次就诊还是强制新建。这个设计更符合急诊的真实工作流而不是简单的数据规则。4.3 医生工作站诊断、医嘱与快捷模板医生端的核心是一个接诊工作台左侧是候诊队列右侧是患者详情和操作区。医生可以从候诊队列看到每个患者的分诊级别和主诉点开后能看到护士录入的过敏史、生命体征信息再往下是诊断录入区和医嘱开立区。急诊场景里医生操作键盘的时间非常有限所以我把常见急诊处置做成了模板功能比如“急性上呼吸道感染”这个诊断模板里预置了对应的血常规检查和基础用药医生点击一次就能把多条医嘱批量插入再按实际情况增删。这个功能我一开始没想加是后期实际试用时发现医生反复输入同样内容才补上的。模板极大减少了录入时间也降低了漏项概率。4.4 收费、退费与日结统计收费页面的核心诉求是快。我把所有待收费项目聚合在患者挂号的同一条列表里收费员勾选项目后确认收款系统立即生成收费记录并标记对应医嘱为“已收费”。打印小票的模板单独做不需要经过浏览器打印窗口直接调用后端生成固定排版。退费走反向流程但有一个关键校验已经执行完毕的药品或检查项目不能直接退只能在备注写明原因由管理员审核后手工处理。因为急诊科每天都有抢救产生的紧急用药这部分费用流程和普通门诊不一样。5. 实际开发中反复踩过的坑与最终解决方案5.1 LocalDateTime 与前端格式化的兼容问题第一个坑是前后端时间格式不一致。Spring Boot 默认序列化 LocalDateTime 时输出2025-06-17T14:30:00这种中间带 T 的格式前端直接展示非常别扭而且提交参数解析时会报格式错误。解决方式是在 application.yml 里统一配置日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8前端配合 dayjs 做二次格式化所有时间类型展示和回传全部走字符串。 注意配置了全局格式后如果接收参数的时间字段是 Date 类型需要确认前端传参格式和配置一致否则会解析失败。5.2 并发场景下重复挂号的处理夜间急诊高峰期同一个患者家属可能同时用两部手机挂号这是极端场景但更常见的是护士手快连点两次提交按钮导致重复挂号。这个问题单靠前端防连点不可靠我做了双保险前端提交后按钮置灰禁用后端保存接口里先按身份证查一次未完成挂号如果存在直接返回提示。底层再靠 reg_no 唯一索引兜底哪怕业务层漏了数据库也会拒绝第二条重复单号。5.3 Vue 打包后放入 Spring Boot 的部署细节如果最终交付物希望是一个可以直接运行的 jar 包最省事的方案是把 Vue 构建出来的 dist 目录整体复制到 Spring Boot 的src/main/resources/static下面重新打包访问http://localhost:8080就能直接看到前端页面不需要单独部署 Nginx。这里有两个坑必须提前说。第一个是 Vue Router 的 history 模式部署后刷新任意非首页路径会 404因为后端没有对应的路由。解决方式是在后端加一个路由回退把非/api开头的请求统一转发到index.html。第二个是前端的接口 baseURL 不能写死成http://localhost:8080要改成相对路径/api否则部署到服务器、换端口、换域名之后所有接口都会断开。5.4 后端接口权限与数据越权前端路由守卫加菜单隐藏只是表面功夫真正要堵住的是接口层的越权访问。我给项目做了一个统一的登录拦截器从请求头取 token 校验所有非白名单接口然后通过自定义注解RequireRole在需要权限的接口上声明角色方法执行前做角色校验。还有一个经常被忽略的点数据越权。医生只能查看自己被分配的候诊患者不能通过手工改接口参数查看其他医生的患者列表。我在候诊队列接口里强制用当前登录医生的 ID 作为过滤条件而不是让前端传 doctorId从根源上避免越权。6. 从零跑通项目环境准备、启动步骤与联调技巧6.1 环境准备建议按前文版本对照表准备JDK 1.8、Maven 3.6、Node.js 18、MySQL 8.0。MySQL 版本建议直接用 8.0字符集选 utf8mb4避免后期遇到生僻字或特殊符号存储不了的问题。6.2 数据库初始化步骤用 Navicat 或命令行执行项目根目录下的emergency.sql脚本里包含建库、建表、初始化管理员账号和完整演示数据。这里给一个建议交付的 SQL 脚本里一定要带演示数据不然后面别人拿到项目第一步就卡在登录页面没有账号。6.3 后端启动与接口自测修改application.yml里数据库连接的用户名密码运行主类启动后端。集成 Swagger 的情况下启动后访问/doc.html查看接口文档可以逐个接口联调。看到 Tomcat started 日志就说明后端就绪。6.4 前端启动与开发代理配置前端根目录执行npm install安装依赖然后npm run dev启动默认 5173 端口。vite.config.js里配置了开发代理所有/api开头的请求自动转发到后端 8080本地开发时不涉及跨域问题。联调时先用管理员账号登录然后依次建分诊护士账号、医生账号、收费员账号把整个急诊流程走一遍。提示第一次跑通最容易卡的地方不是代码而是 Node 依赖安装失败和数据库版本字符集不一致。如果 npm install 报错优先检查 Node 版本是否满足要求。7. 交付物解析与后续扩展思路7.1 一份合格的项目交付物应该包含什么这套项目最终的完整交付物包括后端源码、前端源码、数据库脚本、环境部署文档、需求设计说明。很多人交付项目只给代码和 SQL 文件这是不够的。数据库脚本不能只有建表语句必须包含初始数据部署文档要写清楚 JDK、Node、MySQL 的安装过程和版本要求需求设计说明要讲清楚业务流和数据库设计的对应关系。这些文档的价值在于让接手的人不用重新摸索就能把项目跑起来。7.2 往真实业务扩展需要关注的方向如果你打算把它从教学项目扩展成科室级可用的系统优先级最高的几个方向一是对接医院叫号大屏候诊队列实时展示在电视屏幕上二是对接检验检查结果回传让医生端直接看到检验报告三是增加留观患者生命体征记录护士在留观区用移动端就能记录体温、心率、血压四是用图表把日结统计可视化展示急诊人次分布、分诊级别占比、高峰时段分析。这些扩展点不改变现有的表结构和接口风格都是增量开发这也是当初做模块划分时特意留好的余地。我个人做完这个项目最深的体会是做管理系统真正的难点从来不是写代码而是业务流程梳理。如果一开始就把分诊、挂号、接诊、收费这几个环节的状态流转关系画清楚后面至少能少改三分之一的需求。先把流程图和表结构定好再动手写页面这个顺序反过来会让你反复返工。如果你正在做类似的医疗管理系统我建议你也先找真正在急诊科工作过的人聊半小时比看十篇技术教程都管用。