Stratégies de migration pour le déplacement à partir de l’API Azure pour FHIR
Important
L’API Azure pour FHIR sera mise hors service le 30 septembre 2026. Suivez les stratégies de migration pour passer au service FHIR des Services de données de santé Azure d’ici cette date. En raison de la mise hors service de l’API Azure pour FHIR, les nouveaux déploiements ne seront plus autorisés à compter du 1er avril 2025. Le service FHIR des Services de données de santé Azure est la version évoluée de l’API Azure pour FHIR qui permet aux clients de gérer les services FHIR, DICOM et MedTech avec des intégrations dans d’autres services Azure.
Le service FHIR de Services de données de santé Azure est la plateforme de nouvelle génération pour l’intégration des données d’intégrité. Il offre des services FHIR, DICOM et MedTech gérés, de qualité entreprise, pour divers échanges de données de santé.
Grâce à la migration de vos données FHIR de l’API Azure pour FHIR vers le service FHIR Services de données de santé Azure, votre organisation peut bénéficier d’améliorations des performances, de la scalabilité, de la sécurité et de la conformité. Les organisations peuvent également accéder à de nouvelles fonctions et capacités qui ne sont pas disponibles dans l’API Azure pour FHIR.
L’API Azure pour FHIR sera mise hors service le 30 septembre 2026, vous devez donc migrer vos données FHIR vers le service FHIR de Services de données de santé Azure dès que possible. Pour faciliter le processus, nous avons créé des outils et des conseils pour vous aider à évaluer votre état de préparation, à préparer vos données, à migrer vos applications et à passer au nouveau service.
Approche recommandée
Pour migrer vos données, procédez comme suit :
- Étape 1 : Évaluer la préparation
- Étape 2 : Préparer la migration
- Étape 3 : Migrer les données et les charges de travail d’application
- Étape 4 : Basculer de l’API Azure pour FHIR vers les Services de données de santé Azure
Étape 1 : Évaluer la préparation
Comparez les différences entre l’API Azure pour FHIR et les Services de données de santé Azure. Passez également en revue votre architecture et évaluez si des modifications doivent être apportées.
| Fonctionnalités | Azure API pour FHIR | Azure Health Data Services |
|---|---|---|
| Paramètres | Prises en charge : • RBAC local • Proxy Smart sur FHIR |
Dépréciation planifiée : • RBAC local (9/6/23) • Proxy Smart sur FHIR (9/21/26) |
| Volume de stockage de données | Plus de 4 To | La prise en charge actuelle est de 4 To (Ouvrez une demande de support Azure si vous avez besoin de plus de 4 To) |
| Entrée de données | Outils disponibles dans OSS | opération de $import |
| Mise à l’échelle automatique | Prise en charge à la demande et payante | Activé par défaut sans frais supplémentaires |
| Paramètres de recherche | Type d’offre groupée pris en charge : Batch • Les modificateurs Inclure et Réinsérer, Itérer ne sont pas pris en charge • Tri pris en charge par prénom, nom, date de naissance et date clinique |
Type d’offre groupée prise en charge : Batch et transaction • Paramètres de recherche sélectionnables • Les modificateurs Inclure, Réinsérer et Itérer sont pris en charge • Tri pris en charge par les champs chaîne et DateHeure |
| Événements | Non pris en charge | Prise en charge |
| Infrastructure | Prises en charge : • Clés managées par le client • Support zone de disponibilité et récupération jusqu`à une date et heure • Récupération d’urgence interrégion |
Prises en charge : • Récupération de données • Clés managées par le client Ensuite : • Prise en charge des zones de disponibilité |
Facteurs susceptibles d’affecter votre architecture
L’agent de synchronisation est maintenant déconseillé. Si vous utilisez l’agent de synchronisation pour vous connecter à Dataverse, consultez Vue d’ensemble de la boîte à outils d’intégration des données
Le proxy FHIR est maintenant déconseillé. Si vous utilisez le proxy FHIR pour les événements, reportez-vous à la fonctionnalité d’événements intégrée. Les alternatives peuvent être personnalisées et créées à l’aide du kit de ressources pour Services de données de santé Azure.
Le proxy SMART on FHIR est maintenant déconseillé. Vous devez utiliser la nouvelle capacité SMART on FHIR. Plus d’informations : SMART on FHIR
Le service FHIR de Services de données de santé Azure ne prend pas en charge le RBAC local et l’autorité personnalisée. L’autorité d’émetteur de jeton doit être le point de terminaison d’authentification du client dans lequel le Service FHIR s’exécute.
Le connecteur IoT est pris en charge uniquement à l’aide d’une API Azure pour le service FHIR. Le connecteur IoT est remplacé par le service MedTech. Vous devez déployer un service MedTech et le service FHIR correspondant dans un espace de travail Services de données de santé Azure existant ou nouveau et pointer vos appareils vers le nouveau hub d’événements d’appareil Azure Events Hubs. Utilisez les fichiers de mappage de destination et d’appareil existants du connecteur IoT avec le déploiement du service MedTech.
Si vous souhaitez effectuer la migration des données FHIR d’appareil de connecteur IoT existantes de votre service d’API Azure pour FHIR vers le service FHIR Services de données de santé Azure, utilisez la fonctionnalité d’exportation et d’importation en bloc dans l’outil de migration. Une autre solution de migration serait de déployer un nouveau service MedTech et de relire les messages d’appareil IoT via le service MedTech.
Étape 2 : Préparer la migration
Tout d’abord, créez un plan de migration. Nous vous recommandons les modèles de migration décrits dans le tableau. Selon la tolérance de votre organisation pour les temps d’arrêt, vous pouvez décider d’utiliser certains modèles et outils pour faciliter votre migration.
| Modèle de migration | Détails | Comment ? |
|---|---|---|
| Lift-and-shift | Modèle le plus simple. Idéal si votre pipeline de données peut se permettre un temps d’arrêt plus long. | Choisissez l’option qui convient le mieux à votre organisation : • Configurez un flux de travail pour $export vos données sur l’API Azure pour FHIR, puis $import dans le service FHIR de Services de données de santé Azure. • Le référentiel GitHub fournit des conseils sur l’exécution de ces commandes, ainsi qu’un script permettant d’automatiser la création de la charge utile $import. • Vous pouvez également créer votre propre outil pour migrer les données à l’aide de $export et de $import. |
| Copie incrémentielle | Version continue de la migration lift-and-shift, avec moins de temps d’arrêt. Idéal pour de grandes quantités de données qui prennent plus de temps à copier, ou si vous souhaitez continuer à exécuter l’API Azure pour FHIR pendant la migration. | Optez pour l’option la plus adaptée à votre organisation. • Nous avons créé un outil de migration OSS pour faciliter ce modèle de migration. • Ou créez votre propre outil pour migrer les données de manière incrémentielle. |
Considérations relatives à l’outil de migration OSS
Si vous décidez d’utiliser l’outil de migration OSS, examinez et comprenez les capacités et les limites de l’outil de migration.
Préparer l’API Azure pour le serveur FHIR
Identifiez les données à migrer.
Profitez-en pour nettoyer les données ou les serveurs FHIR que vous n’utilisez plus.
Déterminez si vous souhaitez migrer des versions historiques ou non.
Déployez un nouveau serveur pour le service FHIR de Services de données de santé Azure.
Déployez d’abord un espace de travail de Services de données de santé Azure.
Déployez ensuite un serveur pour le service FHIR de Services de données de santé Azure. Plus d’informations : Déployer un service FHIR dans les Services de données de santé Azure
Configurez votre nouveau serveur pour le service FHIR de Services de données de santé Azure. Si vous devez utiliser les mêmes configurations que dans l’API Azure pour FHIR pour votre nouveau serveur, consultez la liste recommandée des éléments à rechercher dans la documentation de l’outil de migration. Configurez les paramètres avant de migrer.
Étape 3 : Migrer des données
Choisissez le modèle de migration qui convient le mieux à votre organisation. Si vous utilisez des outils de migration OSS, suivez les instructions sur GitHub.
Étape 4 : Migrer des applications et reconfigurer les paramètres
Migrer les applications qui pointaient vers l’ancien serveur FHIR.
Modifiez les points de terminaison sur vos applications afin qu’ils pointent vers l’URL du nouveau serveur FHIR.
Configurez à nouveau les autorisations pour ces applications.
Reconfigurez tous les paramètres restants dans le nouveau serveur pour le service FHIR de Services de données de santé Azure après la migration.
Si vous souhaitez vérifier deux fois que le service FHIR de Services de données de santé Azure et l’API Azure pour les serveurs FHIR ont les mêmes configurations, vous pouvez vérifier les deux points de terminaison de métadonnées pour comparer et contraster les deux serveurs.
Configurez les travaux qui s’exécutaient précédemment dans votre ancienne API Azure pour le serveur FHIR (par exemple, travaux $export)
Étape 5 : Basculer vers le service FHIR de Services de données de santé Azure
Une fois que vous êtes certain que votre serveur pour le service FHIR de Services de données de santé Azure est stable, vous pouvez commencer à utiliser le service FHIR de Services de données de santé Azures pour répondre à vos scénarios d’entreprise. Désactivez les pipelines restants qui s’exécutent sur l’API Azure pour FHIR, supprimez les données du compte de stockage intermédiaire utilisé dans l’outil de migration si nécessaire, supprimez les données de votre serveur Azure API pour FHIR et désactivez votre API Azure pour le compte FHIR.