Pour toutes les régions, les données DICOM brutes stockées reposent sur le stockage de blobs. Les métadonnées consultables issues des images DICOM ingérées (telles que les tags DICOM) sont conservées et facturées comme stockage structuré.

Les tarifs du stockage de blobs sont basés sur la quantité d'octets non structurés (ou BLOB) qui sont ingérés et stockés, ainsi que sur la classe de stockage utilisée. Le tableau suivant répertorie les différentes classes de stockage disponibles pour stocker les données DICOM brutes et leur durée de stockage minimale :

Le tableau suivant présente les frais au repos applicables lorsque vous utilisez les classes de stockage Nearline, Coldline et Archive pour stocker des données DICOM dans l'API Cloud Healthcare. Ces frais s'appliquent à toutes les régions.

Des frais de suppression anticipée s'appliquent lorsque vous supprimez, écrasez ou réécrivez un objet DICOM. Par exemple, vous réécrivez un objet lorsque vous modifiez sa classe de stockage. Les frais de suppression anticipée sont égaux au montant qui aurait été facturé si l'objet était resté dans son état d'origine pendant la durée minimale.

Prenons l'exemple suivant :

• Vous stockez 1 000 Go d'objets DICOM avec la classe de stockage Coldline. Pour le stockage Coldline, le prix par Go et par mois est de 0,01 $. En considérant qu'un mois compte 30 jours, le prix par Go et par jour peut être calculé comme suit :

0,01 $/Go/mois * 1 jour / 30 jours

• À la fin de la journée 60, vous supprimez toutes les données du magasin. Étant donné que la durée de stockage minimale du stockage Coldline est de 90 jours, vous êtes facturé comme si l'objet avait été stocké pendant toute la durée minimale de stockage de 90 jours. Voici le détail de ces frais :
• Les coûts de stockage au repos normaux associés aux 60 jours où vos données existent dans le bucket :

0,01 $/Go/mois * 1 000 Go * 2 mois = 20 $

• Des frais de suppression anticipée associés aux 30 jours restants dans la durée de stockage minimale de 90 jours des données:

(0,01 $/Go/mois x 1 jour / 30 jours) x 1 000 Go x 30 jours = 10 $

• En additionnant les deux composantes du coût, le coût total de stockage de vos données DICOM pendant 60 jours au lieu de 90 jours s'élève à 30 $. Il s'agit du même coût que vous auriez payé si vous aviez stocké vos données DICOM pendant toute la durée de stockage minimale de 90 jours et les aviez supprimées à la fin du 90e jour.

Des frais de récupération s'appliquent lorsque vous lisez, copiez, déplacez ou réécrivez des données ou des métadonnées d'objet stockées dans les classes Nearline, Coldline ou Archive. Ce coût s'ajoute aux frais de réseau associés à la lecture des données.

Le tableau suivant indique les tarifs de récupération pour chaque classe de stockage :

Les opérations d'extraction, de transformation et de chargement (ETL) dans l'API Cloud Healthcare sont réparties dans les catégories suivantes :

• Exportation par lots
• Exportation en flux continu
• Transcodage DICOM

Le volume total de données est agrégé pour l'ensemble des services au cours de chaque période de facturation. Le tableau suivant indique les coûts par Go pour chaque opération ETL :

Ces opérations sont facturées sur la base du volume total de données traitées. Les opérations d'exportation englobent toutes les destinations, telles que Cloud Storage et BigQuery. Le transcodage DICOM n'est facturé que lorsqu'une instance DICOM est demandée dans le cadre d'une syntaxe de transfert différente de celle utilisée lors de son importation. Ceci peut se produire lors des transactions de récupération et des requêtes d'exportation groupée. Pour en savoir plus, consultez la section Transaction de récupération de la Déclaration de conformité DICOM.

Lors de l'exportation vers Cloud Storage :

• Le volume de données DICOM est basé sur la taille des fichiers stockés.
• Le volume de données FHIR est basé sur les octets transférés au format de tampon de protocole.
• Le volume de données HL7v2 est basé sur la taille des octets bruts du message HL7v2.

