Dataverse Healthcare API : utilisez le modèle de pipeline de données de soins de santé pour déployer Azure Logic Apps
Cet article fournit un guide détaillé pour utiliser un modèle et déployer un groupe de Azure Logic Apps qui ingèrent des données FHIR dans les Dataverse Healthcare API, les services de données de santé Azure, ou les deux. Cette solution fonctionne comme un flux d’application logique prêt pour l’entreprise qui sert de relais entre les Services de données de santé Azure et les Dataverse Healthcare API. Le flux gère également la logique de nouvelle tentative et la gestion des exceptions. Il se base sur un déclencheur Stockage Blob Azure plutôt que sur le Déclencheur HTTP utilisé dans la configuration manuelle.
Ce flux de travail est disponible pour le déploiement en tant que modèle Azure Resource Manager (ARM) intitulé Modèle de pipeline de données de santé. Vous pouvez déployer le modèle depuis Déployer la solution de soins de santé depuis le Centre de solutions Microsoft Cloud. Cette offre est plus robuste et prise en charge fournie par Microsoft Cloud for Healthcare. Vous devez configurer certaines configurations manuelles de base après avoir déployé le modèle.
Remarque
Ce flux Logic App est fourni comme point d’entrée pour les données entrantes des dossiers de santé électroniques (DSE), ce qui garantit que les données FHIR sont publiées dans les services corrects. Il ne s’agit pas d’une solution définitive dans son état actuel et elle est destinée à être mise à jour en fonction des besoins de votre entreprise.
Les services Logic App ne sont pas nécessaires pour publier des données FHIR dans les points de terminaison de Dataverse Healthcare API. Vous pouvez choisir de créer votre propre solution pour transmettre des données de votre DSE aux API et gérer les réponses.
Les services d’application logique se basent sur un déclencheur Stockage Blob Azure pour déclencher le traitement asynchrone des packs publiés sur un emplacement de stockage configurable. Cette option gère des charges plus lourdes pour les cas d’utilisation en entreprise et inclut des étapes supplémentaires de gestion des exceptions. Cependant, vous devez effectuer des tests approfondis avec vos charges quotidiennes prévues.
Après le déploiement, vous pouvez étendre les applications logiques pour les adapter aux besoins particuliers de votre système.
Important
Ce modèle ARM est uniquement compatible avec 2e vague de lancement 2022 de Microsoft Cloud for Healthcare et versions ultérieures. Pour les anciennes versions, supprimez le Définir requestBody sur la réponse FHIR en cas de succès action avant de déclencher une exécution.
La configuration inclut les étapes suivantes :
- Conditions préalables
- Concevoir
- Étapes post-déploiement
- Gestion des erreurs
- Configurer les nouvelles tentatives
- Sécuriser des Logic Apps
Conditions préalables
Vérifiez que les conditions suivantes sont remplies par votre environnement avant de déployer le modèle :
- Un compte et un abonnement Azure. Si vous n’avez pas d’abonnement, inscrivez-vous pour créer un compte Azure gratuit avant de commencer.
- Un Groupe de ressources Azure configuré avec les autorisations appropriées pour créer de nouvelles ressources, ou un Rôle de contributeur pour créer de nouveaux groupes de ressources.
- Accès au sein du groupe de ressources pour créer des ressources et attribuer des rôles Azure.
- Le respect des consignes de sécurité définies par les administrateurs Azure et la stratégie de l’organisation.
Concevoir
Le diagramme suivant illustre la conception du pipeline déployé via le modèle :
Le modèle ARM déploie plusieurs Logic Apps modularisées. Il comprend les trois services d’application logique suivants :
| Logic Apps | Description |
|---|---|
| Traiter le pack FHIR | La première instance d’application logique déclenchée lorsqu’un pack est chargé dans le stockage blob. Cette application logique détermine s’il faut publier le pack sur FHIR ou directement sur Dataverse. |
| Envoyer le pack vers FHIR | La deuxième application logique déclenchée à partir de l’application logique Traiter le pack FHIR lorsque vous choisissez de publier le pack sur FHIR. Cette application logique traite le pack de requêtes et le publie dans le serveur FHIR. Une fois que cette application logique a publié le pack sur le serveur FHIR, elle transmet le pack à l’application logique suivante Envoyer le pack à Dataverse pour un traitement ultérieur. |
| Envoyer le pack vers Dataverse | L’application logique finale déclenchée soit à partir de l’application logique Traiter le pack FHIR ou Envoyer le pack à l’application logique FHIR. Elle traite le pack de requêtes et publie le pack sur Dataverse. Elle gère également le nettoyage du conteneur de packs en déplaçant le pack de requêtes vers le conteneur bundleserror ou bundlesarchive. |
Paramètres du modèle
| Paramètre | Description |
|---|---|
| Emplacement de la ressource | La région Azure pour la création de ressources. La valeur par défaut de ce paramètre est la région utilisée pour créer le groupe de ressources. |
| URL de Dataverse | URL de votre environnement Microsoft Cloud for Healthcare Dataverse. Par exemple, https://*orgname*.crm.dynamics.com |
| Publier vers serveur FHIR | Valeur booléenne. Si elle est définie sur true, le pack est publié sur le serveur FHIR. |
| URL du serveur FHIR | URL de votre serveur FHIR. Par exemple, https://*fhirserver*.azurewebsites.netCe paramètre n’est requis que si vous souhaitez publier sur le serveur FHIR avant de publier sur le point de terminaison de l’API upsert Dataverse. |
| Valeur unique | La chaîne unique utilisée pour générer les noms de ressources. Cette valeur est par défaut la fonction uniqueString. Vous pouvez remplacer cette valeur si nécessaire. |
Ressources déployées
Le modèle déploie les ressources suivantes dans votre environnement :
| Ressource | Description |
|---|---|
| Identité managée | Le nom de l’identité managée est au format mi_UniqueValue. Cette identité managée est attribuée à l’application logique et l’accès au compte de stockage, au serveur FHIR et à l’environnement Dataverse lui est accordé. |
| Compte de stockage Azure | Le nom du compte de stockage est au format sa_UniqueValue. Outre le compte de stockage, le modèle déploie également les trois conteneurs suivants : bundles, bundlesarchive et bundleserror. |
| Attribution de rôle | Attribue le rôle Contributeur de données blob de stockage sur le compte de stockage à l’identité managée. |
| Azure Event Grid | Le nom de Event Grid est au format eg_UniqueValue. Tous les événements blob sont publiés sur cet Event Grid. |
| Azure Service Bus | Le nom de Service Bus est au format sb_UniqueValue. Event Grid publie des événements sur ce Service Bus. Le nom de la file d’attente est bundleCreated. |
| Règle d’autorisation | Crée une règle d’autorisation Écouter sur le Service Bus avec le nom bundleauthlisten. |
| Azure Logic Apps | Un ensemble de workflows Logic App associés du type Consommation. Le workflow déclenche les événements Service Bus. Ces applications logiques traitent le pack FHIR et le publient dans les points de terminaison configurés. Chaque application logique est nommée à l’aide de la valeur unique fournie lors du déploiement : 1. laprocessfhirbundle_UniqueValue 2. lasendbundletodataverse_UniqueValue 3. lasendbundletofhir_UniqueValue |
| Connexion API | Plusieurs connexions API requises pour les Logic Apps. |
Sortie
Selon que l’exécution se termine correctement ou avec une erreur, un blob avec le nom orginalblobname_response.json est créé dans le dossier bundlesarchive ou bundleserror avec le schéma suivant :
{
"dataverseResponse": "<The response from the Dataverse healthcare API post the call.>",
"fhirServerResponse": "<The response from the FHIR server call if the "Post to FHIR server" parameter value was set to True.>",
"statusMessage": "<Summary of the responses. In case of a failure, the message provides details about how many resources failed to post to the FHIR server and to Dataverse.>",
"statusCode": "<Code value associated with the issue encountered.>"
}
Selon l’application logique qui a déclenché l’erreur, l’erreur JSON contient le nœud dataverseResponse ou fhirServerResponse. Par exemple, si vous rencontrez une erreur avec l’application logique lasendbundletofhir_UniqueValue, la réponse JSON contient uniquement le nœud et la valeur fhirServerResponse.
Étapes post-déploiement
La section suivante contient les étapes que vous devez suivre une fois le modèle déployé.
Autoriser l’accès au serveur FHIR
L’accès au serveur FHIR à partir de l’application logique nécessite l’attribution de rôle Contributeur de données FHIR, qui permet de publier de nouvelles données sur le service. Ajoutez cette attribution de rôle Azure à l’identité managée utilisée par l’application logique.
Accédez à l’instance du serveur FHIR, sélectionnez Contrôle d’accès (IAM), puis sélectionnez Ajouter une attribution de rôle.
Dans l’onglet Rôle, sélectionnez le rôle contributeur Données FHIR.
Sélectionnez Membres, Identité managée, puis + Sélectionner les membres.
Ajoutez l’identité managée créée avec le déploiement du modèle ARM. L’identité managée nouvellement déployée doit être nommée mi_UniqueValue.
L’attribution peut prendre quelques minutes pour se refléter dans l’identité managée. Sélectionnez Attributions de rôle Azure pour afficher l’attribution de rôle sur l’identité managée.
Accorder l’accès aux Dataverse Healthcare API
La même identité managée est utilisée dans l’application logique pour accéder aux Dataverse Healthcare API en la connectant à un utilisateur de l’application dans l’instance Dataverse cible. Pour plus d’informations sur les utilisateurs de l’application, accédez à Gérer les utilisateurs de l’application dans le Centre d’administration Power Platform.
Vous avez besoin de l’ID client Azure pour l’identité managée afin de configurer l’utilisateur de l’application. Pour récupérer l’ID client, ouvrez l’identité managée créée avec le déploiement du modèle ARM et copiez la valeur ID client dans la zone Vue d’ensemble.
Dans le centre d’administration Power Platform, ouvrez votre environnement Microsoft Cloud for Healthcare. Dans la section Accès, sélectionnez Applications S2S, puis Utilisateur de la nouvelle application.
Dans le volet Créer un utilisateur d’application, sélectionnez la Division correspondante, puis Ajouter une application.
Dans le volet Ajouter une application à partir de Microsoft Entra ID, recherchez l’ID client que vous avez copié à partir de l’identité managée.
Sélectionnez l’identité managée dans la liste, sélectionnez Ajouter, puis modifiez les rôles de sécurité.
Sélectionnez le rôle Utilisateur enregistré de l’application Administrateur de la synchronisation pour FHIR, puis Enregistrer.
Cliquez sur Créer pour créer l’utilisateur de l’application.
Une fois la configuration terminée, vous pouvez tester le flux de travail de l’application logique en publiant un exemple de pack dans le conteneur sa_UniqueValue pour le traitement. En fonction des exigences de votre solution, vous pouvez également modifier l’une de ces applications logiques pour un traitement plus approfondi.
Gestion des erreurs
Si l’exécution d’une application logique génère une erreur, un fichier portant le nom originalblobname_response.json est créé dans le conteneur bundleserror du compte de stockage. Vous pouvez analyser ce fichier pour identifier la cause première de l’erreur, la corriger et soumettre à nouveau le pack avec les ressources défaillantes.
Type de pack : Batch
Le serveur FHIR et les Dataverse Healthcare API traitent un pack de type batch comme un groupe d’actions indépendantes. Par conséquent, les réponses indiquent le succès et l’échec de chaque ressource indépendamment.
Conformément à la spécification FHIR, toute ressource qui échoue génère un OperationOutcome avec une valeur de gravité définie sur erreur, tandis que Dataverse Healthcare API définit msind_requeststatus sur 935000002. Pour plus d’informations sur les types de statut de demande, accédez à Types de statut de demande.
Le flux de travail de l’application logique analyse à la fois les réponses du serveur FHIR et les Dataverse Healthcare API. Il met fin au flux comme Échec si une ressource a généré une erreur.
Remarque
Les Dataverse Healthcare API ne prennent actuellement en charge que les packs FHIR de type batch et batch-response.
Configurer les nouvelles tentatives
Après avoir identifié et corrigé l’erreur, vous pouvez replacer le pack dans le conteneur bundles pour retraitement.
Nouvelle tentative en termes de limitation : serveur FHIR
L’action HTTP dans le workflow d’application logique qui publie sur le serveur FHIR utilise les stratégies de nouvelle tentative d’action HTTP intégrées. La valeur par défaut est une règle d’intervalle exponentiel définie pour réessayer quatre fois. Vous pouvez modifier la politique de nouvelle tentative.
Sélectionnez les points de suspension dans l’angle supérieur droit de la carte d’action, puis sélectionnez Paramètres.
Sous Politique de nouvelle tentative, changez la valeur du champ Type.
Nouvelle tentative en termes de limitation : Dataverse Healthcare API
Les Limites de l’API de protection des services affectent les Dataverse Healthcare API. Si une demande aux Dataverse Healthcare API est limitée, le flux de travail de l’application logique (par défaut), réessaie trois fois à l’intervalle Retry-After spécifié par l’API dans l’en-tête de réponse. Vous pouvez modifier à la fois le nombre de tentatives et l’intervalle.
Pour modifier le nombre de tentatives, modifiez la valeur Nombre dans l’action En boucle jusqu’à.
Pour modifier l’intervalle, modifiez la valeur Nombre dans l’action Retard.
Sécuriser des Logic Apps
Une fois la configuration et le test de l’application logique terminés, vous pouvez verrouiller le traçage en sécurisant les actions d’entrées et de sorties. Pour en savoir plus, consultez Sécuriser Logic App.