📚 课程目录第4章护理任务的数据模型设计

4. 护理任务的数据模型设计

病区护理任务协同平台的核心难点不在界面，而在于“谁在什么位置、为哪位患者、执行哪条医嘱、产生了什么结果”这一串信息能否被准确、可追溯地记录。数据模型设计就是把这串信息固化为实体、属性和关系。本节围绕五个核心实体展开：患者、床位、医嘱、护理任务、执行记录，并给出可直接落库的表结构与 E-R 关系。

一、五个实体的职责边界

患者实体（patient）是病区内一切护理活动的服务对象，保存住院号、姓名、性别、出生日期、过敏史等相对稳定的身份信息。注意：患者与床位是“随时间变化”的关系，患者会转床、出院，因此不能把床号直接写进患者表当作固定属性，否则历史追溯会失真。

床位实体（bed）描述物理位置，包含病区、房间号、床号、床位类型（普通/监护/隔离）、当前状态（空闲/占用/清洁中/停用）。床位是任务分派的空间依据，护士按责任床位组接收任务。

医嘱实体（medical_order）是任务的来源。一条医嘱包含医嘱号、患者、医嘱类型（长期/临时）、项目名称、剂量、给药途径、频次、开始时间、停止时间、开嘱医生、状态（新开/已审核/执行中/已停止）。长期医嘱会按频次“裂变”出多条任务，临时医嘱通常对应一次任务。

护理任务实体（nursing_task）是协同调度的最小工作单元，也是平台的中枢。它记录任务类型（给药、输液、测量生命体征、翻身、标本采集等）、计划执行时间、责任护士、所属病区/床位、优先级、任务状态（待接收/已接收/执行中/已完成/已跳过/已转交）。任务由医嘱生成，但也可由护理常规独立产生（如每 2 小时翻身）。

执行记录实体（execution_record）是任务的“事实凭证”，记录实际执行时间、执行人、实际剂量、执行结果、患者反应、双人核对签名、异常说明。任务与执行记录是一对多：一次任务可能因患者外出而延迟、补执行，产生多条记录。

二、实体关系与 E-R 建模

关系梳理如下：患者与床位为 1:N（一名患者在不同时间占用多张床位，同一时刻仅一张）；患者与医嘱为 1:N；医嘱与护理任务为 1:N（长期医嘱按频次生成多条任务）；患者与护理任务为 1:N；护理任务与执行记录为 1:N；护士与护理任务为 1:N（责任护士），与执行记录为 1:N（执行人）。下图给出核心 E-R 关系与关键字段。

三、数据库表结构设计

将 E-R 图落地为关系表时，需处理两个关键点：一是患者—床位的时间维度，建议单独建 patient_bed_history 表记录占用起止时间，而不是在患者表里放床号；二是医嘱与任务的裂变，长期医嘱按频次生成任务时，任务表需保留 order_id 与 plan_time，便于按时间窗查询和去重。

-- 患者表
CREATE TABLE patient (
  inpatient_no   VARCHAR(20) PRIMARY KEY,
  name           VARCHAR(30) NOT NULL,
  gender         CHAR(1),
  birth_date     DATE,
  allergy        VARCHAR(200),
  ward_id        VARCHAR(10),
  status         VARCHAR(10) DEFAULT '在院'
);

-- 床位表
CREATE TABLE bed (
  bed_id     VARCHAR(20) PRIMARY KEY,
  ward_id    VARCHAR(10) NOT NULL,
  room_no    VARCHAR(10),
  bed_no     VARCHAR(10),
  bed_type   VARCHAR(10),   -- 普通/监护/隔离
  status     VARCHAR(10)    -- 空闲/占用/清洁/停用
);

-- 患者床位占用历史（时间维度）
CREATE TABLE patient_bed_history (
  id           BIGINT PRIMARY KEY AUTO_INCREMENT,
  inpatient_no VARCHAR(20),
  bed_id       VARCHAR(20),
  start_time   DATETIME,
  end_time     DATETIME,
  FOREIGN KEY (inpatient_no) REFERENCES patient(inpatient_no),
  FOREIGN KEY (bed_id) REFERENCES bed(bed_id)
);

-- 医嘱表
CREATE TABLE medical_order (
  order_id     VARCHAR(24) PRIMARY KEY,
  inpatient_no VARCHAR(20) NOT NULL,
  order_type   VARCHAR(6),   -- 长期/临时
  item_name    VARCHAR(60),
  dose         VARCHAR(30),
  route        VARCHAR(20),
  freq         VARCHAR(20),  -- qd/bid/q8h/once
  start_time   DATETIME,
  stop_time    DATETIME,
  doctor_id    VARCHAR(20),
  order_status VARCHAR(10)
);

-- 护理任务表
CREATE TABLE nursing_task (
  task_id      VARCHAR(24) PRIMARY KEY,
  order_id     VARCHAR(24),
  inpatient_no VARCHAR(20) NOT NULL,
  bed_id       VARCHAR(20),
  task_type    VARCHAR(20),  -- 给药/输液/体征/翻身/标本
  plan_time    DATETIME NOT NULL,
  nurse_id     VARCHAR(20),
  priority     TINYINT DEFAULT 2,
  task_status  VARCHAR(10) DEFAULT '待接收',
  FOREIGN KEY (order_id) REFERENCES medical_order(order_id),
  FOREIGN KEY (inpatient_no) REFERENCES patient(inpatient_no)
);

-- 执行记录表
CREATE TABLE execution_record (
  record_id    BIGINT PRIMARY KEY AUTO_INCREMENT,
  task_id      VARCHAR(24) NOT NULL,
  exec_time    DATETIME,
  executor_id  VARCHAR(20),
  actual_dose  VARCHAR(30),
  result       VARCHAR(20),  -- 完成/跳过/异常
  reaction     VARCHAR(200),
  verify_nurse VARCHAR(20),
  FOREIGN KEY (task_id) REFERENCES nursing_task(task_id)
);

四、关键约束与索引设计

数据模型能否支撑协同，取决于约束是否到位。建议在 nursing_task 上建立 (nurse_id, plan_time, task_status) 联合索引，护士端“我的待办”查询可命中索引；在 (inpatient_no, plan_time) 上建索引，支持按患者查看当日任务。为防止同一医嘱同一计划时间重复生成任务，可对 (order_id, plan_time) 建唯一约束。

示例参数说明：某病区 40 张床、在院 36 人，长期医嘱平均每人 6 条、按 q8h 裂变，则每日任务量约为 36×6×3≈648 条，加上临时医嘱与护理常规任务，日任务量约 800 条。该数值为教学估算，用于评估索引与分页策略，非实测结果。

五、状态流转与数据一致性

任务状态是协同平台的中枢信号：待接收 → 已接收 → 执行中 → 已完成，异常分支为 已跳过 与 已转交。每次状态变更都应写入执行记录或状态日志，保证“谁在何时改了什么”可追溯。医嘱停止时，需级联将未执行的关联任务置为“已取消”，避免护士端出现无效待办。患者转床时，更新 patient_bed_history 的 end_time 并新增一条占用记录，任务表按新床位重新定位，历史任务仍保留原床位号，确保追溯不失真。

综上，五个实体各司其职：患者是对象，床位是空间，医嘱是来源，任务是调度单元，执行记录是事实凭证。E-R 图确定关系，表结构确定落地方式，约束与索引确定性能与一致性，三者共同构成护理任务协同平台可靠运行的数据底座。