Consentement, autorisation et règle du minimum nécessaire en pratique

Une équipe de recherche en cardiologie écrit au bureau des données : « Nous avons besoin de l'export complet de l'EHR (Electronic Health Record, dossier patient informatisé) pour chaque patient ayant eu un cathétérisme cardiaque au cours des trois dernières années. Tous les champs. Pour vendredi. » Le responsable clinique est co-auteur. La lettre de l'IRB (Institutional Review Board, le comité qui approuve la recherche sur l'humain) est en pièce jointe.

Lancez-vous cette requête ? Non. Pas telle quelle. Voyons pourquoi, et à quoi ressemble réellement une extraction conforme.

Trois portes juridiques différentes

Sous HIPAAHIPAAHealth Insurance Portability and Accountability Act, loi américaine imposant la protection des données de santé (PHI). Violations : amendes jusqu'à 1,9M$ par catégorie de violation. (le Health Insurance Portability and Accountability Act américain de 1996, appliqué par l'Office for Civil Rights du Department of Health and Human Services, « OCR »), les PHI (Protected Health Information, c'est-à-dire les données de santé identifiables) peuvent circuler pour différentes raisons par différentes portes. Confondre les portes est la défaillance de gouvernance la plus fréquente.

Porte 1 : le consentement de soins

Quand un patient signe les formulaires d'admission standards, il consent à l'usage de ses données pour le TPO : Treatment (soins), Payment (paiement) et healthcare Operations (fonctionnement de l'établissement). Un cardiologue qui consulte le dossier de son propre patient pour planifier la pose d'un stent est dans le cadre des soins. Aucune formalité supplémentaire.

Point clé : le consentement de soins ne couvre pas la recherche. L'étude sur les cathétérismes est de la recherche, pas du soin. La porte 1 est fermée ici.

Porte 2 : l'autorisation

La recherche sur des PHI identifiables exige en général une autorisation HIPAA signée : une permission écrite et spécifique de chaque patient, qui nomme l'étude, les données utilisées, les destinataires et une date d'expiration. C'est plus strict que le consentement. C'est de l'opt-in, propre à une étude.

Donc si l'équipe de cardiologie veut des dossiers identifiables, il lui faut soit une autorisation signée de chaque patient, soit une dérogation formelle.

Porte 3 : la dérogation de l'IRB

L'IRB peut accorder une waiver of authorization (dérogation à l'autorisation) quand recueillir l'accord individuel est impraticable (par exemple une étude rétrospective sur 4 000 anciens cas de cathétérisme, dont beaucoup de patients sont désormais injoignables) et que le risque pour la vie privée est faible. La dérogation doit être documentée. Cette lettre de l'IRB en pièce jointe est ce que vous vérifiez en premier : accorde-t-elle explicitement une dérogation, et précise-t-elle le périmètre des données ?

Si la lettre approuve l'étude mais reste muette sur la dérogation, vous revenez poser la question. Ne présumez rien.

Données dé-identifiées et Limited Data Sets : les voies à moindre risque

Deux structures permettent d'avancer avec beaucoup moins de friction.

Données dé-identifiées. Si vous retirez les identifiants de sorte qu'un patient ne puisse raisonnablement être ré-identifié, les données ne sont plus des PHI et les règles d'autorisation HIPAA ne s'appliquent plus. HIPAA prévoit deux méthodes :

• Safe Harbor : retirer 18 types d'identifiants précis (noms, dates complètes sauf l'année, codes postaux au-delà des 3 premiers chiffres, numéros de dossier médical, etc.).
• Expert Determination : un statisticien qualifié certifie que le risque de ré-identification est très faible.

Limited Data Set (LDS). Une voie intermédiaire. Vous pouvez conserver certaines dates et un niveau de détail géographique (utile pour une étude cardiologique en séries temporelles) mais vous retirez les identifiants directs. Un LDS exige un Data Use Agreement (DUA) : un contrat signé qui encadre l'usage et le repartage des données par le destinataire.