Lors de l'exportation vers BigQuery :

• Le volume de données DICOM est basé sur les métadonnées DICOM stockées.
• Le volume de données FHIR est basé sur la totalité de la ressource.

Pour DICOM comme pour FHIR, le calcul effectué est basé sur le nombre d'octets de tampon de protocole transférés.

Lors du transcodage, le volume des données est basé sur la taille d'entrée des données plutôt que sur leur taille de sortie ou leur taille intermédiaire maximale.

Le tableau suivant énumère les opérations pour chaque type de catégorie d'ETL :

Les opérations d'anonymisation sont facturées en fonction du volume de données traitées en trois sous-opérations :

• Inspection : s'effectue sur du texte ou des images sans frais pour détecter les instances de données sensibles.
• Transformation : englobe le masquage, le remplacement, le hachage ou les modifications apportées aux données sensibles dans le cadre du processus d'anonymisation.
• Traitement : correspond au coût de base de l'opération.

La quantité de données traitées dans chacune des sous-opérations dépend de la configuration de l'opération principale.

Remarque : Les opérations d'anonymisation sont facturées progressivement à mesure que le travail est effectué. Une opération qui ne se termine pas peut quand même entraîner des frais pour le travail qui a été effectué.

Les frais sont calculés mensuellement en fonction du nombre d'unités traitées et du niveau concerné. Il existe trois types d'unités, calculés différemment :

• Unités d'inspection : basées sur le nombre d'octets inspectés, multiplié par le nombre d'infoTypes utilisés pour l'inspection. Par exemple, l'inspection de 1 Go de données au moyen de 10 infoTypes équivaut à 10 giga-unités (GU) d'inspection. Par défaut, au moins 10 infoTypes sont utilisés pour chaque inspection, ce qui signifie que le montant minimal des frais applicables est de 10 kilo-unités par opération d'anonymisation.
• Unités de transformation : basées sur le nombre d'octets transformés, sachant que 1 Go de données équivaut à 1 GU de transformation.
• Unités de traitement : basées sur le nombre total d'octets nécessaires à l'opération d'anonymisation.

Chaque type d'unité est facturé selon sa propre catégorie, comme indiqué dans les tableaux ci-dessus :

• Les frais d'inspection et de transformation sont présentés par plages de giga-unités (GU) et de téra-unités (TU). Le tarif indiqué pour chaque plage s'entend par GU.

Par exemple, dans le cadre d'un cycle de facturation donné :

• L'inspection est sans frais jusqu'à 1 GU.
• Les unités d'inspection sont facturées 0,20 $ pour un nombre d'unités compris entre 1 TU et 10 TU.
• Les frais de traitement sont présentés par plages de gigaoctets (Go) et de téraoctets (To). Le tarif indiqué pour chaque plage s'entend par Go.

Par exemple, dans le cadre d'un cycle de facturation donné :

• Le traitement par lot est sans frais jusqu'à 1 Go de stockage structuré.
• Les unités de traitement par lot de stockage structuré sont facturées 0,50 $ pour un nombre d'unités compris entre 1 et 10 To.

Les frais applicables aux sous-opérations varient selon que vous utilisez des données FHIR ou DICOM :

FHIR :

• Les frais d'inspection et de transformation s'appliquent à la partie de la ressource inspectée en vue de détecter des données sensibles, puis transformée.
• Les frais de traitement sont applicables à l'ensemble de la ressource et relèvent de la catégorie "Stockage structuré, par lot".

DICOM :

