Lista de verificación para el desarrollo de software HIPAA: Privacy Rule, Security Rule y BAA

YuSMP Group Editorial Team Equipo editorial, YuSMP Group

TL;DR — HIPAA para software en un párrafo

¿Me afecta HIPAA? Entidad cubierta, socio comercial y la ampliación de HITECH

HIPAA (Public Law 104-191, 1996) y sus reglamentos en 45 CFR Parts 160 y 164 se aplican directamente a las entidades cubiertas (CE): planes de salud, cámaras de compensación sanitarias y prestadores de servicios sanitarios que transmiten cualquier información de salud en formato electrónico en relación con una transacción para la que el HHS ha adoptado un estándar (definición en 45 CFR 160.103).

La HITECH Act de 2009 y la Omnibus Rule de 2013 extendieron directamente la mayor parte de la Privacy Rule y la totalidad de la Security Rule a los socios comerciales (BA) — cualquier persona o entidad que crea, recibe, mantiene o transmite información médica protegida en nombre de una CE. Entre los BA figuran proveedores cloud, proveedores de SaaS, empresas de facturación, servicios de transcripción, empresas de análisis de datos y ahora — según la guía infrarreglamentaria del HHS — los proveedores de inferencia de IA cuando la PHI pasa por ellos.

Si lanza software que accede a información médica protegida, es casi seguro que usted es un socio comercial — el punto en el que comienzan nuestros proyectos de desarrollo de software conforme a HIPAA, que mapean cada flujo de PHI antes de escribir una sola línea de código de corrección. La prueba del HHS es funcional: ¿tiene acceso a PHI al prestar servicios a una CE? Si la respuesta es sí, se aplican la condición de BA y el requisito del BAA, con independencia de cómo esté redactado el contrato.

Tenga en cuenta la excepción de la condición de «conduit» (guía del HHS, 2013): los servicios de mera transmisión (proveedores de internet, servicios postales) que solo acceden a la PHI de forma transitoria no son BA. Según esa misma guía, los proveedores cloud no pueden acogerse a la excepción de «conduit», porque almacenan la PHI aunque sea de forma momentánea.

Qué se considera PHI: los 18 identificadores de HIPAA

La información médica protegida es cualquier información de salud identificable individualmente, en poder de una entidad cubierta o de un socio comercial o transmitida por ellos, que se refiera al estado de salud física o mental pasado, presente o futuro de una persona, a la prestación de asistencia sanitaria o al pago de dicha asistencia. El HHS especifica 18 categorías que deben eliminarse para que los datos se consideren desidentificados según el método Safe Harbor (164.514(b)(2)):

1. Nombres
2. Datos geográficos de nivel inferior al estado — dirección postal, ciudad, condado, distrito, código ZIP (los 3 primeros dígitos están restringidos para poblaciones de <20,000 habitantes)
3. Fechas (salvo el año) directamente relacionadas con una persona — nacimiento, ingreso, alta, fallecimiento
4. Números de teléfono
5. Números de fax
6. Direcciones de correo electrónico
7. Números de la Seguridad Social (Social Security)
8. Números de historia clínica
9. Números de beneficiario de planes de salud
10. Números de cuenta
11. Números de certificados o licencias
12. Identificadores y números de serie de vehículos, incluidas las matrículas
13. Identificadores y números de serie de dispositivos
14. URL web
15. Direcciones IP
16. Identificadores biométricos — huellas dactilares, huellas de voz, escáneres de retina e iris
17. Fotografías de rostro completo e imágenes comparables
18. Cualquier otro número, característica o código de identificación único

En la práctica, las combinaciones importan tanto como los campos individuales. Un código de diagnóstico junto con el código postal y la edad puede reidentificar a una persona incluso sin su nombre. Diseñe sus modelos de datos teniéndolo en cuenta desde el primer día: cifrado a nivel de campo, RBAC granular por categoría de identificador y controles de exportación que eliminen las 18 categorías antes de que los datos salgan del perímetro de la ePHI. Trate las direcciones IP como PHI en cualquier log que también contenga una afección de salud — un punto ciego habitual en los pipelines de analítica.

