1、绪论

1.1 研究背景

近年来，国内大型综合医院普遍面临床位资源配置与患者住院需求之间的结构性矛盾。一方面，优质医疗资源向少数头部医院集中，导致热门科室“一床难求”；另一方面，部分非核心科室床位周转率偏低，资源闲置现象并存。根据国家卫生健康委员会发布的统计公报，三级医院平均床位使用率常年在百分之九十以上高位运行，而部分二级医院及基层医疗机构床位使用率则不足百分之七十，资源错配问题突出。在这种大环境下，跨科室、跨病区的机动床位共享模式逐渐成为医院管理研究的热点。已有学者从管理流程再造、信息系统集成等角度进行了探索，但多数研究停留在制度设计或信息平台搭建层面，对调度算法的实际性能评估较少涉足。少数引入优化算法的研究又往往过度简化约束条件，例如忽略患者住院时间的连续性与床位占用的时间窗重叠问题，导致理论模型与临床实践之间存在明显脱节。

前人在床位调度领域的研究成果为本工作提供了重要参考，但现有方法的不足同样值得重视。多数文献采用先到先服务或按优先级排序的静态分配策略，未能充分考虑不同患者住院时长的差异性对后续床位资源产生的连锁影响。另有部分研究尝试使用遗传算法或模拟退火等元启发式方法，虽然理论上可获得更优解，但计算开销较大，难以适应临床环境中对响应时效性的要求。基于此，本文选择以贪心算法为切入点，在优先级权重排序的基础上融入实时时间窗冲突检测机制，同时引入同优先级FIFO排序与多轮次防饥饿策略，试图在算法复杂度与调度效果之间寻求一种更具实用性的平衡。所要解决的核心问题是：在跨科室机动共享模式下，如何设计一套兼顾资源利用率与分配公平性的床位调度算法，并在真实模拟数据环境中验证其有效性。

从选题意义来看，本研究具有理论与实践两个层面的价值。在实践层面，机动床位共享是深化公立医院改革、提升资源利用效率的重要抓手之一。一套行之有效的智能调度工具能够帮助医院管理者快速响应床位需求变化，减少患者无效等待时间，缓解急诊拥堵，对于改善就医体验、优化医疗资源配置具有直接推动作用。从学科视角审视，将贪心策略与时间窗管理相结合的方法为资源调度类问题提供了新的思路，其可配置的权重参数体系使算法具备较强的场景适应能力，可迁移至手术室排程、检查设备预约等类似领域。随着医疗信息化程度的持续提高，基于数据的智能调度将成为医院运营管理的标准配置，本课题所做的基础性探索恰可为后续更复杂的多目标优化研究提供参考基线。

1.2 国内外研究现状

1.2.1国内研究现状

2021年，范雯怡等以某三甲医院分院区为例，通过科室间床位共享使用、建立科室专业组工作模式及多途径开展床位精细化统筹管理，解决公立医院一院多区床位管理问题[1]；同年，张泽瑞等在设置单边硬时间窗和运血车载容量限制等约束条件下，构建最小化总配送时间的运血车调度模型，并引入高效染色体编码方式设计改进遗传算法，解决灾害医学救援应急血液保障中运血车的调度优化问题[2]。2022年，陈龙等考虑响应性与准入性的权重测度指标反映医患公平性，建立多目标随机规划模型并采用改进后的NSGA2算法求解，解决医院病床调度中运营成本大及医患关系公平性的问题[3]；章莉丽等通过建立多院区床位一体化管理制度、信息系统互联互通、院前手续互通等方法，解决不同院区间床位资源均衡利用及患者住院难等问题[4]。2023年，李娜为解决医联体内病床资源合理利用难题，提出博弈论方法构建动态博弈模型、排队论构建M/M/C排队模型、整数规划理论构建医联体患者病床优化配置模型这三种方法[5]。2024年，陈欣静等通过建设和完善医院信息系统、设立专人专岗，由一站式医疗服务中心对全院住院床位进行统筹管理（包括预住院统一检查检验及预约、跨病区床位调配、日间医疗管理等），解决医院床位运营效率问题[6]；宣晓东等以安徽一家三甲医院为例，基于Grasshopper软件结合系统布置设计法（SLP）和遗传算法，从不同患者人流路径最小值、空间关系积分最大值视角优化门诊空间布局并模拟验证[7]；赖玲悦构建基于时间序列的医疗排队模型T-A/B/C并引入优先级和抢占策略，同时构建基于强化学习的自适应调度模型QL-T-M/G/K和DQN-T-M/G/K，搭建基于DQN-T-M/G/K的自适应调度平台，解决医疗资源调度中的排队问题[8]；熊英采用质性研究与量性研究相结合的方法，通过访谈和问卷调查深入了解医护人员在全院床位统一调配模式下的工作体验和态度，为探索该模式实施中问题的解决方案提供参考依据[9]。2025年，杨丽娜等提出基于改进遗传算法（采用双切点交叉法和逆转变异法改进）的手术排班方法，通过建立最小化完成所有手术时间的数学模型，解决传统手术排班方法难以应对突发情况、易陷入局部最优解、无法实现资源最优配置的问题[10]。

1.2.2国外研究现状

