Notes de publication 2024 : Azure Health Data Services
Cet article décrit les fonctionnalités, les améliorations et les correctifs de bogues publiés en 2024 pour le service FHIR®, le service DICOM® et le service MedTech dans Azure Health Data Services.
Octobre 2024
Azure Health Data Services
Service FHIR
Résolution des bogues
- Validation de l’exportation : un problème a été identifié où les exportations se sont déroulées malgré des paramètres de recherche non valides. Nous introduisons un changement qui empêche les exportations dans ces conditions. Cette fonctionnalité se trouve actuellement derrière un indicateur de validation strict et devient le comportement par défaut le 30 octobre ou après le 30 octobre.
- Inclusion des paramètres de recherche : nous avons résolu un problème où des paramètres de recherche supplémentaires (par exemple,
_include,_has) n’ont pas retourné tous les résultats attendus, omettant parfois le lien suivant. - Exécution du travail d’exportation : une occurrence rare de la fin du
System.ObjectDisposedExceptiontravail d’exportation a été traitée en empêchant les sorties prématurées. - Mise à jour du code d’état HTTP : le code d’état HTTP pour les paramètres non valides pendant la
$reindexcréation du travail est désormais mis à jour vers la version 400, ce qui garantit une meilleure gestion des erreurs. - Nettoyage des paramètres de recherche : un correctif a été implémenté pour garantir le nettoyage complet des paramètres de recherche dans la base de données lorsqu’ils sont déclenchés avec des appels d’API de suppression, en traitant les problèmes liés aux suppressions incomplètes.
- Problème de tri décroissant : résolution d’un problème où les opérations de tri décroissantes n’ont retourné aucune ressource si le champ trié n’avait pas de données dans la base de données, même quand des ressources pertinentes existaient.
- Gestion des échecs d’authentification : ajout d’un nouveau bloc catch pour gérer les échecs d’authentification lorsque les demandes d’importation sont exécutées avec l’identité managée désactivée.
Septembre 2024
Azure Health Data Services
Service FHIR
Amélioration de l’efficacité de l’exportation
La fonctionnalité d’exportation a été améliorée pour optimiser l’utilisation de la mémoire. Avec cette modification, le processus d’exportation envoie désormais des données au stockage d’objets blob une ressource à la fois, ce qui réduit la consommation de mémoire.
Août 2024
Azure Health Data Services
Service FHIR
Gestion des erreurs d’opération d’importation
- L’opération d’importation retourne une erreur HTTP 400 lorsqu’une ressource de paramètre de recherche est ingérée via le processus d’importation. Cette modification est destinée à empêcher les paramètres de recherche d’être placés dans un état non valide lors de l’ingestion avec une opération d’importation.
- L’opération d’importation retourne un code d’état HTTP 400, par opposition au code d’état HTTP 500 précédent, dans les cas où des problèmes de configuration avec le compte de stockage se produisent. Cette mise à jour vise à améliorer la gestion des erreurs associée aux identités managées pendant les opérations d’importation.
Juillet 2024
Azure Health Data Services
Service FHIR
Autoriser les dates dans les données JSON à traiter comme des chaînes dans l’opération Convert-Data
Il est possible que les dates fournies dans les données JSON soient retournées dans un format différent de celui fourni. Lors de la désérialisation des chaînes de charge utile JSON identifiées en tant que dates converties en objets DateTime .NET. Ces objets sont ensuite convertis en chaînes avant de passer par le moteur de modèle Liquid. Cette conversion peut entraîner la reformaté et la représentation de la valeur de date dans le fuseau horaire local du service FHIR.
La contrainte des chaînes aux objets DateTime .NET peut être désactivée à l’aide du paramètre jsonDeserializationTreatDatesAsStringsbooléen . Lorsque la valeur est définie true, les données fournies sont traitées comme une chaîne et ne seront pas modifiées avant d’être fournies au moteur Liquid.
Amélioration de l’opération d’importation
Le service FHIR autorise désormais l’ingestion de données sans spécifier de version au niveau de la ressource. L’ordre des ressources est conservé à l’aide de la valeur lastUpdated. Cette amélioration introduit l’indicateur « allowNegativeVersions ». La définition de l’indicateur true permet au service FHIR d’affecter des versions négatives pour les enregistrements de ressources avec une valeur lastUpdated explicite et aucune version spécifiée.
Correctifs de bogues
- Correction de l’inclusion de ressources supprimées réversibles lors de l’utilisation du paramètre de recherche _security :not search Lors de l’utilisation du paramètre de recherche _security :not dans les opérations de recherche, les ID des ressources supprimées de manière réversible étaient inclus dans les résultats de la recherche. Nous avons résolu le problème afin que les ressources supprimées de manière réversible soient désormais exclues des résultats de recherche.
- L’exportation de données en tant qu’utilisateur SMART Exportant des données en tant qu’utilisateur SMART ne nécessite plus d’étendues d’écriture. Auparavant, il était nécessaire d’accorder des privilèges d’écriture à un utilisateur SMART pour exporter des données, ce qui implique des niveaux de privilèges supérieurs. Pour lancer un travail d’exportation en tant qu’utilisateur SMART, assurez-vous que l’utilisateur est membre du rôle d’exportation FHIR dans RBAC et demande l’étendue clinique SMART « read ». Mise à jour du code d’état de HTTP 500 vers HTTP 400
- Mise à jour du code d’état de HTTP 500 vers HTTP 400 Lors d’une opération corrective, si la charge utile a demandé une mise à jour pour un type de ressource autre que le paramètre, une erreur de serveur interne (HTTP 500) a été levée initialement. Cette opération a été mise à jour pour lever une erreur HTTP 400 à la place.
Optimisation des performances
L’optimisation des requêtes est ajoutée lors de la recherche de ressources FHIR avec une plage de données. Cette optimisation des requêtes permet d’effectuer des requêtes efficaces au fur et à mesure que l’un des CTE combinés est généré.
Mai 2024
Azure Health Data Services
Service FHIR
Amélioration de la mise à l’échelle vers l’opération d’importation
La logique de mise à l’échelle pour les opérations d’importation est améliorée, ce qui permet à plusieurs travaux d’être exécutés en parallèle. Cette modification a un impact sur les journaux d’audit pour l’opération d’importation. Les journaux d’audit des travaux d’importation individuels ont plusieurs lignes, chaque ligne correspondant à un travail de traitement interne.
Résolution des bogues
- Correction : code d’état HTTP pour les requêtes de longue durée. Les requêtes FHIR qui prennent plus de 100 secondes pour exécuter un code d’état HTTP 408 au lieu de HTTP 500.
- Résolu : demande d’historique dans le bundle. Avant le correctif, la demande d’historique dans un bundle a retourné le code d’état HTTP 404.
Convertisseur FHIR autonome (préversion)
L’API de convertisseur FHIR autonome disponible pour la préversion est découplée du service FHIR et empaquetée en tant qu’image conteneur (Docker). En plus de vous permettre de convertir des données de la source d’enregistrement en bundles FHIR R4, le convertisseur FHIR offre :
- Conversion bidirectionnelle des données de la source d’enregistrement vers des bundles FHIR R4 et retour. Par exemple, le convertisseur FHIR peut convertir les données du format FHIR R4 au format HL7v2.
- Expérience améliorée pour la personnalisation des modèles Liquid par défaut.
- Exemples qui montrent comment créer un pipeline ETL (extraire, transformer, charger) avec Azure Data Factory (ADF).
Pour implémenter l'image du conteneur du convertisseur FHIR, consultez le projet GitHub du convertisseur FHIR.
Avril 2024
Service DICOM
Opération Upsert améliorée
L’opération Upsert améliorée vous permet de charger une image DICOM sur le serveur et de la remplacer en toute transparence s’il existe déjà. Avant cette amélioration, les utilisateurs devaient effectuer une opération Delete suivie d’un STOW-RS pour obtenir le même résultat. Avec l’opération Upsert améliorée, la gestion des images DICOM est plus efficace et simplifiée.
Stockage développé pour les attributs requis
Le service DICOM permet aux utilisateurs de charger des fichiers DICOM jusqu’à 4 Go de taille. Aucun fichier DICOM unique ou combinaison de fichiers dans une requête unique n’est autorisé à dépasser cette limite.
Service FHIR
L’opération de suppression en bloc est généralement disponible
L’opération de suppression en bloc permet la suppression de ressources FHIR à différents niveaux, ce qui permet aux organisations de santé de se conformer aux stratégies de rétention des données tout en fournissant des fonctionnalités de traitement asynchrones. Les avantages de l’opération de suppression en bloc sont les suivants :
- Exécuter la suppression en bloc à différents niveaux : l’opération de suppression en bloc vous permet de supprimer des ressources du serveur FHIR de manière asynchrone. Vous pouvez exécuter la suppression en bloc à différents niveaux :
- Niveau système : active la suppression des ressources FHIR sur tous les types de ressources.
- Type de ressource individuel : autorise la suppression de ressources FHIR spécifiques.
- Personnalisable : les paramètres de requête autorisent le filtrage des ressources brutes pour les suppressions ciblées.
- Traitement asynchrone : l’opération est asynchrone, fournissant un point de terminaison d’interrogation pour suivre la progression.
En savoir plus :
Mars 2024
Service DICOM
L’intégration à Azure Data Lake Storage est généralement disponible
L’intégration d’Azure Data Lake Storage pour le service DICOM dans Azure Health Data Services est généralement disponible. Le service DICOM fournit un stockage à l’échelle du cloud pour les données d’imagerie médicale à l’aide de la norme DICOMweb. Grâce à l’intégration d’Azure Data Lake Storage, les organisations peuvent bénéficier d’un contrôle total sur leurs données d’imagerie et bénéficier d’une flexibilité accrue pour accéder à ces données et les utiliser via l’écosystème et les API de stockage Azure.
En utilisant Azure Data Lake Storage avec le service DICOM, les organisations sont en mesure de :
- Autorisez l’accès direct aux données d’imagerie médicale stockées par le service DICOM à l’aide des API de stockage Azure et des API DICOMweb, ce qui offre une plus grande flexibilité pour accéder aux données et les utiliser.
- Ouvrez les données d’imagerie médicale jusqu’à l’ensemble de l’écosystème d’outils permettant d’utiliser le stockage Azure, notamment AzCopy, Explorateur Stockage Azure et la bibliothèque de déplacement des données.
- Déverrouillez de nouvelles analyses et scénarios IA/ML à l’aide de services qui s’intègrent en mode natif à Azure Data Lake Storage, notamment Azure Synapse, Azure Databricks, Azure Machine Learning et Microsoft Fabric.
- Accordez des contrôles pour gérer les autorisations de stockage, les contrôles d’accès, les niveaux et les règles.
En savoir plus :
- Gérer les données d’imagerie médicale avec le service DICOM et Azure Data Lake Storage
- Déployer le service DICOM avec Azure Data Lake Storage
Service FHIR
Parallélisation groupée (GA)
Les bundles sont exécutés en série dans le service FHIR par défaut. Pour améliorer le débit avec les appels groupés, nous avons activé le traitement parallèle.
En savoir plus :
L’opération d’importation accepte plusieurs types de ressources dans un seul fichier
L’opération d’importation autorisée à avoir un type de ressource par fichier d’entrée dans les paramètres de requête. Avec cette fonctionnalité améliorée, vous pouvez passer plusieurs types de ressources dans un seul fichier.
Résolution des bogues
Correction : l’opération d’importation ingère des ressources avec le même type de ressource et la même valeur de champ LastUpdated. Avant cette modification, les ressources exécutées dans un lot avec le même type et
lastUpdatedla même valeur de champ n’ont pas été ingérées dans le service FHIR. Ce correctif de bogue résout le problème. Voir PR#3768.Résolu : recherche FHIR avec 3 paramètres de recherche personnalisés ou plus. Avant ce correctif, une requête de recherche FHIR à la racine avec trois paramètres de recherche personnalisés ou plus a entraîné le code d’état HTTP 504. Voir PR#3701.
Correction : Améliorez les performances pour le traitement de l’offre groupée. Mises à jour de la méthode d’exécution de tâche, ce qui permet d’améliorer les performances du traitement de bundle. Voir PR#3727.
Février 2024
Service FHIR
Le comptage de toutes les versions des ressources est activé
Le paramètre _summary=count de requête et _count=0 peut être ajouté au _history point de terminaison pour obtenir le nombre de toutes les ressources avec version. Ce nombre inclut les ressources historiques et supprimées de manière réversible.
La recherche Revinclude peut référencer toutes les ressources avec un caractère générique
Le service FHIR prend en charge les recherches génériques avec revinclude. Ajoutez *.* au paramètre de requête d’une revinclude requête pour diriger le service FHIR pour référencer toutes les ressources mappées à la ressource source.
Résolution des bogues
Résolu : Améliorez le temps de réponse des requêtes FHIR avec des améliorations des performances. Pour améliorer les performances, un modificateur manquant peut être spécifié pour un paramètre de recherche utilisé pour le tri. Voir PR#3655.
Résolu : l’opération d’importation respecte l’ingestion des versions de ressources non séquentielles. Avant cette modification, le mode incrémentiel dans les versions supposées de l’opération
importest des entiers séquentiels. Après ce correctif de bogue, les versions peuvent être ingérées dans l’ordre non référentiel. Voir PR#3685.
Janvier 2024
Service DICOM
Mise à jour en bloc des fichiers
L’opération de mise à jour en bloc vous permet de modifier les métadonnées d’imagerie pour plusieurs fichiers stockés dans le service DICOM. Par exemple, la mise à jour en bloc vous permet de modifier des attributs DICOM pour une ou plusieurs études dans une opération asynchrone unique. Vous pouvez utiliser une API pour effectuer des mises à jour des données démographiques des patients et éviter le coût des chargements répétitifs.
Au-delà des gains d’efficacité, la fonctionnalité de mise à jour en bloc conserve un enregistrement des modifications dans le flux de modification et conserve les instances d’origine non modifiées pour la récupération ultérieure.
En savoir plus :
Service FHIR
Paramètres de recherche sélectionnables (préversion)
La fonctionnalité de paramètre de recherche sélectionnable disponible en préversion vous permet de personnaliser et d’optimiser les recherches sur les ressources FHIR. La fonctionnalité vous permet de choisir les paramètres de recherche intégrées à activer ou désactiver pour le service FHIR. En activant uniquement les paramètres de recherche dont vous avez besoin, vous pouvez stocker davantage de ressources FHIR et améliorer potentiellement les performances des requêtes de recherche FHIR.
En savoir plus :
Intégration du service FHIR à Azure Active Directory B2C
Les organisations de santé peuvent utiliser le service FHIR dans Azure Health Data Services avec Azure Active Directory B2C (Azure AD B2C). Les organisations bénéficient d’un moyen sécurisé et pratique d’accorder l’accès au service FHIR avec un contrôle d’accès précis pour différents utilisateurs ou groupes, sans créer ou venir des comptes d’utilisateur dans le locataire Microsoft Entra ID de leur organisation. Avec cette intégration, les organisations peuvent :
- Utilisez des fournisseurs d’identité supplémentaires pour authentifier et accéder aux ressources FHIR avec SMART sur les étendues FHIR.
- Gérez et personnalisez les droits d’accès utilisateur ou les autorisations avec des étendues SMART sur FHIR qui prennent en charge le contrôle d’accès précis, les types de ressources et les interactions FHIR et les privilèges sous-jacents d’un utilisateur.
Contenu associé :
- Utiliser Azure Active Directory B2C pour accorder l’accès au service FHIR
- Configurer plusieurs fournisseurs d’identité de service pour le service FHIR
- Résoudre les problèmes de configuration du fournisseur d’identité pour le service FHIR
- Activer SMART sur FHIR pour le service FHIR
- Exemple : Azure ONC (g)(10) SMART sur FHIR
Demander jusqu’à 100 To de stockage
Le service FHIR peut stocker et échanger de grandes quantités de données d’intégrité, et chaque instance de service FHIR a une limite de stockage de 4 To par défaut. Si vous avez plus de données, vous pouvez demander à Microsoft d’augmenter le stockage jusqu’à 100 To pour votre service FHIR.
Avec davantage de stockage, les organisations peuvent gérer des jeux de données volumineux pour activer des scénarios d’analytique. Par exemple, vous pouvez utiliser davantage de stockage pour gérer la santé de la population, effectuer des recherches et obtenir de nouveaux insights à partir des données de santé. De plus, davantage de stockage permet aux clients azure API pour FHIR avec des données à volume élevé (supérieures à 4 To) de migrer vers le service FHIR dans Azure Health Data Services.
Pour demander un stockage supérieur à 4 To, créez une demande de support sur le Portail Azure et utilisez la limite de service et d’abonnement du type de problème (quotas).
Remarque
En raison d’un problème lié aux métriques de facturation pour le stockage, les clients qui optent pour plus de 4 To de capacité de stockage ne seront pas facturés pour le stockage tant que le problème n’est pas résolu.