Cette page explique comment utiliser le système de contrôle des accès FHIR de l'API Cloud Healthcare pour gérer et sécuriser vos données de santé. Vous pouvez utiliser le contrôle des accès FHIR pour définir des règles de consentement, contrôler l'accès aux données en fonction des rôles et du contexte des utilisateurs, et appliquer ces règles dans un magasin 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 Consent. 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 par le biais de ressources FHIR Consent. 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'un environnement 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 générales et concerner plus que les données du dossier médical électronique (DME) du consommateur. Toutefois, pour les besoins du consentement dans l'API Cloud Healthcare, l'accent est mis sur les actions liées à l'accès aux données. L'application de ces actions est limitée à la lecture des données FHIR à partir d'un magasin FHIR.
Une ressource Consent a 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 à l'état actif. Les consentements dans tout autre état n'ont aucun effet sur l'application des règles. Si un consentement est donné au nom d'un patient, il est enregistré comme ayant été accordé par un exécutant.
Type de règle
L'API Cloud Healthcare est compatible avec les types de règles de consentement suivants :
Consentement du patient : 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 règle peut s'appliquer à un sous-ensemble ou à toutes les ressources du magasin spécifié par les critères de ressource. La règle d'administration définit la règle 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 de l'extension
https://g.co/fhir/medicalrecords/CascadingPolicy
et l'URL de l'extension de règle d'administration. Vous pouvez associer ce type de règle à un compartiment de ressources correspondant aux critères de ressources. Il présente les limites suivantes :- Seuls les types Patient (STU3, R4) ou Encounter (STU3, R4) sont acceptés comme base de compartiment.
- Le store FHIR dans lequel la règle est appliquée doit avoir la valeur
false
pourdisableReferentialIntegrity
. Contactez l'assistance Cloud pour utiliser cette fonctionnalité pour un magasin FHIR sans intégrité référentielle.
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 règle d'administration peut approuver l'accès à une ressource.
Instruction d'autorisation
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 directive fournit les éléments suivants :
Type d'application : instruction
permit
oudeny
.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 le demandeur d'API concerné 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 accepte trois propriétés d'un accesseur à utiliser dans une directive de consentement et à comparer à un accesseur effectuant une demande d'accès aux données. Une correspondance exacte (sensible à la casse) est requise 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 une personne, 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'urgenceEnvironnement :
Application/abc
Dans cet exemple, ces propriétés représentent un médecin qui accède aux données lors d'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 qu'Environment est https://g.co/fhir/medicalrecords/Environment
. Notez que ce lien n'est pas résolvable.
Toutes les directives de consentement doivent spécifier un actor
à appliquer, mais n'ont pas toujours besoin de spécifier 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
ouImmunization
.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 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, telles qu'identifiées dans le champ
meta.security
(STU3, R4). Les systèmes de code suivants sont acceptés :Confidentialité : valeurs hiérarchiques classées de la moins à la plus restrictive :
U
,L
,M
,N
,R
,V
. Si une autorisation permet un libellé de sécuritéR
, elle s'applique à toutes les ressources portant un libelléR
ou inférieur. Si un consentement refuse un libellé de sécuritéR
, il s'applique à toutes les ressources au moins aussi sensibles queR
.ActCode : correspondance exacte de la chaîne du code de sécurité.
Workflow d'accès
Cette figure illustre le parcours de bout en bout d'une requête vers un magasin FHIR avec contrôle des accès activé. Un jeton externe avec le champ d'application "consent" (à gauche) est utilisé par l'application 3 lorsqu'elle envoie une requête au magasin FHIR avec le contrôle de l'accès activé (à droite).
Champ d'application du consentement
Lorsqu'il effectue une demande d'accès aux données, un accesseur opère dans un champ d'application du consentement spécifique 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 correspondre exactement à celles fournies dans une autorisation (en respectant la casse) pour qu'elles affectent la décision d'accès de l'application des règles.
Un accesseur peut comporter plusieurs identifiants actor
pertinents pour déterminer l'accès. De même, il peut y avoir 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 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 des soins réguliers, mais peut également être amené à effectuer des soins d'urgence dans le cadre de ces actions. Le professionnel 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 ce type qui représentent le champ d'application du consentement d'un accesseur à 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 ressourcetype
est fournie avecID
. Voici quelques exemples detype
: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 acteurPractitioner/123
est résolue enprojects/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 devalue
:TREAT
ETREAT
HRESCH
env/{type}/{value}
: propriétéenvironment
oùtype
etvalue
sont des chaînes personnalisées sans taxonomie prédéfinie. Voici quelques exemples detype
etvalue
:App/my_app_1
Net/VPN
De plus, les en-têtes de requête HTTP FHIR peuvent également recevoir des portées spéciales, telles que btg
et bypass
, qui sont définies comme suit :
btg
: la fonctionnalité "Bris de glace" (ou BTG, Break the Glass) vous permet, en tant qu'utilisateur humain, d'ignorer les vérifications du consentement en cas d'urgence. Elle ne doit être utilisée qu'en cas d'urgence et est soumise à un examen post-audit. Par conséquent,btg
nécessite au moins unactor
.bypass
: permet aux utilisateurs de confiance (comme un administrateur) ou aux applications de confiance (comme 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 unactor
et unenv
.
Application et détermination des accès
Dans un environnement de santé complexe où coexistent plusieurs règles et consentements, l'application de l'accès et la détermination des autorisations d'accès peuvent être une tâche ardue. Différents acteurs peuvent avoir des attentes et des exigences différentes concernant l'utilisation et la divulgation des informations sur les patients. Pour s'y retrouver dans ce paysage complexe, il est nécessaire 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 concernant le consentement agrégé
Un consommateur de soins de santé, tel qu'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 Consent, mais jusqu'à 200 ressources active
Consent sont appliquées à la fois. Pour en savoir plus, consultez 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 et à un environnement au maximum par entrée provision.
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é s'il n'existe aucune directive correspondante.
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 rencontre, l'accès est refusé.
Mais :
Si une règle d'administration refuse les critères d'accès, 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'accès pour les critères de ressources identifiables (c'est-à-dire le type 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 faire correspondre les ressources dans le magasin.
Les ressources qui n'appartiennent à aucun patient sont déterminées uniquement par les règles d'administration.
Les ressources qui se trouvent dans le compartiment du patient (STU3, R4) ou dans le compartiment de la rencontre (STU3, R4) doivent comporter au moins une directive d'autorisation par patient ou une règle d'administration ou une règle d'administration en cascade, et aucune directive de refus de consentement de la part 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 prendre en charge plusieurs patients participants. Par exemple, Rendez-vous fournit une liste de 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. Dans le cas contraire, les ressources ne sont pas renvoyées. Si une ressource dispose d'une autorisation provenant d'une règle de cascade de rencontres, 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.
- Certaines ressources peuvent prendre en charge plusieurs patients participants. Par exemple, Rendez-vous fournit une liste de 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. Dans le cas contraire, les ressources ne sont pas renvoyées. Si une ressource dispose d'une autorisation provenant d'une règle de cascade de rencontres, où cette rencontre fait référence à un patient via le champ
Les règles décrites sont résumées par le pseudo-code suivant :
Contrôle des accès conjoint
ifresource
does not exist ifresource
is a patient-compartment or encounter-compartment resource: return "deny" else: if there is any admin policy denies access foraccessor criteria
regardless ofresource criteria
other than resource type and resource ID: return "deny" else if there is any admin policy permits access foraccessor criteria
based on the identifiableresource criteria
: return "resource not found" else: return "deny" else: letpatients
= list of patient references named in the patient compartment eligible fields of the requestedresource
if there is any matching deny from eitherpatients
's consents or admin policy or admin cascading policy: return "deny" if there is matching admin policy permits access: return "permit" if allpatients
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 ni mise en cascade à des fins de vérification de l'accès au consentement.
Par exemple, prenons le cas d'un patient identifié par Patient/f001
qui permet à un professionnel d'accéder à l'intégralité de ses 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
même, par exemple, lorsqu'il effectue 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 conflictuelles 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 vers un magasin FHIR, le contrôle des accès se produit dans l'ordre suivant :
L'API Cloud Healthcare vérifie les autorisations sur le compte de service (ou le compte principal) Google Cloudconfiguré 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 magasin FHIR, la requête aboutit.
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
etApplyAdminConsents
.
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 d'autorisation effectuées.Fournissez tous les champs d'application
purpose
etenvironment
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
oufhir.search
), l'application du consentement s'applique à chaque ressource. Toutefois, il existe une différence subtile 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
etfhir.Encounter-everything
se comportent de la même manière quefhir.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 la rencontre concernés, respectivement.
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 instructions d'autorisation ne spécifient pas les trois propriétés d'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, 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 instructions 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