Liste de conformité HIPAA pour l'analytique web

Si votre site web est en contact avec des patients, des adhérents ou des bénéficiaires d’un régime de santé, de quelque manière que ce soit (un vérificateur de symptômes, un portail patient, une recherche « trouver un médecin », voire un simple formulaire de demande de rendez-vous), votre dispositif d’analytique est plus proche d’un problème HIPAA que la plupart des équipes ne le pensent. Les outils de lecture de sessions, les traqueurs d’événements et même l’analytique de pages classique ont été conçus pour l’e-commerce, pas pour la santé, et ils capturent par défaut exactement le type de détail que la HIPAA vise à protéger.

La question n’est pas de savoir si vous êtes une « covered entity ». Elle est de savoir si les données collectées par votre outil d’analytique peuvent identifier une personne précise et ses informations de santé. C’est un seuil plus bas que ce que la plupart des équipes imaginent. Il est généralement franchi par accident, via un champ à saisie automatique, un paramètre d’URL ou une étiquette de formulaire, et non parce que quelqu’un envoie intentionnellement des données patient à un tiers.

Ce guide couvre trois aspects : les 18 identifiants qui font qu’une donnée devient une PHI et la façon dont ils s’infiltrent généralement dans l’analytique ; ce qu’un Business Associate Agreement (BAA) couvre ou ne couvre pas, et ce qu’il faut vérifier avant d’en signer un ; et une liste de vérification que vous pouvez utiliser pour auditer votre dispositif d’analytique actuel ou évaluer un nouveau fournisseur.

Les 18 identifiants HIPAA et où ils se cachent dans les données analytiques

La méthode Safe Harbor de la HIPAA (45 CFR § 164.514(b)(2)) répertorie 18 catégories d’identifiants qui, combinées à des informations de santé, transforment une donnée ordinaire en Protected Health Information. La plupart des explications sur ce sujet s’arrêtent à « voici ce qu’est une PHI ». La question la plus utile pour un éditeur de site web est : lequel de ces identifiants mon outil d’analytique capture-t-il réellement, et comment ?

#	Identifiant	Comment il s’infiltre généralement dans l’analytique
1	Noms	Saisis dans des formulaires de contact, des formulaires de rendez-vous ou des widgets de chat, et capturés par la lecture de sessions si le champ n’est pas masqué.
2	Subdivisions géographiques plus petites qu’un État	Champs d’adresse de facturation/livraison, champs de code postal, ou outils « trouver un établissement à proximité » qui transmettent une adresse comme propriété d’événement.
3	Dates relatives à une personne (naissance, admission, sortie, décès), sauf l’année	Sélecteurs de date de naissance sur les formulaires d’inscription ; date et heure de rendez-vous capturées comme propriété d’événement personnalisé.
4	Numéros de téléphone	Champs téléphone des formulaires de contact/rendez-vous, souvent pré-remplis par l’auto-complétion du navigateur et capturés par une lecture de sessions non masquée.
5	Numéros de fax	Formulaires d’orientation ou d’admission anciens qui incluent encore un champ fax.
6	Adresses e-mail	Formulaires de connexion, inscriptions à une newsletter, et boutons « recevoir mes résultats par e-mail », fréquemment envoyés comme propriétés d’événement pour l’attribution marketing.
7	Numéros de sécurité sociale	Formulaires de vérification d’assurance ou de facturation ; rare mais catastrophique si capturé, ces numéros n’étant quasiment jamais destinés à être enregistrés où que ce soit.
8	Numéros de dossier médical	Transmis dans un chemin d’URL ou une chaîne de requête (/patient/MRN12345) ou intégrés dans un objet data-layer envoyé à l’analytique.
9	Numéros de bénéficiaire d’un régime de santé	Champs d’identifiant d’assurance/adhérent sur les pages de vérification d’éligibilité ou de facturation.
10	Numéros de compte	Numéros de compte du portail patient affichés à l’écran et récupérés par une lecture de sessions non masquée.
11	Numéros de certificat/licence	Numéros de licence de praticien sur les pages « vérifier votre praticien » : risque plus faible, mais toujours sur la liste.
12	Identifiants de véhicule, y compris les plaques d’immatriculation	Rare pour la plupart des sites de santé ; pertinent pour les intégrations de voiturier ou de transport.
13	Identifiants d’appareil et numéros de série	Portails d’appareils connectés ou de DME (équipement médical durable) qui affichent un numéro de série d’appareil dans l’interface.
14	URL web	L’URL de la page elle-même, si le chemin ou la chaîne de requête encode des informations propres à un patient (voir #8).
15	Adresses IP	Collectées par défaut par presque toutes les plateformes d’analytique, souvent sans que personne ne réalise qu’elles doivent être anonymisées ou hachées.
16	Identifiants biométriques	Données d’empreinte vocale ou digitale issues des parcours d’authentification patient : en dehors de la plupart des outils d’analytique web, mais pertinent pour les applications de santé.
17	Photographies de visage complet et images comparables	Téléchargements de photo de profil, parcours de vérification d’identité, ou vignettes de vidéo de téléconsultation capturées par un outil d’analytique basé sur des captures d’écran.
18	Tout autre numéro, caractéristique ou code d’identification unique	Le plus souvent négligé : cookies de session/appareil, identifiants visiteur persistants, ou identifiants utilisateur internes qui peuvent être reliés à un dossier patient précis.

Deux schémas reviennent constamment lorsque cela tourne mal en pratique :

• La lecture de sessions est la surface d’exposition la plus large. Elle ne se contente pas d’enregistrer des champs structurés. Elle enregistre le DOM, ce qui signifie qu’elle peut capturer du texte que le développeur n’avait jamais prévu d’envoyer où que ce soit : valeurs auto-complétées, infobulles, messages d’erreur qui répètent ce qu’un utilisateur a saisi (« Aucun résultat pour John Smith »).
• Les URL et les événements personnalisés sont la deuxième surface la plus large. Les équipes masquent scrupuleusement les champs de formulaire mais oublient que l’URL elle-même ou un événement personnalisé bien intentionné (patient_search, appointment_booked, avec un nom ou un numéro de dossier médical comme propriété) transporte les mêmes identifiants en contournant le masquage.

L’identifiant n°18 mérite une mention particulière car c’est celui que les équipes contournent le plus souvent dans leur raisonnement : « nous ne collectons pas de noms, donc tout va bien ». Un identifiant d’appareil ou de session persistant qui peut être relié à une personne précise, même indirectement, même par une autre personne ayant accès au dossier de santé, constitue en lui-même un identifiant au sens de la Safe Harbor. C’est exactement le type d’arbitrage qu’un BAA et une configuration de déploiement documentée permettent de trancher.

Ce qu’un Business Associate Agreement couvre réellement

Un BAA est souvent traité comme une simple case à cocher (« en ont-ils un, oui ou non »), mais le contenu de l’accord compte davantage que sa simple existence. Deux fournisseurs peuvent tous deux « proposer un BAA » tout en désignant des réalités très différentes.

À quoi sert un BAA. Dans le cadre de la HIPAA, si un fournisseur crée, reçoit, conserve ou transmet des PHI pour le compte d’une covered entity, ce fournisseur est un « business associate » et la relation doit être encadrée par un BAA. L’accord établit les obligations du fournisseur : mesures de protection pour toute PHI traitée, délais de notification en cas de violation, restrictions sur l’usage des données, et ce qu’il advient des données sur demande ou à la résiliation.

Qui a réellement besoin d’un BAA. Vous avez besoin d’un BAA avec un fournisseur d’analytique s’il existe une probabilité réaliste que des PHI atteignent les systèmes de ce fournisseur. Compte tenu des points d’infiltration décrits ci-dessus, cela concerne la plupart des sites de santé proposant une quelconque interaction avec les patients, pas seulement les portails conçus pour héberger des dossiers médicaux. Un BAA n’est généralement pas nécessaire pour un site marketing sans formulaire propre aux patients, sans connexion ni portail, mais « nous pensons ne pas envoyer de PHI » est une position plus faible que « nous avons configuré l’outil pour que les PHI ne puissent pas être envoyées, et nous l’avons vérifié ».

Ce qu’il faut vérifier avant de signer. Quelques questions permettent de distinguer un BAA qui vous protège réellement d’un BAA purement formel :

• Correspond-il à ce que l’outil fait réellement, ou s’agit-il d’un texte standard ? Un modèle de BAA générique qui ne fait pas référence au produit spécifique (lecture de sessions, suivi d’événements, etc.) signale que le fournisseur n’a pas véritablement réfléchi aux points d’entrée possibles des PHI dans son système.
• Quel est le délai de suppression en cas de réception accidentelle de PHI ? Recherchez un nombre précis d’heures ou de jours, et non des formulations comme « rapidement » ou « dès que possible ».
• Le document précise-t-il que le fournisseur n’utilisera les PHI pour aucun autre usage que le service ? Pas d’analytique sur les PHI, pas d’entraînement de modèles, pas d’usage secondaire. Cela doit être explicite, pas sous-entendu.
• Les obligations sont-elles répercutées sur les sous-traitants ? Si le fournisseur utilise une infrastructure cloud ou des sous-traitants, ses obligations issues du BAA doivent juridiquement lier également ces sous-traitants (45 CFR 164.502(e)(1)(ii)).
• Quel est le délai de notification en cas de violation ? La HIPAA fixe une limite maximale de 60 jours (45 CFR 164.410) ; le BAA d’un fournisseur ne devrait pas se contenter de reprendre ce maximum légal comme norme. Un délai plus court est préférable, et la mention « sans délai déraisonnable » en complément de la limite maximale est bon signe.
• Le BAA modifie-t-il réellement le comportement par défaut du fournisseur, ou se contente-t-il de décrire une hypothèse ? Le signal le plus fort est un fournisseur qui active des paramètres par défaut plus stricts (par exemple, l’obfuscation complète du texte dans la lecture de sessions) spécifiquement pour les clients disposant d’un BAA, plutôt qu’un BAA qui se limite à décrire une responsabilité sans rien changer au produit.
• La signature du BAA laisse-t-elle entendre que vous pouvez désormais utiliser l’outil comme un entrepôt de PHI ? Ce ne devrait pas être le cas. Un BAA existe pour couvrir une transmission accidentelle, pas pour autoriser à utiliser un outil d’analytique comme un lieu de stockage intentionnel de données patient. Si le BAA d’un fournisseur se lit de cette manière, c’est un signal d’alerte sur le sérieux avec lequel il a réfléchi à la minimisation des données.

Le Business Associate Agreement d’Air360 est construit autour de ce dernier point : il vise à encadrer les obligations des parties en cas de transmission accidentelle de PHI, et non à autoriser l’usage d’Air360 comme un entrepôt de données patient.

Liste de vérification fournisseur : ce qu’il faut vérifier, et ce que fait Air360

Utilisez cette liste pour auditer votre dispositif d’analytique actuel, ou pour évaluer un nouveau fournisseur. Chaque ligne correspond à un élément que vous devriez pouvoir vérifier concrètement, et non simplement prendre pour acquis.

Vérification	Ce qu’il faut vérifier auprès de tout fournisseur	Ce que fait Air360
Disponibilité d’un BAA	Le fournisseur propose un BAA spécifique au produit que vous utilisez, et non un modèle générique.	BAA disponible pour les clients du secteur de la santé éligibles, couvrant le service d’analytique comportementale et de lecture de sessions d’Air360.
Masquage du texte dans la lecture de sessions	Le texte saisi par l’utilisateur est masqué par défaut, et non en option.	Masque par défaut le texte saisi par l’utilisateur dans les champs de saisie pour tous les clients ; les clients disposant d’un BAA bénéficient d’une obfuscation complète du texte de la page (pas seulement des champs de formulaire) activée par défaut.
Contrôles d’exclusion d’éléments/de pages	Vous pouvez exclure entièrement de la capture des éléments de page spécifiques (portails patient, formulaires de facturation, vues de dossier médical).	Contrôles d’exclusion configurables pour les éléments de page sensibles, les événements personnalisés et les métadonnées.
Minimisation des données par défaut	La configuration par défaut de l’outil évite de collecter des données sensibles, plutôt que de s’en remettre entièrement au client pour verrouiller la collecte.	Conçu selon un principe de minimisation des données : destiné à fonctionner sans collecter de PHI, même avant toute configuration spécifique du client.
Traitement des adresses IP	Les adresses IP sont anonymisées, hachées, ou non conservées sous une forme identifiable.	Utilisées uniquement pour déduire le pays, et non stockées sur les serveurs d’Air360.
Lieu d’hébergement des données et certifications de sécurité	Savoir où les données sont traitées et stockées, et quelles certifications couvrent l’infrastructure.	Les données clients sont traitées et stockées dans des centres de données couverts par ISO 27001/27017/27018, SOC 1/2/3 et PCI DSS. (La HIPAA n’exige pas en elle-même un hébergement aux États-Unis ; elle exige des mesures de protection appropriées et un BAA. Vérifiez que cela correspond à la politique de votre propre organisation.)
Chiffrement	Les données sont chiffrées en transit et au repos.	Chiffrement de pointe utilisé pour les données en transit et au repos sur l’ensemble des produits.
Contrôles d’accès	Le fournisseur applique l’authentification multifacteur et la journalisation des accès sur ses propres systèmes.	Authentification multifacteur obligatoire pour tous les utilisateurs accédant à l’application Air360.
Audits par des tiers	Le fournisseur fait l’objet d’un contrôle de sécurité indépendant, et pas seulement d’une auto-évaluation.	Audits de sécurité réguliers par des tiers, incluant des tests d’intrusion et des analyses de vulnérabilités, avant les versions majeures.
Notification en cas de violation/incident	Engagement contractuel sur un délai de notification précis, et pas seulement « conformément à la loi ».	Obligations de notification définies dans le BAA, avec une limite maximale de 60 jours conformément au 45 CFR 164.410.
Suppression sur demande	Le fournisseur s’engage à supprimer toute PHI reçue accidentellement dans un délai défini.	Suppression dans les 24 heures suivant une demande du client, ou sans délai déraisonnable dès la découverte.
Absence d’usage secondaire des PHI	Les PHI ne sont pas utilisées pour l’analytique propre du fournisseur, l’entraînement de modèles, ou le marketing.	Air360 n’utilise pas les PHI à des fins publicitaires, de profilage, de marketing, ou d’entraînement de modèles.

Une vérification de cinq minutes

Avant d’évaluer un fournisseur, il est utile de vérifier d’abord votre propre mise en œuvre. La majorité des expositions de PHI proviennent de la configuration, et non de l’outil d’analytique lui-même :

1. Ouvrez l’enregistrement d’une lecture de sessions correspondant à un parcours utilisateur réel sur vos pages destinées aux patients, et lisez-le comme le ferait une personne extérieure. Un nom, un e-mail, un numéro de téléphone ou un identifiant lisible apparaît-il à l’écran ?
2. Vérifiez les URL capturées par votre outil d’analytique. Certaines contiennent-elles un nom de patient, un numéro de dossier médical, ou un numéro de compte dans le chemin ou la chaîne de requête ?
3. Examinez vos propriétés d’événements personnalisés. L’une d’entre elles révélerait-elle quelque chose de précis sur un patient réel si une personne extérieure à votre organisation la voyait ?
4. Vérifiez que les champs de mot de passe, les formulaires de dossier médical et les formulaires de facturation/assurance sont explicitement exclus de la capture, et pas seulement couverts par un masquage générique.
5. Si vous disposez d’un BAA, relisez la section relative aux responsabilités du client et vérifiez que votre configuration actuelle satisfait effectivement à ce qu’elle prévoit.

Si vous évaluez Air360 pour un déploiement dans le secteur de la santé, notre déclaration HIPAA et notre guide de déploiement HIPAA détaillent précisément comment configurer la lecture de sessions, les événements et les propriétés personnalisées afin qu’aucune PHI n’atteigne jamais la plateforme.