Opções de importação FHIR

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

Importe recursos FHIR

Use o método fhirStores.import para carregar recursos FHIR do Cloud Storage para a Cloud Healthcare API. O método tem o melhor desempenho quando carrega dados para um arquivo FHIR vazio sem interferência de outras aplicações.

Para chamar fhirStores.import, consulte o artigo Importar e exportar recursos FHIR através do Cloud Storage.

Considere as seguintes propriedades do fhirStores.import método quando decidir se o deve usar. Se fhirStores.import não for adequado para a sua aplicação, pondere usar o método fhir.executeBundle para carregar dados. Para obter informações sobre como chamar fhir.executeBundle, consulte o artigo Gerir recursos FHIR através de pacotes FHIR.

  • O método fhirStores.import aceita pacotes superiores ao limite de 50 MB no fhir.executeBundle. No entanto, o tamanho de cada recurso individual no pacote está limitado a 10 MB.

  • A utilização da API fhirStores.import remove as complexidades da execução de grandes conjuntos FHIR, como as seguintes:

    • Dividir pacotes FHIR em pacotes mais pequenos
    • Gerir vários horários de pacotes
    • Gerir erros transitórios que podem ser repetidos ao nível do recurso ou do pacote

    Muitas vezes, estas vantagens superam as vantagens da utilização de pacotes.

  • Cada recurso na entrada tem de conter um ID fornecido pelo cliente. Cada recurso é armazenado com o ID fornecido, independentemente da definição enableUpdateCreate na loja FHIR.

  • O processo de importação não aplica a integridade referencial, independentemente da definição na loja FHIR.disableReferentialIntegrity A não aplicação da integridade referencial permite-lhe importar recursos com interdependências arbitrárias sem considerar o agrupamento nem a ordenação. Se os dados de entrada contiverem referências inválidas ou se alguns recursos não forem importados, o estado do FHIR store pode violar a integridade referencial.

  • Se já existir um recurso com um determinado ID na loja, a versão mais recente do recurso é substituída sem criar uma nova versão do histórico. A substituição ocorre independentemente da definição disableResourceVersioning na loja FHIR. Se ocorrerem falhas transitórias durante a importação, um recurso importado com êxito pode ser substituído mais do que uma vez.

  • A operação de importação é idempotente, a menos que os dados de entrada contenham vários recursos válidos com o mesmo ID, mas conteúdos diferentes. Nesse caso, após a conclusão da importação, a loja contém exatamente um recurso com cada ID, mas as entradas duplicadas podem conter qualquer versão dos conteúdos. Por exemplo, a importação de um milhão de recursos com o mesmo ID escreve apenas um recurso na loja.

  • Os contadores de resultados da operação não contabilizam IDs duplicados como um erro. Cada recurso na entrada conta como um êxito. Isto pode resultar numa contagem de êxitos superior ao número de recursos no arquivo FHIR. Isto ocorre frequentemente quando importa dados organizados em pacotes produzidos por Patient-everything, em que cada pacote contém a sua própria cópia de um recurso, como Practitioner, que pode ser referenciado por muitos recursos de pacientes.

  • Se alguns recursos não forem importados, por exemplo, devido a erros de análise, os recursos importados com êxito não são revertidos. Por exemplo, se 5 de 100 recursos não forem importados, os 95 recursos restantes são importados para o FHIR store.

  • Quando usa 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 de transações ou em lote. Ao contrário do que acontece no 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 reescritas. O pacote é tratado como uma coleção de recursos a serem escritos conforme fornecidos em Bundle.entry.resource, ignorando Bundle.entry.request. Por exemplo, isto permite a importação de pacotes de conjuntos de resultados da pesquisa produzidos por uma pesquisa FHIR ou uma operação Patient-everything.

Use pacotes FHIR

Consulte os pacotes FHIR para ver uma vista geral dos pacotes FHIR.

Quando usar pacotes FHIR

Considere as seguintes caraterísticas e vantagens da utilização do método fhir.executeBundle quando decidir se o deve utilizar para armazenar recursos FHIR:

  • Se for demasiado caro, em termos de custos de faturação ou largura de banda da rede, criar um pipeline que armazene dados no Cloud Storage e, em seguida, importe os dados através do fhirStores.import, use o fhir.executeBundle.
  • Quando executa pacotes, pode aplicar a integridade das transações.
  • Quando executa pacotes, a validação do perfil FHIR pode ser aplicada.
  • Se precisar de enviar notificações do Pub/Sub quando ocorrem operações de criação, atualização ou eliminaçã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 momento em que um recurso FHIR específico tem de ser processado for em segundos ou minutos, use fhir.executeBundle. Se a hora em que um recurso FHIR específico tem de ser processado for em horas ou dias, use fhirStores.import.
  • Se o seu Google Cloud projeto tiver muitas operações de longa duração (LRO) existentes a realizar outras tarefas, pode verificar um melhor desempenho com fhir.executeBundle em vez de fhirStores.import.

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

    • Processamento de erros em massa
    • Resolver falhas num subconjunto de recursos FHIR ou em lotes completos

Quando não usar pacotes FHIR

Considere as seguintes limitações do fhir.executeBundle ao determinar se o deve usar para armazenar recursos FHIR:

  • Os pacotes têm a quota e a faturação equivalentes aplicadas às operações no interior do pacote, como se as operações fossem executadas fora do pacote. Por exemplo, se um pacote tiver 10 operações POST, 5 operações GET e 1 operação DELETE, a quota e a faturação aplicadas ao pacote são as mesmas que se essas operações fossem executadas de forma independente.

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

  • É mais provável que os pacotes de transações grandes tenham conflitos de transações, o que leva a contenção de dados e falhas nas operações. Para obter informações sobre como estes problemas podem ocorrer e como os resolver, consulte o artigo Evite erros 429 Resource Exhausted operation_too_costly.

  • Pode alcançar e manter um elevado débito de dados através de pacotes em lote, o que ajuda a evitar a contenção de dados. No entanto, os conjuntos de lotes não têm capacidades de consistência transacional, como a integridade referencial

  • Se um pacote for grande, mesmo que seja um pacote em lote, pode observar uma taxa de transferência de dados reduzida. Para mais informações, consulte o artigo Evite pacotes de transações grandes.