Cuotas y límites

La API de Cloud Healthcare aplica límites al uso de los recursos por diversos motivos. Por ejemplo, las cuotas protegen a la comunidad de usuarios de Google Cloud a través de la prevención de los aumentos imprevistos en el uso. Google Cloud también ofrece cuotas de prueba gratuita que proporcionan acceso limitado a los usuarios que están explorando Google Cloud, incluida la API de Cloud Healthcare.

Las cuotas de la API de Cloud Healthcare se aplican por proyecto, ya sea por región o por varias regiones. Si se agota la cuota en una región, eso no afecta el uso de la API de Cloud Healthcare en otras regiones.

Verifica tus cuotas y el uso

Las cuotas son límites que se aplican al almacenamiento (límites de entrada) y a las operaciones.

Puedes revisar la cuota disponible para los recursos de tu proyecto en la página Cuotas de la consola de Google Cloud .

Si solo deseas ver las cuotas de la API de Cloud Healthcare, selecciona Servicio en la lista desplegable Filtrar tabla y, luego, selecciona API de Cloud Healthcare.

No todos los proyectos tienen las mismas cuotas. A medida que tu uso de la API de Cloud Healthcare aumenta con el tiempo, tus cuotas también pueden aumentar. Si prevés un aumento considerable en el uso, puedes solicitar ajustes en la cuota de forma proactiva en la página Cuotas de laGoogle Cloud consola. No se aplican cargos por solicitar aumentos de cuota. Tus costos aumentan solo si usas más recursos.

Límites de recursos

La API de Cloud Healthcare limita el tamaño del contenido de las solicitudes (por ejemplo, el tamaño de una imagen de rayos X en una solicitud de DICOM). No puedes solicitar cambios a los límites de recursos; sin embargo, en algunos casos, puedes usar una operación de importación para importar contenido que supere el límite de recursos.

Se aplican los siguientes límites de recursos y están sujetos a cambios.

Modalidad Límite de tamaño de solicitud
DICOM
  • Transacción de almacenamiento: Ilimitado; todos los demás métodos tienen un límite de 10 MB.
  • Transacción de almacenamiento o transacción de recuperación: Se agota el tiempo de espera si la operación tarda más de 30 minutos.
  • Los métodos de transacción de búsqueda tienen una compensación máxima de 1,000,000 y un límite máximo de 5,000 para los estudios o las series, y de 50,000 para las instancias.
  • Desidentificación: No se pueden procesar archivos de DICOM que sean de más de 1 GB si se trata de ocultamiento de píxeles. Si los Datos del Píxel están comprimidos, su tamaño sin comprimir no puede superar los 2 GB. El tamaño sin comprimir se puede calcular con las etiquetas de DICOM de la siguiente manera: NumberOfFrames * Rows * Columns * SamplesPerPixel * BitsAllocated / 8.
  • Los archivos DICOM transferidos tienen un límite de 4 GB por etiqueta. Este límite no se aplica a los valores con una longitud indefinida.
  • Cuando se transcodifican datos de DICOM, el tamaño máximo de archivo es de 1 GB, y el de marco es de 150 MB.
  • Cuando se aplica el parámetro de consulta viewport en los recursos renderizados, el tamaño máximo del fotograma es de 50 MB y la dimensión máxima (ancho o alto) es de 10,000 píxeles.
  • dicomStores.import: El tamaño máximo de archivo es de 100 GB.
FHIR
  • fhir.executeBundle: 50 MB Es posible que encuentres limitaciones según la cantidad de entradas en un paquete. Para obtener más información, consulta Límites de tamaño de executeBundle de FHIR.
  • fhir.Binary-create: 1 GB
  • fhir.Binary-update: 1 GB
  • Todos los demás métodos: 10 MB Este límite se aplica a la representación interna del recurso, no al tamaño de la carga útil JSON que envías. Un recurso que cumple con este límite puede tener una carga útil de JSON superior a 10 MB.
HL7v2 Tamaño del campo data codificado en base64: 10 MB

Si intentas procesar contenido más grande que el límite del recurso asociado, se muestra un error.

