FHIR アクセス データモデルと制御システム

データモデルの概要

アクセス制御のデータモデルは、同意リソースで情報が掲載されています。適用されるルールと、ルールが適用されるデータを定義します。

アクセスルールは FHIR 同意リソースで情報が掲載されています。FHIR 同意は、医療消費者の選択肢をキャプチャする FHIR リソースの一種です。これは、ある期間にわたって指定した環境から特定の目的のために、一連のアクターがコンシューマに影響を与えるアクションを実行することを許可または拒否します。たとえばコンシューマは、医療患者、医療患者の代理として行動するすべての人、または同意契約を締結した別の個人などです。

FHIR 同意に記録されたアクションは、消費者の電子健康記録（EHR）データだけでなく、幅広い領域に対応できます。ただし、Cloud Healthcare API 内での同意を目的とする場合は、データアクセスに関連するアクションが中心となり、現在、そうしたアクションの適用は、FHIR ストアからの FHIR データの読み取りに制限されています。

同意リソースには、同意の現在の状態を示すステータスが存在します。FHIR ストアにはさまざまな状態の同意が含まれている場合がありますが、Cloud Healthcare API はアクティブ状態の同意のみを適用します。その他の状態の同意は、適用には影響しません。患者に代わって同意した場合は、その同意はパフォーマーによって付与されたものとして記録されます。

ポリシータイプ

Cloud Healthcare API は、次の同意ポリシータイプをサポートしています。

  • 患者の同意: Consent.patient（STU3、R4）を介して患者に関連付けられ、患者コンパートメント（STU3、R4）で定義されている数のデータをバインドします。

  • 管理ポリシー: 患者には関連付けられておらず、拡張 URL https://g.co/fhir/medicalrecords/ConsentAdminPolicy が必要です。このポリシータイプは、リソースの条件で指定されたストアのサブセットまたはすべてのリソースにバインドできます。管理ポリシーは、ストア内のすべてのバインディング リソースにデフォルト ポリシーを設定します。

  • 管理カスケード ポリシー: 拡張機能 URL https://g.co/fhir/medicalrecords/CascadingPolicy と管理ポリシー拡張機能の URL を必要とする管理ポリシーのタイプ。このポリシータイプは、リソースの条件と一致するリソースのコンパートメントにバインドできます。以下の制限があります。

    • コンパートメントのベースとして、Patient（STU3、R4）または Encounter（STU3、R4）のみをサポートします。
    • ポリシーが適用される FHIR ストアでは、disableReferentialIntegrity を false に設定する必要があります。

同じリソースレベルでポリシータイプを組み合わせて、リソースへのアクセスを許可または拒否できます。患者の同意がない場合、管理ポリシーでリソースへのアクセスを承認できます。

同意ディレクティブは、利用者やアクセサーなどの承認済みエンティティへのデータアクセスを許可または拒否する FHIR 同意内でエンコードされた指示です。1 つの FHIR Consent に複数の同意ディレクティブをエンコードできます。各ディレクティブは次の内容を指定します。

  • 適用タイプ: permit または deny 指示。

  • アクション: このディレクティブの対象となる権限。読み取り専用アクセス権を付与するには、access のみサポートされています。

  • アクセサーの条件: ディレクティブの対象となる API リクエスト元を識別する一連の属性。

  • リソースの条件: ディレクティブの対象となるリソースを識別する一連の属性。

アクセサーの条件

Cloud Healthcare API は、同意ディレクティブ内で使用するためと、データアクセス リクエストを行うアクセサーと照合するために、アクセサーの 3 つのプロパティをサポートしています。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 field（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

これは、看護師または特定の病院内の部門のプラクティショナーを表すグループ 999 のメンバーであるプラクティショナー 444 と呼ばれる医師を表します。プラクティショナーは、日常的な処置をするだけでなく、こうした対応の一環として緊急時の処置を行うこともできます。プラクティショナーは、abc というソフトウェア アプリケーションを使用しています。

同意スコープは、アクセサーのデータ リクエストの一部として、リクエスト同意スコープとして提供されます。

同意スコープをリクエストする

FHIR リクエストは FHIR HTTP リクエスト ヘッダーを使用してアクセサーの同意スコープを受け取ります。この同意スコープには、アクセサーの現在の ID、利用資格、使用目的、アクセサーが動作する環境の制約を反映する一連の actor、purpose、environment の値が含まれます。一度に複数のアクセサーの同意スコープを表すプロパティが複数存在する場合もあります。

同意の同意範囲エントリは、次のように定義されます。

  • actor/{type}/{ID}: ID とともにリソース type が指定された actor プロパティ。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}: value が FHIR の使用目的（v3）値セットまたはその拡張のメンバーである purpose プロパティ。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 には少なくとも 1 つの actor が必要です。
  • bypass: 信頼できるユーザー（管理者など）または信頼できるアプリケーション（ML トレーニング パイプラインなど）が同意承認なしに FHIR ストアで操作できるようにします。したがって、bypass には少なくとも 1 つの actor と 1 つの env が必要です。

アクセスの適用とアクセス判定

複数のポリシーと同意が共存する複雑な医療環境では、アクセスの適用とアクセス権限の判断は困難な作業になる可能性があります。さまざまなステークホルダーは、患者情報の使用と開示に関して異なる期待と要件を持っている可能性があります。この複雑な環境を操作するには、アクセスがどのように適用されるかと、アクセス判定を統制する、基礎となるロジックを明確に理解する必要があります。

患者や管理者などの医療消費者は、単一の同意リソースに複数の同意ディレクティブを含めることができます。同意リソースには、permit と deny の provision.type ディレクティブを混在させることができます。デフォルトでは、ユーザーは同意リソースをいくつでも選択できますが、最大で 200 の active 同意リソースが一度に適用されます。詳細については、制約と制限をご覧ください。

