摘 要
随着我国医疗卫生事业快速发展，医疗废弃物产生量持续增长，其全流程规范化管理与安全处置已成为维护公共卫生安全的关键环节。传统医疗废弃物管理依赖人工登记与纸质台账，存在信息追溯困难、流转监管缺失、责任难以界定等问题，无法满足 "来源可查、去向可追、责任可究" 的监管要求。为解决上述痛点，本文设计并实现一套基于微信小程序与 PC 管理后台的医疗废弃物追溯管理系统。
系统采用前后端分离架构，后端以 Spring Boot 为核心，PC 管理端采用 Vue.js 开发，移动端依托微信小程序实现轻量化操作，数据存储采用 MySQL 数据库。系统覆盖科室登记、收运交接、库房暂存、转运出库、处置确认等全生命周期流程，具备扫码追溯、智能预警、数据统计、异常上报、权限控制与打印申请等功能，可满足多角色协同业务需求。
测试与应用表明，系统运行稳定、操作便捷，能够实现医疗废弃物全程数字化、可视化管理，有效提升管理效率与规范化水平，降低环境与健康风险，可为医疗机构医疗废弃物精细化管理与行业监管提供技术支撑。
关键词 ：医疗废弃物；全生命周期追溯；Spring Boot；微信小程序；MySQL
目 录
[第1章 绪论](#第1章 绪论)
[1.2 国内外研究现状](#1.2 国内外研究现状)
[1.3 研究内容](#1.3 研究内容)
[第2章 相关技术](#第2章 相关技术)
[2.1 Vue 前端技术](#2.1 Vue 前端技术)
[2.2 Spring Boot 后端技术](#2.2 Spring Boot 后端技术)
[2.3 MySQL 数据库技术](#2.3 MySQL 数据库技术)
[第3章 系统实现](#第3章 系统实现)
[3.1 系统可行性分析](#3.1 系统可行性分析)
[3.2 系统需求分析](#3.2 系统需求分析)
[3.3 非功能需求分析](#3.3 非功能需求分析)
[3.4 系统流程分析](#3.4 系统流程分析)
[第4章 系统总体设计](#第4章 系统总体设计)
[4.1 系统架构设计](#4.1 系统架构设计)
[4.2 系统功能设计](#4.2 系统功能设计)
[4.3 数据库设计](#4.3 数据库设计)
[第5章 系统实现](#第5章 系统实现)
[5.1 科室人员端功能实现（微信小程序）](#5.1 科室人员端功能实现（微信小程序）)
[5.2 收运人员端功能实现（微信小程序）](#5.2 收运人员端功能实现（微信小程序）)
[5.3 库房管理员端功能实现（微信小程序 / PC 端）](#5.3 库房管理员端功能实现（微信小程序 / PC 端）)
[5.4 处置厂人员端功能实现（微信小程序 / PC 端）](#5.4 处置厂人员端功能实现（微信小程序 / PC 端）)
[5.5 系统管理员端功能实现（PC 网页端）](#5.5 系统管理员端功能实现（PC 网页端）)
[第6章 系统测试](#第6章 系统测试)
[6.1 测试环境](#6.1 测试环境)
[6.2 功能测试](#6.2 功能测试)
[6.3 性能测试](#6.3 性能测试)
[6.4 测试结论](#6.4 测试结论)
[第7章 总结与展望](#第7章 总结与展望)
[7.1 总结](#7.1 总结)
[7.2 展望](#7.2 展望)
系统需求分析
医疗废物转运、入库、处置的信息化已成为医院规范化运营的重要组成14。基于医院医疗废弃物管理的实际业务流程，结合全生命周期追溯需求，对系统进行详细的功能与角色需求分析，明确各角色核心业务诉求，为系统设计与实现提供依据。
3.2.1 科室人员（微信小程序端）
科室人员作为医疗废弃物产生的源头主体，是系统的核心使用角色之一，其核心需求围绕科室日常医废管理展开。科室人员需通过微信小程序完成本科室医疗废弃物的分类、称重与登记操作，系统自动为每批次医废生成唯一追溯码，实现医废产生环节的源头记录；同时需根据医废类别完成规范分类与标签张贴，确保分类操作符合国家医疗废弃物管理规范要求。此外，科室人员需支持通过扫码或输入编号的方式，实时查询本科室产生废弃物的全流程流转状态，清晰掌握医废当前所处环节；并可随时查看科室医废产生统计数据、历史流转记录及系统公告，全面掌握科室医废管理情况，为科室日常管理与合规运营提供数据支撑。用例图如下图3.1所示。
收运人员（微信小程序端）
收运人员是连接科室与库房的关键枢纽，承担医废中间流转的核心职责，其需求聚焦于医废收运与转运交接的全流程管控。收运人员需按时到达各科室收取废弃物，通过微信小程序扫描医废追溯码，快速确认收取信息，完成科室与收运环节的交接；系统自动记录转运时间、收运人员等关键信息，实现流转环节的可追溯。同时，收运人员需具备异常上报能力，若在收运过程中发现包装破损、标识不清、分类错误等异常医废，可实时拍照并填写异常说明，一键上报至系统，通知相关负责人及时处理，有效防控医废流转过程中的安全风险。用例图如下图3.2所示。
库房管理员（微信小程序端）
库房管理员负责医废的暂存管理与转运出库，是医废全生命周期管理的中间管控角色，核心需求围绕库房库存管理与流程衔接展开。库房管理员需接收收运人员移交的医废，通过扫码完成入库登记，实时更新医废库存状态，实现医废入库环节的精准管控；同时需实时监控库房医废库存余量，管理医废存放区域，保障库房存储规范有序。此外，库房管理员需对接处置厂，安排转运车辆，完成医废转运出库登记，实现库房与处置环节的无缝衔接；并可随时查看库存统计报表，系统根据预设存储时长自动触发预警信息，提醒管理员及时处置超期医废，防止医废超期存储引发的安全风险。用例图如下图3.3所示。
处置厂人员（微信小程序端）
处置厂人员是医疗废弃物全生命周期的最终处置主体，核心需求聚焦于医废处置环节的确认与数据管理。处置厂人员到达医院库房后，需通过微信小程序扫描医废追溯码，确认接收医废信息，完成医废处置环节的交接，系统自动更新医废状态为 "已处置"，实现全流程闭环管理。同时，处置厂人员需支持查看本批次医废的完整来源记录、全流程流转轨迹与处置数据，确保医废来源可查、去向可追；并可定期汇总处置量与处置数据，上传至系统后台留档，满足监管部门对医废处置环节的溯源与审计要求。用例图如下图3.4所示。
系统管理员（PC 网页端）
系统管理员是系统的全局管控角色，负责全院医废管理系统的后台维护与全局管理，核心需求围绕系统运维、数据管控与权限管理展开。系统管理员需通过 PC 网页端完成全院各角色用户账号的管理，包括账号创建、权限分配、状态管控等，实现多角色权限的精细化管控；同时需维护科室信息、处置厂信息、医废分类字典等基础数据，保障系统基础数据的准确性与完整性。此外，系统管理员需具备全局追溯能力，可按时间、科室、编号等多维度检索医疗废弃物的全流程流转轨迹，实现医废全生命周期的全局监管；支持批量生成或打印追溯码标签，满足医院医废管理的实际操作需求；可设置库存预警阈值、存储时长上限等预警规则，实现系统智能预警；并可发布系统公告、配置轮播图，向各端用户推送重要通知，保障系统信息的及时同步。用例图如下图3.5所示。
系统功能设计
本系统围绕医院医疗废弃物全生命周期追溯管理需求，构建了 "微信小程序端 + PC 管理后台" 双端协同的功能体系，以唯一追溯码为核心线索，串联科室人员、收运人员、库房管理员、处置厂人员、系统管理员五类角色，实现医废从产生、收集、转运、入库到最终处置的全程可追溯、可监管、可审计，同时满足数据统计、异常预警、台账管理等院感与环保监管要求。
科室人员作为医废产生源头的操作者，核心功能聚焦 "医废登记与状态跟踪"，包括医废信息录入、分类选择、重量填写、追溯码生成与保存、登记记录查询、科室数据概览、追溯查询与重新打印申请等，同时可接收系统通知与预警消息，查看本科室医废全流程流转状态，确保源头信息真实、完整、可追溯。
收运人员作为医废流转的中间环节执行者，核心功能围绕 "收运任务与交接确认" 展开，包括待收运清单查看、扫码收运确认、异常医废上报、收运记录查询等，通过扫码完成医废从科室到库房的交接，实时更新医废状态，同步记录收运人、收运时间等信息，实现流转环节责任到人、操作留痕。
库房管理员作为医废库存与转运的管理者，核心功能聚焦 "入库管理、库存管控与转运出库"，包括扫码入库登记、重量核对、库存明细查看、库存统计分析、转运信息登记、出库确认等，实时监控库存状态与超期存放预警，完成医废从入库到转运至处置厂的全流程管控，保障库存安全与流转合规。
处置厂人员作为医废最终处置的执行者，核心功能围绕 "处置确认与记录管理" 展开，包括扫码处置确认、处置方式录入、处置记录查询、处置数据统计等，通过扫码完成医废最终状态闭环，记录处置单位、处置时间、处置方式等信息，实现医废从产生到处置的全生命周期闭环管理。
系统管理员作为平台运维与监管者，核心功能旨在 "保障系统合规稳定运行与全流程监管"，包括用户管理、科室管理、废弃物分类管理、追溯查询、追溯码打印、报表导出、数据统计分析、异常预警记录处理、预警规则配置、公告发布、轮播图管理等，通过后台集中管控，实现医废全流程数据的统一监管、统计分析与异常预警，为医院院感管理、环保合规与审计溯源提供全面支撑。
系统同时配套完善的辅助功能，包括多角色权限管控、数据隔离、状态单向流转校验、追溯码唯一性保障、二维码生成与打印、Excel 报表导出、定时预警任务等，确保系统操作安全、流程规范、数据准确，满足医院医疗废弃物追溯管理的全流程业务需求。总体功能如下图 4-2 所示。
物理结构设计
（1）系统用户表：存储所有系统用户信息，是整个系统的账号基础。
表4.1 系统用户表
|-----|------|------|-----|----|----|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
|-------------|--------------|---|-------------------|---|--------------------------------------------------------------------------------------------|
| id | int | 否 | - | 是 | 用户ID |
| username | varchar(50) | 否 | - | 否 | 工号/账号 |
| password | varchar(200) | 否 | - | 否 | 密码 |
| real_name | varchar(50) | 否 | - | 否 | 真实姓名 |
| phone | varchar(20) | 是 | NULL | 否 | 手机号 |
| role | varchar(20) | 否 | - | 否 | 角色：dept_staff-科室人员 transporter-收运人员 warehouse_admin-库房管理员 disposal_staff-处置厂人员 admin-系统管理员 |
| dept_id | int | 是 | NULL | 否 | 所属科室ID（科室人员专用） |
| avatar | varchar(500) | 是 | NULL | 否 | 头像路径 |
| status | tinyint | 是 | 1 | 否 | 状态：1启用 0禁用 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（2）科室信息表：存储医院所有科室信息
表4.2 科室信息表
|--------|--------------|------|------|----|------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | 科室ID |
| name | varchar(100) | 否 | - | 否 | 科室名称 |
| code | varchar(50) | 否 | - | 否 | 科室编号 |
| leader | varchar(50) | 是 | NULL | 否 | 负责人 |
| phone | varchar(20) | 是 | NULL | 否 | 联系电话 |
续表4.2 科室信息表
|-------------|----------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| status | tinyint | 是 | 1 | 否 | 状态：1启用 0禁用 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（3）废弃物分类表：定义医疗废弃物的标准分类。
表4.3 废弃物分类表
|-----|------|------|-----|----|----|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
|-----------------|--------------|---|-------------------|---|-------------|
| id | int | 否 | - | 是 | 分类ID |
| name | varchar(100) | 否 | - | 否 | 分类名称 |
| code | varchar(50) | 否 | - | 否 | 分类编码 |
| disposal_method | varchar(200) | 是 | NULL | 否 | 处置方式 |
| notes | varchar(500) | 是 | NULL | 否 | 注意事项 |
| status | tinyint | 是 | 1 | 否 | 状态：1启用 0禁用 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（4）科室人员扩展表：存储科室人员的额外信息。
表4.4 科室人员扩展表
|-------------|-------------|------|------|----|----|---|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 | |
| id | int | 否 | - | 是 | ID ||
| user_id | int | 否 | - | 否 | 用户ID ||
| title | varchar(50) | 是 | NULL | 否 | 职称（医生/护士等） ||
| employee_no | varchar(50) | 是 | NULL | 否 | 员工编号 ||
续表4.4 科室人员扩展表
|-------------|-------------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| position | varchar(50) | 是 | NULL | 否 | 岗位 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（5）收运人员扩展表：存储收运人员专属信息。
表4.5 收运人员扩展表
|---------------------|--------------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | ID |
| user_id | int | 否 | - | 否 | 用户ID |
| license_no | varchar(50) | 是 | NULL | 否 | 驾驶证号 |
| vehicle_no | varchar(50) | 是 | NULL | 否 | 收运车辆编号 |
| transport_area | varchar(200) | 是 | NULL | 否 | 收运区域 |
| driver_license_type | varchar(20) | 是 | NULL | 否 | 驾照类型 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（6）库房管理员扩展表：存储库房管理员信息。
表4.6 库房管理员扩展表
|----------------|--------------|------|------|----|----------------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | ID |
| user_id | int | 否 | - | 否 | 用户ID |
| warehouse_id | int | 是 | NULL | 否 | 所属库房ID |
| warehouse_name | varchar(100) | 是 | NULL | 否 | 库房名称 |
| admin_level | tinyint | 是 | 1 | 否 | 管理级别：1-普通管理员 2-高级管理员 |
续表4.6 库房管理员扩展表
|-------------|----------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（7）处置人员扩展表：存储处置厂人员信息。
表4.7 处置人员扩展表
|--------------------|--------------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | ID |
| user_id | int | 否 | - | 否 | 用户ID |
| disposal_unit | varchar(100) | 是 | NULL | 否 | 处置单位 |
| equipment_no | varchar(50) | 是 | NULL | 否 | 操作设备编号 |
| qualification_cert | varchar(200) | 是 | NULL | 否 | 资质证书 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
| update_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | update_time |
（8）预警记录表：存储系统自动触发的所有预警记录。
表4.8 预警记录表
|----------------|--------------|------|------|----|--------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | 预警ID |
| rule_id | int | 是 | NULL | 否 | 触发规则ID |
| waste_id | int | 是 | NULL | 否 | 关联医废ID |
| trace_code | varchar(64) | 是 | NULL | 否 | 追溯码 |
| warning_type | varchar(50) | 是 | NULL | 否 | 预警类型 |
| warning_msg | varchar(500) | 是 | NULL | 否 | 预警信息 |
| overtime_hours | int | 是 | NULL | 否 | 超时时长 |
续表4.8 预警记录表
|---------------|--------------|------|-------------------|----|------------------------------------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| dept_id | int | 是 | NULL | 否 | 科室ID |
| dept_name | varchar(100) | 是 | NULL | 否 | 科室名称 |
| source | varchar(20) | 是 | system | 否 | 来源：system-系统自动 manual-人工上报 |
| reporter_name | varchar(50) | 是 | NULL | 否 | 上报人姓名 |
| handle_status | varchar(20) | 是 | pending | 否 | 处理状态：pending-未处理 handled-已处理 ignored-已忽略 |
| handler_id | int | 是 | NULL | 否 | 处理人ID |
| handler_name | varchar(50) | 是 | NULL | 否 | 处理人姓名 |
| handle_time | datetime | 是 | NULL | 否 | 处理时间 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
（9）消息表：向用户推送消息。
表4.9 消息表
|------------------|--------------|------|--------|----|-----------------------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| id | int | 否 | - | 是 | 消息ID |
| user_id | int | 否 | - | 否 | 接收用户ID |
| title | varchar(200) | 否 | - | 否 | 标题 |
| content | text | 是 | - | 否 | 内容 |
| type | varchar(20) | 是 | system | 否 | 类型：warning-预警通知 system-系统通知 |
| related_waste_id | int | 是 | NULL | 否 | 关联医废ID |
| is_read | tinyint | 是 | 0 | 否 | 是否已读：0未读 1已读 |
| read_time | datetime | 是 | NULL | 否 | 阅读时间 |
续表4.9 消息表
|-------------|----------|------|-------------------|----|-------------|
| 字段名 | 数据类型 | 允许为空 | 默认值 | 主键 | 备注 |
| create_time | datetime | 是 | CURRENT_TIMESTAMP | 否 | create_time |
系统实现
5.1 科室人员端功能实现（微信小程序）
5.1.1 注册与登录模块
科室人员通过微信授权一键登录系统，系统自动校验用户身份与科室归属权限，完成登录后自动跳转至科室人员首页。模块支持密码找回、账号绑定等辅助功能，保障登录安全性与便捷性，同时记录登录日志，便于审计追溯。
追溯码生成与打印模块
医废信息登记完成后，系统基于唯一编码规则自动生成专属追溯码，以二维码形式展示，支持直接打印粘贴于医废包装袋上。追溯码作为医废全流程追溯的核心标识，确保每一袋医废从产生到处置全程可追踪。
收运人员端功能实现（微信小程序）
5.2.1 注册与登录模块
收运人员通过账号密码或微信授权登录系统，系统校验收运人员身份与负责区域权限，登录后自动跳转至收运人员首页，展示待收运任务清单，提升收运工作效率。
库房管理员端功能实现（微信小程序 / PC 端）
5.3.1 注册与登录模块
库房管理员通过账号密码登录系统，系统校验管理员身份与库房权限，支持双端登录，满足移动端现场操作与 PC 端后台管理的双重需求。
出库确认模块
转运出库时，管理员再次核对医废信息，完成出库确认，系统记录出库时间、出库人等信息，确保医废出库流程合规、可追溯。
系统管理员端功能实现（PC 网页端）
5.5.1 登录模块
系统管理员通过专属账号密码登录 PC 管理后台，系统采用权限校验机制，保障后台登录安全性，登录后跳转至管理员首页，展示系统概览数据。
追溯查询模块
管理员可通过追溯码查询任意医废的全生命周期流转轨迹，查看各环节操作信息，实现全流程监管与审计溯源，满足监管部门检查需求。
总结与展望
7.1 总结
本研究围绕医院医疗废弃物全生命周期追溯管理需求，设计并实现了基于微信小程序 + PC 网页端的双端协同医疗废弃物追溯管理系统。研究工作涵盖需求分析、系统设计、功能实现与测试验证等多个阶段，形成了一套完整的解决方案。在系统设计层面，采用前后端分离架构，以 MySQL 为数据存储核心，构建了科室人员、收运人员、库房管理员、处置厂人员、系统管理员五类角色的协同管理体系，实现了医废全流程可视化、规范化管控。在功能实现层面，系统完成了医废登记、扫码追溯、收运交接、库存管控、处置确认、智能预警与后台管理等核心功能，解决了传统人工管理中信息追溯困难、责任界定模糊、监管效率低下等痛点。在测试验证层面，通过搭建贴近实际的测试环境，完成功能与性能测试，验证了系统的稳定性、安全性与易用性。本系统的实现，为医院医疗废弃物管理提供了数字化、智能化工具，实现了 "来源可查、去向可追、责任可究" 的监管要求，提升了医院院感管理水平与环保合规性，具有较强的实际应用价值。
7.2 展望
尽管系统已完成开发与测试并通过验证，但在功能完善、技术升级与应用拓展方面仍存在进一步优化与拓展的空间，未来可从以下方向深入研究：
在现有功能基础上，新增医废包装智能检测、收运路线智能规划等功能，通过图像识别技术辅助收运人员检查包装合规性，基于算法优化收运路线，提升收运工作效率与精细化管理水平。同时，完善多语言支持与多院区协同管理功能，适配不同规模医院的管理需求与跨院区数据互通需求。
探索引入物联网传感器、区块链等技术，实现医废产生、收运、处置全流程的自动数据采集与信息不可篡改，提升系统的自动化水平与数据安全性。优化后端架构，引入微服务拆分与容器化部署，提升系统的可扩展性与迭代效率，支撑未来业务规模的扩大与功能升级。
将系统对接医院 HIS 系统、环保部门监管平台，实现数据互通与信息共享，满足上级部门监管检查与医院内部管理的双重需求。探索向社区卫生服务中心、中小型医疗机构推广应用，提供轻量化、定制化解决方案，扩大系统应用范围，推动医疗废弃物管理行业的标准化、信息化建设。