Fonctionnalités
L’API Azure pour FHIR® fournit un déploiement entièrement managé du serveur Microsoft FHIR 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 | Consultez la remarque suivante. |
recherche chaînée inversée | Oui | Oui | Consultez la remarque suivante. |
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 basé sur les rôles
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 FhirServer:Security:Enabled
paramètre de configuration est défini true
sur , et toutes les requêtes (sauf /metadata
) sur le serveur FHIR doivent avoir Authorization
un en-tête de requête défini sur Bearer <TOKEN>
. Le jeton doit contenir au moins un rôle tel que défini dans la revendication roles
. Une demande est autorisée si le jeton contient un rôle qui autorise 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 avez 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 données/documents doivent être 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 des ressources : taille de ressource individuelle, y compris l’historique, ne doit pas dépasser 20 Go.
Étapes suivantes
Dans cet article, vous lisez 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
Remarque
FHIR® est une marque déposée de HL7 utilisé avec l’autorisation de HL7.