Opciones de importación de FHIR

En esta página, se describen opciones para almacenar grandes lotes de datos de FHIR en la API de Cloud Healthcare.

Importa recursos de FHIR

Usa el método fhirStores.import para cargar recursos de FHIR de Cloud Storage a la API de Cloud Healthcare. El método funciona mejor cuando se cargan datos en un almacén de FHIR vacío sin interferencia de otras aplicaciones.

Para llamar a fhirStores.import, consulta Importa y exporta recursos de FHIR mediante Cloud Storage.

Ten en cuenta las siguientes propiedades del método fhirStores.import cuando decidas si usarlo o no. Si fhirStores.import no es adecuado para tu aplicación, considera usar el método fhir.executeBundle para cargar datos. Si quieres obtener información para llamar a fhir.executeBundle, consulta Administra recursos de FHIR mediante paquetes de FHIR.

  • El método fhirStores.import acepta paquetes cuyo tamaño supera el límite de 50 MB en fhir.executeBundle. Sin embargo, el tamaño de cada recurso individual dentro del paquete está limitado a 10 MB.

  • Usar fhirStores.import quita las complejidades de la ejecución de paquetes de FHIR grandes, como en los siguientes ejemplos:

    • Dividir paquetes de FHIR en paquetes más pequeños
    • Cómo administrar varias programaciones de paquetes
    • Administra errores transitorios que se pueden reintentar a nivel de recurso o paquete

    A menudo, estas ventajas superan las ventajas de usar paquetes.

  • Cada recurso en la entrada debe contener un ID proporcionado por el cliente. Cada recurso se almacena mediante el uso del ID proporcionado, sin importar la configuración enableUpdateCreate del almacén de FHIR.

  • El proceso de importación no aplica la integridad referencial de forma forzosa, sin importar la configuración disableReferentialIntegrity en el almacén de FHIR. No aplicar la integridad referencial te permite importar recursos con interdependencias arbitrarias sin considerar el agrupamiento ni el ordenamiento. Si los datos de entrada contienen referencias que no son válidas o si falla la importación de algunos recursos, puede que el estado del almacén de FHIR infrinja la integridad referencial.

  • Si ya existe un recurso con un ID determinado en el almacén, se reemplaza la versión más reciente del recurso sin crear una versión histórica nueva. El reemplazo se produce sin importar la configuración disableResourceVersioning del almacén de FHIR. Si se producen errores transitorios durante la importación, puede que se reemplace un recurso importado correctamente más de una vez.

  • La operación de importación es idempotente, a menos que los datos de entrada contengan varios recursos válidos con el mismo ID, pero con contenidos diferentes. En ese caso, después de que se completa la importación, el almacén contiene exactamente un recurso con cada ID, pero las entradas duplicadas pueden contener cualquier versión del contenido. Por ejemplo, mediante la importación de un millón de recursos con el mismo ID, se escribe solo un recurso en el almacén.

  • Los contadores de resultados de las operaciones no cuentan los ID duplicados como un error. Cada recurso en la entrada cuenta como una operación exitosa. Esto podría dar como resultado un conteo de operaciones exitosa que sea mayor que la cantidad de recursos del almacén de FHIR. Esto a menudo ocurre cuando se importan datos organizados en paquetes producidos por Patient-everything, en los que cada paquete contiene su propia copia de un recurso, como Practitioner, al que pueden hacer referencia muchos recursos de pacientes.

  • Si algunos recursos tienen fallas de importación, por ejemplo, debido a errores de análisis, los recursos importados correctamente no se revierten. Por ejemplo, si no se pueden importar 5 de 100 recursos, los 95 recursos restantes se importan al almacén de FHIR.

  • Cuando usas el formato BUNDLE, el método de importación rechaza los paquetes con Bundle.type de history. El método de importación no aplica la semántica de procesamiento de paquetes en los paquetes por lotes o de transacciones. A diferencia de fhir.executeBundle, los paquetes de transacciones no se ejecutan como una sola transacción, y no se reescriben las referencias internas de paquetes. El paquete se trata como una colección de recursos que se escribirán como se proporcionan en Bundle.entry.resource, lo que significa que se ignorará Bundle.entry.request. Por ejemplo, esto permite la importación de paquetes de conjuntos de búsqueda producidos por una búsqueda de FHIR o una operación Patient-everything.

Usa paquetes de FHIR

Consulta Paquetes de FHIR para obtener una descripción general de los paquetes de FHIR.

Cuándo usar paquetes de FHIR

Ten en cuenta las siguientes características y ventajas de usar el método fhir.executeBundle cuando decidas si usarlo para almacenar recursos de FHIR:

  • Si es demasiado costoso, en términos de costos de facturación o de ancho de banda de red, compilar una canalización que almacene datos en Cloud Storage y, luego, los importe mediante fhirStores.import, usa fhir.executeBundle.
  • Cuando se ejecutan paquetes, se puede aplicar la integridad de las transacciones.
  • Cuando se ejecutan paquetes, se puede aplicar la validación del perfil de FHIR.
  • Si necesitas enviar notificaciones de Pub/Sub cuando se llevan a cabo operaciones de creación, actualización o eliminación de FHIR, usa fhir.executeBundle. Las notificaciones de Pub/Sub no se envían cuando los recursos de FHIR se importan mediante fhirStores.import.
  • Si el momento en que se debe procesar un recurso de FHIR específico es en segundos o minutos, usa fhir.executeBundle. Si el momento en el que se debe procesar un recurso de FHIR en particular es en horas o días, usa fhirStores.import.
  • Si tu proyecto de Google Cloud tiene muchas operaciones de larga duración (LRO) que realizan otras tareas, es posible que observes un mejor rendimiento con fhir.executeBundle en lugar de fhirStores.import.

  • Si la aplicación que administra la operación fhirStores.import no tiene una buena estrategia para lo siguiente, usa fhir.executeBundle:

    • Cómo manejar errores masivos
    • Solución de fallas en un subconjunto de recursos de FHIR o lotes completos

Cuándo no usar paquetes de FHIR

Ten en cuenta las siguientes limitaciones de fhir.executeBundle cuando determines si usarlo para almacenar recursos de FHIR:

  • Los paquetes tienen la cuota y la facturación equivalentes que se aplican a las operaciones dentro del paquete como si las operaciones se ejecutaran fuera del paquete. Por ejemplo, si un paquete tiene 10 operaciones POST, 5 operaciones GET y 1 operación DELETE, la cuota y la facturación que se aplican al paquete son las mismas que si esas operaciones se ejecutaran de forma independiente.

    Como resultado, tratar de reducir los límites de cuota y los costos de operación de FHIR no son motivos para usar paquetes en lugar de fhirStores.import.

  • Los paquetes de transacciones grandes tienen más probabilidades de tener conflictos de transacciones, lo que genera contención de datos y operaciones fallidas. Para obtener información sobre cómo pueden ocurrir estos problemas y cómo resolverlos, consulta Cómo evitar errores 429 Resource Exhausted operation_too_costly.

  • Puedes lograr y mantener una capacidad de procesamiento de datos alta con los conjuntos por lotes, lo que te ayuda a evitar la contención de datos. Sin embargo, los paquetes por lotes no cuentan con capacidades de coherencia transaccional, como la integridad referencial.

  • Si un paquete es grande, incluso si es un paquete por lotes, es posible que observes una capacidad de procesamiento de datos reducida. Para obtener más información, consulta Cómo evitar paquetes de transacciones grandes.