配額與限制

由於各方面因素的考量，Cloud Healthcare API 有資源用量的限制。舉例來說，配額限制可預防使用量意外暴增的情況，藉此保障 Google Cloud 使用者社群的權益。 Google Cloud 也提供免費試用配額，讓使用者能體驗 Google Cloud的部分功能，包括 Cloud Healthcare API。

每個專案有各自的 Cloud Healthcare API 配額，且配額是根據單一或多個區域計算。在某個區域耗盡配額，不會影響您在其他區域的 Cloud Healthcare API 用量上限。

查看配額與用量

配額指的是儲存空間 (也稱為輸入限制) 和作業方面的限制。

如要查看專案的可用資源配額，請前往 Google Cloud console 的「配額」頁面。

如要只顯示 Cloud Healthcare API 配額，請在「篩選表格」下拉式選單中依序選取「服務」和「Cloud Healthcare API」。

並非所有專案的配額都相同。在您使用 Cloud Healthcare API 一段時間後，系統可能會根據您的用量增長情況自動提升您的配額。如果您預期用量將大幅攀升，可以透過Google Cloud console 的「配額」頁面主動要求提高配額。這類要求不會產生任何費用。除非您使用了更多資源，否則費用不會增加。

資源限制

Cloud Healthcare API 會限制要求的內容大小，例如 DICOM 要求中的 X 光影像的大小。您無法要求調整資源限制，但在某些情況下，您可以使用匯入作業來處理超過資源限制的內容。

目前資源限制如下 (未來可能會有所異動)：

模型 要求大小限制
DICOM
  • 商店交易：無限制。其他方法均為 10 MB。
  • 儲存交易或擷取交易：如果作業時間超過 30 分鐘，就會發生逾時。
  • 搜尋交易方法的偏移值最多可達 1,000,000，而研究/系列上限為 5,000，執行個體上限為 50,000。
  • 去識別化：如果涉及像素遮蓋，去識別化作業無法處理超過 1 GB 的 DICOM 檔案。如果 Pixel 資料經過壓縮，解壓縮後的大小不得超過 2 GB。您可以使用 DICOM 標記計算未壓縮的大小，如下所示：NumberOfFrames * Rows * Columns * SamplesPerPixel * BitsAllocated / 8。
  • 以擷取的 DICOM 檔案來說，上限為每個標記 4 GB。這項限制不適用於長度未定義的值。
  • 在 DICOM 資料的轉碼作業中，檔案大小上限為 1 GB，影格大小上限則為 150 MB。
  • 在已算繪的資源上套用 viewport 查詢參數時，影格大小上限為 50 MB，最大尺寸 (寬度或高度) 為 10,000 像素。
  • dicomStores.import：檔案大小上限為 100 GB。
FHIR
HL7v2 Base64 編碼的 data 欄位大小：10 MB

如果您嘗試處理超過相關資源限制的內容，則會收到錯誤訊息。

FHIR executeBundle 大小限制

您可以使用 fhir.executeBundle 方法，在單一 API 要求中執行多項 FHIR 作業。作業數量取決於批次或交易套件中的項目數量。比起針對每項作業個別呼叫 API，這種做法更有效率。

fhir.executeBundle要求的處理時間會隨著套件中的項目數量增加。資源爭用 (例如，在多個交易套件中平行更新相同資源) 等因素也可能影響效能。如需資源爭用可能發生的情況，以及如何避免資源爭用導致錯誤，請參閱資料輸送量最佳做法。如果套裝組合過大 (尤其是超過 1,000 個項目)，可能會逾時而無法完成。

為確保系統能順利及時處理要求，請在傳送fhir.executeBundle要求時注意下列限制：

  • 交易組合：為避免逾時，如果組合超過 4,500 個項目，系統會立即拒絕。交易套裝組合必須成功執行所有作業。
  • 批次套件：沒有特定項目限制，但套件越大，逾時的風險就越高。逾時可能會導致部分成功，只有部分項目會處理。

使用匯入作業來處理超過資源限制的內容

