Modèle et système de contrôle des données d'accès FHIR

Présentation du modèle de données

Le modèle de données pour le contrôle des accès est représenté par des ressources de consentement. Elles définissent les règles qui s'appliquent et les données auxquelles elles s'appliquent.

Les règles d'accès sont exprimées via des ressources Consentement FHIR. L'autorisation FHIR est un type de ressource FHIR qui capture les choix du consommateur de soins de santé. Elle autorise ou non un ensemble d'acteurs à effectuer des actions sur le consommateur dans un objectif spécifique à partir d'unEnvironnement donné sur une période donnée. Par exemple, un consommateur peut être le patient bénéficiant des soins, toute personne agissant pour le compte d'un patient ou une autre personne ayant conclu un contrat de consentement.

Les actions enregistrées dans un consentement FHIR peuvent être larges et concerner plus que les données du dossier médical électronique (DMF) du consommateur. Toutefois, aux fins du consentement dans l'API Cloud Healthcare, l'accent est mis sur les actions liées à l'accès aux données, et l'application de ces actions est limitée à la lecture des données FHIR à partir d'un magasin FHIR.

Une ressource Consent possède un état qui indique l'état actuel de l'autorisation. Bien qu'un magasin FHIR puisse contenir de nombreux consentements dans différents états, l'API Cloud Healthcare n'applique que les consentements qui sont dans l'état actif. Les consentements dans tout autre État n'ont aucun effet sur l'application. Si un consentement est donné au nom d'un patient, il est enregistré comme étant accordé par un interprète.

Type de règle

L'API Cloud Healthcare accepte les types de règles de consentement suivants:

  • Consentement du patient: est associé à un patient à l'aide de Consent.patient (STU3, R4) et lie autant de données que défini par le compartiment du patient (STU3, R4).

  • Règle d'administration: n'est associée à aucun patient et doit comporter une URL d'extension https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Ce type de stratégie peut se lier à un sous-ensemble ou à toutes les ressources du magasin spécifiées par les critères de ressources. La stratégie d'administration définit la stratégie par défaut pour toutes les ressources de liaison du magasin.

  • Règle de cascade d'administration: type de règle d'administration qui nécessite l'URL d'extension https://g.co/fhir/medicalrecords/CascadingPolicy et l'URL d'extension de la règle d'administration. Vous pouvez lier ce type de règle à un compartiment de ressources correspondant aux critères de ressources. présente les limites suivantes:

Vous pouvez combiner des types de règles au même niveau de ressource pour autoriser ou refuser l'accès à une ressource. Si le consentement d'un patient est manquant, la stratégie d'administration peut approuver l'accès à une ressource.

Les directives de consentement sont des instructions encodées dans un consentement FHIR qui autorisent ou refusent l'accès aux données à une entité autorisée, telle qu'un bénéficiaire ou un accédant. Un seul consentement FHIR peut encoder plusieurs directives de consentement. Chaque directive fournit les éléments suivants:

  • Type de mesure d'application: instruction permit ou deny.

  • Action: autorisation(s) couverte(s) par cette directive. Seul access est accepté pour fournir un accès en lecture seule.

  • Critères d'accès: ensemble d'attributs qui identifient la demande d'API couverte par la directive.

  • Critères de ressources: ensemble d'attributs qui identifient les ressources couvertes par la directive.

Critères d'accesseur

L'API Cloud Healthcare prend en charge trois propriétés d'un accésseur à utiliser dans une directive d'autorisation et à faire correspondre à un accésseur effectuant une requête d'accès aux données. Une correspondance exacte sensible à la casse doit être appliquée à l'accesseur dans le cadre de la détermination de l'accès proposée par le serveur FHIR.

Ces propriétés sont encodées comme suit:

  • Acteur: représente un individu, un groupe ou un rôle d'accès qui identifie l'accesseur ou une caractéristique de l'accesseur.

  • Finalité: représente l'intention d'utilisation des données.

  • Environnement: représente un identifiant abstrait qui décrit l'environnement ou les conditions dans lesquelles l'accesseur agit.

Par exemple, un accesseur peut être représenté par les propriétés suivantes:

  • Acteur : Practitioner/123

  • Finalité : ETREAT ou accès à des fins de traitement d'urgence

  • Environnement : Application/abc

Dans cet exemple, ces propriétés représentent un médecin qui accède aux données lorsqu'il effectue un traitement d'urgence à l'aide d'une application logicielle appelée abc.

provision.actor et provision.purpose sont définis dans la norme FHIR, tandis que l'environnement est https://g.co/fhir/medicalrecords/Environment. Notez que ce lien ne peut pas être résolu.

Toutes les directives d'autorisation doivent spécifier un actor à appliquer, mais pas nécessairement un purpose ou un environment. Par exemple, si aucun environment n'est spécifié dans l'instruction d'autorisation, l'instruction correspond à toute environment qui n'est pas déjà couverte par d'autres instructions d'autorisation.