2021年，Ankita, P. U. 等人提出了一个混合整数线性规划（MILP）模型并设计了一种基于提前完成策略的启发式方法以求解动态泊位分配问题，目标为最小化船舶周转时间，并通过与MILP模型在若干实例上的比较验证了该启发式方法在多数情况下能给出高效或最优解 [11]。2021年，Pishnamazzadeh, M. 等人提出了一个基于弹性工程的混合整数线性规划优化模型并采用模拟退火算法及一种新颖的初始解生成程序，实现在病房间共享空床以缓解病房拥挤和患者等待，并将病房关系优先级、患者性别、住院时长与房间可用性等因素纳入考虑，从而显著提升医院绩效 [12]。2022年, Somwong, P. 等人提出了一个利用物联网设备采集温度、声强和光照等实时数据并结合机器学习预测房间空闲状态的智能空房检测与预订系统，同时提供Web应用以提升预订管理的准确性和用户满意度 [13]。2022年, Akhil Kapoor 与 BalKrishna Mishra 提出了一种面向资源受限环境的混合床位分配系统，建议将所有择期手术患者于手术当天收治并以座椅进行术前准备，从而在案例中将平均住院天数与术前住院天数明显降低并提高床位利用率，强调按专科与急诊情况灵活分配床位的重要性 [14]。2025年, Rachaniotis, N. 等人提出了一个将乘法型效用函数与机器学习方法（如LSTM）相结合的框架，并通过将差分进化与深度强化学习整合以校准权重，旨在针对突发事件下重症资源的时变管理制定有效的流量调整策略，提升突发卫生事件中容量规划的决策适应性与效率 [15]。

1.3 主要研究内容

本文围绕机动床位共享场景下的调度优化问题，设计并实现了一套基于贪心算法的床位调度系统。研究工作首先从问题建模入手，将床位分配抽象为带时间窗约束的资源调度问题，明确了以最大化床位利用率和保障分配公平性为核心的双重目标。在系统架构层面，采用Flask作为后端服务框架，结合SQLAlchemy完成数据持久化，前端则以Bootstrap和ECharts构建响应式交互界面，整体形成从数据模拟、调度执行到结果可视化的闭环流程。算法部分重点设计并实现了贪心调度策略：通过优先级平方加权、床位类型权重系数及等待时长动态加成三重机制计算患者综合优先级，确保高紧急度患者优先获得资源；同时引入基于时间区间重叠检测的冲突校验模块，避免同一床位在相同时段被重复分配。为防止低优先级患者因连续轮空而陷入饥饿状态，进一步设计了多轮迭代调度与轮次加成机制，使等待时间与未分配次数能够逐步推高患者权重，平衡效率与公平之间的矛盾。作为对比基线，实现了随机分配算法以量化评估贪心策略的优化幅度。研究还针对正常就诊、高峰就诊及应急响应三种典型场景生成了差异化的模拟数据，从床位匹配成功率、床位利用率、优先级满足率及类型匹配率等多个维度进行算法效果验证，并借助调度日志模块记录了权重计算过程与冲突检测详情，为算法行为解释提供依据。最后通过调节床位数量与权重参数开展多组对比测试，分析了不同资源配置水平下调度效果的演变规律，为实际部署中的参数选型提供参考。

2、相关技术与理论

本章围绕机动床位共享系统的技术选型与算法理论基础展开论述，依次介绍后端服务框架、数据持久化方案、前端交互技术以及核心调度算法所依赖的数学原理，为后续系统设计与实现提供理论支撑。

2.1 Flask Web框架

Flask是一款基于Python语言的轻量级Web应用框架，其内核由Werkzeug工具库和Jinja2模板引擎构成。与Django等全栈框架相比，Flask不预设项目结构，不强制绑定数据库访问层或表单验证组件，开发者可根据实际需求灵活装配扩展模块。这一特性使其在中小规模科研原型系统及算法验证平台中应用广泛。本系统选择Flask作为后端服务框架主要基于三点考量：其一，Python在科学计算与算法原型开发领域生态成熟，将调度算法直接嵌入Web服务层可避免跨语言调用的复杂度；其二，Flask内置的开发服务器与调试工具能够快速响应代码变更，便于在算法调参阶段进行反复测试；其三，Flask的蓝图机制支持按功能模块拆分路由，有助于在后续迭代中向微服务架构演进。系统利用Flask的路由装饰器将床位查询、患者请求提交、调度模拟触发等业务接口映射为REST风格端点，请求与响应均采用JSON数据格式，确保前后端交互的标准化与低耦合。

2.2 SQLAlchemy对象关系映射

在数据持久化层面，系统选用SQLAlchemy作为Python与关系数据库之间的桥梁。SQLAlchemy遵循数据映射器模式，将数据库表结构抽象为Python类，将表记录映射为类的实例对象，使得开发者无需编写原始SQL语句即可完成增删改查操作。其会话机制通过工作单元模式跟踪对象状态变更，在事务提交时自动生成并执行相应的SQL指令。本系统涉及床位、患者请求、调度记录、算法结果及调度日志五类核心实体，实体之间存在复杂的外键关联关系，例如调度记录同时关联患者请求与床位，调度日志又反向指向调度记录。若采用手写SQL维护这些关系，不仅代码冗余度高，且易因级联更新疏漏引发数据不一致。SQLAlchemy的关系函数可声明式定义实体间的一对多或多对一关联，并通过惰性加载策略优化查询性能。此外，SQLAlchemy的数据库方言适配层使得系统可在不修改业务代码的前提下，从开发环境SQLite平滑迁移至生产级数据库管理系统，为后续部署提供了灵活性。

