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:

Cifrado en reposo — PHI cifrado en reposo con AES-256 gestionado por Google (predeterminado de Cloud SQL)
Controles de acceso — Acceso a PHI restringido a roles designados
Registro de auditoría — Todo acceso a PHI registrado con códigos de razón
Retención de datos — Eliminación automática tras el período de retención configurado
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. 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:

Firmar un Business Associate Agreement (BAA) con Devotel
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)

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. 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 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 es el catálogo upstream de esos registros y de las attestaciones que los vinculan:

{
  "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:

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.

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.

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.

Verificar el estado actual — GET /api/v1/compliance/baa/ devuelve baa_status, los detalles del firmante, y days_until_expiry (owner/admin).
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.

POST /api/v1/compliance/baa/require
{
  "reason": "We began storing patient appointment reminders that contain PHI."
}

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.

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.
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) y la audiencia de una campaña resuelve a un id de lista o segmento designado, el preverificación de lanzamiento de campaña 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:

GET /api/v1/compliance/hipaa/phi-audiences

{
  "audience_ids": ["list_9f2c1a", "seg_4b7e20"],
  "max": 500
}

Reemplazar el registro:

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:

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.
Puerta de envío (por destinatario, comportamiento existente). La puerta de envío por destinatario documentada en BAA — la puerta de envío HIPAA 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:

{
  "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:

Componer el registro — PUT /api/v1/compliance/hipaa/phi-audiences con los ids de lista/segmento que contienen PHI.
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.
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.
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:

POST /api/v1/settings/hipaa/reauth-challenge

La respuesta devuelve un token de corta duración (5 minutos), de un solo uso:

{
  "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:

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:

{
  "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:

Interruptor de Modo HIPAA — Habilitar/deshabilitar modo HIPAA (requiere BAA)
Sección BAA — Ejecutar el BAA (firma electrónica de escribir-el-nombre) y rastrear su estado, firmante, y expiración del término
Retención de Datos — Configurar el período de eliminación automática de datos
Registro de Acceso PHI — Ver y exportar el rastro de auditoría de acceso PHI
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:

El equipo de seguridad de Devotel es notificado dentro de 1 hora vía alertas automatizadas
Las organizaciones afectadas son notificadas dentro de 24 horas según la Regla de Notificación de Brechas de HIPAA
Los registros de acceso PHI son inmediatamente preservados y exportados para análisis forense
Los pasos de remediación son documentados y compartidos con las partes afectadas

Páginas relacionadas

Escáner DLP — el control en tiempo de envío que señala datos regulados cruzando un mensaje saliente
Escáner de política pre-envío — 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

Getting Started

Channels

Channels (Voice)

AI Agents

Flows

Numbers & Verify

Concepts

Features

Billing

Webhooks

Security & SSO

Compliance

Legal

Changelog

Controles de cumplimiento HIPAA para mensajería sanitaria

Cumplimiento HIPAA

Resumen

Quién puede hacer qué

Prerequisitos

Controles Técnicos

1. Cifrado en Reposo

2. Controles de Acceso

3. Registro de auditoría PHI

4. Retención de Datos

5. Ciclo de vida del estado BAA

Ejecutar el BAA

Registro de Audiencias Adyacentes a PHI

Preverificación de Lanzamiento de Campaña

6. Deshabilitar el Modo HIPAA

Referencia de API

Configuración del Dashboard

Salvaguardas de Infraestructura

Redacción de PII/PHI en Transcripciones de Voz y Video

La redacción está activada de forma predeterminada

Responsabilidad Compartida

Respuesta a Incidentes

Páginas relacionadas

​Cumplimiento HIPAA

​Resumen

​Quién puede hacer qué

​Prerequisitos

​Controles Técnicos

​1. Cifrado en Reposo

​2. Controles de Acceso

​3. Registro de auditoría PHI

​4. Retención de Datos

​5. Ciclo de vida del estado BAA

​Ejecutar el BAA

​Registro de Audiencias Adyacentes a PHI

​Preverificación de Lanzamiento de Campaña

​6. Deshabilitar el Modo HIPAA

​Referencia de API

​Configuración del Dashboard

​Salvaguardas de Infraestructura

​Redacción de PII/PHI en Transcripciones de Voz y Video

​La redacción está activada de forma predeterminada

​Responsabilidad Compartida

​Respuesta a Incidentes

​Páginas relacionadas

Cumplimiento HIPAA

Resumen

Quién puede hacer qué

Prerequisitos

Controles Técnicos

1. Cifrado en Reposo

2. Controles de Acceso

3. Registro de auditoría PHI

4. Retención de Datos

5. Ciclo de vida del estado BAA

Ejecutar el BAA

Registro de Audiencias Adyacentes a PHI

Preverificación de Lanzamiento de Campaña

6. Deshabilitar el Modo HIPAA

Referencia de API

Configuración del Dashboard

Salvaguardas de Infraestructura

Redacción de PII/PHI en Transcripciones de Voz y Video

La redacción está activada de forma predeterminada

Responsabilidad Compartida

Respuesta a Incidentes

Páginas relacionadas