📚 课程目录第4章医疗角色与权限建模

4. 医疗角色与权限建模

在医疗数据访问控制工程中，角色是连接“人”与“数据”的核心抽象。角色建模的质量，直接决定了后续策略引擎能否准确回答一个关键问题：谁，在什么条件下，可以对哪一条数据，执行什么操作。本节围绕六类典型医疗角色展开职责分析，并进一步讨论权限粒度设计、角色继承与互斥约束的实现方法。

一、六类角色的职责与数据边界

医疗场景中的角色并非简单的岗位名称，而是由职责范围、数据接触面、操作类型、合规约束四个维度共同定义的。以下逐一分析。

医生是诊疗数据的核心生产者与使用者。其职责包括书写病历、开具医嘱、下达检查检验申请、查阅患者历史诊疗记录。数据边界通常限定在“本人主管患者”或“本科室患者”范围内。关键操作包括：创建/修改病历、开立医嘱、查看检验检查结果、申请会诊。医生角色通常拥有较高的数据读取权限，但修改权限应受时间窗限制——例如病历在签署后进入只读状态，修改需通过“修订”机制留痕。

护士的职责聚焦于执行医嘱、记录护理文书、监测生命体征。其数据边界与医生有重叠但操作类型不同：护士可以执行医嘱（如记录给药时间、剂量），可以写入护理记录、体温单、出入量记录，但通常不能修改医生开具的医嘱内容。护士对患者基本信息的读取权限较宽，但对诊断、手术记录等敏感字段的读取可能受限。

技师（检验、影像、病理等）的职责是接收检查申请、执行检查、出具报告。其数据边界具有明显的“任务驱动”特征：技师只能访问与当前检查任务关联的患者信息，且通常只能写入检查结果和报告，不能浏览患者的完整病历。例如，检验技师可以查看检验申请单和患者基本信息，但不应访问病程记录。

管理员分为系统管理员与业务管理员。系统管理员负责账号、角色、权限的配置与审计，通常不应拥有患者临床数据的读取权限，以避免“运维人员窥探病历”的合规风险。业务管理员（如病案室、质控人员）则可以在授权范围内进行数据统计、病案首页管理、质量检查等操作。

患者是数据的“主体”而非“操作者”。患者有权查阅自己的诊疗记录、检验报告、费用清单，并可以授权他人访问。在权限模型中，患者角色通常具有“自我数据读取”和“授权管理”两类权限，但不能修改临床记录。患者授权是许多访问控制策略的重要触发条件。

科研人员的职责是使用脱敏或去标识化后的数据进行研究。其数据边界应严格限定在伦理审批和授权范围内的数据集，通常只能进行批量读取和统计分析，不能定位到具体患者。科研人员角色往往需要与“数据脱敏”“最小数据集”“伦理批件”等约束条件绑定。

二、权限粒度设计：从粗到细的四层模型

权限粒度决定了访问控制的精确程度。医疗数据访问控制中，建议采用四层粒度模型：

系统级：能否登录系统、访问哪个子系统（如HIS、LIS、PACS）。
模块级：能否进入病历模块、医嘱模块、检验模块。
数据级：能否访问某类数据对象，如“患者基本信息”“检验报告”“影像文件”。
字段级：能否读取或修改具体字段，如“身份证号”“HIV检测结果”“精神科诊断”。

字段级粒度是医疗场景中最敏感也最必要的。例如，护士可以读取患者姓名、床号、过敏史，但“HIV抗体检测结果”字段可能仅对感染科医生和患者本人开放。实现字段级控制时，通常需要在策略中引入属性条件，如科室、患者授权状态、数据敏感级别。

权限粒度不是越细越好。粒度过细会导致策略数量爆炸、维护困难。建议对高敏感字段单独建模，对一般字段按数据对象整体授权。

三、角色继承：减少重复授权的有效手段

角色继承允许一个角色自动获得另一个角色的权限。在医疗场景中，常见的继承关系包括：

