Precios de la API de Cloud Healthcare
En este documento se detallan los precios de la API de Cloud Healthcare y API Natural Language de Healthcare.
API de Cloud Healthcare
En esta sección se detallan los precios de la API de Cloud Healthcare. También puede utilizar el Calculadora de precios de Google Cloud para estimar el coste que supone usar la API de Cloud Healthcare.
Si pagas en una moneda que no sea el dólar estadounidense, se aplicarán los precios que figuran para tu divisa en la página de SKUs de Cloud Platform.
Resumen de precios
Los precios de la API de Cloud Healthcare se basan en una combinación de los siguientes elementos:
- Almacenamiento de datos
- Volumen de solicitudes
- Volumen de notificaciones
- Almacenamiento de datos de eSIM
- Eliminación anticipada de datos de eSIM
- Visualización de datos de eSIM
- Operaciones de extracción, transformación y carga (ETL)
- Operaciones de desidentificación
- Gestión de consentimientos y de la privacidad
- Uso de la red
Tablas de precios
En las siguientes tablas de precios se muestran los cargos que se aplican por el uso de la API de Cloud Healthcare.
Para ver ejemplos que reflejan el uso y los cargos, ve a la sección Ejemplos de precios.
Almacenamiento de datos
El almacenamiento de datos se factura según dos categorías: almacenamiento estructurado o almacenamiento de blobs. En la tabla que aparece más abajo, los cargos por almacenamiento de blob corresponden a la , que no requiere una duración de almacenamiento mínima. Para obtener información sobre otras Cargos por clase de almacenamiento de blob y su duración mínima de almacenamiento; consulta Almacenamiento de datos de eSIM.
De forma predeterminada, todos los cargos por almacenamiento forman parte de la categoría de almacenamiento estructurado. El volumen de almacenamiento se basa en los bytes de datos ingeridos más la sobrecarga asociada a la indexación (medida por bytes indexados) y los bytes de las copias de seguridad. Los precios se basan en las mediciones periódicas agregadas de todos los almacenes de datos durante un periodo de facturación.
Volumen de solicitudes
Una solicitud es una operación HTTPS o gRPC que se invoca mediante cualquiera de las siguientes opciones:
- El punto de conexión
healthcare.googleapis.com
- La herramienta gcloud
- Consola de Google Cloud
Hay varios tipos de solicitudes:
- Solicitudes estándar: opción predeterminada para todas las solicitudes
- Solicitudes complejas: captura las solicitudes a la API con gran intensidad computacional en comparación con las solicitudes estándar
- Solicitudes multioperación: captura las solicitudes multioperación
- Solicitudes de operaciones avanzadas: captura operaciones como momentos concretos de FHIR recuperación
Tus primeras 25.000 solicitudes son gratuitas. Cuando se agote el nivel gratuito, los siguientes niveles se tarifican por cada 100.000 solicitudes al mes.
Categoría | Hasta 25.000 solicitudes | De 25.000 a 1000 millones de solicitudes | Más de 1000 millones de solicitudes |
---|---|---|---|
Solicitudes estándar | 0,00 USD | 0,39 USD | 0,29 USD |
Solicitudes complejas | 0,00 USD | 0,69 USD | 0,59 USD |
Solicitudes multioperación | 0,00 USD | 0,39 USD | 0,29 USD |
Las solicitudes de operaciones avanzadas se facturan a 0,99 USD por cada 100.000 solicitudes de anuncios.
A menos que se especifique en la tabla siguiente, todas las operaciones son solicitudes estándar. Desplázate para ver todo el contenido de la tabla.
Por ejemplo:
- Las operaciones DICOM que se enumeran en la columna "Operaciones de solicitudes multioperación" de la tabla anterior pueden transferir varias instancias DICOM con una única solicitud (por ejemplo, una única solicitud
dicomStores.storeInstances
se puede usar para subir varias instancias). En tales casos, se cobra por una solicitud multioperación por cada instancia DICOM transferida. - Una llamada al método
hl7V2Stores.messages.batchGet
consta de una solicitud estándar y varias solicitudes multioperaciónn - 1
, donden
es el número de mensajes devueltos. - Una llamada al método
fhir.executeBundle
consta de una solicitud estándar y varias solicitudesn-1
de varias operaciones donden
es el número de entradas de paquete solicitadas que no son operaciones de eliminación (fhir.delete
es gratis). - La validación de los perfiles FHIR se cobra como una solicitud compleja por cada recurso de una solicitud
fhir.create
,fhir.update
yfhir.patch
. Las llamadas afhir.executeBundle
se cobran por cada recurso validado del paquete. Solo se cobra una vez por recurso, independientemente del número de perfiles que tengan. - Recuperar un solo ID de recurso FHIR mediante la recuperación a un momento dado FHIR
(
fhirStores.rollback
) cuesta 0, 0000099 USD y recuperar 100.000 IDs de recursos FHIR únicos cuestan 0,99 USD.
Volumen de notificaciones
Las notificaciones son eventos de streaming que se originan en los almacenes de datos y que se envían a Google Cloud o a puntos de conexión externos. Contienen nombres de recursos, sus metadatos o recursos enteros. Además, se generan según la configuración que proporcione el usuario. De forma predeterminada, todas las notificaciones pertenecen a la categoría "Notificaciones estándar".
Los siguientes precios son por 1 millón de notificaciones al mes:
Categoría | Hasta 100.000 notificaciones (por 1 millón) | Más de 100.000 notificaciones (por 1 millón) |
---|---|---|
Notificaciones estándar | 0,00 USD | 0,29 USD |
Por ejemplo, las notificaciones de Pub/Sub que se envían a un tema de Pub/Sub vinculado a un almacén de datos son de tipo estándar.
Almacenamiento de datos DICOM
Los datos HTTPS almacenados y sin procesar en todas las regiones utilizan el almacenamiento de blobs. Metadatos disponibles para búsquedas de ingeridas (como las etiquetas de imagen) se conservan y se cobran como parte de Almacenamiento estructurado.
Los precios del almacenamiento de blob se basan en la cantidad de bytes no estructurados o BLOB que se ingieren y se almacenan y en la clase de almacenamiento que utilizan. Los siguientes enumera las diferentes clases de almacenamiento disponibles para almacenar datos de imagen sin procesar y la duración mínima de almacenamiento:
Clase de almacenamiento | Tiempo mínimo de almacenamiento |
---|---|
Estándar | Ninguno |
Nearline | 30 días |
Coldline | 90 días |
Archivar | 365 días |
En la siguiente tabla se muestran los cargos en reposo que se aplican al usar Nearline. almacenamiento en Coldline, y con las clases de almacenamiento Archive para almacenar datos CO API de Cloud Healthcare. Estos cargos se aplican a todas las regiones.
Clase de almacenamiento | Precio (por GB por mes) |
---|---|
Nearline | 0,020 USD |
Coldline | 0,010 USD |
Archivar | 0,003 USD |
Los cargos de la clase de almacenamiento estándar aparecen como Blob Cargos por almacenamiento en diferentes regiones en la sección Almacenamiento de datos tabla.
Eliminación temprana de datos de VPC
Se aplica un cargo por eliminación anticipada cuando elimines, sobrescribas o reescribas un archivo . Un ejemplo de reescritura se produce cuando se cambia la clase de almacenamiento de un objeto. El cargo por eliminación anticipada es igual al importe que se hubiera cobrado si el objeto permanece en su estado original durante el periodo mínimo.
Veamos un ejemplo:
Almacena 1000 GB de objetos eSIM con la clase de almacenamiento Coldline. En el caso del almacenamiento de Coldline, el precio por GB al mes es de 0,01 USD. Considerando un mes como 30 días, el precio por GB al día se puede calcular de la siguiente manera:
$0.01/GB/month * 1 day / 30 days
Al final del día 60, se eliminan todos los datos de la tienda. Porque Coldline almacenamiento tiene una duración mínima de almacenamiento de 90 días, se te cobrará como si el se ha almacenado durante todo el periodo de almacenamiento mínimo de 90 días. Aquí tienes la desglose del cargo:
El coste de almacenamiento en reposo normal asociado a los 60 días que los datos han existido en el segmento:
$0.01/GB/month * 1,000 GB * 2 months = $20
Una tarifa de eliminación anticipada asociada a los 30 días restantes de la Duración mínima de almacenamiento en 90 días:
($0.01/GB/month * 1 day / 30 days) * 1,000 GB * 30 days = $10
Al añadir los dos componentes del cargo, el coste total de almacenamiento de tu archivo los datos de 60 días en lugar de 90 días son de 30 €. Es el mismo coste que habrías Si hubieses almacenado tus datos de imagen diagnosticadas durante todo el periodo de almacenamiento mínimo de 90 días. duración y se elimina al final del día 90.
Extracción de datos de imagen diagnosticada
Se aplica una tarifa de recuperación cuando lees, copias, mueves o reescribes datos de objetos o metadatos almacenados en Nearline Storage, Coldline Storage o Almacenamiento. Este coste se suma a los cargos por red asociados a la lectura de los datos.
En la siguiente tabla se muestran las tasas de extracción de cada clase de almacenamiento:
Clase de almacenamiento | Precio (por GB) |
---|---|
Estándar | 0 USD |
Nearline | 0,01 USD |
Coldline | 0,02 USD |
Archivar | 0,05 USD |
En cada extracción de Nearline Storage, Coldline Storage o Archive Storage, se aplica un cargo por solicitud compleja adicional.
Operaciones de extracción, transformación y carga (ETL)
Las operaciones de extracción, transformación y carga (ETL) de la API de Cloud Healthcare se dividen en las siguientes categorías:
- Exportar lote
- Exportar streaming
- Evaluar lote
- Transcodificar DICOM
En el volumen total se tienen en cuenta los datos agregados de todos los servicios durante cada periodo de facturación. En la siguiente tabla se indican los costes por GB de cada operación de ETL:
Categoría | Hasta 1 GB | De 1 a 1024 GB (1 TB) | Más de 1 TB |
---|---|---|---|
Exportar lote | 0,19 USD | 0,14 USD | 0,09 USD |
Exportar streaming | 0,34 USD | 0,29 USD | 0,24 USD |
Evaluar lote | 0,05 USD | 0,05 USD | 0,05 USD |
Transcodificar DICOM | 0,00 USD | 0,004 USD | 0,003 USD |
Estas operaciones se facturan según el volumen total de datos procesados.
Las operaciones de exportación incluyen todos los destinos, como Cloud Storage y BigQuery. La transcodificación DICOM solo se cobra cuando se solicita una instancia DICOM con un valor de transfer-syntax
distinto al que se ha usado para subirla.
Puede ser el caso con las solicitudes de transacción de recuperación y de exportación en bloque.
Para obtener más información, consulta la sección sobre la transacción de recuperación de la declaración de conformidad de DICOM.
Las operaciones de evaluación de lotes comparan los datos entre dos almacenes de anotaciones: un almacén de anotaciones "validadas en el terreno" y otro de anotaciones "evaluadas". La operación hace iteraciones en todos los registros de anotaciones del almacén validado en el terreno y busca coincidencias (por ejemplo, registros de anotaciones que describan el mismo recurso DICOM o FHIR) en el almacén de anotaciones evaluadas. Los pares de anotaciones que coincidan se comparan para comprobar si hay diferencias entre los registros de anotaciones evaluadas y las validadas en el terreno. Los precios son proporcionales al tamaño total de los pares que coincidan, más la longitud total de los nombres de recurso del almacén validado en el terreno.
A la hora de exportar a Cloud Storage:
- El volumen de los datos DICOM se basa en el tamaño de los archivos almacenados.
- El volumen de los datos FHIR se basa en los bytes transferidos en el formato de búfer de protocolo.
- El volumen de los datos HL7v2 se basa en el número de bytes de mensajes HL7v2 sin procesar.
- El volumen de los datos del registro de anotación se basa en los bytes transferidos en el formato de búfer de protocolo.
A la hora de exportar a BigQuery:
- El volumen de los datos DICOM se basa en los metadatos DICOM almacenados.
- El volumen de los datos FHIR se basa en el recurso entero.
- El volumen de los datos del registro de anotación se basa en los bytes transferidos en el formato de búfer de protocolo.
Tanto en el caso de DICOM como en el de FHIR se usa una medición basada en el número de bytes de búfer de protocolo transferidos.
A la hora de transcodificar, el volumen de los datos no se basa en el tamaño intermedio máximo ni de salida, sino en el tamaño de entrada.
En la siguiente tabla se enumeran las operaciones de cada tipo de categoría ETL:
Operaciones de desidentificación
Las operaciones de desidentificación se facturan según el volumen de datos procesados en estas tres suboperaciones:
- Inspección: se realiza con imágenes o texto libre para descubrir instancias de datos sensibles.
- Transformación: incluye la ocultación, la sustitución, la compresión o la modificación de los datos sensibles como parte del proceso de desidentificación.
- Procesamiento: hace referencia al coste base de la operación.
La cantidad de datos de cada suboperación depende de cómo se realice la principal configurado.
Los cargos de facturación se determinan cada mes en función del número de unidades procesadas y sus niveles. Hay tres tipos de unidades. Cada una de ellas se calcula de manera diferente:
- Unidades de inspección: se basan en el número de bytes inspeccionados, multiplicado por el número de infoTypes usados en la inspección. Por ejemplo, si inspeccionas 1 GB de de datos con 10 infoTypes equivalen a 10 gigaunidades (GU) de inspección. De forma predeterminada, se utilizan un mínimo de 10 infoTypes en 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 el número de bytes transformados. 1 GB de datos equivale a 1 GU de transformación.
- Unidades de procesamiento: se basan en el número total de bytes de la operación de desidentificación.
El precio de cada tipo de unidad depende de la categoría, tal como se especifica en las tablas anteriores:
Los costes de inspección y transformación se ofrecen en intervalos de gigaunidades (GU) y teraunidades (TU). Dentro de cada intervalo, el precio se indica por GU.
A continuación tienes un ejemplo de facturación de un ciclo determinado:
- Hasta 1 GU de inspección es gratis.
- Las unidades de inspección se facturan a 0,20 USD si el total está comprendido entre 1 y 10 TU.
Los costes de procesamiento se ofrecen en intervalos de gigabytes (GB) y terabytes (TB). Dentro de cada intervalo, el precio se indica por GB.
A continuación tienes un ejemplo de facturación de un ciclo determinado:
- Hasta 1 GB de almacenamiento estructurado, el procesamiento por lotes es gratis.
- Las unidades de almacenamiento estructurado y procesamiento por lotes se facturan a 0,50 USD si el total está comprendido entre 1 y 10 TB.
Suboperación | Hasta 1 GU | De 1 GU a 1 TU | De 1 a 10 TU | Más de 10 TU |
---|---|---|---|---|
Inspección | 0,00 USD | 0,30 USD | 0,20 USD | 0,10 USD |
Transformación | 0,00 USD | 3,00 USD | 2,00 USD | 1,00 USD |
Suboperación | Categoría | Hasta 1 GB | De 1 GB a 1 TB | De 1 a 10 TB | Más de 10 TB |
---|---|---|---|---|---|
Procesamiento | Almacenamiento estructurado, por lotes | 0,00 USD | 0,60 USD | 0,50 USD | 0,40 USD |
Procesamiento | Almacenamiento de blobs, por lotes | 0,00 USD | 0,08 USD | 0,06 USD | 0,05 USD |
Los precios de las suboperaciones dependen de si trabajas con datos FHIR o DICOM:
FHIR:
- Los cargos por inspección y transformación se aplican a la parte del recurso que se inspecciona en busca de datos sensibles y, posteriormente, se transforma.
- Los cargos por procesamiento se aplican al recurso entero según la tarifa del almacenamiento estructurado y el procesamiento por lotes.
DICOM:
- Los cargos por inspección se aplican a la parte del recurso (incluidos los datos de píxeles) que se inspecciona en busca de datos sensibles.
- Los cargos por transformación se aplican a la parte del recurso (excluidos los datos de píxeles) que se transforma después de la inspección. Si se realiza ocultación de imágenes, solo se factura la inspección, no la transformación. Para obtener más información sobre cómo funciona en la práctica, consulta el ejemplo de desidentificación de DICOM.
- Los cargos por procesamiento se aplican al recurso entero y se calculan según el tamaño de la instancia DICOM original. Los cargos por procesamiento de metadatos DICOM se basan en la categoría de almacenamiento estructurado y el procesamiento por lotes. Los cargos por procesamiento relativos al uso de datos de píxeles se rigen por la categoría del almacenamiento de blobs y el procesamiento por lotes.
Gestión de consentimientos y de la privacidad
La API Consent Management se factura según el número de recursos Consent
que se gestionan y el número de recursos UserDataMapping
que se evalúan cuando se realizan operaciones por lotes de determinación del acceso.
El número de consentimientos que se gestionan se corresponde con el número medio de objetos Consent
ACTIVE
y DRAFT
que se utilizan durante cada periodo de facturación. Los consentimientos REVOKED
, REJECTED
y ARCHIVED
no se facturan.
Para el método de determinación del acceso por lotes projects.locations.datasets.consentStores.queryAccessibleData
, el número de recursos UserDataMapping
evaluados es el número total de recursos UserDataMapping
que hay en el almacén de consentimientos cuando se realiza una solicitud.
El almacenamiento y las operaciones de la API Consent Management se facturan como se describe en las secciones Almacenamiento de datos y Volumen de solicitudes. Todo el almacén de consentimientos se factura como almacenamiento estructurado, con la excepción de los bytes no estructurados o "blobs", que se almacenan en un consentArtifact
. Todas las operaciones de consentimiento se consideran solicitudes estándar excepto EvaluateUserConsent
, que se factura como una solicitud compleja, y QueryAccessibleData
, que se factura tal y como se describe en la sección anterior. Durante el periodo promocional actual, no se te aplicará ningún cargo por el almacenamiento ni por las operaciones estándar o complejas.
Unidad | Precio |
---|---|
Consentimientos gestionados | 0,05 USD por consentimiento y mes |
Determinación del acceso, por lotes | 0,016 USD por 1 millón de recursos UserDataMapping evaluados |
Uso de la red
Transferencia de datos entrante
La transferencia de datos entrante es siempre gratuita.
Transferencia de datos interregionales
No se cobra por la transferencia de datos cuando la solicitud de transferencia se origina desde la API de Cloud Healthcare y llega a cualquier servicio de Google Cloud que se encuentre en la misma región.
Los siguientes precios se aplican a las transferencias de datos de una región a otra o de un grupo multirregional a una única región del mismo continente y viceversa. Los precios son por GB al mes.
Origen y destino del tráfico | Más de 0 GB |
---|---|
De Norteamérica a Norteamérica | 0,01 USD |
De Europa a Europa | 0,02 USD |
De Asia‑Pacífico a Asia‑Pacífico | 0,05 USD |
Intercontinental (excluida Oceanía) | 0,08 USD |
Intercontinental con Oceanía como origen o destino | 0,15 USD |
Uso de red general
El uso de red general se aplica a los datos que salen de Google Cloud. La La API de Cloud Healthcare usa Premium Internet Data Transfer; se muestran los precios más abajo. Los precios de Data Transfer se corresponden con los precios de la red del nivel premium de Google Cloud.
Los precios son por GB al mes.
Origen y destino del tráfico | Hasta 10 TB | De 10 a 150 TB | Más de 150 TB |
---|---|---|---|
De Norteamérica a Norteamérica | 0,105 USD | 0,080 USD | 0,060 USD |
De Europa a Europa | 0,105 USD | 0,080 USD | 0,060 USD |
De Asia‑Pacífico a Asia‑Pacífico | 0,120 USD | 0,085 USD | 0,080 USD |
De Sudamérica a Sudamérica | 0,120 USD | 0,085 USD | 0,080 USD |
De Oceanía a Oceanía | 0,120 USD | 0,085 USD | 0,080 USD |
Intercontinental (excluidas Oceanía y China) | 0,120 USD | 0,085 USD | 0,080 USD |
Intercontinental con Oceanía como origen o destino | 0,190 USD | 0,160 USD | 0,150 USD |
Cualquier tráfico a China | 0,190 USD | 0,160 USD | 0,150 USD |
Ejemplos de precios
Ejemplo de precios de FHIR
Supongamos que una aplicación basada en FHIR y alojada en la región europe-west2
de Google Cloud produce 25 millones de solicitudes al mes con una media de 4 kB por recurso. Como 5 millones de esas solicitudes son búsquedas FHIR, se facturan como solicitudes complejas. En el periodo de un mes, el almacén FHIR conserva una media de 1 TB de datos, incluida la sobrecarga asociada a la indexación y a las copias de seguridad.
En la siguiente tabla aparece el patrón de uso durante el mes en cuestión:
Categoría de precios | Tipo de uso | Cantidad |
---|---|---|
Volumen de solicitudes | Solicitudes estándar Solicitudes complejas |
20.000.000 5.000.000 |
Almacenamiento de datos | Almacenamiento estructurado en europe-west2 |
1 TB |
La factura del mes se calcularía así:
Categoría de precios | Cálculo | Precio |
---|---|---|
Volumen de solicitudes | 25.000.000 de solicitudes totales: (Nivel de hasta 25.000 solicitudes) 25.000 solicitudes estándar * 0,00 USD (Nivel de 25.000 a 1000 millones de solicitudes) 19.975.000 solicitudes estándar * 0,39 USD (Nivel de hasta 25.000 solicitudes) 25.000 solicitudes complejas * 0,00 USD (Nivel de 25.000 a 1000 millones de solicitudes) 4.975.000 solicitudes complejas * 0,69 USD |
0,00 USD 77,90 USD 0,00 USD 34,33 USD |
Almacenamiento de datos | 1 TB en total: (Nivel de hasta 1 GB) 1 GB * 0,00 USD (Nivel de 1 GB a 1 TB) 1023 GB * 0,39 USD |
0,00 USD 398,97 USD |
Total | 511,20 USD |
Ejemplo de precios de DICOM
Supongamos que, en un mes, un pequeño centro de diagnóstico por imagen genera los siguientes elementos en un almacén DICOM ubicado en us-central1
:
- 1000 estudios de rayos X (aproximadamente, 10 MB cada uno)
- 300 TAC (aproximadamente, 300 MB cada una)
- 200 resonancias magnéticas (aproximadamente, 300 MB cada una)
El centro conserva las imágenes durante un año, lo que conlleva un almacenamiento medio mensual de 160 GB, así como otros 6,4 GB de metaetiquetas analizadas, incluida la sobrecarga. Para calcular el número de solicitudes realizadas, supongamos que cada estudio de rayos X consta de una única imagen, y cada tomografía y cada resonancia magnética, de 300 imágenes.
Supongamos también lo siguiente:
- En cada estudio se realizan 2 solicitudes de búsqueda de metadatos (transacción de búsqueda de DICOMweb) para un total de 2 * (1000 + 300 + 200) = 3000 solicitudes complejas.
- Cada imagen se obtiene dos veces, lo que hace un total de 2 × (1000 + 300 × 300 + 200 × 300) = 302.000 solicitudes multioperación.
- Las imágenes tienen que transcodificarse cada vez que se solicitan, lo que hace un total de 2 * 160 GB = 320 GB transcodificados.
En la siguiente tabla aparece el patrón de uso durante el mes en cuestión:
Categoría de precios | Tipo de uso | Cantidad |
---|---|---|
Volumen de solicitudes | Solicitudes complejas Solicitudes multioperación |
3000 302.000 |
Almacenamiento de datos | Almacenamiento estructurado en us-central1 Almacenamiento de blobs en us-central1 |
6,4 GB 160 GB |
Operaciones de extracción, transformación y carga (ETL) | Transcodificar DICOM | 320 GB |
La factura del mes se calcularía así:
Categoría de precios | Cálculo | Precio |
---|---|---|
Volumen de solicitudes | 305.000 solicitudes en total: (nivel de entre 0 y 25.000 solicitudes) 3000 solicitudes complejas * 0,00 USD (nivel de 0-25.000 solicitudes) 25.000 Solicitudes multioperación * 0,00 USD (Nivel de 25.000 a 1000 millones de solicitudes) 277.000 Solicitudes multioperaciones * 0,39 USD |
0,00 USD 0,00 USD 1,08 USD |
Almacenamiento de datos | 166,4 GB en total: (Nivel de hasta 1 GB) 0,5 GB de almacenamiento estructurado * 0,00 USD (Nivel de 1 GB a 1 TB) 5,9 GB de almacenamiento estructurado * 0,24 USD (Nivel de hasta 1 GB) 1 GB de almacenamiento de blobs * 0,00 USD (Nivel de 1 GB a 1 TB) 159 GB de almacenamiento de blobs * 0,02 USD |
0,00 USD 1,42 USD 0,00 USD 3,18 USD |
Operaciones de extracción, transformación y carga (ETL) | 320 GB en total: (Nivel de hasta 1 GB) 1 GB * 0,00 USD (Nivel de 1 GB a 1 TB) 319 GB * 0,004 USD |
0,00 USD 1,28 USD |
Total | 6,96 USD |
Ejemplo de precios de HL7v2
Supongamos que un almacén HL7v2 de us-central1
está conectado a un centro sanitario que crea 10 millones de mensajes mensuales mediante un adaptador MLLP on‑premise.
Como consecuencia, se envían 10 millones de solicitudes de ingestión a la API de Cloud Healthcare.
En respuesta, se generan 10 millones de mensajes de confirmación (aunque no se conservan en el almacén HL7v2).
En el periodo de un mes, el almacén HL7v2 conserva una media de 80 GB de datos, incluida la sobrecarga asociada a la indexación y a las copias de seguridad.
En la siguiente tabla aparece el patrón de uso durante el mes en cuestión:
Categoría de precios | Tipo de uso | Cantidad |
---|---|---|
Volumen de solicitudes | Solicitudes estándar | 20.000.000 |
Almacenamiento de datos | Almacenamiento estructurado en us-central1 |
80 GB |
La factura del mes se calcularía así:
Categoría de precios | Cálculo | Precio |
---|---|---|
Volumen de solicitudes | 20.000.000 de solicitudes totales: (Nivel de hasta 25.000 solicitudes) 25.000 solicitudes estándar * 0,00 USD (Nivel de 25.000 a 1000 millones de solicitudes) 19.975.000 solicitudes estándar * 0,39 USD |
0,00 USD 77,90 USD |
Almacenamiento de datos | 80 GB en total: (Nivel de hasta 1 GB) 1 GB * 0,00 USD (Nivel de 1 GB a 1 TB) 79 GB * 0,24 USD |
0,00 USD 18,96 USD |
Total | 96,86 USD |
Ejemplo de desidentificación de FHIR
Supongamos que desidentificas 10 GB de datos FHIR. Durante el proceso, se inspecciona el 10 % de los datos (1 GB), del cual se transforma, a su vez, el 10 % (0,1 GB). De forma predeterminada, se usan 15 infoTypes.
La factura de la desidentificación se calcularía así:
Suboperación | Cálculo | Precio |
---|---|---|
Inspección | 10 GB * 0,1 inspeccionado * 15 infoTypes * 0,30 USD/GU | 4,50 USD |
Transformación | 10 GB * 0,1 inspeccionado * 0,1 transformado * 3,00 USD/GU | 0,30 USD |
Procesamiento | 10 GB * 0,60 USD/GB | 6,00 USD |
Total | 10,80 USD |
Ejemplo de desidentificación de DICOM
Supongamos que desidentificas 10 GB de datos DICOM. El 90 % de los datos (9 GB) consta de imágenes DICOM. Aunque se inspeccionan todas las imágenes, se transforma el 10 % (0,9 GB). De forma predeterminada, se usan 16 infoTypes.
La factura de la desidentificación se calcularía así:
Suboperación | Cálculo | Precio |
---|---|---|
Inspección | 10 GB * 0,9 imágenes * 16 infoTypes * 0,30 USD/GU | 43,20 USD |
Transformación | Se incluye con la inspección | 0,00 USD |
Procesamiento | Metadatos DICOM: 10 GB * 0,1 de texto * 0,60 USD/GB Datos de píxeles: 10 GB * 0,9 imágenes * 0,08 USD/GB |
0,60 USD 0,72 USD |
Total | 44,52 USD |
Ejemplos de volumen de notificaciones
Supongamos que una aplicación basada en FHIR genera 1,6 millones de notificaciones de Pub/Sub al mes. Como las notificaciones se calculan por 1 millón, tu factura por las notificaciones se determinaría así:
Tipo de notificación | Cálculo | Precio |
---|---|---|
Notificación de Pub/Sub | 1.600.000 de notificaciones totales: (Nivel de hasta 100.000 notificaciones) 100.000 notificaciones * 0,00 USD (Nivel de 100.000 a 1,1 millones de notificaciones) 0,29 USD (Nivel de 1,1 millones a 1,6 millones de notificaciones) 0,29 USD * 0,5 |
0,00 USD 0,29 USD 0,145 USD |
Total | 0,435 USD |
API Natural Language de Healthcare
La API Natural Language de Healthcare proporciona una serie de funciones para extraer información de atención sanitaria de texto médico. Solo pagas por las que utilizas, sin necesidad de comprometerte a nada por adelantado. La API admite estas funciones:
Tipo de función | Descripción |
---|---|
Análisis de entidades | Analiza entidades de atención médica en texto. La respuesta incluye las menciones a entidades reconocidas y las relaciones entre ellas. Cada entidad está vinculada a un vocabulario médico estándar. |
Precios de los registros de texto
El uso que haces de la API de Healthcare Natural Language se calcula en términos de registro de texto mensual. Un registro de texto contiene 1000 caracteres. Los caracteres son caracteres Unicode (incluidos los espacios en blanco y caracteres de marcado, como las etiquetas HTML o XML).
Los cargos por registros de texto se clasifican en los siguientes niveles:
- Gratis (1 registro de texto y 2500 registros)
- Volumen bajo (2500 registros de texto y 1.000.000 registros de texto)
- Volumen alto (más de 1.000.000 de registros de texto)
Los costes de la API Natural Language de Healthcare se calculan cada mes según las funciones utilizadas y la cantidad de registros de texto evaluados mediante esas funciones. En la siguiente tabla se muestra el precio por cada registro de texto durante un mes de facturación. Los precios del nivel de volumen bajo solo se aplican a los registros de texto evaluados por encima del nivel gratuito. Los precios al alza el nivel de volumen solo se aplica a los registros de texto evaluados por encima del nivel de volumen bajo.
Función | Nivel gratuito (1 registro de texto y 2500 registros) | Nivel de volumen bajo (2500 registros de texto y 1.000.000 de registros de texto) | Nivel de gran volumen (más de 1.000.000 de registros de texto) |
---|---|---|---|
Análisis de entidades | 0,00 USD | 0,10 USD | 0,03 USD |
Los registros de texto se facturan en incrementos de registros de texto de 0,1 o en unidades. Por ejemplo,
si has superado el nivel gratuito mensual y envías una solicitud que contenga
800 caracteres, se te cobrará por 0,8 registros de texto.
El coste total sería de 0,08 USD, calculado de la siguiente manera: 0.8 * $0.10
.
Si el número de caracteres de una solicitud no es múltiplo de 100, el recuento de caracteres se redondea al alza al siguiente incremento de 100.
En la siguiente tabla se muestra un ejemplo del precio de tres solicitudes enviadas a la API de Healthcare Natural Language en el nivel de volumen bajo (se asume que se pueden utilizar 2500 caracteres de texto registros y el nivel gratuito se ha agotado). Las solicitudes contienen 8000, 15.000 y 6000 caracteres.
Número de caracteres | Unidades de registros de texto | Precio | |
---|---|---|---|
Solicitud 1 | 8000 | 8 | 0,80 USD |
Solicitud 2 | 15.000 | 15 | 1,50 USD |
Solicitud 3 | 6000 | 6 | 0,60 USD |
Total | 29 000 | 29 | 2,90 € |
En la siguiente tabla se muestra un ejemplo del precio de tres solicitudes que se envían a la API de Healthcare Natural Language. Las solicitudes contienen 150.000.000 (150 millones), 800.000.000 (800 millones), y 600 millones de caracteres, lo que hace un total de 1.550.000.000 (1550.000 millones) de caracteres o 1.550.000 registros de texto.
Número de caracteres | Unidades de registros de texto | Unidades de registro de texto acumulativos | Precio | |
---|---|---|---|---|
Solicitud 1 | 150.000.000 | 150.000 | 150.000 | 14.750 USD (0-2500 registros de texto en el nivel gratuito y 2501-150.000 registros de texto en el nivel de volumen bajo) |
Solicitud 2 | 800.000.000 | 800.000 | 950 000 | 80.000,00 $ (150.000-950.000 registros de texto en el nivel de volumen bajo) |
Solicitud 3 | 600.000.000 | 600.000 | 1.550.000 | 21.500,00 $ (950.000-1.000.000 de registros de texto en el nivel de volumen bajo, 550.000 registros de texto restantes en el nivel de volumen alto) |
Total | 1.550.000.000 | 1.550.000 | 1.550.000 | 116.250,00 € |
Costes de Google Cloud Platform
Si almacenas texto en Cloud Storage para analizarlo o utilizas otros recursos de Google Cloud (como las instancias de la API de Cloud Healthcare o de Compute Engine) junto con la API Natural Language de Healthcare, también se te cobrará por el uso de esos servicios. Puedes utilizar la calculadora de precios de Google Cloud para determinar otros costes según las tarifas actuales.
Para ver el estado actual de tu facturación en la consola de Google Cloud, incluidos el uso y la factura en curso, visita la página Facturación. Si quieres obtener más información sobre cómo gestionar tu cuenta, consulta la documentación de Facturación de Cloud o la página de asistencia para pagos y facturación.
Siguientes pasos
- Echa un vistazo a las guías de inicio rápido para familiarizarte con la API de Cloud Healthcare.
- Consulta las guías prácticas de la API de Cloud Healthcare.
- Consulta la documentación de la API de Cloud Healthcare.
- Prueba la calculadora de precios.
- Obtén información sobre las soluciones y los casos prácticos de la API de Cloud Healthcare.