Points clés - Checklist de conformité HIPAA

Ce guide explique le sujet Checklist de conformité HIPAA avec un contexte pratique. HIPAA dépasse largement l'analytics web, mais une checklist HIPAA ne peut plus ignorer les pages de rendez-vous, les portails patients et les pixels.

La conformité HIPAA dépasse largement l’analytics web, mais l’analytics fait désormais partie des domaines que les organisations de santé ne peuvent pas ignorer. Les pages de prise de rendez-vous, les portails patients, les recherches de symptômes, les annuaires de prestataires et les pixels publicitaires peuvent révéler un contexte de santé. Si cette information est liée à une personne, elle peut devenir une protected health information.

Mise en garde importante pour 2024 : HHS indique qu’un tribunal fédéral a annulé une partie du bulletin d’OCR sur les technologies de suivi, dans la mesure où il appliquait la théorie selon laquelle une adresse IP plus une visite de certaines pages publiques non authentifiées déclencherait automatiquement des obligations HIPAA. Le bulletin reste pertinent, mais les équipes doivent distinguer les pages publiques éducatives non authentifiées des portails, rendez-vous, formulaires d’admission, paiements, pages authentifiées et workflows qui divulguent des informations de santé.

Cette checklist n’est pas un conseil juridique, mais elle donne aux équipes de santé un parcours d’examen pratique avant de déployer de l’analytics, des pixels, des widgets de chat ou des outils de session replay.

Savoir si HIPAA s’applique

HIPAA s’applique aux covered entities et aux business associates. Les covered entities comprennent de nombreux prestataires de santé, plans de santé et healthcare clearinghouses. Les business associates sont des fournisseurs qui créent, reçoivent, maintiennent ou transmettent des protected health information pour le compte d’une covered entity.

HHS explique que la Security Rule exige des garanties administratives, physiques et techniques raisonnables et appropriées pour les electronic protected health information (résumé de la Security Rule par HHS). Les business associates peuvent être directement responsables de nombreuses obligations HIPAA.

Si votre organisation n’est ni une covered entity ni un business associate, d’autres lois sur la confidentialité peuvent tout de même s’appliquer. N’utilisez pas « pas HIPAA » comme raccourci pour « aucun risque de confidentialité ».

Examiner attentivement les technologies de suivi

HHS OCR a publié des recommandations sur les technologies de suivi en ligne, expliquant que les règles HIPAA s’appliquent lorsque des entités régulées collectent ou divulguent des PHI au moyen de technologies de suivi. Les recommandations couvrent les pixels, cookies, web beacons, scripts de suivi et outils similaires (recommandations HHS sur les technologies de suivi en ligne).

Pour les sites web de santé, le risque ne se limite pas aux portails patients connectés. Les pages publiques doivent être classées avec soin : une page générique d’horaires de visite est différente d’un flux de prise de rendez-vous, d’une interaction de recherche de prestataire, d’un formulaire d’admission, d’une page de paiement ou d’une page où l’utilisateur soumet des informations sur des soins. Le contexte et les informations divulguées comptent.

Avant de déployer de l’analytics, demandez-vous :

• L’outil reçoit-il des URL complètes ou des titres de page qui révèlent des sujets de santé ?
• Collecte-t-il l’adresse IP, des données d’appareil ou des identifiants ?
• Dépose-t-il des cookies ou relie-t-il les visites entre les sessions ?
• Reçoit-il des soumissions de formulaires, des termes de recherche ou des métadonnées de rendez-vous ?
• Le fournisseur est-il prêt à signer un business associate agreement lorsque c’est requis ?
• Les données alimentent-elles de la publicité, du retargeting ou des audiences lookalike ?

Si le fournisseur ne signe pas de BAA et que des PHI peuvent être divulguées, n’envoyez pas les données.

Garanties administratives

Attribuez la responsabilité de la confidentialité et de la sécurité. Maintenez des politiques d’accès, de formation du personnel, d’approbation des fournisseurs, de réponse aux incidents et de conservation des données. Gardez un inventaire à jour des systèmes qui stockent ou transmettent des ePHI, y compris les outils d’analytics et de marketing.

Effectuez une analyse des risques et une gestion des risques. Documentez les menaces, leur probabilité, leur impact et les mesures d’atténuation. Le suivi web doit faire partie de cette analyse, pas être une réflexion tardive appartenant uniquement au marketing.

Garanties physiques et techniques

Limitez l’accès aux systèmes et aux locaux. Utilisez des accès fondés sur les rôles, l’authentification multifacteur, des journaux d’audit, le chiffrement en transit, le chiffrement au repos lorsque c’est approprié et des processus de sauvegarde sécurisés.

Pour l’analytics en particulier, utilisez des propriétés d’événements en allowlist. Ne laissez pas les développeurs envoyer des champs de formulaire ou des paramètres d’URL arbitraires dans l’analytics. Supprimez les données personnelles des URL. Évitez le session replay sur les pages de santé sauf s’il est clairement justifié et configuré pour masquer le contenu sensible.

