1. 医疗数据访问控制工程导论

医疗数据访问控制工程，研究的不是“要不要给权限”，而是“在什么条件下、由谁、对哪一份数据、以什么目的、在什么时间窗口内、可以执行什么操作，并且整个过程如何被证明合规”。它把临床业务、数据治理、身份安全、审计合规和软件工程放在同一条链路上，目标是在保障诊疗效率的同时，把数据暴露面压到最小。

课程目标

本课程围绕一条主线展开：从医疗数据的特殊性出发，建立可落地的访问控制模型，再把它工程化为可配置、可审计、可演进的系统能力。学完后应能完成以下任务：

• 识别一份医疗数据资产的敏感级别、所属主体与合规约束；
• 为典型场景选择合适的访问控制模型（RBAC、ABAC、ReBAC 或组合）；
• 把策略写成可执行的判定规则，并说明其输入、优先级与冲突处理；
• 设计最小必要的审计记录，使“谁在何时访问了什么”可回溯；
• 在排障时区分“策略拒绝”“身份失效”“数据脱敏”三类不同结果。

医疗数据的四个关键特性

医疗数据与一般业务数据最大的差别，在于它同时具备高敏感、长生命周期、多主体关联和强合规四重属性。

• 高敏感与不可逆性：基因、精神科、传染病、生殖健康等数据一旦泄露，无法像密码那样“重置”。因此访问控制必须默认拒绝，而不是默认允许。
• 长生命周期：一份病历可能被保存数十年，跨越多个系统、多个版本和多次授权变更。权限不能只按“当前角色”判断，还要考虑历史授权与法定留存要求。
• 多主体关联：同一份数据同时关联患者、主治医生、会诊医生、护士、检验技师、医保审核员和科研人员，不同主体对同一字段的可见范围完全不同。
• 强合规约束：《个人信息保护法》《数据安全法》、医疗健康数据分级分类要求以及医院内部制度，共同构成策略的外部边界。

访问控制工程的定义与范畴

访问控制工程是把“授权意图”转化为“系统可执行判定”的工程活动，其范畴可拆为五层：

1. 主体与身份层：医生、护士、患者、第三方系统、科研账号，以及它们的凭证、证书与多因素认证状态。
2. 资源与分类层：病历、影像、检验、处方、随访记录，按敏感级别和业务域打标。
3. 策略层：用 RBAC 表达岗位职责，用 ABAC 表达“仅当患者属于本人诊疗范围且处于值班时段”，用 ReBAC 表达“会诊关系”这类图关系。
4. 执行层：策略决策点（PDP）与策略执行点（PEP），在 API 网关、数据库代理或应用服务中拦截请求。
5. 审计与治理层：记录访问日志、授权变更、异常告警，并支持合规审计与事后追责。

典型应用场景

以下场景贯穿本课程后续章节，也是策略设计的主要输入：

• 临床诊疗：主治医生可读写本人患者的完整病历；跨科会诊医生在会诊期内可读，但不可导出。
• 护理执行：病区护士可读本区患者医嘱与生命体征，但不可查看精神科既往史。
• 检验检查：技师可读申请单与样本信息，不可读患者完整诊断。
• 患者自助：患者可读本人报告，可授权家属临时查看，授权到期自动失效。
• 科研与统计：科研人员只能访问去标识化数据集，且需通过伦理审批与用途绑定。
• 医保与监管：审核员按案件号访问最小必要字段，访问行为全程留痕。

核心挑战

医疗访问控制的难点不在“写一条规则”，而在规则数量、时效性和可解释性同时增长。主要挑战包括：

• 紧急授权（Break-the-Glass）：抢救场景需要临时越权，但必须事后复核并告警。
• 权限蔓延：医生轮岗、离职、转科后旧权限未回收，形成隐性暴露面。
• 策略冲突：“允许会诊读取”与“禁止跨科导出”同时命中时，需要明确的优先级与拒绝优先原则。
• 性能与体验：字段级判定若每次访问都查多张表，会拖慢临床系统，需要缓存与预计算。
• 可解释性：当访问被拒绝时，必须能说明是哪条策略、哪个条件导致，否则无法排障与申诉。

从概念到工程：一个最小判定示例

假设会诊医生张医生请求读取患者 P-1024 的精神科既往史。策略可写成如下伪规则，用于说明“输入—判定—输出”的工程化表达：

输入：
  subject = {role: "会诊医生", dept: "心内科", on_duty: true}
  resource = {patient_id: "P-1024", type: "精神科既往史", sensitivity: "高"}
  context  = {purpose: "会诊", consult_relation: true, consult_expire: "2025-06-30"}

策略判定（拒绝优先）：
  1. 若 resource.sensitivity == "高" 且 purpose != "会诊" → 拒绝
  2. 若 consult_relation == false 或 当前时间 > consult_expire → 拒绝
  3. 若 subject.role == "会诊医生" 且 on_duty == true → 允许读取，但禁止导出
  4. 其余情况 → 默认拒绝

输出：
  decision = "允许读取（字段级：诊断结论可见，原始病程记录脱敏）"
  audit    = 记录 subject、resource、purpose、decision、policy_id

这个例子体现了三个工程要点：第一，判定输入不只是角色，还包括关系、目的和时间；第二，拒绝优先保证高敏感数据不会被宽松规则误放行；第三，输出不仅是“允许/拒绝”，还可以是“降级为脱敏视图”，并必须写入审计。

本章建立了后续所有章节的共同语言：主体、资源、策略、执行、审计五层结构，以及默认拒绝、最小必要、拒绝优先、全程留痕四条基本约束。后续内容将逐层展开，把这些约束转化为可配置、可测试、可审计的具体工程实现。