基于Web的社区医院管理服务系统设计与实现要点

每年毕设在Web方向里，最容易被选走一类的题目就是“某某管理系统设计与实现”。“基于Web的社区医院管理服务系统”就是其中典型的一个。我去年接触过几个在这个题目上挣扎的同学，也帮人完整复盘过一个能正常答辩的版本。说实话，这个题目看起来普通，但做深做浅差别很大。有人用纯静态页糊弄，也有人真做出来能在社区卫生院试用的系统。如果你正在为这个课题发愁，这篇内容可以把选题定位、需求拆解、技术选型、数据库设计、前后端实现、部署演示的完整链路全部理清楚。

这个系统本质上要解决的问题不复杂：社区医院没有大医院那么强的信息化预算，但同样有挂号、门诊、药房、收费、统计这些日常流程。用Web系统替代纸质记录和Excel表格，就是“管理服务系统”的核心价值。它不太考验算法和性能，更多考验你对业务流程的理解、对工程结构的把握，以及把系统真正跑起来的能力。各个层次的同学都能在这类题目里找到能拿分的部分。

1. 为什么选这个课题：社区医院的痛点与Web化机会

1.1 社区医院和大医院的系统需求差在哪里

大医院的信息化系统往往是全院级产品，涉及HIS、LIS、PACS等一堆专业系统，模块非常多，权限层级也复杂。社区医院则明显不一样，科室数量少，人员结构相对扁平，患者流程更短。一个社区卫生院常见的业务也就是：患者进门挂号、找医生看诊、医生开处方、患者去药房取药或去收费处结算。听起来简单，但是这些环节目前在很多基层医疗机构里仍然靠纸质处方和手工台账运转。

如果你做过实地调研，会发现一个很典型的现象：药房人员在一堆纸质处方里翻找患者姓名，收费员在Excel里登记流水，医生写病历完全靠打字和打印。这些问题就是“管理服务系统”需要解决的。系统要取代的不是复杂的医疗逻辑，而是这些环节中的信息登记、流转和查询问题。

所以说，这个课题的定位不是“做一个医院管理系统”，而是“做一个适合社区医院规模的管理服务系统”。你不需要去做床位管理、手术排期、检验设备对接，但你需要把挂号、门诊、处方、药房、收费这条核心链路闭环。理解这个边界，后面做需求分析时才不会想当然地越做越大。

1.2 为什么用Web而不是桌面客户端

很多人在技术选型上会先纠结一句“为什么是基于Web”。如果你去看过去十年的毕设，早期的门诊系统确实有很多是C/S架构，用C#、VB、Delphi做客户端，数据库直连。这类系统在局域网里能跑，但一提到“部署”就很麻烦，每台电脑都要装客户端，系统更新要一台一台处理。

社区医院里的电脑配置层次不齐，使用人员年纪也偏大。Web方案最大的优势是：出问题不需要现场装软件。部署方只要把服务端装好，其他电脑打开浏览器输入地址就能用。IT管理员不用天天跑去各个窗口升级。

另外，从课题展示的角度看，Web系统也更好演示。答辩现场只需要一台能上网的电脑或笔记本，不用提前在内网环境里各种折腾。当前主流的开发框架也天然偏向Web，Spring Boot、Vue的生态非常成熟，能查到大量资料，遇到问题不至于卡死。

1.3 课题的合理规模：别把毕设做成大厂项目

我经常和学生强调一句话：毕设的目标是证明你掌握了完整开发流程，不是证明你能开发一个商业产品。社区医院管理服务系统的合理规模是2到3个核心业务模块贯通，而不是十几个模块一拥而上。

常见的合规做法是围绕一条主业务线展开：患者→挂号→医生接诊→开处方→药房发药→收费结算。再把用户管理、科室管理、药品管理、统计报表作为辅助模块。这样整个系统的功能边界非常清晰，写开题报告和论文时也容易把逻辑讲圆。如果有人想再加住院管理、排队叫号、检验检查，那就要掂量一下自己的开发时间了。以小见大、闭环完整，才是这个课题最聪明的做法。