Gestion des business associates

Maintenez des BAA avec les fournisseurs qui traitent des PHI pour votre compte. Une politique de confidentialité ou des conditions SaaS standard ne remplacent pas un BAA. Examinez les sous-traitants, l’accès support, la localisation des données, les obligations de notification de violation et les droits de suppression.

Si un fournisseur dit que son produit est « HIPAA ready », vérifiez ce que cela signifie. Signe-t-il des BAA ? Pour quel niveau de produit ? Quelles fonctionnalités sont exclues ? Les intégrations publicitaires sont-elles désactivées ? Les logs sont-ils couverts ?

Préparation aux violations

La HIPAA Breach Notification Rule exige des notifications après une violation de PHI non sécurisées, sous réserve de règles spécifiques d’évaluation et de calendrier. HHS résume ces obligations dans ses recommandations sur la Breach Notification Rule.

Préparez un playbook avant qu’un incident ne survienne. Il doit couvrir la détection, le confinement, la coordination avec les fournisseurs, l’examen juridique, la notification des patients, la notification du régulateur, la notification des médias lorsque c’est requis et la documentation.

Analytics respectueux de la vie privée pour la santé

Les sites de santé ont souvent besoin de métriques opérationnelles de base : visites de pages, referrers, abandons dans le funnel de rendez-vous, landing pages de campagne et taux de complétion des formulaires. Ces objectifs ne nécessitent pas de pixels de retargeting ni de profils comportementaux persistants.

Une configuration d’analytics respectueux de la vie privée devrait éviter les cookies lorsque c’est possible, minimiser les identifiants, exclure les URL ou paramètres sensibles, agréger les rapports, utiliser une conservation courte et garder les données séparées des systèmes publicitaires. Pour les entités régulées, la posture HIPAA du fournisseur et les BAA restent importants.

La question analytics la plus sûre dans la santé n’est pas « Jusqu’où pouvons-nous suivre ? ». C’est « Quelle est la mesure minimale dont nous avons besoin pour améliorer l’accès des patients sans exposer de PHI ? ».

Modèle de mise en œuvre compatible avec l’analytics

Une configuration d’analytics de santé plus sûre commence par la classification des pages. Marquez les pages comme publiques à faible risque, publiques avec contexte de santé, patient authentifié, paiement ou support. Appliquez des règles de suivi différentes à chaque classe. Par exemple, une page d’accueil générique peut autoriser une analytics agrégée, tandis que les pages de rendez-vous, symptômes, portail et paiement peuvent exiger des contrôles plus stricts ou aucune analytics tierce.

Ensuite, construisez une allowlist pour les noms et propriétés d’événements. Les développeurs ne doivent pas pouvoir envoyer des champs de formulaire arbitraires dans l’analytics. Supprimez les paramètres de requête qui contiennent des tokens, emails, identifiants de rendez-vous ou termes de recherche. Masquez ou supprimez les titres de page lorsqu’ils révèlent des conditions sensibles.

Enfin, examinez les fournisseurs chaque année et après les changements majeurs de produit. Un BAA signé il y a deux ans ne garantit pas qu’une fonctionnalité nouvellement activée, un subprocessor ou un add-on d’IA corresponde à votre modèle de risque HIPAA.

Contrôles d’analytics pour la santé

Pour l’analytics de santé, séparez la mesure de l’éducation publique des workflows de rendez-vous, portail, admission, paiement, spécifiques à une condition et authentifiés. Gardez les payloads analytics exempts de noms, emails, numéros de patient ou de dossier, détails de rendez-vous, texte de formulaire, query strings sensibles et identifiants capables de relier un visiteur à des soins.

Si un fournisseur reçoit des PHI, confirmez le rôle HIPAA, le BAA, les contrôles d’accès, la conservation, les subprocessors et le workflow de violation avant que le tag ne soit déployé. Si un fournisseur ne prend pas en charge le rôle HIPAA requis, supprimez le flux de données plutôt que d’essayer de l’enfouir dans une notice.

Questions fréquentes

Qu’est-ce qui compte comme information de santé protégée sur un site web ?

Une PHI est une information de santé liée à une personne identifiable, que ce soit un nom, l’heure d’un rendez-vous, un diagnostic mentionné dans un formulaire ou une adresse IP associée à une recherche de symptômes. Les pages de rendez-vous, les portails patients et les formulaires de vérification de symptômes créent un risque de PHI dès qu’un outil de suivi capture ce contexte avec un identifiant. Dès qu’une page révèle une information de santé sur un visiteur identifiable, l’analyse HIPAA doit commencer là, pas au niveau du serveur.

Un business associate agreement couvre-t-il tous les fournisseurs qui touchent un site de santé ?

