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 指令。

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

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

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

访问者条件

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

这些属性的编码如下所示：

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

  • 目的：表示数据的用途。

  • 环境：表示抽象标识符，用于描述访问者执行操作的环境或条件。

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

  • 发件人：Practitioner/123

  • 用途：ETREAT，或用于紧急治疗

  • 环境：Application/abc

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

provision.actor 和 provision.purpose 定义为 FHIR 标准的一部分，而环境为 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）中的资源需要为每个患者或每个管理员政策或管理员级联政策至少提供一个许可指令，并且没有来自患者和管理政策和管理员级联政策的拒绝同意指令。请求者要访问的资源上指定的所有患者都需要该疾病。

    • 部分资源可能支持多位患者参与者。例如，Appointment 提供了一份参与者列表，这些参与者可能是患者。在此类资源上命名的所有患者都必须允许使用意见征求指令访问访问器，否则系统不会返回相应资源。

所述规则可通过以下公式进行汇总。

联合访问权限控制

if resource does not exist
  if resource is a patient-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:
    return "permit"
  else:
    return "deny"
end

FHIR 存储区会在资源级层（而不是引用级层）检查同意权限。例如，由 Patient/f001 标识的患者允许从业者访问其整个 MedicationRequest 资源，但不允许访问 Patient/f001 资源本身（这属于患者隐私）。在这种情况下，同意的从业者可以查看整个 MedicationRequest 资源，该资源包含引用 Patient/f001 资源的 subject 字段，但看不到 Patient/f001 资源的内容，即使在搜索中使用 _include 也是如此。

冲突解决

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

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

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

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

  1. Cloud Healthcare API 会检查 Google Cloud 上的权限

    代理内配置的服务帐号如果该服务账号在 FHIR 存储区中具有正确的 IAM 权限，请求将继续。

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

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

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

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

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

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

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

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

    • fhir.Patient-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

后续步骤