2. 需求分析与业务建模：挂号、门诊、药房三条主线

2.1 角色梳理：先从“谁在用”开始

做需求分析不能一上来就画用例图，先搞清楚系统里有哪些角色。社区医院的服务系统至少需要这几类角色：

• 患者：通常不是直接登录系统的，而是在前台被登记或注册个人信息，完成挂号。可以做患者自助查询功能，但没必要强制患者注册复杂账号。
• 前台/挂号员：负责患者建档、挂号、退号、收费。
• 医生：查看当日挂号患者、书写病历、诊断、开具处方、查看历史病历。
• 药房人员：查看待发药处方、确认发药、维护药品库存。
• 系统管理员：管理科室、用户、药品分类、系统参数、查看统计报表。

每个角色的操作权限都不同。比如医生不能改药品价格，药房人员不能改病历，管理员不管具体业务。设计角色和权限时，要让Controller和页面菜单都能基于角色做隔离，这部分在答辩时很能加分。

2.2 核心模块拆解：从预约到统计的功能清单

模块划分建议按照信息流向来做，而不是按技术分层。以我的项目经验，下面这几个模块是必做的：

• 系统管理：用户登录、修改密码、用户管理、角色权限管理。
• 基础资料管理：科室信息、医生信息、药品目录、疾病诊断目录（可选）。
• 患者管理：患者基本信息登记、档案查询、历史就诊记录。
• 预约挂号管理：线上/线下预约、当日挂号、号源数量控制、退号。
• 门诊管理：医生接诊、病历书写、诊断结果、处方开具。
• 药房管理：处方审核、库存扣减、药品入库、近效期预警。
• 收费管理：按处方金额结算、收费记录查询、退费处理。
• 统计报表：按日/周/月统计挂号量、科室接诊量、药品消耗，以及收费流水汇总。

如果时间充裕，还可以增加一个简单的公告通知模块，但这些模块不要平均用力。预约挂号、门诊、药房是业务主线，必须做扎实。统计报表可以做简单版，查询出来给管理员看图表即可。基础资料管理通常是“先有数据才能干活”，也建议早点完成。

2.3 数据状态设计：每个单据都要有生命周期

业务系统里最容易被忽略的，是单据的状态流转。挂号单不能一直是“已预约”；处方也不能一直是“待发药”。你需要为每一类核心单据设计状态字段和允许的状态跳转。

比如挂号单的状态可以设计为：

• 已预约：患者预约了某个医生，但还没到院。
• 已取号/已签到：到院确认，进入排队。
• 就诊中：医生开始接诊。
• 已完成：就诊结束，处方开具完成。
• 已退号：取消预约或挂号。
• 已过号：号源作废（可以允许医生操作“重新签到”）。

处方单的状态与之配套：

• 待医生提交：草稿状态。
• 待缴费：医生已提交，患者尚未结算。
• 已缴费/待发药：收费完成，药房可以准备药品。
• 已发药：药品发放完成。
• 已退费：患者退药退费。

这些状态字段要对应到代码里的枚举或者常量类。写接口时，不能允许从“已预约”直接跳到“已发药”，必须在服务层做校验。这些细节写在论文和答辩PPT里，会显得你非常专业。

3. 技术选型与工程结构：Spring Boot + Vue的落地组合

3.1 技术栈不是越新越好，得看稳定性和资料量

我的建议是直接用你已经学过的主流组合，不要为了炫技引入没有把握的框架。“基于Web的社区医院管理服务系统”这个课题，最稳妥的搭配是：

如果是个人开发，不建议把微服务、消息队列、分布式事务等概念塞进来。社区医院的数据量和使用人数决定了单体应用完全够用，技术栈越简单，你越容易把控代码质量。

3.2 后端工程结构：按业务模块分包比按技术层分包更清晰

很多同学的Spring Boot项目喜欢用controller、service、mapper这样的一刀切分包方式。这种做法不是错，但在业务模块较多时，查找代码会很分裂。我的习惯是顶层先按业务领域分，每个领域内部再分层。

一个可参考的包结构：

