1绪论

1.1研究背景与意义

传统的健康检测管理大多依靠手工记载和线下传递，居民的健康档案散落在各个级别的医疗机构里，检测报告一般用纸张的形式保存起来，预约和缴费都要到现场排队办理，医患交流受到门诊时间的限制。造成数据割裂、信息滞后，居民不能系统掌握自身的健康状况，医生不能获得完整的检测历史数据来做出诊断，重复检测和医疗资源的浪费现象也十分普遍。电脑化管理系统出现以后，部分医院开始建立内部信息系统，检测流程由原来的纯线下变为半线上，但是系统之间数据标准不统一，信息孤岛问题没有得到根本的解决[1]。居民对健康服务的需求已经由原来的单一检测向连续监测、个性化指导转变，现有的方式在数据共享、实时响应和主动健康管理支持方面存在着明显的不足[2]。创建以大数据平台为基础的健康检测管理系统，可以把分散的检测数据整合起来，打通居民与医疗机构之间的信息通道，提升健康服务获取的便捷程度。系统按照规范的检测流程和数据标准来减少信息的遗漏以及重复检测的可能性，给慢性病追踪和健康干预赋予数据支撑。该实践对于改善基层健康服务资源分配状况，促使以居民为中心的健康管理模式转变有着实际意义。

1.2国内外研究现状

国内健康检测管理领域早期以医院内部信息系统建设为主，东软集团开发的远程医疗系统可以实现检测数据从基层机构到上级医院的传输[3]。阿里健康搭建起线上体检预约平台，把多家体检机构整合起来，用户可以在平台上自己挑选体检套餐并获取电子报告[4]。微医平台搭建起医患沟通渠道，支持在线问诊之后开具检测项目，检测结果直接推送至用户端[5]。平安好医生创建健康档案模块，保存用户的检测历史数据以及趋势图[6]。公共卫生领域逐渐实行居民电子健康档案，部分省市实现了区域内医疗机构数据的互联，检测记录可以跨院调阅[7]。但是平台之间数据互通还存在壁垒，检测数据标准化程度参差不齐，基于大数据的健康分析和预测功能还在探索中[8]。

国外健康检测管理实践开始得比较早，美国Kaiser Permanente医疗集团早在九十年代就建立了覆盖成员的健康记录系统，检测数据和诊疗信息实时关联[9]。英国国家医疗服务体系推行全民电子健康档案，实验室检测结果在系统里被标准化保存，全科医生和专科医院都可以查阅完整的过往记录[10]。德国CompuGroup Medical公司开发出医疗数据交换平台，把诊所、实验室、药房等机构连接起来，检测报告用结构化的格式在各个机构之间流动[11]。日本富士通同多家医疗机构合作创建了健康管理云平台，把体检数据和日常健康监测信息整合起来，给用户赋予连续的健康记载。荷兰飞利浦公司研发出一种专门为慢性病患者家庭使用而设计的监测系统，居家监测仪器产生的数据会实时传送到健康档案上，医生可以随时查阅并且调整治疗方案[12]。国际标准化组织一直推进医疗数据交换标准，HL7、FHIR框架被广泛应用在检测数据的共享上，为跨系统数据整合奠定基础。

1.3主要研究内容

本课题主要研究设计并实现一个基于SpringBoot的健身房管理系统，以达到用户、教练、管理员三类角色一体化服务的目的。研究内容包含系统需求分析、总体架构设计、功能模块划分、数据库设计。系统采用前后端分离架构，前端用Vue框架搭建交互界面，后端用SpringBoot开发RESTful接口，数据存放在MySQL中。核心功能有用户端的课程和私教预约、体测和训练数据跟踪，教练端的学员管理、训练计划制定和排班、管理员端的用户、教练、场地、器械和预约事务的统一控制以及操作日记来保证数据安全。系统主要解决传统健身房信息不明、预约冲突和训练数据分散的问题。

2相关技术介绍

2.1Spring Boot框架

Spring Boot是用Java语言开发的一个开源的应用开发框架，它的设计目的是简化Spring应用的初始搭建和开发。该框架用自动配置的方式减少了开发者手动写配置文件的麻烦，内嵌的Tomcat或者Jetty服务器使应用可以独立运行，不需要部署到外部容器上[13]。Spring Boot是健康检测管理系统中后端业务逻辑的实现框架，它会接收前端发出的HTTP请求，然后通过控制器层对请求参数进行解析，并调用服务层的方法。服务层封装了检测预约、处方支付、档案管理等主要的业务规则，并且和数据访问层交互来完成数据库的操作。框架提供的依赖管理功能可以方便地集成Hadoop相关的组件，为海量健康检测数据的存储和分析打下基础。事务控制机制保证了处方支付、医嘱开具等操作的原子性，防止出现数据不一致的情况。拦截器和过滤器组件可以对用户的认证以及权限校验进行控制，保证不同的用户只能访问到自己权限范围内资源。开发者使用Spring Boot的单元测试来对各个业务模块进行独立测试，从而提高代码质量以及系统的稳定性。该框架模块化设计使得系统功能可以灵活地进行扩展，后续增加新的检测项目或者健康指导服务时不需要对整个系统进行重构。

2.2 Vue.js框架

