此页面由 Cloud Translation API 翻译。

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

本页面介绍了如何使用 Cloud Healthcare API FHIR 访问权限控制系统来管理和保护您的医疗保健数据。您可以使用 FHIR 访问权限控制来定义意见征求政策，根据用户角色和情境控制数据访问权限，并在 FHIR 存储区中强制执行这些政策。

数据模型概览

访问权限控制的数据模型由同意资源表示。它们定义了适用的规则以及规则适用的数据。

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

FHIR Consent 中记录的操作可能范围广泛，不仅涉及消费者的电子健康记录 (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 和管理员政策扩展程序网址。您可以将此政策类型绑定到符合资源条件的资源区间。具有以下限制：
- 仅支持将患者（STU3、R4）或就诊（STU3、R4）作为隔间库。
- 强制执行相应政策的 FHIR 存储区必须将 disableReferentialIntegrity 设置为 false。请与 Cloud 支持团队联系，以便将此功能用于非参照完整性 FHIR 存储区。

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

同意指令是在 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 访问权限控制的存储区发出请求的端到端流程。当应用 (#3) 向启用了访问权限控制的 FHIR 存储区（右侧）发出请求时，会使用具有同意范围（左侧）的外部令牌。

发出数据访问请求时，访问者在表示与任何 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 资源的内容，即使在执行 FHIR 搜索时使用 _include 也是如此。

冲突解决

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

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

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

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

Cloud Healthcare API 会检查代理中配置的 Google Cloud服务账号（或主账号）的权限。如果该服务账号具有正确的 IAM 权限，可以在 FHIR 存储区中执行所请求的 FHIR 方法，则请求将继续。
如果在 FHIR 存储区配置中启用了同意强制执行功能，并且存在同意感知型 HTTP 标头，则 Cloud Healthcare API 会对患者隔离区资源强制执行同意访问政策。根据最近执行 ApplyConsents 和 ApplyAdminConsents 所捕获的同意指令，同意访问政策的强制执行基于请求中提供的同意范围。

注意：如果 FHIR 存储区配置将同意标头处理定义为 REQUIRED_ON_READ，即使没有同意感知标头，也会强制执行（并拒绝）同意访问权限控制。

向 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

后续步骤

了解如何对 FHIR 存储区强制执行访问权限。