Questions fréquentes (FAQ) sur l’API Azure pour FHIR

FHIR (Prononcez "fire") ou Fast Healthcare Interoperability Resources est une norme d’interopérabilité destinée à permettre l’échange de données médicales entre différents systèmes de santé. Cette norme a été développée par l’organisation HL7 et est en cours d’adoption par les organisations de la santé du monde entier. La version actuelle de FHIR est la version R4 (Release 4). L’API Azure pour FHIR prend en charge R4 et la version précédente STU3 (Standard for Trial Use 3). Pour plus d’informations sur FHIR, accédez à HL7.org.

Oui, les données sont stockées dans des bases de données managées dans Azure. L’API Azure pour FHIR ne fournit pas d’accès direct au magasin de données sous-jacent.

Dans le service managé, vous ne pouvez pas accéder aux données sous-jacentes. Il s’agit de s’assurer que l’API Azure pour FHIR offre les certifications de confidentialité et de conformité nécessaires aux données médicales. Si vous avez besoin d’accéder aux données sous-jacentes, vous pouvez utiliser le serveur FHIR open source.

Nous prenons en charge Microsoft Azure Active Directory en tant que fournisseur d’identité.

Non, nous ne prenons pas en charge B2C dans l’API Azure pour FHIR. Si vous avez besoin de contrôles d’accès plus précis, nous vous recommandons de consulter le proxy FHIR open source.

Les données du service managé sont sauvegardées automatiquement toutes les 4 heures et deux sauvegardes sont conservées. La durée de rétention est donc de 8 heures. La récupération des données est effectuée par l’équipe de support technique et l’objectif de point de récupération (RPO) est inférieur à 240 minutes.

Les clients peuvent effectuer une demande pour restaurer les données ou modifier la stratégie de sauvegarde de données par défaut via un ticket de support.

Nous prenons en charge les versions 4.0.0 et 3.0.1. Pour plus d’informations, consultez Fonctionnalités prises en charge pour FHIR. Vous pouvez également découvrir ce qui a changé entre les versions de FHIR (lors du passage de la version STU3 à la version R4) dans l’historique des versions de HL7 FHIR.

Le connecteur Azure IoT pour FHIR (préversion) ne prend actuellement en charge que la version R4 de FHIR, et est visible sur les instances R4 de l’API Azure pour FHIR.

L’API Azure pour FHIR est un service FHIR managé en disponibilité générale. Les Services de données de santé Azure vous permettent de déployer un service FHIR et un service DICOM dans le même espace de travail. La vue d’ensemble des Services de données de santé Azure fournit plus d’informations.

L’API Azure pour FHIR est une version hébergée et managée de la version open source de Microsoft FHIR Server pour Azure. Dans le service managé, Microsoft fournit toutes les opérations de maintenance et mises à jour.

Lorsque vous exécutez le serveur FHIR pour Azure, vous avez un accès direct aux services sous-jacents, mais vous êtes responsable de la maintenance et de la mise à jour du serveur, ainsi que de tout travail de conformité requis en cas de stockage de données PHI.

Elle est en disponibilité générale pour le grand public et le secteur public dans plusieurs régions géographiques. Pour plus d’informations sur les services cloud de Microsoft pour le secteur public, consultez Services Azure du FedRAMP.

La page des notes de publication fournit une vue d’ensemble de tout ce qui a été distribué via le service managé au cours du mois précédent.

Pour plus d’informations sur les mises en production dans l’API Azure pour FHIR, consultez les versions du serveur FHIR open source. Nous avons travaillé à étiqueter des éléments avec Azure-API-for-FHIR s’ils sont libérés dans le service managé et sont généralement disponibles deux semaines après leur publication dans la page de publication en open source. Nous avons également inclus des instructions sur la façon de tester le build dans votre propre environnement, si vous le souhaitez.

Pour voir quel package de version se trouve actuellement dans le service managé, vous pouvez afficher l’énoncé de capacité de l’API Azure pour FHIR sous la propriété software.version. Vous verrez quel package est déployé.

Vous pouvez trouver la version exacte de FHIR exposée dans l’énoncé de capacité sous la propriété fhirVersion.

Non. Nous n’avons pas de moyen de modifier la version d’une base de données existante. Vous devrez créer une API Azure pour FHIR et recharger les données. Vous pouvez utiliser le convertisseur JSON vers FHIR pour commencer à convertir des données STU3 en R4.

Non. Vous ne pouvez pas modifier l’URL de l’API Azure pour FHIR.

SMART (Substitutable Medical Applications and Reusable Technology) sur FHIR est un ensemble de spécifications ouvertes qui permettent d’intégrer les applications partenaires avec les serveurs FHIR et d’autres systèmes informatiques médicaux, par exemple les dossiers médicaux électroniques et les échanges d’informations médicales. En créant une application SMART sur FHIR, vous avez la garantie que votre application est accessible et exploitable par une multitude de systèmes distincts. Pour plus d’informations sur SMART, visitez le site web SMART Health IT.

Oui, la fonctionnalité SMART sur FHIR est prise en charge à l’aide d’exemples AHDS. C’est ce que l’on appelle SMART sur FHIR (amélioré). SMART on FHIR(Enhanced) peut être considéré comme répondant aux exigences avec le guide d’implémentation de SMART on FHIR (v 1.0.0) et §170.315(g)(10) critère d’API standardisée pour les patients et les services de population. Pour plus d’informations, consultez la documentation SMART on FHIR(Enhanced).

Nous n’autorisons pas les ressources FHIR personnalisées. Si vous avez besoin d’une ressource FHIR personnalisée, vous pouvez créer une ressource personnalisée en plus de la Ressource de base avec des extensions.

