Cloud Healthcare API による医療画像の匿名化

はじめに

このドキュメントでは、研究者、データ サイエンティスト、IT チーム、医療組織、ライフサイエンス組織が Cloud Healthcare API を使用して、Digital Imaging and Communications in Medicine（DICOM）データから個人を特定できる情報（PII）と保護対象保健情報（PHI）を取り除く方法について説明します。匿名化と呼ばれるこのプロセスにより、患者のプライバシーを確保でき、また、DICOM データを研究、データ共有、機械学習に使用するための準備ができます。

付属チュートリアルの Cloud Healthcare API を使用した医療画像の匿名化では、Cloud Healthcare API を使用した医療画像データの匿名化の 2 つのユースケースについて説明します。

DICOM データの匿名化の仕組み

臨床用に取得された医療画像には、研究プロジェクトや教育目的の画像ライブラリなど、重要な二次的用途があります。ただし、承認済みの共同作業者と DICOM 画像を分析または共有する前に、DICOM 画像のセンシティブ データ要素（PII または PHI）を削除または修正する必要があります。

次の図は、オンプレミス ソースから Google Cloud にルーティングされ、Cloud Healthcare API 匿名化オペレーションによって匿名化された医療画像のパイプラインを示しています。

DICOM 匿名化パイプライン。

まず、DICOM 形式の医療画像を Cloud Storage にアップロードし、続いて Cloud Healthcare API にアップロードします。あるいは、DICOM 画像を Cloud Healthcare API に直接アップロードすることもできます。医療画像は、Cloud Healthcare API の DICOM ストアに格納され、Cloud Healthcare API 匿名化プロセスによって画像と関連するメタデータが匿名化されます。

たとえば、ある医学研究者が、オンプレミスの医用画像保管電送システム（PACS）にある脊髄骨折患者の X 線画像にアクセスできる状態であるとします。この画像ピクセルデータは、Storage Transfer Service、Transfer Appliance、またはいずれかのハイブリッド接続プロダクトを使用して、Cloud Storage に移動できます。その後、このデータを Cloud Storage から Cloud Healthcare API にコピー、または移動できます。Cloud Healthcare API にデータを取り込めば、バックアップとしての使用、リモートでの表示、承認済みサードパーティのクラウド サービスやアプリからのアクセスができるようになります。

別のシナリオとして、匿名化された DICOM 画像を AutoML Vision に送信して、医療チームが X 線画像で骨折を判断する際の補助として使えるモデルをトレーニングすることもできます。このように、独自のデータを使用して臨床診断の意思決定支援ツールを構築できます。

Cloud Healthcare API

Cloud Healthcare API は、Google Cloud での医療データ保存およびアクセスのマネージド ソリューションを提供し、既存の医療システムと Google Cloud でホストされるアプリケーションを結び付けます。

Cloud Healthcare API を介して取り込まれたデータは、Google Cloud プロジェクト内で Google Cloud リージョンに対応する地理的な場所にあるデータセットに保存されます。Cloud Healthcare API でサポートされるリージョンは、リージョンに一覧表示されています。Google Cloud プロダクトと Google Cloud プロダクトが実装されるリージョンのリストについては、クラウドのロケーションをご覧ください。

医療データのモダリティは、たとえば DICOM、Fast Healthcare Interoperability Resources（FHIR）、HL7v2 のように、それぞれの構造と処理の特性が異なるため、データセットはモダリティごとに分けられたストアに分割されて取り込まれます。

次の図では、Cloud Healthcare API がどのように場所、データセット、ストアごとに医療データを整理するかを示しています。

Cloud Healthcare API による医療データの整理。

各データセットには、アプリごとに必要に応じて同じモダリティまたは異なるモダリティに対応する 1 つ以上のストアが含まれます。アプリが異なるデータタイプを処理するのであれば、同じデータセットで複数のストアを使用することが適切な場合もあります。たとえば、データ提供元の病院、クリニック、部門に応じてデータを分割したりできます。アプリケーションは、パフォーマンスを損なうことなく、要件に応じた数のデータセットやストアにアクセスできます。コンピューティング リソースやエンドユーザーとの近接性、パーティショニング、アクセス制御など、組織の幅広い目標を満たすように、データセットとストアの全体的なアーキテクチャを設計することが重要です。

次の図では、HL7v2、DICOM、FHIR のストアを含む 2 つのデータセットを示します。

HL7v2 ストアと DICOM ストアでのデータセットのアーキテクチャ。

