Stored, raw DICOM data in all regions uses Blob Storage. Searchable metadata from ingested DICOM images (such as DICOM tags) are persisted and charged as part of Structured Storage.

Blob Storage prices are based on the amount of non-structured or BLOB bytes that are ingested and stored and on the storage class that they use. The following table lists the different storage classes available to store raw DICOM data and their minimum storage duration:

The following table shows the applicable at-rest charges when using Nearline storage, Coldline storage, and Archive storage classes to store DICOM data in Cloud Healthcare API. These charges apply to all regions.

An early deletion charge applies when you delete, overwrite, or rewrite a DICOM object. An example of rewriting is when you change an object's storage class. The early deletion charge is equal to the amount that would've been charged, had the object stayed in its original state for the minimum duration.

Consider the following example:

• You store 1,000 GB of DICOM objects with Coldline storage class. For Coldline storage, the price per GB per month is $0.01. Considering a month as 30 days, the price per GB per day can be calculated as follows:

$0.01/GB/month * 1 day / 30 days

• At the end of day 60, you delete all the data in the store. Because Coldline storage has a 90-day minimum storage duration, you're charged as if the object was stored for the entire 90-day minimum storage duration. Here's the breakdown of the charge:
• The normal at-rest storage cost associated with the 60 days your data existed in the bucket:

$0.01/GB/month * 1,000 GB * 2 months = $20

• An early-deletion fee associated with the 30 days remaining in the data's 90-day minimum storage duration:

($0.01/GB/month * 1 day / 30 days) * 1,000 GB * 30 days = $10

• Adding the two components of the charge, the total storage cost for your DICOM data for 60 days instead of 90 days is $30. This is the same cost you would've paid had you stored your DICOM data for the entire 90-day minimum storage duration and deleted at the end of day 90.

A retrieval fee applies when you read, copy, move, or rewrite object data or metadata that is stored in Nearline storage, Coldline storage, or Archive storage. This cost is in addition to any network charges associated with reading the data.

The following table shows the retrieval rates for each storage class:

Extract, transform, and load (ETL) operations in the Cloud Healthcare API are in the following categories:

• Export batch
• Export streaming
• Transcode DICOM

The total data volume is aggregated across all services during each billing period. The following table lists the costs per GB for each ETL operation:

These operations are billed based on the total volume of data processed. Export operations include all destinations, such as Cloud Storage and BigQuery. DICOM transcoding is only charged when a DICOM instance is requested in a different transfer-syntax than the one it was uploaded with. This can happen for Retrieve Transaction and bulk export requests. For more information, see the Retrieve Transaction section in the DICOM conformance statement.

When exporting to Cloud Storage:

• DICOM data volume is based on the size of the stored files.
• FHIR data volume is based on bytes transferred in the protocol buffer format.
• HL7v2 data volume is based on the size of the raw HL7v2 message bytes.

When exporting to BigQuery:

• DICOM data volume is based on stored DICOM metadata.
• FHIR data volume is based on the entire resource.

For both DICOM and FHIR, the measurement used is based on the number of protocol buffer bytes transferred.

When transcoding, the data volume is based on the data's input size rather than the output or maximum intermediate size.

The following table lists the operations for each type of ETL category:

De-identification operations are billed based on the volume of data processed in three sub-operations:

• Inspection: Occurs on free text or images to discover instances of sensitive data.
• Transformation: Encompasses redaction, replacement, hashing, or changes made to sensitive data as part of the de-identification process.
• Processing: Covers the base cost of the operation.

The amount of data in each sub-operation depends on how the main operation is configured.

Note: De-identification operations are billed progressively as the work completes. An operation that does not complete might still incur billing for the work that was completed successfully.

Billing charges are resolved monthly according to how many units were processed and what tier they fall in. There are three types of units, and each unit type is calculated differently:

• Inspection units: Based on the number of bytes inspected multiplied by the number of infoTypes used for inspection. For example, inspecting 1 GB of data with 10 infoTypes is equivalent to 10 giga-units (GU) of inspection. By default, a minimum of 10 infoTypes are used for each inspection, meaning that there is a minimum charge of 10 kilo-units per de-identification operation.
• Transformation units: Based on the number of bytes transformed, where 1 GB of data is equivalent to 1 GU of transformation.
• Processing units: Based on the total number of bytes in the de-identification operation.

Each type of unit is priced in its own category as detailed in the tables above:

• Inspection and transformation costs are given by ranges of giga-units (GU) and tera-units (TU). Within each range, the price listed is per GU.

For example, for a given billing cycle:

• Up to 1 GU of inspection is free.
• Inspection units are billed at $0.20 for the number of units between 1 TU and 10 TU.
• Processing costs are given by ranges of gigabytes (GB) and terabytes (TB). Within each range, the price listed is per GB.

For example, for a given billing cycle:

• Up to 1 GB of Structured Storage, Batch processing is free.
• Structured Storage, Batch Processing units are billed at $0.50 for the number of units between 1 TB and 10 TB.

The charges for the sub-operations depend on whether you are working with FHIR or DICOM data:

FHIR:

• Inspection and transformation charges apply for the portion of the resource that is inspected for sensitive data and subsequently transformed.
• Processing charges apply to the entire resource at the Structured Storage, Batch rate.

DICOM:

• Inspection charges apply to the portion of the resource (including pixel data) that is inspected for sensitive data.
• Transformation charges apply to the portion of the resource (excluding pixel data) that is transformed after inspection. If image redaction is performed, then charges only apply for inspection, not transformation. For information on how this works in practice, see the DICOM de-identification example.
• Processing charges apply to the entire resource and are calculated based on the size of the original DICOM instance. Processing charges for DICOM metadata use the Structured Storage, Batch category. Processing charges for pixel data use the Blob Storage, Batch category.

