儲存於所有地區的原始 DICOM 資料都會使用 Blob 儲存空間。系統擷取的 DICOM 影像中的可搜尋中繼資料 (例如 DICOM 標記) 會留存，並按照「結構化儲存空間」的費率計費。

Blob 儲存空間的價格取決於擷取和儲存的非結構化或 blob 位元組數，以及使用的儲存空間類別。下表列出可用於儲存原始 DICOM 資料的不同儲存空間級別，以及最短儲存時間：

下表列出在 Cloud Healthcare API 中使用 Nearline、Coldline 和 Archive Storage 級別儲存 DICOM 資料時，適用的靜態資料費用。這些費用適用於所有地區。

刪除、覆寫或重新寫入 DICOM 物件時，會產生提前刪除費用。變更物件的儲存空間級別就是重寫的例子。提前刪除費用等於物件維持原始狀態達到最短時間時，應支付的費用。

請見如下範例：

• 您儲存了 1,000 GB 的 DICOM 物件，儲存空間級別為 Coldline。Coldline Storage 的費率為每月每 GB $0.01 美元。以一個月 30 天計算，每日每 GB 的價格如下：

$0.01/GB/月 * 1 天 / 30 天

• 在第 60 天結束時，您刪除了商店中的所有資料。由於 Coldline 儲存空間的最短儲存時間為 90 天，因此系統會向您收取 90 天的儲存費用。以下是費用明細：
• 資料在 bucket 中存放 60 天所產生的正常靜態儲存空間費用：

$0.01/GB/月 * 1,000 GB * 2 個月 = $20

• 資料在 90 天最短儲存期限內提前刪除，剩餘 30 天的早期刪除費用：

($0.01/GB/月 * 1 天 / 30 天) * 1,000 GB * 30 天 = $10 美元

• 將這兩項費用加總，DICOM 資料儲存 60 天的總費用為 $30 美元，而非 90 天。這與您將 DICOM 資料儲存 90 天，並在第 90 天結束時刪除的費用相同。

讀取、複製、移動或重新寫入儲存在 Nearline Storage、Coldline Storage 或 Archive Storage 的物件資料或中繼資料時，會產生「擷取費用」。這筆費用不包含在與前述資料讀取作業相關的任何網路費用中。

下表列出各儲存空間類別的檢索率：

Cloud Healthcare API 中的擷取、轉換與載入 (ETL) 作業分為下列類別：

• 匯出批次
• 匯出串流
• 轉碼 DICOM

在每個帳單週期中，系統會匯總所有服務的總資料量。下表列出各項 ETL 作業的每 GB 費用：

這些作業項目會根據資料總處理量計算費用。匯出作業項目包括所有目的地，例如 Cloud Storage 和 BigQuery。只有使用不同於上傳時所用的 transfer-syntax 要求 DICOM 執行個體時，才會收取 DICOM 轉碼作業的費用。擷取交易和大量匯出要求可能會發生這種情況。詳情請參閱 DICOM 符合聲明中的「擷取交易」部分。

匯出到 Cloud Storage 時：

• DICOM 資料量會依據所儲存檔案的大小計算。
• FHIR 資料量是依據以通訊協定緩衝區格式傳送的位元組數計算。
• HL7v2 資料量是依據原始 HL7v2 訊息的位元組大小計算。

匯出至 BigQuery：

• DICOM 資料量會依據儲存的 DICOM 中繼資料計算。
• FHIR 的資料量是依據整項資源計算。

以 DICOM 和 FHIR 來說，系統採用的測量方式取決於實際傳送的通訊協定緩衝區位元組數。

進行轉碼時，資料量會依據資料的輸入大小來計算，而非輸出或最大中間大小。

下表列出了各種 ETL 類別的作業項目：

去識別化作業會依據三個子作業中的資料處理量計算費用：

• 檢查：在任意文字或圖片上進行，用於找出是否存在機密資料的情況。
• 轉換：在去識別化過程中，對機密資料進行遮蓋、替換、雜湊或變更。
• 處理：涵蓋作業的基本費用。

每個子作業中的資料量視主要作業的設定方式而定。

注意：去識別化作業會隨著工作完成進度逐步計費。即使作業未完成，仍可能因已順利完成的部分而產生費用。

系統每個月都會依據處理的單位數量和單位所屬級別結算帳單費用。單位分為三個類型，計算方式也各不相同：