さまざまなソースの DICOM 画像をデータセット内の DICOM ストアにコピーできます。詳細については、DICOM ストアの作成と管理をご覧ください。

DICOM データの匿名化

Cloud Healthcare API には、指定した構成に基づいてテキストや画像の機密性の高いコンテンツをスケーラブルに秘匿化（削除）または変更できる匿名化ツールが含まれています。

これらのツールは、DICOM や FHIR など、特定の医療記録形式でエンコードされたテキストと画像に対して動作します。DICOM インスタンスを操作する際に使用する匿名化 API 呼び出しのコンポーネントは、次のとおりです。

  • ソース: センシティブ データを持つ 1 つ以上の DICOM インスタンスを含むデータセットまたは DICOM ストア。付属のチュートリアルではデータセットを使用していますが、単一の DICOM ストアで動作するようにサンプルを変更することもできます。
  • 匿名化の対象: データセットの処理方法を指定する構成パラメータ。タグキーワードを使用するか、DICOM 画像内の焼き付きテキストを不明瞭にして、またはその両方を実施して、DICOM インスタンスのメタデータを匿名化するように DICOM 匿名化オペレーションを構成できます。
  • 宛先: 匿名化は元のデータセットやそのデータに影響しません。代わりに、処理された元のデータのコピーが新しいデータセットまたは DICOM ストア（宛先）に書き込まれます。付属のチュートリアルではデータセットを使用していますが、単一の DICOM ストアで動作するようにサンプルを変更することもできます。

次の 2 つの画像は、匿名化の前後のサンプル X 線画像です。ここでの匿名化の目的は、画像に関連するすべてのメタデータと焼き付きテキストを削除、または変更することです。

最初の X 線画像では、サンプルの PII データと PHI データがメタデータと焼き付きテキストの両方に表示されています。

匿名化前のサンプル X 線画像（サンプルデータを含む）。

2 つ目の画像では、同じ X 線画像の PII メタデータと PHI メタデータのサンプルがすべて削除または不明瞭化されています。

匿名化後のサンプル X 線画像（サンプルデータを含む）。

匿名化後は、すべての画像メタデータが削除され、画像に焼き付けられたすべてのテキストが不透明な長方形で覆い隠されます。このような匿名化の構成は、より詳細な分析、機械学習（ML）モデルのトレーニング、推論において、画像ピクセルデータのみが必要となる場合に有効です。

たとえば、画像分類モデルをトレーニングして、X 線画像に骨折箇所があるかどうかを判断できます。このモデルをトレーニングするには、骨折した骨とそうでない骨を含む多数の画像サンプルが必要です。ただし、患者の性別、年齢、生年月日などの機密情報はモデルに関係しないため、必要ありません。

また、患者集団内での患者の年齢に応じて、特定の病気の進行を分析することもできます。この場合、患者の年齢や性別、各研究の日付などの情報は臨床分析に関連するため、必要となります。メタデータの一部を保持しつつ、患者の名前やカルテ番号などの個人情報を削除するということも可能です。

相対的な時系列を崩さず、すべての日付を変更することがベスト プラクティスですが、変更された日付と患者と一致させることはまず不可能です。詳細については、日付シフトをご覧ください。

必要なアクセス権と Identity and Access Management のロール

Google Cloud では、リソースへのアクセスは Identity and Access Management（IAM）のロールによって管理されます。Cloud Healthcare API にアクセスするには、実行する機能に適したロールが（IAM）アカウントに割り当てられている必要があります。

ユーザー アカウント（Google Cloud コンソールへのアクセスに使用するもの）と IAM サービス アカウントのいずれかを使用できます。付属のチュートリアルでは、ユーザー アカウントを使用する必要がある医療画像の表示を除いて、サービス アカウントを使用します。ここで紹介する一般的な情報は、すべてのアカウント タイプに適用されます。

宛先データセットを作成するには、少なくともソース データセットに対する healthcare.datasets.deidentify 権限と、Google Cloud プロジェクトに対する healthcare.datasets.create 権限が必要となります。Healthcare Dataset Administrator IAM のロールには、これらの権限がすべて含まれています。

データセットと DICOM ストアへのアクセスを制御する方法については、Cloud Healthcare API リソースへのアクセスの制御をご覧ください。データセット メソッドに必要な権限については、アクセス制御または Cloud Healthcare API をご覧ください。

医療画像ビューア

