L'API Cloud Healthcare impose des limites à l'utilisation des ressources pour différentes raisons. Il s'agit, par exemple, de préserver la communauté des utilisateurs de Google Cloud en empêchant les pics d'utilisation imprévus. Google Cloud propose aussi quotas d'essai gratuit qui fournissent un accès limité aux utilisateurs qui explorent Google Cloud, y compris l'API Cloud Healthcare.
Les quotas de l'API Cloud Healthcare sont fixés par projet pour chaque région ou emplacement multirégional. Si vous épuisez votre quota pour une région donnée, l'utilisation de l'API Cloud Healthcare dans les autres régions n'est pas affectée.
Vérifier vos quotas et votre utilisation
Les quotas sont des limites qui s'appliquent au stockage (également appelées "limites d'entrée") et aux opérations.
Pour vérifier les quotas disponibles pour les ressources de votre projet, accédez à la page Quotas de la console Google Cloud.
Pour afficher uniquement les quotas de l'API Cloud Healthcare, dans la colonne Filtre , sélectionnez Service, puis Cloud Healthcare API.
Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que votre utilisation de l'API Cloud Healthcare s'accroît, les quotas peuvent augmenter en conséquence. Si vous pensez qu'une une hausse notable de l'utilisation, vous pouvez demander des ajustements de quota Quotas dans console Google Cloud. Aucuns frais ne s'appliquent lorsque vous demandez une augmentation de quota. Vos coûts n'augmentent que si vous utilisez plus de ressources.
Limites de ressources
L'API Cloud Healthcare limite la taille du contenu d'une requête, par exemple la taille d'une image radio dans une requête DICOM. Vous ne pouvez pas demander la modification d'une limite imposée à une ressource. Toutefois, dans certaines situations, vous pouvez effectuer une opération d'importation pour importer un contenu excédant la limite imposée à une ressource.
Le tableau ci-dessous indique les limites imposées aux ressources et sujettes à modification.
| Modalité | Taille limite des requêtes |
|---|---|
| DICOM |
|
| FHIR | executeBundle : 50 Mo. Autres méthodes : 10 Mo |
| HL7v2 | 10 Mo |
Si vous tentez de traiter un contenu plus volumineux que la limite autorisée pour la ressource, une erreur se produit.
Utiliser des opérations d'importation pour les contenus excédant les limites de ressources
Les opérations d'importation vous permettent de traiter des contenus dont la taille est supérieure à la limite imposée aux ressources. Lors d'une opération d'importation, la taille du contenu n'est limitée que par la taille de stockage maximale de 5 To autorisée pour les objets individuels sur Google Cloud. Les opérations d'importation sont soumises à des quotas de stockage qui déterminent leur durée. Vous pouvez effectuer une opération d'importation si vous souhaitez, par exemple, stocker de nombreuses instances DICOM dans un datastore DICOM, sans être soumis à la limite de taille des requêtes. Au lieu d'importer les instances au moyen des méthodes Store Transaction disponibles, vous pouvez les importer dans un bucket Cloud Storage, puis les importer dans le datastore DICOM.
Pour connaître les étapes détaillées de l'importation de données DICOM au moyen d'une opération d'importation, consultez la page Importer et exporter des données DICOM à l'aide de Cloud Storage.
Pour connaître les étapes détaillées de l'importation de ressources FHIR au moyen d'une opération d'importation, consultez la page Importer et exporter des ressources FHIR à l'aide de Cloud Storage.
Pour connaître les étapes détaillées de l'importation de messages HL7v2 au moyen d'une opération d'importation, consultez la page Importer des messages HL7v2 à partir de Cloud Storage.
Demander la modification d'un quota
Pour demander la modification d'un quota, vous devez disposer de l'autorisation serviceusage.quotas.update. Elle est incluse par défaut pour les rôles prédéfinis suivants : propriétaire, éditeur et administrateur de quotas.
Accédez à la page Quotas.
Sur la page Quotas, sélectionnez les quotas que vous souhaitez modifier. Si vous souhaitez afficher uniquement les quotas de l'API Cloud Healthcare, cliquez sur Service dans la liste déroulante Filtrer le tableau, puis sélectionnez API Cloud Healthcare.
Cochez les cases correspondant aux quotas que vous souhaitez modifier.
En haut de la page, cliquez sur le bouton Modifier les quotas.
Remplissez le formulaire et cliquez sur Suivant.
Saisissez les limites que vous souhaitez, puis cliquez sur Suivant.
Cliquez sur Envoyer la requête.
Par défaut, les demandes de réduction de quota sont refusées. Si vous souhaitez réduire votre quota, répondez à l'e-mail de l'assistance en précisant vos besoins. Un conseiller répondra à votre demande.
Vous recevrez une réponse de l'équipe API Cloud Healthcare dans les 24 à 48 heures suivant votre demande.
Prévoyez une demande de ressources supplémentaires au moins quelques jours à l'avance pour qu'elle soit traitée en temps voulu.
Limites de quota
Les sections suivantes décrivent les quotas associés à l'API Cloud Healthcare les data stores et les opérations.
Quotas DICOM
Le tableau suivant décrit les quotas de l'API Cloud Healthcare associés avec les magasins DICOM et les opérations DICOM.
| Nom de la métrique | Nom à afficher | Description |
|---|---|---|
dicomweb_ops |
Nombre d'opérations DICOMweb par minute et par région | Inclut les méthodes suivantes:
<ph type="x-smartling-placeholder">
|
dicom_structured_storage_bytes |
Entrée de stockage DICOM structurée en octets par minute et par région | Octets structurés, sous forme de tags DICOM et de métadonnées associées, envoyés à l'API Cloud Healthcare lors du traitement des opérations dicomweb_ops. |
dicom_store_ops |
Nombre d'opérations de store DICOM par minute et par région | Opérations effectuées sur le magasin DICOM, et non sur les données DICOM. Inclut les méthodes suivantes: |
dicom_store_lro_ops |
Nombre d'opérations de longue durée du magasin DICOM par minute et par région | Opérations effectuées sur le magasin DICOM, et non sur les données DICOM, qui renvoient une opération de longue durée. Inclut les méthodes suivantes: |
dicom_structured_storage_operations_bytes |
Entrée de stockage DICOM structurée pour les opérations de longue durée, en octets par minute et par région | Octets structurés, sous forme de tags DICOM et de métadonnées associées, envoyés à l'API Cloud Healthcare lors du traitement des opérations dicom_store_lro_ops. |
Quotas FHIR
Le tableau suivant décrit les quotas de l'API Cloud Healthcare associés avec des stores FHIR et des opérations FHIR.
| Nom de la métrique | Nom à afficher | Description |
|---|---|---|
fhir_read_ops |
Nombre d'opérations de lecture FHIR par minute et par région | Mesurée en unités, une unité étant une requête de lecture sur une ressource FHIR individuelle. Inclut les méthodes suivantes: v1beta1: <ph type="x-smartling-placeholder"> v1: <ph type="x-smartling-placeholder"> |
fhir_write_ops |
Nombre d'opérations d'écriture FHIR par minute et par région | Mesurée en unités, une unité correspondant à une requête de création, de mise à jour ou de suppression sur une ressource FHIR individuelle. Inclut les méthodes suivantes: v1beta1: <ph type="x-smartling-placeholder"> v1: <ph type="x-smartling-placeholder"> |
fhir_search_ops |
Nombre d'opérations de recherche FHIR par minute et par région | Mesurée en unités, une unité étant une requête de recherche sur un type de ressource FHIR où la recherche ne nécessite pas de résolution de références, sauf lorsque _include est utilisé. Par exemple, une recherche Observation?subject:Patient.identifier=system|value consomme deux unités de quota fhir_search_ops, car elle nécessite deux recherches, l'une sur la ressource Observation et l'autre sur la ressource Patient, en utilisant subject comme référence.Inclut les méthodes suivantes: v1beta1:
|
fhir_storage_egress_bytes |
Sortie de stockage FHIR en octets par minute et par région | Mesurée en unités, une unité correspondant à un octet, l'API Cloud Healthcare lit l'espace de stockage lors du traitement des opérations fhir_read_ops, fhir_write_ops et fhir_search_ops. |
fhir_storage_bytes |
Entrée de stockage FHIR en octets par minute et par région | Octets envoyés à l'API Cloud Healthcare lors du traitement des opérations fhir_write_ops. |
fhir_store_ops |
Nombre d'opérations de store FHIR par minute et par région | Opérations sur le store FHIR, et non sur les données FHIR. Inclut les méthodes suivantes: |
fhir_store_lro_ops |
Nombre d'opérations de longue durée de store FHIR par minute et par région | Opérations effectuées sur le store FHIR, et non sur des données FHIR, qui renvoient une opération de longue durée. Inclut les méthodes suivantes: |
fhir_storage_operations_bytes |
Entrée de stockage FHIR pour les opérations de longue durée, en octets par minute et par région | Octets envoyés à l'API Cloud Healthcare lors du traitement des opérations fhir_store_lro_ops. |
Recherches multi-opérations
Une même requête peut consommer plusieurs unités de quota. Par exemple, une recherche GET
en utilisant Observation?subject:Patient.identifier=system|value comme
utilise deux unités de quota fhir_search_ops. Deux recherches
sont effectuées, l'une sur la ressource Observation et l'autre sur la ressource Patient, en utilisant
subject comme référence.
S'il s'agit d'une requête de suppression conditionnelle utilisant Observation?status=canceled comme recherche
recherche et supprime six ressources "Observation" :
unités de quota sont consommées:
- Une unité de quota
fhir_search_ops, car la requête de rechercheGETest uniquement sur un type de ressource FHIR, la ressource Observation. La requête renvoie toutes les ressources Observation correspondant aux critères de recherche. - Six unités de quota
fhir_write_ops, car il y a un total de six opérationsDELETEsur les ressources Observation supprimées.
Consommation du quota d'exécution du bundle
Pour envoyer une requête execute bundle, quel que soit le quota utilisé par la requête, Le projet Google Cloud doit avoir au moins une unité disponible pour chacun des les quotas suivants:
fhir_read_opsfhir_write_opsfhir_search_ops
Si ces quotas ne sont pas disponibles, la requête de bundle d'exécution échoue.
Par exemple, si vous envoyez un fhir.executeBundle
avec un groupe de transactions contenant
100 opérations POST, chacune créant une ressource FHIR (l'API Cloud Healthcare)
vérifie d'abord qu'au moins une unité de quota est disponible pour fhir_read_ops, fhir_write_ops et
fhir_search_ops. Si la vérification réussit, l'API Cloud Healthcare
exécute le bundle et crée les ressources FHIR, qui consomment au total
100 unités de quota fhir_write_ops.
Prenons l'exemple du groupe de transactions suivant, qui utilise une référence conditionnelle
Pour créer une ressource Observation si reference existe:
{
"resourceType": "Bundle",
"type": "transaction",
"entry": [
{
"request": {
"method": "POST",
"url": "Observation"
},
"resource": {
"resourceType": "Observation",
"subject": {
"reference": "Patient?identifier=a1b2c3d4e5"
}
}
}
]
}
Lorsque vous exécutez le bundle, l'API Cloud Healthcare
vérifie d'abord qu'au moins une unité de quota est disponible pour fhir_read_ops, fhir_write_ops et
fhir_search_ops Si la vérification réussit, l'API Cloud Healthcare
exécute le bundle. Les unités de quota suivantes sont consommées:
- Un élément
fhir_write_opspour créer la ressource "Observation" - Un élément
fhir_search_ops, car une seule opération de recherche est effectuée sur la référencePatient?identifier=a1b2c3d4e5.