• 檢查單位數：取決於檢查的位元組數乘以檢查所用的 infoType 數量的結果。舉例來說，檢查 1 GB 的資料並使用 10 種 infoType，就等於 10 giga-unit (GU) 的檢查量。預設情況下，每次檢查至少會使用 10 個 infoType，因此每個去識別化作業的最低收費為 10 kilo-unit。
• 轉換單位數：取決於轉換的位元組數，其中 1 GB 的資料等於 1 GU 的轉換量。
• 處理單位數：取決於去識別化作業中的總位元組數。

每一種單位有自己的類別定價，如上表所示：

• 檢查和轉換費用都是以 giga-unit (GU) 和 tera-unit (TU) 範圍界定。資料表中針對不同範圍列出的價格均以 GU 為單位。

舉例來說，某個帳單週期的計費方式可能如下所示：

• 低於 1 GU 的檢查量免費。
• 1 TU 至 10 TU 的檢查單位數，以每單位 $0.20 美元計算費用。
• 處理費用以 GB 和 TB 範圍界定。資料表中針對不同範圍列出的價格均以 GB 為單位。

舉例來說，某個帳單週期的計費方式可能如下所示：

• 1 GB 以下的結構化儲存空間、批次處理免費。
• 1 TB 至 10 TB 的結構化儲存空間、批次處理單位數，以每單位 $0.50 美元計算費用。

子作業項目的費用取決於您是處理 FHIR 還是 DICOM 資料：

FHIR：

• 系統會針對檢查是否含有機密資料並進行後續轉換的資源部分收取相關的檢查和轉換費用。
• 整個資源會以「結構化儲存空間、批次」費率收取相關的處理費用。

DICOM：

• 系統會針對檢查是否含有機密資料的資源部分 (包括像素資料) 收取檢查費用。
• 系統會針對檢查後轉換的資源部分 (不含像素資料) 收取轉換費用。如果執行了圖片遮蓋作業，則只會收取檢查費用，不會收取轉換費用。如要瞭解實際的運作方式，請參閱 DICOM 去識別化範例。
• 系統會針對整個資源收取相關處理費用，處理費用會按原始 DICOM 執行個體的大小計算。DICOM 中繼資料的處理費用會使用「結構化儲存空間、批次」類別，像素資料的處理費用則使用「blob 儲存空間、批次」類別。

FHIR 存取控管功能的定價方式如下：

• 有效病患同意聲明和管理員政策的數量。
• 包含 X-Consent-Scope 標頭的 FHIR 要求。
• 套用政策後觸發的重新建立索引作業。

客戶可以選擇啟用 ConsentConfig，藉此啟用這項功能。如果未啟用，這項功能將停用，且不會產生任何費用。

系統會按月收取有效病患同意聲明和有效管理員政策的費用。有效政策須符合下列所有條件：

• 狀態設為「有效」。
• 這項政策是透過 fhirStores.applyConsents 或 fhirStores.applyAdminConsents 方法強制執行。

包含 X-Consent-Scope 標頭的 FHIR 要求會歸類在不同要求類型，與未含標頭的要求相比，價格可能會有所不同：

呼叫 fhirStores.applyConsents 或 fhirStores.applyAdminConsents 方法會產生費用。系統會針對這些呼叫導致重新建立索引的每個 FHIR 資源，收取一筆多作業要求費用。

此外，如果更新強制級聯政策下的區隔基本資源，系統也會收取 FHIR 重新建立索引的費用。

如要瞭解多項作業要求的定價詳情，請參閱「Request volume」。

如要停止收取同意聲明政策的費用，請按照下列步驟操作：

1. 刪除政策資源，或將狀態變更為「無效」。
2. 呼叫 fhirStores.applyConsents (適用於病患同意聲明) 或 fhirStores.applyAdminConsents (適用於管理員政策) 方法，重新套用政策。

FHIR 資源會加上版本。如果刪除政策資源，但未重新套用政策，資源仍會強制執行存取權，並產生帳單費用。

客戶也可以停用 FHIR 存取控管功能，避免產生費用。如要這麼做，請編輯 FHIR 儲存庫並刪除 ConsentConfig 欄位。請注意，停用這項功能會停止執行所有同意聲明政策。

系統會依據批次存取決議作業期間代管的同意聲明資源數量，以及評估的使用者資料對應資源數量，收取 Consent Management API 的費用。

代管同意聲明數量是帳單週期內「使用中」和「草稿」同意聲明物件的平均數量。撤銷、拒絕和封存的同意聲明不會計費。

