Opções de importação de FHIR

Esta página descreve as opções para armazenar grandes lotes de dados FHIR na API Cloud Healthcare.

Dica: se você estiver importando dados de um servidor externo de FHIR em massa, use as Ferramentas FHIR em massa de código aberto do Google para carregar dados diretamente na API Cloud Healthcare.

Importar recursos de FHIR

Use o método fhirStores.import para carregar recursos FHIR do Cloud Storage para a API Cloud Healthcare. O método tem melhor desempenho 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.

Ao decidir se deve usar o método fhirStores.import, considere as propriedades a seguir. 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.

• O uso de fhirStores.import elimina as complexidades da execução de grandes pacotes FHIR, como estes:

  • Como dividir pacotes FHIR em pacotes menores
  • Gerenciar vários horários de pacotes
  • Gerenciar erros temporários que podem ser tentados novamente no nível do recurso ou do pacote

  Muitas vezes, essas vantagens superam as vantagens do uso de 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 ao importar 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 referenciado por muitos recursos do 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 dos 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 conferir uma visão geral dos pacotes FHIR.

Quando usar pacotes FHIR

Considere as seguintes características e vantagens do uso do método fhir.executeBundle ao decidir se ele será usado para armazenar recursos do FHIR:

• Se for muito caro, em termos de custos de faturamento ou largura de banda de rede, para criar um pipeline que armazene dados no Cloud Storage e os importe usando fhirStores.import, use fhir.executeBundle.
• Ao executar pacotes, a integridade da transação pode ser aplicada.
• Ao executar pacotes, a validação do perfil FHIR pode ser aplicada.
• Se você precisar enviar notificações do Pub/Sub quando ocorrerem operações de criação, atualização ou exclusão do 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 tempo em que um recurso específico do FHIR precisa ser processado estiver em segundos ou minutos, use fhir.executeBundle. Se o tempo em que um recurso específico do FHIR precisa ser processado é em horas ou dias, use fhirStores.import.
• Se o projeto do Google Cloud tiver muitas operações de longa duração (LROs) realizando outras tarefas, talvez você tenha um desempenho melhor com fhir.executeBundle em vez de fhirStores.import.

• Se o aplicativo que gerencia a operação fhirStores.import não tiver uma boa estratégia para o seguinte, use fhir.executeBundle:

  • Como lidar com erros em massa
  • Como resolver falhas em um subconjunto de recursos FHIR ou em 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 do 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 1 operação DELETE, a cota e o faturamento aplicados ao pacote serão os mesmos que se essas operações tivessem sido executadas de forma independente.

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

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

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

• Se um pacote for grande, mesmo que seja um pacote de lote, talvez a taxa de transferência de dados seja reduzida. Para mais informações, consulte Evite pacotes de transações grandes.