springboot医养结合管理系统83124-计算机课程设计、毕业设计

第一章 绪论

1.1 研究背景与意义

1.1.1 研究背景

　　老龄化社会加速发展，正改变着医疗健康服务系统结构上的需求。根据国家统计局数据，我国60岁及以上人口比重不断上升，老年慢性病患者数量众多，对于长期健康管理、日常护理和专业医疗等各方面的需求远远大于现有的资源供给能力[1]。传统模式下，医疗机构和养老服务机构各自为政，信息不能互通，老年人在就医、康复、日常护理等各方面忙得不可开交，医养资源的碎片化问题十分严重[2]。同时国家也陆续出台了有关推进医疗卫生与养老服务相结合的指导意见等政策文件，明确提出要将医养结合作为应对老龄化问题的战略性途径，要求把医疗资源和养老资源结合起来，创建起连续、协调的全生命周期健康服务体系。在数字化转型大潮的冲击之下，依靠互联网平台搭建起来的医养结合信息系统开发，成了破解上述困境的重要技术途径[3]。依靠软件系统来完成健康档案的统一管理、医疗预约的在线办理、护理记录的实时采集，可以从根本上改变医养服务供给方式，大大提高资源调配效率，推动以人为中心的整合型健康服务模式的落地。

1.1.2 研究意义

　　本系统将医疗服务与养老护理整合到一个统一的数字化平台中，使得健康档案、医疗预约、康养计划、护理记录等业务数据在同一个系统内部进行流转共享，打破传统模式下信息孤岛的限制。普通用户可以在线预约、查看历史数据、获得AI辅助的健康建议等，从而降低了获取医养服务的门槛；医护人员可以使用结构化的数据录入以及实时的生理指标预警功能，大大减轻了人工管理的工作量，提高了服务响应的速度。系统使用成熟的开源框架组合进行开发，部署成本、维护成本在合理范围之内，适合中小型医养机构推广使用。从宏观的角度来看，本系统的设计思想、功能结构可以给类似医养结合平台的研发提供一个可以复制的模板，对于提高区域医养服务信息化水平整体水平有一定的示范作用。

1.2 国内外研究现状

1.2.1 国内现状

　　国内医养结合信息化建设起步较晚，但是近几年来由于政策的不断推进，相关的研究也逐渐增多。研究方向从最初的单一电子病历管理发展为综合性健康管理平台，系统形态也由原来的单机部署转变为现在的B/S架构，医疗业务和护理业务的数字化整合程度不断提高。

　　袁文燕（2026）对医院档案管理中数字化档案管理信息系统进行了研究，认为传统档案管理模式已经不能满足现代医院的需求，人为因素造成的档案错误影响到患者的就医体验，提出具体的使用策略，该研究对于本系统健康档案模块数据录入规范的设计有直接的借鉴作用[4]。谭倩怡、刘玉芳于2025年利用Java EE平台，使用SSM框架和MySQL数据库设计并实现了一个健康管理系统，前端使用JSP技术和Bootstrap框架来改善交互界面，对亚健康人群的饮食和生活习惯进行管理，该系统的三层架构设计以及数据库结构设计的实践对本系统有借鉴意义[5]。王传政、陈艳秋在2024年用前后端分离架构开发出智慧移动医疗App，用Vue框架创建前端、用Spring Boot框架创建后台，系统分成患者端、医生端、管理员端三类角色，功能包含在线问诊、处方查询和管理等业务，他们的多角色权限划分思路同本系统四类角色的设计非常相似，有着重要的启示意义[6]。

1.2.2 国外现状

　　国外对于医疗信息系统的研究起步较早，技术储备丰富，研究重点已经由原来的实现基本功能向数据安全、隐私保护、智能化服务等深层次问题发展，区块链技术、微服务架构在医疗信息领域应用的探索比较活跃，具有以患者为中心的数据治理特点。

　　Singh等人于2026年提出了一种基于区块链的患者中心型电子健康记录共享架构，使用权益证明共识机制和智能合约技术，很好地解决了医疗数据在跨机构共享过程中遇到的隐私保护、访问控制问题，用患者为中心的数据权限设计思想给本系统用户数据安全策略提供借鉴[7]。2025年Taloba和Rayan提出了一个用区块链的加密角色访问控制医疗数据管理系统，使用多层加密、IPFS存储实现医疗数据安全透明管理的目标，此框架中的角色权限分层思想可以给本系统多角色权限体系提供借鉴[8]。Pampattiwar和Chavan在2025年提出了一种可以扩展的区块链电子健康记录管理系统，使用改进的遗传算法来提高区块链的可扩展性，并且支持科室级的配置以及患者级的数据保密，他们的模块化的设计思想给本系统的功能结构拆分提供了一定的启示[9]。2025年Natarajan等人提出了一种基于量子安全的患者登录凭证系统，采用对称和非对称加密算法以及量子安全信任协议来保证电子健康记录共享的身份认证安全性，其身份认证机制的设计给本系统账户安全策略提供一定的参考[10]。2023年Bai和Liu使用Spring Cloud微服务框架对传统的单体医疗信息系统进行重构，重构后的系统服务调用平均延迟为370ms左右，数据服务提交延迟为240ms左右，负载能力提高了42%，为本系统的后端架构模块化设计提供技术路线参考[11]。

