[开源] 住院床位实时智能调度系统：面向护士长的多目标优化分配工具，支持 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区分空闲/占用/锁定Patient.emergency_level支持 1–5 级分级Department.quota与occupied实时反映科室配额使用率约束规则rules/分离业务逻辑与算法实现硬约束保底线软约束提体验硬约束含急诊优先、男女分床、科室配额封顶软约束含等待时长最小化、病区负载标准差最小化求解引擎solver/基于 OR-Tools MCP 构建多目标优化模型接收结构化输入并返回分配映射输入为 JSON 格式床位快照 患者列表 规则开关配置输出为{patient_id: bed_id}映射字典及冲突诊断报告CLI 工具cli/提供免界面、低门槛的本地化调度支持run --dry-run预演不落库emergency-insert单条命令完成急诊插队并重算全局方案detect-conflicts独立扫描当前状态是否违反硬约束Web 面板web/前端完全静态加载本地 JSON 数据即可运行热力图以色阶直观显示各病区床位紧张度时间轴标注每位等待患者已候时长推荐方案以双栏对比呈现“当前状态”与“优化后状态”REST APIapi/FastAPI 封装开箱即用适配医院内部系统集成POST /optimize接收患者与床位数据并返回推荐PUT /beds/{bed_id}支持移动端扫码更新床位状态POST /emergency-insert对接急诊分诊系统触发自动重排使用与配置流程上手无需部署服务器。从零开始只需三步准备数据、试跑推荐、选择交付方式。首先生成符合模型要求的初始数据。项目自带模拟器可按真实医院布局生成结构化 JSONpython -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/Obed_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_level3代表什么它直接对应分诊台填写的《急诊患者分级评估表》中第三级标准。限制与适用边界本系统不处理床位物理改造、不对接门禁硬件、不生成护理文书。它专注解决“已有资源如何更优配置”这一确定性问题。因此有三项明确边界不替代临床判断求解器不会建议将传染病患者分配至免疫缺陷患者隔壁病室这类交叉感染风险需护士长结合感控规范人工干预不覆盖全周期管理仅处理“入院分配”环节不涉及出院结算、转科路径、手术排程等下游流程不承诺绝对最优OR-Tools 在百级床位规模下可在 2 秒内收敛但当待排患者超 200 人且硬约束高度紧耦合时可能返回“无可行解”。此时 CLI 的detect-conflicts命令会明确指出冲突项如“急诊床位已满且无空闲男床满足分床要求”把问题显性化而非掩盖。这些限制不是缺陷而是我们对护理管理本质的尊重技术负责厘清约束、呈现选项、压缩试错成本最终拍板永远属于那个站在病区走廊里、手里攥着最新体温单的人。项目地址https://github.com/nexorin9/bed-optimizer