Stratégies de migration pour le déplacement à partir de l’API Azure pour FHIR
Important
L’API Azure pour FHIR sera supprimée le 30 septembre 2026. Suivez les stratégies de migration pour passer au service FHIR Azure Health Data Services à cette date. En raison de la mise hors service de l’API Azure pour FHIR, les nouveaux déploiements ne seront pas autorisés à compter du 1er avril 2025. Le service FHIR Azure Health Data Services 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 Azure Health Data Services 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é.
Lorsque vous migrez vos données FHIR de l’API Azure pour FHIR vers le service FHIR Azure Health Data Services, 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 fonctionnalités et fonctionnalités qui ne sont pas disponibles dans l’API Azure pour FHIR.
L’API Azure pour FHIR sera supprimée le 30 septembre 2026. Vous devez donc migrer vos données FHIR vers le service FHIR Azure Health Data Services dès que possible. Pour faciliter le processus, nous avons créé des outils et des conseils pour vous aider à évaluer votre préparation, préparer vos données, migrer vos applications et basculer vers le 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 Azure Health Data Services
Étape 1 : Évaluer la préparation
Comparez les différences entre l’API Azure pour FHIR et Azure Health Data Services. 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 | Soutenu: • RBAC local • SMART sur le proxy FHIR |
Dépréciation planifiée : • RBAC local (9/6/23) • SMART sur le proxy 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 entraîne des frais | Activé par défaut sans frais supplémentaires |
| Paramètres de recherche | Type de bundle pris en charge : Batch • Inclure et réinsérer, modificateur itérer non 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 • Inclure, revinclude et itérer le modificateur est pris en charge • Tri pris en charge par les champs chaîne et dateTime |
| Événements | Non pris en charge | Prise en charge |
| Infrastructure | Soutenu: • Clés gérées par le client • Support AZ et PITR • Récupération d’urgence interrégion |
Soutenu: • Récupération de données • Clés gérées par le client Prochaine: • Prise en charge des zones de disponibilité |
Éléments à prendre en compte susceptibles d’affecter votre architecture
L’agent de synchronisation est déconseillé. Si vous utilisez l’agent de synchronisation pour vous connecter à Dataverse, consultez Vue d’ensemble du kit de ressources d’intégration de données
Le proxy FHIR est déconseillé. Si vous utilisez le proxy FHIR pour les événements, reportez-vous à la fonctionnalité d’événementing intégrée. Les alternatives peuvent être personnalisées et créées à l’aide du kit de ressources Azure Health Data Services.
SMART sur le proxy FHIR est déconseillé. Vous devez utiliser la nouvelle fonctionnalité SMART sur FHIR. Plus d’informations : SMART sur FHIR
Le service FHIR Azure Health Data Services 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 locataire 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 réussi par le service MedTech. Vous devez déployer un service MedTech et un service FHIR correspondant dans un espace de travail Azure Health Data Services 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 du connecteur IoT existants avec le déploiement du service MedTech.
Si vous souhaitez migrer des données FHIR d’appareil de connecteur IoT existantes de votre API Azure pour FHIR vers le service FHIR Azure Health Data Services, utilisez la fonctionnalité d’exportation et d’importation en bloc dans l’outil de migration. Un autre chemin 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 Azure Health Data Services. • Le dépôt GitHub fournit des conseils sur l’exécution de ces commandes et 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 du 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, passez en revue et comprenez les fonctionnalités et limitations de l’outil de migration.
Préparer l’API Azure pour le serveur FHIR
Identifiez les données à migrer.
Profitez de cette occasion pour propre des serveurs FHIR ou des données que vous n’utilisez plus.
Déterminez si vous souhaitez migrer des versions historiques ou non.
Déployez un nouveau serveur de service FHIR Azure Health Data Services.
Tout d’abord, déployez un espace de travail Azure Health Data Services.
Déployez ensuite un serveur de service FHIR Azure Health Data Services. Plus d’informations : Déployer un service FHIR dans Azure Health Data Services
Configurez votre nouveau serveur de service FHIR Azure Health Data Services. 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 à case activée 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
Migrez des 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 de service FHIR Azure Health Data Services après la migration.
Si vous souhaitez doubler case activée pour vous assurer que le service FHIR Azure Health Data Services et l’API Azure pour les serveurs FHIR ont les mêmes configurations, vous pouvez case activée les deux points de terminaison de métadonnées pour comparer et comparer les deux serveurs.
Configurez les travaux qui s’exécutaient précédemment dans votre ancienne API Azure pour le serveur FHIR (par exemple, $export travaux)
Étape 5 : Basculer vers les services FHIR Azure Health Data Services
Une fois que vous êtes certain que votre serveur de service FHIR Azure Health Data Services est stable, vous pouvez commencer à utiliser le service FHIR Azure Health Data Services pour répondre à vos scénarios métier. 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.