Cloud Healthcare API pricing
This document explains pricing details for Cloud Healthcare API and Healthcare Natural Language API.
Cloud Healthcare API
This section explains pricing details for Cloud Healthcare API. You can also use the Google Cloud Pricing Calculator to estimate the cost of using the Cloud Healthcare API.
If you pay in a currency other than USD, the prices listed in your currency on Cloud Platform SKUs apply.
Pricing overview
Cloud Healthcare API pricing is based on a combination of:
- Data storage
- Request volume
- Notification volume
- DICOM data storage
- DICOM data early deletion
- DICOM data retrieval
- ETL operations
- De-identification operations
- Consent and privacy management
- Network utilization
Pricing tables
The pricing tables below show what charges apply when using the Cloud Healthcare API.
For example scenarios that show usage and charges, see Pricing examples.
Data storage
Data storage charges are categorized as either Structured Storage or Blob Storage. The Blob storage charges in the following table are for Standard storage class, which requires no minimum storage duration. To learn about other Blob storage class charges and their minimum storage duration, see DICOM data storage.
By default, all storage charges are in the Structured Storage category. Storage volume is based on bytes of data ingested plus indexing overhead (as measured by indexed bytes) and backup bytes. Prices are based on periodic measurements aggregated across all data stores during a billing period.
Request volume
A request is an HTTPS or gRPC operation invoked through any of the following:
- The
healthcare.googleapis.com
endpoint - The gcloud tool
- Google Cloud console
Requests can be of the following types:
- Standard requests: Default for all requests
- Complex requests: Captures API requests that are computationally intense compared with standard requests
- Multi-operation requests: Captures multi-operation requests
- Advanced-operation requests: Captures operations such as FHIR point-in-time recovery
Your first 25,000 requests are free. After the free tier is exhausted, the next tiers are priced per 100,000 requests per month.
Category | 0-25,000 requests | 25,000-1 billion requests | 1 billion+ requests |
---|---|---|---|
Standard requests | $0.00 | $0.39 | $0.29 |
Complex requests | $0.00 | $0.69 | $0.59 |
Multi-operation requests | $0.00 | $0.39 | $0.29 |
Advanced operation requests are billed at $0.99 per 100,000 requests.
Unless specified in the following table, all operations are standard requests. Scroll to view full contents of the table.
For example:
- The DICOM operations listed under the "Multi-operation Request operations"
column in the above table can transfer multiple DICOM instances in a single
request (for example, a single
dicomStores.storeInstances
request can be used to upload multiple instances). For these requests, a Multi-operation Request is charged for each DICOM instance transferred. - A call to the
hl7V2Stores.messages.batchGet
method consists of one standard request andn - 1
multi-operation requests wheren
is the number of returned messages. - A call to the
fhir.executeBundle
method consists of one standard request andn-1
multi-operation requests wheren
is the number of requested bundle entries that are not delete operations (fhir.delete
is free). - Validation for FHIR profiles is charged as one Complex Request for each
resource in a
fhir.create
,fhir.update
, andfhir.patch
request. Calls tofhir.executeBundle
are charged for each validated resource in the bundle. You are only charged once per resource, regardless of the number of profiles for the resource. - Recovering a single FHIR resource ID using the FHIR point-in-time recovery
operation (
fhirStores.rollback
) costs $0.0000099, and recovering 100,000 unique FHIR resource IDs costs $0.99.
Notification volume
Notifications are streaming events that originate from data stores and are sent to Google Cloud or external endpoints. Notifications contain either resource names, resource metadata, or entire resources and are generated according to a user-provided configuration. By default, all notifications are of type "Standard Notifications."
The following prices are per 1 million notifications per month:
Category | 0-100,000 notifications (per 1 million) | 100,000+ notifications (per 1 million) |
---|---|---|
Standard Notifications | $0.00 | $0.29 |
For example, Pub/Sub notifications sent to a Pub/Sub topic attached to a data store are Standard Notifications.
DICOM data storage
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:
Storage class | Minimum storage duration |
---|---|
Standard | None |
Nearline | 30 days |
Coldline | 90 days |
Archive | 365 days |
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.
Storage class | Price (per GB per month) |
---|---|
Nearline | $0.020 |
Coldline | $0.010 |
Archive | $0.003 |
The charges for Standard storage class are listed as Blob Storage charges for different regions in the Data storage table.
DICOM data early deletion
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.
DICOM data retrieval
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:
Storage class | Price (per GB) |
---|---|
Standard | $0 |
Nearline | $0.01 |
Coldline | $0.02 |
Archive | $0.05 |
For every retrieval in Nearline storage, Coldline storage, or Archive storage, an additional complex request charge applies.
ETL operations
Extract, transform, and load (ETL) operations in the Cloud Healthcare API are in the following categories:
- Export batch
- Export streaming
- Evaluate batch
- 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:
Category | 0-1 GB | 1-1,024 GB (1 TB) | 1 TB+ |
---|---|---|---|
Export batch | $0.19 | $0.14 | $0.09 |
Export streaming | $0.34 | $0.29 | $0.24 |
Evaluate batch | $0.05 | $0.05 | $0.05 |
Transcode DICOM | $0.00 | $0.004 | $0.003 |
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.
Evaluate batch operations compare data between two annotation stores: a "ground truth" annotation store and an "evaluated" annotation store. The operation iterates through the annotation records in the ground truth store and searches for matches (such as annotation records that describe the same DICOM or FHIR resource) in the evaluated annotation store. Annotation pairs that match are compared to calculate the difference between the ground truth and evaluated annotation records. Prices are proportional to the total size of matched pairs plus the total length of the resource names in the ground truth store.
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.
- Annotation record data volume is based on bytes transferred in the protocol buffer format.
When exporting to BigQuery:
- DICOM data volume is based on stored DICOM metadata.
- FHIR data volume is based on the entire resource.
- Annotation record data volume is based on bytes transferred in the protocol buffer format.
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
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.
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.
Sub-operation | 0-1 GU | 1 GU-1 TU | 1 TU-10 TU | 10+ TU |
---|---|---|---|---|
Inspection | $0.00 | $0.30 | $0.20 | $0.10 |
Transformation | $0.00 | $3.00 | $2.00 | $1.00 |
Sub-operation | Category | 0-1 GB | 1 GB-1 TB | 1 TB-10 TB | 10+ TB |
---|---|---|---|---|---|
Processing | Structured Storage, Batch | $0.00 | $0.60 | $0.50 | $0.40 |
Processing | Blob Storage, Batch | $0.00 | $0.08 | $0.06 | $0.05 |
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.
Consent and privacy management
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.
Unit | Price |
---|---|
Managed consents | $0.05 per consent per month |
Access determination, batch | $0.016 per 1 million UserDataMapping resources evaluated |
Network utilization
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.
Source and destination of traffic | 0 GB+ |
---|---|
North America to North America | $0.01 |
Europe to Europe | $0.02 |
Asia Pacific to Asia Pacific | $0.05 |
Intercontinental (excluding Oceania) | $0.08 |
Intercontinental to/from Oceania | $0.15 |
General network usage
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.
Source and destination of traffic | 0-10 TB | 10 TB-150 TB | 150 TB+ |
---|---|---|---|
North America to North America | $0.105 | $0.080 | $0.060 |
Europe to Europe | $0.105 | $0.080 | $0.060 |
Asia Pacific to Asia Pacific | $0.120 | $0.085 | $0.080 |
South America to South America | $0.120 | $0.085 | $0.080 |
Oceania to Oceania | $0.120 | $0.085 | $0.080 |
Intercontinental (excluding Oceania and China) | $0.120 | $0.085 | $0.080 |
Intercontinental to/from Oceania | $0.190 | $0.160 | $0.150 |
Any traffic to China | $0.190 | $0.160 | $0.150 |
Pricing examples
FHIR pricing example
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:
Pricing category | Type of usage | Amount |
---|---|---|
Request volume | Standard Requests Complex Requests |
20,000,000 5,000,000 |
Data storage | Structured Storage in europe-west2 |
1 TB |
Your bill for the month is calculated as follows:
Pricing category | Calculation | Price |
---|---|---|
Request volume | 25,000,000 requests total: (0-25,000 requests tier) 25,000 Standard Requests * $0.00(25,000-1 billion requests tier) 19,975,000 Standard Requests * $0.39 (0-25,000 requests tier) 25,000 Complex Requests * $0.00(25,000-1 billion requests tier) 4,975,000 Complex Requests * $0.69 |
$0.00$77.90 $0.00$34.33 |
Data storage | 1 TB total: (0-1 GB tier) 1 GB * $0.00(1 GB-1 TB tier) 1,023 GB * $0.39 |
$0.00$398.97 |
Total | $511.20 |
DICOM pricing example
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:
Pricing category | Type of usage | Amount |
---|---|---|
Request volume | Complex Requests Multi-operation Requests |
3,000 302,000 |
Data storage | Structured Storage in us-central1 Blob Storage in us-central1 |
6.4 GB 160 GB |
ETL operations | Transcode DICOM | 320 GB |
Your bill for the month is calculated as follows:
Pricing category | Calculation | Price |
---|---|---|
Request volume | 305,000 requests total: (0-25,000 requests tier) 3,000 Complex Requests * $0.00(0-25,000 requests tier) 25,000 Multi-operation Requests * $0.00(25,000-1 billion requests tier) 277,000 Multi-operation Requests * $0.39 |
$0.00$0.00 $1.08 |
Data storage | 166.4 GB total: (0-1 GB tier) 0.5 GB Structured Storage * $0.00(1 GB-1 TB tier) 5.9 GB Structured Storage * $0.24 (0-1 GB tier) 1 GB Blob Storage * $0.00(1 GB-1 TB tier) 159 GB Blob Storage * $0.02 |
$0.00$1.42 $0.00$3.18 |
ETL operations | 320 GB total: (0-1 GB tier) 1 GB * $0.00(1 GB-1 TB tier) 319 GB * $0.004 |
$0.00$1.28 |
Total | $6.96 |
HL7v2 pricing example
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:
Pricing category | Type of usage | Amount |
---|---|---|
Request volume | Standard Requests | 20,000,000 |
Data storage | Structured Storage in us-central1 |
80 GB |
Your bill for the month is calculated as follows:
Pricing category | Calculation | Price |
---|---|---|
Request volume | 20,000,000 requests total: (0-25,000 requests tier) 25,000 Standard Requests * $0.00(25,000-1 billion requests tier) 19,975,000 Standard Requests * $0.39 |
$0.00$77.90 |
Data storage | 80 GB total: (0-1 GB tier) 1 GB * $0.00(1 GB-1 TB tier) 79 GB * $0.24 |
$0.00$18.96 |
Total | $96.86 |
FHIR de-identification example
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:
Sub-operation | Calculation | Price |
---|---|---|
Inspection | 10 GB * 0.1 inspected * 15 infoTypes * $0.30/GU | $4.50 |
Transformation | 10 GB * 0.1 inspected * 0.1 transformed * $3.00/GU | $0.30 |
Processing | 10 GB * $0.60/GB | $6.00 |
Total | $10.80 |
DICOM de-identification example
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:
Sub-operation | Calculation | Price |
---|---|---|
Inspection | 10 GB * 0.9 images * 16 infoTypes * $0.30/GU | $43.20 |
Transformation | Bundled with inspection | $0.00 |
Processing | DICOM metadata: 10 GB * 0.1 text * $0.60/GB Pixel data: 10 GB * 0.9 images * $0.08/GB |
$0.60 $0.72 |
Total | $44.52 |
Notification volume examples
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:
Notification type | Calculation | Price |
---|---|---|
Pub/Sub notification | 1,600,000 notifications total: (0-100,000 notifications tier) 100,000 notifications * $0.00 (100,000-1.1 million notifications tier) $0.29 (1.1 million - 1.6 million notifications tier) $0.29 * 0.5 |
$0.00 $0.29 $0.145 |
Total | $0.435 |
Healthcare Natural Language API
The Healthcare Natural Language API provides a set of features for extracting healthcare information from medical text. You pay only for the features you use with no upfront commitments. The API supports the following features:
Feature type | Description |
---|---|
Entity analysis | Analyze healthcare entities in text. The response includes the recognized entity mentions and the relationships between them. Each entity is linked to a standard medical vocabulary. |
Pricing text records
Your usage of the Healthcare Natural Language API is calculated in terms of text record monthly volume. A text record contains 1,000 characters. Characters are Unicode characters (including whitespace characters and any markup characters such as HTML or XML tags).
Text record charges are categorized into the following tiers:
- Free (1 text record-2,500 text records)
- Low volume (2,500 text records-1,000,000 text records)
- High volume (More than 1,000,000 text records)
Healthcare Natural Language API costs are calculated each month based on which features you used and how many text records were evaluated using those features. The following table shows the price per 1 text record during a billing month. The prices in the low volume tier only apply to text records evaluated in excess of the free tier. The prices in the high volume tier only apply to text records evaluated in excess of the low volume tier.
Feature | Free tier (1 text record-2,500 text records) | Low volume tier (2,500 text records-1,000,000 text records) | High volume tier (More than 1,000,000 text records) |
---|---|---|---|
Entity analysis | $0.00 | $0.10 | $0.03 |
Text records are billed in 0.1 text record increments, or units. For example,
if you have exceeded the monthly free tier, and you send a request containing
800 characters, you will be charged for 0.8 text records.
The total cost would be $0.08, calculated as follows: 0.8 * $0.10
.
If the number of characters in a request is not a multiple of 100, the character count is rounded upwards to the next increment of 100.
The following table shows an example of the pricing for three requests sent to the Healthcare Natural Language API in the low volume tier (assume that 2,500 text records have already been sent, and the free tier has been exhausted). The requests contain 8,000, 15,000, and 6,000 characters.
Number of characters | Text record units | Price | |
---|---|---|---|
Request 1 | 8,000 | 8 | $0.80 |
Request 2 | 15,000 | 15 | $1.50 |
Request 3 | 6,000 | 6 | $0.60 |
Total | 29,000 | 29 | $2.90 |
The following table shows an example of the pricing for three requests sent to the Healthcare Natural Language API. The requests contain 150,000,000 (150 million), 800,000,000 (800 million), and 600,000,000 (600 million) characters, for a total of 1,550,000,000 (1.55 billion) characters, or 1,550,000 text records.
Number of characters | Text record units | Cumulative text record units | Price | |
---|---|---|---|---|
Request 1 | 150,000,000 | 150,000 | 150,000 | $14,750.00 (0-2,500 text records in free tier, 2,501-150,000 text records in low volume tier) |
Request 2 | 800,000,000 | 800,000 | 950,000 | $80,000.00 (150,000-950,000 text records in low volume tier) |
Request 3 | 600,000,000 | 600,000 | 1,550,000 | $21,500.00 (950,000-1,000,000 text records in low volume tier, remaining 550,000 text records in high volume tier) |
Total | 1,550,000,000 | 1,550,000 | 1,550,000 | $116,250.00 |
Google Cloud Platform costs
If you store text to be analyzed in Cloud Storage, or use other Google Cloud resources in tandem with the Healthcare Natural Language API, such as the Cloud Healthcare API or Compute Engine instances, then you will also be billed for the use of those services. See the Google Cloud Pricing Calculator to determine other costs based on current rates.
To view your current billing status in the Google Cloud console, including usage and your current bill, see the Billing page. For more details about managing your account, see the Cloud Billing Documentation or Billing and Payments Support.
What's next
- Get started with the Cloud Healthcare API by following the Quickstarts.
- Explore the available Cloud Healthcare API how-to guides.
- Read the Cloud Healthcare API documentation.
- Try the Pricing calculator.
- Learn about Cloud Healthcare API solutions and use cases.