Vue.js是一个基于JavaScript的渐进式框架，主要用在构建用户界面上，它的核心库只关注视图层，使用自底向上的增量开发方式[14]。该框架采用组件化的开发方式把页面分成可以独立使用的各个部件，每一个部件都包含有模板、脚本和样式等部分，利于多人合作开发以及后期维护。在健康检测管理系统中，Vue.js创建了面向三类角色的交互界面，用户登录之后首页显示通知公告和医生信息，组件之间用路由来实现页面的切换。双向数据绑定机制使表单输入和数据状态实时同步，用户填写投诉反馈或者预约检测时可以得到即时的响应体验。计算属性和侦听器对健康档案数据进行动态展示的逻辑，按照检测日期排序或者筛选出某种类型的记录。框架内置的指令系统简化了DOM操作，条件渲染根据用户的权限来显示或者隐藏功能入口，列表渲染遍历医生信息和检测项目生成可以点击的条目。系统使用Axios库和后端的Spring Boot进行异步通信，获取检测报告数据之后更新视图，不需要重新加载页面。Vue生命周期钩子函数在组件创建、挂载和销毁的时候执行相应的操作，比如初始化时加载慢病信息列表。该框架的轻量化特点可以保证页面的快速响应，在医疗健康领域内频繁地进行数据交互时，也能够满足要求。

2.3MySQL数据库

MySQL是关系型数据库管理系统，以体积小、速度快、成本低为特点，在Web应用中被广泛使用[15]。该数据库用结构化查询语言对数据进行操作，有事务处理、ACID特性、多版本并发控制的机制来保证数据一致性、完整性。在健康检测管理系统当中，MySQL用来保存用户信息，医生档案，检测项目，处方记录这些结构化的业务数据。数据库设计符合第三范式，用主键和外键约束来建立数据表之间的联系，比如用户表和健康档案表用用户标识进行关联，检测预约表关联用户表和医生表。索引机制用来处理高频查询字段，在医生按科室查询或者用户查看历史预约的时候可以得到迅速响应。存储过程可以封装复杂的统计逻辑，管理员调用时可以直接得到各个类型检测项目预约频次分布。事务处理保证处方支付操作涉及订单表、支付记录表和状态更新表的修改要么全部成功要么全部回滚。系统定时备份，防止数据丢失，读写分离把查询请求分散到从库上，降低主库的压力。MySQL和Hadoop平台一起工作，结构化数据从数据库中导出之后再被Hadoop进行离线分析，从而找出慢性病的发展趋势以及健康干预的效果。成熟的生态系统给开发者在系统运行中不断改善性能表现赋予了诸多监控和调优手段。

2.4Hadoop数据库

Hadoop是由Apache基金会所创建的分布式计算平台，它的主要设计包含分布式文件系统HDFS和并行计算框架MapReduce[16]。HDFS使用主从架构，把大文件分成固定大小的数据块分散到集群各个节点上，用数据复制来保证存储的可靠性。MapReduce把计算任务拆分成映射和归约两个部分，计算逻辑被推送到数据所在的节点上执行，从而减小了网络传输的开销。健康检测管理系统中用Hadoop平台处理大量的非结构化、半结构化数据，即历年检测报告文档、健康随访记录、慢病跟踪日志等。系统每天产生的结构化数据通过Sqoop工具导入到Hive数据仓库中，形成一个健康分析主题的数据集。按照用户的年龄、地域、检测频率等因素对用户进行分组统计，得到各个慢性病的检出率和干预效果。HBase是列式数据库存储实时写入的健康监测数据，可以对指定用户的某个历史指标进行快速查询。平台计算能力支撑着健康趋势预测模型的训练过程，分析人员根据模型输出来调整随访策略和健康指导内容。Hadoop的扩展性可以随着用户规模的增大而自动增加节点，来处理检测数据量不断增多的情况。该平台同Spring Boot后端采用API接口交互，分析结果定时上传到MySQL数据库供前端展示，从而形成一个完整的从数据采集、存储、分析到应用的闭环。

3系统分析

3.1功能需求分析

用户角色可以对系统进行首页浏览、通知查看、医生信息查看这三项信息的获取操作。服务预约、检测预约功能可以供用户在线选择服务项目及时间。处方支付模块可以采用多种支付方式来完成费用结算。用户通过投诉反馈功能向服务过程提出意见，通过在线沟通客服和医生或者客服人员进行实时交流。健康档案查看功能可以查看用户的个人历史检测记录和健康数据。用户角色用例图如图3-1所示。

图3-1 用户用例图

医生角色负责药品信息、疾病信息、诊疗项目三项基础数据的维护操作。健康档案查看功能使医生能够调阅患者历史检测记录，健康指导功能用于向患者提供健康建议。医生信息模块管理个人执业资料，检查预约功能查看患者提交的检测申请。医嘱处方模块开具治疗用药方案，诊疗检查功能录入检查项目与要求。检测报告模块填写并发布检测结果，慢病信息功能跟踪慢性病患者病情变化，健康随访功能安排后续跟踪计划。医生角色用例图如图3-2所示。

图3-2 医生用例图

管理员角色承担系统用户管理，包括普通用户与医生用户的账号维护。药品信息管理、疾病信息管理、诊疗项目管理三项基础数据配置功能由管理员统一操作。健康档案管理监督用户健康数据的完整性与规范性，医生信息管理审核医生执业资料。检测预约管理查看并处理用户提交的检测申请，诊疗检查管理监督检查过程记录。健康随访管理统筹医生随访计划的执行情况。管理员角色用例图如图3-3所示。

