與 DICOM 醫學影像檢視器相互整合

本頁面說明將第三方醫療影像檢視器與 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 資料。您可以透過兩種方式授予這些權限。每種方法各有優缺點:

使用 Google 身分識別服務 OAuth 2.0 流程

  • 使用者可透過醫療檢視器向 Cloud Healthcare API 驗證身分。
  • 醫療檢視者會代表使用者存取 Cloud Healthcare API。
  • 權限會在使用者層級管理,使用者的動作會以使用者唯一 ID 記錄到 Cloud Audit Logs
  • 使用 Google 身分識別服務流程比使用服務帳戶更複雜。舉例來說,應用程式需要處理回呼來儲存授權權杖,這可能會為簡單的應用程式增加不必要的複雜度。

使用服務帳戶

  • 您可以設定醫療檢視器,讓其使用自己的授權和存取控管方法,判斷使用者是否可以查看特定 Cloud Healthcare API 資源。如果您已經有可執行使用者管理和驗證檢查的檢視器,建議您使用服務帳戶。
  • 在檢視器中執行的動作會記錄至 Cloud Audit Logs,但您無法查看個別使用者層級的記錄。
  • 使用服務帳戶進行驗證比使用 Google 身分識別服務流程更簡單。舉例來說,您不需要提示使用者登入,因此也不需要儲存存取權權杖。

使用 Google Identity Services OAuth 2.0 流程授權

您可以使用 Google Identity Services OAuth 2.0 流程,授權醫療檢視器代表使用者存取儲存在 Cloud Healthcare API 中的 DICOM 資料。視應用程式而定,您可以使用下列應用程式的流程:

以下說明登入流程,假設存取檢視器的使用者已建立 DICOM 儲存庫,並在儲存庫中儲存 DICOM 執行個體

  1. 使用者開啟醫療檢視器應用程式。觀眾會看到 Google 提供的同意聲明視窗,其中會顯示應用程式名稱,以及應用程式要求使用者授權憑證存取的 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 端點

使用者驗證檢視器後,檢視器就能向 DICOM 網路端點提出要求。每個 DICOM 儲存庫都會公開單一 DICOMweb 端點。

使用者在檢視器中時,必須指定要存取哪些專案和 DICOM 儲存庫。最簡單的程序是請使用者提供要存取的專案、資料集和 DICOM 儲存區的 ID。不過,提供每個個別值可能會讓使用者花費很長的時間。

您也可以在檢視器中提供使用者輸入內容和自動完成功能的組合。舉例來說,您可以讓使用者輸入專案 ID,然後檢視器會自動填入該專案中的資料集和 DICOM 儲存空間清單。或者,您也可以提供單一輸入欄位,自動填入使用者可存取的專案、資料集和 DICOM 儲存空間。設定上述任一替代方案時,您可能會需要下列 API 方法:

您也可以考慮預先填入使用者資源清單。不過,如果使用者有數百或數千個 DICOM 儲存庫或資料集,預先填入及顯示清單可能就不可行。

使用 DICOMweb 在檢視器中存取資源

Cloud Healthcare API 支援 DICOMweb 標準。為了讓使用者存取自己的資料,檢視器必須導入 DICOMweb RESTful HTTP 方法,而非舊版 DIMSE 通訊協定。

任何觀眾都包含兩個主要元件:

  • 工作清單供應工具
  • 圖片檢視器

您可以將 DICOMweb 標準用於這兩種元件。

查看工作清單供應工具

通常,使用者開啟檢視器時,最先看到的會是每個 DICOM 儲存庫中所有可用研究的清單。觀眾可以使用搜尋交易擷取這些研究。

如要進一步瞭解 Cloud Healthcare API 中搜尋交易的實作方式,請參閱 Cloud Healthcare API 的 DICOM 符合聲明

查看執行個體

使用者進入工作清單供應商後,通常會選取要觀看的課程。如要轉譯研究,檢視器必須存取研究的原始像素位元組和 DICOM 中繼資料。觀眾可以使用「Retrieve Transaction」一組方法擷取這項資訊。您可以使用「擷取交易」方法,擷取整個原始 DICOM 檔案或檔案的原始像素資料。擷取交易方法也支援不同轉移語法之間的轉碼。

如要進一步瞭解 Cloud Healthcare API 中如何實作搜尋和擷取交易方法,請參閱 Cloud Healthcare API 的 DICOM 符合聲明

盡量提高網路總處理量

有時 (例如在轉譯電腦斷層掃描時),檢視器可能需要一次下載多個例項,才能轉譯圖片。為獲得最佳結果,請使用大量並行要求 (例如 50 個以上) 並行擷取每個執行個體。具體數量取決於應用程式和網路頻寬。