📚 课程目录第3章护理任务协同的角色与权限体系

3. 护理任务协同的角色与权限体系

病区护理任务协同平台的核心难点，不在于把任务列出来，而在于“谁能看、谁能改、谁能签、谁只能执行”。如果权限设计过粗，护士长会被大量无关提醒淹没，护理员可能看到不该看的医嘱信息，医生也可能误改护理执行记录。因此，本节围绕病区真实角色职责，说明如何用 RBAC（基于角色的访问控制）模型和最小权限原则，把权限落到具体任务、具体操作和具体数据范围上。

一、病区五类核心角色的职责边界

病区协同通常涉及五类角色，它们不是简单的上下级，而是围绕“医嘱—护理任务—执行—反馈”形成协作链。

护士长：负责病区护理任务的全局调度、人力分配、优先级调整、质量抽查和异常处置。她需要看到全病区任务总览、人员负荷、超时任务和不良事件，但通常不直接替责任护士完成床旁执行签名。
责任护士：是患者护理任务的第一责任人，负责接收医嘱派生任务、评估患者、制定护理措施、分配辅助任务、审核执行结果并完成护理记录。她对所管患者的数据有完整读写权，但跨病区或非分管患者只应拥有只读或不可见权限。
辅助护士：协助完成生命体征测量、标本送检、基础护理等任务。她可以查看被分配任务的患者基本信息与执行要求，执行后提交结果，但不能修改医嘱、不能删除任务、不能查看与任务无关的敏感诊疗信息。
医生：负责下达、修改、停止医嘱，查看护理执行反馈和异常上报。医生需要知道“医嘱是否被执行、何时执行、有无异常”，但不应直接修改护理执行记录，否则会破坏护理文书的原始性。
护理员：承担生活照护、转运协助、床单位整理等非侵入性任务。其权限应限制在任务清单、患者身份核对信息和完成状态回填，不应访问诊断、检验、用药等临床敏感数据。

这五类角色的权限差异，可以用“数据范围 × 操作类型”两个维度来理解。数据范围包括全病区、本责任组、本人任务、指定患者；操作类型包括查看、创建、编辑、执行、审核、删除、导出。RBAC 的基本做法是：先定义角色，再给角色分配权限，最后把用户绑定到角色。用户不直接拥有权限，权限通过角色间接获得，这样人员轮岗、请假替班时只需调整角色绑定，而不必逐条改权限。

二、RBAC 在病区中的落地结构

病区 RBAC 不是一张静态表，而是一个“用户—角色—权限—数据范围”的映射链。下面这张图展示了五类角色与任务对象、操作权限之间的关系，重点体现最小权限原则：每个角色只拿到完成其职责所必需的最小权限集合。

三、最小权限原则的具体落地方法

最小权限原则在病区落地，不能只停留在“少给点权限”的口号上，而要落到三个可操作层面。

第一，默认拒绝与显式授权。系统初始化时，任何新用户默认没有任何业务权限。护士长在排班模块中为护士绑定“责任护士”角色后，该护士才获得本责任组患者的任务读写权。如果某天她临时支援其他病区，应通过“临时授权”增加一个有效期，例如 8 小时，到期自动回收，而不是直接把她改成全病区权限。

第二，职责分离。医嘱的“开立—审核—执行—签名”四个动作不能由同一人闭环完成。医生开立医嘱后，责任护士接收并转化为护理任务，辅助护士执行后提交，责任护士审核签名。系统应在权限层禁止医生直接修改护理执行记录，也禁止辅助护士删除任务。这样即使出现差错，也能通过操作日志追溯到具体环节。

第三，数据范围最小化。同样是“查看患者”，不同角色看到的字段不同。护理员看到的是床号、姓名、任务内容、注意事项；责任护士看到的是完整护理评估、医嘱摘要、检验危急值提醒；医生看到的是医嘱、病程、护理反馈。实现上通常采用“角色—字段—数据行”三级过滤：先判断角色能否访问该模块，再判断能否访问该患者，最后判断能否看到该字段。

四、一个可参考的角色权限配置示例

下面给出一份病区 RBAC 配置片段，用 JSON 形式表达角色与权限的绑定关系。示例仅覆盖核心权限，实际系统还需加入科室、班次、有效期等约束。

{
  "roles": [
    {
      "roleId": "head_nurse",
      "name": "护士长",
      "permissions": [
        "task:view:ward", "task:assign", "task:audit",
        "staff:view:load", "report:export:ward"
      ],
      "dataScope": "ward"
    },
    {
      "roleId": "primary_nurse",
      "name": "责任护士",
      "permissions": [
        "task:view:group", "task:create", "task:edit",
        "task:execute", "task:audit", "patient:view:group"
      ],
      "dataScope": "care_group"
    },
    {
      "roleId": "assist_nurse",
      "name": "辅助护士",
      "permissions": [
        "task:view:assigned", "task:execute", "task:submit"
      ],
      "dataScope": "assigned_task"
    },
    {
      "roleId": "doctor",
      "name": "医生",
      "permissions": [
        "order:create", "order:modify", "order:stop",
        "task:view:feedback", "patient:view:attending"
      ],
      "dataScope": "attending_patient"
    },
    {
      "roleId": "nursing_aide",
      "name": "护理员",
      "permissions": [
        "task:view:assigned", "patient:verify", "task:complete"
      ],
      "dataScope": "assigned_task"
    }
  ]
}

配置完成后，需要做一次权限验证。验证方法不是只看界面按钮是否隐藏，而是用不同角色账号分别登录，尝试访问越权接口。例如用护理员账号调用“查看检验结果”接口，预期返回 403；用辅助护士账号尝试删除任务，预期返回 403；用责任护士账号查看非分管患者，预期只能看到脱敏信息或提示无权限。只有接口层和界面层同时拦截，RBAC 才算真正落地。

实践提示：病区排班变动频繁，建议把“角色绑定”与“排班表”联动。护士上班打卡后自动获得当班责任组权限，下班后自动回收。临时授权必须设置有效期和审批人，避免权限长期滞留。

常见误区：把“护士长”简单等同于“超级管理员”，给她开放所有数据修改权。实际上护士长应侧重调度与审核，不应直接修改护理执行记录。超级权限只应保留给系统管理员，且操作必须留痕。

总结来说，病区护理任务协同的权限体系，核心是让每个角色在正确的时间、对正确的患者、做正确的操作。RBAC 提供了角色与权限的解耦机制，最小权限原则则约束了权限的边界。两者结合，才能既保证协同效率，又守住患者数据安全与护理文书严肃性。