• Les frais d'inspection s'appliquent à la partie de la ressource (données de pixels comprises) qui fait l'objet d'une inspection visant à détecter des données sensibles.
• Les frais de transformation s'appliquent à la partie de la ressource transformée à la suite de l'inspection (à l'exclusion des données de pixels). Si l'image est masquée, les frais ne s'appliquent qu'à l'inspection, et non à la transformation. Pour en savoir plus sur le fonctionnement pratique, consultez cet exemple d'anonymisation DICOM.
• Les frais de traitement s'appliquent à l'ensemble de la ressource et sont calculés en fonction de la taille de l'instance DICOM d'origine. Les frais de traitement concernant les métadonnées DICOM relèvent de la catégorie "Stockage structuré, par lot". Les frais de traitement des données de pixels relèvent de la catégorie "Stockage de blobs, par lot".

La tarification de la fonctionnalité de contrôle des accès FHIR est basée sur les éléments suivants :

• Nombre de consentements de patients et de règles d'administration actifs.
• Les requêtes FHIR contenant l'en-tête X-Consent-Scope.
• Les opérations de réindexation déclenchées par l'application de règles

Les clients peuvent choisir d'activer cette fonctionnalité en activant ConsentConfig. Si vous ne l'activez pas, la fonctionnalité sera désactivée et vous n'aurez aucun frais à payer.

Vous êtes facturé mensuellement pour les consentements de patients actifs et les règles d'administration actives. Une règle active répond à tous ces critères :

• Son état est défini sur "Actif".
• Il a été appliqué à l'aide de la méthode fhirStores.applyConsents ou fhirStores.applyAdminConsents.

Les requêtes FHIR qui incluent l'en-tête X-Consent-Scope sont classées dans différents types de requêtes, ce qui peut avoir une incidence sur la tarification par rapport aux requêtes sans cet en-tête :

L'appel des méthodes fhirStores.applyConsents ou fhirStores.applyAdminConsents entraîne des frais. Vous êtes facturé pour une requête multi-opération pour chaque ressource FHIR réindexée à la suite de ces appels.

Vous êtes également facturé pour la réindexation FHIR lorsque vous mettez à jour des ressources de base de compartiment dans le cadre de stratégies en cascade appliquées.

Pour en savoir plus sur la tarification des requêtes multi-opérations, consultez la section Volume de requêtes.

Pour arrêter les frais liés à une règle de consentement, procédez comme suit :

1. Supprimez la ressource de règle ou définissez son état sur "inactif".
2. Réappliquez la règle en appelant la méthode fhirStores.applyConsents (pour les consentements des patients) ou fhirStores.applyAdminConsents (pour les règles d'administration).

Les ressources FHIR sont versionnées. Si vous supprimez une ressource de règle sans réappliquer la règle, l'accès à la ressource restera appliqué et des frais de facturation seront générés.

Les clients peuvent également arrêter les frais en désactivant la fonctionnalité de contrôle des accès FHIR. Pour ce faire, modifiez le magasin FHIR et supprimez le champ ConsentConfig. Notez que la désactivation de cette fonctionnalité interrompra l'application de toutes les règles de consentement.

L'API Consent Management est facturée en fonction du nombre de ressources "Consent" gérées et du nombre de ressources "UserDataMapping" évaluées pendant les opérations de détermination d'accès par lots.

Le nombre d'autorisations gérées facturé correspond au nombre moyen d'objets Consent à l'état ACTIVE ou DRAFT pendant la période de facturation. Les autorisations RÉVOQUÉES, REFUSÉES et ARCHIVÉES ne sont pas facturées.

En ce qui concerne la méthode de détermination de l'accès par lots projects.locations.datasets.consentStores.queryAccessibleData, le nombre de ressources UserDataMapping évaluées correspond au nombre total de ressources UserDataMapping dans le magasin d'autorisations au moment de la requête.

La facturation de l'espace de stockage et des opérations de l'API Consent Management est décrite dans les sections Stockage des données et Volume des requêtes. Le stockage du magasin d'autorisations est facturé comme stockage structuré, à l'exception des octets non structurés (ou BLOB) qui sont stockés dans un consentArtifact. Les opérations d'autorisation sont considérées comme des requêtes standards, à l'exception de EvaluateUserConsent, qui est facturée comme requête complexe, et de QueryAccessibleData, qui est facturée comme décrit dans la section précédente. Pendant cette période de promotion, le stockage et les opérations standards/complexes ne vous seront pas facturés.

Transfert de données entrant

Le transfert de données entrant est toujours sans frais.

Transfert de données interrégions

Le transfert de données est sans frais lorsque la requête de transfert provient de l'API Cloud Healthcare et qu'elle est adressée à un service Google Cloud situé dans la même région.

Les tarifs suivants s'appliquent aux transferts de données entre régions ou d'un groupe multirégion vers une seule région du même continent, et inversement. Les tarifs s'entendent par Go et par mois.

L'utilisation générale du réseau correspond aux données qui proviennent de Google Cloud. L'API Cloud Healthcare utilise le transfert de données Internet de niveau Premium, dont les tarifs sont indiqués ci-dessous. Les tarifs de transfert de données sont conformes aux tarifs du réseau Google Cloud niveau Premium.

Les tarifs s'entendent par Go et par mois.

Supposons qu'une application basée sur FHIR et hébergée sur Google Cloud dans la région europe-west2 génère 25 000 000 de requêtes en un mois, pour une moyenne de 4 Ko par ressource. Parmi ces requêtes, cinq millions sont des recherches FHIR et sont donc facturées comme des requêtes complexes. Sur une période d'un mois, le datastore FHIR conserve en moyenne 1 To de données, y compris la surcharge liée à la sauvegarde et à l'indexation.

Le tableau suivant illustre ce modèle d'utilisation au cours du mois :

La facture mensuelle est calculée comme suit :

Supposons qu'en un mois, un petit centre d'imagerie génère le volume de données suivant dans un datastore DICOM situé dans la région us-central1 :

• 1 000 radios (environ 10 Mo chacune)
• 300 scanners (environ 300 Mo chacun)
• 200 IRM (environ 300 Mo chacun)

Le centre d'imagerie conserve les images pendant un an, ce qui donne un stockage mensuel moyen de 160 Go, plus 6,4 Go de stockage de balises Meta analysées, surcharge comprise. Pour estimer le nombre de requêtes effectuées, supposons que chaque radio comporte une seule image, et que chaque scanner et IRM comportent 300 images.

Supposons par ailleurs ce qui suit :

• Pour chaque examen, deux requêtes de recherche de métadonnées (transactions de recherche DICOMweb) sont effectuées, soit un total de 2 x (1 000 + 300 + 200) = 3 000 requêtes complexes.
• Chaque image est récupérée deux fois, soit un total de 2 x (1 000 + 300 x 300 + 200 x 300) = 302 000 requêtes multi-opérations.
• Ces images doivent être transcodées chaque fois qu'elles font l'objet d'une requête, soit un total de 2 x 160 Go = 320 Go transcodés.

Le tableau suivant illustre ce modèle d'utilisation au cours du mois :

La facture mensuelle est calculée comme suit :

Supposons qu'un datastore HL7v2 dans la région us-central1 soit connecté à un établissement de soins générant 10 000 000 de messages par mois au moyen d'un adaptateur MLLP sur site. En d'autres termes, 10 000 000 de requêtes d'ingestion sont adressées à l'API Cloud Healthcare. En retour, 10 000 000 d'accusés de réception sont générés (mais ne sont pas conservés dans le datastore HL7v2).

Sur une période d'un mois, le datastore HL7v2 conserve en moyenne 80 Go de données, y compris la surcharge liée à la sauvegarde et à l'indexation.

Le tableau suivant illustre ce modèle d'utilisation au cours du mois :

La facture mensuelle est calculée comme suit :

Supposons que vous souhaitiez anonymiser 10 Go de données FHIR. Lors de l'anonymisation, 10 % (1 Go) des données seront inspectées, dont 10 % (0,1 Go) seront transformées. On utilise par défaut 15 infoTypes.

L'opération d'anonymisation est facturée comme suit :

Supposons que vous souhaitiez anonymiser 10 Go de données DICOM. 90 % (9 Go) des données sont constituées d'images DICOM. Toutes les images sont inspectées, et 10 % (0,9 Go) sont transformées. On utilise par défaut 16 infoTypes.

L'opération d'anonymisation est facturée comme suit :

Supposons qu'une application basée sur FHIR génère 1,6 million de notifications Pub/Sub par mois. Étant donné que les notifications sont calculées par tranche d'un million, votre facture liée aux notifications est établie comme suit :