Critères de ressources

L'API Cloud Healthcare accepte les éléments suivants dans la ressource de consentement:

  • Type de ressource (STU3, R4): représente le type auquel la règle d'autorisation est liée, par exemple Encounter, Observation ou Immunization.

  • ID de ressource (STU3, R4) : représente l'ID auquel la règle d'autorisation est liée.

  • Source de données: représente l'origine de la ressource telle qu'identifiée par la ressource meta.source (disponible uniquement en R4).

  • Tag de données: représente le libellé personnalisé de la ressource, tel que décrit dans la ressource meta.tag (STU3 ,R4).

  • Étiquette de sécurité: représente les étiquettes de sécurité qui définissent les ressources concernées telles qu'identifiées dans le champ meta.security (STU3, R4). Les systèmes de codage suivants sont acceptés:

    • Confidentialité : valeurs hiérarchiques classées de la moins restrictive à la plus restrictive : U, L, M, N, R, V. Si un consentement autorise un libellé de sécurité de R, il s'applique à toutes les ressources libellées R ou moins. Si un consentement refuse un libellé de sécurité R, il s'applique à toutes les ressources au moins aussi sensibles que R.

    • ActCode : correspondance exacte de la chaîne sur le code de sécurité.

Workflow d'accès

authorization_flow

Cette figure illustre le parcours de bout en bout d'une requête vers un magasin avec contrôle des accès FHIR activé. Un jeton externe avec le champ d'application du consentement (à gauche) est utilisé par l'application 3 lors de l'envoi d'une requête au magasin FHIR avec le contrôle des accès activé (à droite).

Lorsqu'il envoie une requête d'accès aux données, un accesseur opère dans un champ d'application des autorisations particulier qui représente ses propriétés actor, purpose et environment associées à toute requête HTTP FHIR. Les valeurs de ces propriétés doivent correspondre à celles fournies dans un consentement pour qu'elles affectent la décision d'accès de l'application de la loi.

Un accesseur peut avoir plusieurs identifiants actor pertinents pour déterminer l'accès. De même, il peut exister plusieurs purposes ou environments pertinents dans un contexte de consentement particulier. Par conséquent, toutes les propriétés d'accesseur pertinentes doivent être fournies dans le cadre d'une requête HTTP FHIR pour représenter correctement cet accesseur à des fins de consentement.

Par exemple, le champ d'application d'autorisation pour une requête de données spécifique peut être le suivant:

actor/Practitioner/444 actor/Group/999 purp/v3/TREAT purp/v3/ETREAT env/App/abc

Il s'agit d'une infirmière ou d'un médecin connu sous le nom de professionnel 444, membre du groupe 999 et représentant les professionnels d'un service d'un hôpital spécifique. Le praticien est là pour fournir un traitement régulier, mais peut également s'occuper des traitements d'urgence dans le cadre de ces actions. Le praticien utilise une application logicielle appelée abc.

Le champ d'application du consentement est fourni en tant que champ d'application du consentement de la requête dans le cadre de la requête de données d'un Accesseur.

Demander le champ d'application des autorisations

Les requêtes FHIR utilisent des en-têtes de requête HTTP FHIR pour recevoir le champ d'application des autorisations de l'accesseur. Ce champ d'application des autorisations contient un ensemble de valeurs actor, purpose et environment pour refléter l'identité actuelle, les qualifications, l'intention d'utilisation et les contraintes environnementales dans lesquelles l'accesseur fonctionne. Il peut y avoir plusieurs propriétés de chacune de ces propriétés qui représentent le champ d'application du consentement d'un accésseur à un moment donné.

Les entrées de champ de portée du consentement sont définies comme suit:

  • actor/{type}/{ID}: propriété actor dans laquelle la ressource type est fournie avec ID. Voici quelques exemples de type:

    • Practitioner
    • Group
    • Patient

    Par exemple, si un magasin au format projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID appelle l'API, une référence locale à un acteur Practitioner/123 est résolue en projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • purp/v3/{value}: propriété purpose où value est membre de l'ensemble de valeurs FHIR Purpose of Use (v3) ou de son extension. Voici quelques exemples de value:

    • TREAT
    • ETREAT
    • HRESCH

  • env/{type}/{value}: propriété environment où type et value sont des chaînes personnalisées sans taxonomie prédéfinie. Voici quelques exemples de type et value:

    • App/my_app_1
    • Net/VPN

