16436基于SpringBoot和vue的医院患者档案管理系统---------免费课设毕设源码分享

原创于 2026-11-09 10:00:00 发布 · 192 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文设计并实现了一个基于SpringBoot后端、Vue前端和MySQL数据库的B/S架构医院患者档案管理系统。系统支持普通用户、医生、护士和管理员四类角色，覆盖预约挂号、就诊记录、住院安排、护理任务、检查申请、健康档案及出院管理等全业务流程。通过功能测试验证了各模块运行稳定、权限隔离清晰、数据一致闭环，满足基层医院患者档案数字化管理需求。

摘要

　　医疗信息化建设大大改变了医院的经营和服务方式，患者档案的高效管理是医院提高服务质量的主要需求。传统的纸质档案管理方式在信息检索、数据共享、多角色协同等各方面都存在着明显的不足，不能满足现代医院业务规模扩大化的需要。本文就医院患者档案管理场景展开设计并创建了基于SpringBoot以及Vue的Web管理系统。系统采用B/S架构，后端用SpringBoot为核心框架，前端用Vue构建交互界面，数据持久层用MySQL数据库。系统包含普通用户、医生用户、护士用户、管理员四种角色，可以进行预约挂号、就诊记录管理、住院安排、护理任务、检查申请、费用信息、健康档案、出院信息等全部业务流程的处理。经过功能测试和系统验证后发现各个模块运行正常，业务流程完整闭环，可以满足医院日常患者档案管理的需求。

关键词：患者档案管理；SpringBoot；Vue；MySQL；医院信息系统

Abstract

　　he advancement of medical informatization has profoundly transformed hospital operations and service delivery models. The efficient management of patient medical records has become a core requirement for improving hospital service quality. Traditional paper-based record management methods have significant shortcomings in information retrieval, data sharing, and multi-role collaboration, making it difficult to adapt to the expanding scale of modern hospital business.

　　This paper designs and implements a web-based management system for hospital patient records, built onSpringBootand Vue. The system adopts a B/S architecture, withSpringBootas the core backend framework, Vue for the interactive frontend interface, and MySQL as the data persistence layer. The system covers four types of roles: ordinary users, doctor users, nurse users, and administrators, supporting a complete business chain including appointment registration, medical visit record management, hospitalization arrangements, nursing tasks, examination applications, expense information, health records, and discharge information.

　　After functional testing and system verification, all modules operate stably with complete and closed business processes, meeting the practical needs of daily patient record management in hospitals.

Key words:Patient Record Management;SpringBoot; Vue; MySQL; Hospital Information System

第一章绪论

1.1 研究背景与意义

1.1.1 研究背景

　　医疗行业数字化转型不断发展，医院管理信息系统也从原来的大量纸质记载转变为精细化的信息化平台。随着患者数量的不断增加和诊疗流程的日益繁杂，传统的档案管理方式在数据准确、检索快、跨科室信息共享等各方面的矛盾越来越明显[1]。患者在就诊时所产生挂号信息、诊断结果、住院安排、护理任务、检查申请、费用清单等互相联系在一起，任何一个环节的信息断层都会对诊疗连续性和患者安全造成影响。现有的部分医院仍然采用手工填报、分散存档的方式，造成数据重复，给医生、护士、管理人员之间的协作工作带来了很大的障碍[2]。国外及国内的研究表明，创建以患者为中心的电子档案管理平台，可以明显减少信息流转所耗费的时间，改善多角色之间的协作效率[3]。以SpringBoot为基础的后端服务框架和Vue前端技术已经很成熟，给创建响应速度快、界面友好的Web端医疗档案系统提供良好的技术支持。在此背景下，设计并实现一个面向医院场景的患者档案管理系统，有很强的现实意义和技术可行性。

1.1.2 研究意义

　　患者档案信息化管理系统建立以后，可以将挂号、就诊、住院、护理、出院等各个业务环节的数据汇总到一个平台上，消除各个业务环节之间存在的信息孤岛。医生可以在系统里随时调出患者的以往就诊记录和健康档案，护士利用护理任务模块按时做好床位安排及护理记载，管理员对全院的用户账号以及业务数据实施统一监管，各个角色的权限明确，操作路径清楚。系统落地应用可以降低纸质档案存储成本、减少人工录入错误，给医院决策层提供可追溯的业务数据支撑。从行业角度来说，该系统的方案可以给规模相似的基层医疗机构提供低成本信息化改造的参考范本，具有一定的社会推广价值和示范作用。

1.2 国内外研究现状

1.2.1 国内现状

　　国内医院信息化建设始于上世纪九十年代，初期主要是从财务管理、药品库存入手。进入21世纪以后，以患者为中心的电子病历系统逐渐兴起，医院信息系统由原来的单点功能发展成业务集成，包括门诊、住院、护理、检查等全部的诊疗过程。近些年来，前后端分离架构以及移动端接入的流行，又促使医疗信息平台的交互体验和数据安全性不断改善。

　　黄娟于2023年设计出一个基于SpringBoot和Vue.js的医院数据提取管理平台，用钉钉小程序规范了数据申请、审核流程，采用前后端分离的方式提高了信息科数据处理的规范化程度[4]，其平台化思想给本系统业务流程设计提供一定的参考。黄赛英于2023年提出基于Java语言和MySQL数据库的Springboot结构医院档案管理系统，主要论证了档案关系流程标准化的路径[5]，其档案分类管理、权限控制的设计方法给本系统的角色权限体系划分提供了一些思路。黄鹏、晋文聪、李明桂（2025）以B/S架构为基础，用Spring Boot和Vue开发出医疗器械管理系统，对操作人员和器械信息进行了全面的管理[6]，多角色权限分配和后端接口设计的经验，给本系统管理员模块功能设计提供直接借鉴。

1.2.2 国外现状

　　国外对于医疗信息系统的研究开始的比较早，基本上是智能化、标准化、去中心化的发展方向。Web端患者管理平台的创建受到广泛的关注，研究方向涉及电子病历的安全存储、患者数据的访问控制、系统并发性能的提升等诸多方面，技术手段越来越多样，业务场景更加接近真实的临床情况。

　　2024年Marbella等人创建了一个基于Web的患者管理信息系统，包含队列管理、预约、病历、提醒、医疗操作这五个主要部分，在研究过程中提到响应式设计和API系统集成属于以后改进的重点方向，其模块化分层的设计思路给本系统功能结构划分给予了直接参照[7]。Alyahya和Almaghrabi在2025年提出了一个基于区块链的医疗记录协同管理平台，用智能合约和访问控制策略保证患者的医疗记录是透明的、安全的[8]，他们的以患者为数据主体的权限控制思想给本系统的普通用户档案查看权限设计提供了一些思路。2024年Nasreen和Singh提出BPMT混合模型，把B+树和Merkle树结合起来用在区块链医疗记录的存储上，大大提高了系统的吞吐量以及数据的完整性，他们的研究对于本系统数据库结构的设计也有一定的借鉴意义[9]。Purnama等人的2026年论文建立了一个基于IOTA分布式账本技术的去中心化电子病历管理系统，给患者提供主动授权、撤销访问和指定共享时长的功能，细粒度的患者数据授权机制给本系统健康档案访问模块的设计给予了参照方向[10]。

　　国外对于数据安全、访问控制以及系统性能优化等工程方面的经验有着诸多的积累，在患者数据主权和跨机构的信息共享上也创建起较为完备的理论体系。本文以国内基层医院的实际为出发点，结合以上研究中对于多角色权限管理以及业务模块闭环设计主要的思想，将挂号、就诊、住院、护理、出院等各方面的业务数据放在同一个平台上，保证数据完整的同时给各个用户提供良好的使用体验。

1.3 主要研究内容

