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

Aperçu

Cette page décrit les fonctionnalités en preview qui sont susceptibles d'être modifiées et de bénéficier d'une assistance limitée. Les modifications apportées aux produits et fonctionnalités pré-DG peuvent ne pas être compatibles avec d'autres versions pré-DG. Pour en savoir plus, consultez les conditions de l'offre pré-DG pour l'API Cloud Healthcare et les descriptions des étapes de lancement.

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.

Consentement FHIR

Les règles d'accès sont exprimées via des ressources de consentement FHIR. Le consentement FHIR est un type de ressource FHIR qui capture les choix d'un consommateur de soins de santé. Elle autorise ou refuse un ensemble d'acteurs à effectuer des actions affectant le consommateur dans un objectif spécifique à partir d'un environnement spécifié 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 ne pas concerner que les données du dossier médical électronique (DME) du consommateur. Toutefois, dans le cadre 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 se limite à la lecture des données FHIR à partir d'un store FHIR.

L'état d'une ressource Consent est celui qui indique l'état actuel du consentement. Bien qu'un store FHIR puisse contenir de nombreux consentements dans différents états, l'API Cloud Healthcare n'applique que les consentements à l'état actif. Dans un autre État, les autorisations n'ont aucun effet sur son application. Si un consentement est donné au nom d'un patient, il est enregistré comme étant accordé par un performant.

Type de règle

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

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

• Règles d'administration: elles ne sont associées à aucun patient et doivent avoir une URL d'extension https://g.co/fhir/medicalrecords/ConsentAdminPolicy. Ce type de règle peut être lié à un sous-ensemble ou à toutes les ressources du magasin, spécifiés par les critères relatifs aux ressources. La règle d'administration définit la stratégie par défaut pour toutes les ressources de liaison du magasin.

• Règle d'administration en cascade: type de règle d'administration qui nécessite l'URL d'extension https://g.co/fhir/medicalrecords/CascadingPolicy et l'URL de l'extension des règles d'administration. Vous pouvez lier ce type de stratégie à un compartiment de ressources qui correspondent aux critères applicables aux ressources. Il est soumis aux limites suivantes:

  • Compatible uniquement avec le patient (STU3, R4) ou Encounter (STU3, R4) comme base du compartiment.
  • Pour le store FHIR où la règle est appliquée, disableReferentialIntegrity doit être défini sur false.

Vous pouvez combiner des types de règles au même niveau de ressource pour autoriser ou refuser l'accès à une ressource. S'il manque l'autorisation du patient, la règle d'administration peut autoriser l'accès à une ressource.

Directive relative au consentement

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

• Type d'application: instruction permit ou deny.

• Action: les autorisations couvertes par cette directive. Seul access est compatible avec les droits d'accès en lecture seule.

• Critères d'accesseur: ensemble d'attributs qui identifient le demandeur d'API couvert par la directive.

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

Critères de l'accesseur

L'API Cloud Healthcare prend en charge trois propriétés d'un accesseur à utiliser dans une directive de consentement et à mettre en correspondance avec un accesseur effectuant une demande d'accès aux données. Il doit y avoir une correspondance exacte sensible à la casse pour qu'une directive soit 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.

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

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

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

• Acteur : Practitioner/123

• Objectif : 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 le cadre de 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 de consentement doivent spécifier un actor pour être appliqué, mais pas toujours 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 la ressource

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 stratégie de consentement s'applique.

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

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

• Libellé de sécurité: représente les libellés 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 code suivants sont compatibles:

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

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

Remarque :Des exemples illustrant la façon dont différentes règles peuvent être représentées via la ressource de consentement sont disponibles dans les guides pratiques.

Workflow d'accès

Cette figure illustre le parcours de bout en bout d'une requête adressée à un magasin compatible avec le contrôle des accès FHIR. Un jeton externe avec le champ d'application du consentement (à gauche) est utilisé par l'application (n° 3) lorsqu'elle envoie une requête au store FHIR avec le contrôle des accès activé (à droite).

Champ d'application du consentement

Lors d'une demande d'accès aux données, un accesseur opère dans un champ d'application de consentement particulier qui représente ses propriétés actor, purpose et environment liées à toute requête HTTP FHIR. Pour que ces propriétés puissent avoir une incidence sur la détermination de l'accès par l'application, les valeurs de ces propriétés doivent correspondre sensiblement à la casse avec celles fournies dans un consentement.

Un accesseur peut avoir plusieurs identifiants actor pertinents pour déterminer l'accès. De même, plusieurs purposes ou environments peuvent être pertinents dans un contexte de consentement particulier. Par conséquent, toutes les propriétés d'accesseur pertinentes doivent être fournies dans une requête HTTP FHIR afin de 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 prodiguer un traitement régulier, mais il peut également gérer un traitement d'urgence dans le cadre de ces actions. Il 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. Plusieurs de ces propriétés peuvent représenter le champ d'application du consentement d'un utilisateur à un moment donné.

