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

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. Le consentement FHIR est une Type de Ressource FHIR qui capture les choix des consommateurs dans le secteur de la santé. Elle autorise ou refuse un ensemble acteurs à effectuer des actions affectant le consommateur dans un objectif spécifique 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 concerner plus de uniquement les données du dossier médical électronique (DME) du consommateur, dans l'API Cloud Healthcare, l'accent est mis sur les actions à l'accès aux données, et l'application de ces mesures est limitée à la lecture de données FHIR à partir d'un store FHIR.

Une ressource Consent possède un état qui indique l'état actuel du consentement. 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: associé au patient utilisant Consent.patient (STU3, R4). et lie 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 disposer d'un URL de l'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 stratégie à un compartiment les ressources qui correspondent aux critères applicables aux 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. Uniquement access est compatible pour fournir un accès en lecture seule.

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

  • Critères de ressources: un 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 le cadre d'une directive sur le consentement et pour établir une correspondance avec un accesseur effectuant un accès aux données requête. Une correspondance exacte sensible à la casse doit être appliquée à l'accesseur dans le cadre de la détermination des droits d'accès proposés 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.

  • Environment (Environnement) : représente un identifiant abstrait qui décrit le 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

  • Objectif: ETREAT ou un accès en cas 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 n'est pas résoluble.

Toutes les directives de consentement doivent spécifier un actor pour être appliquée, mais il n'est pas nécessaire spécifiez toujours purpose ou 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 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 code suivants sont compatibles:

    • Confidentialité: Les valeurs hiérarchiques sont classées de la plus restreinte à la plus restreinte: U, L, M, N, R et V. Si le consentement permet l'utilisation d'un libellé de sécurité R Elle s'applique ensuite à toutes les ressources dont le libellé est R ou inférieur. Si un refuse une étiquette de sécurité R, puis s'applique à toutes les ressources sont au moins aussi sensibles que R.

    • ActCode: la correspondance exacte de chaîne avec 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 être sensibles à la casse avec celles fournies dans le consentement affecte la détermination de l'accès par l'application.

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 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 est résolue en projects/PROJECT_ID/locations/us-central1/datasets/DATASET_ID/fhirStores/STORE_ID/fhir/Practitioner/123.

  • purp/v3/{value}: une propriété purpose où value est membre de Finalités d'utilisation FHIR (v3) ou son extension. Voici quelques exemples de value:

    • TREAT
    • ETREAT
    • HRESCH

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

    • 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 mode "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 faire l'objet d'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 client du secteur de la santé, tel qu'un patient ou un administrateur, peut avoir plusieurs Directives de consentement contenues dans une seule ressource Consent. 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 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.

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

Les règles suivantes décrivent les principes du contrôle des accès conjoint consentement des patients, règles d’administration et 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 la ressource sont identifiables. Tous les autres critères de ressource et le propriétaire de la ressource inconnu, 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 règle d'administration permet d'appliquer les critères d'accesseur de ressources identifiables (type de ressource et ID de ressource), "ressource introuvable" s'affiche.

      • 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 qui ne correspondent à aucun patient ne sont déterminées que par les règles d'administration.

  • Ressources situées dans le compartiment patient (STU3, R4) ou le compartiment de contact (STU3, R4) ont besoin d'au moins une directive de consentement par patient ou règle d'administration ou règle en cascade pour les administrateurs et directive d'absence de consentement des règles d'administration et des règles d'administration et des règles d'administration en cascade. Ce de santé est nécessaire pour tous les patients nommés sur les ressources à laquelle le demandeur peut accéder.

    • Certaines ressources peuvent prendre en charge 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 permettre l'accès à l'accesseur à l'aide de directives de consentement, sinon les ressources ne sont pas renvoyées. Si une ressource dispose d'une autorisation d'une règle de gestion en cascade des rencontres, où celle-ci fait référence à patient via le champ subject (STU3, R4), la ressource est considérée comme autorisée 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 transmise en cascade à des fins de vérification de l'accès par consentement. Prenons l'exemple d'un patient identifié par Patient/f001 qui autorise une Les professionnels doivent accéder à l'intégralité de leur ressource MedicationRequest, mais pas à la Patient/f001 elle-même en raison de la confidentialité des données 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, 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 des instructions en conflit correspondent à une ressource, le conflit est résolu à l'aide de la méthode deny l'emporte sur le modèle 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 s'effectue dans l'ordre suivant:

  1. L'API Cloud Healthcare vérifie les autorisations sur compte de service (ou compte principal) configuré dans le proxy. Si le 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 sur les champs d'application du consentement fournis dans la demande, conformément à l'accord directives capturées 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 de consentement actor pertinent pour le consentement mesures prises.

  • 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 légère différence entre ces méthodes d'accès à plusieurs ressources:

    • 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 directives de consentement ne spécifient pas d'élément purpose ni de 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, 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'un des éléments suivants : Instructions permit ou deny relatives au consentement:

  • 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