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 enfhir.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, comoPractitioner
, 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 conBundle.type
dehistory
. 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 defhir.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 enBundle.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ónPatient-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
, usafhir.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 mediantefhirStores.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, usafhirStores.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 defhirStores.import
. Si la aplicación que administra la operación
fhirStores.import
no tiene una buena estrategia para lo siguiente, usafhir.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 operacionesGET
y 1 operaciónDELETE
, 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.