DICOM Medical Viewer との統合

このページでは、サードパーティの医療画像ビューアを Cloud Healthcare API と統合する方法について説明します。Cloud Healthcare API は、Open Health Image Foundation(OHIF)Weeass ビューアなど、複数のビューアと統合されています。

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

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

医療機関の閲覧者は、Cloud Healthcare API に保存されている DICOM データにアクセスするための認証と承認を処理する必要があります。これらの権限は 2 つの方法で付与できます。それぞれの方法には独自のコストと利点があります。

Google ログイン OAuth 2.0 フローの使用

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

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

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

Google ログイン OAuth 2.0 フローを使用した承認

Google ログイン OAuth 2.0 フローを使用すると、医療機関の閲覧者に対し、ユーザーに代わって Cloud Healthcare API に保存された DICOM データにアクセスする許可を与えることができます。アプリケーションに応じて、ウェブサーバーアプリケーションモバイル アプリケーション、デスクトップ アプリケーションJavaScript ウェブ アプリケーションなどのためのフローを利用できます。

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

ログインフローの概要は次のとおりです。

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

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

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

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

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

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

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

必要なロール

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

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

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

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

ユーザーがビューアを認証した後、ビューアは DICOMweb エンドポイントにリクエストを送信できます。各 DICOM ストアは、単一の DICOMweb エンドポイントを公開します。

ユーザーがビューアを使用している場合、アクセスするプロジェクトと DICOM ストアを指定する必要があります。最も簡単な方法は、アクセスするプロジェクト、データセット、DICOM ストアの ID をユーザーに尋ねることです。ただし、個々の値を指定すると、時間がかかる場合があります。

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

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

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

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

すべてのビューアには、ワークリスト プロバイダとイメージ ビューアの 2 つの主要コンポーネントがあります。どちらのコンポーネントでも DICOMweb 標準を使用できます。

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

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

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

インスタンスの表示

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

この方法が Cloud Healthcare API に実装される詳細については、Cloud Healthcare API のDICOM 適合性宣言をご覧ください。

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

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