FHIR 访问数据模型和控制系统

数据模型概览

访问权限控制的数据模型由意见征求资源表示。它们定义了要应用的规则以及这些规则适用于哪些数据。

访问权限规则通过 FHIR 同意资源表达。FHIR 同意是一种 FHIR 资源，用于捕获医疗保健使用方的选择。它允许或拒绝一组参与者在一段时间内从指定环境中出于特定目的执行影响使用方的操作。例如，使用方可以是医疗保健患者、任何代表医疗保健患者执行操作的人员，或签署了同意协议的其他个人。

FHIR 同意中记录的操作可能很广泛，涉及的不仅仅是消费者的电子健康记录 (EHR) 数据，但出于 Cloud Healthcare API 中征求同意的目的，重点是与数据访问相关的操作，并且强制执行这些操作仅限于从 FHIR 存储区读取 FHIR 数据。

同意资源的状态指示同意的当前状态。虽然 FHIR 存储区可能包含不同状态的许多同意，但 Cloud Healthcare API 只能强制执行处于活跃状态的同意。其他任何状态的同意不会影响强制执行。如果同意是代表患者授予的，则同意将记录为执行者授予。

政策类型

Cloud Healthcare API 支持以下意见征求政策类型：

  • 患者同意：使用 Consent.patient（STU3、R4）与患者相关联，并绑定患者隔离区（STU3、R4）定义的尽可能多的数据。

  • 管理员政策：未与任何患者相关联，且必须具有扩展程序网址 https://g.co/fhir/medicalrecords/ConsentAdminPolicy。此政策类型可绑定到资源条件指定的存储区中的部分或所有资源。管理员政策用于为商店中的所有绑定资源设置默认政策。

  • 管理层级政策：一种管理政策，需要扩展程序网址 https://g.co/fhir/medicalrecords/CascadingPolicy 和管理政策扩展程序网址。您可以将此政策类型绑定到与资源条件匹配的资源舱。存在以下限制：

您可以在同一资源级别组合使用政策类型，以允许或拒绝对资源的访问。如果缺少患者的同意，管理员政策可以批准对资源的访问权限。

同意指令是在 FHIR 同意中编码的指令，用于允许或拒绝已获授权的实体（如受让人或访问者）的数据访问权限。单个 FHIR 同意可以对多条同意指令进行编码。每条指令都提供以下内容：

  • 违规处置类型：permit 或 deny 指令。

  • 操作：此指令涵盖的权限。仅支持 access 提供只读权限。

  • 访问者条件：一组特性，用于标识指令涵盖的 API 请求者。

  • 资源条件：一组特性，用于标识指令涵盖的资源。

访问者条件

Cloud Healthcare API 支持访问者的三个属性，以便在同意指令中使用，并匹配发出数据访问请求的访问者。作为 FHIR 服务器提供的访问确定的一部分，必须有区分大小写的完全匹配才能在访问者上强制执行指令。

这些属性的编码方式如下：

  • 操作者：表示识别访问者或访问者特征的个人、群组或访问角色。

  • 用途：表示使用数据的意图。

  • 环境：表示一个抽象标识符，用于描述访问者所处的环境或条件。

例如，访问者可以由以下属性表示：

  • 发件人：Practitioner/123

  • 用途：ETREAT 或出于紧急治疗目的的访问

  • 环境：Application/abc

在此示例中，这些属性表示在使用名为 abc 的软件应用执行紧急治疗时访问数据的医生。

provision.actor 和 provision.purpose 是 FHIR 标准的一部分，而 Environment 是 https://g.co/fhir/medicalrecords/Environment。请注意，此链接无法解析。

所有同意指令必须指定要实施的 actor，但不一定需要指定 purpose 或 environment。例如，如果未在同意指令中指定 environment，则指令会匹配其他同意指令尚未涵盖的任何 environment。

资源条件

Cloud Healthcare API 支持将以下元素作为同意资源的一部分：

  • 资源类型（STU3、R4）：表示同意政策绑定到的类型，例如 Encounter、Observation 或 Immunization。

  • 资源 ID（STU3、R4）：表示同意政策绑定到的 ID。

  • 数据源：表示资源的来源（由资源 meta.source 标识，仅在 R4 中可用）。

  • 数据标记：表示资源的自定义标签，如资源 meta.tag（STU3、R4）中所述。

  • 安全标签：表示安全标签，用于定义 meta.security 字段（STU3、R4）中标识的受影响资源。支持以下代码系统：

    • 机密性：分层值，从不受限制到最受限制依次为：U、L、M、N、R、V。如果用户同意使用安全标签 R，则该同意会应用于标签为 R 或更低级别的所有资源。如果用户拒绝了安全标签 R，则该拒绝会应用于敏感性至少与 R 相当的所有资源。

    • ActCode：与安全码完全匹配的字符串。