　　国外对于数据安全以及架构弹性方面的研究有着许多成果，在电子健康记录的访问控制以及跨机构共享方面已经形成起较为完备的理论体系。在此基础上，根据国内医养结合的实际情况，对系统进行了健康档案管理、医疗预约、康养记录监测、生理指标预警等功能模块的开发，使系统更加贴近实际应用，具有较强的实用性。

1.3 主要研究内容

　　本文的主要工作就是设计并实现一个基于Spring Boot的医养结合管理系统，以医疗服务和养老护理相结合为题，从业务梳理到系统落地完成全部研究。研究工作分几个递进的阶段来完成。首先要对系统进行全面的需求分析，确定普通用户、管理员、医生、护理人员这四个角色的功能范围，找出健康档案、医疗预约、康养服务、康养记录这些主要的业务场景的数据流和交互方式。在需求明确之后，开始进行系统的架构设计，选择以前后端分离为基础的B/S架构方案，规划出功能结构层次以及业务流程路径。数据库设计阶段根据核心业务实体来建立概念模型和逻辑模型，并且对数据库表结构进行详细的规划。编码实现阶段使用Spring Boot作为后端框架、Vue作为前端框架、MySQL作为数据存储引擎，对各个模块进行功能开发，主要包含健康档案的录入和查询、康养服务的预约和支付、医疗预约和方案制定、护理记录的采集和异常预警、交流论坛的帖子发布和评论互动等。本文的研究重点是系统的业务完整性以及多角色协同管理能力，对于高并发优化、分布式部署等工程化的扩展方向不做详细的论述。研究成果将以可以运行的系统原型为主要的交付物，同时给出需求分析文档、数据库设计文档和系统测试报告等，全部按照软件工程规范化开发流程来开展工作。

第二章 相关技术介绍

2.1 SpringBoot框架

　　Spring Boot是基于Spring框架发展起来的快速应用开发平台，它的主要设计理念就是“约定优于配置”，利用自动装配机制大大减少了传统Spring项目中繁杂的XML配置工作量[12]。开发者只需要引入相应的Starter依赖，框架就会自动完成Bean注册、数据源初始化、Web容器启动等一系列基础配置，让开发团队可以把精力放在业务逻辑的实现上。

　　Spring Boot内嵌Tomcat服务器，可以打包成可执行的JAR文件直接运行，部署非常简单。本系统中Spring Boot起着统一请求路由、业务逻辑处理、数据库操作调度和安全认证等后端核心作用，各个功能模块的Service层、Controller层都建立在它提供的IoC容器之上，模块间通过容器的依赖注入来完成相互间的联系，从而降低代码耦合度[13]。依靠成熟的生态体系，Spring Boot可以很好地与MyBatis持久层框架、JWT令牌认证机制、各种数据连接池等无缝对接，给系统稳定运行提供可靠的技术基础。

2.2 Vue前端框架

　　Vue.js是一个渐进式的JavaScript框架，使用组件化的开发方式以及响应式的数据绑定，可以将复杂的用户界面拆分成相互独立、可复用的功能组件[14]。框架的核心就是MVVM架构，数据层和视图层之间采用双向绑定的方式进行同步，不需要开发者手动去修改DOM就可以达到界面动态更新的目的。

　　本系统中Vue主要用来创建普通用户、管理员、医生、护士等各个角色的前端交互界面。使用Vue Router实现单页应用的路由管理，不同的角色登录之后会被导向不同的功能页面；使用Axios和后端Spring Boot接口进行HTTP通信，完成健康档案录入、预约提交、康养记录查询等数据交互操作。Vue的组件化特性使各个功能模块的界面代码有较高的复用率，论坛帖子列表、健康档案表单、生理指标数据展示等界面单元都是以独立组件的形式封装起来的，从而降低维护成本[15]。

2.3 MySQL数据库

　　MySQL是目前Web应用开发领域使用最广泛的数据库管理系统之一，支持ACID事务特性，有较好的数据一致性保证能力。它能执行复杂的多表联接查询，有很强大的索引优化特性，可以很好地处理结构化业务数据的存取及查询工作[16]。

