+150 XP

Gouverner les PHI : HIPAA, dé-identification et exposition aux breaches

# Gouverner les PHI : HIPAA, dé-identification et exposition aux breaches

Un analyste marketing écrit à votre équipe data : « Puis-je avoir la liste des patients diabétiques avec les noms, les codes postaux et les dates d'admission ? Je veux cibler une campagne bien-être. » Cela semble anodin. C'est aussi une violation potentielle d'HIPAA, qui peut coûter des millions à votre hôpital et déclencher un signalement fédéral.

Comprendre pourquoi cette demande ne passe pas, et comment la reformuler pour qu'elle devienne légale, est la compétence centrale de cette leçon.

Les règles qui encadrent la donnée

Les PHI (Protected Health Information) désignent toute information de santé rattachable à une personne et détenue par une covered entity. Cela inclut les diagnostics, les résultats de laboratoire, les dates d'admission, et même le simple fait qu'une personne soit patiente.

HIPAA (Health Insurance Portability and Accountability Act) est la loi américaine de 1996 qui fixe les règles de base pour le traitement des PHI. Deux volets comptent surtout pour le travail sur la donnée :

  • La Privacy Rule encadre les cas où vous pouvez utiliser ou divulguer des PHI.
  • La Security Rule encadre la façon dont vous protégez les PHI électroniques (chiffrement, contrôles d'accès, audit logs).

Une covered entity est un hôpital, une clinique, un organisme d'assurance santé ou une chambre de compensation. Un business associate est un prestataire qui traite des PHI pour le compte de la covered entity (une société d'analytics cloud, un sous-traitant de facturation). Les business associates sont liés par contrat (un BAA, ou Business Associate Agreement) et sont directement responsables au titre d'HIPAA.

La source officielle est le US Department of Health and Human Services. Leur hub HIPAA for Professionals fait référence.

TPO : les usages qui ne nécessitent aucune autorisation du patient

HIPAA autorise l'usage des PHI sans accord du patient pour trois finalités, regroupées sous le sigle TPO (Treatment, Payment, and Operations).

Treatment. Partager des PHI pour soigner le patient. Un cardiologue consulte les notes des urgences sur ce même patient. Pleinement autorisé.

Payment. Facturation et remboursement. Envoyer des codes de diagnostic à un assureur pour faire payer une demande de remboursement. Autorisé.

Operations. Faire tourner l'hôpital : amélioration de la qualité, coordination des soins, accréditation, audits internes, formation. Une équipe qui analyse les taux de réadmission pour les réduire relève des operations. Autorisé.

Tout ce qui sort du TPO exige généralement soit une authorization du patient (un consentement signé et spécifique), soit une dé-identification (retirer de la donnée ce qui en fait des PHI).

Retour à la demande marketing

Faire du marketing pour vendre un produit bien-être sans lien avec les soins n'est pas du TPO. Selon la Privacy Rule, la plupart des actions marketing utilisant des PHI exigent une autorisation du patient. La demande de l'analyste, telle qu'elle est formulée, constitue donc une violation.

Mais il existe des voies légales :

  • La reformuler en operations. Si la « campagne » est en réalité un programme de care management destiné à aider les patients diabétiques existants à gérer leur pathologie, une partie peut relever des healthcare operations. Cela dépend des détails et d'une revue juridique, pas de votre seul avis.
  • Dé-identifier la donnée. Si l'analyste n'a besoin que de tendances de population (combien de patients diabétiques par région), fournissez-lui des données dé-identifiées. HIPAA ne s'applique alors plus.

La leçon : une même donnée sous-jacente peut être légale ou illégale selon la finalité et l'identifiabilité.

Le standard de dé-identification Safe Harbor

HIPAA prévoit deux méthodes de dé-identification. L'Expert Determination fait appel à un statisticien qualifié pour certifier un faible risque de ré-identification. La plupart des équipes data utilisent la méthode plus simple du Safe Harbor : supprimer 18 identifiants précis, et la donnée n'est plus un PHI.

Voici les 18 identifiants Safe Harbor à retirer :

1. Noms

2. Subdivisions géographiques plus fines que l'État (rue, ville, comté et la plupart des codes postaux)

3. Tous les éléments de date plus précis que l'année (date de naissance, date d'admission, date de sortie)

4. Numéros de téléphone

5. Numéros de fax

6. Adresses e-mail

7. Numéros de sécurité sociale

8. Numéros de dossier médical

9. Numéros de bénéficiaire de plan santé

10. Numéros de compte

11. Numéros de certificat ou de licence

12. Identifiants de véhicule et plaques d'immatriculation

13. Identifiants d'appareils et numéros de série

14. URL web

15. Adresses IP

16. Identifiants biométriques (empreintes digitales, empreintes vocales)

17. Photos du visage en entier et images comparables

18. Tout autre numéro, caractéristique ou code d'identification unique

Deux nuances font trébucher :

  • Codes postaux. Vous pouvez conserver les trois premiers chiffres, mais uniquement si l'unité géographique correspondante compte plus de 20 000 habitants. Pour les zones à trois chiffres peu peuplées, il faut remplacer ces chiffres par 000.
  • Âges de 90 ans et plus. Ils doivent être regroupés dans une catégorie unique « 90+ », car les âges très élevés sont assez rares pour identifier une personne.

La règle complète et les deux méthodes sont documentées dans la guidance de dé-identification du HHS.

Appliquer le safe harbor à la demande

L'analyste voulait des noms, des codes postaux et des dates d'admission. Les trois sont des identifiants Safe Harbor. Voici à quoi ressemble une transformation conforme :

python
import pandas as pd