　　本文主要工作就是设计并实现一个基于SpringBoot、Vue的医院患者档案管理系统。系统以医院患者档案的全生命周期管理为主线，包含普通用户、医生用户、护士用户、管理员这四种角色完整的业务场景。按照系统工程典型的推进路线开展研究工作，即先对系统应用背景及用户需求进行梳理，确定各个角色的功能边界，完成技术可行性、经济可行性和操作可行性分析，再进入架构设计阶段，确定B/S分层架构方案，规划功能结构、业务流程和数据库概念模型，在模块实现阶段，用SpringBoot构建后端服务接口，用Vue搭建前端交互页面，用MySQL承载业务数据的持久化存储，完成从预约挂号到出院信息管理的全链路功能开发，在数据设计阶段，对核心业务表做概念建模和逻辑结构设计，建立实体之间的关联关系，在最后通过功能测试对系统各个模块进行系统性的验证，保证业务流程完整、数据一致。本文的研究重点是业务逻辑的完全实现以及多角色权限体系的设计，不会对系统高并发、分布式部署做过多的考虑。研究预期结果是医院患者档案管理系统原型，带需求分析文档、数据库设计以及测试报告。整体上采用面向对象的分析和设计方法论，用用例驱动需求、用实体关系建模数据、用分层架构组织代码来为后面各章节的详细论述打下方法基础。

第二章相关技术介绍

2.1 Spring Boot框架

　　SpringBoot是由Pivotal团队在Spring框架的基础上推出的一种快速开发框架，它的主要设计目的就是用自动配置的方式消除传统Spring项目繁琐的XML配置过程。开发者只需要引入对应的starter依赖，框架就可以自动完成Bean的注册、数据源的绑定、端口的配置等工作，大大缩短了项目的搭建时间。闾枫认为SpringBoot内嵌了Tomcat等Web容器，项目可以以可执行Jar包的形式独立运行，不需要再部署应用服务器[11]。

　　医院患者档案管理系统中，SpringBoot完成所有的后端业务逻辑的组织以及对外接口的暴露工作。系统中挂号审核、就诊记录登记、护理任务分配等主要流程都是用SpringBoot的控制器层来接收前端请求，然后经过服务层处理之后再把数据存入到MySQL中。框架所给出的统一异常处理机制以及拦截器配置，给系统安全控制和请求链路追踪赋予了稳固根基。柳伟卫在全栈开发实战研究中又提出SpringBoot和前端框架一起工作可以实现工程上的可行性[12]。

2.2 Vue框架

　　Vue是一个渐进式的JavaScript框架，用以构建用户界面，它的核心理念就是使用组件化的方式进行开发。每个Vue组件都有独立的模板、逻辑和样式，组件之间用props传递数据、用事件机制向上通信，从而使得复杂的页面开发和维护更加清晰。秦冬在对Vue框架应用的分析中认为Vue的响应式数据绑定系统可以自动追踪依赖关系，当数据状态发生改变的时候视图层就会同步更新，不需要手动去操作DOM[13]。

　　本系统用Vue来创建四类用户角色的完整的前端交互界面。医生信息展示页、挂号流程表单、护理任务列表、健康档案详情等页面都用Vue单文件组件来组织，配合Axios完成和SpringBoot后端接口的异步数据交互。赵媛认为组件复用机制使得系统在不同的功能模块之间可以共享查询条件、操作按钮这些通用的界面元素，从而大大降低重复开发的工作量[14]。

2.3 MySQL数据库技术

　　MySQL是目前应用最广泛的开源关系型数据库管理系统，具有稳定的事务支持、成熟的索引机制以及很高的跨平台兼容性，在Web应用中占有很重要的位置。MySQL按照关系模型的范式理论来实现对数据的增删改查操作，用结构化查询语言来完成外键约束和事务机制的实现。郑晓霞等人的数据库原理系统研究，对MySQL在企业级Web应用中所具有的核心优势进行了详细的论述[15]。

　　本系统数据持久层全部使用MySQL来实现。挂号信息、就诊记录、住院安排、护理任务、费用信息等主要业务表之间存在着复杂的关联关系，使用MySQL的JOIN查询以及事务控制可以保证跨表的数据操作是原子性的。周德伟在MySQL数据库基础实例教程中详细论述了怎样对高频查询字段做索引，以提升多条件筛选的时候系统响应的速度[16]。

2.4 B/S结构

　　B/S架构就是浏览器/服务器架构，是Web应用系统最常用的部署方式。在这种架构下，客户端只需要标准浏览器就可以访问系统，不需要安装任何专用的客户端软件，系统的全部业务逻辑和数据管理都集中在服务器端，客户端只做页面渲染和用户交互。程煌认为基于B/S架构的系统设计，把系统的升级维护工作集中到服务器端，用户没有感知到功能更新，运维成本比传统的C/S架构低得多[17]。

　　医院患者档案管理系统使用B/S架构，医生、护士、管理员可以在各自的电脑上用浏览器直接访问系统，不需要安装额外的软件。普通用户可以在任何具有网络连接的设备上进行预约挂号、档案查询等操作，系统具有很强的可访问性以及部署灵活性。十三和尼克陈在大型前后端分离项目实战中又对B/S模式下前后端协作开发的工程规范进行了论证[18]。

第三章系统分析

3.1 可行性分析

3.1.1 技术可行性

　　本系统后端使用SpringBoot框架，前端用Vue构建交互层，数据层使用MySQL进行数据持久化，三个都是目前主流并且文档完善的开源技术，生态成熟、社区活跃。B/S架构分层设计使得前后端职责清楚地划分，各个层之间用RESTful接口进行交互，耦合度小、集成好。开发环境采用的是Java和Node.js的生态，工具链齐全，技术路线总体上可行。

3.1.2 操作可行性

　　系统前端采用Vue创建响应式界面，表单布局清楚，操作路径经过逻辑梳理之后符合医护人员日常工作习惯。查询、筛选、提交等交互操作都有视觉反馈，普通用户不需要专业培训就可以完成挂号预约和档案查看。医生和护士用户的功能菜单是分开的，没有出现无关的操作入口给使用者带来认知上的负担。

3.1.3 经济可行性

　　系统使用的是SpringBoot、Vue、MySQL三个开源免费的工具，不会产生软件授权费用。开发阶段主要的投入就是开发人员的时间成本，硬件依靠现有的服务器设备，不需要专门采购。系统上线后运行维护的主要费用是数据库备份和服务器日常巡检，费用结构比较合理，总建设成本在院方可以承受的范围内，经济可行。

3.2 功能需求分析

3.2.1 普通用户角色功能需求

　　普通用户可以浏览医生信息列表，根据姓名或者科室类型进行查询，查看医生详情页，并且可以发表评论。预约挂号模块中选择就诊日期、输入备注、选择支付方式之后提交预约。挂号信息模块查询历史挂号记录和审核状态，就诊记录模块查看个人就诊历史，住院安排模块按床位编号或者姓名查询住院信息，操作路径清楚。如图3-1所示。

图3-1普通用户用例图

3.2.2 医生用户角色功能需求

　　医生用户可以在系统中查看和修改自己的信息。预约申请审核、就诊登记模块，即挂号信息管理模块。在就诊记录管理模块里查看患者就诊信息，做住院登记、病例登记、检查登记以及费用开具等工作。检查申请管理模块中查看各个科室的检查申请并进行审核，各个环节的衔接是完整的。如图3-2所示。

图3-2医生用户用例图

3.2.3 护士用户角色功能需求

　　护士用户登录系统之后可以查看护理任务管理模块中按照床位编号或者用户姓名筛选的任务列表，查看任务详情并完成护理登记操作。健康档案列表模块根据用户的姓名来查找患者的健康档案，查看档案详情的操作流程比较简单。如图3-3为所示。

图3-3护士用户用例图

3.2.4 管理员角色功能需求

