Se usa almacenamiento de BLOB para los datos DICOM sin procesar almacenados en todas las regiones. Los metadatos en los que se pueden realizar búsquedas de las imágenes DICOM transferidas (como las etiquetas DICOM) son persistentes y se cobran como parte del almacenamiento estructurado.

Los precios del almacenamiento de BLOB se determinan según la cantidad de bytes no estructurados o de BLOB que se transfieren y almacenan, y según la clase de almacenamiento que usan. En la siguiente tabla, se enumeran las diferentes clases de almacenamiento disponibles para almacenar datos DICOM sin procesar y su duración mínima de almacenamiento:

En la siguiente tabla, se muestran los cargos aplicables en reposo cuando se usan las clases de almacenamiento Nearline, Coldline y Archive Storage para almacenar datos de DICOM en la API de Cloud Healthcare. Estos cargos se aplican a todas las regiones.

Se aplica un cargo por eliminación temprana cuando borras, reemplazas o reescribes un objeto DICOM. Un ejemplo de reescritura es cuando cambias la clase de almacenamiento de un objeto. El cargo por eliminación temprana es igual al importe que se habría cobrado si el objeto hubiera permanecido en su estado original durante la duración mínima.

Considera el siguiente ejemplo:

• Almacenas 1,000 GB de objetos DICOM con la clase de almacenamiento Coldline. En el caso de Coldline Storage, el precio por GB al mes es de $0.01. Si consideramos que un mes tiene 30 días, el precio por GB por día se puede calcular de la siguiente manera:

$0.01/GB/mes * 1 día / 30 días

• Al final del día 60, borras todos los datos de la tienda. Coldline Storage tiene una duración de almacenamiento mínima de 90 días, por lo que se te cobra como si el objeto se hubiera almacenado durante todo el período mínimo. Este es el desglose del cargo:
• El costo de almacenamiento en reposo normal asociado con los 60 días que tus datos existieron en el bucket:

$0.01/GB/mes * 1,000 GB * 2 meses = $20

• Una tarifa de eliminación temprana asociada con los 30 días restantes en la duración mínima de almacenamiento de 90 días de los datos:

($0.01 por GB por mes * 1 día por 30 días) * 1,000 GB * 30 días = $10

• Si sumamos los dos componentes del cargo, el costo total de almacenamiento de tus datos DICOM durante 60 días en lugar de 90 es de $30. Este es el mismo costo que habrías pagado si hubieras almacenado tus datos DICOM durante toda la duración mínima de almacenamiento de 90 días y los hubieras borrado al final del día 90.

Se aplica una tarifa de recuperación cuando lees, copias, mueves o reescribes datos o metadatos de objetos que se almacenan en Nearline Storage, Coldline Storage o Archive Storage. Este costo se suma a los cargos de red asociados con la lectura de los datos.

En la siguiente tabla, se muestran las tasas de recuperación para cada clase de almacenamiento:

Las operaciones de extracción, transformación y carga (ETL) en la API de Cloud Healthcare se encuentran en las siguientes categorías:

• Exportación por lotes
• Transmisión de exportación
• Transcodificación DICOM

En cada período de facturación, se hace una agregación del volumen total de datos de todos los servicios. En la siguiente tabla, se enumeran los costos por GB para cada operación de ETL:

Se facturan estas operaciones en función del volumen total de datos procesados. Las operaciones de exportación incluyen todos los destinos, como Cloud Storage y BigQuery. Los cargos por la transcodificación DICOM solo se aplican cuando una instancia DICOM se solicita en una transfer-syntax distinta de la que se usó para su carga. Esto puede suceder en el caso de las solicitudes de exportación por lotes y las transacciones de recuperación. Para obtener más información, consulta la sección sobre las transacciones de recuperación en la declaración de conformidad de DICOM.

Cuando realizas una exportación a Cloud Storage ocurre lo siguiente:

• El volumen de los datos de DICOM depende del tamaño de los archivos almacenados.
• El volumen de los datos de FHIR depende de los bytes transferidos en el formato del búfer de protocolo.
• El volumen de datos de HL7v2 se basa en el tamaño de los bytes de mensaje sin procesar de HL7v2.