次の DICOM ビューアは Cloud Healthcare API と統合されており、このビューアを使用して匿名化前後の画像を表示できます。

ビューアを正常に機能させるためには、ログイン認証情報に healthcare.dicomViewer ロールが必要です。

API の構造

各ストアを Google Cloud プロジェクト、ロケーション、データセット、ストアタイプ、ストア名で識別する REST API を使用して、Cloud Healthcare API データセットとストアにあるデータへのアクセスおよび管理ができます。Cloud Healthcare API はモダリティ固有のアクセス基準も実装しており、これらの基準は、各モダリティの業界基準に準拠しています。たとえば、Cloud Healthcare API は、DICOMweb 規格に準拠している DICOM のスタディとシリーズを読み取るオペレーションをネイティブに提供します。

モダリティ固有のストアにアクセスするオペレーションでは、ベースパスとモダリティ固有のリクエストパスから構成されるリクエストパスを使用します。管理オペレーション（通常はロケーション、データセット、データストアに対してのみ実行されます）では、ベースパスのみを使用します。

Cloud Healthcare API データセット内の特定のストアを参照するには、次のような構造のベースパスを使用します。

 /projects/project/locations/location/datasets/dataset/store-type/store-name

次のように置き換えます。

  • project: Google Cloud プロジェクト
  • location: リソースが配置されているゾーン
  • dataset: データセットの名前
  • store-type: データストアのタイプ
  • store-name: データストアの名前

ベースパスの例を次に示します。

/projects/MyProj/locations/us-central1/datasets/dataset1/dicomStores/dicomstore1

上記のパスの例では、dataset1 というデータセットの US-central リージョン内にある Google Cloud プロジェクト MyProj の Cloud Healthcare API DICOM ストアを参照しています。ストアの名前は dicomstore1 です。

データの一部にアクセスするには、ベースパスを適切なモダリティ規格に従って書式設定されたリクエストパスと組み合わせます。たとえば、DICOM ストアへの DICOMweb リクエストは次のようになります。

 base-path/dicomWeb/studies/{study_id}/series?PatientName={patient_name}

パスの base-path 部分は、このリクエストに固有のベースパスを表します。パスの {study_id} 部分は、特定の DICOM スタディを識別し、患者の名前は {patient_name} で指定されます。上記の例では、パス指定は DICOMweb 規格のパス構造に準拠しています。

タグと画像秘匿化構成を使用した匿名化

DICOM データの匿名化には、次の 2 つのプロセスがあります。

  • DICOM メタデータの匿名化
  • 画像内の焼き付きテキストの秘匿化

Cloud Healthcare API では、DICOM タグに基づいてメタデータの匿名化を行い、焼き付きテキストの秘匿化は TextRedactionMode オプションによって実行します。

匿名化のためのタグとプロファイルの使用

DICOM メタデータのタグキーワードに基づいて、DICOM インスタンスを匿名化できます。DicomConfig オブジェクトでは、次のタグ フィルタリング メソッドを使用できます。

  • keepList: 保持するタグのリスト。他のすべてのタグは削除されます。
  • removeList: 削除するタグのリスト。他のすべてのタグは保持されます。
  • TagFilterProfile: 保持または削除するタグを指定するタグ フィルタリング プロファイル。

DICOM 最小属性タグ

次のタグは、Cloud Healthcare API 内の有効な DICOM インスタンスの最小属性です。

  • StudyInstanceUID
  • SeriesInstanceUID
  • SOPInstanceUID
  • TransferSyntaxUID
  • MediaStorageSOPInstanceUID
  • MediaStorageSOPClassUID
  • PixelData
  • Rows
  • Columns
  • SamplesPerPixel
  • BitsAllocated
  • BitsStored
  • Highbit
  • PhotometricInterpretation
  • PixelRepresentation
  • NumberOfFrames

keepList

keepList タグ フィルタリング メソッドを使用するには、タグ名のリストを指定する必要があります。匿名化後のリソースでは、これらのタグのみが保持されます。DicomConfig オブジェクトに keeplist タグを指定すると、DICOM の最小属性タグがデフォルトで追加されます。

keeplist タグを指定しない場合、データセット内の DICOM タグは削除されません。一般に、タグが保持される場合、元と比べると出力に変化が生じていないように見えますが、StudyInstanceUID、SeriesInstanceUID、SOPInstanceUID、MediaStorageSOPInstanceUID タグは新しく一意な値で再生成されています。

removeList

