传统挂号最让人头疼的地方往往不是“不会挂号”而是患者不知道医生什么时候出诊、号源还有多少、预约之后该什么时候到院医院侧又需要同时处理排班、挂号记录、患者签到和医生接诊。把这些环节拆开看每一项都不复杂但一旦要在同一个系统里保持状态一致就会变成一个完整的业务链。这套医疗预约系统以 Android APP 作为患者移动端入口后端由 SpringBoot 提供业务接口MySQL 负责保存患者、医生、排班、健康数据和就诊记录。系统包含注册用户、医生用户和管理员三类使用者核心不是单纯“在线挂号”而是把预约前、到院、就诊和后台调度几个阶段连接起来。一、把一次就诊过程拆开系统逻辑就清楚了从患者视角看整个系统可以理解为一条连续的就诊路径注册登录 → 查看医疗知识/个人健康数据 → 查找医生 → 选择医生与号源 → 预约挂号 → 到院在线签到 → 医生查看挂号记录 → 完成就诊与回复与此同时医生端负责个人信息、挂号记录、就诊回复和排班查看管理员则维护用户、医生排班、医疗知识与健康宣教等后台数据。三个角色围绕同一批业务数据协同工作避免患者端看到的医生信息、排班和后台实际配置相互脱节。图1 系统功能结构图二、预约之前先解决“找谁看、什么时候看”患者真正发起挂号之前需要先完成两件事找到合适的医生以及确认自己的基础健康信息。系统中的医生信息模块展示医生姓名、职称、所属院区、科室、学术成就、擅长领域、余号数量和挂号费用等数据让用户可以先筛选医生再进入预约流程。图2 医生信息列表健康管理模块则把血糖、血压、血脂等指标按测量日期保存形成个人健康数据记录。它并不替代诊断而是让患者能在 APP 内持续查看自己的基础健康信息也方便后续就诊时形成更完整的个人数据链。图3 健康管理界面此外医疗知识模块提供医学常识、疾病预防、药物使用、营养饮食等健康资讯把预约系统从单一“挂号工具”扩展成了一个兼顾就医与健康信息获取的移动端入口。图4 医疗知识查看界面三、预约之后在线签到把“排队”变成可记录的状态完成挂号后患者并不是直接进入就诊。系统还设计了在线签到环节患者到院后通过移动端进行签到系统记录签到时间并把对应挂号状态更新为已签到。这样医生能够判断患者是否已经到达也能减少传统窗口签到带来的重复排队。图5 在线签到界面从数据设计上看签到记录不仅保存患者和医生还关联挂号单号与签到时间。这一点很重要因为签到不是孤立操作它必须能追溯到具体哪一次挂号否则就无法支撑后续的就诊安排。四、医生端不是“看名单”而是管理一整段接诊过程患者完成预约后业务重心会转到医生端。医生首先能够维护自己的专业资料包括职称、院区、科室、学术成就和擅长领域等这些内容同时会成为患者选医生时的重要参考。图6 医生个人信息维护界面挂号记录模块集中展示已经预约的患者信息医生可以提前了解患者姓名、挂号科室、预约时间和相关就诊信息。相比患者端的“我挂了哪个号”医生端更关心“接下来有哪些患者需要处理”。图7 医生挂号记录界面就诊回复模块则承接接诊之后的结果。医生可以结合患者情况填写诊疗回复系统将患者、医生、挂号单号和填写内容关联起来使一次就诊从“预约成功”继续延伸到“有结果可查”。图8 医生就诊回复界面五、排班是这套系统的资源开关医疗预约系统里最容易被忽略的其实是排班。患者能不能挂到号首先取决于医生是否在对应日期和班次出诊。系统的医生排班数据包含排班月份、上班日期、星期、班次、工作地点和医生用户等字段它决定了哪些时间段可以被患者预约。图9 医生排班查看界面医生可以查看自己的工作安排而管理员可以从后台统一调整排班。这样同一份排班数据分别服务于两个目的医生用于确认出诊计划管理员用于医院资源调度。图10 管理员医生排班管理界面六、管理员后台把“人、排班、内容”统一起来管理员端承担的是平台运行层面的治理工作。用户管理模块可以维护管理员、注册用户和医生用户的信息并根据角色进行权限区分这也是患者数据、医生信息和后台管理操作能够隔离的基础。图11 用户管理界面除了排班管理员还负责医疗知识和健康宣教内容。前者偏向医学常识与疾病预防资料后者用于发布健康教育文章、视频或海报。它们共同构成 APP 的内容服务部分。图12 医疗知识添加界面图13 健康宣教管理界面七、技术实现移动端和后端之间怎么协同项目技术栈由 Android、SpringBoot 和 MySQL 组成。Android 负责移动端页面与交互让患者可以随时查看医生、健康数据、预约信息并进行签到SpringBoot 负责身份验证、业务处理和接口服务MySQL 保存用户、医生、排班、健康管理、签到和在线就诊等数据。层次技术在系统中的作用移动端Android患者注册登录、查看医生、健康管理、预约与签到业务服务SpringBoot处理用户身份、业务请求、排班/挂号/就诊等接口数据层MySQL持久化医生、排班、健康数据、签到和就诊记录登录流程也体现了典型的服务端校验逻辑系统先判断用户名和密码是否为空再检查用户是否存在随后获取密码进行校验只有验证通过后才能进入对应功能。图14 用户登录流程图八、数据库设计真正关键的是“号源、签到、就诊”之间的关联系统总 E-R 图将医生、用户、预约挂号、公告资讯和管理员等数据连接起来。对医疗预约业务而言数据库最重要的不是表数量而是能否把医生信息、排班、患者和每一次挂号/就诊记录关联起来。图15 系统总 E-R 图核心数据表关键内容doctor_information医生姓名、职称、院区、科室、擅长领域、余号数量、挂号费用等doctor_scheduling排班月份、日期、星期、班次、工作地点和医生用户health_management患者、血糖、血压、血脂、测量日期等健康数据online_check_in医生、患者、挂号单号和签到时间online_consultation患者、医生、挂号单号、填写内容和就诊回复关联数据例如 online_check_in 表中保存 registration_number挂号单号online_consultation 同样保留挂号单号这使系统可以把“预约—签到—就诊”串成同一次医疗服务过程而不是三个互不相关的页面。九、测试时最值得关注的不是“按钮能不能点”而是业务冲突医疗预约场景存在明显的资源约束因此测试重点放在重复预约、号源已满、医生不存在、无效日期和签到超时等异常情况。相比普通 CRUD 系统这些边界条件更能检验系统是否真正理解预约业务。• 选择正确医生和日期时可以正常预约并生成预约信息• 目标日期号源已满时系统会提示更换日期• 选择不存在的医生时系统会阻止预约• 同一医生、同一时段重复预约时系统会识别已有预约并阻止重复提交• 患者未签到时不能继续就诊• 使用错误二维码签到时系统会提示二维码无效• 医生或患者超时签到时系统能返回对应超时状态。论文测试结果显示注册、登录、医生信息查看、预约挂号和在线签到等主要功能能够对正常输入与异常输入进行正确反馈。尤其是日期冲突、重复预约和签到异常等场景都能够给出明确提示。十、项目总结这套基于 Android 的医疗预约系统并不只是把线下挂号搬到手机上而是围绕一次就诊过程建立了完整的信息链患者先查看医生和健康信息再完成预约挂号与签到医生根据挂号记录进行接诊和回复管理员通过排班与用户管理维持平台运行。从项目学习角度看它涵盖了 Android 移动端开发、SpringBoot 接口服务、MySQL 数据建模、多角色权限、医生排班、号源管理、状态流转和异常校验等典型功能。后续还可以继续扩展预约提醒、电子病历对接、健康数据分析等方向。十一、用户入口注册与登录注册用户通过移动端创建账号并完成身份验证。注册数据会进行格式和完整性校验登录成功后才可以访问健康管理、医生信息、签到等个人业务。图16 用户注册界面图17 用户登录界面 本项目完整源码、MySQL 数据库文件以及相关项目资料已整理可用于课程设计、毕业设计和 Android SpringBoot 项目学习参考。需要完整源码、数据库文件以及项目部署资料的同学可通过文章末尾资源入口免费获取。项目资料仅供学习交流与二次开发参考。