Cuando realizas una exportación a BigQuery ocurre lo siguiente:

• El volumen de los datos de DICOM depende de los metadatos de DICOM almacenados.
• El volumen de los datos de FHIR depende del recurso completo.

Tanto para DICOM como para FHIR, la medida que se utiliza depende de la cantidad de bytes del búfer de protocolo que se transfiere.

Cuando se realiza una transcodificación, el volumen de datos depende del tamaño de entrada de los datos, no del tamaño de salida ni del tamaño intermedio máximo.

En la siguiente tabla, se muestra una lista de operaciones por cada tipo de categoría de ETL:

Los cargos por operaciones de desidentificación se facturan según el volumen de datos procesados en las siguientes tres suboperaciones:

• Inspección: Se aplica al texto libre o a las imágenes para descubrir instancias de datos sensibles.
• Transformación: Comprende la redacción, el reemplazo, el hashing de datos sensibles o la realización de cambios en estos como parte del proceso de desidentificación.
• Procesamiento: cubre el costo base de la operación.

La cantidad de datos de cada suboperación depende de cómo se configure la operación principal.

Nota: Las operaciones de desidentificación se facturan progresivamente a medida que se completa el trabajo. Una operación que no se completa puede generar facturación por el trabajo que se completó correctamente.

Los cargos de facturación se resuelven de forma mensual según la cantidad de unidades procesadas y el nivel al que pertenecen. Hay tres tipos de unidades, y cada uno se calcula de forma diferente:

• Unidades de inspección: se basan en la cantidad de bytes multiplicada por la cantidad de infoTypes que se usaron para la inspección. Por ejemplo, inspeccionar 1 GB de datos con 10 infoTypes equivale a 10 gigaunidades (GU) de inspección. De forma predeterminada, se usa un mínimo de 10 infoTypes para cada inspección, lo que significa que hay un cargo mínimo de 10 kilounidades por operación de desidentificación.
• Unidades de transformación: se basan en la cantidad de bytes transformados, con la equivalencia 1 GB de datos = 1 GU de transformación.
• Unidades de procesamiento: se basan en la cantidad total de bytes incluidos en la operación de desidentificación.

Cada tipo de unidad se cobra al precio de la categoría correspondiente, como se detalla en las tablas anteriores:

• Se proporcionan los costos de inspección y transformación en rangos de gigaunidades (GU) y teraunidades (TU). En cada rango, el precio que se muestra es por GU.

Por ejemplo, en un ciclo de facturación dado, sucede lo siguiente:

• La primera GU de inspección es gratuita.
• Las unidades de inspección se facturan a un valor de $0.20 para la cantidad de unidades entre 1 TU y 10 TU.
• Se proporcionan los costos de procesamiento en rangos de gigabytes (GB) y terabytes (TB). En cada rango, el precio que se muestra es por GB.

Por ejemplo, en un ciclo de facturación dado, sucede lo siguiente:

• Hasta 1 GB de almacenamiento estructurado y procesamiento por lotes es gratuito.
• Las unidades de almacenamiento estructurado y procesamiento por lotes se facturan a un valor de $0.50 por la cantidad de unidades entre 1 TB y 10 TB.

Los cargos generados por las suboperaciones dependen de si trabajas con datos de FHIR o DICOM:

FHIR:

• Se aplican los cargos de inspección y transformación a la parte del recurso que se inspecciona en busca de datos sensibles y que se transforma posteriormente.
• Se aplican los cargos de procesamiento a todo el recurso con la tasa de almacenamiento estructurado, por lotes.

DICOM:

• Se aplican los cargos de inspección a la parte del recurso (incluidos los datos de píxeles) que se inspecciona en busca de datos sensibles.
• Se aplican los cargos de transformación a la parte del recurso (excluidos los datos de los píxeles) que se transforma después de la inspección. Si se realiza un ocultamiento de información en imágenes, solo se aplicarán cargos por inspección, no por transformación. Para obtener información sobre cómo funciona esto en la práctica, consulta el ejemplo de desidentificación de DICOM.
• Los cargos de procesamiento se aplican al recurso completo y se calculan según el tamaño de la instancia de DICOM original. Los cargos de procesamiento de metadatos de DICOM utilizan la categoría almacenamiento estructurado, por lotes. Los cargos de procesamiento de datos de píxeles utilizan la categoría almacenamiento de BLOB, por lotes.