Niveles de sanción en 2026 y el enfoque de aplicación del HHS

Las sanciones pecuniarias civiles en virtud de 45 CFR 160.404, ajustadas a la inflación en la actualización del Federal Register de 2024, siguen una escala escalonada de culpabilidad. Las cifras de 2026, según el ajuste más reciente del HHS:

Las sanciones penales en virtud de 42 USC 1320d-6 añaden penas de prisión de 1–10 años por infracciones cometidas a sabiendas y por delitos cometidos con la intención de vender PHI para obtener un beneficio personal. Los fiscales generales de los estados también tienen potestad sancionadora conferida por la HITECH. En 2024–2025, los acuerdos de resolución (Resolution Agreement) de la OCR se situaron sistemáticamente en el rango de USD 1–5M, y los acuerdos de Anthem y Premera siguen marcando el límite superior.

En diciembre de 2024, el HHS publicó un aviso de propuesta normativa (Notice of Proposed Rulemaking, NPRM) para reforzar la Security Rule, que incluye convertir la mayoría de las especificaciones «abordables» (addressable) en «obligatorias» (required) y exigir la autenticación multifactor, el cifrado de la ePHI en reposo y en tránsito por defecto, inventarios de activos y auditorías anuales de cumplimiento. Tratamos el NPRM como el estándar operativo de cualquier desarrollo HIPAA que comience en 2026 — se espera ampliamente que se apruebe definitivamente en 2026–2027.

Cambios de la HIPAA Security Rule en 2026 — qué deben implementar ya los desarrolladores

El NPRM de 2024 es la revisión más importante de la Security Rule desde la Omnibus Rule de 2013. Al margen de su aprobación definitiva, el enfoque de aplicación de la OCR ya refleja las nuevas expectativas. A continuación, una comparación directa entre la norma anterior y el estándar operativo de 2026 para los equipos de ingeniería:

La implicación práctica para los equipos de ingeniería: trate cada especificación «abordable» de la 164.312 como un requisito estricto. Documente cada decisión de implementación con una justificación basada en el riesgo y firmada por un responsable identificado. Los auditores de la OCR pedirán específicamente la justificación de cualquier especificación «abordable» que se aparte de la implementación de referencia — y en los acuerdos de resolución de 2024–2026, la ausencia de esa documentación se ha citado sistemáticamente como factor agravante en el cálculo de la sanción.

Lo esencial de la Privacy Rule (45 CFR 164.500–534)

La Privacy Rule regula los usos y las divulgaciones de PHI en cualquier formato (papel, oral, electrónico). Para quienes desarrollan software, las disposiciones relevantes son:

• 164.502 — Usos y divulgaciones en general. La PHI solo puede usarse o divulgarse en la medida en que la Privacy Rule lo permita o lo exija, o según lo autorice la persona interesada.
• 164.502(b) — Mínimo necesario. Limite la PHI al mínimo necesario para la finalidad prevista. En software: control de acceso basado en roles y visibilidad a nivel de campo, no «todo el mundo lo ve todo».
• 164.508 — Autorizaciones. El marketing, las notas de psicoterapia y la venta de PHI requieren una autorización específica por escrito. Implementación: flujos de consentimiento explícito con vías de revocación.
• 164.514 — Desidentificación. Dos vías seguras: Expert Determination (estadística) y Safe Harbor (eliminar 18 identificadores). Los datos desidentificados quedan fuera de la HIPAA. Trate el pipeline de desidentificación como crítico para la seguridad — la reidentificación es una brecha.
• 164.520 — Aviso de prácticas de privacidad (NPP). Obligatorio para las CE; los contratos con BA suelen exigir que el BA cumpla el NPP de la CE.
• 164.524 — Derecho de acceso. Las personas deben poder acceder a su PHI en un plazo de 30 días (se permite una prórroga de 30 días). El software debe permitir exportar los datos del paciente en formatos legibles por máquina (orientaciones del HHS, iniciativa de la OCR sobre el derecho de acceso de 2020).
• 164.526 — Derecho de rectificación. Los pacientes pueden solicitar rectificaciones; el sistema debe aceptar y encaminar las solicitudes de rectificación.
• 164.528 — Registro de divulgaciones. Historial de 6 años de las divulgaciones que no sean de tratamiento, pago ni operaciones — el registro de auditoría debe diseñarse para ello desde el primer día.