图3-3 管理员用例图

3.2可行性分析

3.2.1技术可行性

系统采用前后端分离的架构设计，前端用Vue框架做用户交互界面，后端用Spring Boot框架做业务逻辑和数据流转。经过大量的项目验证，两种框架可以保证开发过程中遇到的技术问题可以被解决。MySQL属于关系型数据库，用来保存用户的资料，医生的信息，检测预约等结构化的数据，事务处理机制可以保证数据的操作一致性。Hadoop平台对大量的检测报告、健康档案进行分布式存储和分析，用Spring Boot接口对接形成完整的数据链路。开发者在本科阶段就具有了对Java程序设计、数据库原理、Web开发技术等的系统掌握，并且能够熟练地运用到工作中。性能上由于用户量增大、数据积累等原因会造成系统的查询响应时间变慢。数据存储上用MySQL索引优化、Hadoop集群扩容来应对负载的变化，安全上用权限控制、输入校验防止越权访问、注入攻击。因此系统的技术上是可行的。

3.2.2操作可行性

目标用户群体为普通居民、医生、管理人员，这三种角色在日常生活中都对Web应用有所接触。系统界面布局用的是左侧导航菜单和右侧内容区的模式，功能入口按角色业务特点分组排列。用户登录之后首页显示通知公告和快捷操作入口，预约流程分步骤引导填写信息。医生的操作路径是按照诊疗过程来展开的，从查看预约、开处方、填写报告构成一个闭环。管理员后台用列表形式展示待处理的事项，增删改查操作与一般的管理系统一致。系统上线之后原来的线下预约和报告传递方式变成了线上处理，患者减少了往返医院的次数，医生也从手工记录中解脱出来。日常运行由管理员来维护基本的数据以及用户的权限，开发阶段留有日志来追踪异常。后续的维护工作由开发者或者医院信息科人员完成，操作界面和现有的系统相似降低了学习的成本。因此系统在操作上是可行的。

3.2.3经济可行性

项目资金大部分用在开发阶段人力成本上，开发工具、运行环境都以现有资源为基础。IntelliJ IDEA社区版提供Java开发支持，MySQL与Hadoop采用开源版本无需支付授权费用。前端使用Vue框架以及相关的开源组件库，后端采用Spring Boot框架，使用Apache 2.0许可证，可以自由地在商业项目中使用。系统部署使用医院已有的服务器和存储设备，不需要另外购买硬件。开发者用个人计算机来完成编码和测试的工作，不会产生额外的设备费用。系统投入使用之后减少纸质表单的印刷和人工传递的成本，检测报告在线查阅降低打印和邮寄的费用。预约、支付的线上化减少患者等候时间，提高医生的工作效率，间接增加了医疗服务承载量。投入规模小、预期价值与之相匹配，具备实施条件。因此系统在经济上是可行的。

4系统设计

4.1系统架构设计

系统使用前后端分离的模块化架构设计，前端用Vue框架实现用户交互界面，后端用Spring Boot框架实现业务逻辑和数据流转。用户操作采用Axios异步请求的方式向后端控制器发起请求，控制器收到请求参数之后调用Service层进行具体的业务处理。Service 层对检测预约、处方支付、健康档案管理等核心业务规则进行封装，并通过数据访问层和数据库进行交互来完成操作。MySQL用来存放用户的资料、医生的信息、检测的预约等结构化的业务数据，Hadoop平台用作海量的检测报告和健康档案的分布式存储和分析。本地缓存可以减小频繁查询给数据库带来的压力，提高系统的响应速度。系统整体架构从前端交互、后端业务、数据持久化到大数据分析形成了一个完整的链条，各个层次的职责明确，耦合度低，利于后续功能的拓展和维护。相关研究与实践证明，分层架构设计可以提高Web应用的可维护性、可扩展性[17]。

图4-1 系统架构图

4.2系统结构功能设计

系统根据三类用户角色来设计功能模块，用户角色分为首页浏览、通知查看、医生信息查看、服务预约、检测预约、处方支付、投诉反馈、健康档案查看、在线沟通客服等九个功能。医生角色负责药品信息、疾病信息、诊疗项目、健康档案、健康指导、医生信息、检查预约、医嘱处方、诊疗检查、检测报告、慢病信息、健康随访等十二项业务操作。管理员角色负责系统用户的管理、药品信息的管理、疾病信息的管理、诊疗项目信息的管理、健康档案信息的管理、医生信息的管理、检测预约信息的管理、医嘱处方信息的管理、诊疗检查信息的管理、健康随访信息的管理等十个后台控制功能。该系统的功能结构图如下图4-2所示。

图4-2 系统功能结构图

4.2.1总体业务流程图设计

系统总体业务流程覆盖用户、医生、管理员三类角色的核心操作路径。用户登录后浏览首页通知与医生信息，提交检测预约或服务预约申请。医生查看预约列表后开具医嘱处方或安排诊疗检查，填写检测报告并推送至用户端。用户完成处方支付后查看健康档案，对服务过程提交投诉反馈。医生根据检测结果开展慢病信息跟踪与健康随访，记录随访情况。管理员在后台对各环节数据进行统一监管与配置维护，确保系统运行符合业务规范。总体业务流程图如图4-3所示。

