> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Controles de cumplimiento HIPAA para mensajería sanitaria > Postura HIPAA propiedad del tenant: un interruptor opt-in del propietario del workspace, los sobres de lado del escritorio que requieren BAA que documenta como controles del tenant, la matriz de roles frente a superficies, y la fila de auditoría PHI que se agrega al catálogo de registros de procesamiento del DPA. # Cumplimiento HIPAA La postura de cumplimiento es suya para configurar — Devotel Orbit tiene valores predeterminados abiertos. El modo HIPAA es un **interruptor opt-in, por organización** para organizaciones que manejan Información de Salud Protegida (PHI): un propietario del workspace lo activa, y permanece desactivado a menos que usted lo solicite. Devotel nunca exige el modo HIPAA ni decide que su tráfico es "compliant" — activar el interruptor activa las salvaguardas con puerta BAA de Orbit, y las puertas que abre son controles del tenant que usted opera. Este documento describe los controles técnicos y administrativos que se aplican cuando el modo HIPAA está habilitado. *** ## Resumen El modo HIPAA es un **interruptor opt-in, por organización** — no una postura impuesta por la plataforma. Solo un `owner` del workspace puede cambiarlo, el interruptor está desactivado hasta que usted actúe, y tiene puerta BAA: activa (o relaja) un conjunto de controles mejorados, y ningún envío o acceso lleva reglas específicas de PHI a menos que usted haya optado por ello: 1. **Cifrado en reposo** — PHI cifrado en reposo con AES-256 gestionado por Google (predeterminado de Cloud SQL) 2. **Controles de acceso** — Acceso a PHI restringido a roles designados 3. **Registro de auditoría** — Todo acceso a PHI registrado con códigos de razón 4. **Retención de datos** — Eliminación automática tras el período de retención configurado 5. **Seguimiento de BAA** — Gestión del estado del Business Associate Agreement Los sobres `HIPAA_BAA_REQUIRED` y `HIPAA_BAA_INVALID` que puede recibir en el lado del escritorio son controles del tenant a nivel de documento en los que usted opta y que posee — el mismo veredicto y comportamiento fail-closed descrito en [BAA — la puerta de envío HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate). No son mandatos de plataforma. ## Quién puede hacer qué Los controles HIPAA están asignados a roles, para que pueda mapear cada superficie a las personas en su workspace. (Estas columnas coinciden con la prosa en las secciones siguientes.) | Rol | Lectura de contenido de mensajes | Lectura de registro de acceso PHI | Escritura BAA | Habilitar/deshabilitar modo HIPAA | | ----------- | -------------------------------- | --------------------------------- | ------------- | ------------------------------------------- | | `owner` | Sí | Sí | Sí | Sí (deshabilitar requiere re-autenticación) | | `admin` | Sí | Sí | No | No | | `developer` | Sí | No | No | No | | `viewer` | Sí | No | No | No | | `billing` | No | No | No | No | ## Prerequisitos Antes de habilitar el modo HIPAA, las organizaciones deben: 1. **Firmar un Business Associate Agreement (BAA)** con Devotel 2. Designar un **oficial de cumplimiento HIPAA** dentro de su equipo *** ## Controles Técnicos ### 1. Cifrado en Reposo Todo PHI — incluyendo el `body` del mensaje, `media_url`, y metadatos — está cifrado en reposo usando claves **AES-256 gestionadas por Google** (cifrado predeterminado de Cloud SQL): * **Algoritmo**: AES-256 (cifrado en reposo predeterminado de Google Cloud) * **Gestión de claves**: Las claves de cifrado son gestionadas y rotadas por Google Cloud * **Alcance**: Todo contenido almacenado en base de datos, incluyendo `body` del mensaje, `media_url`, y metadatos * **En tránsito**: TLS 1.3 protege todos los datos en tránsito (ver [Salvaguardas de Infraestructura](#infrastructure-safeguards)) > **Nota**: Devotel actualmente no realiza cifrado a nivel de aplicación por organización de los cuerpos de mensajes. La confidencialidad de PHI en reposo depende del cifrado transparente AES-256 de Google Cloud en lugar de un cifrado a nivel de aplicación. La respuesta `GET /settings/hipaa` incluye un campo `encryption_algorithm` solo para fines de reporte — **no** indica que los cuerpos de mensajes están cifrados individualmente a nivel de aplicación. ### 2. Controles de Acceso Las lecturas de contenido de mensajes están gobernadas por la membresía del workspace y, para claves API, por el alcance `messages:read` / `messages:write`. Cada lectura se registra en el [registro de auditoría PHI](#3-phi-audit-log). La tabla siguiente refleja quién puede leer contenido de mensajes hoy: | Rol | Lectura de contenido de mensajes | Notas | | ----------- | -------------------------------- | --------------------------------------------------------------------------------------- | | `owner` | Sí | Puede habilitar/deshabilitar el modo HIPAA y ver registros de acceso PHI | | `admin` | Sí | Puede ver registros de acceso PHI | | `developer` | Sí | Cada lectura se registra en el registro de acceso PHI | | `viewer` | Sí | Cada lectura se registra en el registro de acceso PHI | | `billing` | No | Confinado a superficies financieras; recibe `403` en endpoints de contenido de mensajes | El rol `billing` está limitado a superficies financieras — facturación, precios, y análisis de uso — y no puede leer contenido de mensajes. Cada otro rol, incluyendo `viewer`, puede leer contenido de mensajes, y cada acceso se escribe en el registro de acceso PHI. Los códigos de razón se almacenan en cada entrada del registro de acceso PHI. Las lecturas a través de `GET /messages` y `GET /messages/{id}` se registran con una razón automática `read`. Las categorías siguientes describen las razones de acceso usadas en otras partes de la plataforma cuando un operador suministra una explícitamente: * `treatment` — Acceso requerido para coordinación de tratamiento de pacientes * `payment` — Acceso requerido para procesamiento de pagos * `operations` — Acceso requerido para operaciones sanitarias * `legal` — Acceso requerido para cumplimiento legal * `support` — Acceso requerido para resolución de soporte al cliente > **Limitación conocida:** Orbit actualmente no restringe las lecturas de contenido de mensajes a un conjunto más estrecho de roles más allá del confinamiento `billing` anterior, y no requiere un código de razón suministrado por el operador en los endpoints de lectura de mensajes (`GET /messages`, `GET /messages/{id}`). Para cumplir el estándar HIPAA de *mínimo necesario*, provisione la membresía del workspace y los alcances de claves API para que solo el personal que necesita PHI pueda alcanzar estos endpoints. Si su programa requiere restricción de lectura por rol en contenido de mensajes, contacte [compliance@devotel.io](mailto:compliance@devotel.io) antes de confiar en ello. ### 3. Registro de auditoría PHI Cada acceso a datos que contienen PHI genera una entrada de registro de auditoría. Este registro es una fila en el catálogo de registros de procesamiento que su organización mantiene — la página [Data Processing Agreement](/compliance/data-processing-agreement) es el catálogo upstream de esos registros y de las attestaciones que los vinculan: ```json theme={null} { "id": "phi_abc123", "userId": "usr_xyz789", "resource": "message:msg_def456", "reason": "treatment", "accessedAt": "2026-04-02T10:30:00Z" } ``` El registro de acceso PHI: * Es **append-only** y no puede ser modificado o eliminado * Retiene hasta **10,000 entradas** por organización (las entradas más antiguas se rotan automáticamente) * Es accesible para los roles `owner` y `admin` vía el dashboard o API * Puede ser exportado para auditorías de cumplimiento externas **Endpoint de API**: `GET /api/v1/settings/hipaa/phi-access-log` ### 4. Retención de Datos Cuando el modo HIPAA está activo, la retención de datos se aplica: * **Período de retención predeterminado**: 365 días (configurable: 30–3,650 días) * **Alcance**: Contenido de mensajes, grabaciones de llamadas, archivos adjuntos de medios * **Mecanismo**: Un trabajo en segundo plano automatizado busca registros expirados y los elimina de forma segura * **Excepciones**: Los registros de auditoría y los registros de acceso PHI se retienen independientemente de la política de retención de datos **Configuración**: Vía dashboard en **Settings → Compliance → HIPAA → Data Retention** o vía API: ```bash theme={null} PUT /api/v1/settings/hipaa { "enabled": true, "data_retention_days": 365 } ``` **Habilitar** el modo HIPAA es una sola llamada — endurece la postura de seguridad del workspace, por lo que no se requiere desafío de re-autenticación (un BAA firmado sigue siendo obligatorio; ver abajo). **Deshabilitar** el modo HIPAA es destructivo y requiere el flujo de re-autenticación de dos pasos descrito en [Deshabilitar el Modo HIPAA](#6-disabling-hipaa-mode). ### 5. Ciclo de vida del estado BAA Devotel rastrea el estado BAA por organización en un ciclo de vida canónico `baa_status`: * **`not_required`** — la organización ha attestado que no hay PHI en el alcance (el predeterminado) * **`pending`** — PHI está en el alcance y el BAA está esperando ejecución * **`executed`** — el BAA ha sido firmado y está dentro de su término * **`expired`** — un BAA ejecutado ha pasado su término de un año y debe ser re-ejecutado Cada BAA ejecutado registra su versión de plantilla, nombre y correo del firmante, marca de tiempo de ejecución, y expiración del término. **Requisito**: El modo HIPAA **no puede ser habilitado** hasta que `baa_status` sea `executed`. Intentar habilitar el modo HIPAA antes de entonces devuelve un error `403 Forbidden`, y cualquier envío de PHI es rechazado con `422 HIPAA_BAA_REQUIRED`. El veredicto de la puerta en tiempo de envío y su comportamiento fail-closed están documentados en [BAA — la puerta de envío HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate). #### Ejecutar el BAA Ejecute el BAA a través de los endpoints `/api/v1/compliance/baa`. Este es el flujo que usa el panel **Compliance → BAA** del dashboard, y el único flujo que satisface las puertas de habilitación HIPAA y envío de PHI. 1. **Verificar el estado actual** — `GET /api/v1/compliance/baa/` devuelve `baa_status`, los detalles del firmante, y `days_until_expiry` (owner/admin). 2. **Attestar que PHI está en el alcance** — `POST /api/v1/compliance/baa/require` establece `hipaa_required` y mueve una organización `not_required` a `pending` para que el paso de ejecución se abra (solo owner). Esto inicia el flujo; no habilita el modo HIPAA. ```bash theme={null} POST /api/v1/compliance/baa/require { "reason": "We began storing patient appointment reminders that contain PHI." } ``` 3. **Ejecutar el BAA** — `POST /api/v1/compliance/baa/execute` registra el acuerdo con una firma electrónica click-wrap de escribir-el-nombre (solo owner). La `typed_attestation` debe coincidir exactamente con `signer_name`. En caso de éxito la organización es estampada `executed` con el firmante, versión, y fecha, lo que desbloquea los envíos de PHI y le permite habilitar el modo HIPAA. ```bash theme={null} POST /api/v1/compliance/baa/execute { "signer_name": "Jane Roe", "signer_email": "jane@example.com", "typed_attestation": "Jane Roe" } ``` Para revisar el acuerdo antes de firmar, llame `GET /api/v1/compliance/baa/template`. > **Endpoint heredado:** `PUT /api/v1/settings/hipaa/baa` (cuerpo `{ signed, signed_at, document_url }`) escribe un espejo de estado JSONB más antiguo y es un **fallback solo para tenants pre-migración**. Una vez que una organización tiene un valor `baa_status`, las puertas de habilitación HIPAA y envío de PHI leen esa columna canónica e ignoran este espejo — por lo que una escritura `signed: true` aquí **no** desbloquea envíos ni el modo HIPAA. Use `POST /api/v1/compliance/baa/execute` en su lugar. > > ```bash theme={null} > PUT /api/v1/settings/hipaa/baa > { > "signed": true, > "signed_at": "2026-04-01T00:00:00Z", > "document_url": "https://storage.devotel.io/baa/org_abc123.pdf" > } > ``` *** ## Registro de Audiencias Adyacentes a PHI El registro de audiencias adyacentes a PHI es un **registro a nivel de organización de ids de listas de contactos y segmentos cuyos miembros portan PHI** — por ejemplo, pacientes que optaron por outreach de tratamiento. La designación pertenece a la audiencia misma, no a ninguna campaña individual: una audiencia es adyacente a PHI por sus datos de origen, por lo que la designación la sigue independientemente de qué campaña la recoja. Cuando HIPAA está en el alcance para su organización (`hipaa_required` establecido vía el [flujo BAA](#5-baa-status-lifecycle)) y la audiencia de una campaña resuelve a un id de lista o segmento designado, el [preverificación de lanzamiento de campaña](#campaign-launch-precheck) rechaza el lanzamiento hasta que su BAA esté `executed` y dentro del término. **API**: `GET /api/v1/compliance/hipaa/phi-audiences` devuelve el registro actual con alcance a su organización. `PUT /api/v1/compliance/hipaa/phi-audiences` reemplaza el registro en una sola escritura. Ambos endpoints requieren el rol `owner` o `admin` — la misma puerta usada para los endpoints BAA. **Leer el registro:** ```bash theme={null} GET /api/v1/compliance/hipaa/phi-audiences ``` ```json theme={null} { "audience_ids": ["list_9f2c1a", "seg_4b7e20"], "max": 500 } ``` **Reemplazar el registro:** ```bash theme={null} PUT /api/v1/compliance/hipaa/phi-audiences { "audience_ids": ["list_9f2c1a", "seg_4b7e20"] } ``` El PUT es un **reemplazo completo** de los ids designados — no hay endpoint DELETE. Para levantar una designación, haga PUT del registro sin ese id; para re-designar, haga PUT con el id añadido de nuevo. Cada elemento es una cadena de id de audiencia (1–128 caracteres), hasta **500** ids por organización. Un `PUT` con un array `audience_ids` vacío limpia el registro. Cada reemplazo se escribe atómicamente (un GET concurrente nunca ve una actualización parcial) y se registra en el registro de auditoría. > **Nota:** El registro es la attestación de su organización de qué audiencias contienen PHI. Es propiedad del tenant: Devotel nunca designa audiencias en su nombre, y la designación solo toma efecto una vez que HIPAA está en el alcance para su organización. *** ## Preverificación de Lanzamiento de Campaña Las campañas tienen **dos** puertas HIPAA en diferentes puntos del flujo: 1. **Preverificación de lanzamiento (a nivel de campaña, puerta dura).** Antes de que una campaña salga del estado borrador/programado, la preverificación de lanzamiento resuelve su audiencia contra el registro. Si la audiencia es una lista o segmento designado **y** el BAA de su organización no está `executed` y dentro del término, el lanzamiento es rechazado con `422 HIPAA_BAA_REQUIRED`. Esto mantiene una cohorte PHI fuera de la inscripción de campaña en lugar de quemar crédito de wallet en miles de rechazos por destinatario. Si el estado de cumplimiento no puede ser leído, la preverificación falla cerrada (`500 HIPAA_BAA_GATE_DB_FAIL`) en lugar de admitir silenciosamente una audiencia PHI. 2. **Puerta de envío (por destinatario, comportamiento existente).** La puerta de envío por destinatario documentada en [BAA — la puerta de envío HIPAA](/compliance/send-gates#baa-the-hipaa-send-gate) sigue aplicando en el momento del mensaje y no ha cambiado. La preverificación evalúa las **mismas** reglas BAA que la puerta por destinatario, por lo que las dos nunca discrepan sobre lo que significa "BAA dentro del término". **Superficie del dashboard:** en el paso de audiencia del asistente de campaña, elegir una lista o segmento designado muestra una advertencia consultiva — *"This audience is designated as PHI-adjacent. Launch requires an executed Business Associate Agreement (BAA) — check its status under Settings → Compliance → BAA."* La advertencia es consultiva: no bloquea el botón **Next**, porque la designación puede ser levantada (o el BAA ejecutado) antes de que usted realmente lance. La puerta dura está en el lanzamiento. **La respuesta de rechazo:** ```json theme={null} { "error": { "code": "HIPAA_BAA_REQUIRED", "status": 422, "message": "The designated PHI-adjacent audience for this campaign requires an executed Business Associate Agreement (BAA) before outbound sends are permitted." } } ``` **Secuencia del operador — un lanzamiento rechazado por la preverificación:** 1. **Componer el registro** — `PUT /api/v1/compliance/hipaa/phi-audiences` con los ids de lista/segmento que contienen PHI. 2. **Verificar el bloqueo** — intente el lanzamiento contra una audiencia designada; espere `422 HIPAA_BAA_REQUIRED` mientras el BAA no esté `executed`/dentro del término. 3. **Resolver el BAA** — ejecute (o re-ejecute un `expired`) BAA vía `POST /api/v1/compliance/baa/execute` como se describe en [Ejecutar el BAA](#executing-the-baa). 4. **Relanzar** — una vez que el BAA está `executed` y dentro del término, la preverificación pasa y la campaña se lanza normalmente. **Límites:** * El registro gobierna **solo lanzamientos de campaña**. Los envíos heredados únicos por destinatario siguen gobernados por la puerta de envío por destinatario, que no consulta el registro. * Solo audiencias de tipo `list` y `segment` resuelven contra el registro en el lanzamiento. Las audiencias ensambladas por contacto (todos los contactos, CSV, entrada manual) se evalúan destinatario-por-destinatario en el momento de envío en su lugar. * La advertencia de PHI-adjacent del asistente es consultiva en el selector de audiencia; la aplicación vive en el lanzamiento. *** ### 6. Deshabilitar el Modo HIPAA Deshabilitar el modo HIPAA es una transición **destructiva, sensible a auditoría**: limpia la bandera de entidad cubierta, el enlace BAA, y el piso de retención estricto en un workspace que puede contener PHI. Para prevenir que esto ocurra en una sesión de navegador robada, deshabilitar requiere un **desafío de re-autenticación fresco**. (Habilitar el modo HIPAA *no* — solo endurece la postura.) Deshabilitar es por lo tanto un flujo de **dos pasos**: **Paso 1 — Emitir un token de desafío de re-autenticación de un solo uso:** ```bash theme={null} POST /api/v1/settings/hipaa/reauth-challenge ``` La respuesta devuelve un token de corta duración (5 minutos), de un solo uso: ```json theme={null} { "challenge_token": "h7Yc...base64url...", "expires_at": "2026-04-02T10:35:00Z" } ``` **Paso 2 — Enviar la solicitud de deshabilitación con el encabezado `X-Reauth-Challenge` establecido a ese token:** ```bash theme={null} PUT /api/v1/settings/hipaa X-Reauth-Challenge: h7Yc...base64url... { "enabled": false } ``` El token debe ser canjeado **dentro de 5 minutos** y puede ser consumido solo **una vez**. Si el encabezado `X-Reauth-Challenge` falta, está mal formado, o ha expirado, la solicitud de deshabilitación es rechazada con `401 REAUTH_REQUIRED`: ```json theme={null} { "error": { "code": "REAUTH_REQUIRED", "message": "Fresh re-authentication is required to disable HIPAA mode. POST /settings/hipaa/reauth-challenge first, then retry within 5 minutes with X-Reauth-Challenge header." } } ``` > **Nota:** El desafío de re-autenticación solo gobierna la transición **habilitar → deshabilitar**. Habilitar el modo HIPAA, y actualizaciones de solo-retención enviadas mientras el modo HIPAA ya está deshabilitado, **no** requieren el encabezado. *** ## Referencia de API | Método | Endpoint | Descripción | Rol Requerido | | ------ | ---------------------------------- | ----------------------------------------------------------------------------------------------------- | --------------- | | `GET` | `/settings/hipaa` | Obtener estado y configuración HIPAA | `admin+` | | `PUT` | `/settings/hipaa` | Habilitar/deshabilitar modo HIPAA (deshabilitar requiere `X-Reauth-Challenge`) | `owner` | | `POST` | `/settings/hipaa/reauth-challenge` | Emitir un token de re-autenticación de un solo uso requerido para **deshabilitar** el modo HIPAA | `owner` | | `GET` | `/settings/hipaa/phi-access-log` | Registro de acceso PHI paginado | `admin+` | | `GET` | `/compliance/baa/` | Obtener estado BAA actual (`baa_status`, firmante, expiración) | `admin+` | | `GET` | `/compliance/baa/template` | Previsualizar el acuerdo BAA antes de firmar | `admin+` | | `POST` | `/compliance/baa/require` | Attestar que PHI está en el alcance y abrir el flujo de ejecución | `owner` | | `POST` | `/compliance/baa/execute` | Ejecutar el BAA vía firma electrónica de escribir-el-nombre | `owner` | | `GET` | `/compliance/hipaa/phi-audiences` | Leer el registro de audiencias adyacentes a PHI | `admin+` | | `PUT` | `/compliance/hipaa/phi-audiences` | Reemplazar el registro de audiencias adyacentes a PHI (escritura de reemplazo completo) | `owner`/`admin` | | `PUT` | `/settings/hipaa/baa` | **Heredado** — espejo de estado BAA pre-migración; ignorado una vez que `baa_status` está establecido | `owner` | *** ## Configuración del Dashboard La configuración HIPAA está disponible en el dashboard bajo **Settings → Compliance**: 1. **Interruptor de Modo HIPAA** — Habilitar/deshabilitar modo HIPAA (requiere BAA) 2. **Sección BAA** — Ejecutar el BAA (firma electrónica de escribir-el-nombre) y rastrear su estado, firmante, y expiración del término 3. **Retención de Datos** — Configurar el período de eliminación automática de datos 4. **Registro de Acceso PHI** — Ver y exportar el rastro de auditoría de acceso PHI 5. **Audiencias Adyacentes a PHI** — Designar qué listas de contactos y segmentos portan PHI; el asistente de campaña advierte sobre audiencias designadas y la preverificación de lanzamiento aplica la puerta BAA *** ## Salvaguardas de Infraestructura Más allá de los controles a nivel de aplicación, la infraestructura de Devotel proporciona: * **Cifrado de Cloud SQL**: Todo el almacenamiento de base de datos cifrado con AES-256 por Google Cloud * **TLS 1.3**: Todos los datos en tránsito cifrados con TLS 1.3 * **Aislamiento de VPC**: Base de datos accesible solo vía IP privada dentro de la VPC * **Sin Contenedores Privilegiados**: GKE Autopilot previene la ejecución de contenedores privilegiados * **Secret Manager**: Todas las claves de cifrado y credenciales almacenadas en GCP Secret Manager * **Rastros de Auditoría**: Google Cloud Audit Logs para el seguimiento de acceso a nivel de infraestructura *** ## Redacción de PII/PHI en Transcripciones de Voz y Video Los subtítulos en vivo, transcripciones de llamadas, y transcripciones post-llamada son generados por el subprocesador de voz-a-texto de Devotel con redacción de PII/PHI habilitada de forma predeterminada. Los numéricos sensibles — números de tarjetas de crédito, números de seguridad social, y similares — son enmascarados en la fuente, antes de que cualquier texto de transcripción sea almacenado o escrito en logs. Para organizaciones HIPAA, esto significa que PHI hablado en una llamada es redactado antes de ser persistido. ### La redacción está activada de forma predeterminada La redacción de transcripciones está habilitada de forma predeterminada y no puede ser desactivada desde su dashboard o API. Desactivarla es un cambio a nivel de despliegue que Devotel hace solo para verticales de cumplimiento de archivo (por ejemplo, legales o sanitarias) que están contractualmente requeridas a retener transcripciones *crudas*, sin redactar, bajo sus propias salvaguardas y BAA. > **Advertencia:** Debido a que este control se aplica a un despliegue completo en lugar de a una sola organización, no puede ser limitado a un workspace. Si su despliegue maneja PHI, la redacción debería permanecer habilitada — confirme su estado por escrito con su contacto de Devotel como parte de su BAA antes de almacenar cualquier PHI. Si la retención de transcripciones crudas fue habilitada alguna vez para su despliegue, las transcripciones capturadas durante esa ventana fueron almacenadas sin redactar y **no** son enmascaradas retroactivamente. Revíselas y púrgelas según su política de retención si contienen PHI, y pida a Devotel que confirme que la redacción está re-habilitada para todas las transcripciones en adelante. *** ## Responsabilidad Compartida El cumplimiento HIPAA es una responsabilidad compartida entre Devotel y el cliente: | Responsabilidad | Devotel | Cliente | | ------------------------------------------------------------------------------------ | ------- | ------- | | Seguridad de infraestructura | ✅ | | | Cifrado de datos en reposo | ✅ | | | Cifrado de datos en tránsito | ✅ | | | Aplicación de control de acceso | ✅ | | | Registro de acceso PHI | ✅ | | | Redacción de PII/PHI en transcripciones (activada por defecto) | ✅ | | | Confirmar que la redacción de transcripciones está habilitada antes de almacenar PHI | | ✅ | | Ejecución de BAA | ✅ | ✅ | | Capacitación de personal | | ✅ | | Procedimientos de notificación de brechas | ✅ | ✅ | | Estándar de mínimo necesario de PHI | | ✅ | | Gestión de consentimiento del paciente | | ✅ | | Evaluación de riesgos | ✅ | ✅ | *** ## Respuesta a Incidentes En el evento de una sospecha de brecha de PHI: 1. El equipo de seguridad de Devotel es notificado dentro de **1 hora** vía alertas automatizadas 2. Las organizaciones afectadas son notificadas dentro de **24 horas** según la Regla de Notificación de Brechas de HIPAA 3. Los registros de acceso PHI son inmediatamente preservados y exportados para análisis forense 4. Los pasos de remediación son documentados y compartidos con las partes afectadas *** ## Páginas relacionadas * [Escáner DLP](/compliance/dlp-scanner) — el control en tiempo de envío que señala datos regulados cruzando un mensaje saliente * [Escáner de política pre-envío](/compliance/policy-scanner) — el veredicto y modo de aplicación al que este control alimenta *** *Última actualización: abril de 2026* *Para preguntas sobre cumplimiento HIPAA, contacte: [compliance@devotel.io](mailto:compliance@devotel.io)*