　　管理员对系统中的普通用户、医生用户、护士用户这三种用户进行统一的管理，可以对这些用户进行查询、添加、修改、删除以及详情查看等操作。根据医生的姓名以及健康状况对就诊记录进行筛选，对修改、删除、查看详细信息等操作进行处理。出院信息管理模块、护理任务管理模块均可以按照床位编号或者用户姓名进行查询，并且可以对数据进行修改、删除、查看详情等操作，从而达到对全院业务数据的统一管理的目的。如图3-4所示。

图3-4管理员用例图

第四章系统设计

4.1 系统架构设计

　　本系统采用B/S架构创建出完整的分层体系，把用户界面层、应用服务层、数据持久层、系统支持层这四个层次有机地联系起来。用户界面层使用Vue框架来实现，为普通用户、医生用户、护士用户、管理员提供各自权限范围内的交互页面，采用组件化的方式保证页面在不同的角色之间有统一的视觉风格。应用服务层用SpringBoot为主，依靠自动配置和内嵌的Web容器对外提供基于RESTful风格的业务接口，对挂号审核、就诊记录管理、护理任务分配、费用开具等主要业务逻辑进行处理。数据持久层用MySQL数据库存储所有的业务实体数据，用标准的SQL做多表关联查询和事务控制。系统支持层包含本地开发环境、JDK运行时和基础工具链，给上层应用稳定运行提供底层支持。各层之间使用统一的接口规范进行通信，层次分明，职责单一，有利于以后的功能扩展和维护。系统架构图如下图4-1所示。

图4-1系统架构图

4.2 系统功能结构设计

　　本系统以医院患者档案管理为核心业务，设计出包含普通用户、医生用户、护士用户、管理员四个角色的完整的功能体系。普通用户主要是患者自助服务平台，即医生信息浏览、挂号、预约挂号、挂号信息查询、就诊记录查看、住院安排查询等。医生用户以诊疗操作为主线，包括医生信息管理、挂号信息管理、就诊记录管理、检查申请管理等模块。护士用户主要针对床位护理场景，有护理任务管理和健康档案列表两个主要模块。管理员是全局数据监管者，对用户管理、就诊记录管理、出院信息管理、护理任务管理等业务数据进行统一维护。该系统的功能结构图如图4-2所示。

图4-2系统功能结构图

4.3 系统流程设计

4.3.1 预约挂号流程设计

　　普通用户进入预约挂号模块后，系统首先验证用户登录状态。用户选择目标医生，填写预约日期与备注信息，提交预约申请。系统判断所选医生当日挂号名额是否充足：名额不足时提示用户重新选择；名额充足时进入支付环节，用户选择支付方式完成付款后，系统生成挂号记录。预约挂号流程图如图4-3所示。

图4-3预约挂号流程图

4.3.2 挂号审核流程设计

　　医生用户进入挂号信息管理模块，查看待审核的预约申请列表。医生对申请内容进行审核判断：若申请信息存在问题则驳回，系统将审核结果回写至挂号记录；若审核通过，系统更新审核状态，医生随后可执行就诊登记操作，将挂号信息转化为就诊记录。挂号审核流程图如图4-4所示。

图4-4挂号审核流程图

4.3.3 就诊记录管理流程设计

　　医生用户进入就诊记录管理模块，按医生姓名或健康状态筛选目标记录。查看就诊详情后，医生判断患者是否需要住院：需要住院则执行住院登记操作，系统关联生成住院申请记录；不需要住院则根据实际情况执行病例登记、检查登记或开具费用操作，各分支操作完成后系统同步更新就诊记录状态。就诊记录管理流程图如图4-5所示。

图4-5就诊记录管理流程图

4.3.4 护理任务执行流程设计

　　护士用户登录系统后进入护理任务管理模块，按床位编号或用户姓名查询待执行任务。系统展示任务列表，护士选择具体任务查看详情，判断当前任务是否具备执行条件：条件不满足时系统提示，护士返回任务列表等待；条件满足时护士执行护理登记操作，填写护理详情后提交，系统记录护理结果并更新任务状态。护理任务执行流程图如图4-6所示。

图4-6护理任务执行流程图

4.3.5 出院信息管理流程设计

　　管理员进入出院信息管理模块，按床位编号或用户姓名查询目标出院记录。系统返回匹配的出院信息列表，管理员查看记录详情。管理员判断信息是否需要修改：需要修改则进入编辑页面更新相关字段，保存后系统确认数据变更；不需要修改则可直接执行删除操作，系统完成数据清理后刷新列表。出院信息管理流程图如图4-7所示。

图4-7出院信息管理流程图

4.4 数据库设计

4.4.1 概念模型设计

　　医院患者档案管理系统的数据关系涉及患者、医生、护士等多类主体，各主体在诊疗过程中产生的业务数据相互关联，构成复杂的多对多与一对多联系网络。概念模型设计的本质是将现实世界中的业务对象抽象为信息世界中的实体，将实体之间的业务关联表达为联系，完成从需求到数据模型的第一次形式化转换。系统在识别核心实体的基础上，为每个实体提取完整的属性集合，并依据业务规则确立实体之间一对一、一对多、多对多的联系类型。用于可视化表达上述抽象结果的工具为E-R图，即实体-联系图。普通用户发起预约产生挂号信息，挂号信息经医生审核后转化为就诊记录，就诊记录中可衍生检查申请、住院申请、费用信息、病程记录等多类从属实体；护士用户依据护理任务执行护理记录，任务数据与住院安排实体直接关联；健康档案作为患者个人信息的持久载体，贯穿诊疗全流程。基于上述分析绘制的全局E-R模型能够完整反映系统的全域数据结构，为后续逻辑模型设计提供依据[19]。全局E-R模型如图4-8所示。

图4-8全局ER图

　　根据系统分析，系统的主要实体有：普通用户、医生信息、医生用户、护士用户、挂号信息、就诊记录、检查申请、住院安排、护理任务、出院信息，各个实体具体的属性如下图所示。

　　（1）普通用户实体主要包括普通用户id、用户姓名、用户年龄、用户性别、审核状态等。如图4-9所示。

图4-9普通用户实体属性图

　　（2）医生信息实体主要包括医生信息id、医生姓名、科室类型、擅长领域、挂号费用等。如图4-10所示。

图4-10医生信息实体属性图

　　（3）医生用户实体主要包括医生用户id、医生姓名、医生年龄、医生性别、审核状态等。如图4-11所示。

图4-11医生用户实体属性图

　　（4）护士用户实体主要包括护士用户id、护士工号、护士姓名、护士性别、审核状态等。如图4-12所示。

图4-12护士用户实体属性图

　　（5）挂号信息实体主要包括挂号信息id、医生用户、用户姓名、预约日期、审核状态等。如图4-13所示。

图4-13挂号信息实体属性图

　　（6）就诊记录实体主要包括就诊记录id、医生姓名、用户姓名、就诊时间、健康状态等。如图4-14所示。

图4-14就诊记录实体属性图

　　（7）检查申请实体主要包括检查申请id、医生姓名、科室类型、检查内容、审核状态等。如图4-15所示。

图4-15检查申请实体属性图

　　（8）住院安排实体主要包括住院安排id、床位编号、医生姓名、用户姓名、入住时间等。如图4-16所示。

图4-16住院安排实体属性图

　　（9）护理任务实体主要包括护理任务id、床位编号、用户姓名、护士用户、任务日期等。如图4-17所示。

图4-17护理任务实体属性图

　　（10）出院信息实体主要包括出院信息id、床位编号、用户姓名、医生姓名、出院日期等。如图4-18所示。

图4-18出院信息实体属性图

4.4.2 数据库表设计