图4-3 总体业务流程图

4.2.2检测预约流程设计

用户进入检测预约页面后选择预约类型与医生，系统验证所选时段是否可预约。预约信息提交后生成待处理记录并推送至对应医生端。医生查看预约列表时对申请进行审核，确认后可转入诊疗检查环节。用户可在个人中心查看预约状态变化，预约成功后在约定时间前往检测。检测报告出具后系统通知用户查阅，整个预约流程形成闭环。检测预约流程如图4-4所示。

图4-4 检测预约流程图

4.2.3医嘱处方流程设计

医生在诊疗过程中根据患者病情开具医嘱处方，选择药品并填写用法用量。处方信息提交后系统校验药品库存与患者过敏史，通过后生成待支付处方记录。用户端收到处方通知后进入支付页面选择支付方式完成结算。支付成功状态回传至医生端，医生据此安排后续诊疗或药品发放。若支付超时或用户取消，处方状态自动失效需重新开具。医嘱处方流程如图4-5所示。

图4-5 医嘱处方流程图

4.2.4健康随访流程设计

医生对慢病登记患者发起健康随访，选择随访类型并填写随访计划。系统记录随访时间与目标后生成待执行任务，到期前向医生发送提醒。医生执行随访时录入患者当前健康指标与随访结果，系统自动更新慢病信息档案。随访记录汇总后可查看历史趋势与干预效果，为调整治疗方案提供依据。管理员可统计各医生随访完成率进行监督。健康随访流程如图4-6所示。

图4-6 健康随访流程图

4.2.5投诉反馈处理流程设计

用户在投诉反馈页面填写问题标题与具体内容，上传相关凭证后提交。系统生成反馈编号并将投诉信息推送至管理员后台。管理员查看投诉内容后进行调查核实，必要时联系涉事医生了解情况。处理完成后填写回复内容提交，用户端收到反馈结果通知。若用户对处理结果不满意可再次提交投诉，系统记录完整处理过程。投诉反馈处理流程如图4-7所示。

图4-7 投诉反馈处理流程图

4.3数据库设计

数据库设计是系统开发的基础环节，关系型数据库通过二维表结构组织数据，其规范化原则能够减少数据冗余、维护数据一致性。MySQL作为成熟的关系型数据库管理系统，在本系统中承担用户信息、医生档案、检测预约等结构化业务数据的持久化存储任务。数据库设计遵循第三范式要求，通过主键与外键约束建立数据表间的关联关系，事务处理机制保障处方支付等操作的数据完整性。索引优化提升高频查询的响应速度，存储过程封装复杂统计逻辑供管理员调用。合理的数据模型设计为系统高效运行提供支撑[18]。

4.3.1E-R图设计

E-R图（实体关系图）是一种用来做数据建模的图形化工具，描述实体、属性以及实体之间的关系。以图示的形式来辅助数据库结构的分析与设计，清楚地表明数据间的相互联系，利于后续的数据库开发及管理工作。下面给出系统全局E-R图以及各个实体的属性图[19]。

图4-18 系统E-R图

4.3.2数据库表设计

数据库表设计就是根据业务需求来确定数据库表的结构、字段类型和关系。通过规范化的设计，保证数据的完整性、一致性、效率，避免冗余的数据，为后续的数据查询、存储、维护提供清晰的结构。以下是系统的数据库表设计展示。数据库表设计

医生信息表主要用于存储医生的执业资料与专业背景。主要包括医生编号、医生姓名、医生职称、擅长方向、出诊时段等字段。如表4-1所示。

表4-1 医生信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	doctor_information_id	int	11	是	是	医生信息ID
2	doctor_number	varchar	64	否	否	医生编号
3	doctors_name	varchar	64	否	否	医生姓名
4	doctor_title	varchar	64	否	否	医生职称
5	good_at_direction	varchar	64	否	否	擅长方向
6	visitation_period	varchar	64	否	否	出诊时段

药品信息表主要用于记录药品基础数据与库存信息。主要包括药品编号、药品名称、药品价格、药品剂型、药品规格等字段。如表4-2所示。

表4-2 药品信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	drug_information_id	int	11	是	是	药品信息ID
2	drug_no	varchar	64	否	否	药品编号
3	drug_name	varchar	64	否	否	药品名称
4	drug_price	double	-	否	否	药品价格
5	pharmaceutical_dosage_form	varchar	64	否	否	药品剂型
6	drug_specifications	varchar	64	否	否	药品规格

疾病信息表用于维护疾病分类与诊断标准。主要包括疾病编号、疾病名称、分类层级、归属系统、诊断标准等字段。如表4-3所示。

表4-3 疾病信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	disease_information_id	int	11	是	是	疾病信息ID
2	disease_number	varchar	64	否	否	疾病编号
3	name_of_disease	varchar	64	否	否	疾病名称
4	class_nameification_level	varchar	64	否	否	分类层级
5	attribution_system	varchar	64	否	否	归属系统
6	diagnostic_criteria	text	65535	否	否	诊断标准

诊疗项目表记录可提供的检测与检查服务项目。主要包括项目编号、项目名称、项目类别、收费价格、适用科室等字段。如表4-4所示。