Pricing for the FHIR Access Control feature is based on the following:

• The number of active Patient consents and Admin policies.
• The FHIR requests containing the X-Consent-Scope header.
• The re-indexing operations triggered by applying policies.

Customers can choose to optionally enable the feature by enabling the ConsentConfig. If not enabled, the feature will be disabled and no charges will be incurred.

You are charged monthly for active Patient consents and active Admin policies. An active policy meets all of these criteria:

• Its status is set to active.
• It has been enforced using the fhirStores.applyConsents or fhirStores.applyAdminConsents method.

FHIR requests that include the X-Consent-Scope header are classified under different request types, which might affect pricing compared to requests without the header:

Calling the fhirStores.applyConsents or fhirStores.applyAdminConsents methods incurs charges. You are charged for one multi-operation request for each FHIR resource that is re-indexed as a result of these calls.

You are also charged for FHIR re-indexing when you update compartment base resources under enforced cascading policies.

For details on pricing for multi-operation requests, see Request volume.

To stop charges for a consent policy, follow these steps:

1. Delete the policy resource or change its status to inactive.
2. Re-apply the policy by calling the fhirStores.applyConsents (for Patient consents) or fhirStores.applyAdminConsents (for Admin policies) method.

FHIR resources are versioned. If you delete a policy resource without re-applying the policy, the resource will continue to have access enforced and will incur billing charges.

Customers can also stop charges by disabling the FHIR Access Control feature. To do so, edit the FHIR Store and delete the ConsentConfig field. Notice that disabling the feature will stop all consent policy enforcements.

The Consent Management API is billed based on the number of Consent resources being managed and the number of UserDataMapping resources evaluated during batch access determination operations.

The number of consents being managed is the average number of ACTIVE and DRAFT Consent objects during the billing period. REVOKED, REJECTED, and ARCHIVED consents are not billed.

For the batch access determination method projects.locations.datasets.consentStores.queryAccessibleData, the number of UserDataMapping resources evaluated is the total number of UserDataMapping resources in the consent store when a request is made.

Consent Management API storage and operations are billed as described in Data storage and Request volume. All consent store storage is billed as Structured Storage except the non-structured or BLOB bytes that are stored within a consentArtifact. All consent operations are standard requests except EvaluateUserConsent, which is billed as a complex request, and QueryAccessibleData, which is billed as described in the preceding section. During the current promotional period, you won't be charged for storage or standard/complex operations.

Inbound data transfer

Inbound data transfer is always free.

Inter-region data transfer

There is no charge for data transfer when the transfer request originates from the Cloud Healthcare API and goes to any service on Google Cloud that is in the same region.

The following prices apply to data transfers between regions or from a multi-region group to a single region on the same continent and vice versa. Prices are per GB per month.

General network usage applies to data that exits Google Cloud. The Cloud Healthcare API uses Premium Internet Data Transfer, with prices shown below. Data transfer prices are consistent with Google Cloud Network Pricing - Premium Tier.

Prices are per GB per month.

Suppose that a FHIR-based application hosted on Google Cloud in europe-west2 produces 25,000,000 requests in a month with an average of 4 kB per resource. Five million of the requests are FHIR searches and so are billed as Complex Requests. Over a one month period, the FHIR store persists an average of 1 TB of data, including backup and indexing overhead.

The following table shows the usage pattern in the given month:

Your bill for the month is calculated as follows:

Suppose that, in one month, a small imaging center generates the following in a DICOM store located in us-central1:

• 1,000 X-ray studies (~10 MB each)
• 300 CT studies (~300 MB each)
• 200 MRI studies (~300 MB each)

The imaging center maintains images for one year, which leads to an average monthly storage of 160 GB and an additional 6.4 GB of parsed meta tag storage, including overhead. To estimate the number of requests made, assume that each X-ray study consists of a single image and each CT study and MRI study consists of 300 images.

Additionally, assume the following:

• For each study, two metadata search requests (DICOMweb Search Transaction) are made for a total of 2*(1,000 + 300 + 200) = 3,000 Complex Requests.
• Each image is retrieved twice, for a total of 2*(1,000 + 300 * 300 + 200 * 300) = 302,000 Multi-operation Requests.
• The images must be transcoded every time they are requested, for a total of 2*160 GB = 320 GB transcoded.

The following table shows the usage pattern in the given month:

Your bill for the month is calculated as follows:

Suppose that an HL7v2 store in us-central1 is connected to a care facility that creates 10,000,000 messages per month using an on-premises MLLP adapter. As a result, 10,000,000 ingest requests will be sent to the Cloud Healthcare API. In response, 10,000,000 acknowledgment messages are generated (but are not persisted in the HL7v2 store).

Over a one month period, the HL7v2 store persists an average of 80 GB of data, including backup and indexing overhead.

The following table shows the usage pattern in the given month:

Your bill for the month is calculated as follows:

Suppose that you de-identify 10 GB of FHIR data. During de-identification, 10% (1 GB) of the data will be inspected, of which 10% (0.1 GB) will be transformed. A default of 15 infoTypes is used.

Your bill for the de-identification is calculated as follows:

Suppose that you de-identify 10 GB of DICOM data. 90% (9 GB) of the data consists of DICOM images. All of the images are inspected, and 10% (0.9 GB) are transformed. A default of 16 infoTypes is used.

Your bill for the de-identification is calculated as follows:

Suppose that a FHIR-based application generates 1.6 million Pub/Sub notifications per month. Because notifications are calculated per one million, your bill for notifications is calculated as follows: