Precios de la API de Cloud Healthcare

Este documento explica los detalles de precios de la API de Cloud Healthcare y la API de lenguaje natural de atención médica.

API de atención médica en la nube

En esta sección se explican los precios de la API de Cloud Healthcare. También puede usar Google Cloud Calculadora de precios para estimar el costo de usar la API de Cloud Healthcare.

Si paga en una moneda distinta a USD, se aplicarán los precios que figuran en su moneda en los SKU de Cloud Platform .

Resumen de precios

El precio de la API de Cloud Healthcare se basa en una combinación de:

• Almacenamiento de datos
• Volumen de solicitudes
• Volumen de notificaciones
• Almacenamiento de datos DICOM
• Eliminación anticipada de datos DICOM
• Recuperación de datos DICOM
• Operaciones ETL
• Operaciones de desidentificación
• Control de acceso FHIR
• Gestión del consentimiento y la privacidad
• Utilización de la red

Tablas de precios

Las tablas de precios a continuación muestran qué cargos se aplican al utilizar la API de Cloud Healthcare.

Para ver ejemplos de escenarios que muestran el uso y los cargos, consulte Ejemplos de precios .

Almacenamiento de datos

Los cargos por almacenamiento de datos se clasifican como almacenamiento estructurado o almacenamiento de blobs. Los cargos por almacenamiento de blobs que se indican en la siguiente tabla corresponden a la clase de almacenamiento estándar, que no requiere una duración mínima de almacenamiento. Para obtener más información sobre los cargos por otras clases de almacenamiento de blobs y su duración mínima, consulte Almacenamiento de datos DICOM .

De forma predeterminada, todos los cargos de almacenamiento se incluyen en la categoría de Almacenamiento Estructurado. El volumen de almacenamiento se basa en los bytes de datos ingresados, más la sobrecarga de indexación (medida por los bytes indexados) y los bytes de respaldo. Los precios se basan en mediciones periódicas agregadas de todos los almacenes de datos durante un período de facturación.

Volumen de solicitudes

Una solicitud es una operación HTTPS o gRPC invocada a través de cualquiera de los siguientes:

• El punto final healthcare.googleapis.com
• La herramienta gcloud
• Google Cloud consola

Las solicitudes pueden ser de los siguientes tipos:

• Solicitudes estándar: valor predeterminado para todas las solicitudes
• Solicitudes complejas: captura solicitudes de API que requieren un uso intensivo de recursos computacionales en comparación con las solicitudes estándar.
• Solicitudes de múltiples operaciones: captura solicitudes de múltiples operaciones
• Solicitudes de operaciones avanzadas: captura operaciones como la recuperación en un punto en el tiempo de FHIR

Tus primeras 25,000 solicitudes son gratuitas. Una vez agotadas las opciones gratuitas, las siguientes se cobran por cada 100,000 solicitudes al mes.

Las solicitudes de operaciones avanzadas se facturan a $0,99 por cada 100.000 solicitudes.

A menos que se especifique en la siguiente tabla, todas las operaciones son solicitudes estándar. Desplácese para ver el contenido completo de la tabla.

Por ejemplo:

• Las operaciones DICOM enumeradas en la columna "Operaciones de solicitud multioperación" de la tabla anterior permiten transferir varias instancias DICOM en una sola solicitud (por ejemplo, una sola solicitud dicomStores.storeInstances permite cargar varias instancias). Para estas solicitudes, se cobra una solicitud multioperación por cada instancia DICOM transferida.
• Una llamada al método hl7V2Stores.messages.batchGet consta de una solicitud estándar y n - 1 solicitudes de operaciones múltiples, donde n es la cantidad de mensajes devueltos.
• Una llamada al método fhir.executeBundle consta de una solicitud estándar y n-1 solicitudes de operaciones múltiples, donde n es el número de entradas de paquete solicitadas que no son operaciones de eliminación ( fhir.delete es gratuito).
• La validación de perfiles FHIR se factura como una solicitud compleja por cada recurso en las solicitudes fhir.create , fhir.update y fhir.patch . Las llamadas a fhir.executeBundle se facturan por cada recurso validado del paquete. Solo se factura una vez por recurso, independientemente del número de perfiles.
• Recuperar un solo ID de recurso FHIR mediante la operación de recuperación de punto en el tiempo FHIR ( fhirStores.rollback ) cuesta $0,0000099, y recuperar 100 000 ID de recursos FHIR únicos cuesta $0,99.