2.3 Bootstrap与ECharts前端技术

系统前端界面基于Bootstrap框架构建。Bootstrap提供了响应式栅格系统、预定义组件样式及跨浏览器兼容性封装，开发者通过组合其CSS类名即可快速搭建风格统一的交互界面。系统管理仪表盘中的统计卡片、床位列表表格、模态对话框均直接复用Bootstrap组件，在保证视觉一致性的同时大幅缩短了前端开发周期。数据可视化部分引入ECharts图表库，其底层依赖Canvas绘制技术，支持折线图、柱状图、饼图等多种图表类型的声明式渲染。本系统在管理员仪表盘及算法结果页面中利用ECharts绘制床位类型分布图、算法成功率对比图及利用率对比图，通过异步请求从后端API获取统计数据并动态更新图表配置项，直观呈现贪心算法与随机算法的性能差异。

2.4 贪心算法理论

贪心算法是一类在每一步决策中选择当前状态下局部最优解的算法范式，其不回溯、不进行全局搜索的特性使得时间复杂度通常维持在多项式级别，适用于对响应时效要求较高的在线调度场景。尽管贪心策略不保证获得全局最优解，但在具有最优子结构性质的问题中，局部最优递推可导向全局最优。床位调度问题可形式化为带时间窗约束的资源分配问题：给定患者集合与床位集合，在满足床位类型约束及时间区间互斥约束的前提下，寻求成功分配数量与资源利用率的最大化。该问题属于组合优化范畴，已被证明具有NP难特性，因而在可接受的时间开销内，贪心算法是一种实用的近似求解手段。

本系统贪心调度的核心在于患者优先级权重的量化。权重计算综合了三方面因素：病情紧急程度、床位类型匹配度以及患者等待时长。设患者的基础优先级等级为p，p取值范围为1至5，则基础优先级权重W_base的计算公式为：

W_base = p² × M

其中M为优先级权重乘数，默认取值为10。该平方增长函数使得高优先级患者获得显著放大的权重优势，例如优先级5患者的W_base为250，而优先级1患者仅为10，二者相差25倍，确保危重患者优先获得床位资源。

床位类型权重W_type由配置参数给定，重症监护床位赋值为3.0，急诊床位为2.5，普通床位为1.0，以此反映不同床位资源的稀缺程度与临床价值差异。

等待时间权重W_wait与患者自到达时刻起至调度时刻的累计时长相关。设以小时计的等待时长为H，每满K小时增加权重1分，并设定上限W_max防止低优先级患者无限累积优势，其计算公式为：

W_wait = min( H / K , W_max )

系统默认K取6，W_max取30，即等待时间每增加6小时，等待权重增加1分，最多累积30分。这一机制使得等待时间较长的患者权重逐步抬升，防止因优先级偏低而被无限搁置。

综合上述分量，患者的总调度权重W_total由下式确定：

W_total = W_base × W_type × α + W_wait + R × β

其中α为类型权重放大系数，默认值1.5，用于平衡病情优先级与床位类型的相对影响；R为当前已执行的调度轮次，β为每轮加成系数，默认值为5。该公式通过线性叠加等待权重与轮次加成，确保长时间未获分配的患者权重逐步攀升，从而在后续轮次中获得更高的被选择概率，实现防饥饿的公平性目标。

2.5 时间窗冲突检测

床位作为不可共享的时间槽资源，任意时刻只能被一名患者占用。冲突检测模块需判定患者请求时段与床位已安排时段是否存在重叠。设患者请求的入住时段为[T_start , T_end]，床位已存在的第i段占用时段为[T_i_start , T_i_end]，则时段重叠的充要条件为：

T_start < T_i_end 且 T_end > T_i_start

该不等式的直观含义是：新请求的开始时间早于已有占用的结束时间，且新请求的结束时间晚于已有占用的开始时间。只有当所有已安排时段均不满足此条件时，方可认定该时段可用。系统在候选床位筛选过程中逐一遍历床位的时间窗记录，执行上述重叠判定，若检测到冲突则将该床位排除或降级处理。

2.6 调度评估指标

为量化对比贪心算法与随机基线算法的性能差异，系统引入以下核心评估指标。床位匹配成功率S_rate定义为成功分配患者数占请求总数的百分比：

S_rate = ( N_success / N_total ) × 100%

其中N_total表示请求总数，N_success为成功分配计数。

床位利用率U_rate从时间维度衡量资源占用效率，设调度周期内总可用床位小时数为H_total，实际占用床位小时数为H_used，则利用率的计算公式为：

U_rate = ( H_used / H_total ) × 100%

其中H_total由各床位在周期内的可用时长累加求得，H_used为所有成功调度记录的实际占用时长之和。此外，优先级满足率与床位类型匹配率分别用于评估高优先级患者保障程度及床位类型与需求的一致性，共同构成算法效果的多维度评价体系。

3、系统分析

3.1 可行性分析

3.1.1经济可行性分析

机动床位共享系统的开发成本主要集中在软件开发人力投入与服务器部署费用两个方面。系统基于Flask、SQLite等开源技术栈构建，无需采购商业数据库授权或专用中间件，软件许可费用为零。开发过程由个人独立完成，人力成本可控。硬件层面，系统可在普通云服务器或院内现有虚拟化平台上运行，初期部署仅需最低配置即可支撑日均千级请求处理。从预期效益来看，系统上线后能够提升床位周转效率，缩短患者平均住院等待时间。以二十张床位的模拟测试为例，贪心算法较随机基线平均提升利用率约二至三个百分点，折合每月每床位多利用约十六小时，直接对应可增收治患者数量。若按三级医院床位日收费均值估算，年度增收治效益远超系统开发投入，投资回收周期预计在三个月以内。综上所述，系统从经济上是可行的。