Pour notre équipe de cardiologie, posez la question : ont-ils besoin des noms des patients et des adresses complètes ? Presque jamais. Ont-ils besoin des dates d'admission et de l'âge pour modéliser les résultats dans le temps ? Probablement. Cela oriente vers un LDS avec un DUA, pas vers une extraction identifiable complète.

Les recommandations officielles de l'OCR sur la dé-identification méritent d'être mises en favori : HHS de-identification guidance.

Europe : la couche RGPDRGPDRèglement de l'UE encadrant la collecte, le stockage et l'usage des données personnelles, avec des amendes indexées sur le chiffre d'affaires mondial.Voir la définition complète →

Si des patients sont dans l'UE, ou si les données arrivent dans une institution de l'UE, le RGPD (Règlement général sur la protection des données, en vigueur depuis 2018, appliqué par les autorités nationales de protection des données) s'applique. Les données de santé sont une « catégorie particulière » qui exige une base légale explicite. La recherche est une base reconnue, mais il faut malgré tout des garanties : minimisation des données, limitation des finalités, et souvent une DPIA (Data Protection Impact Assessment, une analyse de risque documentée). Le vocabulaire diffère de HIPAA, mais le réflexe est identique : collecter le moins, protéger le plus.

🎬 [VIDEO: "HIPAA and Research: Authorization vs Waiver" - youtube.com - un parcours concis de ce qui distingue une recherche nécessitant une autorisation signée d'une recherche couverte par une dérogation de l'IRB]

La règle du minimum nécessaire, appliquée dans la requête

Voici la partie que les équipes de gouvernance sautent. Le standard minimum necessary de HIPAA dit : n'utilisez ou ne divulguez que les PHI nécessaires à la finalité précise. Ce n'est pas une affiche de politique interne. C'est une contrainte que vous appliquez dans le SQLSQLSales Qualified Lead : un prospect que l'équipe commerciale a validé comme prêt pour une prise de contact directe et une proposition, après avoir passé des critères de qualification explicites.Voir la définition complète → lui-même.

« Tous les champs » échoue au minimum nécessaire par défaut. Le protocole d'étude liste les variables dont il a besoin. Votre requête doit retourner exactement celles-là, et rien d'autre.

Comparez la demande naïve et une extraction cadrée :

-- REJETÉ : viole le minimum nécessaire
SELECT * FROM encounters WHERE procedure_code IN ('93458','93459');

-- CADRÉ : uniquement les champs approuvés par le protocole, style LDS,
-- identifiants directs supprimés, dates conservées selon le DUA
SELECT
    hash_id                AS study_subject_id,  -- clé pseudonymisée
    year_of_birth,
    sex,
    admission_date,                              -- autorisé dans un LDS
    procedure_code,
    lvef_percent,                                -- fraction d'éjection cardiaque
    readmission_30d_flag
FROM encounters
WHERE procedure_code IN ('93458','93459')        -- codes de cathétérisme
  AND consent_or_waiver_status = 'APPROVED'       -- filtre sur la base légale
  AND admission_date >= '2023-01-01';

Remarquez quatre contrôles intégrés :

1. **Pas de SELECT *.** Chaque colonne est un choix délibéré, justifié par le protocole.
2. `hash_id` au lieu du nom ou du MRN. Les identifiants directs sont remplacés par une clé pseudonymisée. La table de ré-identification est conservée à part, sous contrôle d'accès.
3. Un filtre sur la base légale (consent_or_waiver_status = 'APPROVED'). Les dossiers sans base documentée ne sont jamais retournés.
4. Un plancher de date correspondant à la fenêtre d'étude approuvée. Pas « tout depuis toujours ».

Le minimum nécessaire est une discipline d'ingénierie des données, pas seulement une discipline juridique.

Les contrôles et audits à réellement mener

