🔥 Étiquettes de sécurité FHIR : Contrôle d'accès à grain fin

Le problème fondamental

Les dossiers de santé ne constituent pas un fichier monolithique unique; ils forment une mosaïque de résultats de laboratoire, d'identifiants de facturation, de notes en santé mentale, de données démographiques et bien plus. Le défi consiste à donner aux professionnels de la santé uniquement les données dont ils ont besoin pour travailler efficacement. L'objectif est d'éviter d'exposer plus d'information que nécessaire. C'est ce principe du « besoin d'en connaître » que les étiquettes de sécurité sont conçues à faire respecter.

Examinons un exemple précis. Un psychiatre qui travaille avec un patient doit avoir accès à des informations très sensibles en santé mentale en plus des données générales liées aux soins. Une infirmière travaillant avec le psychiatre devrait également avoir accès aux notes en santé mentale. Cela dit, souhaitez-vous que d'autres infirmières lisent vos notes en santé mentale? Je ne le crois pas. De plus, un médecin généraliste peut avoir besoin de consulter les signes vitaux d'un patient, mais ne devrait pas avoir accès aux informations en santé mentale pour diverses raisons. Cette liste peut être infinie et dépend toujours des politiques propres à chaque établissement.

Tableau des permissions par rôle

Rôle	Doit voir	Ne doit PAS voir
Psychiatre	Fréquence cardiaque, Santé mentale	–
Infirmière	Fréquence cardiaque, Santé mentale?	Santé mentale (selon le contexte)
Médecin généraliste	Fréquence cardiaque	Santé mentale
Préposé à la facturation	Adresse de facturation, NAS	Adresse domiciliaire
Chercheur clinique	Signes vitaux dépersonnalisés	Noms, NAS

Point de vue du développeur FHIR

Les observations jouent un rôle clé dans les soins de santé, et dans FHIR, la ressource Observation est intentionnellement large. Elle peut représenter aussi bien une lecture de fréquence cardiaque qu'une mesure de tension artérielle ou un dépistage de la dépression — tous relevant du même type de ressource.

Mais tout le monde ne devrait pas voir les mêmes données. Lorsque votre application envoie une requête GET pour des observations, la réponse du serveur FHIR devrait dépendre de la personne qui utilise l'application. Par exemple, les médecins généralistes ne devraient pas voir les évaluations de la dépression, alors que les psychiatres en dépendent. C'est la même requête et le même Bundle — mais différents utilisateurs devraient obtenir des résultats différents.

Prenons une autre ressource FHIR — le Patient. Elle contient beaucoup d'informations, et souvent, les patients ont des adresses différentes à des fins domiciliaires, de facturation ou postales. Il se peut qu'ils ne souhaitent pas partager leur adresse domiciliaire avec tout le monde. Il en va de même pour leur numéro d'assurance sociale — un préposé à la facturation pourrait en avoir besoin, mais pas les autres membres du personnel de la clinique.

Toutes ces données vivent au sein de la même ressource Patient, il nous faut donc un moyen de masquer certains champs tout en exposant la ressource elle-même. Autrement dit, le contrôle d'accès doit être configurable non seulement au niveau de la ressource, mais aussi au niveau des éléments ou propriétés individuels.

Peut-on atteindre une telle granularité dans le contrôle d'accès?

La réponse de FHIR est l'étiquette de sécurité — un concept petit mais puissant attaché aux ressources.

Étiquettes de sécurité FHIR

Considérez cette image comme notre base de données FHIR. Nous pouvons attacher des étiquettes directement dans la base de données à chaque ressource, voire à des propriétés spécifiques au sein d'une ressource. Ces étiquettes indiquent au serveur FHIR qui est autorisé à voir quelles informations.

Les étiquettes de sécurité FHIR fonctionnent à deux niveaux de granularité distincts :

1. Les étiquettes au niveau de la ressource constituent l'approche la plus simple. Ces étiquettes s'attachent à l'ensemble d'une ressource FHIR via la propriété meta.security. Pensez-y comme des étiquettes qui indiquent « ce dossier Patient en entier est confidentiel » ou « cette Observation entière contient des informations sensibles ». Puisque meta.security est un tableau, vous pouvez attacher plusieurs étiquettes à une seule ressource — par exemple, marquer un dossier à la fois comme « confidentiel » et « lié à la santé mentale ».