Salvaguardas técnicas de la Security Rule (164.302–318)

La Security Rule regula únicamente la PHI electrónica (ePHI) y es la norma con la que los equipos de software trabajan a diario. Se organiza en tres grupos de salvaguardas, cada uno con «estándares» (obligatorios) y «especificaciones de implementación» (obligatorias o abordables). «Abordable» no significa opcional — significa que debe implementarla o documentar una alternativa razonable y adecuada.

Salvaguardas administrativas — 164.308

• 164.308(a)(1) Proceso de gestión de la seguridad — análisis de riesgos, gestión de riesgos, política de sanciones y revisión de la actividad de los sistemas de información. El análisis de riesgos es la base de todo el programa de la Security Rule; las conclusiones del HHS citan sistemáticamente análisis de riesgos inexistentes u obsoletos como causa raíz en los acuerdos más importantes.
• 164.308(a)(3) Seguridad del personal — autorización/supervisión, habilitación y procedimientos de baja.
• 164.308(a)(4) Gestión del acceso a la información — autorización, establecimiento y modificación del acceso. Las revisiones trimestrales de accesos se consideran ya un requisito básico.
• 164.308(a)(5) Concienciación y formación en seguridad — formación periódica, recordatorios de seguridad, protección contra malware, supervisión de inicios de sesión y gestión de contraseñas.
• 164.308(a)(6) Procedimientos ante incidentes de seguridad — identificar, responder, documentar y mitigar.
• 164.308(a)(7) Plan de contingencia — copia de seguridad de datos, recuperación ante desastres, funcionamiento en modo de emergencia, pruebas y revisión, y criticidad de aplicaciones y datos.
• 164.308(a)(8) Evaluación — evaluación técnica y no técnica periódica respecto al estándar.
• 164.308(b) Contratos con socios comerciales — garantías satisfactorias por escrito (BAA) antes de permitir el acceso al BA.

Salvaguardas físicas — 164.310

Controles de acceso a las instalaciones (164.310(a)), uso y seguridad de las estaciones de trabajo (164.310(b)/(c)) y controles de dispositivos y soportes, incluidos eliminación, reutilización, trazabilidad y copia de seguridad (164.310(d)). En un SaaS nativo en la nube, los controles físicos se heredan en gran parte del BAA del proveedor cloud, pero las políticas de estaciones de trabajo para los portátiles de los desarrolladores que tocan ePHI en entornos no productivos siguen siendo responsabilidad suya: debe redactarlas y hacerlas cumplir.

Salvaguardas técnicas — 164.312

Esta es la sección que su equipo de ingeniería debe implementar directamente. Cinco estándares:

• 164.312(a) Control de acceso. Identificación única de usuario (obligatoria), procedimiento de acceso de emergencia (obligatorio), cierre automático de sesión (abordable — en la práctica, obligatorio), cifrado y descifrado (abordable — en la práctica, obligatorio).
• 164.312(b) Controles de auditoría. Mecanismos de hardware, software y procedimiento que registran y examinan la actividad en los sistemas de información que contienen ePHI. No se especifica un plazo de conservación, pero la 164.316(b)(2) fija 6 años para la documentación relacionada.
• 164.312(c) Integridad. Mecanismo para autenticar la ePHI — protegerla de alteraciones o destrucciones indebidas. Hashes criptográficos, firmas digitales y almacenamiento de escritura única para los registros de auditoría.
• 164.312(d) Autenticación de personas o entidades. Verificar la identidad antes de conceder el acceso. La MFA se considera ya el mínimo.
• 164.312(e) Seguridad de la transmisión. Controles de integridad y cifrado de la ePHI en tránsito. TLS 1.2+ en todas partes, sin excepciones.

Notificación de brechas: el plazo de 60 días (164.400–414)