表4-4 诊疗项目表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	diagnosis_and_treatment_items_id	int	11	是	是	诊疗项目ID
2	project_number	varchar	64	否	否	项目编号
3	project_name	varchar	64	否	否	项目名称
4	project_category	varchar	64	否	否	项目类别
5	charged_price	double	-	否	否	收费价格
6	applicable_department	varchar	64	否	否	适用科室

检测预约表用于存储用户提交的检测申请信息。主要包括预约类型、预约时间、医生用户、普通用户、预约备注等字段。如表4-5所示。

表4-5 检测预约表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	test_appointment_id	int	11	是	是	检测预约ID
2	appointment_type	varchar	64	否	否	预约类型
3	appointment_time	datetime	-	否	否	预约时间
4	doctor_user	int	11	否	否	医生用户
5	ordinary_user	int	11	否	否	普通用户
6	appointment_remarks	text	65535	否	否	预约备注

医嘱处方表记录医生开具的治疗方案与用药信息。主要包括预约类型、预约时间、药品名称、服用方式、医嘱信息等字段。如表4-6所示。

表4-6 医嘱处方表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	doctors_prescription_id	int	11	是	是	医嘱处方ID
2	appointment_type	varchar	64	否	否	预约类型
3	appointment_time	datetime	-	否	否	预约时间
4	drug_name	varchar	64	否	否	药品名称
5	way_of_taking	varchar	64	否	否	服用方式
6	orders_information	text	65535	否	否	医嘱信息

健康档案表存储用户的健康监测数据与历史记录。主要包括记录编号、血压记录、血糖记录、心率记录、记录时间等字段。如表4-7所示。

表4-7 健康档案表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	health_archives_id	int	11	是	是	健康档案ID
2	record_number	varchar	64	否	否	记录编号
3	blood_pressure_recording	double	-	否	否	血压记录
4	blood_glucose_record	double	-	否	否	血糖记录
5	heart_rate_recording	double	-	否	否	心率记录
6	recording_time	datetime	-	否	否	记录时间

检测报告表存储检测结果与医生建议。主要包括检查项目、检查结果、报告信息、用户姓名、医嘱信息等字段。如表4-8所示。

表4-8 检测报告表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	test_report_id	int	11	是	是	检测报告ID
2	inspection_items	varchar	64	否	否	检查项目
3	inspection_results	varchar	64	否	否	检查结果
4	report_information	varchar	255	否	否	报告信息
5	user_name	varchar	64	否	否	用户姓名
6	orders_information	text	65535	否	否	医嘱信息

慢病信息表用于跟踪慢性病患者的病情变化。主要包括慢病类型、血压记录、血糖记录、心率记录、登记时间等字段。如表4-9所示。

表4-9 慢病信息表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	chronic_disease_information_id	int	11	是	是	慢病信息ID
2	chronic_disease_type	varchar	64	否	否	慢病类型
3	blood_pressure_recording	varchar	64	否	否	血压记录
4	blood_glucose_record	varchar	64	否	否	血糖记录
5	heart_rate_recording	varchar	64	否	否	心率记录
6	registration_time	date	-	否	否	登记时间

健康随访表记录医生对患者的跟踪随访情况。主要包括慢病类型、随访时间、随访结果、健康评估等字段。如表4-10所示。

表4-10 健康随访表

序号	字段名	类型	长度	是否非空	是否主键	备注
1	health_follow_up_id	int	11	是	是	健康随访ID
2	chronic_disease_type	varchar	64	否	否	慢病类型
3	follow_up_time	datetime	-	否	否	随访时间
4	follow_up_results	varchar	64	否	否	随访结果
5	health_assessment	text	65535	否	否	健康评估

4.4Hadoop平台设计

健康检测大数据背景之下，为了实现健康检测数据、健康档案的有效存储及分析，系统使用了Hadoop平台来进行处理。检测报告、健康随访记录、慢病跟踪日志这些非结构化的数据，会在系统运行的过程中被不断地产生出来。Hadoop配置模块在应用启动的时候按照属性条件来加载，创建FileSystem实例并设置文件系统的默认地址和数据块复制因子。工具类封装目录检查、文件上传下载和删除操作，检测报告生成之后调用上传接口将报告写入HDFS指定目录，文件路径和报告记录在MySQL中建立关联。用户查阅检测报告的时候系统从HDFS读取文件内容返回给前端，慢病跟踪数据定期导入Hive创建分析数据集，MapReduce作业根据年龄、地域、检测频次等维度统计慢性病检出率和干预效果，分析结果同步到MySQL供前端显示。Hadoop平台和Spring Boot后端通过API接口交互来完成从数据采集、存储、分析到应用的闭环，具有良好的扩展性，可以随着用户数量的增加而动态增加节点，为之后加入机器学习模型做疾病风险预测提供数据支持。

5系统实现

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服务预约功能实现

用户选择服务类型后进入预约表单页，填写预约时间与备注信息后提交。系统校验时段可约性后生成预约记录并推送至对应医生端。服务预约界面如图5-4所示。

图5-4 服务预约界面

5.1.5处方支付功能实现

医生开具处方后用户端收到待支付通知，进入处方详情页查看药品清单与费用。用户选择微信或支付宝方式完成支付，系统回调更新支付状态。处方支付界面如图5-5所示。

图5-5 处方支付界面

5.1.6投诉反馈功能实现