com.example.communityhospital ├── common // 通用返回体、异常处理、常量、工具类 ├── config // 配置类：CORS、拦截器、MybatisPlus分页、Redis ├── security // 登录鉴权、JWT工具、权限注解 ├── module │ ├── auth // 登录、修改密码 │ ├── user // 用户管理、角色管理 │ ├── patient // 患者档案 │ ├── department // 科室管理 │ ├── doctor // 医生坐诊信息 │ ├── registration// 挂号管理 │ ├── outpatient // 门诊病历、处方 │ ├── pharmacy // 药品管理、处方发药、入库 │ ├── charge // 收费、退费 │ └── report // 统计报表 └── CommunityHospitalApplication.java

这样的好处是：每个模块的Controller、Service、Mapper都在自己的包里，改需求的时候只动对应模块，减少跨包跳转。推荐每个实体都配套一个DTO，不要直接把数据库实体暴露给前端，避免字段过多和安全性问题。

3.3 前端工程结构与API调用规范

前端项目建议用Vite初始化，目录可以这样规划：

• src/api：按后端模块封装的请求方法，比如registration.js、charge.js。
• src/router：路由和角色守卫。
• src/views：页面组件，按模块建文件夹。
• src/components：公共组件，比如上传、分页、打印。
• src/store：Pinia中的用户信息、Token状态。
• src/utils：axios实例、日期格式化等工具。

axios实例需要统一处理基础URL、Token注入和业务错误码。比如后端返回的结构统一为{ code: 200, message: "success", data: [...] }，前端拦截器拿到非200的code时统一提示，而不是每个页面都写一遍错误处理。

下面是一个简单的axios封装思路：