3.1.2技术可行性分析

系统后端采用Flask框架，该框架在Python生态中已高度成熟，社区活跃且文档完备，能够满足Web服务开发的基本需求。数据持久层使用SQLAlchemy对象关系映射，支持SQLite、MySQL、PostgreSQL多种数据库方言，可在开发与生产环境间无缝迁移。核心调度算法采用贪心策略结合时间窗冲突检测，算法复杂度为O（n×m×k），其中n为患者数，m为床位候选数，k为单床位时间槽数量。在五百患者、二十床位的典型规模下，单次调度执行耗时控制在秒级以内，符合临床辅助决策的响应时效要求。前端基于Bootstrap和ECharts构建，兼容主流浏览器且无需安装客户端插件。综上所述，系统从技术上是可行的。

3.1.3操作可行性分析

系统面向管理员与普通用户设计了差异化的操作界面。管理员端提供床位状态管理、患者请求审核、调度模拟触发、结果图表分析及调度日志查询等功能，所有操作均通过表单选择或按钮点击完成，关键步骤设有确认对话框以防止误操作。普通用户端仅涉及床位申请提交与调度结果查看，界面简洁，引导清晰。系统上线前配套编写用户操作手册，管理人员经简单培训即可熟练使用。综上所述，系统从操作上是可行的。

3.2 需求分析

3.2.1业务流程分析

本系统的核心业务围绕床位资源调度展开，按参与角色可划分为患者请求提交、管理员审核调度及结果分析反馈三个主要阶段，具体流程如下。

患者请求提交流程：普通用户登录系统后进入申请床位页面，填写患者姓名、联系电话、就诊科室、床位类型需求、病情描述、期望入住时间及预计住院天数等必要信息，提交后生成待审核记录。系统自动为每条请求赋予默认优先级，等待管理员介入处理。此流程涉及的核心业务动作包括申请信息录入、数据校验及请求入库。

图3.1患者申请业务流程

管理员调度管理流程：管理员进入患者请求管理页面后，可按状态筛选待处理记录，逐一审核病情描述并调整优先级等级。确认无误后，可选择贪心算法或随机算法执行批量调度，也可手动为特定患者分配合适床位。调度过程中，系统根据时间窗冲突检测结果自动筛选可用床位，生成调度记录并更新床位占用状态。该流程还支持重置请求状态以重新运行调度测试。

图3.2管理员调度业务流程

结果查看与分析流程：调度完成后，管理员可在算法结果页面查看不同场景下的成功率与利用率对比图表，并通过调度日志追溯每条分配决策的权重计算过程与冲突检测详情。普通用户可在调度结果页面查看当前申请的分配状态，若已分配则显示床位编号、入住时间及预计出院时间，历史申请记录亦可供查阅。

图3.3结果查询业务流程

3.2.2功能需求分析

依据用户角色划分，系统需提供以下功能模块。

管理员角色功能：第一，床位管理功能，支持查看所有床位状态，手动将床位标记为可用、占用或维护中。第二，患者请求管理功能，支持按状态筛选患者请求列表，调整请求优先级，手动分配床位或拒绝请求，以及一键批量调度。第三，调度模拟功能，支持选择正常就诊、高峰就诊、应急响应三种预设场景运行算法对比测试，并实时展示成功率与利用率结果。第四，结果查看功能，以图表形式呈现贪心算法与随机算法在各场景下的性能差异，支持历史结果回溯。第五，调度日志功能，记录每次分配的时间戳、算法类型、权重计算明细、冲突检测结果及最终分配状态，支持按条件筛选和详情查看。

图3.4管理员用例图

普通用户角色功能：第一，床位申请功能，填写患者信息与住院需求后提交待审。第二，调度结果查看功能，实时跟踪当前申请的审核状态及分配床位信息。第三，历史记录功能，按时间倒序列出本人所有申请记录及其处理结果。

图3.5普通用户用例图

基于上述分析，管理员用例图如图3.4所示。管理员用例包括：床位管理、请求审核、优先级调整、手动分配、批量调度、场景模拟、结果对比、日志查阅。普通用户用例图如图3.5所示，用例包括：提交申请、查看调度结果、浏览历史记录。

3.2.3非功能性需求分析

第一，响应时间需求。患者请求提交及调度结果查询操作应在两秒内完成页面响应，批量调度算法执行时间在五百条请求规模下不超过五秒，以保证管理员交互流畅性。

第二，可靠性需求。系统应能正确处理时间窗冲突检测逻辑，杜绝同一床位同一时段被重复分配的情况发生。调度失败时需完整记录失败原因，避免数据状态不一致。

第三，可扩展性需求。算法权重参数应支持通过配置文件调节，床位类型分布比例与场景模拟数据量应可在不修改核心代码的前提下灵活调整，为后续算法优化预留接口。

第四，易用性需求。管理界面中的批量操作按钮应有明确标注，图表应随鼠标悬停显示具体数值，关键操作需提供二次确认机制以防止误触。

第五，可维护性需求。后端代码遵循模块化组织，调度算法与Web服务层解耦，便于单独进行算法单元测试与性能调优。调度日志采用结构化JSON字段存储冲突详情与候选床位评估结果，方便后续问题排查与数据审计。

