[开源] 住院床位实时智能调度系统：面向护士长的多目标优化分配工具，支持 CLI 快速决策、Web 可视化监控与 API 集成调用
本项目是专为临床护理管理一线设计的住院床位实时智能调度系统，核心解决护士长在日常排床中面临的三类刚性压力：急诊患者必须即刻收治、男女患者需物理分隔、各科室床位配额不可突破；同时兼顾等待时长压缩、病区负载均衡等柔性目标。我们采用 Google OR-Tools 的混合整数规划（MIP）求解器构建约束满足型优化引擎，输入当前床位状态、待入院患者列表及规则配置，输出可落地的分配推荐方案。系统提供三种交付形态：命令行工具（CLI）供值班护士快速生成/验证方案；轻量 Web 面板（纯 HTML/CSS/JS，无外部依赖）呈现床位热力图、等待队列时间轴与推荐结果对比；以及 FastAPI 封装的 REST API，便于接入医院 HIS 或护理移动终端。技术栈聚焦 Python 3.11+ 生态（OR-Tools、pandas、Pydantic），前端零框架，全栈 Docker 可选部署，不绑定云服务或特定数据库。
定位与能力范围
我们不做床位预约平台，也不做电子病历延伸模块。本项目明确服务于病房护士长、护理组长、院级床位协调员这三类直接承担排床决策责任的角色。它不替代人工判断，而是把“该不该收”“收去哪”“谁先谁后”这些反复权衡的过程，转化为可配置、可复现、可追溯的规则驱动流程。硬约束如「急诊患者必须分配至急诊专用床」和「同一病室不得混住异性患者」由求解器强制保障；软约束如「优先缩短等待超 4 小时患者的入床时间」和「避免某病区占用率突增至 95% 以上」则通过加权目标函数引导最优解方向。所有规则均映射到代码中的rules/模块，支持按院区、时段、科室动态启用或调整，无需修改求解逻辑本身。
核心功能模块
系统能力围绕「数据—规则—求解—呈现」闭环展开，每个环节职责清晰、接口内聚：
模块 | 职责说明 | 关键能力体现 |
|---|---|---|
数据模型（models/） | 定义床位（Bed）、患者（Patient）、科室（Department）三类核心实体及其字段语义 | Bed.status区分空闲/占用/锁定； |
约束规则（rules/） | 分离业务逻辑与算法实现，硬约束保底线，软约束提体验 | 硬约束含急诊优先、男女分床、科室配额封顶；软约束含等待时长最小化、病区负载标准差最小化 |
求解引擎（solver/） | 基于 OR-Tools MCP 构建多目标优化模型，接收结构化输入并返回分配映射 | 输入为 JSON 格式床位快照 + 患者列表 + 规则开关配置；输出为 |
CLI 工具（cli/） | 提供免界面、低门槛的本地化调度支持 | run --dry-run预演不落库； |
Web 面板（web/） | 前端完全静态，加载本地 JSON 数据即可运行 | 热力图以色阶直观显示各病区床位紧张度；时间轴标注每位等待患者已候时长；推荐方案以双栏对比呈现“当前状态”与“优化后状态” |
REST API（api/） | FastAPI 封装，开箱即用，适配医院内部系统集成 | POST /optimize接收患者与床位数据并返回推荐； |
使用与配置流程
上手无需部署服务器。从零开始只需三步：准备数据、试跑推荐、选择交付方式。
首先生成符合模型要求的初始数据。项目自带模拟器，可按真实医院布局生成结构化 JSON：
python -m bed_optimizer.data_simulator --output data/hospital_layout.json该命令将创建含 12 个病区、86 张床位、32 名待入院患者的样例数据，字段严格对齐models/中定义的必填项（如Bed.gender、Patient.wait_time_hours）。你也可用 Excel 整理后导出为同结构 JSON 替换此文件。
接着用 CLI 快速验证调度逻辑是否符合预期：
python -m bed_optimizer.cli run --dry-run该命令读取data/hospital_layout.json，调用求解器计算最优分配，并打印推荐结果与关键指标（如平均等待时长下降 X 小时、最大病区占用率从 92% 降至 78%）。确认无误后，加--apply参数即可写入本地状态文件，完成一次完整排床。
若需长期使用，可任选一种服务模式： - 启动 Web 面板：直接用浏览器打开web/index.html，点击“加载本地数据”按钮导入 JSON； - 启动 API 服务：运行python run_api.py，默认监听http://localhost:8000； - 集成进现有系统：调用/optimize端点传入 JSON 数据体，响应即为分配建议。
所有配置（如软约束权重、急诊床标识前缀、分床性别规则）均集中于config/目录下的 YAML 文件，修改后重启服务即生效。
工程结构与扩展路径
项目采用扁平化模块划分，各子包职责单一、边界明确，便于医院信息科或第三方开发者按需裁剪：
bed_optimizer/models/：仅含 Pydantic 模型定义，可直接复用于 HIS 数据对接层；
bed_optimizer/solver/：核心算法封装，输入输出均为标准 Python 字典，不耦合任何 I/O；
bed_optimizer/rules/：规则以函数形式组织，新增一条“儿科患者优先分配邻近护士站床位”只需在该目录下新增
.py文件并注册；bed_optimizer/web/：纯静态资源，
index.html中通过fetch()加载本地 JSON，无后端依赖，可直接托管在任意 HTTP 服务上；bed_optimizer/api/：FastAPI 路由与依赖注入层，若医院已有 Flask/Django 体系，可仅复用
solver/与models/模块自行封装。
这种结构意味着：中小医院可只用 CLI + Web 面板完成全部工作；大型医联体可在 API 层统一接入多家分院数据，由中心节点批量调度；科研团队亦可将solver/模块作为独立组件嵌入仿真平台，测试不同规则组合对平均住院日的影响。
数据字段与业务映射说明
所有字段设计均来自一线排床真实动作，非理论抽象。例如：
Bed.locked_reason不是空泛的“锁定”，而是明确记录
'cleaning'、'maintenance'、'quarantine'三类常见原因，Web 面板据此过滤掉不可用床；Patient.diagnosis字段虽不参与求解，但在 Web 时间轴中与
wait_time_hours并列展示，帮助护士长快速识别“腹痛待查”与“脑梗死恢复期”患者在等待队列中的相对优先级；Department.emergency_beds表示该科室预留的急诊专用床数量，与普通床位分开计数，确保急诊插队不挤占常规收治能力。
这些字段在说明文档中均有业务含义注释，而非仅类型声明。你不需要猜emergency_level=3代表什么，它直接对应分诊台填写的《急诊患者分级评估表》中第三级标准。
限制与适用边界
本系统不处理床位物理改造、不对接门禁硬件、不生成护理文书。它专注解决“已有资源如何更优配置”这一确定性问题。因此有三项明确边界：
- 不替代临床判断
：求解器不会建议将传染病患者分配至免疫缺陷患者隔壁病室，这类交叉感染风险需护士长结合感控规范人工干预；
- 不覆盖全周期管理
：仅处理“入院分配”环节，不涉及出院结算、转科路径、手术排程等下游流程；
- 不承诺绝对最优
：OR-Tools 在百级床位规模下可在 2 秒内收敛，但当待排患者超 200 人且硬约束高度紧耦合时，可能返回“无可行解”。此时 CLI 的
detect-conflicts命令会明确指出冲突项（如“急诊床位已满且无空闲男床满足分床要求”），把问题显性化而非掩盖。
这些限制不是缺陷，而是我们对护理管理本质的尊重：技术负责厘清约束、呈现选项、压缩试错成本；最终拍板，永远属于那个站在病区走廊里、手里攥着最新体温单的人。
项目地址：
https://github.com/nexorin9/bed-optimizer