　　关系数据库的逻辑设计阶段将概念模型中的实体与联系转化为具体的关系模式，每个实体对应一张数据库表，实体属性映射为表的字段，实体间的联系通过外键约束加以体现。本系统依据第三范式对各业务表进行结构规范化处理，消除字段间的传递依赖，降低数据冗余程度。胡劲在数据库信息管理系统的逻辑架构研究中指出，合理的逻辑设计能够在保证数据完整性的前提下提升查询效率，是系统稳定运行的基础保障[20]。系统核心业务表共筛选十张，涵盖普通用户、医生信息、医生用户、护士用户、挂号信息、就诊记录、检查申请、住院安排、护理任务、出院信息，各表通过用户编号、医生用户编号、普通用户编号等外键字段建立关联关系，数据流向与业务流程保持一致，整体逻辑结构清晰完整。

　　（1）普通用户表主要是用来记录患者的基本注册信息。主要包括普通用户id、用户姓名、用户年龄、用户性别等字段。如表4-1所示。

表4-1普通用户表

序号	字段名	类型	长度	备注
1	ordinary_user_id	int	11	主键
2	user_name	varchar	64	用户姓名
3	user_age	varchar	64	用户年龄
4	user_gender	varchar	2	用户性别
5	examine_state	varchar	16	审核状态
6	user_id	int	11	用户ID
7	create_time	datetime	-	创建时间
8	update_time	timestamp	-	更新时间

　　（2）医生信息表主要是用来存储医生的详细介绍与执业信息。主要包括医生信息id、医生姓名、科室类型、挂号费用等字段。如表4-2所示。

表4-2医生信息表

序号	字段名	类型	长度	备注
1	doctor_information_id	int	11	主键
2	doctors_name	varchar	64	医生姓名
3	department_type	varchar	64	科室类型
4	areas_of_expertise	varchar	64	擅长领域
5	registration_fee	double	-	挂号费用
6	working_time	varchar	64	上班时间
7	doctor_user	int	11	医生用户
8	cover_image	varchar	255	封面图片
9	create_time	datetime	-	创建时间
10	update_time	timestamp	-	更新时间

　　（3）医生用户表主要是用来管理医生账号的基本身份信息。主要包括医生用户id、医生姓名、医生性别、审核状态等字段。如表4-3所示。

表4-3医生用户表

序号	字段名	类型	长度	备注
1	doctor_user_id	int	11	主键
2	doctors_name	varchar	64	医生姓名
3	doctors_age	varchar	64	医生年龄
4	gender_of_doctor	varchar	2	医生性别
5	examine_state	varchar	16	审核状态
6	user_id	int	11	用户ID
7	create_time	datetime	-	创建时间
8	update_time	timestamp	-	更新时间

　　（4）护士用户表主要是用来维护护士账号的身份与审核信息。主要包括护士用户id、护士工号、护士姓名、护士性别等字段。如表4-4所示。

表4-4护士用户表

序号	字段名	类型	长度	备注
1	nurse_user_id	int	11	主键
2	nurse_number	varchar	50	护士工号
3	name_of_nurse	varchar	64	护士姓名
4	gender_of_nurses	varchar	2	护士性别
5	examine_state	varchar	16	审核状态
6	user_id	int	11	用户ID
7	create_time	datetime	-	创建时间
8	update_time	timestamp	-	更新时间

　　（5）挂号信息表主要是用来记录患者预约挂号的完整业务数据。主要包括挂号信息id、医生用户、用户姓名、预约日期、审核状态等字段。如表4-5所示。

表4-5挂号信息表

序号	字段名	类型	长度	备注
1	registration_information_id	int	11	主键
2	doctor_user	int	11	医生用户
3	doctors_name	varchar	64	医生姓名
4	department_type	varchar	64	科室类型
5	registration_fee	double	-	挂号费用
6	ordinary_user	int	11	普通用户
7	user_name	varchar	64	用户姓名
8	appointment_date	date	-	预约日期
9	appointment_remarks	text	200	预约备注
10	examine_state	varchar	16	审核状态
11	pay_state	varchar	16	支付状态
12	pay_type	varchar	16	支付类型

　　（6）就诊记录表主要是用来保存患者每次就诊的诊疗过程数据。主要包括就诊记录id、医生姓名、用户姓名、就诊时间、健康状态等字段。如表4-6所示。

表4-6就诊记录表

序号	字段名	类型	长度	备注
1	visit_records_id	int	11	主键
2	doctor_user	int	11	医生用户
3	doctors_name	varchar	64	医生姓名
4	ordinary_user	int	11	普通用户
5	user_name	varchar	64	用户姓名
6	department_type	varchar	64	科室类型
7	visit_time	datetime	-	就诊时间
8	health_status	varchar	64	健康状态
9	diagnostic_results	text	200	诊断结果
10	create_time	datetime	-	创建时间
11	update_time	timestamp	-	更新时间

　　（7）检查申请表主要是用来记录医生为患者提交的检查申请及审核状态。主要包括检查申请id、医生姓名、科室类型、检查内容、审核状态等字段。如表4-7所示。

表4-7检查申请表

序号	字段名	类型	长度	备注
1	check_application_id	int	11	主键
2	doctor_user	int	11	医生用户
3	doctors_name	varchar	64	医生姓名
4	department_type	varchar	64	科室类型
5	ordinary_user	int	11	普通用户
6	check_contents	text	200	检查内容
7	date_of_inspection	date	-	检查日期
8	examine_state	varchar	16	审核状态
9	create_time	datetime	-	创建时间
10	update_time	timestamp	-	更新时间

　　（8）住院安排表主要是用来记录患者入院后的床位分配与住院管理信息。主要包括住院安排id、床位编号、医生姓名、用户姓名、入住时间等字段。如表4-8所示。

表4-8住院安排表

序号	字段名	类型	长度	备注
1	hospitalization_arrangements_id	int	11	主键
2	bed_number	varchar	30	床位编号
3	doctor_user	int	11	医生用户
4	doctors_name	varchar	64	医生姓名
5	ordinary_user	int	11	普通用户
6	user_name	varchar	64	用户姓名
7	check_in_time	datetime	-	入住时间
8	check_in_remarks	text	200	入住备注
9	create_time	datetime	-	创建时间
10	update_time	timestamp	-	更新时间

　　（9）护理任务表主要是用来分配护士对住院患者的日常护理工作。主要包括护理任务id、床位编号、用户姓名、护士用户、任务日期等字段。如表4-9所示。

表4-9护理任务表

序号	字段名	类型	长度	备注
1	nursing_tasks_id	int	11	主键
2	bed_number	varchar	30	床位编号
3	ordinary_user	int	11	普通用户
4	user_name	varchar	64	用户姓名
5	nurse_user	int	11	护士用户
6	task_date	date	-	任务日期
7	task_specificss	text	200	任务详情
8	create_time	datetime	-	创建时间
9	update_time	timestamp	-	更新时间

　　（10）出院信息表主要是用来登记患者出院时的相关手续与信息汇总。主要包括出院信息id、床位编号、用户姓名、医生姓名、出院日期等字段。如表4-10所示。

表4-10出院信息表

序号	字段名	类型	长度	备注
1	discharge_information_id	int	11	主键
2	bed_number	varchar	30	床位编号
3	ordinary_user	int	11	普通用户
4	user_name	varchar	64	用户姓名
5	doctor_user	int	11	医生用户
6	doctors_name	varchar	64	医生姓名
7	discharge_date	date	-	出院日期
8	discharge_remarks	text	200	出院备注
9	create_time	datetime	-	创建时间
10	update_time	timestamp	-	更新时间

第五章系统实现

5.1 普通用户角色功能实现

5.1.1 医生信息

