Modèle de données d'accès et système de contrôle 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 les ressources de consentement. Ils 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 les ressources de consentement FHIR. Le consentement FHIR est un type de ressource FHIR qui capture les choix d'un consommateur de santé. Elle autorise ou refuse un ensemble d'acteurs à effectuer des actions affectant le consommateur à une fin spécifique dans 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 générales et traiter plus que les données du dossier médical électronique (DME) du consommateur. Toutefois, aux fins du consentement au sein de 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 d'un store FHIR.

Une ressource de consentement a un état 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 autorisations à l'état active. Le consentement dans tout autre État n'a aucune incidence sur l'application. Si un consentement est accordé au nom d'un patient, il est enregistré comme accordé par un artiste.

Type de règle

L'API Cloud Healthcare est compatible avec les types de règles de consentement suivants:

  • Le 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 patient (STU3, R4).

  • Règle d'administration: n'est associée à aucun patient et doit 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 de ressource. Une 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 de la règle d'administration. Vous pouvez lier ce type de stratégie à un compartiment de ressources correspondant aux critères de ressource. Elle est soumise aux limites suivantes:

    • Uniquement compatible avec le patient (STU3, R4) ou la rencontre (STU3, R4) comme base de compartiment.
    • Pour le store FHIR dans lequel 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. Dans le cas contraire, la règle d'administration peut autoriser 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 accesseur. Un même consentement FHIR peut encoder plusieurs directives de consentement. Chaque instruction fournit les éléments suivants:

  • Type d'application: instruction permit ou deny.

  • Action: autorisation(s) couverte(s) par cette directive. Seul access permet de fournir un 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 d'accesseur

L'API Cloud Healthcare accepte trois propriétés d'un accesseur à utiliser dans une directive de consentement et pour la mise en correspondance avec un accesseur effectuant une demande d'accès aux données. Il doit exister 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 celui-ci.

  • 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 correspond à https://g.co/fhir/medicalrecords/Environment. Notez que ce lien ne peut pas être résolu.

Toutes les instructions de consentement doivent spécifier un actor à appliquer, mais il n'est pas nécessaire de spécifier une purpose ou une 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 règle de consentement est liée.

  • Source de données: représente l'origine de la ressource, telle qu'identifiée par la ressource meta.source (uniquement disponible dans 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, 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 limitée à la plus limitée : U, L, M, N, R, V. Si un consentement autorise le libellé de sécurité R, il s'applique à toutes les ressources portant le libellé R ou un niveau inférieur. Si un consentement refuse un libellé de sécurité R, il s'applique à toutes les ressources au moins aussi sensibles que R.

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

Accéder au workflow

authorization_flow

Cette figure illustre le parcours de bout en bout d'une requête vers un store FHIR activé. 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 contrôle des accès activé (à droite).

Lorsqu'il effectue une demande d'accès aux données, un accesseur opère dans un champ d'application d'autorisation particulier qui représente ses propriétés actor, purpose et environment liées à toute requête HTTP FHIR. Les valeurs de ces propriétés doivent être une correspondance sensible à la casse avec celles fournies dans le consentement pour qu'elles affectent la décision d'accès de l'application.

Un accesseur peut avoir plusieurs identifiants actor permettant de déterminer l'accès. De même, plusieurs purposes ou environments peuvent être pertinentes 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 professionnel doit assurer un traitement régulier, mais il peut aussi assurer un traitement d'urgence dans le cadre de ces mesures. 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 simultanément le champ d'application du consentement d'un utilisateur.

Les entrées du champ d'application du consentement sont définies comme suit:

  • actor/{type}/{ID}: propriété actor où la ressource type est fournie avec le 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'objectif d'utilisation FHIR (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

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

  • btg: le "bris de glace" (ou BTG) 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 fait l'objet d'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 ML) d'opérer sur le store FHIR sans autorisation de consentement. Par conséquent, bypass nécessite au moins un élément actor et un élément env.

Application des accès 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 peut s'avérer fastidieux. Les différentes personnes concernées peuvent avoir des attentes et des exigences différentes en ce qui concerne l'utilisation et la divulgation des informations sur les patients. Comprendre cet environnement complexe nécessite de comprendre clairement comment l'accès est appliqué et la logique sous-jacente qui régit la détermination de l'accès.

Un consommateur de soins de santé, tel qu'un patient ou un administrateur, peut disposer de plusieurs directives de consentement dans une même ressource Consent. 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 active 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 à une fin et à un environnement par entrée de provisionnement.

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

  • Par défaut, l'accès à toutes les ressources est refusé en l'absence d'instruction correspondante.

  • Si la ressource demandée n'existe pas, seuls le type de ressource 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 indiqué:

    • Si le type de ressource appartient au compartiment patient ou au compartiment de rencontre, 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 des ressources (par exemple, le type de ressource et l'ID de ressource), 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 le store.

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

  • Les ressources situées dans le compartiment patient (STU3, R4) ou dans le compartiment contact (STU3, R4) doivent comporter au moins une directive d'autorisation par patient ou règle d'administration ou règle en cascade pour l'administrateur, et aucune directive de refus de consentement de l'administrateur et règle en cascade des règles en cascade. Cette condition est requise de la part de tous les patients nommés sur les ressources que le demandeur doit accéder.

    • Certaines ressources peuvent prendre en charge plusieurs patients. Par exemple, Rendez-vous fournit une liste de participants, qui peuvent être des patients. Tous les patients nommés dans 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 liée à une règle en cascade de découverte, lorsque 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 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 est appliquée en cascade pour la 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 en raison de la confidentialité du patient. 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 même, par exemple, lors d'une recherche FHIR à l'aide de _include.

Résolution de conflits

Des conflits peuvent se produire entre différentes instructions 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 d'une requête tenant compte du consentement à un store FHIR, le contrôle des accès s'effectue dans l'ordre suivant:

  1. L'API Cloud Healthcare vérifie les autorisations du compte de service Google Cloud (ou du compte principal) configurées 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 est traitée.

  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 demande, conformément aux instructions relatives au consentement recueillies lors de 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:

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

  • 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é.

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 relatives au consentement ne spécifient pas les trois propriétés d'accesseur. Dans ce cas, toute valeur de propriété de champ d'application 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 instructions relatives au consentement ne spécifient pas de 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 champs d'application.

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, il 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