Un Business Associate Agreement (BAA) es un contrato escrito exigido por HIPAA entre una covered entity y un proveedor que maneja información de salud protegida (PHI) en su nombre. Vincula legalmente a ese proveedor — el business associate — a salvaguardar la PHI, usarla solo como está permitido y reportar brechas. Sin un BAA firmado, compartir PHI con el proveedor es en sí mismo una violación de HIPAA.
Covered entity vs business associate
HIPAA divide el mundo en dos roles, y el BAA es el contrato entre ambos:
| Covered entity | Business associate | |
|---|---|---|
| Quién | Planes de salud, centros de intercambio, proveedores que transmiten datos de salud electrónicamente | Cualquier proveedor que crea, recibe, mantiene o transmite PHI para una covered entity |
| Ejemplos | Hospitales, clínicas, aseguradoras | Alojamientos en la nube, empresas de facturación, proveedores de analítica, servicios de transcripción |
| Obligación bajo HIPAA | Cumplimiento completo de la Privacy Rule y la Security Rule | Salvaguardar la PHI según el BAA y las reglas aplicables |
| Necesita un BAA con | Cada business associate | Cada subcontratista que toca PHI |
La cadena importa: un business associate que entrega PHI a su propio subcontratista también necesita un BAA con ese subcontratista. Las obligaciones de HIPAA fluyen hasta el final de la cadena.
Qué debe contener un BAA
HIPAA prescribe los elementos requeridos. Un BAA conforme establece los usos permitidos y requeridos de la PHI, exige al business associate implementar salvaguardas apropiadas, lo obliga a reportar incidentes de seguridad y brechas, le exige vincular a sus subcontratistas a los mismos términos y prevé la devolución o destrucción de la PHI al terminar el contrato. Es el instrumento que hace a un proveedor legalmente responsable de la ePHI que de otro modo manejaría sin ningún deber bajo HIPAA.
La brecha de los BAA en el seguimiento web
Aquí es donde los BAA chocan con la web moderna. Un hospital puede tener BAAs impecables con su proveedor de EHR, su alojamiento en la nube y su empresa de facturación — y aun así estar expuesto, porque una etiqueta de marketing en su sitio web transmite datos de pacientes a un proveedor que no tiene BAA y no va a firmar uno.
Los productos estándar de Analytics y Ads de Google y el píxel de Meta no se ofrecen bajo un BAA para este uso, y sus términos generalmente prohíben enviarles PHI. Así que cuando un script de seguimiento en una página orientada a pacientes captura un identificador junto con contexto de salud — convirtiéndolo en ePHI — y lo envía a esas plataformas, no hay ningún acuerdo que lo proteja, y estructuralmente no puede haberlo. Este es el núcleo del problema del seguimiento web bajo HIPAA y de la acción de aplicación de la OCR que le siguió.
Cerrar la brecha
Un BAA es un control legal; no puede detener una transmisión que nunca cubrió. Cerrar la brecha requiere saber qué scripts se ejecutan en páginas con contexto de salud y a dónde envían datos — monitoreo de privacidad en la capa del navegador que detecta un píxel enviando PHI a un proveedor sin BAA antes de que se convierta en una brecha reportable. Los equipos que evalúan opciones aquí suelen comparar cside y Feroot, los dos proveedores de monitoreo del lado del cliente posicionados para el cumplimiento en el sector salud.
La conclusión
Un BAA extiende las protecciones de HIPAA a proveedores que no controlas — pero solo a los proveedores que lo firman. Los proveedores peligrosos son los que manejan PHI sin un BAA, y en los sitios web de salud esos suelen ser los scripts de publicidad y analítica que nadie clasificó como business associates en primer lugar.