匯入作業可用於處理超過相關資源限制的內容。在匯入作業中，內容的大小不得超過 5 TB，即 Google Cloud 針對個別物件所設的儲存大小上限。匯入作業受儲存空間配額限制，且該配額會影響完成作業所需的時間。舉例來說，如果您想在 DICOM 儲存庫中儲存大量的 DICOM 執行個體，而不想受到要求大小的限制，建議您使用匯入作業，先將執行個體上傳至 Cloud Storage 值區，再匯入 DICOM 儲存庫，而不透過儲存交易方法上傳執行個體。

如需使用匯入作業匯入 DICOM 資料的詳細步驟，請參閱匯入及匯出 DICOM 資料相關說明。

如需使用匯入作業匯入 FHIR 資源的詳細步驟，請參閱匯入及匯出 FHIR 資源。

如需使用匯入作業匯入 HL7v2 訊息的詳細步驟，請參閱從 Cloud Storage 匯入 HL7v2 訊息。

要求調整配額

您必須具備 serviceusage.quotas.update 權限，才能要求調整配額。根據預設，擁有者、編輯者和配額管理員這些預先定義的角色都具備這項權限。

  1. 前往「配額」頁面。

    前往配額頁面

  2. 在「配額」頁面中，選擇要變更的配額項目。如果只想查看 Cloud Healthcare API 的配額，請在「篩選表格」下拉式選單中依序選取 [服務] 和 [Cloud Healthcare API]。

  3. 依據您要編輯的配額項目勾選相應的方塊。

  4. 按一下頁面頂端的 [編輯配額] 按鈕。

  5. 填寫表單後，按一下 [下一步]。

  6. 輸入要求的上限，然後按一下 [下一步]。

  7. 點選 [提交要求]。

根據預設，系統會自動拒絕減少配額的要求。如想減少配額，請回覆支援電子郵件，並附上提出該需求的原因。我們的支援代表將會回覆您的要求。

您會在提交要求後的 24 至 48 小時內收到 Cloud Healthcare API 團隊的回覆。

請至少提前幾天規劃所需的額外資源並提出申請，確保您的申請可以及時獲得核准。

地點配額要求

您可以要求提高特定區域或多區域位置的 Cloud Healthcare API 配額。

如要提高單一區域的配額，請在配額提高要求中指定該區域。

如要在多區域位置申請提高配額，請按照下列步驟操作：

  • 如要提高us多區域的配額，請在要求中說明配額適用於「美國中繼區域」。
  • 如要提高eu多區域的配額，請在要求中說明配額適用於「歐盟中繼區域」。

配額限制

以下各節說明與 Cloud Healthcare API 資料存放區和作業相關的配額。

DICOM 配額

下表說明與 DICOM 存放區和 DICOM 作業相關的 Cloud Healthcare API 配額。

指標名稱 顯示名稱 說明
dicomweb_ops 每個區域每分鐘的 DICOMweb 作業數 包括下列方法：
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series.instances 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series.instances.frames 方法
dicom_structured_storage_bytes 每個區域每分鐘的結構化 DICOM 儲存空間傳入資料量 (以位元組為單位) 以 DICOM 標記和相關中繼資料形式傳送至 Cloud Healthcare API 的結構化位元組，用於處理 dicomweb_ops 作業。
dicom_store_ops 每個地區每分鐘的 DICOM 儲存庫作業數 DICOM 儲存庫上的作業，而非 DICOM 資料。包括下列方法：
dicom_store_lro_ops 每個地區每分鐘的 DICOM 儲存庫長時間執行作業數 針對 DICOM 儲存庫 (而非 DICOM 資料) 執行的作業，會傳回長時間執行的作業。包括下列方法：
dicom_structured_storage_operations_bytes 每個區域每分鐘的結構化 DICOM 儲存空間傳入資料量 (以位元組為單位)，適用於長時間執行的作業 以 DICOM 標記和相關中繼資料形式傳送至 Cloud Healthcare API 的結構化位元組，用於處理 dicom_store_lro_ops 作業。

FHIR 配額

下表說明與 FHIR 存放區和 FHIR 作業相關的 Cloud Healthcare API 配額。

指標名稱 顯示名稱 說明
fhir_read_ops 每個區域每分鐘的 FHIR 讀取作業數 以單位計算，一個單位代表對個別 FHIR 資源發出的一項讀取要求。

包括下列方法：

