La conformité HIPAA en matière de suivi web exige des entités couvertes et de leurs associés commerciaux qu'ils évaluent chaque technologie de suivi tiers déployée sur des pages susceptibles de traiter des informations de santé protégées (PHI). Selon les directives de l'OCR du HHS publiées en décembre 2022 et mises à jour en mars 2024, les scripts qui collectent des adresses IP, des chemins de navigation ou des termes de recherche liés à la santé sur des pages patients authentifiées peuvent constituer une violation de la HIPAA sans les mesures de protection appropriées et les Accords de Partenariat Commercial en place.
Pourquoi les scripts de suivi créent un risque HIPAA
Les sites web de santé attirent un type d'intention utilisateur bien précis. Un visiteur qui recherche un "traitement pour la dépression" ou qui se connecte à un portail patient partage des informations de santé lors de cette interaction, même sans remplir de formulaire. Les outils standard d'analyse web et de publicité capturent ces données d'interaction par conception.
Le problème est que ces outils — Google Analytics, Meta Pixel, LinkedIn Insight Tag, services d'enregistrement de sessions et des centaines d'autres — envoient les données collectées vers des serveurs tiers. Lorsque le contexte de la page est celui d'un prestataire de santé, ces données constituent fréquemment des PHI au regard de la HIPAA, et le processeur de données doit alors disposer d'un Accord de Partenariat Commercial (BAA). La plupart des fournisseurs de suivi ne signent pas de BAA couvrant ces données. Google Analytics, Meta et les plateformes similaires financées par la publicité excluent généralement les données de suivi de santé de la couverture BAA ou refusent tout simplement d'en signer un.
Les directives OCR de 2022 et ce qui a changé
Avant décembre 2022, de nombreuses organisations de santé supposaient que les pixels de suivi étaient autorisés sur les pages publiques car les patients ne s'étaient pas connectés et aucun dossier médical n'était directement accessible.
Le bulletin de l'Office des droits civils (OCR) du HHS publié en décembre 2022 a mis fin à cette hypothèse. L'OCR a déclaré que les technologies de suivi sur les pages non authentifiées peuvent également exposer des PHI lorsque le contexte de la page révèle un état de santé : la page de prise de rendez-vous d'un hôpital, un vérificateur de symptômes ou une page de ressources sur des maladies spécifiques. Les directives mises à jour de mars 2024 ont assoupli la position initiale de l'OCR sur certains scénarios de pages non authentifiées, tout en maintenant que le suivi sur pages authentifiées sans BAA reste une violation.
Le test opérationnel selon les directives actuelles de l'OCR :
- L'entité est-elle une entité couverte ou un associé commercial HIPAA ?
- Les données collectées (adresse IP, URL, terme de recherche, source de référence) identifient-elles une personne en lien avec un problème de santé, un service médical ou un paiement de soins ?
- Le fournisseur de suivi dispose-t-il d'un BAA signé couvrant les données collectées ?
Si 1 et 2 sont positifs et 3 est négatif, la technologie de suivi crée une responsabilité au titre de la HIPAA.
Quelles données deviennent des PHI sur les sites web de santé
| Élément de données | Quand il devient PHI | Exemple de scénario |
|---|---|---|
| Adresse IP | Quand associée à une visite sur une page relative à un état de santé | Patient naviguant sur le service d'oncologie, IP envoyée à Meta Pixel |
| URL de la page | Quand l'URL contient un nom de maladie ou de traitement | Chemin /traitement-cancer ou /therapie-sante-mentale dans les analyses |
| URL de référence | Quand elle révèle un état de santé via une requête de recherche | Référence depuis la recherche "spécialiste maux de dos près de chez moi" |
| Termes de recherche sur le site | Toujours, sur les pages de santé authentifiées | Recherche sur le portail patient "médicament tension artérielle" |
| Statut de connexion | Sur les pages authentifiées | Utilisateur connecté au portail patient consultant ses résultats d'analyses |
| Données saisies dans les formulaires | Lors de la soumission de formulaires capturée par des enregistreurs de session | Description de symptômes dans un formulaire de demande de rendez-vous |
Niveau de risque par type de technologie de suivi
| Technologie | Ce qu'elle collecte | Risque HIPAA sur les pages patients | BAA généralement disponible ? |
|---|---|---|---|
| Google Analytics 4 | IP, URLs de pages, événements | Élevé | Portée limitée seulement |
| Meta Pixel | IP, URL, événements personnalisés | Élevé | Meta refuse le BAA |
| LinkedIn Insight Tag | IP, données professionnelles inférées | Moyen | LinkedIn refuse le BAA |
| Enregistrement de session (Hotjar, FullStory) | Frappes au clavier, saisies de formulaire, mouvements de souris | Très élevé | Variable ; vérifier la portée |
| Widgets de chat (Intercom, Drift) | Messages utilisateur, IP, pages consultées | Élevé si contenu de santé | BAA individuel requis |
| Outils de tests A/B | Variante de page, ID utilisateur, données de clics | Moyen | Consulter les conditions du fournisseur |
| Scripts tiers via CDN | Toutes données collectées par le script chargé | Selon l'objet du script | BAA du fournisseur parent requis |
Incidents documentés
Kaiser Permanente (2024) : Kaiser a divulgué une violation affectant 13,4 millions de membres, attribuée à des codes de suivi sur ses propriétés web et applications mobiles. Les scripts ont transmis les noms des membres, leurs adresses IP, leurs termes de recherche dans l'encyclopédie de santé et leur statut de connexion à des fournisseurs tiers. L'analyse complète de l'incident est disponible sur le blog de cside.
Novant Health (2022) : Novant Health a informé 1,3 million de patients que Meta Pixel intégré dans son portail patient et son intégration MyChart avait envoyé à Meta des détails de rendez-vous, des noms de médecins et des types de rendez-vous.
Cerebral (2023) : La plateforme de santé mentale a divulgué que les pixels de suivi Meta Pixel, Google et TikTok qu'elle avait déployés avaient capturé des données sensibles de santé mentale — y compris des déclarations de patients et des informations sur des conditions psychiatriques — transmises à ces plateformes publicitaires.
BetterHelp (2023) : La FTC a conclu un accord de 7,8 millions de dollars avec BetterHelp pour avoir partagé des données de santé de consommateurs, notamment des adresses e-mail et des réponses à des questionnaires de santé, avec Facebook et Snapchat à des fins de ciblage publicitaire.
Comment réaliser un inventaire des technologies de suivi
Une évaluation des risques alignée sur l'OCR pour les technologies de suivi couvre quatre étapes.
Étape 1 : Inventorier chaque script sur chaque page. L'examen manuel du gestionnaire de balises et du code source est insuffisant — les scripts chargés via des plateformes publicitaires, des CDN ou des widgets partenaires intégrés peuvent ne pas apparaître dans le gestionnaire de balises, et les scripts chargés conditionnellement nécessitent une observation en temps d'exécution.
Étape 2 : Classer les pages par sensibilité des données. Les pages marketing publiques comportent moins de risques que les portails patients, les vérificateurs de symptômes, les formulaires de prise de rendez-vous et toute page nécessitant une authentification. Établir une correspondance entre chaque type de page, les données qu'il traite et les scripts qui s'y chargent.
Étape 3 : Vérifier le statut BAA pour chaque fournisseur de suivi. Demander le BAA et lire les limitations de portée. La plupart des plateformes financées par la publicité excluent les données de santé de la couverture BAA même lorsqu'elles proposent un BAA à d'autres fins.
Étape 4 : Supprimer ou bloquer les scripts sans BAA des pages à risque élevé. Pour les traceurs pour lesquels aucun BAA n'est disponible ou a été refusé, les supprimer des pages sensibles ou utiliser une couche de gestion des scripts qui empêche leur chargement sur des chemins de pages spécifiques.
Contrôles techniques réduisant le risque HIPAA
Limiter les scripts aux pages autorisées. Utiliser le gestionnaire de balises pour empêcher les scripts d'analyse et de publicité de se charger sur les pages destinées aux patients. Ne pas déployer des scripts de suivi sur l'ensemble du site web de santé ; configurer des règles par page ou par section.
Utiliser une Politique de Sécurité du Contenu comme couche de contrôle. Une CSP peut bloquer des origines de scripts tiers non autorisés sur les pages patients. La CSP seule ne suffit pas — les scripts distribués via des domaines autorisés peuvent toujours collecter des données — mais elle réduit la surface d'attaque.
Connaître les limites de Subresource Integrity. SRI empêche un script d'être modifié en transit, mais n'empêche pas un script non modifié de collecter et transmettre des PHI par conception.
Surveiller le comportement en temps d'exécution, pas seulement la configuration. Le comportement des scripts évolue avec les mises à jour des fournisseurs, les tests A/B et les variations de distribution CDN. Surveiller en continu les données que les scripts tiers envoient réellement en temps d'exécution — et non ce que leur documentation indique — est nécessaire pour détecter les changements avant qu'ils ne deviennent des divulgations.
Comment Privacy Watch de cside adresse les risques des scripts de santé
Privacy Watch de cside surveille le comportement en temps d'exécution des scripts tiers sur les propriétés web, en identifiant quelles données chaque script lit depuis la page et où il les envoie. Pour les organisations de santé, cela signifie une visibilité continue sur le fait qu'un pixel de suivi déployé collecte des données liées aux PHI, quels domaines les reçoivent et si de nouveaux scripts apparaissent sur des pages qui devraient être restreintes.
Lorsqu'un script se charge sur une page en dehors de sa portée approuvée, Privacy Watch peut signaler l'événement et bloquer l'exécution du script avant que les données du patient ne quittent le navigateur. Cette couche de surveillance capture le comportement en temps d'exécution que les contrôles basés uniquement sur la configuration et les audits statiques des gestionnaires de balises ne peuvent pas détecter.
