Um Business Associate Agreement (BAA) é um contrato escrito exigido pela HIPAA entre uma covered entity e um fornecedor que lida com informações de saúde protegidas (PHI) em seu nome. Ele vincula legalmente esse fornecedor — o business associate — a proteger a PHI, usá-la apenas conforme permitido e reportar violações. Sem um BAA assinado, compartilhar PHI com o fornecedor é, por si só, uma violação da HIPAA.
Covered entity vs business associate
A HIPAA divide o mundo em dois papéis, e o BAA é o contrato entre eles:
| Covered entity | Business associate | |
|---|---|---|
| Quem | Planos de saúde, clearinghouses, prestadores que transmitem dados de saúde eletronicamente | Qualquer fornecedor que cria, recebe, mantém ou transmite PHI para uma covered entity |
| Exemplos | Hospitais, clínicas, seguradoras | Provedores de nuvem, empresas de faturamento, fornecedores de analytics, serviços de transcrição |
| Obrigação sob a HIPAA | Conformidade completa com a Privacy Rule e a Security Rule | Proteger a PHI conforme o BAA e as regras aplicáveis |
| Precisa de um BAA com | Cada business associate | Cada subcontratado que toca em PHI |
A cadeia importa: um business associate que entrega PHI ao seu próprio subcontratado também precisa de um BAA com esse subcontratado. As obrigações da HIPAA descem até o fim da cadeia.
O que um BAA deve conter
A HIPAA prescreve os elementos obrigatórios. Um BAA em conformidade define os usos permitidos e exigidos da PHI, exige que o business associate implemente salvaguardas apropriadas, obriga-o a reportar incidentes de segurança e violações, exige que ele vincule seus subcontratados aos mesmos termos e prevê a devolução ou destruição da PHI no encerramento do contrato. É o instrumento que torna um fornecedor legalmente responsável pela ePHI que, de outra forma, ele manejaria sem nenhum dever sob a HIPAA.
A lacuna dos BAAs no rastreamento de sites
É aqui que os BAAs colidem com a web moderna. Um hospital pode ter BAAs impecáveis com seu fornecedor de EHR, seu provedor de nuvem e sua empresa de faturamento — e ainda assim ficar exposto, porque uma tag de marketing no seu site transmite dados de pacientes a um fornecedor que não tem BAA e não vai assinar um.
Os produtos padrão de Analytics e Ads do Google e o pixel da Meta não são oferecidos sob um BAA para esse uso, e seus termos geralmente proíbem enviar PHI a eles. Então, quando um script de rastreamento em uma página voltada a pacientes captura um identificador junto com contexto de saúde — transformando-o em ePHI — e o envia para essas plataformas, não há nenhum acordo protegendo esses dados, e estruturalmente não pode haver. Esse é o núcleo do problema do rastreamento de sites sob a HIPAA e da fiscalização do OCR que veio em seguida.
Fechando a lacuna
Um BAA é um controle legal; ele não pode impedir uma transmissão que nunca cobriu. Fechar a lacuna exige saber quais scripts rodam em páginas com contexto de saúde e para onde eles enviam dados — monitoramento de privacidade na camada do navegador que revela um pixel enviando PHI a um fornecedor sem BAA antes que isso vire uma violação reportável. Equipes que avaliam opções aqui costumam comparar cside e Feroot, os dois fornecedores de monitoramento client-side posicionados para conformidade na área da saúde.
A conclusão
Um BAA estende as proteções da HIPAA a fornecedores que você não controla — mas apenas aos fornecedores que assinam um. Os fornecedores perigosos são os que lidam com PHI sem um BAA, e em sites de saúde esses geralmente são os scripts de publicidade e analytics que ninguém classificou como business associates em primeiro lugar.