Les entrées du champ d'application 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 se résout 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 Objectif d'utilisation (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. Exemples de type et value:

  • App/my_app_1
  • Net/VPN

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

• btg : "bris de glace" vous permet, en tant qu'utilisateur humain, d'ignorer 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 (tels qu'un administrateur) ou aux applications de confiance (telles qu'un pipeline d'entraînement de ML) de fonctionner sur le store FHIR sans autorisation de consentement. Par conséquent, bypass nécessite au moins un actor et un env.

Remarque :Les requêtes qui utilisent btg ou bypass sont annotées différemment dans le consentMode des journaux d'audit. Pour faciliter les vérifications de la gouvernance des données, ces deux privilèges spéciaux ne doivent être utilisés qu'à des fins prévues.

Application forcée et détermination des accès

Dans un environnement de santé complexe où plusieurs règles et autorisations coexistent, appliquer les accès et déterminer les autorisations d'accès peuvent s'avérer fastidieux. Les attentes et les exigences liées à l'utilisation et à la divulgation des informations sur les patients peuvent varier d'une personne à l'autre. Pour s'adapter à ce paysage complexe, il est nécessaire de comprendre clairement comment les accès sont appliqués et la logique sous-jacente qui régit leur détermination.

Règles relatives au consentement agrégé

Un consommateur de soins de santé, tel qu'un patient ou un administrateur, peut disposer de plusieurs instructions de consentement dans une seule ressource de consentement. Les ressources de consentement 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 ressources de consentement active 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.

Propriétés de l'instruction d'autorisation

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

Les règles suivantes décrivent les principes du contrôle conjoint d'accès du consentement des patients, des règles d'administration et des règles d'administration en cascade:

• En l'absence de directive correspondante, l'accès à toutes les ressources est refusé par défaut.

• Si la ressource demandée n'existe pas, seuls le type et l'ID de ressource sont identifiables. Tous les autres critères de 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 d'observation, l'accès est refusé.

  • Mais :

    • Si une règle d'administration refuse les critères d'accesseur, quels que soient les autres critères de ressource, l'accès est refusé.

    • Si une règle d'administration autorise les critères d'accesseur pour les critères d'identification de la ressource (c'est-à-dire le type et l'ID de ressource), une erreur "resource not found" (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 faire correspondre les ressources du magasin.

• Les ressources n'appartenant à aucun patient sont déterminées uniquement par les règles d'administration.

• Les ressources situées dans le compartiment patient (STU3, R4) ou celles qui se trouvent dans le compartiment (STU3, R4) nécessitent au moins une directive d'autorisation de consentement par patient ou la règle d'administration ou la règle d'administration en cascade, et la règle d'autorisation d'administration en cascade et la règle d'administration et la règle d'administration en cascade. Cette condition est requise pour tous les patients nommés sur les ressources auxquelles le demandeur doit accéder.

  • Certaines ressources peuvent prendre en charge plusieurs patients. Par exemple, Appointment fournit une liste de participants pouvant ê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 seront pas renvoyées. Si une ressource dispose d'une autorisation issue d'une règle de rencontre en cascade, 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 des accès conjoint

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 store FHIR vérifie l'autorisation de consentement au niveau de chaque ressource. Toute référence dans une ressource n'est pas résolue et n'est pas traitée en cascade à des fins de vérification de l'accès au consentement. Prenons l'exemple d'un patient identifié par Patient/f001 qui permet à un praticien d'accéder à l'intégralité de sa ressource MedicationRequest, mais pas à la ressource Patient/f001 elle-même pour des raisons de confidentialité. Dans ce scénario, le praticien 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 même, par exemple, lorsqu'il effectue une recherche FHIR à l'aide de _include.

Résolution de conflits

Des conflits peuvent exister entre différentes directives permit et deny. Si deux instructions 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

Lors de l'envoi d'une requête tenant compte du consentement à un store FHIR, le contrôle des accès est effectué dans l'ordre suivant:

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

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'accès au consentement est basée sur les champs d'application du consentement fournis dans la requête, en fonction des directives de consentement capturées lors de la dernière exécution de ApplyConsents et de ApplyAdminConsents.

   Remarque :Si la configuration du store FHIR définit le traitement de l'en-tête de consentement sur REQUIRED_ON_READ, le contrôle des accès au consentement est appliqué (et refusé), même sans les en-têtes prenant en compte le consentement.

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

• Fournissez au moins un champ d'application de consentement actor pertinent pour les actions de consentement effectuées.

• 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.executeBundle ou fhir.search), le contrôle d'accès s'applique à chaque ressource. Cependant, il existe une légère différence entre ces méthodes d'accès multiressources:

  • 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 se comporte de la même manière que fhir.search, sauf qu'il renvoie 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 concerné.

Détermination de l'accès au consentement

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 directives de consentement ne spécifient pas les trois propriétés d'accesseur. Dans ce cas, toute valeur de propriété de portée du consentement 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 directives de consentement ne spécifient pas d'élément purpose ni de environment. Par conséquent, le champ d'application du consentement doit également être mis en correspondance avec les directives de consentement qui ne spécifient pas ces types de portée.

Par exemple, si vous définissez le champ d'application du consentement sur actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc, cela correspond à l'une des directives de consentement 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

Étapes suivantes

• Découvrez comment appliquer l'accès à un store FHIR.