Cet article fait partie d'une série sur les sessions de Health Samurai lors du HL7 FHIR DevDays 2025. Dans cet article, intitulé « Contrôle d'accès granulaire natif FHIR », Rostislav Antonov, ingénieur logiciel chez Health Samurai, montre comment les étiquettes de sécurité FHIR peuvent protéger les données cliniques sensibles tout en maintenant les dossiers utilisables pour les équipes soignantes.
Ce que vous apprendrez :
- Pourquoi différents cliniciens (par exemple, les psychiatres par rapport aux médecins généralistes) ont besoin de vues différentes du même dossier patient.
- Comment les étiquettes de sécurité FHIR fonctionnent à la fois au niveau de la ressource et au niveau de l'élément (champ).
- Comment le serveur FHIR Aidbox implémente le contrôle d'accès basé sur les étiquettes à l'aide du filtrage en base de données et du masquage en ligne.
- Les principaux compromis en matière de confidentialité, de sécurité, de performance et de conformité FHIR.
Pourquoi les rôles ne suffisent pas
Les données de santé mêlent souvent des informations hautement sensibles (adresses, identifiants, notes psychiatriques) à des informations cliniques courantes au sein d'une même ressource. Un contrôle d'accès simple basé sur les rôles à l'échelle des ressources entières ne peut pas offrir à un psychiatre et à un médecin généraliste des vues appropriément différentes sans masquer trop ou exposer trop. Le modèle décrit dans la conférence suppose que le système doit être en mesure de masquer des champs spécifiques tout en retournant le reste de la ressource, de façon cohérente pour tous les utilisateurs et tous les cas d'utilisation.
Les étiquettes de sécurité FHIR en pratique
FHIR fournit des étiquettes de sécurité qui peuvent exprimer la confidentialité et la finalité d'utilisation à l'aide de systèmes de codes HL7. La conférence distingue les étiquettes hiérarchiques (par exemple, les niveaux de confidentialité où « restreint » inclut « normal ») des étiquettes plates (telles que les codes de finalité d'utilisation sans hiérarchie). Les étiquettes peuvent être placées sur la ressource (meta.security) ou en ligne au niveau de l'élément via des extensions, permettant des modèles tels que des « observations réservées à la psychiatrie » ou une adresse domiciliaire marquée comme sensible quant à la localisation, tandis qu'une adresse de facturation reste visible.
Vérification d'accès à deux niveaux
Le contrôle d'accès combine des vérifications au niveau de la ressource et au niveau de l'élément. D'abord, chaque ressource est stockée avec des étiquettes de sécurité, et chaque utilisateur dispose d'un ensemble d'étiquettes dérivé de son identité et de ses jetons. Les requêtes entrantes sont réécrites avec des filtres basés sur les étiquettes, de sorte que la base de données ne retourne que les ressources dont les étiquettes correspondent à celles de l'utilisateur. Ensuite, les étiquettes en ligne sont évaluées au fur et à mesure que le serveur parcourt chaque ressource : les champs autorisés sont retournés normalement ; les champs bloqués sont remplacés par une extension data-absent-reason pour indiquer que la valeur est intentionnellement masquée. Cela permet de maintenir les règles d'accès indépendantes du type de ressource tout en évitant la duplication des enregistrements.
Avantages et compromis
Utilisées de cette façon, les étiquettes de sécurité offrent un contrôle granulaire, réutilisent les normes HL7/FHIR existantes et prennent en charge les politiques basées sur les rôles et sur les attributs. Dans le même temps, la conférence souligne d'importants compromis : les marqueurs « absent » visibles et les étiquettes peuvent révéler l'existence de données masquées ; le masquage d'éléments obligatoires peut enfreindre la conformité stricte à FHIR ; et le parcours au niveau des éléments engendre une surcharge de performance mesurable. La politique d'accès ne peut donc pas être purement technique : les déploiements doivent décider comment équilibrer transparence, confidentialité et exactitude.
Considérations opérationnelles et démonstration
Sur le plan opérationnel, le modèle repose sur une gestion rigoureuse des étiquettes et sur l'audit. Les étiquettes des utilisateurs proviennent des systèmes d'identité, les clients doivent étiqueter correctement les ressources, et les données historiques peuvent nécessiter des migrations de ré-étiquetage. Une étiquette « bris de verre » (break-glass) permet des remplacements d'urgence, mais exige une journalisation rigoureuse ; les implémentations actuelles se concentrent davantage sur la protection en lecture que sur la protection en écriture, comme la suppression d'étiquettes. Les scénarios de démonstration montrent comment les étiquettes basées sur JWT orientent les appels Postman, où un utilisateur voit à la fois les observations psychiatriques et générales et un autre ne voit que les observations générales, ou encore où seules certaines adresses sont visibles, illustrant ainsi la divulgation sélective sans duplication des ressources.
Comment cela aide les équipes FHIR
Pour les organisations qui mettent en œuvre des systèmes basés sur FHIR, cette approche montre comment les étiquettes de sécurité FHIR standard peuvent constituer le socle d'un contrôle d'accès granulaire plutôt qu'un modèle propriétaire. Elle démontre que les étiquettes au niveau de la ressource et au niveau de l'élément peuvent coexister pour prendre en charge des politiques expressives et interopérables, tandis que la discussion explicite des risques de divulgation, de performance et d'écriture aide les équipes à concevoir des déploiements qui reconnaissent clairement leurs compromis plutôt que de traiter les étiquettes comme une solution complète.
Ressources
Regardez la présentation complète de Rostislav au FHIR DevDays 2025 ainsi que la liste de lecture complète de Health Samurai : Regarder la vidéo complète Liste de lecture complète sur YouTube
Connectez-vous avec Rostislav sur LinkedIn.
Voir aussi : RBAC avec Keycloak et SMART on FHIR V2.
