Opções de importação de FHIR

Nesta página, descrevemos opções para armazenar grandes lotes de dados FHIR na API Cloud Healthcare.

Importar recursos de FHIR

Use o método fhirStores.import para carregar recursos FHIR do Cloud Storage na API Cloud Healthcare. O método funciona melhor ao carregar dados em um armazenamento FHIR vazio sem interferência de outros aplicativos.

Para chamar fhirStores.import, consulte Como importar e exportar recursos FHIR usando o Cloud Storage.

Considere as seguintes propriedades do método fhirStores.import ao decidir se vai usá-lo. Se fhirStores.import não for adequado para seu aplicativo, use o método fhir.executeBundle para carregar dados. Para informações sobre como chamar fhir.executeBundle, consulte Como gerenciar recursos FHIR usando pacotes FHIR.

  • O método fhirStores.import aceita pacotes maiores que o limite de 50 MB em fhir.executeBundle. No entanto, o tamanho de cada recurso individual no pacote é limitado a 10 MB.
  • Usar fhirStores.import elimina as complexidades da execução de grandes pacotes FHIR, como os seguintes:

    • Como dividir pacotes FHIR em pacotes menores
    • Como gerenciar várias programações de pacotes
    • Como gerenciar erros temporários que podem ser repetidos no nível do recurso ou do pacote

    Muitas vezes, essas vantagens superam as vantagens de usar pacotes.

  • Cada recurso na entrada precisa ter um ID fornecido pelo cliente. Cada recurso é armazenado usando o ID fornecido, independentemente da configuração enableUpdateCreate no armazenamento FHIR.

  • O processo de importação não impõe integridade referencial, independentemente da configuração disableReferentialIntegrity no armazenamento FHIR. Não aplicar a integridade referencial permite importar recursos com interdependências arbitrárias sem considerar o agrupamento ou a ordem. Se os dados de entrada tiverem referências inválidas ou se alguns recursos não forem importados, o estado do armazenamento FHIR poderá violar a integridade referencial.

  • Se um recurso com um determinado ID já existir no armazenamento, a versão mais recente do recurso será substituída sem criar uma nova versão histórica. A substituição ocorre independentemente da configuração disableResourceVersioning no armazenamento FHIR. Se ocorrerem falhas temporárias durante a importação, um recurso importado poderá ser substituído mais de uma vez.

  • A operação de importação é idempotente, a menos que os dados de entrada tenham vários recursos válidos com o mesmo ID, mas conteúdos diferentes. Nesse caso, depois de concluir a importação, o armazenamento passa a ter exatamente um recurso com cada ID, mas as entradas duplicadas podem ter qualquer versão do conteúdo. Por exemplo, importar um milhão de recursos com o mesmo ID grava apenas um recurso no armazenamento.

  • Os contadores de resultados da operação não contam IDs duplicados como um erro. Cada recurso na entrada conta como um sucesso. Isso pode resultar em uma contagem de sucesso maior do que o número de recursos no armazenamento FHIR. Isso geralmente ocorre na importação de dados organizados em pacotes produzidos por Patient-everything, em que cada pacote contém a própria cópia de um recurso, como Practitioner, que pode ser referenciada por muitos recursos de paciente.

  • Se alguns recursos não forem importados, como por causa de erros de análise, os recursos importados não serão revertidos. Por exemplo, se 5 de 100 recursos não forem importados, os 95 recursos restantes serão importados para o armazenamento FHIR.

  • Ao usar o formato BUNDLE, o método de importação rejeita pacotes com Bundle.type de history. O método de importação não aplica a semântica de processamento de pacotes para pacotes em lote ou de transações. Ao contrário de fhir.executeBundle, os pacotes de transações não são executados como uma única transação, e as referências internas do pacote não são regravadas. O pacote é tratado como uma coleção de recursos a serem gravados conforme fornecido em Bundle.entry.resource, ignorando Bundle.entry.request. Por exemplo, isso permite a importação de pacotes de conjuntos de pesquisa gerados por uma pesquisa FHIR ou uma operação Patient-everything.

Usar pacotes FHIR

Consulte Pacotes FHIR para ter uma visão geral dos pacotes FHIR.

Quando usar pacotes FHIR

Considere as seguintes características e vantagens de usar o método fhir.executeBundle ao decidir usá-lo para armazenar recursos FHIR:

  • Se for muito caro, em termos de custos de faturamento ou largura de banda da rede, criar um pipeline que armazene dados no Cloud Storage e importe os dados usando fhirStores.import, use fhir.executeBundle.
  • Ao executar pacotes, a integridade da transação pode ser aplicada.
  • Ao executar pacotes, é possível aplicar a validação do perfil FHIR.
  • Se você precisar enviar notificações do Pub/Sub quando ocorrerem operações de criação, atualização ou exclusão de FHIR, use fhir.executeBundle. As notificações do Pub/Sub não são enviadas quando os recursos FHIR são importados usando fhirStores.import.
  • Se o horário em que determinado recurso FHIR precisa ser processado for em segundos ou minutos, use fhir.executeBundle. Se o horário em que um determinado recurso FHIR precisa ser processado for em horas ou dias, use fhirStores.import.
  • Se seu projeto do Google Cloud tiver muitas operações de longa duração (LRO, na sigla em inglês) que executam outras tarefas, talvez você note um desempenho melhor com fhir.executeBundle em fhirStores.import.
  • Se o aplicativo que gerencia a operação fhirStores.import não tiver uma boa estratégia para as seguintes situações, use fhir.executeBundle:

    • Como lidar com erros em massa
    • Como corrigir falhas em um subconjunto de recursos FHIR ou lotes inteiros

Quando não usar pacotes FHIR

Considere as seguintes limitações de fhir.executeBundle ao determinar se ele será usado para armazenar recursos FHIR:

  • Os pacotes têm a cota e o faturamento equivalentes aplicados às operações dentro do pacote, como se as operações fossem executadas fora dele. Por exemplo, se um pacote tiver 10 operações POST, 5 operações GET e uma operação DELETE, a cota e o faturamento aplicados a ele serão iguais, como se essas operações fossem executadas de forma independente.

    Como resultado, reduzir os limites de cota e os custos de operação de FHIR não são motivos para usar pacotes em vez de fhirStores.import.

  • Pacotes grandes de transações podem ter mais chances de apresentar conflitos de transação, o que leva a contenção de dados e operações com falha. Para mais informações sobre como esses problemas podem ocorrer e como resolvê-los, consulte Evitar erros 429 Resource Exhausted operation_too_costly.

  • É possível alcançar e manter uma alta capacidade de dados usando pacotes em lote, o que ajuda a evitar a contenção de dados. No entanto, os pacotes em lote não têm recursos de consistência transacional, como integridade referencial.

  • Se um pacote for grande, mesmo que seja em lote, você poderá ter uma capacidade de dados reduzida. Para mais informações, consulte Evitar grandes pacotes de transações.