Volumen de notificaciones

Las notificaciones son eventos de transmisión que se originan en almacenes de datos y se envían a Google Cloud o puntos finales externos. Las notificaciones contienen nombres de recursos, metadatos de recursos o recursos completos, y se generan según la configuración proporcionada por el usuario. De forma predeterminada, todas las notificaciones son del tipo "Notificaciones estándar".

Los siguientes precios son por 1 millón de notificaciones al mes:

Por ejemplo, las notificaciones de Pub/Sub enviadas a un tema de Pub/Sub adjunto a un almacén de datos son notificaciones estándar.

Almacenamiento de datos DICOM

Los datos DICOM almacenados sin procesar en todas las regiones utilizan almacenamiento de blobs. Los metadatos de búsqueda de las imágenes DICOM ingresadas (como las etiquetas DICOM) se conservan y se facturan como parte del almacenamiento estructurado.

Los precios del almacenamiento de blobs se basan en la cantidad de bytes no estructurados o BLOB que se ingieren y almacenan, así como en la clase de almacenamiento utilizada. La siguiente tabla enumera las diferentes clases de almacenamiento disponibles para almacenar datos DICOM sin procesar y su duración mínima de almacenamiento:

La siguiente tabla muestra los cargos en reposo aplicables al usar almacenamiento Nearline, Coldline y Archive para almacenar datos DICOM en la API de Cloud Healthcare. Estos cargos se aplican a todas las regiones.

Los cargos para la clase de almacenamiento estándar se enumeran como cargos de almacenamiento de blobs para diferentes regiones en la tabla de almacenamiento de datos .

Eliminación anticipada de datos DICOM

Se aplica un cargo por eliminación anticipada al eliminar, sobrescribir o reescribir un objeto DICOM. Un ejemplo de reescritura es cuando se cambia la clase de almacenamiento de un objeto. El cargo por eliminación anticipada es igual al importe que se habría cobrado si el objeto hubiera permanecido en su estado original durante el tiempo mínimo.

Consideremos el siguiente ejemplo:

• Almacena 1000 GB de objetos DICOM con la clase de almacenamiento Coldline. Para el almacenamiento Coldline, el precio por GB al mes es de $0.01. Considerando un mes de 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, eliminas todos los datos del almacén. Dado que el almacenamiento en Coldline tiene una duración mínima de 90 días, se te cobra como si el objeto hubiera estado almacenado durante ese periodo. A continuación, el desglose del cargo:

  • El costo normal de almacenamiento en reposo asociado con los 60 días que sus datos permanecieron en el depósito:

     $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 de 90 días de los datos:

     ($0.01/GB/month * 1 day / 30 days) * 1,000 GB * 30 days = $10 

• Al sumar los dos componentes del cargo, el costo total de almacenamiento de sus datos DICOM durante 60 días en lugar de 90 es de $30. Este es el mismo costo que habría pagado si hubiera almacenado sus datos DICOM durante el período mínimo de almacenamiento de 90 días y los hubiera eliminado al final del día 90.

Recuperación de datos DICOM

Se aplica una tarifa de recuperación al leer, copiar, mover o reescribir datos de objetos o metadatos almacenados en almacenamiento Nearline, Coldline o Archive. Este costo se suma a cualquier cargo de red asociado con la lectura de los datos.

La siguiente tabla muestra las tasas de recuperación para cada clase de almacenamiento:

Por cada recuperación en almacenamiento Nearline, almacenamiento Coldline o almacenamiento de archivo, se aplica un cargo adicional por solicitud compleja .

Operaciones ETL

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