如果採用批次存取決議方法 projects.locations.datasets.consentStores.queryAccessibleData，則評估的 UserDataMapping 資源數量為提出要求時同意聲明存放區中的 UserDataMapping 資源總數。

系統會依據資料儲存和要求量的說明，收取 Consent Management API 儲存空間和作業的費用。所有同意聲明存放區儲存空間均比照結構化儲存空間計費，但是 consentArtifact 中儲存的非結構化或 blob 位元組除外。所有同意聲明作業都屬於標準要求，下列兩項除外：EvaluateUserConsent 是依複雜要求計費，而 QueryAccessibleData 的收費方式如上一節所述。在目前這段優惠期間，系統不會向您收取儲存空間或標準/複雜作業的費用。

傳入資料移轉

傳入資料一律免付費。

跨區域資料移轉

當傳輸要求源自 Cloud Healthcare API 並傳送到 Google Cloud 上同地區的任何服務時，不必支付資料傳輸費用。

不同地區間的資料傳輸或從多地區群組到同一個大洲的單一地區的資料傳輸 (反之亦然)，適用以下價格。以下為每月每 GB 的價格。

從 Google Cloud 輸出的資料會產生一般網路用量費用。Cloud Healthcare API 使用進階級網際網路資料傳輸，費率如下所示。資料移轉價格同「Google Cloud Network 定價 - 進階級」價格。

以下為每月每 GB 的價格。

假設以 FHIR 為基礎的應用程式託管於 europe-west2 的 Google Cloud 上，這個應用程式在某個月產生了 2,500 萬個要求，每個資源平均使用 4 KB。其中 500 萬個要求屬於 FHIR 搜尋作業，所以會以複雜要求計算費用。在一個月的期間內，FHIR 儲存庫留存了平均 1 TB 的資料，其中包括備份和基本的索引資料量。

下表列出此特定月份的使用模式：

該月費用的計算結果如下：

假設在某個月，一家小型影像中心在位於 us-central1 的 DICOM 儲存庫中產生以下項目：

• 1,000 個 X 光檢查作業 (每個約 10 MB)
• 300 個 CT 檢查作業 (每個約 300 MB)
• 200 個 MRI 檢查作業 (每個約 300 MB)

這家影像中心會將影像保留一年時間，所以每月儲存量平均為 160 GB，另外還有 6.4 GB 的剖析中繼標記儲存量 (包括固定占用的資料量)。為了估算發出的要求數，假設每個 X 光檢查作業都包含一張影像，每個 CT 檢查作業和 MRI 檢查作業包含 300 張影像。

另外再假設以下條件：

• 每項檢查作業都會發出兩個中繼資料搜尋要求 (DICOMweb 搜尋交易)，因此複雜要求的數量總計為：2*(1,000 + 300 + 200) = 3,000 個。
• 每張影像擷取兩次，因此多作業要求的數量總計為：2*(1,000 + 300 * 300 + 200 * 300) = 302,000 個。
• 每次處理影像要求時，系統都必須進行影像轉碼作業，所以轉碼量共計為：2*160 GB = 320 GB。

下表列出此特定月份的使用模式：

該月費用的計算結果如下：

假設位於 us-central1 的 HL7v2 儲存庫連線至一處護理中心，並使用內部部署 MLLP 介面卡每月建立 10,000,000 個訊息。因此，將會有 10,000,000 個擷取要求傳送到 Cloud Healthcare API。而為了回應，系統會產生 10,000,000 個確認訊息 (但不會留存在 HL7v2 儲存庫中)。

在一個月的期間內，HL7v2 儲存庫留存了平均 80 GB 的資料，其中包括備份和基本的索引資料量。

下表列出此特定月份的使用模式：

該月費用的計算結果如下：

假設您對 10 GB 的 FHIR 資料執行去識別化作業。在去識別化的流程中，系統將會先檢查 10% (1 GB) 的資料，然後轉換其中 10% (0.1 GB) 的資料。這個流程會使用預設的 15 個 infoType。

該月去識別化作業的費用計算結果如下：

假設您對 10 GB 的 DICOM 資料執行去識別化作業，其中 90% (9 GB) 的資料由 DICOM 影像組成。所有圖片都經過檢查，有 10% (0.9 GB) 進行了轉換，並使用了預設的 16 個 infoType。

該月去識別化作業的費用計算結果如下：

假設以 FHIR 為基礎的應用程式每個月會產生 160 萬個 Pub/Sub 通知。通知是以 100 萬個為單位計算，因此通知費用的計算方式如下：