Options d'importation FHIR

Cette page décrit les options permettant de stocker de grands lots de données FHIR dans l'API Cloud Healthcare.

Importer des ressources FHIR

Utilisez la méthode fhirStores.import pour charger des ressources FHIR depuis Cloud Storage dans l'API Cloud Healthcare. Cette méthode fonctionne mieux lors du chargement de données dans un store FHIR vide sans interférence des autres applications.

Pour appeler fhirStores.import, consultez la page Importer et exporter des ressources FHIR à l'aide de Cloud Storage.

Tenez compte des propriétés suivantes de la méthode fhirStores.import lorsque vous décidez de l'utiliser ou non. Si fhirStores.import n'est pas adapté à votre application, envisagez d'utiliser la méthode fhir.executeBundle pour charger des données. Pour plus d'informations sur l'appel de fhir.executeBundle, consultez la section Gérer les ressources FHIR à l'aide de bundles FHIR.

  • La méthode fhirStores.import accepte les bundles qui dépassent la limite de 50 Mo sur fhir.executeBundle. Cependant, la taille de chaque ressource individuelle du bundle est limitée à 10 Mo.

  • L'utilisation de fhirStores.import élimine la complexité liée à l'exécution de grands groupes FHIR, tels que les suivants:

    • Diviser les bundles FHIR en groupes plus petits
    • Gérer plusieurs programmations de lots
    • Gérer les erreurs temporaires qui peuvent être relancées au niveau d'une ressource ou d'un bundle

    Bien souvent, ces avantages sont plus importants que ceux liés à l'utilisation d'offres groupées.

  • Chaque ressource de l'entrée doit contenir un ID fourni par le client. Chaque ressource est stockée à l'aide de l'ID fourni, quel que soit le paramètre enableUpdateCreate défini sur le magasin FHIR.

  • Le processus d'importation n'applique pas l'intégrité référentielle, quel que soit le paramètre disableReferentialIntegrity défini sur le magasin FHIR. L'application forcée de l'intégrité référentielle vous permet d'importer des ressources avec des interdépendances arbitraires sans tenir compte du regroupement ou de l'ordre. Si les données d'entrée contiennent des références non valides ou si l'importation de certaines ressources échoue, l'état du magasin FHIR peut enfreindre l'intégrité référentielle.

  • Si une ressource possède déjà un ID dans le magasin, la version la plus récente de la ressource est écrasée sans créer de version historique. L'écrasement se produit quel que soit le paramètre disableResourceVersioning défini sur le magasin FHIR. Si des échecs temporaires se produisent lors de l'importation, une ressource importée avec succès peut être écrasée plusieurs fois.

  • L'opération d'importation est idempotente, sauf si les données d'entrée contiennent plusieurs ressources valides avec le même ID, mais avec un contenu différent. Dans ce cas, une fois l'importation terminée, le magasin contient exactement une ressource avec chaque ID, mais les entrées en double peuvent contenir n'importe quelle version du contenu. Par exemple, l'importation d'un million de ressources possédant le même ID n'écrit qu'une ressource dans le magasin.

  • Les compteurs de résultats de l'opération ne comptabilisent pas les ID en double par erreur. Chaque ressource de l'entrée compte pour un succès. Cela peut entraîner un décompte de réussite supérieur au nombre de ressources du magasin FHIR. Cela se produit souvent lors de l'importation de données organisées en lots produits par Patient-everything, où chaque groupe contient sa propre copie d'une ressource, telle que Practitioner, qui peut être référencée par de nombreuses ressources patient.

  • Si l'importation de certaines ressources échoue, par exemple en raison d'erreurs d'analyse, les ressources importées avec succès ne font pas l'objet d'un rollback. Par exemple, si l'importation de 5 ressources sur 100 échoue, les 95 ressources restantes sont importées dans le magasin FHIR.

  • Lorsque vous utilisez le format BUNDLE, la méthode d'importation rejette les groupes avec Bundle.type du type history. La méthode d'importation n'applique pas la sémantique de traitement du lot pour les groupes de lots ou de transactions. Contrairement à fhir.executeBundle, les groupes de transactions ne sont pas exécutés en tant que transaction unique et les références internes ne sont pas réécrites. Le groupe est traité comme une collection de ressources à écrire comme indiqué dans Bundle.entry.resource, en ignorant Bundle.entry.request. Par exemple, cela permet d'importer des groupes d'ensembles de recherche générés par une recherche FHIR ou une opération Patient-everything.

