DICOM Medical Viewer との統合

このページでは、サードパーティの医療画像ビューアを Cloud Healthcare API と統合するためのコンセプトとベスト プラクティスについて説明します。Cloud Healthcare API は、Open Health Imaging Foundation(OHIF)ビューアWeasis ビューアなど、複数のビューアと統合されています。

準備

ビューアで使用する DICOM 画像を保存していない場合は、最初に DICOM データの保存Cloud Storage を使用した DICOM データのインポートとエクスポートをご覧ください。

OAuth 2.0 を使用したリクエストの承認と認証

Google Cloud API は、認証と承認の両方で OAuth 2.0 プロトコルをサポートしています。

医療ビューアは、Cloud Healthcare API に保存された DICOM データにアクセスするための認証と承認を扱う必要があります。これらの権限は、2 通りの方法で付与できます。各メソッドには、それぞれに特有のコストとメリットがあります。

Google Identity Services OAuth 2.0 フローの使用

  • エンドユーザーは、Cloud Healthcare API に対して医療ビューアを使用して自身を認証します。
  • 医療機関の閲覧者は、エンドユーザーに代わって Cloud Healthcare API にアクセスします。
  • 権限はユーザーのレベルで管理され、ユーザーのアクションはユーザーの一意の識別子で Cloud Audit Logs に記録されます。
  • Google Identity Services フローの使用は、サービス アカウントの使用よりも複雑です。たとえば、認証トークンを保存するために、アプリケーションはコールバックを処理する必要があります。これにより、単純なアプリケーションには不要な複雑さが増す可能性があります。

サービス アカウントの使用

  • 独自の承認とアクセス制御の方法を使用できるよう Medical Viewer を構成して、エンドユーザーが特定の Cloud Healthcare API リソースを表示できるかどうかを判断します。独自のユーザー管理と認証チェックを実行するビューアがある場合は、サービス アカウントを使用すると便利です。
  • ビューアで実行されたアクションは Cloud Audit Logs に記録されますが、個々のエンドユーザーのレベルでログを表示することはできません。
  • サービス アカウントを使用した認証は、Google Identity Services フローを使用する場合よりも簡単です。たとえば、ユーザーにログインを求める必要はないため、アクセス トークンを保存する必要がありません。

Google Identity Services OAuth 2.0 フローを使用した承認

Google Identity Services OAuth 2.0 フローを使用すると、医療機関の閲覧者に対し、ユーザーに代わって Cloud Healthcare API に保存された DICOM データにアクセスする許可を与えることができます。アプリケーションに応じて、次のアプリケーションで使用できるフローがあります。

ログインフローの以下の説明では、ビューアにアクセスするユーザーが DICOM ストアを作成し、ストアに DICOM インスタンスを保存していることを前提としています。

  1. ユーザーが医療ビューア アプリケーションを開きます。ビューアには、アプリケーションの名前と、ユーザーの認証情報を使用してアクセス権限をリクエストしている Google API サービスが表示されます。ユーザーはアプリケーションへのアクセス権の付与を同意また拒否できます。
  2. ユーザーが Google Identity Services のページに転送されます。ユーザーがアプリケーションに要求されたアクセスを許可すると、アプリケーションはユーザーのデータにアクセスする権限を取得します。

更新トークンは、ビューアに保存しないでください。ユーザーが付与するアクセス トークンは有効期限が短く、トークンの有効期限が切れるときにのみ交換される必要があります。

更新トークンも、以下の理由により不要です。

  • ビューアを使用している場合、ユーザーは常に存在している。
  • 更新トークンを使用するには、トークンを安全に保存するための追加作業が必要です。

サービス アカウントを使用した承認

サービス アカウントで OAuth 2.0 を使用すると、エンドユーザーのレベルではなく、医療機関の閲覧者のレベルで認証と承認を管理できます。

サービス アカウントを使用して医療機関の閲覧者を Cloud Healthcare API で認証する方法については、API への認証をご覧ください。

