Cloud Healthcare API enforces limits on resource usage for a variety of reasons. For example, quotas protect the community of Google Cloud users by preventing unforeseen spikes in usage. Google Cloud also offers free trial quotas that provide limited access for users that are exploring Google Cloud, including Cloud Healthcare API.
Quotas for Cloud Healthcare API are enforced by project on either a per-region or multi-region basis. Quota exhaustion in a single region doesn't affect your usage of Cloud Healthcare API in other regions.
Checking your quotas and usage
Quotas are limits on storage (also called ingress limits) and operations.
To check the available quota for resources in your project, go to the Quotas page in Google Cloud console.
To display only Cloud Healthcare API quotas, in the Filter table drop-down list, select Service and then select Cloud Healthcare API.
Not all projects have the same quotas. As your use of Cloud Healthcare API expands over time, your quotas can increase accordingly. If you expect a notable upcoming increase in usage, you can proactively request quota adjustments from the Quotas page in Google Cloud console. There is no charge for requesting an increase in quota. Your costs increase only if you use more resources.
Resource limits
Cloud Healthcare API limits the size of the content of a request, such as the size of an X-ray image in a DICOM request. You cannot request a change to a resource limit; however, in some situations you can use an import operation to import content that is larger than a resource limit.
The following resource limits apply and are subject to change.
Modality | Request size limit |
---|---|
DICOM |
|
FHIR |
|
HL7v2 | 10 MB |
If you attempt to process content larger than the associated resource limit, an error occurs.
FHIR executeBundle size limits
You can use the fhir.executeBundle
method to perform multiple FHIR operations in a single API request. The
number of operations depends on the number of entries in a
batch or transaction bundle. This approach is more efficient than making
individual API calls for each operation.
Processing times for fhir.executeBundle
requests increase with the number
of entries in the bundle. Factors like resource contention (for example,
updating the same resource as part of many transaction bundles in parallel) can
also impact performance. For examples of when resource contention can occur
and how to prevent it from causing errors, see Data throughput best practices.
Large bundles, especially those exceeding 1,000
entries, might time out and fail to complete.
To ensure successful and timely processing, consider these limits when sending your
fhir.executeBundle
requests:
- Transaction bundles: Bundles exceeding 4,500 entries are immediately rejected to prevent timeouts. Transaction bundles require all operations to succeed.
- Batch bundles: No specific entry limit exists, but larger bundles increase the risk of timeouts. Timeouts might result in partial success, with only some entries processed.
Using import operations for content that exceeds resource limits
Import operations permit you to process content that is larger than the associated resource limit. The content size in an import operation is limited only by the Google Cloud maximum storage size of 5 TB for individual objects. Import operations are subject to storage quotas that determine how long an import operation takes. You might want to use an import operation, for example, if you want to store many DICOM instances in a DICOM store and don't want to be subject to the request size limit. Rather than uploading the instances using the available Store Transaction methods, you could instead upload the instances into a Cloud Storage bucket and then import them into the DICOM store.
For detailed steps to import DICOM data using an import operation, see Importing and exporting DICOM data.
For detailed steps to import FHIR resources using an import operation, see Importing and exporting FHIR Resources.
For detailed steps to import HL7v2 messages using an import operation, see Import HL7v2 messages from Cloud Storage.
Request a change to quota
To request a change to a quota, you must have
serviceusage.quotas.update
permission. This permission is included by default
for the following predefined roles: Owner,
Editor, and Quota Administrator.
Go to the Quotas page.
In the Quotas page, select the quotas that you want to change. If you want to display only Cloud Healthcare API quotas, select Service from the Filter table drop-down list and then select Cloud Healthcare API.
Check the boxes of the quotas that you want to edit.
Click the Edit Quotas button at the top of the page.
Fill out the form and then click Next.
Enter the limits that you are requesting and then click Next.
Click Submit request.
A request to decrease quota is rejected by default. If you want to reduce your quota, reply to the support email with an explanation of your requirements. A support representative will respond to your request.
You will receive a response from the Cloud Healthcare API team within 24 to 48 hours of your request.
Plan to request additional resources at least a few days in advance to make sure that there is enough time to fulfill your request.
Location quota requests
You can request a quota increase for the Cloud Healthcare API in a specific region, or in a multi-region location.
To request a quota increase in a single region: In your quota increase request, specify the region.
To request a quota increase in a multi-region location:
- For a quota increase in the
us
multi-region, state in your request that the quota is for "US meta region." - For a quota increase in the
eu
multi-region, state in your request that the quota is for "EU meta region."
Quota limits
The following sections describe the quotas associated with Cloud Healthcare API data stores and operations.
DICOM quotas
The following table describes the Cloud Healthcare API quotas associated with DICOM stores and DICOM operations.
Metric name | Display name | Description |
---|---|---|
dicomweb_ops |
Number of DICOMweb operations per minute per region | Includes the following methods:
|
dicom_structured_storage_bytes |
Structured DICOM storage ingress in bytes per minute per region | Structured bytes, in the form of DICOM tags and related metadata, sent to the Cloud Healthcare API while processing dicomweb_ops operations. |
dicom_store_ops |
Number of DICOM store operations per minute per region | Operations on the DICOM store, not DICOM data. Includes the following methods: |
dicom_store_lro_ops |
Number of DICOM store long-running operations per minute per region | Operations on the DICOM store, not DICOM data, that return a long-running operation. Includes the following methods: |
dicom_structured_storage_operations_bytes |
Structured DICOM storage ingress for long-running operations in bytes per minute per region | Structured bytes, in the form of DICOM tags and related metadata, sent to the Cloud Healthcare API while processing dicom_store_lro_ops operations. |
FHIR quotas
The following table describes the Cloud Healthcare API quotas associated with FHIR stores and FHIR operations.
Metric name | Display name | Description |
---|---|---|
fhir_read_ops |
Number of FHIR read operations per minute per region | Measured in units, where one unit is one read request on an individual FHIR resource. Includes the following methods: v1beta1: v1: |
fhir_write_ops |
Number of FHIR write operations per minute per region | Measured in units, where one unit is one create, update, or delete request on an individual FHIR resource. Includes the following methods: v1beta1: v1: |
fhir_search_ops |
Number of FHIR search operations per minute per region | Measured in units, where one unit is a search request on a FHIR resource type where the search doesn't require resolving references, except when _include is used. For example, a Observation?subject:Patient.identifier=system|value search consumes two fhir_search_ops quota units because it requires two searches, one on the Observation resource and one on the Patient resource, using the subject as a reference.Includes the following methods: v1beta1:
|
fhir_storage_egress_bytes |
FHIR storage egress in bytes per minute per region | Measured in units, where one unit is one byte the Cloud Healthcare API reads from storage while processing fhir_read_ops , fhir_write_ops , and fhir_search_ops operations. |
fhir_storage_bytes |
FHIR storage ingress in bytes per minute per region | Bytes sent to the Cloud Healthcare API while processing fhir_write_ops operations. |
fhir_store_ops |
Number of FHIR store operations per minute per region | Operations on the FHIR store, not FHIR data. Includes the following methods: |
fhir_store_lro_ops |
Number of FHIR store long-running operations per minute per region | Operations on the FHIR store, not FHIR data, that return a long-running operation. Includes the following methods: |
fhir_storage_operations_bytes |
FHIR storage ingress for long-running operations in bytes per minute per region | Bytes sent to the Cloud Healthcare API while processing fhir_store_lro_ops operations. |
Multi-operation searches
A single request can consume multiple quota units. For example, a GET
search
request using Observation?subject:Patient.identifier=system|value
as the
search parameter consumes two fhir_search_ops
quota units. Two search
operations are performed, one on the Observation resource and one on the Patient resource, using the
subject
as a reference.
If a conditional delete request using Observation?status=canceled
as the search
criteria searches for and deletes six Observation resources, the following
quota units are consumed:
- One
fhir_search_ops
quota unit, because theGET
search request is only performed on one type of FHIR resource, the Observation resource. The request returns all Observation resources matching the search criteria. - Six
fhir_write_ops
quota units, because there are a total of sixDELETE
operations on the deleted Observation resources.
Execute bundle quota consumption
To send an execute bundle request, regardless of the quota the request consumes, your Google Cloud project must have at least one unit available for each of the following quotas:
fhir_read_ops
fhir_write_ops
fhir_search_ops
If these quotas aren't available, the execute bundle request fails.
For example, if you send a fhir.executeBundle
request with a transaction bundle containing
100 POST
operations, each of which creates a FHIR resource, the Cloud Healthcare API
first verifies that at least one quota unit is available for fhir_read_ops
, fhir_write_ops
, and
fhir_search_ops
. If the verification succeeds, the Cloud Healthcare API
executes the bundle and creates the FHIR resources, which consume a total of
100 fhir_write_ops
quota units.
Consider the following transaction bundle, which uses a conditional reference
to create an Observation resource if the reference
exists:
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"request": {
"method": "POST",
"url": "Observation"
},
"resource": {
"resourceType": "Observation",
"subject": {
"reference": "Patient?identifier=a1b2c3d4e5"
}
}
}
]
}
When you execute the bundle, the Cloud Healthcare API
first verifies that at least one quota unit is available for fhir_read_ops
, fhir_write_ops
, and
fhir_search_ops
. If the verification succeeds, the Cloud Healthcare API
executes the bundle. The following quota units are consumed:
- One
fhir_write_ops
to create the new Observation resource. - One
fhir_search_ops
, because a single search operation is performed on thePatient?identifier=a1b2c3d4e5
reference.
Best practices
For best practices on managing Cloud Healthcare API quota, see Quota management best practices.