　　医生信息模块主要是对系统内全部医生的展示数据进行浏览与检索。用户在该模块中输入医生姓名或选择科室类型后触发查询，系统返回匹配的医生列表并支持排序与筛选操作。用户点击列表条目进入详情页后，可完整查看该医生的执业介绍、擅长领域及挂号费用信息，并可在详情页发表评论或执行点赞、收藏操作，系统对上述操作均给出即时状态反馈。医生信息界面如图5-1所示。

图5-1医生信息界面

　　普通用户通过医生信息模块查看医生详情并进行互动。前端请求由DoctorInformationController处理，调用getObj方法获取医生信息，同时通过PraiseController、CollectController和CommentController记录用户的点赞、收藏和评论操作。这些控制器继承BaseController，利用通用查询方法实现数据交互。

　　核心代码实现如下：

DoctorInformation doctor_information = new DoctorInformation(); doctor_information.setDoctor_user(paramMap.get("doctor_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("doctor_user")))); doctor_information.setDoctors_name(paramMap.get("doctors_name")==null?null:String.valueOf(paramMap.get("doctors_name"))); doctor_information.setDepartment_type(paramMap.get("department_type")==null?null:String.valueOf(paramMap.get("department_type"))); doctor_information.setRegistration_fee(paramMap.get("registration_fee")==null?null:Double.valueOf(String.valueOf(paramMap.get("registration_fee"))));

5.1.2 预约挂号

　　预约挂号模块主要是对患者的挂号预约申请进行提交与支付处理。用户在该模块中选择目标医生、填写预约日期并输入备注内容后，选择微信、支付宝或网银中的一种支付方式进行确认。系统接收提交后校验当前医生的挂号名额状态，名额充足时记录预约信息并生成待审核挂号单，名额不足时系统返回提示信息，用户可重新选择日期后再次提交，操作流程与状态反馈保持清晰对应。预约挂号界面如图5-2所示。

图5-2预约挂号界面

　　用户提交预约挂号时，前端调用RegistrationInformationController的add方法。该方法读取请求参数，封装成RegistrationInformation实体，并调用addEntity持久化数据，同时设置审核状态为“未审核”、支付状态为“未支付”。系统自动记录预约日期和备注信息。

　　核心代码实现如下：

RegistrationInformation registration_information = new RegistrationInformation(); registration_information.setDoctor_user(paramMap.get("doctor_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("doctor_user")))); registration_information.setDoctors_name(paramMap.get("doctors_name")==null?null:String.valueOf(paramMap.get("doctors_name"))); registration_information.setAppointment_date(parseToTimestamp(timStr)); registration_information.setAppointment_remarks(paramMap.get("appointment_remarks")==null?null:String.valueOf(paramMap.get("appointment_remarks"))); registration_information.setExamine_state("未审核");

5.1.3 挂号信息

　　挂号信息模块主要是对用户已提交的历史预约记录进行查询与状态跟踪。用户可按医生姓名、审核状态、支付状态输入查询条件进行精确筛选，重置按钮可一键清空全部筛选条件。系统根据查询参数返回对应的挂号记录列表，用户点击列表中的详情按钮可查看该条挂号的完整信息，包括预约时间、科室、审核进度及支付状态，操作路径简洁直观。挂号信息界面如图5-3所示。

图5-3挂号信息界面

　　用户查询挂号信息时，后端通过RegistrationInformationController的getList方法返回列表。用户可根据医生姓名、审核状态、支付状态进行筛选，并调用updateExamineState方法修改审核状态、updatePayState方法修改支付状态。系统根据ID更新对应字段。

　　核心代码实现如下：

Map<String,String> queryMap = new HashMap<>(); queryMap.put("id",String.valueOf(id)); RegistrationInformation registration_information = service.findOne(queryMap); if (registration_information!=null) { registration_information.setExamine_state(newState); this.setEntity(queryMap,new HashMap<>(),registration_information); }

5.1.4 就诊记录

　　就诊记录模块主要是对用户个人的历史就诊信息进行检索与查阅。用户在该模块中可输入医生姓名或选择健康状态作为筛选条件，系统返回符合条件的就诊记录列表。用户点击具体记录进入详情页，可查看该次就诊的诊断结论、就诊时间及对应科室信息，页面支持重置操作以恢复默认列表视图，整体交互逻辑流畅清晰。就诊记录界面如图5-4所示。

图5-4就诊记录界面

　　就诊记录模块由VisitRecordsController管理。用户提交就诊记录时调用add方法，将医生信息、患者信息、健康状态及就诊内容存入数据库。系统支持按医生姓名和健康状态查询，并展示详细记录。

　　核心代码实现如下：

VisitRecords visit_records = new VisitRecords(); visit_records.setDoctor_user(paramMap.get("doctor_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("doctor_user")))); visit_records.setDoctors_name(paramMap.get("doctors_name")==null?null:String.valueOf(paramMap.get("doctors_name"))); visit_records.setHealth_status(paramMap.get("health_status")==null?null:String.valueOf(paramMap.get("health_status"))); visit_records.setVisit_time(parseToTimestamp(timStr)); visit_records.setContents(paramMap.get("contents")==null?null:String.valueOf(paramMap.get("contents")));

5.1.5 住院安排

　　住院安排模块主要是对用户当前或历史住院信息进行查询与详情查看。用户在该模块中可输入床位编号或用户姓名进行检索，系统返回匹配的住院安排记录列表。用户点击列表中的详情按钮后，页面展示该次住院的床位分配、入住时间、主治医生及相关备注信息，重置操作可还原列表至初始状态，查询路径明确，信息呈现完整。住院安排界面如图5-5所示。

图5-5住院安排界面

　　住院安排模块通过HospitalizationArrangementsController实现。用户查看住院安排时，后端调用getList方法返回床位编号、用户姓名等数据。系统支持按床位编号和用户姓名查询，并展示详情。

　　核心代码实现如下：

HospitalizationArrangements hospitalization_arrangements = new HospitalizationArrangements(); hospitalization_arrangements.setBed_number(paramMap.get("bed_number")==null?null:String.valueOf(paramMap.get("bed_number"))); Map<String, String> mapbed_number = new HashMap<>(); mapbed_number.put("bed_number",String.valueOf(paramMap.get("bed_number"))); List listbed_number = service.selectBaseList(service.select(mapbed_number, new HashMap<>())); if (listbed_number.size()>0){ return error(30000, "字段床位编号内容不能重复"); }

5.2 医生用户角色功能实现

5.2.1 医生信息管理

　　医生信息管理模块主要是对医生自身的执业信息进行查询与更新维护。医生用户在该模块中可按医生姓名或科室类型进行信息检索，系统返回匹配的记录条目。医生选择目标记录后可进入详情查看页，核实当前信息的完整性；若需更新信息，则进入修改页面对相关字段进行编辑，提交后系统完成数据更新，修改结果即时反映在列表视图中。医生信息管理界面如图5-6所示。

图5-6医生信息管理界面

　　医生用户通过DoctorInformationController的set方法修改个人信息。系统根据查询条件定位记录，将前端提交的医生姓名、科室类型、擅长领域等参数更新到数据库，并返回成功状态。

　　核心代码实现如下：

5.2.2 挂号信息管理

　　挂号信息管理模块主要是对患者提交的预约挂号申请进行审核与就诊登记处理。医生用户可按医生姓名、审核状态、支付状态筛选待处理的挂号记录，选择目标记录后执行审核操作，系统将审核结果回写至挂号信息表。审核通过的记录支持就诊登记操作，医生完成登记后系统生成对应的就诊记录，审核与登记两个操作节点状态均在列表页实时更新。挂号信息管理界面如图5-7所示。

图5-7挂号信息管理界面

　　医生对挂号信息进行审核时，前端调用RegistrationInformationController的updateExamineState方法。该方法根据挂号信息ID修改examine_state字段，支持“未审核”“已通过”“未通过”三种状态切换，并返回审核结果。

　　核心代码实现如下：

if (!newState.equals("未审核") && !newState.equals("已通过") && !newState.equals("未通过")) { return "非法的审核状态"; } Map<String,String> queryMap = new HashMap<>(); queryMap.put("id",String.valueOf(id)); RegistrationInformation registration_information = service.findOne(queryMap); registration_information.setExamine_state(newState); this.setEntity(queryMap,new HashMap<>(),registration_information);

5.2.3 诊记录管理

　　就诊记录管理模块主要是对患者就诊过程中产生的诊疗数据进行管理与后续操作处理。医生用户通过姓名或健康状态筛选目标记录，进入详情后可根据患者实际情况选择执行住院登记、病例登记、检查登记或费用开具操作，各操作分支相互独立。系统在医生完成每项操作后即时更新就诊记录的关联数据状态，操作结果可在详情页直接核查，数据流转路径清晰完整。就诊记录管理界面如图5-8所示。

图5-8就诊记录管理界面

　　就诊记录管理模块使用VisitRecordsController的set方法。医生可以修改患者的健康状态、诊断结果，并触发住院登记、病例登记、开具费用、检查登记等子操作。系统根据记录ID更新对应字段。

　　核心代码实现如下：

VisitRecords visit_records = new VisitRecords(); visit_records.setDoctor_user(paramMap.get("doctor_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("doctor_user")))); visit_records.setHealth_status(paramMap.get("health_status")==null?null:String.valueOf(paramMap.get("health_status"))); visit_records.setDiagnostic_results(paramMap.get("diagnostic_results")==null?null:String.valueOf(paramMap.get("diagnostic_results"))); visit_records.setVisit_time(parseToTimestamp(timStr)); this.setEntity(queryMap,configMap,visit_records);

5.2.4 检查申请管理

　　检查申请管理模块主要是对来自各科室的检查申请进行审核处理。医生用户在该模块中可按医生姓名或科室类型筛选检查申请列表，点击目标条目进入详情页查看检查内容与申请信息。医生根据申请内容的完整性与合理性执行审核操作，审核通过或驳回的结果由系统即时同步至申请记录，相关状态字段在列表视图中实时刷新，审核流程完整可追溯。检查申请管理界面如图5-9所示。

图5-9检查申请管理界面

　　医生提交检查申请后，通过CheckApplicationController的add方法保存申请数据，包括检查日期、检查内容等。管理员或医生可调用updateExamineState方法审核申请，更新审核状态字段。

　　核心代码实现如下：

CheckApplication check_application = new CheckApplication(); check_application.setDoctor_user(paramMap.get("doctor_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("doctor_user")))); check_application.setDoctors_name(paramMap.get("doctors_name")==null?null:String.valueOf(paramMap.get("doctors_name"))); check_application.setDate_of_inspection(parseToTimestamp(timStr)); check_application.setCheck_contents(paramMap.get("check_contents")==null?null:String.valueOf(paramMap.get("check_contents"))); check_application.setExamine_state("未审核");

5.3 护士用户角色功能实现

5.3.1 护理任务管理

　　护理任务管理模块主要是对护士负责的床位护理工作任务进行查询与执行登记。护士用户在该模块中可输入床位编号或用户姓名筛选待执行任务列表，点击具体任务进入详情页核实任务内容与执行要求。确认具备执行条件后，护士在护理登记表单中填写护理详情并提交，系统记录护理结果并更新任务状态，重置操作可还原查询条件至默认状态。护理任务管理界面如图5-10所示。

图5-10护理任务管理界面

　　护士用户通过NursingTasksController查看护理任务，并调用NursingRecordsController的add方法完成护理登记。登记时记录床位编号、患者信息、护理具体内容和登记日期。系统支持按床位编号和用户姓名查询任务。

　　核心代码实现如下：

NursingRecords nursing_records = new NursingRecords(); nursing_records.setBed_number(paramMap.get("bed_number")==null?null:String.valueOf(paramMap.get("bed_number"))); nursing_records.setOrdinary_user(paramMap.get("ordinary_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("ordinary_user")))); nursing_records.setRecord_date(parseToTimestamp(timStr)); nursing_records.setCare_specificss(paramMap.get("care_specificss")==null?null:String.valueOf(paramMap.get("care_specificss"))); this.addEntity(nursing_records);

5.3.2 健康档案列表

　　健康档案列表模块主要是对住院患者的个人健康档案数据进行查询与查阅。护士用户在该模块中输入用户姓名后触发检索，系统返回匹配的健康档案记录列表。护士点击具体条目进入详情页，可查看患者的过敏史、病史记录、紧急联系人及详情备注等完整档案信息，重置按钮用于清空当前查询条件并恢复完整列表视图，操作简洁高效。健康档案列表界面如图5-11所示。

图5-11健康档案列表界面

　　健康档案列表由HealthRecordController提供。护士用户可查看患者的健康档案，包括年龄、性别、过敏史、既往病史等。前端支持按用户姓名查询，后端调用getList方法返回数据。

　　核心代码实现如下：

HealthRecord health_record = new HealthRecord(); health_record.setOrdinary_user(paramMap.get("ordinary_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("ordinary_user")))); health_record.setUser_name(paramMap.get("user_name")==null?null:String.valueOf(paramMap.get("user_name"))); health_record.setAllergy_history(paramMap.get("allergy_history")==null?null:String.valueOf(paramMap.get("allergy_history"))); health_record.setHistory_record(paramMap.get("history_record")==null?null:String.valueOf(paramMap.get("history_record"))); this.addEntity(health_record);

5.4 管理员角色功能实现

5.4.1 用户管理

　　用户管理模块主要是对系统内普通用户、医生用户、护士用户三类账号信息进行统一维护。管理员在该模块中可输入用户编号或用户姓名进行检索，系统返回匹配的账号列表。管理员可对列表中的账号执行添加、修改、删除、详情查看操作，新增用户时需填写基本身份信息，修改操作完成后系统即时刷新列表数据，三类用户的管理界面结构一致，操作规范统一。用户管理界面如图5-12所示。

图5-12用户管理界面

　　管理员通过OrdinaryUserController、DoctorUserController和NurseUserController管理三类用户。以普通用户为例，add方法新增用户，set方法修改信息，delete方法删除用户，并通过getList方法支持按用户姓名查询。

　　核心代码实现如下：

OrdinaryUser ordinary_user = new OrdinaryUser(); ordinary_user.setUser_name(paramMap.get("user_name")==null?null:String.valueOf(paramMap.get("user_name"))); ordinary_user.setUser_age(paramMap.get("user_age")==null?null:String.valueOf(paramMap.get("user_age"))); ordinary_user.setUser_gender(paramMap.get("user_gender")==null?null:String.valueOf(paramMap.get("user_gender"))); ordinary_user.setUserId(paramMap.get("user_id")==null?null:Integer.valueOf(String.valueOf(paramMap.get("user_id")))); this.addEntity(ordinary_user);

5.4.2 就诊记录管理

　　就诊记录管理模块主要是对系统内全部就诊数据进行监管与维护操作。管理员在该模块中可按医生姓名或健康状态筛选就诊记录列表，选择目标记录后可进入详情页查看完整就诊信息。管理员可对记录执行修改操作以更正信息偏差，亦可执行删除操作清理无效数据，操作完成后系统同步刷新列表视图，全部数据变更均有操作时间戳记录，便于后续核查。就诊记录管理界面如图5-13所示。

图5-13就诊记录管理界面

　　管理员对就诊记录拥有修改和删除权限。VisitRecordsController的set方法允许更新健康状态、诊断结果等内容，delete方法移除记录。系统支持按医生姓名和健康状态筛选数据。

　　核心代码实现如下：

VisitRecords visit_records = new VisitRecords(); visit_records.setHealth_status(paramMap.get("health_status")==null?null:String.valueOf(paramMap.get("health_status"))); visit_records.setDiagnostic_results(paramMap.get("diagnostic_results")==null?null:String.valueOf(paramMap.get("diagnostic_results"))); visit_records.setVisit_time(parseToTimestamp(timStr)); visit_records.setContents(paramMap.get("contents")==null?null:String.valueOf(paramMap.get("contents"))); this.setEntity(queryMap,configMap,visit_records);

5.4.3 出院信息管理

　　出院信息管理模块主要是对患者出院时登记的信息记录进行维护管理。管理员在该模块中可输入床位编号或用户姓名进行检索，系统返回符合条件的出院信息列表。管理员可对目标记录执行修改操作更新出院备注或相关字段，亦可执行删除操作移除错误数据，各操作完成后系统反馈操作结果并刷新列表，数据准确性与完整性得到有效保障。出院信息管理界面如图5-14所示。

图5-14出院信息管理界面

　　出院信息模块由DischargeInformationController处理。管理员调用add方法登记出院信息，set方法修改出院日期和备注，delete方法删除记录。前端支持按床位编号和用户姓名查询。

　　核心代码实现如下：

DischargeInformation discharge_information = new DischargeInformation(); discharge_information.setBed_number(paramMap.get("bed_number")==null?null:String.valueOf(paramMap.get("bed_number"))); discharge_information.setOrdinary_user(paramMap.get("ordinary_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("ordinary_user")))); discharge_information.setDischarge_date(parseToTimestamp(timStr)); discharge_information.setDischarge_remarks(paramMap.get("discharge_remarks")==null?null:String.valueOf(paramMap.get("discharge_remarks"))); this.addEntity(discharge_information);

5.4.4 护理任务管理

　　护理任务管理模块主要是对全院护理任务的分配数据进行监管与维护。管理员在该模块中可按床位编号或用户姓名筛选护理任务列表，选择目标记录后可查看任务的详细分配信息。管理员可对任务记录执行修改操作调整任务内容，亦可执行删除操作清理失效任务数据，操作完成后系统同步更新列表状态，任务数据的完整性与准确性在管理员的统一监管下得到保障。护理任务管理界面如图5-15所示。

图5-15护理任务管理界面

　　护理任务管理使用NursingTasksController。管理员可新增、修改、删除护理任务，任务包含床位编号、患者姓名、任务日期和具体内容。系统提供按床位编号和用户姓名的查询功能。

　　核心代码实现如下：

NursingTasks nursing_tasks = new NursingTasks(); nursing_tasks.setBed_number(paramMap.get("bed_number")==null?null:String.valueOf(paramMap.get("bed_number"))); nursing_tasks.setOrdinary_user(paramMap.get("ordinary_user")==null?null:Integer.valueOf(String.valueOf(paramMap.get("ordinary_user")))); nursing_tasks.setTask_date(parseToTimestamp(timStr)); nursing_tasks.setTask_specificss(paramMap.get("task_specificss")==null?null:String.valueOf(paramMap.get("task_specificss"))); this.addEntity(nursing_tasks);

第六章系统测试

6.1 测试目的

　　软件测试是系统上线之前不可缺少的质量检验工作。本系统测试的主要目的是对业务逻辑和设计规格进行拟合度验证，主要检验挂号审核、就诊记录流转、护理任务执行、出院信息管理等主要业务链路各个操作节点数据一致性和功能完整性。赵聚雪等人的研究认为，软件测试要对正常流程和边界异常两种情况进行测试才能控制上线风险[21]。对多角色权限体系进行测试时还要检验各个角色在功能访问边界上是否被隔离正确，保证各个角色的操作行为符合设计要求。

6.2 测试方法

　　本系统用功能测试和黑盒测试相结合的方式来对各个功能模块进行系统的验证。黑盒测试不关心系统内部实现的细节，只从用户的操作角度来输入测试数据，检验系统输出的结果和预期是否相符，适合于业务流程的全部链条的覆盖。

　　按照各个角色的操作路径，测试人员对预约挂号、挂号审核、就诊登记、护理登记、出院管理等业务节点做正常的、异常的、边界值的用例类型测试数据进行测试。测试结果通过与预期结果比较来得出结论，所有的测试用例执行状态都用表格的形式记录下来，测试过程可以追溯。

6.3 测试用例

　　本节针对系统七个核心业务模块设计测试用例，验证各模块在典型操作场景下的功能正确性与业务逻辑准确性。

　　预约挂号模块测试：该模块验证患者完成预约流程的全链路正确性，重点关注日期选择、支付方式提交、名额校验等关键判断节点的系统响应准确性。如表6-1所示。

表6-1预约挂号测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
正常预约提交	验证完整信息提交后系统生成挂号记录	选择医生、日期、支付方式后提交	生成待审核挂号单	符合预期
名额不足提示	验证挂号名额不足时系统提示机制	选择已满额日期后提交	系统返回名额不足提示	符合预期
缺少必填项提交	验证必填字段校验逻辑	不选支付方式直接提交	页面提示必填项未填写	符合预期

　　挂号审核模块测试：该模块验证医生对预约申请执行审核操作时的状态流转准确性，重点关注审核通过与驳回两条路径的数据回写正确性。如表6-2所示。

表6-2挂号审核测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
审核通过操作	验证审核通过后状态字段更新	选择待审核记录执行通过操作	审核状态更新为已通过	符合预期
审核驳回操作	验证审核驳回后状态字段更新	选择待审核记录执行驳回操作	审核状态更新为已驳回	符合预期
就诊登记操作	验证审核通过后可执行就诊登记	对已通过记录执行就诊登记	生成就诊记录条目	符合预期

　　就诊记录管理模块测试：该模块验证医生对就诊记录执行多类型操作时各分支路径的数据一致性，关注住院登记、检查登记、费用开具等操作的关联数据生成准确性。如表6-3所示。

表6-3就诊记录管理测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
住院登记操作	验证住院登记后关联住院申请生成	在就诊详情页执行住院登记	系统生成住院申请记录	符合预期
检查登记操作	验证检查登记后检查申请数据写入	在就诊详情页执行检查登记	系统生成检查申请条目	符合预期
健康状态筛选	验证按健康状态筛选的查询准确性	选择特定健康状态执行查询	列表仅显示对应状态记录	符合预期

　　护理任务管理模块测试：该模块验证护士执行护理登记操作时任务状态更新的准确性，以及多条件查询场景下的列表筛选正确性。如表6-4所示。

表6-4护理任务管理测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
床位编号查询	验证按床位编号筛选任务列表	输入床位编号执行查询	列表返回对应床位的任务	符合预期
护理登记提交	验证护理登记后任务状态更新	填写护理详情后提交登记	系统记录护理结果并更新状态	符合预期
重置操作验证	验证重置后列表恢复默认视图	查询后点击重置按钮	筛选条件清空，列表完整显示	符合预期

　　健康档案列表模块测试：该模块验证护士按用户姓名查询患者健康档案时的检索准确性，以及档案详情数据的完整呈现情况。如表6-5所示。

表6-5健康档案列表测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
姓名精确查询	验证精确姓名查询返回准确记录	输入完整姓名执行查询	系统返回对应患者档案	符合预期
详情页数据完整性	验证档案详情页数据完整呈现	点击目标记录进入详情页	过敏史、病史等字段完整显示	符合预期

　　用户管理模块测试：该模块验证管理员对三类用户账号执行增删改查操作时的数据正确性，重点关注新增与删除操作对列表数据的即时更新效果。如表6-6所示。

表6-6用户管理测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
新增用户操作	验证新增用户后数据写入准确性	填写用户信息后提交添加	新用户记录出现在列表中	符合预期
删除用户操作	验证删除操作后列表数据更新	选择目标用户执行删除	目标记录从列表中移除	符合预期
姓名查询操作	验证按姓名筛选的检索准确性	输入用户姓名执行查询	列表仅返回匹配用户	符合预期

　　出院信息管理模块测试：该模块验证管理员对出院记录执行修改与删除操作时的数据一致性，以及多条件查询场景下系统的响应准确性。如表6-7所示。

表6-7出院信息管理测试用例表

测试项	测试目的	测试步骤	预期结果	实际结果
修改出院信息	验证修改操作后字段数据更新	进入修改页面更新字段后保存	修改内容在列表中即时更新	符合预期
删除出院记录	验证删除操作后数据从列表移除	选择目标记录执行删除操作	记录从列表中消失	符合预期
床位编号查询	验证按床位编号筛选出院记录	输入床位编号执行查询	返回对应床位的出院信息	符合预期

测试结论

　　按照系统测试用例执行结果，预约挂号模块的正常预约提交、名额不足提示、缺少必填项提交三项测试都符合预期；挂号审核模块的审核通过、审核驳回、就诊登记操作都符合预期；就诊记录管理模块的住院登记、检查登记、健康状态筛选都符合预期；护理任务管理模块的床位编号查询、护理登记提交、重置操作都符合预期；健康档案列表模块的姓名精确查询、详情页数据完整性都符合预期；用户管理模块的新增用户、删除用户、姓名查询都符合预期；出院信息管理模块的修改出院信息、删除出院记录、床位编号查询都符合预期。所有七个主要业务模块测试用例的实际结果与预期结果完全相符，没有出现任何由于功能异常或者数据不符所引发的问题。系统对于预约挂号、挂号审核、就诊记录流转、护理任务执行、健康档案查阅、用户账号管理、出院信息管理等业务链路工作正常，各个角色的权限范围清楚，数据状态的变化也及时准确。

总结

　　医院患者档案管理系统研究与开发，意在解决传统纸质档案模式下信息检索速度慢、多角色数据共享难、业务流程协同差等主要问题。系统的完成是预定设计目标基本实现的结果，给医院患者档案数字化管理提供了一个行之有效的工具平台。

　　系统从需求分析开始，确定了普通用户、医生用户、护士用户、管理员四个角色的功能边界，然后完成B/S架构的总体规划以及数据库概念模型、逻辑模型的设计工作。编码实现阶段采用SpringBoot创建后端服务接口、Vue创建前端交互界面、MySQL存储数据，三者各司其职、互不干涉，业务模块包括了预约挂号、挂号审核、就诊记录、检查申请、住院安排、护理任务、费用信息、出院管理等各个方面。经过功能测试后发现各个模块的业务流程稳定，数据一致，测试用例通过率满足要求。

　　系统目前还存在着一些不足之处，移动端的适配工作还没有做好，用户在小屏设备上操作的体验不好，系统缺少数据统计和可视化功能，管理层不能直接了解整个业务状况，同时并发处理能力在极端访问情况下也有一定的限制，并没有使用缓存来优化高频查询。

　　之后可以继续做如下改进工作，针对移动端加强响应式布局设计，改善各种设备的访问体验，加入图表统计功能模块，给管理员显示就诊量、床位利用率等重要指标的可视化展示，尝试加入缓存层来加强系统的并发处理能力。系统成功落地给基层医疗机构信息化改造提供一定的参考价值，随着功能不断改善，其应用范围和社会效益也会得到进一步扩展。

参考文献

[1] 赵克坚,成晓岚,蔡联荟,等.基于MySQL数据库的医院投诉处置软件开发与应用[J].医院管理论坛,2025,42(4):87-89+60.

[2] 吴小静,吴旭丽,高小燕.融合Spring与Vue框架在医院挂号系统设计中的应用[J].自动化技术与应用,2025,44(10):177-180.

[3] 马绍阳,王伟东,韩斌倩,等.基于SpringBoot+Vue的智能远程医疗平台的设计与实现[J].网络安全技术与应用,2024(1):55-57.

[4] 黄娟.基于SpringBoot和Vue.js的医院数据提取管理平台的设计与实现[J].信息与电脑(理论版),2023,35(22):91-93.

[5] 黄赛英.基于Springboot的医院档案管理系统设计[J].集成电路应用,2023,40(11):384-385.

[6] 黄鹏,晋文聪,李明桂.基于SpringBoot和Vue的医疗器械管理系统的设计与实现[J].信息与电脑,2025,37(2):155-157.

[7] Marbella HN,AkbarIA,SetiawanB.Designand development of a web-based patient management information system[J].ProcediaComputer Science,2024,234:1-8.

[8] AlyahyaS,AlmaghrabiZ.Blockchain-Based Cooperative Medical Records Management System[J].Computers,2025,14(10):1-20.

[9] NasreenM,SinghSK.BPMT:A hybrid model for secure and effective electronic medical record management system[J].Journalof Computational Science,2024,83:1-15.

[10] PurnamaH,SudewaI P BH,NizamiT,etal.AccessControl Development Within the Framework of an IOTA-Based Electronic Medical Record Management System[J].Sensors,2026,26(5):1-18.

[11] 闾枫.Spring Boot项目开发教程[M].北京:人民邮电出版社,2022:264.

[12] 柳伟卫.Vue.js+SpringBoot全栈开发实战[M].北京:人民邮电出版社,2023:484.

[13] 秦冬.浅析Vue框架在前端开发中的应用[J].信息与电脑(理论版),2024,36(13):61-63.

[14] 赵媛.基于Vue的Web系统前端性能优化分析[J].电脑编程技巧与维护,2024,45(9):44-46.

[15] 郑晓霞,张艳艳,刘超.MySQL数据库原理及应用[M].北京:人民邮电出版社,2024:302.

[16] 周德伟.MySQL数据库基础实例教程[M].北京:人民邮电出版社,2024:222.

[17] 程煌.基于B/S架构的网上招聘系统的设计与研究[C].武汉:武汉市创读时代出版策划有限公司,2020:10-22.

[18] 十三,尼克陈.SpringBoot+Vue3大型前后端分离项目实战[M].北京:电子工业出版社,2023:719.

[19] 曾辉.关系数据库技术在计算机网络设计中的应用[J].信息与电脑(理论版),2023,35(14):206-208.

[20] 胡劲.数据库信息管理系统的逻辑架构与功能设计探析[J].电脑知识与技术,2023,19(19):96-98.

[21] 赵聚雪,杨鹏,郑楚锋.软件测试管理与实践[M].北京:人民邮电出版社,2024:218.

致谢

　　这篇论文的完成，比我预想的要难得多。

　　从选题到最后定稿，经过数月的反复推翻、重新整理的过程，比出现在纸面上的文字要曲折得多。导师在全过程里给予耐心的引导，每次提交草稿之后得到的修改意见，起初觉得繁琐，后来回想起来才明白批注背后所蕴含的逻辑，即学术写作的严谨性不是自然而然形成的，而是在一次次的纠偏中逐渐形成的。对此无以为报，只有把论文写得更扎实一些作为回应。

　　系统开发过程中出现过很多让人非常沮丧的卡顿。一段时间后前后端数据联调一直不能跑通，反复查看日志、修改接口参数，连续数个夜晚都在同一个问题上耗时。最后找到原因的时候，并没有特别强烈的成就感，更多的是"终于可以继续了"的平静。这是四年里实验室零星积累起来的感受，不需要戏剧化的时刻，做完、做对才是目标本身。

　　家人没有直接过问论文的进展情况，但是每隔一段时间会寄来问候，成为那段高密度工作期间唯一可以让人稍微休息一下的事情。他们不懂SpringBoot，也不需要懂，只要在那里就好。

　　四年本科的学习将要结束。带走的不只是一个文凭或者一套系统，还有无数次从头再来中慢慢养成的一点点耐心。这份耐心一直起作用。

标签