　　本系统业务数据包含用户账户、健康档案、康养记录、医疗预约、医疗方案、治疗记录、服务评价等多个人员相关实体，各个实体之间有明确的外键关联关系。MySQL用表结构来存储上述业务数据，用合理的索引字段加快查询响应速度，用事务机制保证预约创建、支付状态更新等需要写入多张表的数据完整性。本系统数据库的设计是符合第三范式，保证数据不重复的前提下合理设置冗余字段提高高频查询场景的查询效率，满足医养业务对数据准确性、响应速度的要求。

2.4 B/S架构模式

　　B/S架构是目前Web应用系统中使用最广的软件部署方式和交互方式，它所具有的主要特点就是用户只需要用浏览器就可以访问到服务器端的各种服务，而不需要在本地安装专门的客户端软件。该架构中业务逻辑、数据处理和存储都在服务器端完成，浏览器只做页面展示和用户交互，大大降低了客户端的维护成本，也简化了系统的升级和部署过程[17]。本系统采用基于B/S架构的前后端分离设计，前端用Vue框架构建的页面集通过HTTP协议向后端Spring Boot应用发送RESTful请求，后端处理请求后返回JSON格式的数据，前端动态渲染更新页面。相比传统的C/S架构而言，B/S模式使得医养结合管理系统有着“一处部署，多处使用”的成效，管理员、医生、护理人员以及普通用户均能借助各自的终端登录系统开展操作，无须另行安装应用程序，极大提升了系统的可访问性和运维便利性。B/S架构和MySQL数据库良好的兼容性保证了系统数据持久化方面的稳定运行，给医养结合服务在多角色协同场景下的落地提供可靠的技术支持。

第三章 系统分析

3.1 可行性分析

3.1.1 技术可行性

　　本系统使用的是Spring Boot作为后端框架、Vue作为前端技术、MySQL作为数据存储层，这三种技术都是目前Web开发领域经过长时间生产检验的技术组合。Spring Boot的自动装配机制和MyBatis持久层框架兼容性较好，Vue的前后端分离架构用RESTful接口和后端稳定通信，技术栈各个层次之间接口规范明确，结构合理，开发环境搭建方便，系统在现有的技术条件下具备了充分的实现基础。

3.1.2 操作可行性

　　系统前端用Vue框架创建交互界面，页面布局清楚，操作路径简单，各个功能模块都有明显的引导流程。普通用户进行健康档案的录入、服务预约等日常操作的时候，表单结构简单明了，步骤设计符合一般的认知习惯，学习成本小。医护人员在使用记录录入、方案管理等专业的功能的时候，界面逻辑同实际的工作流程相吻合，认知负担得到了较好的控制。

3.1.3 经济可行性

　　本系统所用到的所有技术组件都是开源软件，不需要支付商业授权费，开发工具和运行环境的获取成本很低。系统部署在本地服务器上可以满足运行的要求，日常的运维操作比较简单，维护的工作量也较小。整体建设投入以开发人力成本为主，学校在毕业设计方面的资源可以完全满足，经济结构合理，建设成本在可控范围内。

3.2 功能需求分析

3.2.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框架构建，负责呈现各角色的操作页面，通过Axios客户端向后端发起RESTful请求。应用服务层以Spring Boot为核心，集成Spring MVC处理请求路由，业务逻辑由Service层组件实现，Controller层统一负责请求参数解析与响应封装。数据持久层借助MyBatis框架完成对象与数据库表之间的映射操作，SQL语句通过Mapper文件进行集中维护。系统支持层包含本地部署的MySQL数据库实例，承载所有结构化业务数据的持久化存储任务，同时提供文件存储目录用于封面图片、富文本资源等非结构化内容的管理。整体架构在保证功能完整性的前提下，充分利用了成熟开源组件的稳定性，各层职责清晰，便于后续功能扩展与维护。系统架构图如图4-1所示。

图4-1系统架构图

4.2 系统结构功能设计

　　本系统面向普通用户、管理员、医生用户、护理人员四类角色，各角色拥有独立的功能模块集合。普通用户可访问交流论坛、康养服务、医疗服务、健康档案、康养记录五大模块；管理员负责健康档案管理、康养计划管理、服务预约管理、康养记录管理四个管控模块；医生用户操作医疗项目管理、医疗预约管理、医疗方案管理、治疗记录管理四个专业模块；护理人员则管理康养服务、预约服务、康养记录三类日常业务模块。各角色功能模块相互协作，共同支撑医疗预约、康养服务、健康数据采集与监测的完整业务闭环。该系统功能结构如图4-2所示。

图4-2系统功能结构图

4.3 业务流程设计

4.3.1 健康档案添加功能流程设计

