Opciones de importación de FHIR

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

Importar recursos FHIR

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

Para llamar a fhirStores.import, consulta Importar y exportar recursos FHIR mediante Cloud Storage.

Ten en cuenta las siguientes propiedades del método fhirStores.import a la hora de decidir si lo vas a usar. Si fhirStores.import no es adecuado para tu aplicación, considera usar el método fhir.executeBundle para cargar datos. Para obtener información sobre cómo llamar a fhir.executeBundle, consulta Gestionar recursos FHIR mediante paquetes FHIR.

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

  • Al usar fhirStores.import, se eliminan las complejidades de ejecutar paquetes FHIR grandes, como las siguientes:

    • Dividir paquetes FHIR en paquetes más pequeños
    • Gestionar varias programaciones de paquetes
    • Gestionar errores transitorios que se pueden volver a intentar a nivel de recurso o paquete

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

  • Cada recurso de la entrada debe contener un ID proporcionado por el cliente. Cada recurso se almacena con el ID proporcionado, independientemente del ajuste enableUpdateCreate del almacén FHIR.

  • El proceso de importación no aplica la integridad referencial, independientemente de la configuración disableReferentialIntegrity del almacén FHIR. Si no se aplica la integridad referencial, puede importar recursos con interdependencias arbitrarias sin tener en cuenta la agrupación ni el orden. Si los datos de entrada contienen referencias no válidas o si no se pueden importar algunos recursos, el estado del almacén FHIR puede infringir la integridad referencial.

  • Si ya existe un recurso con un ID determinado en la tienda, se sobrescribe la versión más reciente del recurso sin crear una nueva versión histórica. La sobrescritura se produce independientemente del ajuste disableResourceVersioning del almacén FHIR. Si se producen errores transitorios durante la importación, un recurso importado correctamente podría sobrescribirse 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 contenido diferente. En ese caso, una vez completada la importación, la tienda contendrá exactamente un recurso con cada ID, pero las entradas duplicadas podrían contener cualquier versión del contenido. Por ejemplo, si importa un millón de recursos con el mismo ID, solo se escribirá un recurso en el almacén.

  • Los contadores de resultados de operaciones no contabilizan los IDs duplicados como errores. Cada recurso de la entrada se cuenta como un éxito. Esto podría dar lugar a que el recuento de éxitos sea mayor que el número de recursos del almacén FHIR. Esto suele ocurrir al importar datos organizados en paquetes producidos por Patient-everything, donde cada paquete contiene su propia copia de un recurso, como Practitioner, al que pueden hacer referencia muchos recursos Patient.

  • Si no se pueden importar algunos recursos, por ejemplo, debido a errores de análisis, no se revertirán los recursos que se hayan importado correctamente. Por ejemplo, si no se pueden importar 5 de 100 recursos, los 95 recursos restantes se importarán al almacén FHIR.

  • Cuando se usa 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 a los paquetes de transacciones o por lotes. A diferencia de fhir.executeBundle, los paquetes de transacciones no se ejecutan como una sola transacción y las referencias internas de los paquetes no se reescriben. El paquete se trata como una colección de recursos que se escriben tal como se proporcionan en Bundle.entry.resource, ignorando Bundle.entry.request. Por ejemplo, esto permite importar paquetes de resultados de búsqueda producidos por una búsqueda FHIR o una operación Patient-everything.

Usar paquetes FHIR

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

Cuándo usar paquetes FHIR

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

  • Si resulta demasiado caro, ya sea en términos de costes de facturación o de ancho de banda de la red, crear una canalización que almacene datos en Cloud Storage y, a continuación, importe los datos mediante fhirStores.import, utiliza fhir.executeBundle.
  • Al ejecutar paquetes, se puede aplicar la integridad de las transacciones.
  • Al ejecutar paquetes, se puede aplicar la validación de perfiles FHIR.
  • Si necesitas enviar notificaciones de Pub/Sub cuando se produzcan operaciones de creación, actualización o eliminación de FHIR, usa fhir.executeBundle. Las notificaciones de Pub/Sub no se envían cuando se importan recursos FHIR con fhirStores.import.
  • Si el momento en el que se debe procesar un recurso FHIR concreto es en segundos o minutos, usa fhir.executeBundle. Si el momento en el que se debe procesar un recurso FHIR concreto se mide en horas o días, usa fhirStores.import.
  • Si tu proyecto de Google Cloud tiene muchas operaciones de larga duración (OLD) que realizan otras tareas, es posible que obtengas un mejor rendimiento con fhir.executeBundle que con fhirStores.import.

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

    • Gestionar errores en bloque
    • Solucionar errores en un subconjunto de recursos FHIR o en lotes completos

Cuándo no usar paquetes FHIR

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

  • Los paquetes tienen la misma cuota y facturación que las operaciones que se realizan 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 aplicadas al paquete son las mismas que si esas operaciones se ejecutaran de forma independiente.

    Por lo tanto, el objetivo de reducir los límites de las cuotas y los costes de las operaciones de FHIR no es motivo para usar paquetes en lugar de fhirStores.import.

  • Es más probable que los paquetes de transacciones grandes tengan conflictos de transacciones, lo que provoca contención de datos y errores en las operaciones. Para obtener información sobre cómo se pueden producir estos problemas y cómo solucionarlos, consulta el artículo Evitar errores 429 Resource Exhausted operation_too_costly.

  • Puedes conseguir y mantener un alto rendimiento de datos mediante paquetes por lotes, lo que te ayuda a evitar la contención de datos. Sin embargo, los paquetes por lotes no tienen funciones de coherencia transaccional, como la integridad referencial.

  • Si un paquete es grande, aunque sea un paquete por lotes, es posible que se reduzca el rendimiento de los datos. Para obtener más información, consulta Evitar paquetes de transacciones grandes.