• Lote de exportación
• Exportar streaming
• Evaluar lote
• Transcodificar DICOM

El volumen total de datos se suma para todos los servicios durante cada período de facturación. La siguiente tabla muestra los costos por GB para cada operación ETL:

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 factura cuando se solicita una instancia DICOM con una transfer-syntax diferente a la utilizada para la carga. Esto puede ocurrir con las solicitudes de recuperación de transacciones y de exportación masiva. Para obtener más información, consulte la sección "Recuperar transacción" en la declaración de conformidad con DICOM .

Al exportar al almacenamiento en la nube:

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

Al exportar a BigQuery:

• El volumen de datos DICOM se basa en los metadatos DICOM almacenados.
• El volumen de datos FHIR se basa en el recurso completo.

Tanto para DICOM como para FHIR, la medición utilizada se basa en la cantidad de bytes de búfer de protocolo transferidos.

Al transcodificar, el volumen de datos se basa en el tamaño de entrada de los datos en lugar del tamaño de salida o el tamaño intermedio máximo.

La siguiente tabla enumera las operaciones para cada tipo de categoría ETL:

Operaciones de desidentificación

Las operaciones de desidentificación se facturan en función del volumen de datos procesados ​​en tres suboperaciones:

• Inspección : se realiza en texto libre o imágenes para descubrir instancias de datos confidenciales.
• Transformación : incluye la redacción, el reemplazo, el hash o los cambios realizados a datos confidenciales como parte del proceso de desidentificación.
• Procesamiento : Cubre el costo base de la operación.

La cantidad de datos en cada suboperación depende de cómo esté configurada la operación principal.

Los cargos de facturación se resuelven mensualmente según la cantidad de unidades procesadas y el nivel al que pertenecen. Hay tres tipos de unidades, y cada tipo de unidad 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 utilizados para la inspección. Por ejemplo, inspeccionar 1 GB de datos con 10 infoTypes equivale a 10 gigaunidades (GU) de inspección. Por defecto, se utiliza un mínimo de 10 infoTypes para cada inspección, lo que significa que el cargo mínimo es de 10 kilounidades por operación de desidentificación.
• Unidades de transformación : Basadas en la cantidad de bytes transformados, donde 1 GB de datos equivale a 1 GU de transformación.
• Unidades de procesamiento : según el número total de bytes en la operación de desidentificación.

Cada tipo de unidad tiene un precio en su propia categoría como se detalla en las tablas anteriores:

• Los costos de inspección y transformación se expresan en rangos de gigaunidades (UG) y teraunidades (TU). Dentro de cada rango, el precio indicado es por UG.

  Por ejemplo, para un ciclo de facturación determinado:

  • Hasta 1 GU de inspección es gratuita.
  • Las unidades de inspección se facturan a $0,20 por la cantidad de unidades entre 1 TU y 10 TU.

• Los costos de procesamiento se expresan en rangos de gigabytes (GB) y terabytes (TB). Dentro de cada rango, el precio indicado es por GB.

  Por ejemplo, para un ciclo de facturación determinado:

  • Hasta 1 GB de almacenamiento estructurado, el procesamiento por lotes es gratuito.
  • Las unidades de almacenamiento estructurado y procesamiento por lotes se facturan a $0,50 por la cantidad de unidades entre 1 TB y 10 TB.

Los cargos por las suboperaciones dependen de si se trabaja con datos FHIR o DICOM:

FHIR:

• Se aplican cargos por inspección y transformación por la parte del recurso que se inspecciona en busca de datos confidenciales y posteriormente se transforma.
• Los cargos de procesamiento se aplican a todo el recurso a la tarifa por lotes de almacenamiento estructurado.

DICOM:

• Se aplican cargos de inspección a la parte del recurso (incluidos los datos de píxeles) que se inspecciona en busca de datos confidenciales.
• Los cargos por transformación se aplican a la parte del recurso (excluyendo los datos de píxeles) que se transforma tras la inspección. Si se realiza la redacción de la imagen, los cargos solo se aplican a la inspección, no a la transformación. Para obtener información sobre cómo funciona esto en la práctica, consulte el ejemplo de desidentificación DICOM .
• Los cargos por procesamiento se aplican a todo el recurso y se calculan en función del tamaño de la instancia DICOM original. Los cargos por procesamiento de metadatos DICOM se basan en la categoría de almacenamiento estructurado por lotes. Los cargos por procesamiento de datos de píxeles se basan en la categoría de almacenamiento de blobs por lotes.

Control de acceso FHIR

El precio de la función de control de acceso FHIR se basa en lo siguiente:

• El número de consentimientos de pacientes y políticas de administración activos.
• Las solicitudes FHIR que contienen el encabezado X-Consent-Scope .
• Las operaciones de reindexación desencadenadas por la aplicación de políticas.

Los clientes pueden habilitar la función opcionalmente activando ConsentConfig . Si no se habilita, la función se desactivará y no se aplicará ningún cargo.

Políticas de consentimiento activo

Se le cobrará mensualmente por los consentimientos de pacientes y las políticas administrativas vigentes. Una política activa cumple con todos estos criterios:

• Su estado se establece como active .
• Se ha aplicado mediante el método fhirStores.applyConsents o fhirStores.applyAdminConsents .

El precio por política de consentimiento se prorratea. Si una política de consentimiento se elimina o se desactiva, la API de Cloud Healthcare solo cobrará por el periodo en que estuvo activa.

Solicitudes con alcance de consentimiento

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

Para obtener detalles sobre los precios de cada tipo de solicitud, consulte Volumen de solicitudes .

Costos de reindexación

Llamar a los métodos fhirStores.applyConsents o fhirStores.applyAdminConsents genera cargos. Se le cobrará una solicitud multioperación por cada recurso FHIR que se reindexe como resultado de estas llamadas.

También se le cobrará por la reindexación de FHIR cuando actualice los recursos base del compartimento conforme a políticas en cascada aplicadas.

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

Detener los cargos por políticas de consentimiento

Para detener los cargos por una póliza de consentimiento, siga estos pasos:

1. Eliminar el recurso de política o cambiar su estado a inactive .
2. Vuelva a aplicar la política llamando al método fhirStores.applyConsents (para consentimientos de pacientes) o fhirStores.applyAdminConsents (para políticas de administrador).

Los recursos de FHIR tienen versiones. Si elimina un recurso de política sin volver a aplicarla, el acceso al recurso seguirá siendo obligatorio y se aplicarán cargos de facturación.

Los clientes también pueden detener los cargos desactivando la función de Control de Acceso de FHIR. Para ello, editen la Tienda FHIR y eliminen el campo ConsentConfig . Tengan en cuenta que al desactivar esta función, se detendrá la aplicación de la política de consentimiento.

Gestión del consentimiento y la privacidad

La API de administración de consentimiento se factura en función de la cantidad de recursos Consent que se administran y la cantidad de recursos UserDataMapping evaluados durante las operaciones de determinación de acceso por lotes.

La cantidad de consentimientos gestionados corresponde al promedio de objetos Consent ACTIVE y DRAFT durante el período de facturación. Los consentimientos REVOKED , REJECTED y ARCHIVED no se facturan.

Para el método de determinación de acceso por lotes projects.locations.datasets.consentStores.queryAccessibleData , la cantidad de recursos UserDataMapping evaluados es la cantidad total de recursos UserDataMapping en el almacén de consentimiento cuando se realiza una solicitud.

El almacenamiento y las operaciones de la API de Gestión de Consentimiento se facturan como se describe en Almacenamiento de datos y Volumen de solicitudes . Todo el almacenamiento del almacén de consentimiento se factura como Almacenamiento Estructurado, excepto los bytes no estructurados o BLOB que se almacenan dentro de un consentArtifact . Todas las operaciones de consentimiento son solicitudes estándar, excepto EvaluateUserConsent , que se factura como una solicitud compleja, y QueryAccessibleData , que se factura como se describe en la sección anterior. Durante el período promocional actual, no se le cobrará por el almacenamiento ni por las operaciones estándar/complejas.

