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 和管理員政策擴充功能網址。您可以將這類政策繫結至符合資源條件的資源區間。有下列限制：

您可以在相同資源層級合併政策類型，允許或拒絕存取資源。如果缺少病患同意聲明，管理員政策可以核准資源存取權。

同意聲明指令是 FHIR 同意聲明中編碼的指令，可允許或拒絕授權實體 (例如受讓人或存取者) 存取資料。單一 FHIR Consent 可能會編碼多個同意聲明指令。每個指令都會提供下列資訊：

  • 強制執行類型：permit 或 deny 指示。

  • 動作：這項指令涵蓋的權限。系統僅支援 access，提供唯讀存取權。

  • 存取者條件：一組屬性，用於識別指令涵蓋的 API 要求者。

  • 資源條件：一組屬性，用於識別指令涵蓋的資源。

存取者條件

Cloud Healthcare API 支援存取者的三項屬性，可用於同意聲明指令中，並與提出資料存取要求的存取者進行比對。必須完全相符 (區分大小寫)，才能在 FHIR 伺服器提供的存取權判斷中，對存取者強制執行指令。

這些屬性的編碼方式如下：

  • Actor：代表可識別存取者或存取者特徵的個人、群組或存取角色。

  • 目的：代表資料的使用意圖。

  • 環境：代表抽象 ID，用於說明存取子運作的環境或條件。

舉例來說，存取子可能由下列屬性表示：

  • 執行者：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 存取權控管的存放區提出要求的端對端歷程。應用程式 (#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 至少需要一個 actor。
  • bypass：允許受信任的使用者 (例如管理員) 或受信任的應用程式 (例如機器學習訓練管道) 在 FHIR 存放區中運作，不必取得同意授權。因此，bypass 至少需要一個 actor 和一個 env。

存取權強制執行和存取權決議

在多項政策和同意聲明並存的複雜醫療保健環境中，強制執行存取權和判斷存取權限可能是一項艱鉅的任務。對於病患資訊的使用和揭露方式，不同利害關係人可能有不同的期望和要求。如要在這個複雜的環境中順利運作，您必須清楚瞭解存取權的強制執行方式，以及決定存取權的基礎邏輯。

醫療保健消費者 (例如病患或管理員) 可能在單一同意聲明資源中有多個同意聲明指令。同意聲明資源可能包含 permit 和 deny provision.type 指令。根據預設，使用者可擁有任意數量的 Consent 資源，但一次最多可強制執行 200 個 active Consent 資源。詳情請參閱「限制和限制」一節。

系統會從特定使用者的「同意聲明」資源中擷取所有同意聲明指令，並據此制定一組匯總的同意聲明規則。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 欄位，但即使使用 _include 執行 FHIR 搜尋，也無法查看 Patient/f001 資源的內容。

解決衝突

各種 permit 和 deny 指令之間可能發生衝突。如果兩個衝突的指令與資源相符，系統會使用「deny 優先於 permit」模型解決衝突。

系統只會強制執行 active 同意聲明。

資源存取權強制執行邏輯

對 FHIR 儲存庫提出同意聲明感知要求時，存取控管會依下列順序執行：

  1. Cloud Healthcare API 會檢查在 Proxy 中設定的服務帳戶 (或主體) 權限。 Google Cloud如果服務帳戶具備適當的 IAM 權限，可在 FHIR 儲存庫上執行所要求的 FHIR 方法，系統就會繼續處理要求。

  2. 如果在 FHIR 儲存庫設定中啟用同意聲明強制執行功能，且存在同意聲明感知 HTTP 標頭，Cloud Healthcare API 就會對 Patient Compartment 資源強制執行同意聲明存取政策。系統會根據要求中提供的同意聲明範圍，以及最近一次執行 ApplyConsents 和 ApplyAdminConsents 時擷取的同意聲明指令，強制執行同意聲明存取權政策。

對 FHIR 存放區提出同意聲明相關要求時，須遵守下列規則：

  • 請至少提供一個與同意聲明動作相關的actor同意聲明範圍。

  • 提供與同意聲明動作相關的任何其他 purpose 和 environment 範圍。

  • 如果同意範圍項目的數量超過支援的上限，系統會傳回錯誤。

  • 如果您呼叫存取多個資源的方法 (例如 fhir.Patient-everything、fhir.Encounter-everything、fhir.executeBundle 或 fhir.search 方法)，系統會對每個資源個別強制執行同意聲明。不過，這些多資源存取方法之間有細微差異：

    • fhir.executeBundle 讀取多個資源時，如果沒有同意聲明權限，系統會針對個別資源顯示「Consent access denied or the resource being accessed does not exist」(拒絕同意聲明存取權，或存取的資源不存在) 訊息 (請參閱「取得同意聲明範圍的 FHIR 資源」中的範例)。

    • fhir.search 會略過沒有同意聲明權限的資源，且不會傳回同意聲明存取遭拒錯誤，即使是透過 _id 搜尋也一樣 (請參閱「使用同意聲明範圍搜尋 FHIR 資源」中的範例)。

    • fhir.Patient-everything 和 fhir.Encounter-everything 的行為與 fhir.search 類似，但如果呼叫端未分別取得所要求病患或就診資源的同意聲明權限，則會傳回「Consent access denied or the resource being accessed does not exist」。

同意指令最多只能有一個 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

後續步驟