　　普通用户在健康档案模块发起新增操作，系统验证用户身份状态后，用户依次填写基本信息、过敏病史、既往手术记录等结构化字段，在输入完成后选择触发AI健康建议生成。系统对输入数据的完整性进行校验，若校验未通过则提示用户补全必填项，校验通过后写入数据库并返回提交成功状态。健康档案添加流程图如图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图作为可视化表达工具，将上述实体与联系清晰呈现，为后续数据库逻辑设计提供严谨的结构依据[18]。全局E-R模型如图4-8所示。

图4-8全局ER图

　　根据系统分析，系统的主要实体有：普通用户、健康档案、康养记录、医疗预约、医疗方案、康养服务、服务预约、医疗服务、护理人员、医生用户，各个实体具体的属性如下图所示。

　　（1）普通用户实体主要包括普通用户ID、用户姓名、用户性别、审核状态、用户ID、创建时间、创建用户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、人员姓名、人员性别、审核状态、用户ID、创建时间、创建用户ID、更新时间等。如图4-17所示。

图4-17护理人员实体属性图

　　（10）医生用户实体主要包括医生用户ID、医生姓名、医生性别、审核状态、用户ID、创建时间、创建用户ID、更新时间等。如图4-18所示。

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

4.4.2 数据库表设计

　　数据库逻辑设计是在概念模型基础上，将E-R图中的实体、属性与联系转换为关系数据库可识别的二维表结构的过程。转换过程遵循关系数据库规范化理论，以第三范式为设计基准，消除数据冗余与传递依赖，保证数据完整性[19]。每个实体对应一张数据表，实体的主键属性映射为表的主键字段，实体间的关联关系通过外键字段加以体现。对于多对多联系，本系统在医疗预约、服务预约等业务场景中采用了中间关联表的形式进行处理，明确记录双方实体的引用关系。字段数据类型的选定依据字段的实际业务含义，数值类字段区分整型与浮点型，字符串类字段根据内容长度特征合理设置varchar长度，长文本内容使用text类型存储。索引策略方面，对高频查询字段如用户ID、预约状态、服务时间等建立必要索引，在提升查询效率的同时控制索引维护开销，确保数据库在中等规模数据量下稳定运行。

　　（1）普通用户表主要是用来存储注册用户的基本身份信息及审核状态。主要包括普通用户ID、用户姓名、用户性别、审核状态等字段。如表4-1所示。

表4-1普通用户表

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

　　（2）健康档案表主要是用来存储用户的健康基本信息与历史病史数据。主要包括健康档案ID、用户姓名、过往病例、过敏病史等字段。如表4-2所示。

表4-2健康档案表

序号	字段名	类型	长度	备注
1	health_record_id	int	11	主键
2	user_name	varchar	64	用户姓名
3	user_gender	varchar	64	用户性别
4	regular_user	int	11	普通用户
5	archive_date	date	-	档案日期
6	past_cases	text	255	过往病例
7	allergy_history	text	255	过敏病史
8	history_of_surgery	text	255	历史手术
9	health_assessment	varchar	255	健康评估
10	create_time	datetime	-	创建时间
11	update_time	timestamp	-	更新时间

　　（3）康养记录表主要是用来记录护理人员为用户采集的生理监测数据及护理情况。主要包括康养记录ID、服务项目、用户体温、血压收缩等字段。如表4-3所示。

表4-3康养记录表

序号	字段名	类型	长度	备注
1	health_records_id	int	11	主键
2	service_items	varchar	64	服务项目
3	nursing_staff	int	11	护理人员
4	regular_user	int	11	普通用户
5	user_name	varchar	64	用户姓名
6	service_hours	date	-	服务时间
7	appointment_number	varchar	64	预约编号
8	user_body_temperature	double	-	用户体温
9	blood_pressure_contraction	double	-	血压收缩
10	user_heart_rate	double	-	用户心率
11	venous_blood_oxygen	double	-	静脉血氧
12	special_care	text	255	特殊护理
13	create_time	datetime	-	创建时间
14	update_time	timestamp	-	更新时间

　　（4）医疗预约表主要是用来记录用户针对医疗项目提交的预约申请及支付状态。主要包括医疗预约ID、医疗项目、医生用户、审核状态等字段。如表4-4所示。

表4-4医疗预约表

序号	字段名	类型	长度	备注
1	medical_appointment_id	int	11	主键
2	medical_projects	varchar	64	医疗项目
3	doctor_user	int	11	医生用户
4	doctors_name	varchar	64	医生姓名
5	project_price	double	-	项目价格
6	regular_user	int	11	普通用户
7	user_name	varchar	64	用户姓名
8	appointment_time	date	-	预约时间
9	examine_state	varchar	16	审核状态
10	pay_state	varchar	16	支付状态
11	pay_type	varchar	16	支付类型
12	create_time	datetime	-	创建时间
13	update_time	timestamp	-	更新时间

　　（5）医疗方案表主要是用来存储医生为患者制定的诊疗计划与用药方案信息。主要包括医疗方案ID、医疗项目、药品名称、治疗方案等字段。如表4-5所示。