De plus, les en-têtes de requête HTTP FHIR peuvent également recevoir des champs d'application spéciaux, tels que btg et bypass, qui sont définis comme suit:

  • btg: le "bris de glace" vous permet, en tant qu'utilisateur humain, de contourner les vérifications du consentement en cas d'urgence. Il ne doit être utilisé qu'en cas d'urgence et est soumis à un examen post-audit. Par conséquent, btg nécessite au moins un actor.
  • bypass: permet aux utilisateurs de confiance (comme un administrateur) ou aux applications de confiance (comme un pipeline de formation ML) d'utiliser le store FHIR sans autorisation de consentement. Par conséquent, bypass nécessite au moins un actor et un env.

Application et détermination des accès

Dans un environnement de santé complexe où plusieurs règles et consentements coexistent, l'application des accès et la détermination des autorisations d'accès peuvent s'avérer une tâche ardue. Les différentes parties prenantes peuvent avoir des attentes et des exigences différentes concernant l'utilisation et la divulgation des informations sur les patients. Pour naviguer dans ce paysage complexe, vous devez bien comprendre comment l'accès est appliqué et la logique sous-jacente qui régit la détermination de l'accès.

Un consommateur de services de santé, comme un patient ou un administrateur, peut avoir plusieurs directives de consentement contenues dans une seule ressource de consentement. Les ressources d'autorisation peuvent contenir une combinaison d'instructions provision.type permit et deny. Par défaut, un utilisateur peut disposer d'un nombre illimité de ressources de consentement, mais jusqu'à 200 active ressources de consentement sont appliquées à la fois. Pour en savoir plus, consultez la section Contraintes et limites.

Toutes les instructions d'autorisation sont extraites des ressources d'autorisation active pour qu'un utilisateur donné définisse un ensemble de règles d'autorisation agrégées.

L'application du consentement est limitée à un seul objectif et à un seul environnement par entrée de provision.

Les règles suivantes décrivent les principes de contrôle conjoint des accès au consentement du patient, de la stratégie d'administration et de la stratégie en cascade de l'administrateur:

  • Par défaut, l'accès à toutes les ressources est refusé si aucune directive ne correspond.

  • Si la ressource demandée n'existe pas, seuls le type et l'ID de la ressource sont identifiables. Si tous les autres critères de la ressource et le propriétaire de la ressource sont inconnus, la règle suivante s'applique dans l'ordre de la liste:

    • Si le type de ressource appartient au compartiment patient ou au compartiment consultation, l'accès est refusé.

    • Mais :

      • Si une stratégie d'administrateur refuse les critères d'accès, quels que soient les autres critères de la ressource, l'accès est refusé.

      • Si une stratégie d'administration autorise les critères d'accès pour les critères de ressources identifiables (type de ressource et ID de ressource, par exemple), une erreur "ressource introuvable" est renvoyée.

      • Dans tous les autres cas, l'accès est refusé.

  • Les règles d'administration sont les règles par défaut utilisées pour mettre en correspondance les ressources dans la plate-forme.

  • Les ressources qui n'appartiennent à aucun patient ne sont déterminées que par les règles d'administration.

  • Les ressources du compartiment patient (STU3, R4) ou du compartiment de la rencontre (STU3, R4) doivent comporter au moins une directive d'autorisation du consentement par patient ou règle d'administration ou règle d'administration en cascade, et aucune directive de refus du consentement du patient et de la règle d'administration et de la règle d'administration en cascade. Cette condition est nécessaire pour tous les patients nommés sur les ressources auxquelles le demandeur peut accéder.

    • Certaines ressources peuvent être utilisées par plusieurs patients. Par exemple, Rendez-vous fournit une liste des participants, qui peuvent être des patients. Tous les patients nommés sur ces ressources doivent autoriser l'accès à l'accesseur à l'aide d'instructions de consentement, sinon les ressources ne sont pas renvoyées. Si une ressource dispose d'une autorisation provenant d'une règle en cascade de rencontre, où cette rencontre fait référence à un patient via le champ subject (STU3, R4), la ressource est considérée comme autorisée par le patient.

Les règles décrites sont résumées par le pseudo-code suivant:

Contrôle conjoint des accès

if resource does not exist
  if resource is a patient-compartment or encounter-compartment resource:
    return "deny"
  else:
    if there is any admin policy denies access for accessor criteria regardless of resource criteria other than resource type and resource ID:
      return "deny"
    else if there is any admin policy permits access for accessor criteria based on the identifiable resource criteria:
      return "resource not found"
    else:
      return "deny"
else:
  let patients = list of patient references named in the patient compartment eligible fields of the requested resource
  if there is any matching deny from either patients's consents or admin policy or admin cascading policy:
    return "deny"
  if there is matching admin policy permits access:
    return "permit"
  if all patients have matching patient consents or admin cascading consent that permit access or are subject of encounters which permit the access through encounter cascading policy:
    return "permit"
  else:
    return "deny"
end