必要な役割

ビューアが適切に機能するには、ユーザーに次のロールが必要です。

  • roles/healthcare.dicomViewer: DICOM リソースの表示
  • roles/healthcare.dicomEditor: DICOM リソースの表示、編集、作成

ログインフローで、ユーザーはすでにこれらのロールを設定しているはずで、ビューアは他に何もする必要はありません。サービス アカウントを使用する場合、サービス アカウントでロールを設定する必要があります。ビューアは、DICOM ストアへのアクセスに必要な権限を持たないユーザーに適切な PERMISSION_DENIED エラーを返します。

DICOMweb エンドポイントへのアクセス

ユーザーがビューアを認証すると、ビューアは DICOMweb エンドポイントにリクエストを行うことができます。各 DICOM ストアは、1 つの DICOMweb エンドポイントを公開します。

ユーザーがビューアを使用する際は、アクセスするプロジェクトと DICOM ストアを指定する必要があります。アクセスするプロジェクト、データセット、DICOM ストアの ID を指定するようにユーザーに依頼するのが最も簡単です。ただし、個別の値を指定すると、時間がかかる可能性があります。

代わりに、ユーザー入力とオート コンプリートの組み合わせをビューアに渡すこともできます。たとえば、ユーザーにプロジェクト ID を入力してもらうと、ビューアはそのプロジェクト内のデータセットと DICOM ストアのリストを自動的に入力します。または、ユーザーがアクセスできるプロジェクト、データセット、DICOM ストアを自動的に入力する 1 つの入力フィールドを指定することもできます。次の API メソッドは、これらの代替手段の内のどれか 1 つを設定するときに役立ちます。

ユーザー リソースのリストを事前に入力することもできます。ただし、ユーザーが数百または数千の DICOM ストアまたはデータセットを持っている場合、リストの事前入力と表示が履行できない可能性があります。

DICOMweb を使用してビューアでリソースにアクセスする

Cloud Healthcare API はDICOMweb 標準をサポートしています。ユーザーが各自のデータにアクセスできるようにするには、ビューアでレガシーの DIME プロトコルではなく DICOMweb RESTful HTTP メソッドを実装する必要があります。

ビューアには主に 2 つのコンポーネントがあります。

  • ワークリスト プロバイダ
  • イメージ ビューア

どちらのコンポーネントでも DICOMweb 標準を使用できます。

ワークリスト プロバイダの表示

通常、ユーザーがビューアを開いたときに最初に表示される情報は、各 DICOM ストアで利用可能なすべてのスタディのリストです。ビューアは Search Transaction を使用してこれらのスタディを取得できます。

Cloud Healthcare API に検索トランザクションを実装する方法の詳細については、Cloud Healthcare API のDICOM 適合性宣言をご覧ください。

インスタンスの表示

ワークリスト プロバイダに登録した後、ユーザーは通常、表示するスタディを選択します。スタディをレンダリングするには、ビューアはスタディの未加工のピクセルバイトと DICOM メタデータにアクセスする必要があります。この情報は、Retrieve トランザクション セットのメソッドを使用して取得できます。Retrieve トランザクション メソッドを使用すると、未加工の DICOM ファイル全体または未加工のピクセルデータを取得できます。Retrieve トランザクション メソッドでは、異なる転送構文間のコード変換もサポートされています。

Cloud Healthcare API に Search と Retrieve トランザクション メソッドを実装する方法の詳細については、Cloud Healthcare API の DICOM 適合性宣言をご覧ください。

ネットワーク スループットの最大化

CT スキャンをレンダリングするときなど、画像をレンダリングするためにビューアが一度に多数のインスタンスをダウンロードする必要がある場合があります。最良の結果を得るには、多数の同時リクエスト(50 以上など)を使用して各インスタンスを並列にフェッチします。正確な数は、アプリケーションとネットワーク帯域幅によって異なります。