4、系统设计

4.1 系统架构设计

本系统采用分层架构模式组织代码逻辑，按照数据流动方向自底向上划分为数据持久层、业务逻辑层、路由控制层及前端展示层四个层级。数据持久层基于SQLAlchemy对象关系映射框架，负责定义床位、患者请求、调度记录、算法结果及调度日志五类实体模型，封装对SQLite数据库的增删改查操作，向上层提供统一的会话管理接口。业务逻辑层位于数据持久层之上，包含贪心调度算法模块与随机分配算法模块，独立处理优先级权重计算、时间窗冲突检测及多轮调度迭代逻辑，不依赖于Web请求上下文，可单独进行单元测试与性能调优。路由控制层由Flask框架的视图函数构成，接收前端HTTP请求，解析参数后调用业务逻辑层完成数据处理，最终以JSON格式或渲染模板方式返回响应。前端展示层采用Bootstrap响应式布局与ECharts图表库，负责管理员仪表盘、床位管理界面、调度结果对比图等可视化内容的呈现。各层之间遵循单向依赖原则，业务逻辑层不感知路由控制层的请求细节，数据持久层不包含业务规则判断，保证了系统的可维护性与扩展性。

图4.1系统架构图

系统架构如图4.1所示（注：以文字描述层次关系）。自下而上分别为：数据库层（SQLite数据库文件）、数据访问层（SQLAlchemy ORM模型）、业务逻辑层（贪心调度器与随机调度器）、Web服务层（Flask路由与视图函数）、前端界面层（Bootstrap页面模板与ECharts图表组件）。请求自前端发起，经Flask路由分发至对应视图函数，视图函数调用调度器执行业务计算，调度器通过ORM模型读写数据库，结果逐层返回前端渲染。

4.2 系统功能设计

本系统旨在为医院床位资源提供一套智能化调度管理工具，核心功能包括床位状态管理、患者请求审核、调度算法执行及结果可视化分析。按照用户角色与业务边界，系统功能划分为管理员端模块与普通用户端模块两大组成部分。管理员端涵盖床位管理、请求管理、调度模拟、结果查看及调度日志五个子模块。床位管理支持查看全院床位实时占用状态，并可手动变更床位状态属性。请求管理提供待审请求列表展示、优先级人工调整、手动分配床位及拒绝请求操作。调度模拟模块允许管理员在正常就诊、高峰就诊、应急响应三种预设场景下运行贪心算法与随机算法的对比测试，实时返回成功率与利用率数据。结果查看模块以图表形式呈现历史调度结果，支持按场景与算法类型筛选。调度日志模块记录每次分配的详细决策过程，包括权重计算分量、候选床位评估结果及冲突检测详情。普通用户端包含床位申请提交、当前调度结果查询及历史记录浏览三个子模块。床位申请提交引导用户填写患者基本信息、床位需求及期望入住时段。调度结果查询实时反馈审核状态及分配床位信息。历史记录浏览按时间倒序展示过往申请及处理结果。

图4.2系统功能模块

系统功能模块如图4.2所示（注：以文字描述层次结构）。顶层为机动床位共享系统，向下分为管理员端与用户端两大分支。管理员端分支下挂床位管理、请求管理、调度模拟、结果查看、调度日志五个叶子模块；用户端分支下挂床位申请、调度结果、历史记录三个叶子模块。

4.3 数据库设计

4.3.1数据关系设计

本系统选用关系型数据库SQLite作为数据存储引擎。各数据表之间存在明确的外键关联关系，用于维护实体间的引用完整性。患者请求表通过用户标识外键关联至用户表，表示每条申请由特定用户提交。调度记录表同时外键关联患者请求表与床位表，形成“一个请求对应一条调度记录、一条调度记录引用一张床位”的关系链路。调度日志表进一步外键关联患者请求表、床位表及调度记录表，实现调度过程与决策明细的追踪追溯。算法结果表不参与外键关联，独立存储各场景下不同算法的统计数据，供结果对比模块直接读取。

图4.3系统E-R图

系统数据关系如图4.3所示。用户表与患者请求表为一对多关系，一个用户可提交多条申请。患者请求表与调度记录表为一对多关系，同一请求在多次模拟中可能产生多条调度记录。床位表与调度记录表为一对多关系，一张床位上可发生多次调度安排。调度记录表与调度日志表为一对一关系，每条调度记录对应一条详细的日志条目。

4.3.2数据库表设计

本系统数据库表用于存储用户账户信息、床位资源信息、患者入院请求、调度分配记录、算法评估结果以及调度过程日志，各表字段设计兼顾业务字段完整性与查询效率。以下对核心数据表结构进行说明。

（1）用户信息表（user_bed）

user_bed表记录系统注册用户的身份信息及权限角色，字段包括用户唯一标识、登录用户名、密码哈希值及角色标识。其中角色字段取值为admin或user，用于区分管理员与普通用户的访问权限。user_bed数据表结构如表4.1所示。

段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	用户唯一标识，自增
username	VARCHAR(80)	否	否	否	登录用户名，唯一
password_hash	VARCHAR(120)	否	否	否	密码哈希值
role	VARCHAR(20)	否	否	否	角色，admin或user
created_at	DATETIME	是	否	否	账户创建时间

（2）床位信息表（bed_bed）