{
  "meta": {
    "security": [
      {
        "code": "R",
        "system": "http://terminology.hl7.org/CodeSystem/v3-Confidentiality"
      },
      {
        "code": "PSY",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  ... rest of the resource
}

2. Les étiquettes au niveau de la propriété (également appelées étiquettes en ligne) offrent un contrôle beaucoup plus fin. Elles permettent de protéger des propriétés spécifiques au sein d'une ressource tout en laissant les autres propriétés accessibles. Pour utiliser les étiquettes au niveau de la propriété, vous devez d'abord ajouter un indicateur spécial PROCESSINLINELABEL à la propriété meta.security de la ressource. Vous pouvez ensuite attacher des étiquettes de sécurité à des propriétés individuelles à l'aide des extensions FHIR. Par exemple, vous pourriez protéger uniquement l'adresse domiciliaire dans une ressource Patient tout en gardant l'adresse de facturation visible.

{
  "meta": {
    "security": [
      {
        "code": "PROCESSINLINELABEL",
        "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
      }
    ]
  },
  "resourceType": "Patient",
  "address": [
    {
      "use": "home",
      "city": "Metropolis",
      "line": [
        "123 Confidential Ave"
      ],
      "state": "MA",
      "country": "US",
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
          "valueCoding": {
            "code": "LOCIS",
            "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"
          }
        }
      ]
    },
    {
      "use": "billing",
      "city": "Metropolis",
      "line": [
        "123 Non-Confidential Ave"
      ],
      "state": "MA",
      "country": "US"
    }
  ]
  ... rest of the resource
}

Anatomie d'une étiquette de sécurité FHIR

Les étiquettes de sécurité FHIR utilisent des systèmes de codes HL7 normalisés.

La v3 Confidentiality fonctionne de façon hiérarchique, à l'instar des niveaux d'habilitation de sécurité. Si vous disposez d'un accès « Restreint », vous voyez automatiquement les données aux niveaux inférieurs comme « Normal » et « Faible ».

L'ActCode et la finalité d'utilisation sont plats — soit vous possédez le code correspondant exact, soit vous ne l'avez pas. L'accès à un code ne confère pas l'accès aux autres.

Connaître le vocabulaire n'est que la moitié de l'histoire. Voyons comment un serveur FHIR utilise réellement ces étiquettes au moment d'une requête — de l'étiquetage des données au masquage des propriétés.

Fonctionnement des étiquettes de sécurité

Le flux de travail des étiquettes de sécurité suit trois étapes principales :

1. Étiqueter vos données et vos utilisateurs. Chaque ressource FHIR reçoit des étiquettes de sécurité, et les utilisateurs se voient attribuer des niveaux d'habilitation précisant les informations auxquelles ils peuvent accéder.

2. Faire correspondre les permissions des utilisateurs aux étiquettes des ressources. Lorsqu'un utilisateur demande des données, le moteur de contrôle d'accès compare l'habilitation de l'utilisateur aux étiquettes de sécurité de la ressource en appliquant ses règles configurées de correspondance d'étiquettes (p. ex., niveaux de dominance, étiquettes requises partielles ou totales, contraintes de finalité). L'accès n'est accordé que si ces règles sont satisfaites au niveau de la ressource.

3. Vérifier les restrictions au niveau de la propriété. Si une ressource contient l'indicateur PROCESSINLINELABEL, le serveur examine les propriétés individuelles au sein de cette ressource. Les propriétés auxquelles l'utilisateur ne peut pas accéder sont masquées à l'aide de l'extension standard FHIR data-absent-reason avec la valeur « masked ».

Détails d'implémentation

Voici comment nous avons implémenté ce flux de travail dans notre serveur FHIR, Aidbox :

1. Obtenir les permissions de l'utilisateur. Lorsqu'une requête arrive, Aidbox détermine d'abord le niveau d'accès de l'utilisateur en vérifiant ses étiquettes de sécurité à deux endroits : la revendication « scope » dans le jeton d'accès JWT et la propriété optionnelle User.securityLabel dans le dossier de l'utilisateur.

2. Développer les étiquettes hiérarchiques. Pour les codes de confidentialité, le système développe automatiquement la hiérarchie. Si un utilisateur dispose d'un accès « Restreint », Aidbox ajoute toutes les étiquettes de niveau inférieur (« Normal », « Faible », « Non restreint ») à ses permissions.

3. Appliquer le filtrage au niveau de la ressource. En coulisse, Aidbox injecte les étiquettes de sécurité de l'utilisateur dans le paramètre de recherche FHIR _security pour filtrer les ressources. Par exemple, si un utilisateur dispose d'une habilitation de confidentialité « R » (Restreint) et de l'étiquette « PSY » (information sur les troubles psychiatriques), une requête simple comme GET /fhir/Observation est transformée en :

GET 
/fhir/Observation?_security=http://terminology.hl7.org/CodeSystem/v3-Confidentiality|R,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|N,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|L,
http://terminology.hl7.org/CodeSystem/v3-Confidentiality|U,
http://terminology.hl7.org/CodeSystem/v3-ActCode|PSY

Étant donné qu'Aidbox utilise PostgreSQL comme base de données, cette requête FHIR est transformée en requête SQL. À ce stade, Aidbox applique le contrôle d'accès au niveau de la ressource, car la requête SQL ne retournera que les ressources dont les étiquettes de sécurité correspondent. Les ressources sans étiquettes ou avec des étiquettes non correspondantes sont automatiquement exclues des résultats.

4. Gérer l'accès au niveau de la propriété. Pour les ressources comportant l'indicateur PROCESSINLINELABEL, Aidbox examine chaque propriété portant des étiquettes de sécurité en ligne. Les propriétés accessibles sont retournées telles quelles, tandis que les propriétés restreintes sont masquées à l'aide de l'extension data-absent-reason.

Avantages

Voici un résumé des avantages des étiquettes de sécurité :

1. Interopérabilité. Les étiquettes de sécurité utilisent les systèmes de codes HL7 natifs.

2. Granularité au niveau de la ressource. Vous pouvez étiqueter des ressources individuelles avec plusieurs étiquettes plutôt que de construire le contrôle d'accès en fonction des types de ressources. Cela signifie que vous pouvez interroger toutes les Observations en toute sécurité sans craindre d'exposer des données sensibles en santé mentale à des utilisateurs qui ne devraient pas les voir.

3. Granularité au niveau de la propriété. Les étiquettes de sécurité en ligne permettent de masquer une seule propriété d'une ressource tout en exposant le reste de la ressource.

Compromis

Les étiquettes de sécurité comportent des compromis importants à prendre en compte :

1. La visibilité des étiquettes peut divulguer de l'information

Lorsque les utilisateurs voient les extensions data-absent-reason et les étiquettes de sécurité qui les accompagnent, un utilisateur malveillant peut immédiatement déterminer quel niveau d'accès est nécessaire pour voir les données masquées. Cela pourrait entraîner un problème de contrôle d'accès. Aidbox offre un indicateur strip labels pour supprimer les étiquettes de sécurité de la réponse.

2. Sécurité médicale contre fuite de données

La divulgation de l'absence de données peut elle-même constituer une fuite de données. Lorsque vous masquez des propriétés sensibles à l'aide de data-absent-reason="masked", vous indiquez à l'utilisateur : « il y a quelque chose ici que vous ne pouvez pas voir. » Pour des informations stigmatisantes telles que la santé mentale ou la toxicomanie, le simple fait de savoir que des données existent peut être problématique.

On pourrait dire : ne pas utiliser le masquage, mais plutôt supprimer complètement la propriété de la ressource comme si elle n'existait pas. Toutefois, cela introduit un autre problème — si les refus d'accès aux données ne sont pas signalés, ils pourraient être interprétés comme une absence de données, ce qui pourrait mener à des décisions médicales erronées.

Il n'y a pas de solution simple à cela. La décision doit être soigneusement pesée pour chaque cas.

3. Confidentialité contre conformité

La spécification FHIR exige que certaines propriétés de ressources soient présentes, mais les exigences de confidentialité pourraient vous obliger à les masquer. Que se passe-t-il lorsque nous modifions une propriété FHIR obligatoire? Cela signifie que nous retournerons une ressource non conforme en réponse.

Par exemple, status est une propriété obligatoire dans Observation. Mais si vous souhaitez la masquer, vous retournerez une ressource qui n'est pas valide.

{
  "id": "bp-001",
  "resourceType": "Observation",
  "meta": {
    "security": [ ...labels... ]
  },
  "_status": {
    "extension": [
      {
        "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
        "valueCode": "masked"
      }
    ]
  },
  "code": {
    "coding": [
      {
        "extension": [
          {
            "url": "http://terminology.hl7.org/CodeSystem/data-absent-reason",
            "valueCode": "masked"
          }
        ]
      }
    ]
  }
}

Bien que la « conformité pour la conformité » puisse constituer un compromis acceptable, cela devient un vrai problème lorsque les applications clientes dépendent de la présence de ces propriétés obligatoires. Ainsi, « c'est la confidentialité contre la conformité, et parfois la confidentialité doit l'emporter. »

4. Surcharge de performance

Comme vous avez peut-être remarqué, l'application des étiquettes de sécurité ajoute une surcharge de traitement à plusieurs points.

Nous avons effectué des tests de performance et comparé trois configurations d'Aidbox : Sans contrôle d'accès basé sur les étiquettes

Avec des étiquettes au niveau de la ressource
Avec des étiquettes en ligne

Nous avons mesuré les opérations de lecture FHIR en effectuant des requêtes GET /fhir/Patient/id. Les résultats ont montré un ralentissement de 6,2 % pour les étiquettes au niveau de la ressource et de 7,4 % pour les étiquettes au niveau de la propriété. Donc, si votre application n'exige pas chaque milliseconde de performance, il ne s'agit pas d'un problème majeur.

Opérations de création et de mise à jour

Notre implémentation des étiquettes de sécurité FHIR ne couvre actuellement que les opérations de lecture et de recherche. Les opérations de création et de mise à jour nécessitent une gestion supplémentaire.

Le problème

Considérez ce scénario : un client demande une ressource Patient où l'adresse domiciliaire est masquée en raison de permissions insuffisantes. Le client voit l'adresse de facturation et d'autres propriétés, puis souhaite mettre à jour le numéro de téléphone du patient. Comment le serveur FHIR devrait-il gérer cette mise à jour sans perdre les données d'adresse domiciliaire masquées?

Approche recommandée

Éviter entièrement les opérations PUT — PUT remplace la ressource entière, ce qui ferait perdre toute propriété masquée que le client ne pouvait pas voir.
Utiliser plutôt les opérations PATCH — PATCH permet des mises à jour sélectives de propriétés spécifiques sans affecter la ressource entière.
Validation côté client — Implémenter une logique pour n'autoriser la modification que des propriétés qui n'étaient pas masquées dans la réponse originale.

Étiquettes au niveau de la ressource contre étiquettes au niveau de la propriété

Étiquettes au niveau de la ressource (dans meta.security) — FHIR recommande de préserver les étiquettes dans meta lors de l'opération de création, mais vous devez tout de même faire preuve de prudence avec les mises à jour.
Étiquettes au niveau de la propriété (extensions en ligne) — sont plus complexes, car elles existent au sein des données de la ressource elle-même.

Il s'agit d'un domaine en évolution où les serveurs FHIR ont besoin d'une logique personnalisée pour gérer les mises à jour en toute sécurité tout en préservant les limites de sécurité.

Pas de solution miracle

La principale conclusion de cet article est que les étiquettes sont un outil précis, mais elles comportent encore de nombreux compromis à considérer.

Démonstration Postman

Essayez l'implémentation des étiquettes de sécurité FHIR d'Aidbox dans Postman. Veuillez lire la description dans la collection Postman avant d'exécuter les requêtes.

Vous pouvez utiliser la collection Postman fournie pour explorer différents scénarios impliquant un contrôle d'accès à grain fin avec les étiquettes de sécurité FHIR. La collection comprend des exemples de requêtes et des conseils sur la façon de tester le masquage et le filtrage des propriétés de données sensibles en fonction des permissions des utilisateurs.

Exécuter dans Postman

Le serveur FHIR Aidbox est disponible gratuitement à des fins de développement et de test, vous pouvez donc configurer votre propre instance et expérimenter avec les étiquettes de sécurité dans un environnement réel. Cela facilite l'évaluation du fonctionnement pratique des étiquettes de sécurité avant d'envisager une utilisation en production.

Voir aussi : RBAC avec Keycloak et SMART on FHIR V2.