La notificación de brechas se introdujo con la HITECH y se codificó en 45 CFR Subpart D. Una «brecha» es la adquisición, el acceso, el uso o la divulgación de PHI no protegida de una forma no permitida por la Privacy Rule y que compromete la seguridad o la privacidad (164.402). Una evaluación de riesgos de cuatro factores determina si la notificación es obligatoria; se presume que un uso o una divulgación no permitidos es una brecha, salvo que el análisis de cuatro factores demuestre una baja probabilidad de compromiso.

La vía segura (safe harbor): si la PHI estaba cifrada conforme al estándar de las orientaciones del HHS/HITECH (NIST SP 800-111 en reposo, TLS validado según NIST SP 800-52 / FIPS 140-2 en tránsito), la pérdida no es una brecha notificable. El cifrado es el control de mayor impacto de todo el stack técnico de HIPAA.

Los BAA y la cadena de subcontratistas

El requisito del BAA de 45 CFR 164.504(e) no es negociable. Elementos obligatorios:

• Usos y divulgaciones de PHI permitidos y exigidos al BA.
• El BA no usará ni divulgará la PHI salvo en la forma permitida o exigida.
• El BA implementará las salvaguardas adecuadas (Security Rule para la ePHI).
• El BA comunicará las brechas y los incidentes de seguridad.
• El BA garantizará que los subcontratistas acepten las mismas restricciones (164.308(b)(2), 164.502(e)(1)(ii)).
• El BA pondrá la PHI a disposición para el acceso, la rectificación y el registro de divulgaciones de las personas.
• El BA devolverá o destruirá la PHI al finalizar el contrato (si es viable).
• El BA pondrá sus prácticas de cumplimiento a disposición del HHS.
• Resolución por incumplimiento grave.

Elabore ya un inventario de BAA si no lo tiene. Vemos programas en los que Postgres en una instancia RDS apta para HIPAA está debidamente cubierto por el BAA, pero los logs fluyen hacia un stack de observabilidad no apto para HIPAA — una infracción inmediata. Todo servicio posterior que vea ePHI, aunque sea de forma transitoria, necesita un BAA.

Cloud, LLM, móvil e IoT — la ePHI en los stacks modernos

La realidad actual de HIPAA va más allá de lo que imaginó la ley de 1996. Implicaciones prácticas:

• Cloud. AWS, GCP y Azure publican listas de servicios aptos para HIPAA. Firme el BAA antes de enviar ePHI. Limite las cargas de trabajo con ePHI exclusivamente a los servicios aptos. Tenga cuidado con los servicios «en la sombra» que ponen en marcha los analistas.
• LLM. AWS Bedrock, Azure OpenAI Service y Vertex AI ofrecen un uso cubierto por BAA. ChatGPT y Claude.ai en sus versiones de consumo no están cubiertos por BAA — incluso pegar PHI en una consola de desarrollador es una brecha. En un RAG sobre PHI, el almacén de embeddings, la base de datos vectorial y los logs de recuperación contienen ePHI y necesitan una cobertura completa por BAA. Nuestra área de desarrollo de software conforme a HIPAA trata el stack de LLM como una superficie de ePHI de primer orden.
• Móvil. Las apps de salud para iOS y Android que manejan PHI deben usar Keychain / Keystore para las credenciales, exigir un acceso biométrico o por PIN, desactivar la copia de seguridad de la ePHI en el iCloud / Google Drive del usuario salvo que esté cubierta por un BAA (ninguno lo está) y fijar los certificados (certificate pinning).
• IoT y monitorización remota. Cifrado del transporte del dispositivo a la nube, rotación de la identidad del dispositivo, arranque seguro y registro a prueba de manipulaciones. Capa adicional de la FDA 510(k) para dispositivos de clase II/III.

Lista de verificación HIPAA para apps móviles — iOS y Android

Las aplicaciones de salud móviles presentan superficies de exposición de ePHI que el texto principal de la Security Rule no detalla por completo. Si su app gestiona PHI en el dispositivo personal de un paciente, se requieren los siguientes controles, además de las salvaguardas independientes de la plataforma descritas arriba:

