Partager via


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

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 truesur , 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.