4. 医院排班数据基础

排班系统能否算得准、排得稳,取决于它掌握的主数据是否完整、一致、可追溯。主数据不是“人员名单”这么简单,而是把“谁可以做什么、在什么时间做、被什么规则约束、有什么个人诉求”翻译成计算机能推理的结构。本节围绕七类核心主数据展开:人员、资质、班次、岗位、需求、请假、偏好,并说明它们之间的引用关系与建模要点。

一、七类主数据的职责边界

先明确每类数据回答什么问题,避免字段混放。人员主数据回答“这个人是谁、属于哪个科室、用工性质如何”;资质主数据回答“这个人被允许承担哪些岗位”;班次主数据回答“一个班次从几点到几点、时长多少、属于哪类班型”;岗位主数据回答“这个位置需要什么资质、需要几个人”;需求主数据回答“某天某岗位需要多少人力”;请假主数据回答“某人在某时段不可用”;偏好主数据回答“某人倾向或不倾向什么班次”。

关键原则是:资质是人员与岗位之间的桥,需求是岗位与班次的桥,请假与偏好是人员对可用性和满意度的约束。若把“张三能上夜班”直接写进人员表,资质就无法复用,也无法支持换岗、借调与多院区场景。

医院排班主数据关系模型 人员—资质—岗位—需求—班次 的引用链,以及请假/偏好的约束作用 人员 Person 工号 / 姓名 / 科室 用工性质 / 合同工时 入职日期 / 状态 资质 Qualification 资质编码 / 名称 生效日 / 失效日 等级 / 发证机构 岗位 Position 岗位编码 / 名称 所需资质集合 所属科室 / 区域 班次 Shift 班次编码 / 班型 开始 / 结束时间 时长 / 跨天标记 需求 Demand 日期 / 岗位 所需人数 班次要求 请假 Leave 人员 / 起止时间 请假类型 审批状态 偏好 Preference 人员 / 班次 / 权重 持有 满足 产生需求 指定班次 约束 影响 约束层 请假 = 硬约束(不可排) 偏好 = 软约束(可权衡) 排班引擎的输入 可用人员 = 人员 − 请假 − 资质过期 待覆盖需求 = 需求 × 班次 × 岗位

二、人员与资质:把“能做什么”独立出来

人员表建议保留最小必要字段:工号(主键)、姓名、所属科室、用工性质(正式/合同/规培/进修/实习)、合同月工时、入职日期、在职状态。用工性质直接影响可排班次范围与加班规则,例如规培人员通常不单独承担夜班主班,进修人员可能只允许跟班。

资质表采用“人员—资质”多对多关系,字段包括:人员工号、资质编码、取得日期、失效日期、等级。资质编码应可枚举,例如“ICU-独立值班”“急诊-分诊”“手术室-器械护士”“PICC-置管”。岗位表则声明所需资质集合,例如“ICU夜班责任护士”要求 {ICU-独立值班, 基础生命支持}。排班时,系统对每个候选人员做资质匹配:人员持有的资质集合 ⊇ 岗位要求的资质集合,且所有资质在排班日期均未过期,才判定为资质合格。

资质过期是排班中最隐蔽的硬约束。建议在资质表中保留失效日期,并在排班前执行一次“资质有效性扫描”,把过期资质从可用集合中剔除,而不是在排班算法内部临时判断。

三、班次与岗位:时间模板与位置模板

班次是时间模板,描述“一段可被占用的工作时间”。典型字段:班次编码(如 D、N、A、P)、班型(白班/夜班/中班/行政班)、开始时间、结束时间、时长(小时)、是否跨天、是否计入夜班补贴。跨天标记很重要:夜班 22:00–06:00 跨越自然日,排班周期归属、休息间隔计算、工时统计都依赖它。

岗位是位置模板,描述“一个需要被填充的工作位置”。字段包括:岗位编码、岗位名称、所属科室、所需资质集合、默认班次集合、是否关键岗位。岗位与班次是多对多:同一岗位可排白班或夜班,同一班次可服务多个岗位。需求表则把两者绑定到具体日期:(日期,岗位,班次)→ 所需人数。例如“2025-06-10,ICU责任护士,夜班,需要 2 人”。

四、请假与偏好:硬约束与软约束

请假是硬约束。字段:人员工号、开始时间、结束时间、请假类型(年假/病假/事假/产假/培训)、审批状态。只有审批通过的请假才进入排班约束;待审批状态可作为预警但不阻断排班。请假的时间粒度建议精确到小时,以便处理“半天假”“调休两小时”等场景。

偏好是软约束。字段:人员工号、偏好对象(班次或日期)、偏好类型(希望/避免)、权重(1–5)。偏好不阻断排班,但参与目标函数打分。例如“张三避免连续夜班,权重 4”“李四希望周五白班,权重 2”。权重让排班引擎在满足硬约束的前提下,尽量提升整体满意度,而不是简单地把偏好当作必须满足的条件。

五、主数据建模的落地检查

建模完成后,建议用一组最小校验用例验证数据是否可用:

校验项检查内容不通过时的典型后果
资质覆盖每个岗位所需资质是否都有至少一名在职人员持有需求无法被满足,排班出现空缺
资质有效期排班日期是否落在资质有效区间内排了不具备资质的人,存在合规风险
班次时间合法性结束时间是否晚于开始时间,跨天标记是否正确工时统计错误,休息间隔计算失真
需求完整性每个(日期,岗位,班次)是否都有需求记录漏排或重复排班
请假冲突已审批请假是否与已排班次重叠人员冲突,需要临时换班
偏好权重范围权重是否在约定区间内(如 1–5)目标函数被异常值主导

一个可参考的最小数据样例(示例数据,非真实医院数据):

人员: P001 张三 急诊科 正式 月工时174h
资质: P001 持有 [急诊-分诊(2024-01-01~2026-12-31), BLS(2024-03-01~2026-02-28)]
岗位: POS-ER-TRIAGE 急诊分诊 所需资质 [急诊-分诊]
班次: SHIFT-D 白班 08:00-16:00 8h 不跨天
需求: 2025-06-10 POS-ER-TRIAGE SHIFT-D 需要 2 人
请假: P001 2025-06-10 08:00~12:00 事假 已审批
偏好: P001 避免 SHIFT-N 权重 3

基于以上数据,排班引擎在 2025-06-10 白班分诊岗位上的可用人员集合为:持有“急诊-分诊”且资质未过期、且当天 08:00–16:00 无已审批请假的人员。张三因 08:00–12:00 有事假,只能覆盖 12:00–16:00,若岗位要求全程在岗,则张三不满足该班次;若允许拆班,则可作为部分覆盖候选。偏好“避免夜班”不影响白班排班,但会在夜班候选打分时降低张三的优先级。

主数据建模最常见的错误是把“岗位要求”写成“人员属性”。一旦人员调岗或岗位要求变更,散落在人员表中的资质信息就无法批量维护。坚持“人员—资质—岗位”三表分离,是排班系统可维护性的底线。

总结来看,七类主数据构成一条清晰的引用链:人员通过资质匹配岗位,岗位在日期上产生需求,需求指定班次,请假削减可用人员,偏好调整候选优先级。把这条链上的每个对象、每个字段、每种关系定义清楚,排班算法才有稳定、可解释的输入基础。