bed_bed表记录医院所有床位的基本属性与实时状态，字段包括床位编号、床位类型、所属科室、所在楼层及状态标识。床位类型取值为ICU、GENERAL、EMERGENCY三种。bed_bed数据表结构如表4.2所示。

字段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	床位唯一标识，自增
bed_number	VARCHAR(20)	否	否	否	床位编号，唯一
bed_type	VARCHAR(20)	否	否	否	床位类型
department	VARCHAR(50)	否	否	否	所属科室
floor	INTEGER	否	否	否	所在楼层
status	VARCHAR(20)	是	否	否	状态，available/occupied/maintenance
created_at	DATETIME	是	否	否	记录创建时间

（3）患者请求表（request_bed）

request_bed表记录患者提交的住院申请信息，包含患者身份、病情描述、优先级、床位类型需求、期望入住时间及预计住院时长等字段。外键user_id关联至user_bed表。request_bed数据表结构如表4.3所示。

字段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	请求唯一标识，自增
patient_id	VARCHAR(50)	否	否	否	患者编号
patient_name	VARCHAR(100)	否	否	否	患者姓名
user_id	INTEGER	是	否	是	关联user_bed表id
department	VARCHAR(50)	否	否	否	就诊科室
priority	INTEGER	否	否	否	优先级，1至5
bed_type_required	VARCHAR(20)	否	否	否	所需床位类型
description	TEXT	是	否	否	病情描述
contact_phone	VARCHAR(20)	是	否	否	联系电话
expected_start_time	DATETIME	是	否	否	期望入住时间
expected_duration_days	INTEGER	是	否	否	预计住院天数
arrival_time	DATETIME	否	否	否	到达时间
estimated_duration	INTEGER	否	否	否	预计住院小时数
status	VARCHAR(20)	是	否	否	状态，pending/assigned/completed/rejected
scenario	VARCHAR(20)	否	否	否	所属场景，normal/peak/emergency
created_at	DATETIME	是	否	否	申请提交时间

（4）调度记录表（schedule_bed）

schedule_bed表记录每次床位分配的结果，外键patient_request_id关联request_bed表，外键bed_id关联bed_bed表。schedule_bed数据表结构如表4.4所示。

字段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	调度记录唯一标识，自增
patient_request_id	INTEGER	否	否	是	关联request_bed表id
bed_id	INTEGER	否	否	是	关联bed_bed表id
algorithm_type	VARCHAR(20)	否	否	否	算法类型，greedy/random/manual
start_time	DATETIME	否	否	否	入住开始时间
end_time	DATETIME	否	否	否	预计出院时间
actual_duration	INTEGER	是	否	否	实际占用小时数
success	BOOLEAN	是	否	否	是否分配成功
created_at	DATETIME	是	否	否	记录创建时间

（5）算法结果表（result_bed）

字段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	结果记录唯一标识，自增
scenario	VARCHAR(20)	否	否	否	场景名称
algorithm_type	VARCHAR(20)	否	否	否	算法类型
total_requests	INTEGER	否	否	否	总请求数
successful_assignments	INTEGER	否	否	否	成功分配数
success_rate	FLOAT	否	否	否	成功率
total_bed_hours	INTEGER	否	否	否	总可用床位小时数
used_bed_hours	INTEGER	否	否	否	已使用床位小时数
utilization_rate	FLOAT	否	否	否	床位利用率
created_at	DATETIME	是	否	否	记录创建时间

result_bed表存储各场景下不同算法的汇总统计指标，供结果对比模块查询展示。result_bed数据表结构如表4.5所示。

（6）调度日志表（log_bed）

log_bed表详细记录每次调度决策的过程信息，包括权重计算各分项数值、候选床位评估详情、冲突检测结果及失败原因等，外键分别关联request_bed表、bed_bed表及schedule_bed表。log_bed数据表结构如表4.6所示。

字段名	数据类型	允许空	主键	外键	字段说明
id	INTEGER	否	是	否	日志唯一标识，自增
patient_request_id	INTEGER	是	否	是	关联request_bed表id
bed_id	INTEGER	是	否	是	关联bed_bed表id
schedule_id	INTEGER	是	否	是	关联schedule_bed表id
algorithm_type	VARCHAR(20)	否	否	否	算法类型
success	BOOLEAN	是	否	否	分配是否成功
failure_reason	VARCHAR(200)	是	否	否	失败原因
timestamp	DATETIME	是	否	否	日志时间戳
conflict_detected	BOOLEAN	是	否	否	是否检测到冲突
conflict_details	TEXT	是	否	否	冲突详情JSON
priority_weight	FLOAT	是	否	否	优先级权重分值
bed_type_match_weight	FLOAT	是	否	否	床位类型匹配权重
time_weight	FLOAT	是	否	否	等待时间权重
total_weight	FLOAT	是	否	否	综合权重总分
candidate_beds_eval	TEXT	是	否	否	候选床位评估JSON
requested_start	DATETIME	是	否	否	请求开始时间
requested_end	DATETIME	是	否	否	请求结束时间
created_at	DATETIME	是	否	否	记录创建时间

4.4 贪心算法设计与实现

贪心算法的核心思想是在每一步决策中均选取当前状态下的最优选择，通过局部最优解的递推逼近全局最优目标。将这一思想应用于床位调度问题，需在每一次床位分配时，从待处理患者队列中选取综合优先级最高的请求，为其匹配最优可用床位，如此循环直至无可分配资源或请求全部处理完毕。本系统贪心调度器围绕优先级权重计算、床位匹配策略、时间窗冲突检测及多轮迭代调度四个核心环节展开设计与实现。

