Fonctionnalités
L’API Azure pour FHIR fournit un déploiement complètement managé du serveur FHIR Microsoft pour Azure. Le serveur est une implémentation de la FHIR standard. Ce document répertorie les principales fonctionnalités du serveur FHIR.
Version FHIR
Dernière version prise en charge : 4.0.1
Versions antérieures également prises en charge : 3.0.2
API REST
Voici un résumé des fonctionnalités RESTful prises en charge. Pour plus d’informations sur l’implémentation de ces fonctionnalités, consultez Fonctionnalités de l’API REST FHIR.
| API | Azure API pour FHIR | Service FHIR dans les Services de données de santé Azure | Commentaire |
|---|---|---|---|
| lire | Oui | Oui | |
| vread | Oui | Oui | |
| mise à jour | Oui | Oui | |
| update with optimistic locking | Oui | Oui | |
| update (conditional) | Oui | Oui | |
| patch | Oui | Oui | Prise en charge du Patch JSON et du Patch FHIRPath uniquement. |
| patch (conditionnel) | Oui | Oui | Prise en charge du Patch JSON et du Patch FHIRPath uniquement. |
| history | Oui | Oui | |
| create | Oui | Oui | Prend en charge POST et PUT |
| create (conditional) | Oui | Oui | Problème no 1382 |
| search | Partiel | Partiel | Consultez Vue d’ensemble de la recherche FHIR. |
| recherche chaînée | Oui | Oui | Voir la Note ci-dessous. |
| recherche chaînée inversée | Oui | Oui | Voir la Note ci-dessous. |
| batch | Oui | Oui | |
| transaction | Non | Oui | |
| paging | Partiel | Partiel | self et next sont pris en charge |
| intermediaries | Non | N° |
Remarque
Dans l’API Azure pour FHIR et le serveur FHIR open source soutenus par Azure Cosmos DB, la recherche chaînée et la recherche en chaînée inversée sont une implémentation MVP. Pour effectuer une recherche chaînée sur Azure Cosmos DB, l’implémentation décrit l’expression de recherche et émet des sous-requêtes pour résoudre les ressources mises en correspondance. Cette opération est effectuée pour chaque niveau de l’expression. Si une requête retourne plus de 1 000 résultats, une erreur est levée.
Opérations étendues
Toutes les opérations prises en charge qui étendent l’API REST.
| Type de paramètre de recherche | Azure API pour FHIR | Service FHIR dans les Services de données de santé Azure | Commentaire |
|---|---|---|---|
| $export | Oui | Oui | Prend en charge le système, le groupe et le patient. |
| $convert-data | Oui | Oui | |
| $validate | Oui | Oui | |
| $member-match | Oui | Oui | |
| $patient-everything | Oui | Oui | |
| $purge-history | Oui | Oui |
Persistance
Le serveur FHIR Microsoft dispose d’un module de persistance enfichable (voir Microsoft.Health.Fhir.Core.Features.Persistence).
Le code open source de FHIR Server inclut une implémentation pour Azure Cosmos DB et SQL Database.
Azure Cosmos DB est une base de données multimodèle distribuée à l’échelle mondiale (NoSQL, MongoDB et autres). Il prend en charge différents niveaux de cohérence. Le modèle de déploiement par défaut configure le serveur FHIR avec une cohérence Strong, mais la stratégie de cohérence peut être modifiée (généralement assouplie) en envoyant une demande individuelle à l’aide de l’en-tête de demande x-ms-consistency-level.
Contrôle d’accès en fonction du rôle
Le serveur FHIR utilise l’ID Microsoft Entra pour le contrôle d’accès . Plus précisément, le contrôle d’accès en fonction du rôle (RBAC) est appliqué, si le paramètre de configuration FhirServer:Security:Enabled a la valeur true. De plus, l’en-tête de requête Authorization de toutes les requêtes (à l’exception de /metadata) envoyées au serveur FHIR Server doit avoir la valeur Bearer <TOKEN>. Le jeton doit contenir au moins un rôle tel que défini dans la revendication roles. Une demande sera autorisée si le jeton contient un rôle qui permet l’application de l’action spécifiée sur la ressource spécifiée.
Actuellement, les actions autorisées pour un rôle donné sont appliquées à l’ensemble de l’API.
Limites du service
Unités de requête (RU) : vous pouvez configurer jusqu’à 100 000 unités de requête dans le portail pour l’API Azure pour FHIR. Vous aurez besoin au minimum de 400 RU ou de 40 RU/Go, selon la valeur la plus grande. Si vous avez besoin de plus de 100 000 unités de requête, vous pouvez placer un ticket de support pour augmenter les unités de requête. Le maximum disponible est 1 000 000. En outre, nous prenons en charge la mise à l’échelle automatique des RU.
Taille de bundle : chaque bundle est limité à 500 éléments.
Taille des données : les éléments Données/Documents doivent chacun être un peu inférieurs à 2 Mo.
Limite d’abonnement : par défaut, chaque abonnement est limité à un maximum de 10 instances de serveur FHIR. Si vous avez besoin de plus d’instances par abonnement, ouvrez un ticket de support et fournissez des détails sur vos besoins.
Taille de la ressource : la taille de ressource individuelle, y compris l’historique, ne doit pas dépasser 20 Go.
Étapes suivantes
Dans cet article, vous avez obtenu des informations sur les fonctionnalités FHIR prises en charge dans l’API Azure pour FHIR. Pour plus d’informations sur le déploiement de l’API Azure pour FHIR, consultez
FHIR® est une marque déposée de HL7 utilisé avec l’autorisation de HL7.
Commentaires
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir: https://aka.ms/ContentUserFeedback.
Soumettre et afficher des commentaires pour