Utilización de la red

Transferencia de datos entrantes

La transferencia de datos entrantes siempre es gratuita.

Transferencia de datos entre regiones

No hay ningún cargo por la transferencia de datos cuando la solicitud de transferencia se origina en la API de Cloud Healthcare y se dirige a cualquier servicio en Google Cloudque está en la misma región.

Los siguientes precios se aplican a transferencias de datos entre regiones o desde un grupo multirregional a una sola región del mismo continente y viceversa. Los precios son por GB al mes.

Uso general de la red

El uso general de la red se aplica a los datos que existen Google CloudLa API de Cloud Healthcare utiliza la Transferencia de Datos Premium por Internet, cuyos precios se muestran a continuación. Los precios de transferencia de datos son consistentes con Google Cloud Precios de red: Nivel Premium.

Los precios son por GB por mes.

Ejemplos de precios

Ejemplo de precios de FHIR

Supongamos que una aplicación basada en FHIR está alojada en Google Cloud En europe-west2 se generan 25 000 000 de solicitudes al mes, con un promedio de 4 kB por recurso. Cinco millones de estas solicitudes son búsquedas FHIR, por lo que se facturan como solicitudes complejas. Durante un mes, el almacén FHIR almacena un promedio de 1 TB de datos, incluyendo la sobrecarga de copias de seguridad e indexación.

La siguiente tabla muestra el patrón de uso en el mes dado:

Su factura del mes se calcula de la siguiente manera:

Ejemplo de precios DICOM

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

• 1.000 estudios de rayos X (~10 MB cada uno)
• 300 estudios de TC (~300 MB cada uno)
• 200 estudios de resonancia magnética (~300 MB cada uno)

El centro de imágenes conserva las imágenes durante un año, lo que supone un almacenamiento mensual promedio de 160 GB y 6,4 GB adicionales de almacenamiento de metaetiquetas analizadas, incluyendo los gastos generales. Para estimar el número de solicitudes realizadas, supongamos que cada estudio de radiografía consta de una sola imagen y que cada estudio de tomografía computarizada (TC) y resonancia magnética consta de 300 imágenes.

Además, supongamos lo siguiente:

• Para cada estudio, se realizan dos solicitudes de búsqueda de metadatos (transacción de búsqueda DICOMweb) para un total de 2*(1000 + 300 + 200) = 3000 solicitudes complejas.
• Cada imagen se recupera dos veces, para un total de 2*(1000 + 300 * 300 + 200 * 300) = 302 000 solicitudes de operaciones múltiples.
• Las imágenes deben transcodificarse cada vez que se solicitan, para un total de 2*160 GB = 320 GB transcodificados.

La siguiente tabla muestra el patrón de uso en el mes dado:

Su factura del mes se calcula de la siguiente manera:

Ejemplo de precios de HL7v2

Supongamos que un almacén HL7v2 en us-central1 está conectado a un centro de atención médica que genera 10 000 000 de mensajes al mes mediante un adaptador MLLP local. Como resultado, se enviarán 10 000 000 de solicitudes de ingesta a la API de Cloud Healthcare. En respuesta, se generan 10 000 000 de mensajes de confirmación (pero no se almacenan en el almacén HL7v2).

Durante un período de un mes, el almacén HL7v2 persiste un promedio de 80 GB de datos, incluidos los gastos generales de copia de seguridad e indexación.

La siguiente tabla muestra el patrón de uso en el mes dado:

Su factura del mes se calcula de la siguiente manera:

Ejemplo de desidentificación de FHIR

Supongamos que desidentifica 10 GB de datos FHIR. Durante la desidentificación, se inspeccionará el 10 % (1 GB) de los datos, de los cuales el 10 % (0,1 GB) se transformará. Se utilizan 15 infoTypes por defecto.

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

Ejemplo de desidentificación DICOM

Supongamos que se desidentifican 10 GB de datos DICOM. El 90 % (9 GB) de los datos consiste en imágenes DICOM. Se inspeccionan todas las imágenes y el 10 % (0,9 GB) se transforma. Se utiliza un valor predeterminado de 16 infoTypes.

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