• Keychain (iOS) / Keystore (Android) para almacenar todas las credenciales y los tokens. Los tokens de PHI, las claves de sesión y los secretos de API nunca deben guardarse en NSUserDefaults, SharedPreferences, una base SQLite local sin cifrar ni en el sistema de archivos sin protección. Utilice el enclave seguro que proporciona el sistema operativo; en Android 9+, use claves respaldadas por StrongBox cuando estén disponibles.
• Bloqueo biométrico o por PIN cada vez que la app vuelve a primer plano. El cierre automático de sesión del 164.312(a) se aplica también a los móviles: la app debe volver a autenticar al usuario cuando haya estado en segundo plano más allá del umbral de inactividad — normalmente 5–15 minutos en interfaces clínicas.
• Desactive la copia de seguridad en la nube para la ePHI. De forma predeterminada, iOS copia los datos de las apps en iCloud y Android, en Google Drive. Ninguna de las dos plataformas ofrece un BAA para consumidores. Excluya las bases de datos y los archivos con ePHI de las API de copia de seguridad correspondientes (NSFileProtectionComplete + allowsCloudEncryption: false en iOS; android:allowBackup="false" o reglas de exclusión selectiva en Android).
• Fijación de certificados (certificate pinning). Los ataques de intermediario (man-in-the-middle) sobre TLS en móviles son habituales en las redes Wi-Fi de los entornos sanitarios. Fije la huella del certificado de su API y cierre la conexión si no coincide (fail closed); utilice pines de respaldo y una ventana de rotación para no quedar bloqueado al renovar el certificado.
• Prevención de capturas y grabaciones de pantalla. Active FLAG_SECURE en las Activities de Android que contengan PHI; en iOS, supervise UIScreen.captureDidChange y oculte el contenido de la pantalla durante la captura. La PHI visible en una captura de pantalla es PHI divulgada.
• Detección de jailbreak y root. Un dispositivo rooteado puede leer directamente el contenido de Keystore/Keychain. Utilice una biblioteca de detección comercial (SafetyNet Attestation / Play Integrity API en Android; DeviceCheck en iOS) y, si se detecta, bloquee el acceso o restrinja los privilegios.
• Controles de los datos sin conexión. Limite la ePHI almacenada en la caché local a lo que realmente requiere la sesión actual del usuario; acote en el tiempo la ventana sin conexión (24 horas es un máximo defendible en la mayoría de los contextos clínicos); vuelva a cifrar la caché local cada vez que el dispositivo se bloquee de nuevo.
• Higiene de las notificaciones push. Las vistas previas de las notificaciones no deben mostrar PHI. Utilice textos genéricos («Tiene un nuevo mensaje de su equipo asistencial») en lugar de contenido clínico, incluso con el dispositivo desbloqueado. Las cargas útiles de las notificaciones que incluyan PHI requieren la misma cobertura de BAA que la propia API.

Un SDLC conforme a HIPAA en 8 pilares

1. Análisis de riesgos según el 164.308(a)(1)(ii)(A), actualizado cada año y tras cualquier cambio significativo. Utilice la metodología NIST 800-30; los auditores la reconocen.
2. Formación del personal según el 164.530(b) para todas las personas que manejan PHI, documentada en un LMS con certificados de finalización.
3. Acceso con mínimo privilegio y revisiones de acceso trimestrales según el 164.308(a)(4); aprovisionamiento mediante SCIM, acceso JIT a producción y definiciones de roles versionadas.
4. Registro de auditoría en un almacén a prueba de manipulaciones (object lock, solo anexado) con una conservación de 6+ años para cumplir el 164.316(b)(2); registre cada lectura, escritura, eliminación y exportación de PHI, con el usuario, la marca de tiempo, la IP de origen y el identificador del registro.
5. Cifrado en reposo (AES-256, claves gestionadas con KMS) y en tránsito (TLS 1.2+, módulos criptográficos validados FIPS 140-2 cuando sea viable); BYOK para los clientes empresariales.
6. Copias de seguridad, DR y plan de contingencia probado según el 164.308(a)(7); RTO/RPO documentados por sistema y restauración probada al menos una vez al año.
7. Cadena de BAA mapeada, actualizada cada año y controlada a través del proceso de compras.
8. Respuesta a incidentes: un runbook con el plazo de 60 días para las brechas ya incorporado, probado dos veces al año mediante ejercicios de mesa (tabletop) e integrado con el sistema de avisos de guardia.