# Extraction brute de PHI (ne sort jamais de la zone sécurisée sous cette forme)
df = pd.read_csv("diabetic_patients.csv")

# Transformations Safe Harbor
df = df.drop(columns=["name", "mrn", "phone", "email", "ssn"])

# Ne garder que le code postal à 3 chiffres ; neutraliser les préfixes peu peuplés
sparse = {"036", "059", "063", "102", "203", "556",
          "692", "790", "821", "823", "830", "831",
          "878", "879", "884", "890", "893"}
df["zip3"] = df["zip"].astype(str).str[:3]
df["zip3"] = df["zip3"].where(~df["zip3"].isin(sparse), "000")
df = df.drop(columns=["zip"])

# Dates réduites à l'année
df["admit_year"] = pd.to_datetime(df["admit_date"]).dt.year
df = df.drop(columns=["admit_date"])

# Âges 90+ regroupés
df["age"] = df["age"].clip(upper=90)

df.to_csv("diabetic_deidentified.csv", index=False)

L'analyste obtient maintenant des comptages régionaux de diabète par année, sans aucun moyen d'isoler un patient. HIPAA ne s'applique plus à ce fichier. La question de la campagne devient un problème de stratégie marketing, pas de conformité.

Il existe aussi une voie intermédiaire : le Limited Data Set, qui peut conserver les dates et une géographie partielle pour la recherche, la santé publique ou les operations, mais uniquement sous un Data Use Agreement signé. Il n'est pas dé-identifié : il reste donc un PHI, avec des restrictions.

Exposition aux breaches : ce qui se passe quand ça dérape

Un breach est une acquisition, un accès, un usage ou une divulgation non autorisés de PHI. Au titre de la Breach Notification Rule, une covered entity doit généralement :

  • Informer les personnes concernées sans délai déraisonnable, et au plus tard 60 jours après la découverte.
  • Informer le HHS.
  • Informer les médias si le breach touche 500 résidents ou plus d'un État ou d'une juridiction.

Les breaches importants sont publiés sur le portail d'enforcement du HHS, surnommé le « Wall of Shame ». Une attaque ransomware qui chiffre des PHI est présumée être un breach, sauf si vous pouvez démontrer une faible probabilité de compromission par une évaluation formelle du risque.

Les sanctions augmentent avec le degré de culpabilité, de la violation commise sans le savoir jusqu'à la négligence délibérée, et peuvent atteindre plusieurs millions de dollars par an en cas de violations répétées d'une même disposition. Au-delà des amendes, les breaches entraînent une atteinte à la réputation et une perte de confiance des patients, souvent le coût le plus lourd.

Les déclencheurs les plus fréquents dans la vraie vie sont banals : un ordinateur portable perdu sans chiffrement, un tableur envoyé par e-mail au mauvais destinataire, ou une base contenant des PHI laissée accessible à un ensemble trop large de collaborateurs. Une bonne gouvernance est ennuyeuse, et c'est voulu.

Vérification des acquis

1. Un analyste marketing demande une liste de patients avec noms, codes postaux et dates d'admission pour une campagne bien-être. Pourquoi cette demande échoue-t-elle au regard d'HIPAA, tel que décrit ?

2. Qu'est-ce qui distingue le mieux la Privacy Rule de la Security Rule d'HIPAA ?

3. Une société d'analytics cloud traite des données patients pour le compte d'un hôpital. Quelle affirmation décrit correctement son statut au regard d'HIPAA ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes sur ce qui constitue un PHI lorsqu'il est détenu par une covered entity.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes sur les finalités TPO qui permettent l'usage de PHI sans authorization du patient.

Sélectionnez toutes les réponses correctes.

Installer le réflexe de gouvernance

Les étapes techniques ne fonctionnent que dans un processus gouverné. Trois pratiques séparent les équipes data matures des équipes exposées.

Minimum necessary. Pour tout usage hors TPO, ne partagez que la donnée nécessaire à la tâche. L'analyste voulait des noms ; il avait besoin de comptages. Par défaut, donnez moins.

Accès basé sur les rôles et audit logs. Restreignez qui peut interroger les PHI bruts, et journalisez chaque accès. En cas d'enquête sur un breach, vous devez pouvoir montrer qui a touché à quoi.

Un point d'entrée pour les demandes. Toute demande de données doit répondre à trois questions avant d'être servie : quelle est la finalité ? Est-ce du TPO ? Sinon, existe-t-il une authorization, ou faut-il dé-identifier ? Un formulaire court intercepte la demande marketing avant qu'elle ne devienne un incident.

Rien de tout cela ne constitue un conseil juridique. Quand une demande se situe à la frontière du TPO, transmettez-la à votre privacy officer ou à votre juriste. Le rôle de l'analyste est de reconnaître la frontière, pas de trancher seul.

Points clés à retenir

  • Les PHI sont des informations de santé identifiables. Une fois dé-identifiées selon le Safe Harbor, HIPAA ne s'applique plus.
  • Le TPO (Treatment, Payment, Operations) ne nécessite aucune authorization. Presque tout le reste, y compris la majorité du marketing, en exige une.
  • Le Safe Harbor consiste à retirer 18 identifiants précis, avec un traitement particulier pour les codes postaux (garder trois chiffres uniquement si la zone dépasse 20 000 habitants) et les âges de 90 ans et plus (regroupés).
  • Les breaches imposent un délai de notification de 60 jours, un signalement public au-delà de 500 personnes touchées, et des sanctions proportionnelles à la négligence.
  • Gouvernez l'entrée des demandes, pas seulement la donnée. Appliquez le minimum necessary, restreignez les accès, journalisez tout, et remontez les demandes limites au privacy officer ou au juridique.