DicomConfig オブジェクトに removeList タグを指定できます。匿名化オペレーションでは、リストで指定されたタグのみが削除されます。removeList タグを指定しない場合、匿名化オペレーションは通常どおりに行われますが、宛先データセット内の DICOM タグは秘匿化されません。

DICOM 最小属性タグは、removeList に追加できません。

TagFilterProfile

保持または削除するタグを指定する代わりに、TagFilterProfile プロファイルを使用できます。この事前定義プロファイルでは、タグの処理方法や変更方法を決定します。たとえば、MINIMAL_KEEP_LIST_PROFILE プロファイルでは、有効な DICOM リソースの生成に必要なタグのみを保持し、その他のタグはすべて削除されます。詳細については、TagFilterProfile ドキュメントをご覧ください。

事前に選択されており、すべての DICOM タグとそのコンテンツを確認して理解する必要がないため、特に技術者以外のユーザーには、タグ フィルタリング メソッドとして TagFilterProfile プロファイルの使用をおすすめします。

よく使用されるプロファイル

業界では一般的な匿名化ユースケースの 1 つとして、プロファイル ATTRIBUTE_CONFIDENTIALITY_BASIC_PROFILE を使用することで DICOM 規格の属性の機密性プロファイルに基づいてタグを削除するものがあります。

よく使用される別のプロファイルは DEIDENTIFY_TAG_CONTENTS です。このプロファイルは、タグコンテンツ内のメタデータを検査し、機密テキストを置き換えます。DEIDENTIFY_TAG_CONTENTS プロファイルを使用する場合は、情報タイプやプリミティブ変換などの構成も適用できます。情報タイプとプリミティブ変換は、他のプロファイルには適用できません。

情報タイプを使用して、タグを使用して匿名化するときにスキャンするデータを定義できます。情報タイプとは、患者名、メールアドレス、電話番号、識別番号、クレジット カード番号などのセンシティブ データのタイプです。詳細については、InfoTypes と infoType 検出器をご覧ください。

プリミティブ変換は、入力値の変換に使用するルールです。各タグの情報タイプにプリミティブ変換を適用することで、DICOM タグをどのように匿名化するかをカスタムできます。たとえば、患者の姓を匿名化して、アスタリスクの羅列に置き換えることができます。プリミティブ変換の詳細については、プリミティブ変換オプションをご覧ください。

付属のチュートリアルでは、MINIMAL_KEEP_LIST_PROFILE プロファイルのユースケースを示します。

デフォルトの情報タイプ

デフォルトでは、DEIDENTIFY_TAG_CONTENTS プロファイルは次の情報タイプを処理します。

  • AGE
  • CREDIT_CARD_NUMBER
  • DATE
  • EMAIL_ADDRESS
  • IP_ADDRESS
  • LOCATION
  • MAC_ADDRESS
  • PERSON_NAME
  • PHONE_NUMBER
  • SWIFT_CODE
  • US_DRIVERS_LICENSE_NUMBER
  • US_PASSPORT
  • US_SOCIAL_SECURITY_NUMBER
  • US_VEHICLE_IDENTIFICATION_NUMBER
  • US_INDIVIDUAL_TAXPAYER_IDENTIFICATION_NUMBER

変更が必要な情報タイプが上記リストにすべて含まれている場合は、パラメータを追加することなく DEIDENTIFY_TAG_CONTENTS プロファイルを使用できます。

画像の焼き付きテキストの秘匿化

Cloud Healthcare API では、焼き付けられた機密テキストを画像内で秘匿化できます。PII や PHI などの機密データは Cloud Healthcare API によって検出され、不透明な長方形で覆い隠されます。Cloud Healthcare API では、入力と同じ DICOM 画像が返されますが、設定した条件に応じて機密情報を含むと判断されたテキストは秘匿化されます。

ImageConfig オブジェクト内の TextRedactionMode オプションを指定することで、画像の焼き付きテキストを秘匿化できます。

  • REDACT_ALL_TEXT: データセット内の DICOM 画像から焼き付きテキストをすべて秘匿化します。
  • REDACT_SENSITIVE_TEXT: データセット内の DICOM 画像から焼き付けられた機密テキストを秘匿化します。

REDACT_SENSITIVE_TEXT を指定すると、患者 ID として default infoTypes と custom infoType が秘匿化されます。カルテ番号（MRN）などの情報は画像から削除されます。

画像の秘匿化構成の詳細については、画像の焼き付きテキストの秘匿化をご覧ください。

次のステップ