La lista de verificación técnica que realmente usan los auditores

• Identificadores de usuario únicos — nunca cuentas compartidas.
• MFA obligatoria en todas las cuentas con acceso a PHI, sin excepciones por «comodidad del administrador».
• Tiempos de espera de sesión ≤ 15 minutos en las interfaces clínicas y ≤ 30 en el back-office.
• Cierre automático de sesión implementado y probado.
• Cifrado en reposo con claves gestionadas con KMS; política de rotación de claves documentada y aplicada.
• TLS 1.2+ en todas partes; cifrados débiles desactivados; HSTS preload.
• Registros de auditoría de solo anexado, inmutables y con verificación de integridad (HMAC o firma); conservación de 6 años.
• Pista de auditoría de las exportaciones de PHI con detalle a nivel de campo.
• Pipeline de desidentificación validado mediante Safe Harbor o Expert Determination, con una nueva evaluación anual del riesgo de reidentificación.
• Acceso a la base de datos de producción solo mediante JIT, con grabación de cada sesión.
• Copias de seguridad cifradas, distribuidas geográficamente y con la restauración probada.
• Inventario de BAA con proveedores al día; todos los servicios que tocan PHI incluidos en el alcance.
• Análisis de riesgos vigente, firmado y fechado dentro de los últimos 12 meses.
• Runbook de respuesta a incidentes vigente; último ejercicio de mesa dentro de los últimos 6 meses.
• Registros de formación del personal al día; último ciclo dentro de los últimos 12 meses.

Las 10 infracciones más frecuentes que vemos en las revisiones previas a la auditoría

1. Análisis de riesgos inexistente o con 3+ años de antigüedad.
2. Registros enviados a un proveedor de observabilidad sin BAA (Datadog por defecto, Sentry por defecto, etc.).
3. Acceso «en la sombra» de los desarrolladores a producción, sin JIT y sin grabación.
4. Cuentas de servicio compartidas, a menudo restos de la fase de desarrollo.
5. Desidentificación implementada como SQL ad hoc, no como un pipeline validado.
6. La app móvil guarda PHI en la caché del almacenamiento local sin cifrar.
7. Personal de soporte que usa ChatGPT o Claude.ai con PHI real — una brecha inmediata.
8. Copias de seguridad cifradas en tránsito, pero almacenadas descifradas en la caché de una CDN.
9. Ningún BAA con el proveedor de correo electrónico pese a que hay PHI en el cuerpo de los tickets de soporte.
10. El runbook de respuesta a incidentes menciona el plazo de 60 días, pero nadie lo ha activado en 18 meses.

Coste del desarrollo de software conforme a HIPAA: estimaciones para 2026

El cumplimiento de HIPAA no es una partida presupuestaria — es una disciplina de ingeniería integrada en todo su SDLC. En un producto SaaS típico construido desde cero para ser apto para HIPAA, el trabajo específico de cumplimiento añade un 25–40 % al coste del proyecto. En una adaptación (retrofit) — el cumplimiento añadido a un sistema existente que no lo cumple — el sobrecoste es del 60–150 %, porque las infracciones de arquitectura (bases de datos sin cifrar, cuentas compartidas, ausencia de registros de auditoría) exigen una reingeniería invasiva, no cambios de configuración.

Una empresa HealthTech en Serie A que construye una nueva plataforma vinculada a la EHR debería presupuestar $150k–$350k para la ingeniería HIPAA en un alcance de producto de $500k–$1M. El mantenimiento anual — supervisión, nuevas pruebas, ciclos de formación, renovación de los BAA — supone $40k–$120k/año. Compare esas cifras con el techo de sanción de Tier 4, de $2.13M por categoría de infracción y año, y el cálculo del ROI resulta evidente. Nuestras evaluaciones a precio cerrado de desarrollo de software conforme a HIPAA delimitan su arquitectura concreta y elaboran un presupuesto de corrección partida por partida, para que las sorpresas de coste aparezcan al estimar, no durante la auditoría.