表4-5医疗方案表

序号	字段名	类型	长度	备注
1	medical_program_id	int	11	主键
2	medical_projects	varchar	64	医疗项目
3	doctor_user	int	11	医生用户
4	doctors_name	varchar	64	医生姓名
5	regular_user	int	11	普通用户
6	user_name	varchar	64	用户姓名
7	drug_name	varchar	64	药品名称
8	usage_and_dosage	varchar	64	用法用量
9	medication_plan	text	255	用药计划
10	treatment_plan	text	255	治疗方案
11	create_time	datetime	-	创建时间
12	update_time	timestamp	-	更新时间

　　（6）康养服务表主要是用来存储护理人员发布的服务项目信息及服务流程描述。主要包括康养服务ID、服务项目、项目价格、服务流程等字段。如表4-6所示。

表4-6康养服务表

序号	字段名	类型	长度	备注
1	recreation_services_id	int	11	主键
2	service_items	varchar	64	服务项目
3	nursing_staff	int	11	护理人员
4	name_of_personnel	varchar	64	人员姓名
5	service_standards	varchar	64	服务标准
6	project_price	double	-	项目价格
7	cover_image	varchar	255	封面图片
8	service_process	text	255	服务流程
9	praise_len	int	11	点赞数
10	collect_len	int	11	收藏数
11	create_time	datetime	-	创建时间
12	update_time	timestamp	-	更新时间

　　（7）服务预约表主要是用来记录用户对康养服务项目提交的预约信息与处理进度。主要包括服务预约ID、服务项目、服务状态、支付状态等字段。如表4-7所示。

表4-7服务预约表

序号	字段名	类型	长度	备注
1	service_appointment_id	int	11	主键
2	service_items	varchar	64	服务项目
3	nursing_staff	int	11	护理人员
4	name_of_personnel	varchar	64	人员姓名
5	project_price	double	-	项目价格
6	regular_user	int	11	普通用户
7	user_name	varchar	64	用户姓名
8	service_hours	date	-	服务时间
9	appointment_number	varchar	64	预约编号
10	service_status	varchar	64	服务状态
11	examine_state	varchar	16	审核状态
12	pay_state	varchar	16	支付状态
13	create_time	datetime	-	创建时间
14	update_time	timestamp	-	更新时间

　　（8）医疗服务表主要是用来存储医生发布的医疗项目信息及服务过程描述。主要包括医疗服务ID、医疗项目、项目价格、医疗流程等字段。如表4-8所示。

表4-8医疗服务表

序号	字段名	类型	长度	备注
1	medical_services_id	int	11	主键
2	medical_projects	varchar	64	医疗项目
3	doctor_user	int	11	医生用户
4	doctors_name	varchar	64	医生姓名
5	gender_of_doctor	varchar	64	医生性别
6	project_price	double	-	项目价格
7	cover_image	varchar	255	封面图片
8	medical_process	text	255	医疗流程
9	praise_len	int	11	点赞数
10	collect_len	int	11	收藏数
11	create_time	datetime	-	创建时间
12	update_time	timestamp	-	更新时间

　　（9）护理人员表主要是用来存储护理人员的基本身份信息及账号审核状态。主要包括护理人员ID、人员姓名、人员性别、审核状态等字段。如表4-9所示。

表4-9护理人员表

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

　　（10）医生用户表主要是用来存储医生账号的基本信息及平台审核状态。主要包括医生用户ID、医生姓名、医生性别、审核状态等字段。如表4-10所示。

表4-10医生用户表

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

第五章 系统实现

5.1 普通用户角色功能实现

5.1.1 交流论坛

　　交流论坛功能模块主要是对用户发布的帖子内容进行创建、浏览与社区互动的管理。用户在论坛页面输入关键词后系统返回匹配的帖子列表，点击进入帖子详情页可查看完整内容。创作新帖时，用户上传封面图片，系统校验文件格式后显示预览；选择分类标签后进入富文本编辑器区域完成正文写作，点击发布后系统完成非空校验并将帖子数据持久化，页面跳转回帖子列表显示新发布内容。针对他人帖子，用户可点击点赞或踩按钮触发状态切换，收藏操作将帖子存入个人收藏列表；评论区支持直接发表评论以及针对特定评论的回复操作，用户可删除自己发布的评论，操作后评论列表实时更新。交流论坛界面如图5-1所示。

图5-1交流论坛界面

5.1.2 康养服务

