Configurer les tables de santé virtuelles

La fonctionnalité Tables de données de santé virtuelles dans Microsoft Cloud for Healthcare optimise vos dépenses d’hébergement cloud. Cette fonctionnalité vous aide à virtualiser vos données de référence cliniques et d’autres données de santé à l’utilisation de nos applications pilotées par modèle et d’autres solutions d’engagement. La virtualisation de vos données élimine le besoin de créer des intégrations coûteuses qui visualisent les mêmes tables intensives en données plusieurs fois dans les applications Microsoft et tierces telles que les systèmes de dossier médical informatisé (DME).

Conditions préalables

Les tables de données de santé virtuelles ciblent les fonctionnalités de base dans la connexion Microsoft Cloud for Healthcare aux serveurs FHIR externes. Cet article suppose que vous disposez d’un serveur FHIR et de la version de novembre 2021 de Microsoft Cloud for Healthcare. De plus, cet article suppose que vous avez effectué les étapes suivantes :

• Configurer l’agent de synchronisation Azure FHIR et l’Administrateur de la synchronisation pour FHIR.
• Configurer les patients pour qu’ils circulent de FHIR vers Dataverse.
• Configurer une identité gérée dans Azure (ID client et clé secrète client) avec des autorisations sur le serveur FHIR.
• Configurer l’identité gérée dans l’Administrateur de la synchronisation pour FHIR.
• Configurer les attributs de source de données virtuels (URL du serveur FHIR, Auth, Resource).
• Basculer les routes de données de Rendez-vous et d’Observation sur Virtuel.

Pour plus d’informations sur l’exécution de ces étapes, voir Configurer l’Administrateur de la synchronisation pour FHIR.

Itinéraires de données

Les tables de données de santé virtuelles tirent le meilleur parti de la solution de tables virtuelles Microsoft Dataverse (entités) et la basent sur un concept de routage de données.

Une des limites des tables virtuelles Dataverse aujourd’hui, c’est qu’il n’y a aucun moyen de convertir une table physique existante en table virtuelle et vice versa, ce qui provoque la création de tables nettes. Le moment venu de passer au virtuel ou au physique, vous devez aau moment reconfigurer vos applications Dataverse pour utiliser la nouvelle structure de table.

L’un des défis avec les tables virtuelles Dataverse aujourd’hui, c’est qu’après avoir virtualisé une table, les utilisateurs finaux sont confrontés à deux tables possibles à utiliser à la création de vues enregistrées et de recherches avancées.

Les tables de données de santé virtuelles résolvent ce problème en vous permettant d’établir des itinéraires de données pour vos tables ou entités.

Notes

Vous n’êtes pas sûr de l’entité par rapport à la table ? Accédez à Développeurs : Comprendre la terminologie dans Microsoft Dataverse.

Cartes d’entités et d’attributs

Les tables de données de santé virtuelles exploitent les mêmes cartes d’entités, que vous décidiez de virtualiser vos données ou de conserver Dataverse comme source. Pour plus d’informations, accédez à Cartes d’entités.

Les tables de données de santé virtuelles exploitent les mêmes mappages d’attributs, que vous décidiez de virtualiser vos données ou de conserver Dataverse comme source. Pour plus d’informations, accédez à Mappages d’attributs.

Détails de la mise en œuvre

Les tables qui prennent en charge les tables de données de santé virtuelles sont configurées pour être acheminées vers Dataverse par défaut. Pour faire passer le magasin de données en virtuel et acheminer les demandes de données vers le serveur FHIR, procédez comme suit dans l’Administrateur de la synchronisation pour FHIR :

1. Configurez les rôles de sécurité pour les administrateurs et les utilisateurs de table virtuelle :

   • Attribuez le nouveau rôle de sécurité d’administrateur des tables virtuelles Healthcare aux administrateurs qui configurent les tables virtuelles. Assurez-vous que ces administrateurs ont également le rôle d’administrateur de synchronisation pour Administrateur de la synchronisation pour FHIR, comme détaillé dans Rôles de sécurité de l’administrateur de la synchronisation pour FHIR.
   • Attribuez le nouveau rôle de sécurité d’utilisateur des tables virtuelles Healthcare à tous ceux qui ont accès aux entités de tables virtuelles.

2. Configurez la connectivité au serveur FHIR :

   • ID client et clé secrète client du fournisseur
   • Source de données de Santé Microsoft

3. Mettre à jour la route des données pour les tables sélectionnées.

Notes

Si la table de base Observation ou Rendez-vous est changée en virtuelle ou Dataverse, vous devez modifier toutes les tables de support associées en même temps.

Seuls les tableaux liés à l’Observation et aux Rendez-vous sont dans le champ d’application des tables de données de soins de santé virtuels. Ces enregistrements auront un accès en lecture seule.

Les autres détails de mise en œuvre incluent :

• Développer : Prend en charge les tables d’extension des observations et rendez-vous.

  • Récupérer plusieurs : quand les tables de développement sont configurées pour acheminer les données à partir d’un fournisseur de données virtuel, la récupération multiple n’est prise en charge que si la requête contient des filtres sur l’attribut de lien parent. Par exemple, le composant d’observation est une entité étendue de l’entité d’observation. La carte d’entité pour le composant d’observation est configurée comme indiqué dans la capture d’écran suivante :

    

    La requête multiple de récupération pour le composant d’observation doit contenir un filtre sur des ID spécifiques de msemr_observation (attribut de lien parent) :

    

  • Récupérer : étant donné que les entrées de développement n’ont pas d’ID unique dans FHIR, nous ne prenons pas en charge la récupération des entrées de développement à l’aide d’un ID. L’ID qui s’affiche quand vous sélectionnez un enregistrement dans un ensemble de résultats multiples récupérés est temporaire.

• Filtrage : prend en charge le filtrage de colonne tel que défini par la spécification HL7.org FHIR. Filtrage sur les entités liées pour un seul niveau.

• Filtrage composite : prend en charge des filtres composites limités pour les filtres composites à table unique. Les définitions de filtres composites suivantes sont prises en charge :

  Filtre composite	Description
  code-value-concept	Couple de paramètres code et valeur codée
  code-value-date	Couple de paramètres code et valeur date/heure
  code-value-quantity	Couple de paramètres code et valeur de quantité
  code-value-string	Couple de paramètres code et valeur de chaîne
  combo-code-value-concept	Paire de paramètres code et valeur codée, y compris dans les composants
  combo-code-value-quantity	Paire de paramètres code et valeur de quantité, y compris dans les composants

  Pour plus d’informations sur les filtres composites, consultez Paramètres de recherche composites dans la documentation HL7 FHIR.

• Entités liées : Prend en charge les filtres d’entités liées à l’aide du filtrage chaîné tel que défini par la spécification HL7.org FHIR. Le niveau de prise en charge dépend de la version de l’API Azure pour FHIR. Les conditions de filtre non prises en charge feront apparaître des exceptions et ne renverront aucun résultat.

• Tri : Implémenté comme défini par la spécification HL7.org FHIR. Le niveau de prise en charge dépend de la version de l’API Azure pour FHIR. Les conditions de tri non prises en charge renverront toujours des données.

• Notifications et exceptions : Notifications dans le contexte des tables FHIR Flex. Message utilisateur de tri limité et filtre basé sur la version de l’API Azure pour FHIR.

Des tables de support supplémentaires ont été configurées dans le cadre des tables de données de santé virtuelles. Ces enregistrements de support sont :

• Observation

  • Observation basée sur
  • Composant d’observation
  • Catégorie d’observation
  • Plage de référence du composant d’observation
  • Exécutant de l’observation
  • Plage de référence d’observation
  • Application de la plage de référence de l’observation

• Rendez-vous

  • Compte de rendez-vous
  • Historique de classe de rendez-vous
  • Diagnostic de rendez-vous
  • Épisode de rendez-vous de soins
  • Modalités d’hospitalisation de rendez-vous
  • Privilège d’hospitalisation de rendez-vous
  • Diète d’hospitalisation de rendez-vous
  • Emplacement de rendez-vous
  • Participant au rendez-vous
  • Type de participant au rendez-vous
  • Raison du rendez-vous
  • Historique de statut de rendez-vous
  • Type de rendez-vous

Notes

Si le fournisseur de données à utiliser pour l’Observation ou le Rendez-vous est défini sur Virtuel, vous devez modifier toutes les tables de support associées en même temps.

Mettre à jour l’ID client et la clé secrète client

1. Dans l’Administrateur de la synchronisation pour FHIR, accédez à Paramètres d’intégration.

   

2. Entrer l’ID client et la Clé secrète du client pour le serveur FHIR dans les champs fournis.

3. Entrer l’URL du serveur et l’URL de l’autorité pour le serveur FHIR cible.

4. Sélectionnez Enregistrer pour valider vos modifications.

5. Effectuez les mêmes étapes au moment de la mise à jour d’une Clé secrète client quand elle est expirée ou nouvellement générée.

Mettre à jour la route de données vers Dataverse ou virtuelle

Suivez ces étapes pour basculer la route des données pour les tables de virtuelle à Dataverse, ou vice versa.

1. Dans l’Administrateur de la synchronisation pour FHIR, accédez à Routes de données sous Configuration de l’application.

2. Sélectionnez une table de base, soit Observation ou Rendez-vous.

   

3. Modifiez le Fournisseur de données à utiliser. Vous serez invité avec une confirmation.

   

4. Après avoir choisi Confirmer le changement, vous pouvez ensuite sélectionner la carte d’entité à utiliser pour cet itinéraire.

   

5. Après avoir enregistré, répétez ces étapes pour les tableaux de support de votre sélection actuelle.

Éléments à ne pas oublier

La section suivante présente certaines des principales considérations d’implémentation à garder à l’esprit au moment de la planification de l’activation de la fonctionnalité de tables de données de santé virtuelles. Cependant, cette liste n’est pas exhaustive. Pour plus d’informations, accédez à Limitations des tables virtuelles.

Risque	Expérience utilisateur	Tactique d’atténuation potentielle
Vues et tableaux de bord enregistrés existants	Tous les graphiques et tableaux de bord créés à l’aide d’entités physiques virtualisées depuis ne fonctionneront plus.	Refactorisez les vues et les tableaux de bord enregistrés pour utiliser la nouvelle entité virtualisée. Notez le nouveau texte Natif ajouté au début des versions Dataverse héritées des tables de données de santé virtuelles. La version virtuelle de ces tables sera par exemple nommée Rendez-vous ou Observations. Communiquez le changement aux utilisateurs finaux. En plus des vues système, les utilisateurs devront refactoriser les vues personnelles.
Graphiques	Tous les graphiques ne fonctionneront plus ou ne seront plus disponibles pour la création.	Power BI ou une solution alternative pour visualiser ces données est obligatoire. Les graphiques pilotés par modèles ne seront pas rendus pour les données virtualisées. Communiquez le changement aux utilisateurs finaux. Ils n’auront plus de graphiques dans les vues personnelles et les tableaux de bord s’ils ont été créés avant d’utiliser des entités physiques.
Recherche par pertinence non prise en charge	La recherche par pertinence ne fonctionnera pas pour les tables de données de santé virtuelles.	Communiquez le changement aux utilisateurs finaux. Évaluez si les entités virtuelles peuvent être exploitées dans votre déploiement. La nouvelle expérience de recherche par défaut dans Power Apps piloté par modèle est basé sur la recherche par pertinence.
AI Builder non pris en charge	Toutes les informations AI Builder qui utilisaient autrefois les tables Dataverse physiques ne seront plus disponibles quand ces tables seront virtualisées.	Considérez d’autres options d’IA de Microsoft. Les jeux de données dans lesquels vous envisagez de virtualiser Dataverse devrait probablement être analysés avec des services Azure comme Azure Synapse Analytics pour découvrir des opportunités dans votre clinique ou votre entreprise.
Les tables virtuelles présentent un modèle de sécurité simplifié, car elles passeront à une sécurité au niveau de l’organisation.	La sécurité doit être examinée pour vos exigences de conformité.	Si la sécurité à l’échelle de l’organisation ne convient pas à votre déploiement, reconsidérez l’activation de la fonctionnalité des tables de données de santé virtuelles.

Limitations connues

Étant donné que la fonctionnalité Tables de données de santé virtuelles est basée sur la solution de table virtuelle existante de Dataverse, elles a les mêmes limites. Tenez compte de ces limitations pendant que vous déterminez si cette fonctionnalité fonctionnera pour vos besoins.

Les limitations suivantes s’appliquent également :

• Cette fonctionnalité ne prend actuellement en charge que la connexion aux serveurs FHIR Azure. Pour plus d’informations, accédez à Qu’est-ce que le service FHIR ?.

• La prise en charge de la recherche et du tri dépend de la version du serveur FHIR configuré. Pour plus d’informations, accédez à Vue d’ensemble de la recherche FHIR.

• Pour la recherche et le filtrage, un seul niveau d’entité de lien est actuellement pris en charge.

• Pour la recherche et le filtrage, un seul niveau d’entités de développement est actuellement pris en charge.

• Pour les tables virtuelles, les relations aux tables non basées sur FHIR ne sont pas prises en charge.

Questions fréquentes

Pour une liste des questions fréquemment posées, accédez à FAQ sur les tables de données de santé virtuelles.

Voir aussi

Qu’est-ce que Microsoft Cloud for Healthcare ?
FAQ sur les tables de données de santé virtuelles
Prise en main des tables virtuelles Microsoft Dataverse (entités)
Configurer l’Administrateur de la synchronisation pour FHIR