Si está definiendo el alcance de un desarrollo HealthTech o corrigiendo un programa HIPAA, realizamos análisis de brechas a precio cerrado a través de nuestro servicio de desarrollo de software conforme a HIPAA; los hemos llevado a cabo junto con programas de desarrollo SaaS y de software a medida, y un CTO a tiempo parcial con experiencia real en proyectos HIPAA suele amortizarse en los dos primeros meses solo con la reducción de riesgos.

Preguntas frecuentes

¿Debo cumplir HIPAA si solo soy un proveedor?

Si crea, recibe, mantiene o transmite PHI en nombre de una entidad cubierta, sí — usted es un socio comercial (business associate) según el 45 CFR 160.103, la Security Rule ampliada por HITECH y la mayor parte de la Privacy Rule se le aplican directamente, y debe firmar un BAA.

¿Qué exige técnicamente la Security Rule?

164.312, salvaguardas técnicas: control de acceso con identificadores únicos y acceso de emergencia (164.312(a)), controles de auditoría (164.312(b)), integridad (164.312(c)), autenticación (164.312(d)) — con la MFA como mínimo en 2026 — y seguridad de la transmisión con TLS 1.2+ (164.312(e)).

¿De cuánto tiempo dispongo para notificar una brecha?

CE: notificar a las personas afectadas en un plazo de 60 días desde el descubrimiento (164.404); al HHS de forma simultánea si son 500+; registro anual si son <500. BA: notificar a la CE en un plazo de 60 días (164.410), que por contrato suele reducirse a 5–30.

¿El cifrado ofrece un puerto seguro (safe harbor) frente a la notificación de brechas?

Sí, si el cifrado cumple el estándar de la guía del HHS/HITECH — NIST 800-111 en reposo, NIST 800-52 / FIPS 140-2 en tránsito. Las claves deben guardarse separadas del texto cifrado.

¿Puedo usar AWS, GCP o Azure para la ePHI?

Sí — firme primero el BAA, limítese a los servicios aptos para HIPAA e implemente cifrado con KMS, IAM con mínimo privilegio, registro de auditoría completo y aislamiento mediante VPC. Revise la lista de servicios aptos cada trimestre.

¿Cómo es un SDLC conforme a HIPAA?

Ocho pilares: análisis de riesgos, formación del personal, acceso con mínimo privilegio, registro de auditoría con conservación de 6 años, cifrado, plan de contingencia, cadena de BAA y respuesta a incidentes con el plazo de 60 días incorporado.

¿Cuánto cuesta el desarrollo de software conforme a HIPAA?

En un desarrollo nuevo, la ingeniería HIPAA suele añadir un 25–40 % al coste del proyecto. Principales partidas: cifrado y gestión de claves ($15k–$40k), MFA y controles de acceso ($10k–$25k), infraestructura de registro de auditoría ($15k–$35k), análisis de riesgos ($8k–$20k), revisión de proveedores con BAA ($5k–$15k) y una prueba de penetración anual ($15k–$30k). Un producto HealthTech en Serie A con un alcance de $500k–$1M debería presupuestar $150k–$350k para la ingeniería específica de HIPAA. Adaptar el cumplimiento a un sistema existente que no lo cumple suele costar un 60–150 % más, porque las infracciones de arquitectura — bases de datos sin cifrar, cuentas compartidas, ausencia de registros de auditoría — exigen una reingeniería invasiva en lugar de cambios de configuración.

HIPAA no es una lista de verificación. Es un enfoque operativo.

Los equipos que cumplen HIPAA sin sobresaltos tratan el cumplimiento como un artefacto del propio desarrollo: compras condicionadas a un BAA, servicios cifrados por defecto, registros de auditoría generados por el framework y no a mano, MFA obligatoria desde el primer día y análisis de riesgos según un calendario. Los equipos que tratan HIPAA como una auditoría de fin de proyecto siempre pasan por alto algo importante y lo pagan durante una investigación de la OCR.

Última actualización: 26 de mayo de 2026. Las referencias a secciones remiten a las partes 160 y 164 del 45 CFR. Nada de lo contenido en este artículo constituye asesoramiento jurídico para una situación concreta.