Nous vous autorisons à charger toutes données JSON FHIR valides dans le serveur. Si vous souhaitez stocker la définition de structure qui définit l’extension, vous pouvez l’enregistrer en tant que ressource de définition de structure. Pour effectuer une recherche sur les extensions, vous devez définir vos propres paramètres de recherche.

Votre ressource doit être juste inférieure à 2 Mo. Il s’agit d’une limitation du magasin de données sous-jacent et nous ne pouvons pas augmenter cette valeur.

Dans le service managé, nous prenons uniquement en charge JSON. Le serveur FHIR open source prend en charge JSON et XML. Pour afficher la version XML dans open source, utilisez _format= application/fhir+xml.

La limite actuelle de _count est 1000. Si vous définissez _count sur une valeur supérieure à 1000, un avertissement apparaît dans l’offre groupée, indiquant que seuls 1 000 enregistrements seront présentés.

Pour l’exportation de groupe, vous exportez uniquement les références incluses à partir du groupe, et non toutes les caractéristiques de la ressource de groupe.

Nous autorisons la publication de bundles par lot, mais pas de bundles transactionnels dans l’API Azure pour FHIR. Vous pouvez utiliser le service FHIR dans les Services de données de santé Azure si vous avez besoin d’une prise en charge du bundle de transactions.

Vous pouvez utiliser l’opération patient-$everything ou utiliser une recherche de compartiment dans l’API Azure pour FHIR. Cela vous permet d’obtenir toutes les ressources associées à un patient spécifique. Notez que le compartiment du patient contient maintenant toutes les ressources associées au patient, mais pas le patient lui-même. Vous devrez également effectuer une recherche pour obtenir le patient si vous avez besoin d’inclure la ressource patient dans vos résultats.

Nous prenons en charge le tri sur la date de dernière mise à jour : _sort =_lastUpdated. Nous prenons également en charge _sort sur les éléments FirstName, LastName, BirthDate et ClinicalDate. Pour plus d’informations sur les autres paramètres de recherche pris en charge, consultez Vue d’ensemble de la recherche FHIR.

Oui, nous prenons en charge l’opération patient-$everything. Pour plus d’informations, consultez le guide pratique sur patient-$everything.

Non, l’API Azure pour FHIR ne prend pas en charge les opérations de terminologie aujourd’hui.

La commande $export fait partie de la spécification FHIR. Si le service FHIR est configuré avec une identité gérée et un compte de stockage, et si l’identité gérée a accès à ce compte de stockage, vous pouvez appeler la commande $export sur l’API FHIR pour exporter toutes les ressources FHIR vers le compte de stockage. Pour plus d’informations, consultez l’article $export.

Nous avons un outil open source qui permet de dépersonnaliser les données FHIR. La même technologie est également intégrée à l’API Azure pour FHIR sous la forme d’une exportation dépersonnalisée.

L’exportation anonyme est actuellement prise en charge uniquement sur une exportation complète du système (/$export) et non pour l’exportation de patients (/Patient/$export). Nous travaillons également à la mise à disposition au niveau du patient.

Il existe deux types de suppression de base pris en charge dans l’API Azure pour FHIR. Il s’agit de la suppression et de la suppression conditionnelle.

• Avec la suppression, vous pouvez choisir d’effectuer une suppression réversible (type le plus courant) et de pouvoir toujours récupérer les versions historiques de votre enregistrement.
• Avec la suppression conditionnelle, vous pouvez passer un critère de recherche pour supprimer une ressource d’un élément à la fois ou plusieurs à la fois.
• Avec la suppression ou la suppression conditionnelle, si vous avez transmis le paramètre hardDelete, tous les enregistrements et l’historique sont supprimés et irrécupérables.

Vous pouvez récupérer des fichiers supprimés si vous n’utilisez pas le paramètre hardDelete. Le ou les enregistrements dans l’API Azure pour FHIR doivent toujours exister. Vous les trouverez en effectuant une recherche d’historique sur la ressource et en recherchant la dernière version avec des données.

Pour plus d’informations sur l’activation des journaux d’audit et des exemples de requêtes, consultez Activer la journalisation des diagnostics dans l’API Azure pour FHIR. Si vous souhaitez inclure des informations supplémentaires dans les journaux, consultez Utiliser des en-têtes HTTP personnalisés.

Pour résoudre ce problème, vous pouvez augmenter votre débit ou basculer vers la mise à l’échelle automatique pour vous assurer que vous disposez de ressources de calcul suffisantes pour traiter les demandes. Si vous continuez à rencontrer des problèmes, veuillez créer un ticket de support.

La valeur minimale pour les RU doit être d’au moins 40 RU par Go. Lorsque vous chargez des données, les RU sur la base de données augmenteront si vous êtes en-dessous de cette valeur minimale.

Nous avons une collection d’architectures de référence disponibles dans la page Health Architecture sur GitHub.

Pour effectuer des case activée d’intégrité sur le service FHIR, entrez {{fhirurl}}/health/check dans la requête GET. Vous devriez être en mesure de voir l’état du service FHIR. Réponse du code d’état HTTP avec 200 et OverallStatus comme « Sain » en réponse, signifie que votre case activée d’intégrité réussit. En cas d’erreurs, vous recevrez une réponse d’erreur avec le code http status 404 (introuvable) ou status code 500 (erreur interne du serveur) et des informations détaillées dans le corps de la réponse dans certains scénarios.

Oui, l’API Azure pour FHIR permet de configurer des clés gérées par le client, en tirant parti de la prise en charge d’Azure Cosmos DB. Pour plus d’informations sur le chiffrement de vos données avec une clé personnelle, consultez Configurer des clés gérées par le client sur REST.