　　康养服务功能模块主要是对护理人员发布的服务项目进行展示、查询与在线预约处理。用户在服务列表页按项目名称或类别进行筛选，系统返回符合条件的服务项目卡片，点击进入详情页后系统展示服务标准、价格及完整服务流程说明。用户确认服务内容后点击预约按钮，系统判断当前用户的预约次数是否超出限制，未超限则跳转至日期选择页面；用户选定服务时间后进入支付页面，选择支付方式完成扫码支付，系统接收支付回调后更新预约记录的支付状态，生成唯一预约编号并在用户端呈现预约成功信息。康养服务界面如图5-2所示。

图5-2康养服务界面

5.1.3 医疗服务

　　医疗服务功能模块主要是对医生发布的医疗项目进行查询与预约支付的流程管理。用户在医疗服务列表中按项目类别或医生姓名进行检索，系统返回对应的医疗项目卡片，点击后进入详情页查看医生信息、项目价格及医疗流程描述。用户确认后发起预约，系统生成待支付记录，引导用户进入支付环节，扫码支付完成后系统更新支付状态并将预约单推送至对应医生的待处理列表。医疗服务界面如图5-3所示。

图5-3医疗服务界面

5.1.4 健康档案

　　健康档案功能模块主要是对用户个人健康信息的录入、查询与导出进行管理。用户在档案列表页可按姓名或日期条件进行查询，点击重置清空筛选条件，查询结果支持导出为文件。新增档案时，用户选择档案日期后依次填写过敏病史、过往病例、历史手术等结构化字段，填写完毕后可点击AI健康建议按钮，系统根据已填内容生成建议文本并回填至对应区域，用户确认后提交，数据写入健康档案表，档案列表随之更新显示新增记录。健康档案界面如图5-4所示。

图5-4健康档案界面

5.1.5 康养记录

　　康养记录功能模块主要是对用户历史生理监测数据的查阅操作进行管理。用户进入康养记录列表后查看护理人员采集的历史监测记录，点击具体记录进入详情页，系统展示该次服务的体温、血压、心率、血氧四项生理指标数值，同时呈现饮食记录、护理说明及异常情况等文本性数据，用户可据此了解自身健康状态的动态变化情况。康养记录界面如图5-5所示。

​编辑 图5-5康养记录界面

5.2 管理员角色功能实现

5.2.1 健康档案管理

　　健康档案管理功能模块主要是对系统内所有用户健康档案数据进行查阅与导出的统一管控。管理员在档案列表页通过姓名、性别或日期组合条件执行查询操作，点击重置清空当前筛选状态，查询结果可批量导出。点击特定档案记录后，系统展示该用户的过敏病史、过往病例、历史手术及健康评估全部字段内容，管理员以只读方式审阅档案详情，数据不允许在此界面修改。健康档案管理界面如图5-6所示。

图5-6健康档案管理界面

5.2.2 康养计划管理

　　康养计划管理功能模块主要是对用户康养计划的执行状态进行查询与详情维护的操作管理。管理员在计划列表页按用户姓名或执行周期条件检索，系统返回对应计划记录并显示当前执行进度百分比。点击具体计划后进入详情编辑页，管理员可修改康养目标、服务项目、执行周期、执行进度及计划详情等字段，保存后系统更新数据库并在列表页刷新进度显示。康养计划管理界面如图5-7所示。

图5-7康养计划管理界面

5.2.3 服务预约管理

　　服务预约管理功能模块主要是对用户提交的康养服务预约订单进行状态筛查与批量审核的处理。管理员在预约列表页按审核状态、支付状态等条件组合筛选目标订单，系统返回符合条件的预约记录列表。管理员勾选多条待确认订单后执行批量确认操作，系统将选中记录的审核状态批量更新为已确认，相关用户端预约状态随之同步刷新。服务预约管理界面如图5-8所示。

图5-8服务预约管理界面

5.2.4 康养记录管理

　　康养记录管理功能模块主要是对护理人员采集的生理监测数据进行实时监控、查询删除与服务评价的综合管控。管理员进入模块后实时查看各用户的最新生理指标数据，当系统检测到某项指标超出预设阈值时，自动弹出预警提示窗口，管理员确认后记录预警事件。列表支持按用户姓名、服务时间等条件查询，管理员可删除错误录入的记录，对已完成服务的记录执行服务评价操作，系统将评价内容关联至对应康养记录存档。康养记录管理界面如图5-9所示。

图5-9康养记录管理界面

5.3 医生用户角色功能实现

5.3.1 医疗项目管理

　　医疗项目管理功能模块主要是对医生负责的医疗服务项目信息进行查询与维护的操作处理。医生在项目列表页按项目名称进行检索，系统返回本医生关联的服务项目列表，点击具体项目进入详情页，医生可查看并修改项目价格、封面图片及医疗流程描述内容，保存后系统更新对应数据记录，用户端展示的项目信息同步刷新。医疗项目管理界面如图5-10所示。

图5-10医疗项目管理界面

5.3.2 医疗预约管理