同意ディレクティブはすべて、active 同意リソースから抽出され、一連の集約された同意ルールが作成されます。

同意の適用は現在、プロビジョニング エントリごとに最大 1 つの目的および最大 1 つの環境に制限されています。

次のルールは、患者の同意、管理ポリシー、管理カスケード ポリシーの共同アクセス制御の原則について説明しています。

  • 一致するディレクティブがない場合は、デフォルトですべてのリソースへのアクセスが拒否されます。

  • リクエストされたリソースが存在しない場合は、リソースタイプとリソース ID のみを識別できます。他のすべてのリソースの条件とリソース オーナーが不明の場合は、リストの順で以下のルールが適用されます。

    • リソースタイプが患者コンパートメントまたは受診コンパートメントに属している場合、アクセスは拒否されます。

    • それ以外の場合:

      • 他のリソースの条件に関係なく、アクセサーの条件を拒否する管理ポリシーがある場合、アクセスは拒否されます。

      • 識別可能なリソースの条件（リソースタイプとリソース ID）に対してアクセサーの条件を許可する管理ポリシーがある場合は、「リソースが見つかりません」エラーが返されます。

      • それ以外の場合、アクセスは拒否されます。

  • 管理ポリシーは、ストア内のリソースの照合に使用されるデフォルトのポリシーです。

  • 患者に属していないリソースは、管理ポリシーのみによって決定されます。

  • 患者コンパートメント（STU3、R4）またはエンカウンタ コンパートメント（STU3、R4）内のリソースは、患者または管理ポリシーまたは管理カスケード ポリシーごとに少なくとも 1 つの許可同意ディレクティブが必要であり、患者と管理ポリシーおよび管理カスケード ポリシーからの同意拒否ディレクティブは必要ありません。この条件は、リクエスト元がアクセスするリソースに名前が指定されているすべての患者に必要です。

    • 一部のリソースでは、複数患者の参加がサポートされます。たとえば、予約には、患者である可能性がある参加者のリストが準備されています。このようなリソースに指定されるすべての患者は、同意ディレクティブを介してアクセサーへのアクセスを許可する必要があります。そうしないと、リソースは返されません。リソースにエンカウンタ カスケード ポリシーの権限がある場合、このエンカウンタは 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 リソース自体にはアクセスできない場合を考えます。このシナリオでは、プラクティショナーは Patient/f001 リソースを参照する subject フィールドを含む MedicationRequest リソース全体を見ることができますが、_include を使用して FHIR 検索を行ったとしても Patient/f001 のリソースの内容を見ることはできません。

競合の解決

さまざまな permit ディレクティブと deny ディレクティブの間では、競合が発生する可能性があります。2 つの競合するディレクティブがリソースと一致する場合は、permit モデルを取り込む deny モデルを使用して競合が解決されます。

同意の適用には、active の同意のみが含まれます。

リソース アクセスの適用ロジック

FHIR ストアに対して同意に基づくリクエストを行うと、次の順序でアクセス制御が行われます。

  1. Cloud Healthcare API では、プロキシで構成された Google Cloud サービス アカウント（またはプリンシパル）の権限を確認します。FHIR ストアでリクエストされた FHIR メソッドを実行するための適切な IAM 権限がサービス アカウントに付与されている場合、リクエストは続行されます。

  2. FHIR ストア構成で同意の適用が有効で、同意に基づく HTTP ヘッダーが存在する場合、Cloud Healthcare API は患者コンパートメント リソースに対して同意アクセス ポリシーを適用します。同意アクセス ポリシーの適用は、ApplyConsents と ApplyAdminConsents の最新の実行によって取得された同意ディレクティブに従って、リクエストで指定された同意スコープに基づきます。

FHIR ストアへの同意に基づくリクエストを行う場合、次のルールが適用されます。

  • 行われた同意アクションに関連する actor 同意スコープを少なくとも 1 つ指定します。

  • 行われた同意アクションに関連する purpose スコープと environment スコープを追加します。

  • 同意スコープのエントリ数がサポートされている上限を超えると、エラーが返されます。

  • 複数のリソースにアクセスするメソッド（例: fhir.Patient-everything、fhir.executeBundle、fhir.search）を呼び出す場合、それぞれ個別のリソースに同意の適用が行われます。ただし、これらのマルチリソース アクセス方法には若干の違いがあります。

    • 複数のリソースを読み取る fhir.executeBundle は、同意権限のない個々のリソースの「同意アクセスが拒否されているか、アクセスされているリソースが存在しません」を受け取ります（同意スコープを持つ FHIR リソースを取得する例をご覧ください）。

    • fhir.search は、_id で検索しても、同意権限のないリソースをスキップし、同意アクセス拒否エラーを返しません（同意スコープを使用して FHIR リソースを検索するの例を参照）。

    • fhir.Patient-everything は fhir.search と同じように動作しますが、呼び出し元がリクエストした患者リソースに対する同意権限を持っていない場合は「同意アクセスが拒否されているか、アクセスされているリソースが存在しません」を返します。

同意ディレクティブには最大 1 つの actor、最大 1 つの purpose、最大 1 つの environment を設定できますが、同意スコープにはそれぞれの要素を複数設定できます。一部の同意ディレクティブは、3 つのアクセサー プロパティをすべて指定しているわけではありません。その場合、競合の解決のルールによっては、同意スコープのプロパティ値が一致する場合があります。その結果、同意スコープは複数の同意ディレクティブと一致する場合があります。

リクエストの同意スコープに同じ同意スコープタイプ（actor、purpose、environment）のエントリが 2 つ以上含まれている場合、同意スコープが複数の同意ディレクティブと一致する可能性があります。一部の同意ディレクティブは、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

次のステップ