Los precios de la función de control de acceso a FHIR se basan en lo siguiente:

• La cantidad de consentimientos de pacientes y políticas de administrador activos.
• Las solicitudes de FHIR que contienen el encabezado X-Consent-Scope.
• Las operaciones de reindexación que se activan cuando se aplican políticas.

Los clientes pueden optar por habilitar la función habilitando ConsentConfig. Si no se habilita, la función se inhabilitará y no se generarán cargos.

Se te cobra mensualmente por los consentimientos de pacientes activos y las políticas de administrador activas. Una política activa cumple con todos estos criterios:

• Su estado se establece como activo.
• Se aplicó con el método fhirStores.applyConsents o fhirStores.applyAdminConsents.

Las solicitudes FHIR que incluyen el encabezado X-Consent-Scope se clasifican en diferentes tipos de solicitudes, lo que podría afectar los precios en comparación con las solicitudes sin el encabezado:

Llamar a los métodos fhirStores.applyConsents o fhirStores.applyAdminConsents genera cargos. Se te cobra una solicitud de varias operaciones por cada recurso de FHIR que se reindexa como resultado de estas llamadas.

También se te cobra por la reindexación de FHIR cuando actualizas recursos base de compartimentos en políticas en cascada forzadas.

Para obtener detalles sobre los precios de las solicitudes de múltiples operaciones, consulta Volumen de solicitudes.

Para detener los cargos de una política de consentimiento, sigue estos pasos:

1. Borra el recurso de política o cambia su estado a inactivo.
2. Vuelve a aplicar la política llamando al método fhirStores.applyConsents (para los consentimientos de pacientes) o fhirStores.applyAdminConsents (para las políticas de administrador).

Los recursos de FHIR tienen versiones. Si borras un recurso de política sin volver a aplicar la política, el recurso seguirá teniendo acceso forzado y generará cargos de facturación.

Los clientes también pueden detener los cargos inhabilitando la función de control de acceso a FHIR. Para ello, edita el almacén de FHIR y borra el campo ConsentConfig. Ten en cuenta que, si inhabilitas la función, se detendrán todas las aplicaciones de la política de consentimiento.

Se factura la API de administración de consentimientos en función de la cantidad de recursos de Consentimiento administrados y de recursos de UserDataMapping evaluados en las operaciones por lotes de determinación de accesos.

La cantidad facturada de consentimientos administrados corresponde al promedio de objetos Consent con los estados ACTIVE y DRAFT que se procesaron durante el período de facturación. Los consentimientos REVOKED, REJECTED y ARCHIVED no se facturan.

En el caso del método por lotes projects.locations.datasets.consentStores.queryAccessibleData de determinación de accesos, la cantidad de recursos UserDataMapping evaluados corresponde al total de recursos UserDataMapping existentes en el almacén de consentimientos cuando se realiza una solicitud.

Se facturan el almacenamiento y las operaciones de la API de Administración de consentimientos como se describe en las secciones Almacenamiento de datos y Volumen de solicitudes. Se factura todo el almacenamiento de consentimientos como almacenamiento estructurado, excepto los bytes no estructurados o de BLOB que se guardan en un consentArtifact. Todas las operaciones de consentimiento son solicitudes estándares, excepto EvaluateUserConsent, que se factura como solicitud compleja, y QueryAccessibleData, que se factura como se describe en la sección anterior. Durante el período promocional actual, no se te cobrarán el almacenamiento ni las operaciones estándares o complejas.

Transferencia de datos entrante

La transferencia de datos entrante siempre es gratuita.

Transferencia de datos entre regiones

No se generan cargos por la transferencia de datos cuando la solicitud de transferencia se origina en la API de Cloud Healthcare y se dirige a un servicio de Google Cloud ubicado en la misma región.

