Opciones de importación de FHIR

En esta página, se describen las opciones para almacenar lotes grandes 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 desde Cloud Storage a la API de Cloud Healthcare. El método tiene el mejor rendimiento cuando se cargan datos en un almacén de FHIR vacío sin interferencias de otras aplicaciones.

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

Ten en cuenta las siguientes propiedades del método fhirStores.import cuando decidas si debes usarlo. 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 Administra recursos de FHIR con paquetes de FHIR.

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

  • El uso de fhirStores.import quita las complejidades de ejecutar paquetes de FHIR grandes, como los siguientes:

    • División de paquetes de FHIR en paquetes más pequeños
    • Cómo administrar varias programaciones de paquetes
    • Administración de errores transitorios que se pueden volver a intentar a nivel del recurso o del paquete

    A menudo, estas ventajas superan las 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 ocurre a menudo 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 falla la importación de 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 debes usarlo para almacenar recursos de FHIR:

  • Si es demasiado costoso, ya sea en términos de costos de facturación o ancho de banda de red, crear una canalización que almacene datos en Cloud Storage y, luego, importe los datos con fhirStores.import, usa fhir.executeBundle.
  • Cuando se ejecutan paquetes, se puede aplicar la integridad de la transacción.
  • Cuando se ejecutan paquetes, se puede aplicar la validación de perfiles de FHIR.
  • Si necesitas enviar notificaciones de Pub/Sub cuando se realizan 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 de FHIR con fhirStores.import.
  • Si la hora en la que se debe procesar un recurso de FHIR en particular está en segundos o minutos, usa fhir.executeBundle. Si la hora en la 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) existentes 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
    • Cómo abordar las fallas en un subconjunto de recursos de FHIR o en lotes completos

Cuándo no usar paquetes de FHIR

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

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

    Como resultado, apuntar a 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.

  • Es más probable que los paquetes de transacciones grandes tengan 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 alta capacidad de procesamiento de datos con paquetes por lotes, lo que te ayuda a evitar la contención de datos. Sin embargo, los paquetes por lotes no tienen capacidades de coherencia transaccional, como la integridad referencial.

  • Si un paquete es grande, incluso si es un paquete por lotes, es posible que veas una reducción de la capacidad de procesamiento de datos. Para obtener más información, consulta Evita paquetes de transacciones grandes.