用户在投诉反馈页面填写标题与具体问题，上传相关图片凭证后提交。系统生成反馈编号并推送至管理员后台，处理结果通过消息通知用户。投诉反馈界面如图5-6所示。

图5-6 投诉反馈界面

5.1.7健康档案查看功能实现

用户进入健康档案页面可查看历次检测记录与健康指标，系统以列表形式展示血压、血糖、心率等数据。点击单条记录可查阅完整检测报告与医生建议。健康档案查看界面如图5-7所示。

图5-7 健康档案查看界面

5.1.8检测预约功能实现

用户选择检测项目与预约时段后提交申请，系统展示可预约医生列表供用户选择。预约成功后在个人中心可查看预约状态与后续安排。检测预约界面如图5-8所示。

图5-8 检测预约界面

5.1.9在线沟通客服功能实现

用户点击在线沟通入口进入会话页面，与医生或客服人员进行实时文字交流。系统记录聊天历史供双方查阅，未读消息在会话列表红点提示。在线沟通客服界面如图5-9所示。

图5-9 在线沟通客服界面

5.2医生功能实现

5.2.1药品信息功能实现

医生进入药品信息管理页面可查看所有药品列表，系统按药品名称、剂型分类展示。医生可通过搜索快速定位药品，点击详情查阅生产厂家与有效期。药品信息界面如图5-10所示。

图5-10 药品信息界面

5.2.2疾病信息功能实现

医生在疾病信息页面维护疾病分类与诊断标准，系统以树形结构展示分类层级。医生可查看疾病归属系统与诊断标准说明，支持按疾病名称检索。疾病信息界面如图5-11所示。

图5-11 疾病信息界面

5.2.3诊疗项目功能实现

医生查看诊疗项目列表，系统按项目类别分组展示收费价格与适用科室。医生在开具处方或检查时可快速引用项目信息，减少重复录入。诊疗项目界面如图5-12所示。

图5-12 诊疗项目界面

5.2.4健康档案功能实现

医生输入用户姓名或编号调阅患者健康档案，系统展示历史检测记录与健康指标趋势。医生可查看过敏史、家族病史等关键信息辅助诊断。健康档案界面如图5-13所示。

图5-13 健康档案界面

5.2.5健康指导功能实现

医生根据患者检测结果为用户制定个性化健康建议，填写指导信息后提交。系统将指导内容推送至用户端，同时记录在健康档案中备查。健康指导界面如图5-14所示。

图5-14 健康指导界面

5.2.6医生信息功能实现

医生可查看并维护个人执业信息，包括医生照片、擅长方向、出诊时段等内容。修改后提交需管理员审核，审核通过后前台展示更新。医生信息界面如图5-15所示。

图5-15 医生信息界面

5.2.7检查预约功能实现

医生进入检查预约列表页查看患者提交的申请，按预约时间排序展示待处理记录。点击详情可查看用户主诉与病史，选择通过或退回操作。检查预约界面如图5-16所示。

图5-16 检查预约界面

5.2.8医嘱处方功能实现

医生在开具处方页面选择药品并填写用法用量，系统自动计算费用。提交前可预览完整处方信息，确认后生成待支付记录推送用户。医嘱处方界面如图5-17所示。

图5-17 医嘱处方界面

5.2.9诊疗检查功能实现

医生对已通过预约的患者录入检查项目与要求，填写检查注意事项。系统生成检查任务并通知用户按时前往，检查结果待后续录入。诊疗检查界面如图5-18所示。

图5-18 诊疗检查界面

5.2.10检测报告功能实现

医生完成检查后填写检测结果与报告信息，上传相关附件后提交。系统将报告推送至用户端，同时归档至健康档案长期保存。检测报告界面如图5-19所示。

图5-19 检测报告界面

5.2.11慢病信息功能实现

医生对慢病患者登记慢病类型与当前指标，系统记录每次跟踪数据。可查看历史变化趋势，为调整治疗方案提供依据。慢病信息界面如图5-20所示。

图5-20 慢病信息界面

5.2.12健康随访功能实现

医生制定随访计划并选择随访患者，系统按计划时间提醒执行。随访时录入患者当前状况与评估结果，记录归档备查。健康随访界面如图5-21所示。

图5-21 健康随访界面

5.3管理员功能实现

5.3.1系统用户管理功能实现

管理员在用户管理页面可查看普通用户与医生用户列表，支持按姓名或状态筛选。可新增用户账号、重置密码或冻结异常账户，操作记录写入日志。系统用户管理界面如图5-22所示。

图5-22 系统用户管理界面

5.3.2药品信息管理功能实现

管理员维药品基础数据，可新增药品并填写名称、价格、剂型、规格等信息。支持批量导入与导出，对过期药品可下架处理。药品信息管理界面如图5-23所示。

图5-23 药品信息管理界面

5.3.3疾病信息管理功能实现

管理员管理疾病分类与诊断标准，可新增疾病并设置归属系统与分类层级。支持按疾病编号或名称快速检索，对错误信息可编辑或删除。疾病信息管理界面如图5-24所示。

图5-24 疾病信息管理界面

5.3.4诊疗项目管理功能实现

管理员维护诊疗项目列表，可新增项目并设置项目类别、收费价格与适用科室。支持按项目编号或名称查询，对价格调整可实时更新。诊疗项目管理界面如图5-25所示。