　　医疗预约管理功能模块主要是对患者提交的预约申请进行审批决策的操作处理。医生进入预约列表后查看待处理的患者预约申请，每条申请包含患者基本信息、预约时间及项目名称。医生逐条执行审批操作，选择确认时系统将预约状态更新为已确认并触发通知消息推送至患者端；选择拒绝时系统要求医生输入拒绝原因，确认提交后状态更新为已拒绝，患者端预约列表随之更新。医疗预约管理界面如图5-11所示。

图5-11医疗预约管理界面

5.3.3 医疗方案管理

　　医疗方案管理功能模块主要是对医生为患者制定的诊疗方案进行新增录入的操作处理。医生在方案录入页选择关联的医疗项目后填写患者用户信息，依次输入诊断结果、药品名称、用法用量、用药频率，通过富文本编辑器完成治疗流程的详细编写，提交后系统将方案数据写入医疗方案表并关联对应的患者记录，患者端可在个人页面查阅方案内容。医疗方案管理界面如图5-12所示。

图5-12医疗方案管理界面

5.3.4 治疗记录管理

　　治疗记录管理功能模块主要是对医生针对患者治疗过程提交的反馈记录进行录入管理的操作处理。医生进入治疗记录页后选择已存在的医疗方案作为关联依据，填写本次治疗的执行时间与治疗效果描述，确认无误后提交，系统将治疗反馈数据写入治疗记录表，管理员可在后台查阅患者的完整治疗进展。治疗记录管理界面如图5-13所示。

图5-13治疗记录管理界面

5.4 护理人员角色功能实现

5.4.1 康养服务管理

　　康养服务管理功能模块主要是对护理人员个人发布的服务项目进行新增维护的操作管理。护理人员在服务列表页点击新增后进入服务录入表单，依次填写服务项目名称、设定项目价格，上传封面图片后系统显示预览效果，通过富文本编辑器对服务流程进行详细的步骤说明编写。提交后系统将服务信息写入康养服务表，用户端服务列表随之更新展示新发布的服务项目供用户查阅预约。康养服务管理界面如图5-14所示。

图5-14康养服务管理界面

5.4.2 预约服务管理

　　预约服务管理功能模块主要是对分配至本护理人员的服务预约订单进行状态跟踪与服务确认的操作处理。护理人员在订单列表页按服务日期或服务状态进行查询，系统返回当前名下的全部预约记录。对已完成实际服务的订单，护理人员执行确认已服务操作，系统将订单服务状态更新为已完成，管理员端订单状态随之同步，已完成订单进入待评价流程。预约服务管理界面如图5-15所示。

图5-15预约服务管理界面

5.4.3 康养记录管理

　　康养记录管理功能模块主要是对护理人员为服务用户采集生理监测数据进行录入的操作处理。护理人员选择服务日期后进入数据采集表单，依次录入体温、血压、心率、血氧数值，系统对每项数据实时进行阈值比对，检测到异常值时弹出预警提示要求护理人员确认，确认后继续录入饮食日志、特殊护理说明与异常情况文字描述，全部填写完毕后提交，数据写入康养记录表，管理员实时监控视图更新。康养记录管理界面如图5-16所示。

图5-16康养记录管理界面

第六章 系统测试

6.1 测试目的

　　软件测试是验证系统实现质量、管控上线风险的关键环节。对于医养结合管理系统而言，测试工作的核心目标在于全面验证各功能模块的业务规则匹配程度，确认健康档案录入、医疗预约审批、康养记录采集等关键业务流程在正常路径与异常路径下均能产生与设计预期一致的系统响应。生理指标预警、支付状态流转、角色权限隔离等涉及数据一致性的复合场景需要重点覆盖，通过测试暴露潜在的逻辑漏洞，将系统在实际部署运行中出现业务错误的概率降至可接受范围[20]。测试工作的完成质量直接决定了系统功能模块的闭环程度。

6.2 测试方法

　　本系统测试采用功能测试作为主要方法，针对各角色功能模块逐一设计测试用例，依据需求分析中定义的业务规则制定预期结果，通过实际操作触发系统响应后与预期结果对比判定是否通过。测试涵盖正常输入场景、边界条件场景、非法输入场景三类情况，重点关注表单校验逻辑、状态流转逻辑与权限控制逻辑的准确性。

　　针对数据一致性要求较高的模块，如预约状态同步、生理指标预警触发，采用端到端的链路追踪方式执行测试，从用户操作端发起数据变更请求，逐层验证数据库写入结果是否与前端展示保持一致，确保全链路数据在各角色界面中呈现统一。

6.3 测试用例

　　本节针对系统七个核心业务模块设计测试用例，覆盖功能路径、状态流转与异常处理等关键验证场景。

　　健康档案模块测试重点验证档案新增时必填字段校验机制与AI健康建议触发逻辑的正确性，确认档案数据在提交后能准确写入数据库并在列表页刷新显示。

