Business Associate Agreement (BAA)
Las organizaciones que envían, almacenan o procesan Protected Health Information (PHI) a través de Devotel Orbit necesitan un Business Associate Agreement registrado. La plataforma hace cumplir que la ruta del BAA exista antes de que el modo HIPAA pueda habilitarse: cuando el PHI entra en el ámbito, la puerta en el momento del envío rechaza el tráfico conHIPAA_BAA_REQUIRED hasta que se registre un BAA ejecutado.
Esta guía cubre el ciclo de vida completo: los estados canónicos de baa_status, cómo encajan los seis endpoints /api/v1/compliance/baa, qué rol puede llamar a cada endpoint, qué cambia una vez que un BAA está ejecutado y cómo revertir un acuerdo ejecutado al valor predeterminado de la plataforma.
Este es un control HIPAA propiedad del inquilino: usted decide si el PHI está en el ámbito, ejecuta el acuerdo de forma deliberada y lo vuelve a ejecutar antes de que venza el plazo anual. Devotel suministra la canalización de firma electrónica — la representación de la plantilla, la captura de la firma mecanografiada, el anclaje inmutable de la auditoría y el PDF ejecutado almacenado — pero la determinación legal de que el PHI está en el ámbito es suya.
Estados de baa_status
Su organización siempre está en uno de cuatro estados, reportados por GET /api/v1/compliance/baa:
La respuesta también lleva los datos del firmante y la cuenta atrás hasta el vencimiento:
hipaa_required se activa mientras el estado sigue siendo not_required, el endpoint de lectura transiciona la organización a pending automáticamente, de modo que el paso de ejecución se abre sin una llamada aparte.
Por qué el flujo comienza con una acreditación
El flujo del BAA existe porque HIPAA se aplica al uso, no a las cuentas. La plataforma no asume que cada espacio de trabajo maneja PHI: la organización primero acredita que el PHI está en el ámbito, lo que activa la banderahipaa_required y mueve el estado a pending. Esa acreditación es lo que abre el paso de ejecución; la ejecución luego completa el acuerdo. Este orden cierra una dependencia circular: el modo HIPAA no puede habilitarse sin un BAA ejecutado, pero el panel también necesitaba una forma de iniciar el BAA antes de que existiera el modo HIPAA.
Tanto require (PHI está en el ámbito) como decline (ningún PHI en el ámbito) escriben una fila de la cadena de auditoría compliance.baa.* que nombra al actor, de modo que la acreditación en sí es un evento legal registrado, no un simple cambio de configuración descartable.
El flujo de endpoints
Todas las rutas viven bajo/api/v1/compliance/baa y requieren una sesión autenticada. Las seis operaciones siguientes son el ciclo de vida completo; la página Settings → Compliance → BAA del panel dirige exactamente estos endpoints.
1. Leer el estado actual
owner o admin puede leer. Use esto primero: le indica si la organización necesita acreditar, ejecutar, re-ejecutar o descargar.
2. Previsualizar la plantilla
Antes de firmar, revise el texto del acuerdo finalizado.GET /api/v1/compliance/baa/template devuelve la plantilla representada con el nombre legal de su organización ya rellenado. Los campos del momento de ejecución (marcas de tiempo, referencia del documento) aparecen como marcadores legibles en lugar de placeholders en bruto, y los campos del firmante son espacios en blanco que el panel rellena en vivo mientras usted escribe.
3. Acreditar que el PHI está en el ámbito
hipaa_required = true y mueve una organización not_required a pending. Abre el flujo de ejecución: no habilita el modo HIPAA. El reason opcional (hasta 500 caracteres) se registra en la fila de auditoría.
4. Ejecutar con una firma electrónica de escribir-el-nombre
La ejecución es solo para owner: una firma click-wrap vincula a la organización, por lo que no es una acción de nivel de desarrollador. El firmante vuelve a escribir su nombre legal entyped_attestation, y el servidor exige que coincida exactamente con signer_name; una discrepancia se rechaza con un 400, lo que además bloquea los envíos automáticos de formularios en blanco.
En caso de éxito, el servidor:
- Representa la plantilla con los datos del firmante, las marcas de tiempo de ejecución y una referencia de documento generada
- Almacena el documento representado como el PDF ejecutado canónico
- Estampa la organización como
executedcon el firmante, la versión de la plantilla y la marca de tiempo de ejecución, y registra el vencimiento (ejecución más el plazo estándar de un año) - Escribe una entrada
compliance.baa.executeden el registro de auditoría junto con el método de firma (type_the_name): la entrada de auditoría es la evidencia legal de la acreditación, y el PDF almacenado es el documento canónico
5. Descargar la copia ejecutada
Una vez que un BAA está registrado, cualquierowner o admin puede obtenerlo para sus registros, una auditoría de un cliente o un regulador:
404.
6. Revertir al valor predeterminado de la plataforma
Revertir elimina el acuerdo registrado y devuelve la organización anot_required. Es solo para owner y solo se puede llamar sobre un BAA ejecutado o vencido, y solo después de que el modo HIPAA haya sido deshabilitado, de modo que un espacio de trabajo HIPAA activo no pueda deshacer su propia evidencia silenciosamente.
Decline: acreditar que ningún PHI está en el ámbito
POST /api/v1/compliance/baa/decline (owner o admin, reason opcional) registra que el PHI no está en el ámbito y levanta la puerta en el momento del envío una vez que una organización se haya dado de alta. Se niega a tocar un BAA registrado: un decline no puede desmantelar un acuerdo ejecutado; para eso está revert. Como require y decline son conmutadores de acreditación simétricos, un administrador que declina puede restaurar el requisito más adelante si el PHI vuelve a entrar en el ámbito.
Roles y la cadena de auditoría
Los endpoints de lectura, previsualización, descarga y acreditación aceptanowner o admin. Los dos actos que vinculan o deshacen un acuerdo legal — execute y revert — son solo para owner.
Cada escritura agrega una entrada
compliance.baa.* al registro de auditoría de la organización — compliance.baa.hipaa_required en require, compliance.baa.declined en decline, compliance.baa.executed en execute, compliance.baa.reverted en revert — que lleva el actor, el motivo y (en la ejecución) la versión de la plantilla y el método de firma. Esa cadena de solo agregación, no el campo de estado actual, es la evidencia legal de la acreditación. Puede inspeccionarla desde el panel en Settings → Audit log.
Qué cambia una vez que un BAA está ejecutado
Ejecutar el BAA hace dos cosas:- Levanta la puerta de envío de PHI. Mientras
hipaa_requiredsea verdadero y no haya un BAA en plazo registrado, los envíos salientes que tocan PHI se rechazan con422 HIPAA_BAA_REQUIRED. Un BAA ejecutado elimina ese rechazo. (La resolución de la puerta y su comportamiento fail-closed están documentados en Send gates.) - Desbloquea el modo HIPAA. Habilitar el modo HIPAA requiere
baa_status = "executed"; intentarlo antes de la ejecución devuelve403. Una vez que el modo HIPAA está activado, los controles descritos en HIPAA compliance controls — el registro de acceso a PHI, la retención de datos y el resto — se aplican al espacio de trabajo.
Flujo del panel
El mismo ciclo de vida está disponible sin tocar la API en Settings → Compliance → BAA:- Tarjeta de estado — muestra el
baa_statusactual, la fecha de ejecución, el firmante y un banner de re-ejecución cuando el plazo está dentro de los 60 días previos al vencimiento - Previsualización de la plantilla — el acuerdo representado con el nombre de su organización ya rellenado
- Formulario de acreditación — el nombre y el correo electrónico del firmante más el campo de firma de escribir-el-nombre, mostrado a los owners cuando el estado es
pending - Descarga — un enlace a la copia ejecutada una vez ejecutada, con una URL fresca de 24 horas en cada solicitud
require e inmediatamente abre el panel de ejecución, reflejando el flujo de la API anterior.
Preguntas frecuentes
¿Cuánto dura un BAA ejecutado? Un año desde la ejecución. La respuesta de estado llevaexpires_at y days_until_expiry; dentro de los 60 días previos al vencimiento, el panel muestra un banner de re-ejecución. Pasado el vencimiento, el estado pasa a expired y la puerta de envío de PHI se cierra de nuevo hasta que usted re-ejecute con el mismo flujo.
¿Puede un admin ejecutar el BAA para desbloquear los envíos?
No: la ejecución (y la reversión) es solo para owner porque vincula a la organización. Un admin sí puede marcar el PHI como requerido o declinado, leer el estado, previsualizar la plantilla y descargar la copia ejecutada.
¿Cuál es la diferencia entre decline y revert?
decline registra que ningún PHI está en el ámbito y levanta la puerta de envío; se niega a tocar un BAA ejecutado. revert elimina por completo un acuerdo ejecutado o vencido, devolviendo la organización a not_required mientras conserva su historial de auditoría y el PDF almacenado. Ambos dejan entradas en la cadena de auditoría.
¿Aceptan los endpoints un espejo de estado JSONB heredado?
El flujo de /api/v1/compliance/baa es la ruta canónica. El espejo anterior PUT /api/v1/settings/hipaa/baa (documentado en HIPAA compliance controls) es un respaldo solo para inquilinos pre-migración; una vez que una organización tiene un valor de baa_status, las puertas leen la columna canónica e ignoran el espejo.
Última actualización: septiembre de 2026 Para preguntas sobre el BAA, contacte: compliance@devotel.io