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 version preview qui sont susceptibles d'être modifiées et peuvent avoir 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 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 store FHIR puisse contiennent de nombreux consentements dans différents états, l'API Cloud Healthcare applique les consentements à l'état actif ; Consentement dans tout autre État n'ont aucun effet sur leur application. Si le consentement est donné au nom le consentement est enregistré comme accordé par un performant.

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 être lié à un sous-ensemble ou à toutes les ressources du magasin spécifié en fonction des critères de ressource. La règle d'administration définit pour toutes les ressources de liaison du magasin.

• Règles d'administration en cascade: type de règles d'administration qui nécessitent l'autorisation URL de l'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 les ressources qui correspondent aux critères applicables aux ressources. Contient le les limites suivantes:

  • Compatible uniquement avec le patient (STU3, R4) ou Encounter (STU3, R4) comme base du compartiment.
  • Le store FHIR où la règle est appliquée doit avoir disableReferentialIntegrity définie 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 que autoriser ou refuser l'accès aux données à une entité autorisée telle qu'un bénéficiaire ou accesseur Un seul consentement FHIR peut encoder plusieurs directives de consentement. Chaque fournit les éléments suivants:

• Type d'application: instruction permit ou deny.

• Action: les autorisations couvertes 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. Pour qu'une directive soit appliquée, il doit y avoir une correspondance exacte sensible à la casse. sur 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 une personne, 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.

• 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 établissement d'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 peuvent être résolus.

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 prend en charge les éléments suivants dans le cadre du Ressource "consent" :

• 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 les règles relatives au consentement s'appliquent.

• Source de données: représente l'origine de la ressource, telle qu'identifiée par le 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. comme indiqué 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é.

Remarque :Des exemples de 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 du consentement qui représente ses actor, purpose et environment lié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 effectuer une détermination de l'accès. De même, il peut y avoir plusieurs purposes ou environments 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'un 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 prodiguer un traitement régulier, mais peut-être aussi gérer un traitement d'urgence dans le cadre de ces mesures. La 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 une le champ d'application du consentement de l'accesseur.

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

• actor/{type}/{ID}: une propriété actor dans laquelle la ressource type est fourni 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 se résout 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 incluent:

  • 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 : "bris de glace" vous permet, en tant qu'utilisateur humain, d'ignorer le 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: autorise les utilisateurs de confiance (par exemple, un administrateur) ou les utilisateurs de confiance des applications (telles qu'un pipeline d'entraînement ML) pour qu'elles fonctionnent sur le store FHIR. sans autorisation préalable. bypass nécessite donc 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. Faciliter la gouvernance des données ces deux droits spéciaux ne doivent être utilisés que pour objectifs.

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

Dans un environnement de santé complexe où de multiples politiques et autorisations coexister, l'application forcée de l'accès et la détermination des autorisations d'accès peuvent être tâche. Plusieurs partenaires peuvent avoir des attentes et des exigences différentes concernant l'utilisation et la divulgation des informations des patients. Navigation le paysage complexe nécessite de bien comprendre comment l'accès est appliqué. et la logique sous-jacente qui régit la détermination de l'accès.

Règles relatives au consentement agrégé

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. Ressources sur le consentement peut contenir à la fois permit et deny provision.type . Par défaut, un utilisateur peut disposer de n'importe quel nombre de ressources de consentement, à 200 active Les ressources de consentement sont appliquées en même temps. Voir 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 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 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 rencontre-compartment: l'accès est refusé.

  • Mais :

    • Si une règle d'administration refuse les critères d'accesseur, indépendamment des autres critères de 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 n'appartenant à aucun patient sont déterminées par l'administrateur uniquement règles.

• 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 pour obtenir la 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 à partir d'une règle de cascade de rencontre 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. N'importe quelle valeur référence dans une ressource n'est pas résolue et transmise en cascade à des fins de vérification de l'accès au 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 Le praticien peut voir l'intégralité de la ressource MedicationRequest, qui inclut un Le champ subject fait référence à la ressource Patient/f001, mais ne peut pas voir contenu de la ressource Patient/f001, par exemple, lors de l'exécution une recherche FHIR à l'aide de _include.

Résolution de conflits

Des conflits peuvent exister 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

   Remarque :Si la configuration du store FHIR définit le gestion de l'en-tête de consentement en tant que REQUIRED_ON_READ, contrôle des accès consentement est appliquée (et refusée), même sans les en-têtes compatibles avec 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 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.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 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. Consentement ne spécifient pas les trois propriétés d'accesseur, auquel cas les la valeur de la propriété du champ d'application du consentement peut correspondre en fonction 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. Le champ d'application du consentement doit donc être sont également mis en correspondance avec les directives sur le consentement qui ne spécifient pas ces types de portée.

Par exemple, définir le champ d'application du consentement sur actor/Practitioner/123 actor/Group/999 purp/v3/TREAT env/App/abc 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

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