Le magasin FHIR vérifie l'autorisation du consentement au niveau de chaque ressource. Toute référence dans une ressource n'est pas résolue et n'est pas transmise en cascade à des fins de vérification de l'accès par consentement. Par exemple, un patient identifié par Patient/f001 permet à un professionnel d'accéder à l'intégralité des informations MedicationRequest, mais pas à la ressource Patient/f001 elle-même en raison de sa confidentialité. Dans ce scénario, le professionnel peut voir l'intégralité de la ressource MedicationRequest, qui inclut un champ subject faisant référence à la ressource Patient/f001, mais ne peut pas voir le contenu de la ressource Patient/f001, par exemple, lors d'une recherche FHIR à l'aide de _include.

Résolution de conflits

Des conflits peuvent survenir entre différentes directives permit et deny. Si deux directives en conflit correspondent à une ressource, le conflit est résolu à l'aide du modèle deny l'emporte sur permit.

Seules les autorisations active sont incluses pour l'application des autorisations.

Logique d'application de l'accès aux ressources

Lorsque vous effectuez une requête d'autorisation à un magasin FHIR, le contrôle des accès se produit dans l'ordre suivant:

  1. L'API Cloud Healthcare vérifie les autorisations sur le compte de service Google Cloud (ou le principal) configuré dans le proxy. Si le compte de service dispose des autorisations IAM appropriées pour effectuer la méthode FHIR demandée sur le magasin FHIR, la requête aboutit.

  2. Si l'application de l'autorisation est activée dans la configuration du magasin FHIR et que les en-têtes HTTP compatibles avec les autorisations sont présents, l'API Cloud Healthcare applique des règles d'accès aux autorisations pour les ressources des patients. L'application des règles d'autorisation d'accès est basée sur les niveaux d'autorisation fournis dans la requête, conformément aux instructions d'autorisation capturées par la dernière exécution de ApplyConsents et ApplyAdminConsents.

Les règles suivantes s'appliquent lors de l'envoi d'une requête d'autorisation à un magasin FHIR:

  • Indiquez au moins un champ d'application du consentement actor pertinent pour les actions d'autorisation.

  • Fournissez tous les champs d'application purpose et environment supplémentaires pertinents pour les actions d'autorisation.

  • Si le nombre d'entrées de champ d'application des autorisations dépasse les limites acceptées, une erreur est renvoyée.

  • Si vous appelez une méthode qui accède à plusieurs ressources (par exemple, fhir.Patient-everything, fhir.Encounter-everything, fhir.executeBundle ou fhir.search), le contrôle d'accès s'applique à chaque ressource. Toutefois, il existe une différence subtile entre ces méthodes d'accès multiressource:

    • Le fhir.executeBundle qui lit plusieurs ressources reçoit le message "Accès à l'autorisation refusé ou la ressource à laquelle vous accédez n'existe pas" pour les ressources individuelles sans autorisation (consultez des exemples dans la section Obtenir des ressources FHIR avec un champ d'application d'autorisation).

    • fhir.search ignore les ressources non autorisées et ne renvoie pas d'erreur de type accès refusé, même pour la recherche par _id (consultez les exemples dans la section Rechercher des ressources FHIR avec un champ d'application d'autorisation).

    • fhir.Patient-everything et fhir.Encounter-everything se comportent de la même manière que fhir.search, sauf qu'ils renvoient le message "Autorisation d'accès refusée ou la ressource recherchée n'existe pas" si l'appelant n'a pas l'autorisation requise pour le patient ou l'encounter concerné, respectivement.

Une directive d'autorisation comporte au maximum un actor, un purpose et un environment, tandis que le champ d'application du consentement peut avoir plusieurs éléments. Certaines instructions d'autorisation ne spécifient pas les trois propriétés de l'accesseur, auquel cas une valeur de propriété de champ d'application d'autorisation peut correspondre en fonction des règles de résolution des conflits. Par conséquent, un champ d'application d'autorisation peut correspondre à plusieurs instructions d'autorisation.

Si le champ d'application des autorisations d'une requête inclut au moins deux entrées du même type de champ d'application d'autorisation (actor, purpose ou environment), le champ d'application de l'autorisation peut correspondre à plusieurs instructions d'autorisation. Certaines instructions d'autorisation ne spécifient ni purpose ni environment. Par conséquent, le champ d'application des autorisations doit également être mis en correspondance avec les instructions d'autorisation qui ne spécifient pas ces types de champs d'application.

Par exemple, définir la portée du consentement sur actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc correspond à l'une des instructions d'autorisation permit ou deny suivantes:

  • actor/Practitioner/123 purp/v3/TREAT env/App/abc
  • actor/Practitioner/123 purp/v3/TREAT
  • actor/Practitioner/123 env/App/abc
  • actor/Practitioner/123
  • actor/Group/999 purp/v3/TREAT env/App/abc
  • actor/Group/999 purp/v3/TREAT
  • actor/Group/999 env/App/abc
  • actor/Group/999

Étape suivante