图5-25 诊疗项目管理界面

5.3.5健康档案管理功能实现

管理员可查看全平台用户健康档案，按记录编号或用户姓名检索。对异常数据可标记并通知医生复核，保障档案信息准确性。健康档案管理界面如图5-26所示。

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

5.3.6医生信息管理功能实现

管理员审核医生提交的执业资料变更申请，查看变更前后对比后选择通过或驳回。可手动更新医生职称与服务社区信息。医生信息管理界面如图5-27所示。

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

5.3.7检测预约管理功能实现

管理员查看所有检测预约记录，按预约时间或医生姓名筛选。对超时未处理的预约可人工干预，确保预约流程正常推进。检测预约管理界面如图5-28所示。

图5-28 检测预约管理界面

5.3.8医嘱处方管理功能实现

管理员监管全平台处方开具情况，可查看处方详情与支付状态。对异常处方可标记并追溯处理过程，保障用药安全。医嘱处方管理界面如图5-29所示。

图5-29 医嘱处方管理界面

5.3.9诊疗检查管理功能实现

管理员监督检查任务执行进度，查看已完成与待处理检查记录。可导出检查数据用于统计分析，为管理决策提供支撑。诊疗检查管理界面如图5-30所示。

图5-30 诊疗检查管理界面

5.3.10健康随访管理功能实现

管理员统计各医生随访计划完成率，查看随访记录与评估结果。对长期未随访患者可提醒医生跟进，提升慢病管理质量。健康随访管理界面如图5-31所示。

图5-31 健康随访管理界面

6系统测试

6.1测试目的

系统测试就是检验健康检测管理系统是否符合设计阶段所提出的各项功能需求和性能要求。按照预先设定好的测试用例来检验各个功能模块在实际运行过程中是否可以正确地处理用户的操作，数据流转是否符合预期。测试过程主要对用户预约、医生开方、管理员监管这三个主要业务进行完整性、正确性的测试。同时对系统在高负载情况下的响应时间、稳定性进行评价，发现存在的问题并及时加以改正，保证交付给客户的产品可以稳定可靠地运行到目标环境中。测试结果给后面系统维护、功能扩展提供基本的数据参考。

6.2测试方法

系统使用黑盒测试为主、白盒测试为辅的混合测试方法。黑盒测试根据各个功能模块设计测试用例，对用户注册登录、检测预约提交、处方支付流程、投诉反馈处理等业务场景进行测试，检验输入输出是否符合预期结果。白盒测试是检验核心业务逻辑代码路径覆盖情况，保证分支条件、循环结构等能够正确运行。功能性测试用手工测试模拟真实用户操作，性能测试用工具模拟多用户并发访问场景。测试过程中记录下缺陷现象和复现步骤，开发人员修复后再做回归测试以保证问题的解决[20]。

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 健康随访测试用例表

模块名称	测试内容	操作	预期结果	实际结果	结论
健康随访	制定随访计划	选择患者并填写随访时间与内容	系统生成随访任务并记录	随访任务生成	符合预期
健康随访	执行随访	到随访时间后录入随访结果与评估	随访状态更新为已完成	状态正常更新	符合预期
健康随访	随访记录查看	进入随访列表查看历史随访记录	历史随访记录完整显示	记录正常显示	符合预期

6.4测试结论

系统功能测试涉及服务预约、处方支付、投诉反馈、检测预约、医嘱处方、检测报告、健康随访这七个主要业务模块，总共做了21个测试用例的测试。测试结果说明各个模块功能正常，用户提交预约之后医生端可以及时收到申请，处方支付流程可以完成微信和支付宝两种方式的回调处理，投诉反馈从提交到管理员回复全过程信息同步准确。检测预约医生审核通过或者退回时状态更新及时，医嘱处方填写和预览功能满足诊疗业务需要，检测报告生成后可以推送至用户端并归档到健康档案中，健康随访任务可以正常创建和执行记录。所有的测试用例的实际结果都和预期的结果一致，系统功能满足设计的要求。

7总结

传统的健康检测管理方式存在着数据存储分散、信息共享滞后、居民健康档案不完整等现实问题，居民无法全面掌握自身的健康状况，医生在诊断时缺少历史数据的支持，重复检测和医疗资源的浪费现象比较普遍。本文设计并实现了一个基于Hadoop的健康检测管理系统，即把分散于各地的健康检测数据集中起来，打通居民与医疗机构间的健康检测数据交流渠道，提高居民健康服务的便捷性、连续性。以用户、医生、管理员三个角色为模块，对预约申请、诊疗开方、健康跟踪等所有的业务流程进行设计，实现系统的设计目的。

系统开发按照软件工程规范，分需求分析、系统设计、编码实现、测试验证四个阶段来完成。需求分析阶段对三类角色的业务操作进行梳理，确定各个功能模块的边界以及交互关系。系统设计阶段使用前后端分离的架构，前端用Vue框架来创建用户界面，后端用Spring Boot框架来处理业务逻辑，用Hadoop平台来存储分析大量的检测报告和健康档案，用MySQL来管理结构化的业务数据。编码实现阶段完成了用户端的预约支付、医生端的诊疗开方、管理员端的后台监管等主要功能的实现。测试阶段针对服务预约、处方支付、检测报告、健康随访等重要模块展开用例验证工作，得出结论各模块正常运行，数据流转无误。