import axios from 'axios' import { ElMessage } from 'element-plus' import router from '@/router' const service = axios.create({ baseURL: '/api', timeout: 10000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( response => { const res = response.data if (res.code === 200) { return res } if (res.code === 401) { router.push('/login') return Promise.reject(new Error('登录已过期')) } ElMessage.error(res.message || '请求失败') return Promise.reject(new Error(res.message)) }, error => { ElMessage.error(error.message || '网络异常') return Promise.reject(error) } )

需要注意的是，前端联调时如果本地开发服务器的端口和后端不一致，最好通过Vite的proxy配置解决跨域，而不是在后端随便放行所有来源。生产环境把前端打包后交给Nginx托管，再让Nginx反向代理到后端接口，就不会有跨域问题了。

4. 数据库设计与关键实现：把“可用”做到“能答辩”

4.1 核心数据表：从科室到收费记录的关系梳理

数据库设计是这个课题最容易拿分也最容易扣分的环节。表结构不能堆砌，要用关系把业务串起来。下面这组表是能满足主流程的最小集合：

• sys_user：登录用户表，包含用户名、加密密码、真实姓名、角色ID、状态。
• sys_role：角色表，可以简单做角色ID和角色编码。
• department：科室表，包含科室名称、位置、备注。
• doctor_info：医生信息表，关联user_id和department_id，包含职称、简介、每日号源数量。
• patient：患者表，包含姓名、性别、年龄、身份证号、手机号、建档时间。
• registration：挂号表，包含患者ID、医生ID、科室ID、挂号日期、时段、状态、费用。
• medical_record：病历表，包含挂号ID、患者ID、医生ID、主诉、诊断、病史、医嘱。
• prescription：处方表，关联medical_record_id和patient_id，包含总金额、状态。
• prescription_item：处方明细表，包含药品ID、数量、单价、金额。
• drug：药品表，包含药品编码、名称、规格、单位、库存数量、零售价、生产厂家、有效期。
• charge_record：收费记录表，包含处方ID、患者ID、应收金额、实收金额、收费员ID、收费时间。

注意这些表之间千万不要用逻辑删除把业务搞乱。比如患者删除了，关联的挂号记录还要保留。建议使用deleted字段做逻辑删除，但业务单据表尽量不删除，采用作废/退号状态保留数据，方便写统计报表。

4.2 挂号并发：别让一个医生号源被抢超

社区医院系统的并发量不大，但“号源数量”这种数据必须做原子操作，不能靠两步查询再修改。比如医生每日号源是30人，两个患者同时挂最后1个号，如果先查剩余号再在服务层减1，就可能出现超挂。

最简单的处理方式是使用数据库乐观锁或原子更新。我在项目里常用的做法是“余号”字段使用UPDATE ... SET remaining = remaining - 1 WHERE doctor_id = ? AND date = ? AND remaining > 0，更新受影响行数为1才算挂号成功。这样天然防止超挂。

挂号成功后创建挂号记录，如果后续要支持取消预约，再走“退号”逻辑把余号加回来。这个业务在答辩时非常容易被问到：“你如何处理临界竞争？”你应该直接说出上述原子更新方案，比泛泛谈锁机制有说服力得多。

4.3 处方与库存：事务与状态校验一个都不能少

药房发药是另一个容易出问题的地方。一张处方包含多条药品明细，发药时不能逐条扣库存，因为如果第一条扣成功了、第二条库存不足，就会导致数据不一致。正确的做法是在一个数据库事务里：

1. 校验处方状态为“已缴费/待发药”。
2. 逐条检查药品库存是否充足。
3. 逐条扣减库存。
4. 修改处方状态为“已发药”。
5. 写收费记录或更新发药人。

Spring Boot里使用@Transactional方法，注意一个问题：如果事务方法是在同一个类内部被调用，@Transactional可能会失效。建议把事务控制放在Service实现类，Controller只负责接参数和返回结果。

代码思维示例：

@Transactional(rollbackFor = Exception.class) public void dispense(Long prescriptionId, Long pharmacyUserId) { Prescription p = prescriptionMapper.selectById(prescriptionId); if (p == null || !StatusEnum.PAID.equals(p.getStatus())) { throw new BizException("处方状态不允许发药"); } List<PrescriptionItem> items = prescriptionItemMapper.selectByPrescriptionId(prescriptionId); for (PrescriptionItem item : items) { Drug drug = drugMapper.selectById(item.getDrugId()); if (drug.getStock() < item.getQuantity()) { throw new BizException("药品库存不足：" + drug.getName()); } drugMapper.reduceStock(drug.getId(), item.getQuantity()); } p.setStatus(StatusEnum.DISPENSED.getValue()); prescriptionMapper.updateById(p); }

这里有一点要特别提醒：reduceStock的SQL同样要带上stock >= #{quantity}的条件，否则极少数情况下还是可能扣负数。真正严格的做法是扣减成功后判断返回行数，不为1则抛出异常回滚。

4.4 权限控制与数据安全：答辩时的高频提问点

系统的登录密码必须做加密存储，这个不用多讲，用BCrypt加密即可。JWT生成时可以带上用户ID、角色编码和过期时间，拦截器里校验Token后把当前用户信息放入ThreadLocal，供Service层随时获取。

对于角色权限，最轻量的方式是自定义注解@RequireRole，例如医生接口只允许ROLE_DOCTOR访问。前端路由做动态导航栏过滤，后端接口用注解做二次校验。答辩时你可以明确说明“前端的菜单控制只是体验优化，真正的权限防线在后端”。这句话很加分。

另外要重视的是“接口参数校验”。挂号时患者ID、医生ID是否为null，药品数量是否大于0，病历主诉是否为空，这些都应该用@Validated或手动校验。一个管理系统如果接口随便传非法参数还能入库，那论文里写再多“系统安全性”都会被打折扣。

5. 跨浏览器与部署实战：从本地到云服务器的避坑记录

5.1 跨浏览器支持：别在打印和日期组件上翻车

社区医院的老电脑上浏览器种类很杂，开发时你用的是Chrome，但实际演示的电脑可能装了360安全浏览器、搜狗浏览器甚至老版本Edge。跨浏览器兼容问题主要集中在两个地方：日期控件和打印。

第一个坑是日期格式。很多人习惯直接把后端返回的LocalDateTime序列化成ISO格式字符串，比如2026-05-01T10:30:00，前端用new Date()解析还可以，但直接在表格里展示就不好看。建议后端统一返回自定义格式，比如yyyy-MM-dd HH:mm:ss，在Jackson配置里做全局格式化。

第二个坑是打印。药房和收费处经常需要把小票或处方单打印出来。Vue项目里最简单的方案是打开一个新窗口，把需要打印的内容用window.document.write写进去，再调用window.print()。但这种方案在不同浏览器上对@page样式的支持不一样。稳妥的做法是：单独做一个纯HTML的打印模板页面，不依赖Element Plus组件库渲染，用最基础的表格和CSS实现。这样在各类浏览器上展示效果更一致。

5.2 部署步骤：Nginx托管前端 + Jar包跑后端

部署这个环节很多人会卡住。其实流程固定，按顺序做就不会错。

后端部署：

1. 在服务器安装JDK和MySQL，创建数据库并导入初始化SQL。
2. 在application-prod.yml里修改数据库地址、端口和文件上传路径。
3. 用Maven执行mvn clean package -DskipTests打出Jar包。
4. 使用nohup java -jar community-hospital.jar --spring.profiles.active=prod &启动。
5. 检查日志，确认端口监听和数据库连接正常。

前端部署：

1. 修改vite.config.js里的base: './'，避免资源路径错误。
2. 执行npm run build，生成dist目录。
3. 将dist下的文件上传到Nginx的html目录。
4. 配置Nginx将/api前缀的请求反向代理到本地的后端端口。

Nginx关键配置示例：

server { listen 80; server_name yourdomain.com; root /usr/share/nginx/html; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; 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末尾是否带/会影响路径拼接，最容易踩坑。配置完记得nginx -t测试语法，再systemctl reload nginx。

5.3 演示数据与答辩演示准备

很多同学在功能做好之后忽略了一个重要环节：准备演示数据。系统里空空荡荡，演示时临时录入患者、医生、药品，不仅浪费时间，还展示不出查询和统计功能。

建议你在答辩前准备好一整条业务演示数据，至少包括以下内容：

• 五个以上科室和对应医生，每个医生设置不同的号源数。
• 二十个以上患者档案，手机号和身份证号要看起来真实。
• 五十个以上的药品记录，库存数量要有高有低，方便演示预警功能。
• 过去两周的挂号、病历、处方和收费记录，方便演示统计报表。

演示时走一个完整流程最有说服力：先用管理员创建医生和药品；再以挂号员身份给患者建档并挂号；然后切换到医生账号写病历、开处方；再到收费员账号做结算；最后药房账号确认发药。这个过程能展示多角色协同，也能体现你对系统的熟悉程度。

5.4 评委最爱问的追问与应对思路

答辩时不能只讲“我做了什么”，还要准备回答“为什么这么做”。在你的准备笔记里，这四组问题是几乎必问的：

• “号源怎么保证不超挂？”：用原子更新语句扣减余号，受影响行数为0则挂失败。
• “药品库存和收费不一致怎么办？”：发药和扣库存放在一个事务里，订单状态校验前置，异常全部回滚。
• “医生能看到其他患者的隐私吗？”：通过JWT中的用户ID和角色做接口级校验，查询病历前判断当前登录医生是否有权访问该患者。
• “系统如果卡顿怎么办？”：先解释本项目规模下单体架构足够，再说通过索引优化常用查询、分页查询大列表、以及Redis缓存字典数据。

口径要克制，不要为了应付问题吹嘘自己用了多复杂的中间件。只要基础逻辑扎实，评委一般不会在“为什么不使用微服务”这种问题上过分为难。回答时可以强调“当前的业务规模决定了单体架构是最合适的选择，若未来门诊量增加，可以先从数据库读写分离和服务模块拆分起步”。这种回答既客观又务实。

说实话，做完这套系统再回头看，最大的感受是：毕业设计难的不在代码量，而在“把一件事从头到尾想清楚并闭环”。社区医院管理服务系统的每个模块单独拎出来都不难，但把它们串成一条能用、能演示、能讲清的业务链路，需要你对需求、数据、状态、权限、部署都有真实的把握。如果你能在答辩现场把这个系统完整跑通，还能回答清楚关键设计的原因，这个课题的分数一定不会低。