访问工作流

authorization_flow

此图展示了向启用了 FHIR 访问权限控制的存储区发出请求的端到端历程。在向启用了访问权限控制的 FHIR 存储区发出请求时，应用 (#3) 会使用具有意见征求范围的外部令牌（左）。

发出数据访问请求时，访问者在表示与任何 FHIR HTTP 请求相关的 actor、purpose 和 environment 属性的特定同意范围内执行操作。这些属性的值必须与同意中提供的值匹配（区分大小写），以影响强制执行的访问确定。

一个访问者可以有多个与做出访问决定相关的 actor 标识符。同样，特定同意上下文中可以有多个相关的 purposes 或 environments。因此，所有相关访问者属性应作为 FHIR HTTP 请求的一部分提供，以便正确地表示该访问者。

例如，给定数据请求的同意范围可能如下所示：

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

这代表称为从业者 444 的护士或医生，他/她是群组 999 的成员，该群组代表来自特定医院内某个部门的从业者。从业者可以提供常规治疗，但也可能会在这些操作中采取紧急治疗方法。从业者使用的是名为 abc 的软件应用。

在访问者数据请求中，同意范围作为请求同意范围提供。

请求同意范围

FHIR 请求使用 FHIR HTTP 请求标头接收访问者的同意范围。此同意范围包含一组 actor、purpose 和 environment 值，以反映访问者的当前身份、资格、使用意图，以及访问者在其中执行操作的环境限制条件。在任何时候，这些属性中都可能有多个属性表示访问者的同意范围。

同意范围条目的定义如下：

  • actor/{type}/{ID}：一个 actor 属性，其中会将资源 type 与 ID 一起提供。type 示例包括：

    • Practitioner
    • Group
    • Patient

    例如，如果格式为 projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID 的存储区调用该 API，则对 Practitioner/123 执行器的本地引用会解析为 projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123。

  • purp/v3/{value}：一个 purpose 属性，其中 value 是 FHIR 用途 (v3) 值集或其扩展的成员。value 示例包括：

    • TREAT
    • ETREAT
    • HRESCH

  • env/{type}/{value}：一个 environment 属性，其中 type 和 value 是没有预定义分类的自定义字符串。type 和 value 的示例包括：

    • App/my_app_1
    • Net/VPN

此外，FHIR HTTP 请求标头还可以接收特殊作用域，例如 btg 和 bypass，如下所定义：

  • btg：借助“紧急访问权限”（简称“BTG”），您（作为人为用户）可以在紧急情况下跳过意见征求检查。此功能应仅在紧急情况下使用，并且会接受审核后审核。因此，btg 至少需要一个 actor。
  • bypass：允许受信任的用户（例如管理员）或受信任的应用（例如机器学习训练流水线）在无需征求用户同意的情况下对 FHIR 存储区进行操作。因此，bypass 至少需要一个 actor 和一个 env。

访问权限强制执行和访问权限判定

在存在多项政策和意见征求的复杂医疗保健环境中，强制执行访问权限和确定访问权限是一项艰巨的任务。各种利益相关方对患者信息的使用和披露可能有不同的期望和要求。若要顺利应对这一复杂的环境，您必须清楚了解如何强制执行访问权限以及管理访问权限确定的底层逻辑。

医疗保健使用方（例如患者或管理员）可以在单个同意资源中包含多条同意指令。同意资源可能同时包含 permit 和 deny provision.type 指令。默认情况下，用户可能拥有任意数量的同意资源，但一次执行最多 200 个 active 同意资源。如需了解详情，请参阅限制。

所有同意指令都从给定用户的 active 同意资源中提取，以创建一组汇总的同意规则。

同意强制执行仅限于每个条款条目最多一个目的和一个环境。

以下规则介绍了患者意见征求、管理员政策和管理员级联政策的联合访问控制原则：

  • 默认情况下，如果没有匹配的指令，则会拒绝所有资源的访问权限。

  • 如果请求的资源不存在，则只有资源类型和资源 ID 可识别。所有其他资源条件和资源所有者均未知，则在列表顺序中应用以下规则：

    • 如果资源类型属于患者隔离区或病历隔离区：系统会拒绝访问。

    • 否则：

      • 如果有管理员政策拒绝了访问条件，则无论其他资源条件如何，系统都会拒绝访问。

      • 如果存在允许针对可识别资源条件（即资源类型和资源 ID）使用访问器条件的管理员政策，则会返回“找不到资源”错误。

      • 在所有其他情况下，访问权限都会被拒绝。

  • 管理政策是用于匹配商店中资源的默认政策。

  • 不属于任何患者的资源仅由管理员政策决定。

  • 患者隔离区（STU3、R4）或相遇隔离区（STU3、R4）中的资源需要每个患者或管理员政策或管理员级联政策至少包含一个允许同意指令，并且不得包含来自患者和管理员政策和管理员级联政策的拒绝同意指令。请求者访问的资源上指定的所有患者都需要满足此条件。

    • 某些资源可能支持多个患者参与者。例如，预约提供可能是患者的参与者列表。在此类资源上命名的所有患者都必须使用同意指令允许访问者访问，否则系统不会返回资源。如果某个资源具有相遇级联政策授予的权限，并且相遇通过 subject 字段（STU3、R4）引用了患者，则该资源被视为已获得患者的许可。

上述规则可用以下伪代码总结：

联合访问控制

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

FHIR 存储区会在每个资源级别检查同意权限。系统不会解析资源中的任何引用，也不会为征求用户意见的访问权限检查目的而进行级联。例如，假设由 Patient/f001 标识的患者允许从业者访问其整个 MedicationRequest 资源，但不允许访问 Patient/f001 资源本身（这属于患者隐私）。在这种情况下，从业者可以查看整个 MedicationRequest 资源，该资源包含引用 Patient/f001 资源的 subject 字段，但看不到 Patient/f001 资源的内容，例如，即使在使用 _include 执行 FHIR 搜索时也是如此。

冲突解决

各种 permit 和 deny 指令之间可能会发生冲突。如果两个冲突的指令与资源匹配，则使用“deny 优先于 permit”模型解决冲突。

仅包含 active 同意以强制同意。

资源访问权限强制执行逻辑

向 FHIR 存储区发出同意感知请求时，访问权限控制会按以下顺序执行：

  1. Cloud Healthcare API 会检查代理中配置的服务账号（或正文）的权限。 Google Cloud如果该服务账号具有在 FHIR 存储区中执行请求的 FHIR 方法的正确 IAM 权限，请求将继续。

  2. 如果在 FHIR 存储区配置中启用了同意强制执行功能，并且存在同意感知型 HTTP 标头，则 Cloud Healthcare API 会对患者隔离区资源强制执行同意访问政策。根据最近执行 ApplyConsents 和 ApplyAdminConsents 所捕获的同意指令，同意访问政策的强制执行基于请求中提供的同意范围。

向 FHIR 存储区发出同意感知请求时，以下规则适用：

  • 至少提供一个与同意操作相关的 actor 同意范围。

  • 提供与同意操作相关的任何其他 purpose 和 environment 范围。

  • 如果同意范围条目的数量超过支持的限制，则会返回错误。

  • 如果您调用的方法访问多个资源（例如 fhir.Patient-everything、fhir.Encounter-everything、fhir.executeBundle 或 fhir.search 方法），则同意强制执行适用于各个资源。不过，这些多资源访问方法之间存在细微差异：

    • 读取多个资源的 fhir.executeBundle 在没有同意权限的情况下会收到单个资源的“同意访问被拒绝或正在访问的资源不存在”错误（请参阅获取具有同意范围的 FHIR 资源中的示例）。

    • fhir.search 会跳过没有同意权限的资源，并且不会返回同意访问遭拒错误，即使通过 _id 搜索也是如此（请参阅搜索具有同意范围的 FHIR 资源中的示例）。

    • fhir.Patient-everything 和 fhir.Encounter-everything 的行为类似于 fhir.search，不同之处在于，如果调用方对请求的患者或患者就诊记录资源没有同意权限，它们会分别返回“同意访问被拒绝或正在访问的资源不存在”错误。

一条同意指令最多有一个 actor、最多一个 purpose 和最多一个 environment，而同意范围可以有多个。某些同意指令不会指定所有三个访问者属性，在这种情况下，任何同意范围属性值都可以匹配，具体取决于冲突解决规则。因此，同意范围可以匹配多条同意指令。

如果请求的同意范围包含同一同意范围类型（actor、purpose 或 environment）的两个或更多条目，则同意范围可能匹配多条同意指令。某些同意指令未指定 purpose 或 environment。因此，同意范围还必须与未指定这些范围类型的同意指令匹配。

例如，将同意范围设置为 actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc 与以下任意 permit 或 deny 同意指令匹配：

  • actor/Practitioner/123 purp/v3/TREAT env/App/abc
  • actor/Practitioner/123 purp/v3/TREAT
  • actor/Practitioner/123 env/App/abc
  • actor/Practitioner/123
  • actor/Group/999 purp/v3/TREAT env/App/abc
  • actor/Group/999 purp/v3/TREAT
  • actor/Group/999 env/App/abc
  • actor/Group/999

后续步骤