Los precios que se muestran a continuación se aplican a las transferencias de datos entre regiones o desde un grupo multirregional hacia una región individual en el mismo continente y viceversa. Los precios son por GB al mes.

Se aplica el uso general de la red a los datos que salen de Google Cloud. La API de Cloud Healthcare usa la transferencia de datos Premium de Internet, con los precios que se muestran a continuación. Los precios de transferencia de datos son coherentes con los precios de redes del nivel Premium de Google Cloud.

Los precios son por GB al mes.

Imagina que una aplicación basada en FHIR, alojada en Google Cloud y ubicada en europe-west2, produce 25,000,000 de solicitudes en un mes, con un promedio de 4 kB por recurso. De estas, cinco millones son búsquedas de FHIR, por lo que se cobran como solicitudes complejas. En un período de un mes, el almacenamiento FHIR conserva un promedio de 1 TB de datos, incluidas las copias de seguridad y los gastos de funcionamiento de la indexación.

En la siguiente tabla, se muestra el patrón de uso de este mes:

La factura del mes se calcula de la siguiente manera:

Imagina que, en un mes, un centro de diagnóstico por imágenes pequeño genera lo siguiente en un almacén DICOM ubicado en us-central1:

• 1,000 estudios de rayos X (de unos 10 MB cada uno)
• 300 estudios de tomografía (de unos 300 MB cada uno)
• 200 estudios de resonancia magnética (de unos 300 MB cada uno)

El centro de diagnóstico conserva las imágenes durante un año, lo que significa que, en promedio, cada mes deberán almacenar 160 GB y tener 6.4 GB adicionales de almacenamiento de metaetiquetas analizadas, incluidos los gastos de funcionamiento. Para calcular la cantidad de solicitudes realizadas, calcula que cada estudio de rayos X consta de una sola imagen y cada estudio de tomografía y resonancia magnética consta de 300 imágenes.

Además, calcula lo siguiente:

• Por cada estudio se generan dos solicitudes de búsqueda de metadatos (Transacción de búsqueda DICOMweb), lo que da un total de 2*(1,000 + 300 + 200) = 3,000 solicitudes complejas.
• Cada imagen se recupera dos veces, lo que da un total de 2*(1,000 + 300 * 300 + 200 * 300) = 302,000 solicitudes de varias operaciones.
• Se debe hacer una transcodificación de las imágenes cada vez que se solicitan, lo que da un total de 2 * 160 GB = 320 GB de transcodificación.

En la siguiente tabla, se muestra el patrón de uso de este mes:

La factura del mes se calcula de la siguiente manera:

Imagina que un almacén HL7v2 en us-central1 está conectado a un centro de atención que genera 10,000,000 mensajes al mes a través de un adaptador MLLP local. Como resultado, se enviarán 10 millones de solicitudes de transferencia a la API de Cloud Healthcare. En respuesta, se generarán 10 millones de mensajes de confirmación de recepción (pero estos no se conservarán en el almacén HL7v2).

Durante el transcurso de un mes, el almacén HL7v2 conservará 80 GB de datos en promedio, incluidas las copias de seguridad y los gastos de funcionamiento de la indexación.

En la siguiente tabla, se muestra el patrón de uso de este mes:

La factura del mes se calcula de la siguiente manera:

Imagina que vas a desidentificar 10 GB de datos de FHIR. Durante la desidentificación, se inspeccionará el 10% de los datos (1 GB), de los que se transformará el 10% (0.1 GB). De forma predeterminada, se usan 15 infotipos.

La factura por la desidentificación se calcula de la siguiente manera:

Supón que vas a desidentificar 10 GB de datos de DICOM. El 90% de los datos (9 GB) son imágenes DICOM. Se inspeccionan todas las imágenes y se transforma el 10% (0.9 GB). De forma predeterminada, se usan 16 infotipos.

La factura por la desidentificación se calcula de la siguiente manera:

Imagina que una aplicación basada en FHIR genera 1.6 millones de notificaciones Pub/Sub al mes. Como las notificaciones se calculan por cada millón, la factura se determina de la siguiente manera: