Un Business Associate Agreement (BAA) est un contrat écrit exigé par HIPAA entre une covered entity et un prestataire qui traite des informations de santé protégées (PHI) pour son compte. Il lie juridiquement ce prestataire — le business associate — à protéger les PHI, à ne les utiliser que dans le cadre autorisé et à signaler les violations. Sans BAA signé, partager des PHI avec le prestataire constitue en soi une violation de HIPAA.
Covered entity vs business associate
HIPAA divise le monde en deux rôles, et le BAA est le contrat qui les relie :
| Covered entity | Business associate | |
|---|---|---|
| Qui | Régimes d'assurance santé, chambres de compensation, prestataires transmettant des données de santé par voie électronique | Tout prestataire qui crée, reçoit, conserve ou transmet des PHI pour une covered entity |
| Exemples | Hôpitaux, cliniques, assureurs | Hébergeurs cloud, sociétés de facturation, fournisseurs d'analytique, services de transcription |
| Obligation HIPAA | Conformité complète à la Privacy Rule et à la Security Rule | Protéger les PHI conformément au BAA et aux règles applicables |
| A besoin d'un BAA avec | Chaque business associate | Chaque sous-traitant qui touche aux PHI |
La chaîne compte : un business associate qui confie des PHI à son propre sous-traitant a aussi besoin d'un BAA avec ce sous-traitant. Les obligations de HIPAA se propagent jusqu'en bas de la chaîne.
Ce qu'un BAA doit contenir
HIPAA prescrit les éléments obligatoires. Un BAA conforme définit les utilisations autorisées et requises des PHI, impose au business associate de mettre en place des mesures de protection appropriées, l'oblige à signaler les incidents de sécurité et les violations, exige qu'il lie ses sous-traitants aux mêmes clauses, et prévoit la restitution ou la destruction des PHI à la résiliation du contrat. C'est l'instrument qui rend un prestataire juridiquement responsable des ePHI qu'il traiterait sinon sans aucune obligation au titre de HIPAA.
L'angle mort des BAA : le suivi des sites web
C'est ici que les BAA se heurtent au web moderne. Un hôpital peut avoir des BAA irréprochables avec son fournisseur d'EHR, son hébergeur cloud et sa société de facturation — et rester exposé, parce qu'une balise marketing sur son site web transmet des données de patients à un prestataire qui n'a pas de BAA et n'en signera pas.
Les produits standard Analytics et Ads de Google et le pixel de Meta ne sont pas proposés sous BAA pour cet usage, et leurs conditions interdisent généralement de leur envoyer des PHI. Ainsi, quand un script de suivi sur une page destinée aux patients capture un identifiant accompagné d'un contexte de santé — le transformant en ePHI — et l'envoie à ces plateformes, aucun accord ne le protège, et structurellement aucun ne le peut. C'est le cœur du problème du suivi des sites web sous HIPAA et des actions d'application de l'OCR qui ont suivi.
Combler l'écart
Un BAA est un contrôle juridique ; il ne peut pas empêcher une transmission qu'il n'a jamais couverte. Combler l'écart exige de savoir quels scripts s'exécutent sur les pages à contexte de santé et où ils envoient les données — une surveillance de la confidentialité au niveau du navigateur qui repère un pixel envoyant des PHI à un prestataire sans BAA avant que cela ne devienne une violation à déclarer. Les équipes qui évaluent les options comparent souvent cside et Feroot, les deux fournisseurs de surveillance côté client positionnés sur la conformité dans le secteur de la santé.
Ce qu'il faut retenir
Un BAA étend les protections de HIPAA à des prestataires que vous ne contrôlez pas — mais uniquement à ceux qui en signent un. Les prestataires dangereux sont ceux qui traitent des PHI sans BAA, et sur les sites web de santé, ce sont généralement les scripts publicitaires et d'analytique que personne n'a classés comme business associates au départ.