表6-1健康档案测试用例表

测试内容	测试步骤	预期结果	实际结果
新增档案正常提交	填写完整字段后点击提交	档案写入成功，列表刷新	符合预期
必填字段缺失提交	留空档案日期后点击提交	系统提示必填项不能为空	符合预期
AI建议生成触发	填写病史信息后点击生成建议	建议文本回填至对应字段	符合预期

　　康养服务预约模块测试主要验证预约次数限制逻辑、日期选择有效性校验与支付状态更新的正确性，确认预约编号在支付成功后正确生成。

表6-2康养服务预约测试用例表

测试内容	测试步骤	预期结果	实际结果
正常预约提交	选择服务日期并完成支付	预约编号生成，状态更新为已支付	符合预期
超限预约拦截	在已达次数上限时再次发起预约	系统提示预约次数已达上限	符合预期
支付状态同步	完成扫码支付后返回列表	预约记录支付状态变更为已支付	符合预期

　　医疗预约管理模块测试验证医生端审批操作对预约状态的准确更新，以及拒绝操作时原因字段的非空校验是否生效。

表6-3医疗预约管理测试用例表

测试内容	测试步骤	预期结果	实际结果
医生确认预约	点击确认按钮提交审批	预约状态更新为已确认	符合预期
医生拒绝预约并填写原因	输入拒绝原因后提交	状态更新为已拒绝，原因存档	符合预期
拒绝原因为空提交	留空原因直接点击拒绝提交	系统提示拒绝原因不能为空	符合预期

　　康养记录采集模块测试重点验证生理指标异常值触发预警弹窗的机制，以及正常数值提交后数据正确写入数据库的情况。

表6-4康养记录采集测试用例表

测试内容	测试步骤	预期结果	实际结果
正常数据提交	录入正常范围指标后提交	数据写入成功，管理员端可见	符合预期
异常指标预警触发	录入超出阈值的体温数值	系统弹出异常预警提示窗口	符合预期
预警确认后继续录入	确认预警弹窗后填写剩余字段	表单恢复可操作状态，提交成功	符合预期

　　医疗方案管理模块测试验证方案录入时项目关联字段与诊断结果字段的必填校验，以及富文本编辑器内容能否完整保存至数据库。

表6-5医疗方案管理测试用例表

测试内容	测试步骤	预期结果	实际结果
完整方案新增提交	填写全部字段后提交	方案数据写入成功并关联患者	符合预期
未选关联项目提交	不选择医疗项目直接提交	系统提示必须关联医疗项目	符合预期

　　服务预约管理模块测试验证管理员批量确认操作是否正确批量更新多条预约记录的审核状态，单条确认与批量确认的状态变更结果应保持一致。

表6-6服务预约管理测试用例表

测试内容	测试步骤	预期结果	实际结果
单条预约确认	勾选单条预约后执行确认	该条预约状态更新为已确认	符合预期
批量预约确认	勾选多条预约后执行批量确认	所选预约状态批量更新为已确认	测试成功

　　论坛帖子发布模块测试验证封面图片格式校验、标题非空校验及发布成功后帖子出现在列表首页的完整流程。

表6-7论坛帖子发布测试用例表

测试内容	测试步骤	预期结果	实际结果
正常帖子发布	填写标题正文选择分类后发布	帖子写入成功并显示在列表	符合预期
封面图片格式不合规	上传非图片格式文件	系统提示文件格式不支持	符合预期
标题为空发布	留空标题直接点击发布	系统提示标题不能为空	符合预期

测试结论

　　经过对医养结合管理系统全部功能模块的功能测试，所有的测试用例的实际结果都和预期的结果一致，系统功能可以正常运行，业务逻辑闭环。健康档案模块中新增档案的必填字段校验和AI建议生成功能正常触发，数据写入和列表刷新没有异常；康养服务预约模块的预约次数限制、日期有效性以及支付状态同步都符合设计预期，预约编号在支付成功之后正确生成；医疗预约管理模块中医生端的确认和拒绝操作可以正确更新预约状态，拒绝原因的非空校验有效拦截了非法提交；康养记录采集模块在录入正常指标时数据正常入库，在输入超出阈值指标时系统会自动弹出预警弹窗，确认后仍然可以提交，异常预警机制工作可靠；医疗方案管理模块的关联项目校验和富文本内容存储都通过验证；服务预约管理模块的单条和批量确认操作都可以正确批量更新审核状态；论坛帖子发布模块的图片格式校验、标题非空校验和发布后列表展示都正常。因此本系统在功能正确性、数据一致性、角色权限隔离这三个方面都达到了设计目的，可以满足医养结合业务场景下实际使用的要求。

项目分享：大家可自取用于参考学习，获取方式可私信哦！