（1）优先级权重计算

患者综合调度权重的计算融合了病情紧急程度、床位类型需求等级、等待时长及历史轮空次数四类因素，以此量化不同患者在分配序列中的相对紧迫性。设患者优先级等级为p，取值范围为1至5，数值越大表示病情越危重。基础优先级权重W_base采用二次函数增长，计算公式为：

W_base = p² × M_priority

其中M_priority为优先级权重乘数，系统默认设定为10。此函数使优先级5患者的基础权重达到250，优先级1患者仅为10，二者相差25倍，确保危重患者占据显著优势。

床位类型权重W_type依据床位稀缺程度与临床重要性预先设定。参照Config配置中BED_TYPES的定义，重症监护床位权重为3.0，急诊床位为2.5，普通床位为1.0。设患者请求的床位类型为T_req，则W_type取值即为对应床位类型的预设权重值。

等待时间权重W_wait用于量化患者自到达以来累计等待时长对紧迫性的提升作用。设已等待小时数为H，每累计K小时增加权重1分，同时设定上限W_max以防低优先级患者无限累积优势。计算公式为：

W_wait = min( H / K , W_max )

系统默认K取6，W_max取30，即等待时间每增加6小时，等待权重加1分，至多累积30分。

轮次加成机制为多轮调度设计。设当前调度轮次序号为R，每轮加成系数为β，则轮次加成分值为R × β。系统默认β取5，最多迭代5轮，因此轮次加成上限为25分。

综合以上分量，患者的总调度权重W_total由下式确定：

W_total = W_base × W_type × α + W_wait + R × β

式中α为类型权重放大因子，默认值为1.5，用于调节床位类型匹配对综合权重的影响强度。总权重计算完成后，各患者的分配顺序按总权重降序排列，权重相等时以到达时间先后为序，体现同优先级先到先服务的公平原则。

上述权重计算中涉及的可配置参数汇总如表4.7所示。

参数名称	默认值	取值范围	说明
优先级权重乘数	10	5~20	控制优先级平方增长速度
等待时间增量周期	6	3~12	每多少小时增加1分
等待权重上限	30	10~50	等待时间权重的封顶值
轮次加成系数	5	2~10	每轮未分配所获加分
类型权重放大因子	1.5	1.0~3.0	调节类型权重对总权重的影响
最大调度轮次	5	3~10	多轮迭代的上限次数

（2）床位匹配策略

在确定患者分配顺序后，贪心调度器需为当前患者从可用床位集合中筛选出最优床位。筛选过程采用三级匹配策略，兼顾类型适配度、科室归属一致性及资源紧张时的灵活降级。

第一级为精确匹配。筛选出床位类型与患者需求完全相同且状态为可用的床位，并将同科室床位置于候选序列前列。若存在同科室且无时间窗冲突的床位，则直接分配。精确匹配能够最大限度保证医疗资源与患者需求的契合度。

第二级为灵活匹配。当精确匹配无合适床位时，根据患者需求类型放宽候选条件。普通床位需求可使用任意类型床位，优先选用普通床位以避免占用重症资源；急诊床位需求可降级使用普通床位，但不可占用重症床位；重症监护需求仅限使用重症床位，不允许降级。第二级筛选同样优先选择同科室床位。

第三级为兜底匹配。在前两级均无法找到可用床位时，遍历所有状态为可用的床位，按科室匹配优先及床位类型等级排序后分配。此级匹配通常出现在资源极度紧张时段，确保患者尽可能获得床位而非直接拒绝。

（3）时间窗冲突检测

床位作为不可共享的时间资源，任意时刻只能被一名患者占用。在选定候选床位后，必须检测其历史调度记录是否与患者请求的入住时段重叠。设请求时段为[T_start , T_end]，床位已安排的第i段占用时段为[T_i_start , T_i_end]，则存在冲突的判定条件为：

T_start < T_i_end 且 T_end > T_i_start

若该条件对任意一条已安排时段成立，则认定当前床位存在时间窗冲突，需继续考察下一候选床位。系统在调度过程中实时维护各床位的时间占用列表，冲突检测每次均基于最新状态进行，确保分配方案在时序上的可行性。

（4）多轮迭代调度机制

为防止低优先级患者在单轮调度中因资源被高优先级患者抢占而长期搁置，算法引入多轮迭代与轮次加成机制。调度流程如图4.4所示：首轮将所有待处理请求按初始综合权重排序，逐一为其匹配床位，成功则生成调度记录并将请求移出队列；未成功的请求轮次计数器R加一，等待重新计算权重后进入下一轮。迭代过程持续至所有请求均获分配或达到最大轮次上限。达到上限仍未分配的请求记录为调度失败，并在调度日志中标注失败原因。

多轮迭代结合等待时间权重与轮次加成的双重作用，使得低优先级患者的综合权重随等待时长与轮空次数累积而逐步攀升，最终在后续轮次中获得被选择的机会。该机制在优先保障危重患者的同时，有效避免了低优先级请求陷入无限饥饿状态，实现了调度效率与分配公平性的平衡。

图4.4算法执行流程图

算法执行流程如图4.4。开始→输入患者请求列表与床位列表→初始化轮次计数器→计算各请求综合权重→按权重降序排列→遍历请求执行床位匹配→冲突检测→成功则生成调度记录，失败则轮次加一→判断是否达到最大轮次或队列为空→结束。

