简介电子病历EMR是医疗信息化的核心载体设计时需兼顾业务流程的完整性与数据安全。以Java技术栈为例借助Spring Boot构建后端服务、MyBatis Plus简化持久层操作并通过JWT与RBAC实现接口级的权限管控可显著提升开发效率与系统可维护性。同时基于事务机制和乐观锁确保病历、处方与库存数据的一致性为中小型诊所及科室级应用提供了轻量级解决方案。本文从系统架构出发剖析患者-病历-处方-药品闭环的设计思路并分享环境搭建、核心接口实现、Nginx部署及常见坑点帮助开发者快速掌握此类管理系统的构建方法也为课程设计或毕业设计提供了可直接改造的参考源码。 最近开源了一套Java实现的医院病人电子病历管理系统源码源代码和说明材料都打包好了。很多朋友拿到手第一反应是问“这玩意儿怎么跑起来”“能不能改成自己的毕设”“表和表之间到底什么关系”。今天不聊虚的直接把我做这套系统的整体思路、技术选型、核心模块实现和踩过的坑整理出来希望能让刚接触这个项目的同学少走弯路。这套系统定位不是那种大而全的HIS系统而是聚焦“病人—病历—处方—药品”这条主干业务链。它覆盖了患者基础信息管理、医生接诊、电子病历录入、诊断管理、处方开立、药品库存管理、用户角色权限、操作日志回看等模块。对于中小型诊所、科室级病历管理或者Java Web方向的课程设计、毕业设计这套代码拿来改改就能用比从零搭框架省太多时间。1. 项目概述与整体设计思路1.1 为什么需要一套完整的电子病历管理系统源码电子病历不是普通的增删改查。你去看这个领域的需求就会发现它牵扯到真实的医院就诊流程患者先挂号或者登记医生接诊后写主诉、现病史、既往史、体格检查、辅助检查、初步诊断然后开处方药房配药扣库存。整个过程涉及的角色也很多医生、护士、药师、管理员每个角色能看的数据、能做的操作完全不一样。我去年在帮一家民营门诊做信息化改造的时候市面上现成的轻量级病历系统要么收费贵要么定制不灵活。于是索性自己写了一套把核心模块抽出来整理成开源项目。当时给自己定了几条规矩第一技术栈不要太冷门Java开发的人一看就懂第二业务要闭环不能只做一个病历录入页面就完事第三权限和操作日志必须到位这是医疗系统的基本底线第四代码结构要清爽方便二次开发。这套源码的价值也在这。它不是那种“只能跑demo”的脚手架而是把医生真正会用的流程做了进去。你在学习的时候不只是看几个CRUD接口而是能理解到“一个患者的完整就诊记录是如何在多个角色之间流转的”。1.2 系统核心业务流程与角色权限划分整个系统我按医院常见的组织方式做了三种核心角色管理员、医生、药房人员。实际项目中还可以扩展护士、挂号员、患者自助端但核心闭环只需要这三个角色就能转起来。以一次普通门诊为例完整流程是这样的管理员先维护好科室、药品、医生账号等基础数据。患者登记基本信息生成患者唯一编号。医生登录系统在“接诊列表”里看到待接诊患者点击进入病历编辑页。医生填写病历主表包含主诉、现病史、既往史、检查结果、初步诊断等信息。医生根据诊断开立处方选择药品、填写用法用量和天数。处方保存时系统自动校验库存库存不足会给出提示。药房人员登录后看到待发药处方点击配药后库存扣减。管理员通过操作日志可以跟踪每一步的登录、录入、修改行为。这个流程看起来简单但每一步都牵涉权限校验和状态流转。我在设计时没有用复杂的工作流引擎而是用状态字段和角色注解来控制。因为电子病历系统的核心场景相对固定工作流引擎反而会把项目搞重维护成本也高。角色权限这块我用的是基于RBAC的简化模型用户表、角色表、权限表三张基础表配合Shiro或JWT的注解做方法级拦截。比如医生角色访问药房库存管理接口时会直接被拒绝管理员可以查看所有操作日志。这样设计的好处是很直观后端接口里加一行注解就能控制访问范围不需要在业务代码里到处写if判断。2. 技术选型与关键方案解析2.1 后端Spring Boot MyBatis Plus的取舍与实践做管理系统后端框架我首选Spring Boot这是目前Java生态里整合成本最低的方案。项目用的是Spring Boot 2.x版本JDK1.8即可运行如果你本机是JDK11或者17只要调整spring-boot-starter-parent版本也都没问题。持久层我选择了MyBatis Plus而不是原生MyBatis或者Spring Data JPA。原因很简单这个项目里有很多简单的单表操作比如根据患者ID查病历列表、根据角色ID查用户列表、药品的分页模糊查询。MyBatis Plus的BaseMapper内置了insert、selectById、updateById、deleteById这些常用方法开发效率提升非常明显。但这里有一个容易踩的坑MyBatis Plus的乐观锁插件和分页插件需要手动配置否则注解Version和分页查询不会生效。我最初的版本忘了加MyBatisPlusInterceptor导致分页返回全部数据后来排查了很久才发现是配置缺失。源码里已经把配置写好了位置在config/mybatis/MybatisPlusConfig.java你如果改造成其他项目记得把这两个插件带上。至于为什么不选Spring Data JPA主要是国内医院HIS系统的开发团队熟悉MyBatis生态的占多数而且复杂SQL的手动优化空间更大。病历查询经常要联表过滤MyBatis的XML文件写动态SQL比JPA的Specification要直观。2.2 前端Vue Element UI和前后端分离部署前端部分我选的是Vue 2 Element UI打包后通过Nginx做静态资源托管。为什么不是Vue 3和Element Plus考虑到这套项目要兼容大量老学员、老电脑的环境Vue 2生态稳定资料多遇到问题搜索时答案一眼就能看懂。前后端分离的好处是后端完全以JSON接口方式提供服务只要接口文档清楚前端想换成React或者微信小程序都很容易。我在说明材料里附了一份完整的接口文档每个接口的请求参数、返回结构都有二次开发时可以直接对着文档联调。部署方面前端npm run build之后生成dist目录后端mvn package打出jar包。生产环境用Nginx托管dist目录同时把/api路径反向代理到后端服务的8080端口。这样前端的登录请求会通过Nginx转发到后端不会出现跨域问题也让前后端的访问入口保持一致。3. 核心功能拆解与数据库设计3.1 数据库表设计从患者到病历的完整建模数据库设计是我觉得这个项目最值得看的地方。当时没有盲目追求大而全而是围绕业务闭环设计了9张核心表分别是表名用途说明sys_user系统用户表保存登录账号、密码、角色关联sys_role角色表内置管理员、医生、药房等角色sys_permission权限表保存接口权限或菜单权限标识patient患者信息表姓名、性别、年龄、手机号、身份证等department科室表记录科室名称、位置、电话medical_record病历主表保存一次就诊的完整病历内容diagnosis诊断表保存医生给出的疾病诊断结果prescription处方表记录开方时间、医生、患者、状态prescription_item处方明细表具体药品、剂量、用法、数量drug药品表药品名称、规格、库存量、单价等operation_log操作日志表记录关键操作行为为什么把病历和诊断分开因为一次就诊可能对应多个诊断结论比如“上呼吸道感染”和“扁桃体炎”同时存在。如果只设计一个病历字段存多诊断时只能塞成字符串后续做统计分析非常痛苦。拆成一对多以后医生端可以动态添加多条诊断报表也能按诊断名称聚合。患者表和病历表的关系也是一对多。患者基本信息独立存储每次就诊生成一条新的病历记录这样既能保证患者历史的就诊轨迹完整又避免在病历表里重复存姓名、身份证号等冗余数据。考虑到系统规模和部署环境我主键用的是自增Long类型。如果你的项目未来要做分库分表可以把主键改成雪花ID算法基于MyBatis Plus的IdType ASSIGN_ID切换代价很小。源码里也预留了相关配置。3.2 病历主表与处方明细的事务一致性设计电子病历系统里最需要小心的一个场景医生保存整份病历的同时还要保存诊断列表和处方明细。任何一步失败都可能导致患者信息不完整。我采用的是Spring的Transactional声明式事务。病历表、诊断表、处方表、处方明细表的插入操作放在同一个事务方法里任何一个异常都会整体回滚。这个设计保证了数据库一致性但也带来了一个性能隐患如果处方明细非常大事务持锁时间会变长。所以我在代码里对病历内容做了长度校验防止一次性提交大量文本。药品库存扣减这块源码里有一个专门的StoredProcedure思路但其实是用了“乐观锁扣减”的简化版。sql语句如下UPDATE drug SET stock stock - #{quantity} WHERE id #{drugId} AND stock #{quantity}这样通过受影响行数判断库存是否足够如果返回0就说明库存不足直接抛业务异常。这个方案比先查出来再判断要安全天然规避了并发扣减时的超卖问题。另外病历历史版本的问题也值得提一下。医疗场景下医生修改病历后系统应该保留修改痕迹。我的实现比较轻量在medical_record表里增加了update_time字段但没有做完整的版本表。如果你的项目答辩时被问到这个问题可以补充一张medical_record_history表在更新前把旧记录插入历史表。这样既保留痕迹又不会让主表数据膨胀到影响查询性能。4. 从0到1实操源码运行与核心模块实现4.1 环境准备与本地快速启动拿到源码后先看根目录下的README和数据库脚本我建议按这个顺序启动项目安装JDK 1.8并配置好JAVA_HOME环境变量。安装Maven 3.6配置阿里云镜像加快依赖下载速度。安装MySQL 5.7创建一个名为hospital_emr的数据库执行sql/hospital_emr.sql脚本。搭建Node.js 14环境用npm install安装前端依赖。打开后端application.yml修改数据库用户名密码。启动后端mvn spring-boot:run。启动前端npm run serve。访问前端地址默认管理员账号 admin / 123456。这里有几个常见的环境变量配置问题我在说明材料里用专门篇幅写了。比如Windows下JAVA_HOME配置后仍然提示找不到Java通常是Path里没有添加%JAVA_HOME%\bin。还有MySQL 8.0连接时需要改驱动类名和URL时区参数否则启动会报Server returns invalid timezone。如果遇到直接参考文档里的配置片段即可。4.2 登录认证与权限控制落地登录模块是这套系统所有功能的入口我用了JWT 自定义注解的方式来实现无状态认证。用户登录成功后后端生成一个JWT令牌其中包含用户ID、用户名、角色编码有效期设置为8小时。前端把token存在localStorage里每次请求时在请求头里带上Authorization字段。后端通过拦截器解析token并设置当前登录用户的上下文。密码安全方面千万不能用明文。源码中使用的是BCrypt加密即使数据库泄露攻击者也很难反推出原始密码。用户表里password字段保存的是BCrypt哈希串每次登录时用BCryptPasswordEncoder的matches方法校验。方法级权限控制我用了一个自定义注解RequireRole例如PostMapping(/medical-record) RequireRole({DOCTOR, ADMIN}) public Result saveRecord(RequestBody MedicalRecordDTO dto) { return medicalRecordService.save(dto); }拦截器会从JWT里解析出角色编码和注解里的角色集合比对不匹配就直接返回403 JSON。这套方案比Spring Security的过滤器链轻量代码更容易理解对新手来说也更友好。4.3 病历录入与处方开立的核心接口实现病历保存的Service层代码是整个项目业务逻辑最复杂的一部分我写了一个比较清晰的接口public Long createRecord(MedicalRecordDTO dto) { MedicalRecord record new MedicalRecord(); BeanUtils.copyProperties(dto, record); record.setDoctorId(UserContext.getUserId()); record.setStatus(COMPLETED); medicalRecordMapper.insert(record); if (CollectionUtils.isNotEmpty(dto.getDiagnosisList())) { for (DiagnosisDTO diagnosisDTO : dto.getDiagnosisList()) { Diagnosis diagnosis new Diagnosis(); diagnosis.setRecordId(record.getId()); diagnosis.setName(diagnosisDTO.getName()); diagnosis.setIcdCode(diagnosisDTO.getIcdCode()); diagnosisMapper.insert(diagnosis); } } if (CollectionUtils.isNotEmpty(dto.getPrescriptionList())) { for (PrescriptionDTO prescriptionDTO : dto.getPrescriptionList()) { Prescription prescription new Prescription(); prescription.setRecordId(record.getId()); prescription.setDoctorId(record.getDoctorId()); prescription.setPatientId(record.getPatientId()); prescription.setStatus(WAIT_DISPENSING); prescriptionMapper.insert(prescription); // 插入药品明细并扣减库存 } } return record.getId(); }这里有一个容易被忽略的细节病历对象的createTime和updateTime字段我是在数据库层面用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP来自动维护的。这样代码里不需要每次都手动set时间也不会出现时区错乱的怪问题。医生前端录入时主诉、现病史这些文本框我做了字数限制和必填校验。虽然前端校验体验不错但后端依然要做一遍统一校验我用的是JSR 303注解比如NotBlank、Size确保绕过前端提交脏数据也不会进入数据库。4.4 部署上线与Nginx反向代理配置如果想要部署到服务器我的建议是使用Docker Compose源码里提供了docker-compose.yml示例涵盖MySQL、后端服务、前端Nginx三个容器。Nginx配置的关键部分是这样server { listen 80; server_name hospital.example.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://backend:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }需要重点提醒的是proxy_pass末尾的斜杠问题。如果proxy_pass后面不带URI比如写http://backend:8080请求会原样转发如果带了/api/Nginx会替换匹配到的location前缀。很多新手在这里配置错误导致接口404。我在说明材料里用红字标注了但线上交流时还是经常会有人踩到这个坑。5. 高频问题排查与避坑经验5.1 后端启动与运行期间的常见报错报错信息原因分析解决思路java.lang.OutOfMemoryError: insufficient memoryJVM堆内存设置不足或者是分页查询一次性加载太多数据开发环境在IDEA里调大VM options生产环境使用-Xms512m -Xmx1024m同时检查代码避免把大列表直接返回Server returns invalid timezoneMySQL 8.0的时区设置问题数据库连接URL加上serverTimezoneAsia/ShanghaiMyBatis Plus分页查询返回全部数据缺少分页插件配置确认MybatisPlusInterceptor配置生效Access denied for user rootlocalhost数据库账号密码错误或远程连接权限不足检查application.ymlMySQL中授权远程访问CORS跨域问题前端端口与后端端口不一致开发环境配置代理生产环境用Nginx同源转发内存溢出这个问题我实际遇到过一次比较典型的场景。报表统计模块里把某个时间段的所有病历都加载到内存再过滤数据量一大就直接OutOfMemoryError。后来改成使用SQL聚合查询只返回统计结果内存瞬间就下来了。所以在有大量数据的业务里尽量让数据库算完再返回不要把大表整个load进Java堆。5.2 开发期容易忽略的安全与审计细节医疗数据属于敏感数据哪怕只是课程设计也应该从早期就养成安全习惯。第一所有涉及患者姓名的列表接口后端都需要做越权校验不能出现A医生登录后能查到B医生的患者隐私。源码里通过查询条件强制加上doctor_id限制而不是只靠前端隐藏。第二SQL注入的防护。MyBatis里写动态SQL时排序字段、表名这类不能用#{}代替的必须做白名单校验。比如排序字段只允许传入name、createTime否则直接返回默认排序。源码里所有模糊查询使用Like函数的参数拼接没有用${}拼接。第三操作日志记录。病例修改、处方删除、权限变更这类敏感操作必须留着痕迹。我实现了一个基于AOP的日志切面在日志注解的方法执行后自动记录操作人、操作时间、请求IP、方法名称和参数摘要。这样管理员在审计时能追踪到具体是谁在什么时候改了什么数据。5.3 前后端联调中的Bug定位技巧前后端分离项目联调阶段最容易出现的问题是“前端明明调用了接口后端却收不到”。遇到这种情况我推荐先打开浏览器F12看Network面板确认请求是否真的发出去请求URL是否正确请求头是否带了token。如果前端报跨域错误要看后端拦截器是否允许OPTIONS预检请求很多JWT拦截器没有放行OPTIONS导致前端实际请求一直失败。另一个常见的低级问题是端口冲突。后端8080被占用时可以换一个端口但记得前端代理配置也要同步修改。源码里统一通过环境变量读取服务端口不用改代码就能切换配置。6. 如何高效使用说明材料与二次开发扩展6.1 说明材料里有哪些可以直接用的内容这套源码附带的说明材料不是简单的README而是包含了一份完整的数据库字典、接口文档和部署手册。数据库字典逐个表解释字段含义和枚举值接口文档包含请求示例和响应示例部署手册则涵盖了Windows本地运行和Linux服务器部署两个场景。对这些材料我的建议是先读部署手册把项目跑起来再对着数据库字典看表结构。等你能从患者登记到药房发药完整走通一遍流程后再去看接口文档这样理解会更加立体。千万不要一开始就扎进代码细节里容易被mapping和service绕晕。6.2 基于这套源码可以扩展的方向二次开发方向很多我见过有人加了预约挂号模块让患者在小程序端选科室、选医生、选时间段后台生成待接诊记录也有人加了检查检验管理对接检验仪器上传的数值结果还有人把原来的用户角色扩展成五级增加了护士站和收费员。我个人最推荐加的扩展是“数据统计报表”比如医生工作量统计、药品消耗排行、患者年龄段分布。这些功能不需要改动已有表结构只要在SQL里做聚合查询即可而且给毕业设计答辩加分非常明显。做报表时你才会体会到提前在每个表里保存create_time和update_time是多么明智。这些都是统计的天然维度后期不需要回补数据。另外一个有意义的扩展是电子病历模板管理。现实中医生输入病历有固定的话术结构比如“主诉现病史既往史体格检查”。你可以增加一个模板表把常用词句存成模板医生录入时一键填充。这个功能在真实门诊使用频率极高开发难度也不大。7. 最后分享几点做这类系统的体会花了大半年时间从设计到编码再把这套系统开源出来我自己最大的体会是做一个管理系统业务理解比技术炫技重要得多。你可以用各种高深的技术把系统做得很花哨但如果医生录入一份病历要点十几次鼠标护士找药房要重新打字那这个系统上线也只会被嫌弃。所以我在设计时始终把“操作效率”放在前面比如默认值、快速选择、表单联动这些细节比一个高性能接口更让人感到顺手。还有就是如果你准备拿这套源码做毕业设计千万别把“运行成功”当成终点。答辩老师更喜欢听到你讲“为什么要这么设计”。比如为什么用JWT而不是session为什么库存扣减要放在事务里为什么病历和诊断要分开存储。这些设计背后的“为什么”才是项目真正的价值所在。源码和文档给你提供了基础但你理解透彻之后才能从容应对各种追问。最后再分享一个平时很容易被忽略的小技巧数据库设计和开发过程中所有时间字段统一使用datetime类型并且在代码中明确时区为东八区。我第一次做这套系统时因为开发机时区跟数据库时区不一致导致病历上的时间显示差了8个小时查了很久才发现是连接串缺了serverTimezone参数。后来我直接在MySQL连接参数里固定了时区前端展示时间也统一格式化这个问题再也没出现过。希望你用这套源码时能避开这些问题更希望你把它改造成属于你自己的东西。本文还有配套的精品资源点击获取
Java电子病历管理系统源码实战：核心设计与二次开发指南
简介电子病历EMR是医疗信息化的核心载体设计时需兼顾业务流程的完整性与数据安全。以Java技术栈为例借助Spring Boot构建后端服务、MyBatis Plus简化持久层操作并通过JWT与RBAC实现接口级的权限管控可显著提升开发效率与系统可维护性。同时基于事务机制和乐观锁确保病历、处方与库存数据的一致性为中小型诊所及科室级应用提供了轻量级解决方案。本文从系统架构出发剖析患者-病历-处方-药品闭环的设计思路并分享环境搭建、核心接口实现、Nginx部署及常见坑点帮助开发者快速掌握此类管理系统的构建方法也为课程设计或毕业设计提供了可直接改造的参考源码。 最近开源了一套Java实现的医院病人电子病历管理系统源码源代码和说明材料都打包好了。很多朋友拿到手第一反应是问“这玩意儿怎么跑起来”“能不能改成自己的毕设”“表和表之间到底什么关系”。今天不聊虚的直接把我做这套系统的整体思路、技术选型、核心模块实现和踩过的坑整理出来希望能让刚接触这个项目的同学少走弯路。这套系统定位不是那种大而全的HIS系统而是聚焦“病人—病历—处方—药品”这条主干业务链。它覆盖了患者基础信息管理、医生接诊、电子病历录入、诊断管理、处方开立、药品库存管理、用户角色权限、操作日志回看等模块。对于中小型诊所、科室级病历管理或者Java Web方向的课程设计、毕业设计这套代码拿来改改就能用比从零搭框架省太多时间。1. 项目概述与整体设计思路1.1 为什么需要一套完整的电子病历管理系统源码电子病历不是普通的增删改查。你去看这个领域的需求就会发现它牵扯到真实的医院就诊流程患者先挂号或者登记医生接诊后写主诉、现病史、既往史、体格检查、辅助检查、初步诊断然后开处方药房配药扣库存。整个过程涉及的角色也很多医生、护士、药师、管理员每个角色能看的数据、能做的操作完全不一样。我去年在帮一家民营门诊做信息化改造的时候市面上现成的轻量级病历系统要么收费贵要么定制不灵活。于是索性自己写了一套把核心模块抽出来整理成开源项目。当时给自己定了几条规矩第一技术栈不要太冷门Java开发的人一看就懂第二业务要闭环不能只做一个病历录入页面就完事第三权限和操作日志必须到位这是医疗系统的基本底线第四代码结构要清爽方便二次开发。这套源码的价值也在这。它不是那种“只能跑demo”的脚手架而是把医生真正会用的流程做了进去。你在学习的时候不只是看几个CRUD接口而是能理解到“一个患者的完整就诊记录是如何在多个角色之间流转的”。1.2 系统核心业务流程与角色权限划分整个系统我按医院常见的组织方式做了三种核心角色管理员、医生、药房人员。实际项目中还可以扩展护士、挂号员、患者自助端但核心闭环只需要这三个角色就能转起来。以一次普通门诊为例完整流程是这样的管理员先维护好科室、药品、医生账号等基础数据。患者登记基本信息生成患者唯一编号。医生登录系统在“接诊列表”里看到待接诊患者点击进入病历编辑页。医生填写病历主表包含主诉、现病史、既往史、检查结果、初步诊断等信息。医生根据诊断开立处方选择药品、填写用法用量和天数。处方保存时系统自动校验库存库存不足会给出提示。药房人员登录后看到待发药处方点击配药后库存扣减。管理员通过操作日志可以跟踪每一步的登录、录入、修改行为。这个流程看起来简单但每一步都牵涉权限校验和状态流转。我在设计时没有用复杂的工作流引擎而是用状态字段和角色注解来控制。因为电子病历系统的核心场景相对固定工作流引擎反而会把项目搞重维护成本也高。角色权限这块我用的是基于RBAC的简化模型用户表、角色表、权限表三张基础表配合Shiro或JWT的注解做方法级拦截。比如医生角色访问药房库存管理接口时会直接被拒绝管理员可以查看所有操作日志。这样设计的好处是很直观后端接口里加一行注解就能控制访问范围不需要在业务代码里到处写if判断。2. 技术选型与关键方案解析2.1 后端Spring Boot MyBatis Plus的取舍与实践做管理系统后端框架我首选Spring Boot这是目前Java生态里整合成本最低的方案。项目用的是Spring Boot 2.x版本JDK1.8即可运行如果你本机是JDK11或者17只要调整spring-boot-starter-parent版本也都没问题。持久层我选择了MyBatis Plus而不是原生MyBatis或者Spring Data JPA。原因很简单这个项目里有很多简单的单表操作比如根据患者ID查病历列表、根据角色ID查用户列表、药品的分页模糊查询。MyBatis Plus的BaseMapper内置了insert、selectById、updateById、deleteById这些常用方法开发效率提升非常明显。但这里有一个容易踩的坑MyBatis Plus的乐观锁插件和分页插件需要手动配置否则注解Version和分页查询不会生效。我最初的版本忘了加MyBatisPlusInterceptor导致分页返回全部数据后来排查了很久才发现是配置缺失。源码里已经把配置写好了位置在config/mybatis/MybatisPlusConfig.java你如果改造成其他项目记得把这两个插件带上。至于为什么不选Spring Data JPA主要是国内医院HIS系统的开发团队熟悉MyBatis生态的占多数而且复杂SQL的手动优化空间更大。病历查询经常要联表过滤MyBatis的XML文件写动态SQL比JPA的Specification要直观。2.2 前端Vue Element UI和前后端分离部署前端部分我选的是Vue 2 Element UI打包后通过Nginx做静态资源托管。为什么不是Vue 3和Element Plus考虑到这套项目要兼容大量老学员、老电脑的环境Vue 2生态稳定资料多遇到问题搜索时答案一眼就能看懂。前后端分离的好处是后端完全以JSON接口方式提供服务只要接口文档清楚前端想换成React或者微信小程序都很容易。我在说明材料里附了一份完整的接口文档每个接口的请求参数、返回结构都有二次开发时可以直接对着文档联调。部署方面前端npm run build之后生成dist目录后端mvn package打出jar包。生产环境用Nginx托管dist目录同时把/api路径反向代理到后端服务的8080端口。这样前端的登录请求会通过Nginx转发到后端不会出现跨域问题也让前后端的访问入口保持一致。3. 核心功能拆解与数据库设计3.1 数据库表设计从患者到病历的完整建模数据库设计是我觉得这个项目最值得看的地方。当时没有盲目追求大而全而是围绕业务闭环设计了9张核心表分别是表名用途说明sys_user系统用户表保存登录账号、密码、角色关联sys_role角色表内置管理员、医生、药房等角色sys_permission权限表保存接口权限或菜单权限标识patient患者信息表姓名、性别、年龄、手机号、身份证等department科室表记录科室名称、位置、电话medical_record病历主表保存一次就诊的完整病历内容diagnosis诊断表保存医生给出的疾病诊断结果prescription处方表记录开方时间、医生、患者、状态prescription_item处方明细表具体药品、剂量、用法、数量drug药品表药品名称、规格、库存量、单价等operation_log操作日志表记录关键操作行为为什么把病历和诊断分开因为一次就诊可能对应多个诊断结论比如“上呼吸道感染”和“扁桃体炎”同时存在。如果只设计一个病历字段存多诊断时只能塞成字符串后续做统计分析非常痛苦。拆成一对多以后医生端可以动态添加多条诊断报表也能按诊断名称聚合。患者表和病历表的关系也是一对多。患者基本信息独立存储每次就诊生成一条新的病历记录这样既能保证患者历史的就诊轨迹完整又避免在病历表里重复存姓名、身份证号等冗余数据。考虑到系统规模和部署环境我主键用的是自增Long类型。如果你的项目未来要做分库分表可以把主键改成雪花ID算法基于MyBatis Plus的IdType ASSIGN_ID切换代价很小。源码里也预留了相关配置。3.2 病历主表与处方明细的事务一致性设计电子病历系统里最需要小心的一个场景医生保存整份病历的同时还要保存诊断列表和处方明细。任何一步失败都可能导致患者信息不完整。我采用的是Spring的Transactional声明式事务。病历表、诊断表、处方表、处方明细表的插入操作放在同一个事务方法里任何一个异常都会整体回滚。这个设计保证了数据库一致性但也带来了一个性能隐患如果处方明细非常大事务持锁时间会变长。所以我在代码里对病历内容做了长度校验防止一次性提交大量文本。药品库存扣减这块源码里有一个专门的StoredProcedure思路但其实是用了“乐观锁扣减”的简化版。sql语句如下UPDATE drug SET stock stock - #{quantity} WHERE id #{drugId} AND stock #{quantity}这样通过受影响行数判断库存是否足够如果返回0就说明库存不足直接抛业务异常。这个方案比先查出来再判断要安全天然规避了并发扣减时的超卖问题。另外病历历史版本的问题也值得提一下。医疗场景下医生修改病历后系统应该保留修改痕迹。我的实现比较轻量在medical_record表里增加了update_time字段但没有做完整的版本表。如果你的项目答辩时被问到这个问题可以补充一张medical_record_history表在更新前把旧记录插入历史表。这样既保留痕迹又不会让主表数据膨胀到影响查询性能。4. 从0到1实操源码运行与核心模块实现4.1 环境准备与本地快速启动拿到源码后先看根目录下的README和数据库脚本我建议按这个顺序启动项目安装JDK 1.8并配置好JAVA_HOME环境变量。安装Maven 3.6配置阿里云镜像加快依赖下载速度。安装MySQL 5.7创建一个名为hospital_emr的数据库执行sql/hospital_emr.sql脚本。搭建Node.js 14环境用npm install安装前端依赖。打开后端application.yml修改数据库用户名密码。启动后端mvn spring-boot:run。启动前端npm run serve。访问前端地址默认管理员账号 admin / 123456。这里有几个常见的环境变量配置问题我在说明材料里用专门篇幅写了。比如Windows下JAVA_HOME配置后仍然提示找不到Java通常是Path里没有添加%JAVA_HOME%\bin。还有MySQL 8.0连接时需要改驱动类名和URL时区参数否则启动会报Server returns invalid timezone。如果遇到直接参考文档里的配置片段即可。4.2 登录认证与权限控制落地登录模块是这套系统所有功能的入口我用了JWT 自定义注解的方式来实现无状态认证。用户登录成功后后端生成一个JWT令牌其中包含用户ID、用户名、角色编码有效期设置为8小时。前端把token存在localStorage里每次请求时在请求头里带上Authorization字段。后端通过拦截器解析token并设置当前登录用户的上下文。密码安全方面千万不能用明文。源码中使用的是BCrypt加密即使数据库泄露攻击者也很难反推出原始密码。用户表里password字段保存的是BCrypt哈希串每次登录时用BCryptPasswordEncoder的matches方法校验。方法级权限控制我用了一个自定义注解RequireRole例如PostMapping(/medical-record) RequireRole({DOCTOR, ADMIN}) public Result saveRecord(RequestBody MedicalRecordDTO dto) { return medicalRecordService.save(dto); }拦截器会从JWT里解析出角色编码和注解里的角色集合比对不匹配就直接返回403 JSON。这套方案比Spring Security的过滤器链轻量代码更容易理解对新手来说也更友好。4.3 病历录入与处方开立的核心接口实现病历保存的Service层代码是整个项目业务逻辑最复杂的一部分我写了一个比较清晰的接口public Long createRecord(MedicalRecordDTO dto) { MedicalRecord record new MedicalRecord(); BeanUtils.copyProperties(dto, record); record.setDoctorId(UserContext.getUserId()); record.setStatus(COMPLETED); medicalRecordMapper.insert(record); if (CollectionUtils.isNotEmpty(dto.getDiagnosisList())) { for (DiagnosisDTO diagnosisDTO : dto.getDiagnosisList()) { Diagnosis diagnosis new Diagnosis(); diagnosis.setRecordId(record.getId()); diagnosis.setName(diagnosisDTO.getName()); diagnosis.setIcdCode(diagnosisDTO.getIcdCode()); diagnosisMapper.insert(diagnosis); } } if (CollectionUtils.isNotEmpty(dto.getPrescriptionList())) { for (PrescriptionDTO prescriptionDTO : dto.getPrescriptionList()) { Prescription prescription new Prescription(); prescription.setRecordId(record.getId()); prescription.setDoctorId(record.getDoctorId()); prescription.setPatientId(record.getPatientId()); prescription.setStatus(WAIT_DISPENSING); prescriptionMapper.insert(prescription); // 插入药品明细并扣减库存 } } return record.getId(); }这里有一个容易被忽略的细节病历对象的createTime和updateTime字段我是在数据库层面用DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP来自动维护的。这样代码里不需要每次都手动set时间也不会出现时区错乱的怪问题。医生前端录入时主诉、现病史这些文本框我做了字数限制和必填校验。虽然前端校验体验不错但后端依然要做一遍统一校验我用的是JSR 303注解比如NotBlank、Size确保绕过前端提交脏数据也不会进入数据库。4.4 部署上线与Nginx反向代理配置如果想要部署到服务器我的建议是使用Docker Compose源码里提供了docker-compose.yml示例涵盖MySQL、后端服务、前端Nginx三个容器。Nginx配置的关键部分是这样server { listen 80; server_name hospital.example.com; root /usr/share/nginx/html; index index.html; location /api/ { proxy_pass http://backend:8080/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }需要重点提醒的是proxy_pass末尾的斜杠问题。如果proxy_pass后面不带URI比如写http://backend:8080请求会原样转发如果带了/api/Nginx会替换匹配到的location前缀。很多新手在这里配置错误导致接口404。我在说明材料里用红字标注了但线上交流时还是经常会有人踩到这个坑。5. 高频问题排查与避坑经验5.1 后端启动与运行期间的常见报错报错信息原因分析解决思路java.lang.OutOfMemoryError: insufficient memoryJVM堆内存设置不足或者是分页查询一次性加载太多数据开发环境在IDEA里调大VM options生产环境使用-Xms512m -Xmx1024m同时检查代码避免把大列表直接返回Server returns invalid timezoneMySQL 8.0的时区设置问题数据库连接URL加上serverTimezoneAsia/ShanghaiMyBatis Plus分页查询返回全部数据缺少分页插件配置确认MybatisPlusInterceptor配置生效Access denied for user rootlocalhost数据库账号密码错误或远程连接权限不足检查application.ymlMySQL中授权远程访问CORS跨域问题前端端口与后端端口不一致开发环境配置代理生产环境用Nginx同源转发内存溢出这个问题我实际遇到过一次比较典型的场景。报表统计模块里把某个时间段的所有病历都加载到内存再过滤数据量一大就直接OutOfMemoryError。后来改成使用SQL聚合查询只返回统计结果内存瞬间就下来了。所以在有大量数据的业务里尽量让数据库算完再返回不要把大表整个load进Java堆。5.2 开发期容易忽略的安全与审计细节医疗数据属于敏感数据哪怕只是课程设计也应该从早期就养成安全习惯。第一所有涉及患者姓名的列表接口后端都需要做越权校验不能出现A医生登录后能查到B医生的患者隐私。源码里通过查询条件强制加上doctor_id限制而不是只靠前端隐藏。第二SQL注入的防护。MyBatis里写动态SQL时排序字段、表名这类不能用#{}代替的必须做白名单校验。比如排序字段只允许传入name、createTime否则直接返回默认排序。源码里所有模糊查询使用Like函数的参数拼接没有用${}拼接。第三操作日志记录。病例修改、处方删除、权限变更这类敏感操作必须留着痕迹。我实现了一个基于AOP的日志切面在日志注解的方法执行后自动记录操作人、操作时间、请求IP、方法名称和参数摘要。这样管理员在审计时能追踪到具体是谁在什么时候改了什么数据。5.3 前后端联调中的Bug定位技巧前后端分离项目联调阶段最容易出现的问题是“前端明明调用了接口后端却收不到”。遇到这种情况我推荐先打开浏览器F12看Network面板确认请求是否真的发出去请求URL是否正确请求头是否带了token。如果前端报跨域错误要看后端拦截器是否允许OPTIONS预检请求很多JWT拦截器没有放行OPTIONS导致前端实际请求一直失败。另一个常见的低级问题是端口冲突。后端8080被占用时可以换一个端口但记得前端代理配置也要同步修改。源码里统一通过环境变量读取服务端口不用改代码就能切换配置。6. 如何高效使用说明材料与二次开发扩展6.1 说明材料里有哪些可以直接用的内容这套源码附带的说明材料不是简单的README而是包含了一份完整的数据库字典、接口文档和部署手册。数据库字典逐个表解释字段含义和枚举值接口文档包含请求示例和响应示例部署手册则涵盖了Windows本地运行和Linux服务器部署两个场景。对这些材料我的建议是先读部署手册把项目跑起来再对着数据库字典看表结构。等你能从患者登记到药房发药完整走通一遍流程后再去看接口文档这样理解会更加立体。千万不要一开始就扎进代码细节里容易被mapping和service绕晕。6.2 基于这套源码可以扩展的方向二次开发方向很多我见过有人加了预约挂号模块让患者在小程序端选科室、选医生、选时间段后台生成待接诊记录也有人加了检查检验管理对接检验仪器上传的数值结果还有人把原来的用户角色扩展成五级增加了护士站和收费员。我个人最推荐加的扩展是“数据统计报表”比如医生工作量统计、药品消耗排行、患者年龄段分布。这些功能不需要改动已有表结构只要在SQL里做聚合查询即可而且给毕业设计答辩加分非常明显。做报表时你才会体会到提前在每个表里保存create_time和update_time是多么明智。这些都是统计的天然维度后期不需要回补数据。另外一个有意义的扩展是电子病历模板管理。现实中医生输入病历有固定的话术结构比如“主诉现病史既往史体格检查”。你可以增加一个模板表把常用词句存成模板医生录入时一键填充。这个功能在真实门诊使用频率极高开发难度也不大。7. 最后分享几点做这类系统的体会花了大半年时间从设计到编码再把这套系统开源出来我自己最大的体会是做一个管理系统业务理解比技术炫技重要得多。你可以用各种高深的技术把系统做得很花哨但如果医生录入一份病历要点十几次鼠标护士找药房要重新打字那这个系统上线也只会被嫌弃。所以我在设计时始终把“操作效率”放在前面比如默认值、快速选择、表单联动这些细节比一个高性能接口更让人感到顺手。还有就是如果你准备拿这套源码做毕业设计千万别把“运行成功”当成终点。答辩老师更喜欢听到你讲“为什么要这么设计”。比如为什么用JWT而不是session为什么库存扣减要放在事务里为什么病历和诊断要分开存储。这些设计背后的“为什么”才是项目真正的价值所在。源码和文档给你提供了基础但你理解透彻之后才能从容应对各种追问。最后再分享一个平时很容易被忽略的小技巧数据库设计和开发过程中所有时间字段统一使用datetime类型并且在代码中明确时区为东八区。我第一次做这套系统时因为开发机时区跟数据库时区不一致导致病历上的时间显示差了8个小时查了很久才发现是连接串缺了serverTimezone参数。后来我直接在MySQL连接参数里固定了时区前端展示时间也统一格式化这个问题再也没出现过。希望你用这套源码时能避开这些问题更希望你把它改造成属于你自己的东西。本文还有配套的精品资源点击获取