Límites de tamaño de executeBundle de FHIR

Puedes usar el método fhir.executeBundle para realizar varias operaciones de FHIR en una sola solicitud a la API. La cantidad de operaciones depende de la cantidad de entradas en un lote o paquete de transacciones. Este enfoque es más eficiente que realizar llamadas a la API individuales para cada operación.

Los tiempos de procesamiento de las solicitudes de fhir.executeBundle aumentan con la cantidad de entradas del paquete. Factores como la contención de recursos (por ejemplo, actualizar el mismo recurso como parte de muchos paquetes de transacciones en paralelo) también pueden afectar el rendimiento. Para ver ejemplos de cuándo puede ocurrir la contención de recursos y cómo evitar que cause errores, consulta Prácticas recomendadas para el procesamiento de datos. Los paquetes grandes, en especial los que superan las 1,000 entradas, pueden agotar el tiempo de espera y no completarse.

Para garantizar un procesamiento exitoso y oportuno, ten en cuenta estos límites cuando envíes tus solicitudes de fhir.executeBundle:

  • Paquetes de transacciones: Los paquetes que superan las 4,500 entradas se rechazan de inmediato para evitar tiempos de espera. Los paquetes de transacciones requieren que todas las operaciones se realicen correctamente.
  • Paquetes por lotes: No existe un límite de entrada específico, pero los paquetes más grandes aumentan el riesgo de que se agote el tiempo de espera. Los tiempos de espera pueden generar un éxito parcial, con solo algunas entradas procesadas.

Usa operaciones de importación para el contenido que supera el límite de recursos

Las operaciones de importación te permiten procesar el contenido que supera el límite de recursos asociado. El tamaño del contenido en una operación de importación está limitado solo por el Google Cloud tamaño máximo de almacenamiento de 5 TB para objetos individuales. Las operaciones de importación están sujetas a cuotas de almacenamiento que determinan cuánto tiempo tarda una operación de importación. Se recomienda que uses una operación de importación, por ejemplo, si quieres almacenar varias instancias de DICOM en un almacén DICOM y no quieres estar sujeto a los límites de tamaño de solicitud. En vez de subir las instancias con los métodos de Transacción de almacenamiento disponibles, puedes subirlas a un bucket de Cloud Storage y, luego, importarlas al almacén de DICOM.

Si deseas obtener instrucciones para importar datos de DICOM mediante una operación de importación, consulta cómo importar y exportar datos de DICOM.

Si deseas obtener instrucciones para importar recursos de FHIR mediante una operación de importación, consulta cómo importar y exportar recursos de FHIR.

Si deseas obtener instrucciones detalladas para importar mensajes HL7v2 con una operación de importación, consulta Importa mensajes HL7v2 desde Cloud Storage.

Solicita que se aplique un cambio a una cuota

Para solicitar que se modifique una cuota, debes tener el permiso serviceusage.quotas.update. Este permiso se incluye de forma predeterminada en las funciones predefinidas de Propietario, Editor y Administrador de cuotas.

  1. Ve a la página Cuotas.

    Ir a Cuotas

  2. En la página Cuotas, selecciona las cuotas que deseas cambiar. Si solo deseas ver las cuotas de la API de Cloud Healthcare, selecciona Servicio en la lista desplegable Filtrar tabla y, luego, selecciona API de Cloud Healthcare.

  3. Marca las casillas de las cuotas que quieres editar.

  4. Haz clic en el botón Editar cuotas en la parte superior de la página.

  5. Completa el formulario y haz clic en Siguiente.

  6. Ingresa los límites que deseas solicitar y haz clic en Siguiente.

  7. Haz clic en Enviar solicitud.

Las solicitudes de disminución de cuota se rechazan de forma predeterminada. Si deseas reducir la cuota, responde el correo electrónico de asistencia para explicar tus requisitos. Un representante del equipo de asistencia responderá a tu solicitud.

Recibirás una respuesta del equipo de la API de Cloud Healthcare en un plazo de 24 a 48 horas tras el envío de tu solicitud.

Planifica tu solicitud de recursos adicionales con al menos un par de días de anticipación a fin de asegurarte de que haya tiempo suficiente para completarla.

Solicitudes de cuota de ubicación

Puedes solicitar un aumento de la cuota para la API de Cloud Healthcare en una región específica o en una ubicación multirregional.

Para solicitar un aumento de cuota en una sola región, especifícala en la solicitud.

Para solicitar un aumento de cuota en una ubicación multirregional, sigue estos pasos:

  • Si solicitas un aumento de cuota en la multirregión de us, indica en tu solicitud que la cuota es para la "metaregión de EE.UU.".
  • Para solicitar un aumento de cuota en la multirregión de eu, indica en tu solicitud que la cuota es para la "metaregión de la UE".

Límites de cuota

En las siguientes secciones, se describen las cuotas asociadas con los almacenes de datos y las operaciones de la API de Cloud Healthcare.

Cuotas de DICOM

En la siguiente tabla, se describen las cuotas de la API de Cloud Healthcare asociadas con los almacenes y las operaciones de DICOM.

Nombre de la métrica Nombre visible Descripción
dicomweb_ops Cantidad de operaciones de DICOMweb por minuto y por región Incluye los siguientes métodos:
  • Todos los métodos projects.locations.datasets.dicomStores.studies en v1beta1 y v1
  • Todos los métodos projects.locations.datasets.dicomStores.studies.series en v1beta1 y v1
  • Todos los métodos projects.locations.datasets.dicomStores.studies.series.instances en v1beta1 y v1
  • Todos los métodos projects.locations.datasets.dicomStores.studies.series.instances.frames en v1beta1 y v1
dicom_structured_storage_bytes Ingreso de almacenamiento de DICOM estructurado en bytes por minuto y por región Son bytes estructurados, en forma de etiquetas DICOM y metadatos relacionados, que se envían a la API de Cloud Healthcare durante el procesamiento de las operaciones de dicomweb_ops.
dicom_store_ops Cantidad de operaciones del almacén de DICOM por minuto y por región Operaciones en el almacén de DICOM, no en los datos de DICOM. Incluye los siguientes métodos:
dicom_store_lro_ops Cantidad de operaciones de larga duración del almacén de DICOM por minuto y por región Operaciones en el almacén de DICOM, no en los datos de DICOM, que devuelven una operación de larga duración. Incluye los siguientes métodos:
dicom_structured_storage_operations_bytes Ingreso de almacenamiento de DICOM estructurado para operaciones de larga duración en bytes por minuto y por región Son bytes estructurados, en forma de etiquetas DICOM y metadatos relacionados, que se envían a la API de Cloud Healthcare durante el procesamiento de las operaciones de dicom_store_lro_ops.

Cuotas de FHIR

En la siguiente tabla, se describen las cuotas de la API de Cloud Healthcare asociadas con los almacenes de FHIR y las operaciones de FHIR.

Nombre de la métrica Nombre visible Descripción
fhir_read_ops Cantidad de operaciones de lectura de FHIR por minuto y por región Se mide en unidades, donde una unidad es una solicitud de lectura en un recurso de FHIR individual.

Incluye los siguientes métodos:

v1beta1: v1:
fhir_write_ops Cantidad de operaciones de escritura de FHIR por minuto y por región Se mide en unidades, donde una unidad equivale a una solicitud de creación, actualización o eliminación en un recurso FHIR individual.

Incluye los siguientes métodos:

v1beta1: v1:
fhir_search_ops Cantidad de operaciones de búsqueda de FHIR por minuto y por región Se mide en unidades, donde una unidad es una solicitud de búsqueda en un tipo de recurso de FHIR en la que la búsqueda no requiere resolver referencias, excepto cuando se usa _include. Por ejemplo, una búsqueda de Observation?subject:Patient.identifier=system|value consume dos unidades de cuota de fhir_search_ops porque requiere dos búsquedas, una en el recurso Observation y otra en el recurso Patient, con subject como referencia.

Incluye los siguientes métodos:

v1beta1: v1:
fhir_storage_egress_bytes Egresos de almacenamiento de FHIR en bytes por minuto y por región Se mide en unidades, donde una unidad equivale a un byte que la API de Cloud Healthcare lee del almacenamiento mientras procesa las operaciones fhir_read_ops, fhir_write_ops y fhir_search_ops.
fhir_storage_bytes Ingreso de almacenamiento de FHIR en bytes por minuto y por región Son los bytes enviados a la API de Cloud Healthcare durante el procesamiento de las operaciones de fhir_write_ops.
fhir_store_ops Cantidad de operaciones del almacén de FHIR por minuto y por región Operaciones en el almacén de FHIR, no en los datos de FHIR.

Incluye los siguientes métodos:
fhir_store_lro_ops Cantidad de operaciones de larga duración del almacén de FHIR por minuto y por región Operaciones en el almacén de FHIR, no en los datos de FHIR, que devuelven una operación de larga duración.

Incluye los siguientes métodos:
fhir_storage_operations_bytes Ingreso de almacenamiento de FHIR para operaciones de larga duración en bytes por minuto y por región Son los bytes enviados a la API de Cloud Healthcare durante el procesamiento de las operaciones de fhir_store_lro_ops.

Una sola solicitud puede consumir varias unidades de cuota. Por ejemplo, una solicitud de búsqueda de GET que usa Observation?subject:Patient.identifier=system|value como parámetro de búsqueda consume dos unidades de cuota de fhir_search_ops. Se realizan dos operaciones de búsqueda, una en el recurso Observation y otra en el recurso Patient, con subject como referencia.

Si una solicitud de borrado condicional que usa Observation?status=canceled como criterio de búsqueda busca y borra seis recursos de Observation, se consumen las siguientes unidades de cuota:

  • Una unidad de cuota de fhir_search_ops, ya que la solicitud de búsqueda de GET solo se realiza en un tipo de recurso de FHIR, el recurso Observation. La solicitud devuelve todos los recursos de Observation que coinciden con los criterios de búsqueda.
  • Seis unidades de cuota de fhir_write_ops, ya que hay un total de seis operaciones de DELETE en los recursos de Observation borrados.

Consumo de cuota de ejecución de paquete

Para enviar una solicitud de paquete de ejecución, independientemente de la cuota que consuma la solicitud, tu proyectoGoogle Cloud debe tener al menos una unidad disponible para cada una de las siguientes cuotas:

  • fhir_read_ops
  • fhir_write_ops
  • fhir_search_ops

Si estas cuotas no están disponibles, falla la solicitud de ejecución del paquete.

Por ejemplo, si envías una solicitud fhir.executeBundle con un paquete de transacción que contiene 100 operaciones POST, cada una de las cuales crea un recurso de FHIR, la API de Cloud Healthcare primero verifica que haya al menos una unidad de cuota disponible para fhir_read_ops, fhir_write_ops y fhir_search_ops. Si la verificación se realiza correctamente, la API de Cloud Healthcare ejecuta el paquete y crea los recursos de FHIR, que consumen un total de 100 unidades de cuota de fhir_write_ops.

Considera el siguiente paquete de transacciones, que usa una referencia condicional para crear un recurso de Observation si existe el reference:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "request": {
        "method": "POST",
        "url": "Observation"
      },
      "resource": {
        "resourceType": "Observation",
        "subject": {
          "reference": "Patient?identifier=a1b2c3d4e5"
        }
      }
    }
  ]
}

Cuando ejecutas el paquete, la API de Cloud Healthcare primero verifica que haya al menos una unidad de cuota disponible para fhir_read_ops, fhir_write_ops y fhir_search_ops. Si la verificación se realiza correctamente, la API de Cloud Healthcare ejecuta el paquete. Se consumen las siguientes unidades de cuota:

  • Un fhir_write_ops para crear el nuevo recurso de Observation.
  • Una fhir_search_ops, porque se realiza una sola operación de búsqueda en la referencia Patient?identifier=a1b2c3d4e5.

Prácticas recomendadas

Para conocer las prácticas recomendadas para administrar la cuota de la API de Cloud Healthcare, consulta Prácticas recomendadas para la administración de cuotas.