Utiliser des bundles FHIR

Consultez la section Groupes FHIR pour obtenir un aperçu des groupes FHIR.

Quand utiliser des bundles FHIR

Tenez compte des caractéristiques et avantages suivants de la méthode fhir.executeBundle lorsque vous décidez de l'utiliser pour stocker des ressources FHIR:

  • S'il est trop coûteux, en termes de frais de facturation ou de bande passante réseau, de créer un pipeline qui stocke les données dans Cloud Storage, puis les importe à l'aide de fhirStores.import, utilisez fhir.executeBundle.
  • Lors de l'exécution de bundles, l'intégrité des transactions peut être appliquée.
  • Lors de l'exécution de bundles, la validation du profil FHIR peut être appliquée.
  • Si vous devez envoyer des notifications Pub/Sub lorsque des opérations FHIR de création, de mise à jour ou de suppression se produisent, utilisez fhir.executeBundle. Les notifications Pub/Sub ne sont pas envoyées lorsque des ressources FHIR sont importées à l'aide de fhirStores.import.
  • Si l'heure à laquelle une ressource FHIR particulière doit être traitée est exprimée en secondes ou en minutes, utilisez fhir.executeBundle. Si l'heure à laquelle une ressource FHIR particulière doit être traitée est exprimée en heures ou en jours, utilisez fhirStores.import.
  • Si votre projet Google Cloud comporte de nombreuses opérations de longue durée effectuant d'autres tâches, vous obtiendrez peut-être de meilleures performances avec fhir.executeBundle par rapport à fhirStores.import.

  • Si l'application qui gère l'opération fhirStores.import ne dispose pas d'une bonne stratégie pour les éléments suivants, utilisez fhir.executeBundle:

    • Gérer les erreurs d'envoi groupé
    • Résoudre les échecs sur un sous-ensemble de ressources FHIR ou des lots entiers

Dans quels cas ne pas utiliser de groupes FHIR

Tenez compte des limites suivantes de fhir.executeBundle lorsque vous déterminez si vous devez l'utiliser pour stocker des ressources FHIR:

  • Un quota et une facturation équivalents sont appliqués aux opérations au sein du bundle comme si celles-ci étaient exécutées en dehors de celui-ci. Par exemple, si un lot comporte 10 opérations POST, 5 opérations GET et 1 opération DELETE, le quota et la facturation appliqués au groupe sont les mêmes que si ces opérations étaient exécutées indépendamment.

    Par conséquent, avoir pour objectif de réduire les limites de quota et les coûts d'exploitation FHIR n'est pas une raison d'utiliser des bundles au lieu de fhirStores.import.

  • Les groupes de transactions volumineux sont plus susceptibles d'avoir des conflits de transactions, ce qui entraîne des conflits de données et l'échec d'opérations. Pour savoir comment ces problèmes peuvent se produire et comment les résoudre, consultez la section Éviter les erreurs 429 Resource Exhausted operation_too_costly.

  • Vous pouvez atteindre et maintenir un débit de données élevé à l'aide de groupes de lots, ce qui vous permet d'éviter les conflits de données. Cependant, les bundles de lots ne disposent pas de fonctionnalités de cohérence transactionnelle, telles que l'intégrité référentielle.

  • Si un lot est volumineux, le débit de données peut être réduit, même s'il s'agit d'un lot par lot. Pour en savoir plus, consultez la section Éviter les lots de transactions volumineux.