主任医师继承医生：主任医师拥有医生的全部权限，并额外拥有审批、质控、教学查房等权限。
护士长继承护士：护士长拥有护士的全部权限，并额外拥有排班、护理质量检查、病区数据统计权限。
专科医生继承医生：如心内科医生继承基础医生权限，再叠加心内科专属的数据访问范围。

继承关系应遵循“权限只增不减”的原则，即子角色是父角色的超集。如果出现需要“减少”权限的情况，应通过互斥约束或显式拒绝策略处理，而不是通过继承实现。

四、互斥约束：防止权限冲突与合规风险

互斥约束用于限制同一用户不能同时拥有某些角色组合。医疗场景中典型的互斥关系包括：

医生与管理员互斥：临床医生不应同时拥有系统管理员的权限配置权，防止“自开权限、自改病历”。
科研人员与临床医生互斥：若同一人既是临床医生又是科研人员，其科研数据访问可能绕过脱敏流程，带来隐私泄露风险。
医嘱开立与医嘱执行互斥：同一人不应同时拥有开立医嘱和执行医嘱的权限，以形成“开立-执行”的制衡。

互斥约束的实现通常有两种方式：静态互斥（角色分配时即禁止）和动态互斥（同一会话中不能同时激活互斥角色）。静态互斥适合强合规场景，动态互斥适合需要临时切换角色的场景。

五、角色-权限-约束的建模示例

下面给出一个简化的角色权限配置示例，使用JSON结构表达角色、权限和约束。该示例为教学假设，实际部署需结合医院具体制度和合规要求调整。

{
  "roles": {
    "doctor": {
      "inherits": [],
      "permissions": [
        "patient:read:basic",
        "patient:read:history",
        "record:create",
        "record:update:unsigned",
        "order:create",
        "lab:read:result"
      ],
      "constraints": {
        "dataScope": "attending_patients",
        "timeWindow": "record_update_before_sign"
      }
    },
    "nurse": {
      "inherits": [],
      "permissions": [
        "patient:read:basic",
        "nursing:write",
        "order:execute",
        "vital:write"
      ],
      "constraints": {
        "dataScope": "assigned_ward",
        "deny": ["order:update", "record:update"]
      }
    },
    "lab_tech": {
      "inherits": [],
      "permissions": [
        "patient:read:basic",
        "lab:write:result",
        "lab:read:request"
      ],
      "constraints": {
        "dataScope": "assigned_tasks",
        "deny": ["record:read", "order:create"]
      }
    },
    "researcher": {
      "inherits": [],
      "permissions": [
        "dataset:read:deidentified",
        "stats:execute"
      ],
      "constraints": {
        "dataScope": "approved_protocol",
        "deny": ["patient:read:identified"]
      }
    }
  },
  "mutex": [
    ["doctor", "sys_admin"],
    ["researcher", "doctor"],
    ["order:create", "order:execute"]
  ]
}

该配置中，dataScope限定数据范围，deny显式拒绝越权操作，mutex定义互斥角色和互斥权限。策略引擎在鉴权时，先检查角色是否激活、是否违反互斥约束，再检查权限和数据范围，最后检查字段级敏感规则。

六、角色建模的落地检查要点

在实际工程中，角色建模完成后应进行以下检查：

每个角色的权限是否遵循“最小必要”原则，是否存在过度授权。
继承链是否清晰，是否存在循环继承或权限冲突。
互斥约束是否覆盖了“开立-执行”“临床-管理”“临床-科研”等关键制衡关系。
字段级敏感数据是否单独建模，是否与患者授权状态联动。
角色变更是否有审计日志，是否支持定期复核。

角色与权限建模不是一次性工作，而是随着医院组织架构、业务流程和合规要求不断演进的持续过程。良好的角色模型应当既能准确表达职责边界，又能灵活适应变化，同时保持可审计、可解释、可维护。