5、系统实现

5.1 开发环境配置

本系统开发与测试环境配置如表5.1所示。后端服务基于Python语言构建，采用Flask作为Web应用框架，开发工具选用Visual Studio Code。数据库使用SQLite进行轻量级数据存储，通过SQLAlchemy工具包实现对象关系映射。前端界面基于Bootstrap框架构建响应式布局，图表渲染由ECharts库提供支持。系统开发及运行均在Windows操作系统环境下完成，浏览器兼容Chrome、Edge等主流内核。

配置项	版本或说明
操作系统	Windows 11
开发语言	Python 3.10
Web框架	Flask 3.0
数据库	SQLite 3
ORM工具	SQLAlchemy 2.0
前端框架	Bootstrap 5
图表库	ECharts 5
开发工具	Visual Studio Code

5.2 功能模块实现

依据第四章功能模块设计，系统实现了管理员端与普通用户端两大类功能。以下对核心模块的实现细节进行说明。

5.2.1床位管理模块

床位管理模块负责全院床位资源的展示与状态控制。管理员登录后进入床位管理页面，系统通过Bed模型查询全部床位记录，并依据Schedule表中当前时段的调度占用情况计算各床位的实时可用状态。床位列表以表格形式呈现，包含床位编号、类型、科室、楼层及当前状态字段。管理员可通过下拉菜单将指定床位手动标记为可用、占用或维护中，状态变更通过异步请求提交至后端路由处理，后端在更新Bed表status字段的同时，若由占用转为可用且存在正在执行的调度记录，则自动将对应调度记录的结束时间截断至当前时刻，同步更新患者请求状态为已完成。该模块核心代码位于app.py中的manage_beds视图函数及set_bed_status路由。

5.2.2患者请求管理模块

患者请求管理模块汇总所有用户提交的住院申请。管理员可按状态筛选pending、assigned、completed及rejected四类请求，列表展示患者基本信息、优先级、床位类型需求、期望入住时间及病情描述摘要。管理员可人工调整请求的优先级等级，或直接拒绝申请。手动分配功能通过弹出模态框加载指定类型的可用床位列表，选中床位后提交分配请求，后端执行时间窗冲突校验并生成调度记录。批量分配功能支持选择贪心算法或随机算法，可针对选中患者、全部待处理患者或重置后全部患者三种范围执行一键调度。该模块对应app.py中的manage_requests视图及batch_assign、assign_bed、reject_request等路由函数。

5.2.3调度模拟模块

调度模拟模块嵌入于管理员仪表盘中，提供正常就诊、高峰就诊及应急响应三种预设场景的算法对比测试入口。管理员点击对应场景按钮后，前端通过异步请求向run_simulation路由发送场景参数，后端依次执行贪心调度器与随机调度器的批量调度方法，分别计算成功率与利用率指标，将结果写入AlgorithmResult表，同时为每次分配生成对应的ScheduleLog日志记录。执行完成后将两种算法的成功率与利用率以JSON格式返回前端，前端调用ECharts绘制柱状对比图。该模块支持重置数据选项，可在重新测试前清空历史调度记录。

5.2.4调度日志模块

调度日志模块记录每次床位分配的决策全过程。ScheduleLog表存储了患者标识、分配床位、算法类型、权重计算各分量值、候选床位评估结果、冲突检测详情及失败原因等信息。管理员在调度日志页面可按算法类型和分配结果筛选记录，点击详情按钮可弹出模态框展示完整决策数据，包括优先级权重、类型匹配权重、等待权重及总权重的数值，以及候选床位评估表格和冲突检测结论。该模块为算法行为追溯和参数调优提供了数据支撑。对应实现位于app.py的schedule_logs视图及schedule_log_detail路由。

5.2.5用户申请与结果查询模块

普通用户登录后进入床位申请页面，填写患者姓名、联系电话、就诊科室、床位类型、病情描述、期望入住时间及预计住院天数后提交，系统生成PatientRequest记录并置为pending状态。调度结果页面实时展示当前申请的审核状态，若已分配床位则显示床位编号、入住时间及预计出院时间。历史记录页面按时间倒序列出用户全部申请及其处理结果，支持按状态和床位类型筛选。该部分功能对应app.py中的user_dashboard、schedule_result及history视图。

5.3 贪心算法实现

贪心调度器的实现封装于algorithms/greedy.py中的GreedyScheduler类。类初始化时接收床位类型配置字典、已有调度记录列表及权重参数配置字典三个可选参数。calculate_priority_weight方法依据公式计算患者综合权重，返回各分量及总分的字典结构。check_time_conflict方法遍历床位已安排时段，逐一执行重叠判定，返回冲突标志及冲突详情列表。find_available_bed方法按照三级匹配策略筛选候选床位，在遍历过程中调用冲突检测，将每张候选床位的评估结果记录至候选列表，返回首个无冲突的床位对象。schedule_batch方法实现多轮迭代调度逻辑，外层循环控制轮次上限，内层按当前权重排序处理剩余请求，已分配请求移出队列，未分配请求轮次计数器递增。

随机分配算法作为对比基线实现在algorithms/random_algo.py中。RandomScheduler类在批量调度时随机打乱患者顺序，对每位患者从可用床位中随机选取一张无时间窗冲突的床位进行分配，不涉及任何优先级或类型匹配逻辑。