由于开发周期以及实验环境所限，系统还存在着一些不足。处方支付模块只接模拟接口，没有和真实的微信、支付宝支付平台进行对接，交易安全还需要加强。Hadoop平台部署在单机测试环境下，没有搭建完整的集群，大数据处理能力不能充分发挥。健康档案数据分析功能比较简单，只能进行简单的查询和展示，没有使用机器学习模型进行疾病风险预测的能力。医生端移动适配没有做好，部分界面在手机端浏览的时候会出现显示问题。

后续研究可以从以下几个方面入手加以改善。创建Hadoop分布式集群，增大海量检测数据的存储量和分析速度。根据机器学习算法建立慢病风险预测模型，用健康档案数据给用户提供建议性的预警服务。开发医生端移动应用或者对现有的界面进行响应式改造，改善移动场景下使用的体验。系统整合检测预约、健康档案、慢病跟踪等服务，可以给基层医疗健康管理提供技术支持，有较好的应用推广价值。

参考文献

1. 黑马程序员.Spring Boot企业级开发教程[M].北京:人民邮电出版社,2024:258.
2. 徐家喜,王小正,朱杰.Java EE框架技术与案例教程[M].南京:南京大学出版社,2023:312.
3. 李磊.Java EE企业级应用开发实战[M].北京:人民邮电出版社,2023:257.
4. 十三,尼克陈.Spring Boot+Vue 3大型前后端分离项目实战[M].北京:电子工业出版社,2023:719.
5. 闾枫.Spring Boot项目开发教程[M].北京:人民邮电出版社,2022:264.
6. 周喜平.Spring Cloud微服务架构实战[M].北京:人民邮电出版社,2022:393.
7. 孙鑫.详解Spring Boot[M].北京:电子工业出版社,2022:528.
8. 钟林森.分布式中间件技术实战[M].北京:机械工业出版社,2022:935.
9. 李兴华,马云涛.Spring Boot开发实战[M].北京:人民邮电出版社,2022:312.
10. 约翰·卡内尔,伊拉里·华卢波·桑切斯.Spring微服务实战[M].北京:人民邮电出版社,2022:379.
11. 王志亮,纪松波.基于SpringBoot的Web前端与数据库的接口设计[J].工业控制计算机,2023,36(3):51-53.
12. 熊永平.基于SpringBoot框架应用开发技术的分析与研究[J].电脑知识与技术,2021,15(36):76-77.
13. 黑马程序员.Spring Boot企业级开发教程[M].北京:人民邮电出版社,2024:258.
14. 柳伟卫.Vue.js+Spring Boot全栈开发实战[M].北京:人民邮电出版社,2023:484.
15. 郑阿奇.MySQL数据库教程[M].北京:人民邮电出版社,2024:465.
16. 张成文.大数据技术基础[M].北京:人民邮电出版社,2024:247.
17. 王志亮,纪松波.基于SpringBoot的Web前端与数据库的接口设计[J].工业控制计算机,2023,36(3):51-53.
18. 王希,戴靓婕.MySQL数据库技术在Web动态网页设计中的运用研究[J].软件,2024,45(7):77-79.
19. 胡劲. 数据库信息管理系统的逻辑架构与功能设计探析[J]. 电脑知识与技术, 2023, 19(19): 96-98.
20. 李泳. Spring Boot开发与测试实战[M]. 北京: 人民邮电出版社, 2022: 435.

致谢

四年光阴如白驹过隙，行文至此，也意味着大学生活即将画上句号。回首这段求学时光，从入学时的懵懂到如今即将踏出校门，每一分成长都离不开师长、同窗与家人的支持与陪伴，心中充满感激之情。

感谢我的校内指导老师，从论文选题、开题报告到系统设计与论文撰写，老师在每个关键节点都给予悉心指导。老师治学严谨的态度深深影响着我，每当我在研究思路或技术实现上遇到困惑时，老师总能耐心点拨，引导我找到解决问题的方向。感谢企业导师在实习期间对我的帮助，让我在实践中理解软件开发流程，在项目落地的过程中积累了宝贵经验。

本次毕业设计从需求梳理到系统实现，经历了多次调整与完善。面对理论难点与技术瓶颈时曾一度感到迷茫，正是反复查阅文献、调试代码的过程让我逐渐找到突破的方法。当系统最终能够稳定运行、功能逐一实现时，所有的付出都变得值得。大学四年构建起的专业知识体系，让我在面对未来挑战时多了一份底气与从容。

感谢计算机学院全体老师四年来的辛勤教导，每一堂课都为我打下坚实的专业基础。感谢辅导员老师在生活与学业上的关心，让远离家乡求学的我倍感温暖。感谢实验室的伙伴们，无数个并肩奋战的日子、深夜讨论问题时的碰撞，都将成为青春记忆里最珍贵的部分。

特别感谢我的父母家人，二十多年来默默付出，始终做我最坚强的后盾。是你们的支持让我能够安心求学，在追逐梦想的路上无所顾虑。养育之恩无以为报，唯有继续努力，成为让你们骄傲的人。

毕业不是终点，而是新征程的起点。我将带着这份感恩之心走上工作岗位，用所学回馈社会，不负韶华，不负期望。

点赞+收藏+关注 → 私信领取本源代码、数据库