Ejemplos de volumen de notificaciones

Supongamos que una aplicación basada en FHIR genera 1,6 millones de notificaciones de Pub/Sub al mes. Dado que las notificaciones se calculan por millón, su factura por notificaciones se calcula de la siguiente manera:

API de lenguaje natural para atención médica

La API de Lenguaje Natural para el Cuidado de la Salud ofrece un conjunto de funciones para extraer información sanitaria de textos médicos. Solo paga por las funciones que utiliza, sin compromisos iniciales. La API admite las siguientes funciones:

Registros de texto de precios

Su uso de la API de Lenguaje Natural para el Cuidado de la Salud se calcula en función del volumen mensual de registros de texto . Un registro de texto contiene 1000 caracteres . Los caracteres son Unicode (incluidos los espacios en blanco y cualquier carácter de marcado, como etiquetas HTML o XML).

Los cargos por registros de texto se clasifican en los siguientes niveles:

• Gratis (1 registro de texto - 2500 registros de texto)
• Volumen bajo (2500 registros de texto - 1 millón de registros de texto)
• Alto volumen (más de 1.000.000 de registros de texto)

Los costos de la API de Lenguaje Natural para el Cuidado de la Salud se calculan mensualmente en función de las funciones utilizadas y la cantidad de registros de texto evaluados con ellas. La siguiente tabla muestra el precio por registro de texto durante un mes de facturación. Los precios del plan de bajo volumen solo se aplican a los registros de texto evaluados que exceden el nivel gratuito. Los precios del plan de alto volumen solo se aplican a los registros de texto evaluados que exceden el nivel de bajo volumen.

Los registros de texto se facturan en incrementos de 0,1 registros de texto, o unidades. Por ejemplo, si ha superado el nivel gratuito mensual y envía una solicitud de 800 caracteres, se le cobrarán 0,8 registros de texto. El coste total sería de 0,08 $, calculado de la siguiente manera: 0.8 * $0.10 .

Si el número de caracteres en una solicitud no es múltiplo de 100, el recuento de caracteres se redondea hacia arriba al siguiente incremento de 100.

La siguiente tabla muestra un ejemplo del precio de tres solicitudes enviadas a la API de Lenguaje Natural para Salud en el nivel de bajo volumen (suponiendo que ya se han enviado 2500 registros de texto y se ha agotado el nivel gratuito). Las solicitudes contienen 8000, 15 000 y 6000 caracteres.

La siguiente tabla muestra un ejemplo del precio de tres solicitudes enviadas a la API de Lenguaje Natural para el Sector Salud. Las solicitudes contienen 150 000 000 (150 millones), 800 000 000 (800 millones) y 600 000 000 (600 millones) de caracteres, lo que suma un total de 1 550 000 000 (1550 millones) de caracteres o 1 550 000 registros de texto.

Costos de Google Cloud Platform

Si almacena texto para analizarlo en el almacenamiento en la nube o utiliza otrosGoogle Cloud recursos en conjunto con la API de lenguaje natural para atención médica, como la API de atención médica en la nube o las instancias de Compute Engine, también se le facturará por el uso de esos servicios. Consulte la Google Cloud Calculadora de precios para determinar otros costos según las tarifas actuales.

Para ver su estado de facturación actual en el Google Cloud Para consultar la consola, incluyendo el uso y su factura actual, consulte la página de Facturación . Para obtener más información sobre cómo administrar su cuenta, consulte la Documentación de Facturación en la Nube o el Soporte de Facturación y Pagos .

¿Qué sigue?

• Comience a utilizar la API de Cloud Healthcare siguiendo las instrucciones de inicio rápido .
• Explore las guías prácticas de la API de Cloud Healthcare disponibles.
• Lea la documentación de la API de Cloud Healthcare .
• Pruebe la calculadora de precios .
• Obtenga información sobre las soluciones API y los casos de uso de Cloud Healthcare .