Seulement si ce fournisseur crée, reçoit, conserve ou transmet des PHI pour le compte d’une covered entity, car c’est ce qui déclenche le statut de business associate. Un fournisseur qui ne reçoit jamais de PHI, parce que les données sont retirées ou agrégées avant de lui parvenir, n’a pas besoin de BAA pour ce flux de données. L’approche du checklist consiste à classer d’abord chaque page et chaque charge de données, puis à décider quels fournisseurs en ont réellement besoin.

Qu’est-ce qui a changé avec la décision de justice de 2024 sur la directive de suivi de HHS ?

Un tribunal fédéral a annulé la partie du bulletin d’OCR sur les technologies de suivi qui traitait une adresse IP combinée à la visite de certaines pages publiques non authentifiées comme une preuve automatique de divulgation au sens de HIPAA. Le reste du bulletin s’applique toujours, et la directive plus large d’OCR sur les pixels, cookies et scripts de suivi n’a pas disparu. Les équipes doivent encore distinguer les simples pages publiques d’information des portails, rendez-vous, admission et paiement qui, eux, révèlent une information de santé.

Un site de santé peut-il utiliser des outils d’analytics ?

Oui, tant que la configuration évite d’envoyer des PHI à un fournisseur qui refuse de signer un BAA, ou évite de collecter des PHI dès le départ grâce à des propriétés en liste blanche et des URL nettoyées. Les indicateurs opérationnels de base, visites de page, référents, abandon dans l’entonnoir, pages de campagne, ne nécessitent ni pixels de retargeting ni profils persistants. L’objectif est la mesure minimale nécessaire pour améliorer l’accès des patients, pas le maximum de données qu’un outil peut collecter.

Quelle est la différence entre une covered entity et un business associate ?

Une covered entity est un prestataire de soins, une caisse d’assurance santé ou une chambre de compensation de soins de santé directement régulée par HIPAA. Un business associate est un fournisseur, une plateforme d’analytics, un widget de chat, un outil de session replay, qui crée, reçoit, conserve ou transmet des PHI pour le compte de cette covered entity. Les business associates peuvent porter une responsabilité directe sur de nombreuses obligations HIPAA qui leur sont propres, pas seulement des obligations contractuelles transmises par la covered entity.

À quelle fréquence une équipe de santé doit-elle revoir ses BAA fournisseurs ?

Le checklist recommande de revoir les fournisseurs chaque année, puis à nouveau après tout changement produit majeur, car un BAA signé il y a deux ans ne dit rien sur une fonctionnalité, un sous-traitant ou un module d’IA que le fournisseur a activé le mois dernier. Une allégation « HIPAA ready » d’un fournisseur mérite la même vérification : quel niveau signe un BAA, quelles fonctionnalités sont exclues, si les intégrations publicitaires et les journaux sont couverts. L’accord doit être traité comme quelque chose qui vieillit, pas comme un document signé une fois puis classé.

Que doit contenir une liste blanche pour les événements d’analytics ?

Une liste blanche d'analytics doit nommer précisément les propriétés d’événement que les développeurs sont autorisés à envoyer, plutôt que de laisser la porte ouverte à des champs de formulaire ou des paramètres d’URL arbitraires. Les paramètres de requête contenant des tokens, des e-mails, des identifiants de rendez-vous ou des termes de recherche sont retirés avant d’atteindre l’outil d’analytics, et les titres de page qui révèlent une condition de santé sont masqués ou supprimés. Tout ce qui sort de la liste blanche ne part pas, point final.

Le logiciel de session replay crée-t-il un risque HIPAA sur les pages de santé ?

Oui. Les outils de replay capturent ce qu’un visiteur a tapé et cliqué, ce qui, sur une page de rendez-vous ou d’admission, peut inclure une information de santé liée à cette personne. Le checklist recommande d’éviter le session replay sur les pages de santé sauf justification claire, avec un outil configuré pour masquer le contenu sensible. Une session replay non masquée sur un formulaire de symptômes fait partie des schémas de suivi les plus risqués qu’un site puisse faire tourner.

Qu’est-ce qui déclenche la Breach Notification Rule de HIPAA ?

Une violation de PHI non sécurisées déclenche la règle, sous réserve des exigences d’évaluation et de délais que HHS détaille dans sa directive sur la Breach Notification Rule. C’est pourquoi le checklist demande un plan avant qu’un incident ne survienne, couvrant détection, confinement, coordination avec les fournisseurs, revue juridique et les notifications aux patients, régulateurs et médias qu’une violation peut exiger. Attendre d’avoir construit ce plan après qu’un pixel de suivi a laissé fuiter des données de rendez-vous, c’est trop tard.

Une politique de confidentialité suffit-elle à la place d’un business associate agreement ?

Non. Le checklist est clair sur ce point : une politique de confidentialité ou des conditions SaaS standard ne remplacent pas un BAA quand un fournisseur traite des PHI pour le compte d’une covered entity. Une vraie revue de BAA couvre les sous-traitants, l’accès support, la localisation des données, les obligations de notification de violation et les droits de suppression, ce qu’une politique de confidentialité générique ne couvre pas.