La gouvernance n'existe que si elle est vérifiable après coup. Menez ceux-ci :

1. Contrôle de périmètre avant diffusion

Avant qu'un export ne sorte, comparez les colonnes retournées à la liste de variables approuvée par l'IRB. Une réconciliation en une ligne : champs approuvés moins champs retournés doit être vide, et champs retournés moins champs approuvés doit être vide. Si la requête retourne home_phone alors que le protocole ne l'a jamais demandé, bloquez la diffusion.

2. Journalisation des accès et piste d'audit

Chaque accès aux PHI doit être journalisé : qui, quoi, quand, quel ensemble de patients, sous quelle base légale. La Security Rule de HIPAA exige des contrôles d'audit. Quand l'OCR enquête sur une violation, le journal est votre preuve. Pas de journal, pas de défense.

Une requête d'audit mensuelle simple : lister tous les exports de recherche, l'utilisateur demandeur, le nombre de lignes, et si un DUA ou un identifiant d'autorisation y est rattaché. Toute ligne avec une base légale nulle est un incident.

3. Audit ponctuel du minimum nécessaire

Échantillonnez les extractions réalisées. Pour chacune, demandez à un relecteur : « Cette étude aurait-elle pu répondre à sa question avec moins de champs ou des données plus grossières ? » Si des dates de naissance complètes ont été diffusées là où l'année de naissance suffisait, c'est un constat. Documentez-le et resserrez le modèle de requête.

4. Revue du risque de ré-identification

Pour tout ce qui est étiqueté dé-identifié, confirmez la méthode. Les extractions Safe Harbor ne doivent contenir aucun des 18 identifiants : lancez donc un scan automatisé des motifs de date de naissance, des codes postaux et des notes en texte libre (les notes laissent souvent fuir des noms). Le texte libre est la cachette classique des PHI ; scannez-le ou excluez-le.

5. Suivi des DUA et des expirations

Les autorisations et les DUA expirent. Tenez un registre avec les dates. Quand une autorisation arrive à échéance, l'usage en aval doit cesser. Une revue annuelle repère les jeux de données qui ont survécu à leur base légale.

Retour à l'équipe de cardiologie

Voici la décision, proprement :

• Consentement de soins ? Insuffisant. Il s'agit de recherche.
• Autorisation signée ? Nécessaire seulement s'ils insistent sur des données identifiables sans dérogation de l'IRB.
• Ce que vous livrez réellement : confirmez que la lettre de l'IRB accorde une dérogation ou qu'un LDS suffit, signez un DUA, puis lancez la requête cadrée ci-dessus qui ne retourne que les champs du protocole avec une clé pseudonymisée. Journalisez. Fixez une expiration.

« Tous les champs pour vendredi » devient « les champs approuvés sous DUA, journalisés, avec l'année de naissance au lieu des dates complètes ». Même étude, une fraction du risque.

À retenir

• Faites correspondre la porte à la finalité. Le consentement de soins (TPO) ne couvre jamais la recherche. La recherche sur des PHI identifiables exige une autorisation signée ou une dérogation d'IRB documentée.
• Privilégiez la structure la moins risquée. Des données dé-identifiées ou un Limited Data Set avec un Data Use Agreement répondent en général à la question de recherche sans export identifiable complet.
• Appliquez le minimum nécessaire dans le SQL. Interdisez SELECT *, ne retournez que les colonnes approuvées par le protocole, pseudonymisez les identifiants et filtrez sur une base légale documentée.
• Auditez, sinon ça n'a pas eu lieu. Journalisez chaque accès, réconciliez les colonnes diffusées avec la liste approuvée, scannez le texte libre à la recherche d'identifiants qui fuient, et suivez les expirations d'autorisations et de DUA.
• Le RGPD reflète le même réflexe. Pour les patients de l'UE, appliquez la minimisation des données, une base légale pour les données de santé de catégorie particulière, et une DPIA quand le risque est significatif.