v1beta1： v1：
fhir_write_ops 每個區域每分鐘的 FHIR 寫入作業數 以單位計算，一個單位代表對個別 FHIR 資源發出的一項建立、更新或刪除要求。

包括下列方法：

v1beta1： v1：
fhir_search_ops 每個區域每分鐘的 FHIR 搜尋作業次數 以單位計算，一個單位是指對 FHIR 資源類型提出的搜尋要求，且搜尋不需要解析參照 (使用 _include 時除外)。舉例來說，Observation?subject:Patient.identifier=system|value 搜尋會耗用兩個 fhir_search_ops 配額單位，因為這類搜尋需要以 subject 做為參照，分別搜尋 Observation 資源和 Patient 資源。

包括下列方法：

v1beta1： v1：
fhir_storage_egress_bytes 每個區域每分鐘的 FHIR 儲存空間輸出量 (以位元組為單位) 以單位計算，一個單位是指 Cloud Healthcare API 在處理 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 作業時從儲存空間讀取的位元組。
fhir_storage_bytes 每個區域每分鐘的 FHIR 儲存空間傳入資料量 (以位元組為單位) 處理 fhir_write_ops 作業時傳送至 Cloud Healthcare API 的位元組數。
fhir_store_ops 每個區域每分鐘的 FHIR 儲存庫作業數 FHIR 儲存庫上的作業，而非 FHIR 資料。

包括下列方法：
fhir_store_lro_ops 每個區域每分鐘的 FHIR 儲存庫長時間執行作業數 針對 FHIR 儲存庫 (而非 FHIR 資料) 執行的作業，會傳回長時間執行的作業。

包括下列方法：
fhir_storage_operations_bytes 每個區域每分鐘的位元組數，代表長時間執行作業的 FHIR 儲存空間輸入量 處理 fhir_store_lro_ops 作業時傳送至 Cloud Healthcare API 的位元組數。

單一要求可能會耗用多個配額單位。舉例來說，使用 Observation?subject:Patient.identifier=system|value 做為搜尋參數的 GET 搜尋要求會耗用兩個 fhir_search_ops 配額單位。系統會執行兩項搜尋作業，分別針對 Observation 資源和 Patient 資源，並以 subject 做為參照。

如果使用 Observation?status=canceled 做為搜尋條件的條件式刪除要求，搜尋並刪除六個 Observation 資源，則會耗用下列配額單位：

  • 1 個fhir_search_ops配額單位，因為GET搜尋要求只對一種 FHIR 資源 (Observation 資源) 執行。要求會傳回所有符合搜尋條件的 Observation 資源。
  • 六個 fhir_write_ops 配額單位，因為已刪除的 Observation 資源共有六個 DELETE 作業。

執行軟體包配額用量

如要傳送執行套裝組合要求，無論要求消耗的配額為何，Google Cloud 專案必須至少有下列配額各一單位：

  • fhir_read_ops
  • fhir_write_ops
  • fhir_search_ops

如果沒有這些配額，執行套件要求就會失敗。

舉例來說，如果您傳送的 fhir.executeBundle 要求包含 100 項 POST 作業 (每項作業都會建立 FHIR 資源)，Cloud Healthcare API 會先確認 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 至少有一個配額單位可用。如果驗證成功，Cloud Healthcare API 會執行套件並建立 FHIR 資源，總共會消耗 100 個 fhir_write_ops 配額單位。

請參考下列交易套裝組合，其中使用條件式參照，在 reference 存在時建立 Observation 資源：

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "request": {
        "method": "POST",
        "url": "Observation"
      },
      "resource": {
        "resourceType": "Observation",
        "subject": {
          "reference": "Patient?identifier=a1b2c3d4e5"
        }
      }
    }
  ]
}

執行套件時，Cloud Healthcare API 會先確認 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 至少有一個配額單位可用。如果驗證成功，Cloud Healthcare API 會執行該套件。系統會耗用下列配額單位：

  • 一個 fhir_write_ops，用於建立新的 Observation 資源。
  • 一個 fhir_search_ops，因為系統會在 Patient?identifier=a1b2c3d4e5 參照上執行單一搜尋作業。

最佳做法

如要瞭解管理 Cloud Healthcare API 配額的最佳做法，請參閱「配額管理最佳做法」。