Un cliente me llamó un jueves por la tarde a finales de 2023 — un giro de fintech a healthtech, acababan de contratar a un consultor de cumplimiento que había revisado su base de código Next.js y devolvió una lista de tres páginas de problemas. "Pensamos que ponerlo en AWS era suficiente", dijo el fundador. Genuinamente lo creía. Y honestamente, había escuchado esa misma frase de probablemente seis equipos diferentes antes del suyo.
La compatibilidad con HIPAA es una de esas áreas donde todos piensan que entienden la superficie — firmar un BAA, elegir un proveedor de nube compatible, listo. Pero la Regla de Seguridad HIPAA no le importa la página de marketing de tu proveedor de hosting. Le importa cómo tu aplicación maneja, almacena, transmite y audita Información Protegida de Salud (PHI). Next.js — como framework — no es ni compatible ni incompatible con HIPAA fuera de la caja. Lo que construyas encima de él es todo.thinksthey understand the surface — sign a BAA, pick a compliant cloud provider, done. But theHIPAA Security Ruledoesn't care about your hosting provider's marketing page. It cares about how your application handles, stores, transmits, and audits Protected Health Information (PHI). Next.js — as a framework — is neither compliant nor non-compliant out of the box. What you build on top of it is everything.
Así que permíteme guiarte a través de lo que realmente cuenta en 2026, basado en arquitecturas reales que he construido y errores reales que he visto cometer a equipos.
---
Lo que "Next.js compatible con HIPAA" realmente significa
Las personas confunden el cumplimiento de infraestructura con el cumplimiento de aplicaciones. No son lo mismo.
Tu proveedor de nube (AWS, GCP, Azure — elige uno) puede firmar un Acuerdo de Asociado de Negocios contigo. Es un documento legal que establece que protegerán PHI en su infraestructura de acuerdo con las reglas de HIPAA. AWS tiene una lista de servicios elegibles para HIPAA que vale la pena guardar. Pero un BAA de AWS no significa que tu aplicación Next.js sea compatible. Ni de cerca.HIPAA-eligible services listthat's worth bookmarking. But a BAA from AWS doesn't mean your Next.js app is compliant. Not even close.
La capa de aplicación es tu responsabilidad. Siempre. El framework es solo un vehículo.yourresponsibility. Always. The framework is just a vehicle.
Esto es lo que pasa — Next.js 14+ (y hacia 2026, el App Router está completamente maduro) te da componentes de servidor, server actions, middleware y funciones edge. Cada uno de esos tiene implicaciones diferentes para el manejo de PHI. Un componente de servidor que consulta una base de datos de pacientes y pasa datos a un componente cliente — ¿dónde viven esos datos? ¿Cuánto tiempo? ¿Terminan en un caché del navegador? Estas no son preocupaciones hipotéticas.
---
El Problema de la Superficie de PHI
Antes de escribir una línea de código, hago que cada cliente de health-tech haga un ejercicio: mapear cada lugar donde PHI podría tocar la aplicación. No donde debería tocarla. Donde podría.shouldtouch it. Where itcould.
Eso incluye:
- Parámetros de URL (he visto IDs de pacientes en query strings — no lo hagas)
- localStorage y sessionStorage del navegador
localStorageandsessionStorage - Gestión de estado del lado del cliente (almacenes Zustand, Redux, incluso React context)
- Caché de fetch de Next.js y la capa Data Cache
- Salida de log de console.log durante desarrollo que se filtra a producción
console.logduring development that sneaks into production - Herramientas de seguimiento de errores como Sentry (más sobre esto en breve)
- Pipelines de análisis — GA4, Segment, Amplitude
Los últimos dos causan problemas a más equipos que casi cualquier otra cosa. A principios de 2024, Seahawk tenía un cliente de telesalud que había configurado Sentry para monitoreo de errores. Un movimiento estándar. Excepto que sus límites de error estaban capturando el objeto props completo en caso de fallo — lo que incluía detalles de citas e indicadores de salud del usuario. Sentry no estaba cubierto bajo su BAA. Eso es una brecha esperando ocurrir.
Sanitización de tu Seguimiento de Errores
Si estás usando Sentry con código adyacente a PHI, usa el hook beforeSend para limpiar campos sensibles antes de que salgan del navegador. Punto final. Algo como esto es innegociable:beforeSendhook to scrub sensitive fields before they leave the browser. Full stop. Something like this is non-negotiable:
`` beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; } ``beforeSend(event) { if (event.user) { delete event.user.email; delete event.user.ip_address; } return event; }``
Sentry sí tiene una ruta de cumplimiento HIPAA — firmarán un BAA — pero aun así necesitas configurar qué datos les envías. El BAA no sanitiza tus payloads automáticamente.HIPAA compliance path— they'll sign a BAA — but you still need to configure what data you send them. The BAA doesn't sanitise your payloads automatically.
---
Autenticación y Manejo de Sesiones
Aquí es donde veo más atajos. Los equipos recurren a NextAuth.js (ahora Auth.js), conectan un proveedor y consideran que terminaron. Auth.js es una librería sólida. Pero los valores por defecto no son valores por defecto de HIPAA.
Algunos detalles específicos:
- Almacenamiento de tokens de sesión — Auth.js usa por defecto una sesión basada en cookies, lo cual está bien, pero necesitas httpOnly, secure, y sameSite: 'strict' configurados explícitamente. No des por sentado.— Auth.js defaults to a cookie-based session, which is fine, but you need
httpOnly,secure, andsameSite: 'strict'explicitly set. Don't assume. - Vencimiento de sesión — El estándar de Cierre Automático de HIPAA (§164.312(a)(2)(iii)) requiere que las sesiones se terminen después de un período definido de inactividad. El número no está prescrito, pero 15 minutos es el estándar de la industria para aplicaciones clínicas. Configura un temporizador de inactividad en tu layout. Por lo general lo construyo como un hook personalizado que ejecuta una server action para invalidar la sesión.— HIPAA's Automatic Logoff standard (§164.312(a)(2)(iii)) requires that sessions terminate after a defined period of inactivity. The number isn't prescribed, but 15 minutes is the industry standard for clinical applications. Wire up an inactivity timer in your layout. I usually build this as a custom hook that fires a server action to invalidate the session.
- MFA — No está estrictamente mandatado por el texto de HIPAA, pero intenta explicarle a un auditor de OCR por qué no lo implementaste después de una brecha. Usa TOTP mediante algo como otplib o apóyate en un proveedor de identidad como Auth0 o Clerk que tenga MFA integrado y firme un BAA.— Not strictly mandated by HIPAA's text, but try explaining to an OCR auditor why you didn't implement it after a breach. Use TOTP via something like
otplibor lean on an identity provider like Auth0 or Clerk that has MFA baked in and will sign a BAA. - Registro de auditoría de eventos de autenticación — Cada login, cada intento de login fallido y cada logout necesitan ser registrados con un timestamp e identificador de usuario. Cada uno.— Every login, failed login, and logout needs to be logged with a timestamp and user identifier. Every single one.
No te voy a decir que Auth.js sea incorrecto para este caso de uso — lo he implementado en producción en proyectos HIPAA. Pero tienes que aplicar deliberadamente los requisitos de cumplimiento encima.
---
Datos en Tránsito y en Reposo
El tránsito es la parte fácil. TLS 1.2 como mínimo, TLS 1.3 preferentemente, en todas partes. No solo tu dominio principal — tus rutas de API, tus funciones edge, cualquier webhook. Si estás en Vercel, esto se maneja automáticamente. Si haces self-hosting en EC2 o ejecutas Next.js en un contenedor Docker detrás de un proxy inverso NGINX, necesitas configurarlo tú mismo. He revisado bases de código donde las llamadas internas entre servicios seguían siendo HTTP porque "está dentro de la VPC". Eso no es una posición aceptable.
El reposo es más difícil. Algunos detalles que importan:
- Cifrado de base de datos — AWS RDS con cifrado habilitado (usa AES-256 vía AWS KMS). Es una casilla de verificación, pero necesitas marcarla realmente y documentarla.— AWS RDS with encryption enabled (uses AES-256 via AWS KMS). This is a checkbox, but you need to actually check it and document it.
- Cifrado a nivel de campo para datos altamente sensibles — Para cosas como números de seguro social, diagnósticos o listas de medicamentos, frecuentemente agrego una segunda capa de cifrado a nivel de aplicación usando una librería como @aws-sdk/client-kms para envolver/desenvolver claves. La sobrecarga es real, pero también lo es el riesgo.— For things like SSNs, diagnoses, or medication lists, I often add a second layer of encryption at the application level using a library like
@aws-sdk/client-kmsto wrap/unwrap keys. Overhead is real, but so is the risk. - Next.js Data Cache — Este punto confunde a muchos. El App Router cachea respuestas de fetch por defecto. Si estás obteniendo datos de pacientes en un componente servidor con fetch(), necesitas { cache: 'no-store' } a menos que estés deliberadamente gestionando la revalidación. Una respuesta cacheada que contiene PHI sentada en la memoria o sistema de archivos del servidor es un problema.— This one catches people out. The App Router caches fetch responses by default. If you're fetching patient data in a server component with
fetch(), you need{ cache: 'no-store' }unless you're very deliberately managing revalidation. A cached response containing PHI sitting in the server's memory or filesystem is a problem. - Backups — Cifrados. Probados. Documentados. Obvio, pero he auditado sistemas donde los backups existían pero nunca habían sido restaurados una sola vez.— Encrypted. Tested. Documented. Obvious, but I've audited systems where the backups existed but had never been restored once.
---
Audit Logging: La Parte que Nadie Quiere Construir
Aquí algo que diré claramente — audit logging es la cosa más aburrida y más importante que construirás en una aplicación de health-tech. Todo acceso a PHI necesita ser registrado. No solo escrituras. Lecturas también.
El estándar HIPAA Audit Controls (§164.312(b)) requiere "mecanismos de hardware, software, y/o procedimentales que registren y examinen la actividad en sistemas de información que contengan o utilicen ePHI." En la práctica, esto significa: necesitas un registro de solo-adición de quién accedió a qué datos de pacientes, cuándo y desde dónde.HIPAA Audit Controls standard(§164.312(b)) requires "hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." What that means practically: you need an append-only log of who accessed what patient data, when, and from where.
Yo construyo esto como una capa middleware en Next.js. Para proyectos con App Router, intercepto en middleware.ts para logging a nivel de rutas y agrego un envoltorio de servicio delgado alrededor de cualquier función de consulta a base de datos que toque tablas PHI. Los registros de auditoría se escriben en una tabla de base de datos separada (o un servicio como AWS CloudTrail si quieres garantías de inmutabilidad) — nunca en la misma tabla que el PHI mismo.middleware.tsfor route-level logging and add a thin service wrapper around any database query function that touches PHI tables. The log records get written to a separate database table (or a service like AWS CloudTrail if you want immutability guarantees) — never the same table as the PHI itself.
Un registro de auditoría mínimo se ve así:
user_id — quién— whoresource_type + resource_id — qué+resource_id— whataction — read / write / delete— read / write / deleteip_address — dónde (anonimizado a nivel de red está bien)— where (anonymised at the network layer is fine)timestamp (UTC, siempre UTC)(UTC, always UTC)request_id — para correlacionar con tus logs de aplicación— to correlate with your application logs
No dejes que los desarrolladores hagan console.log(patientRecord) y lo llamen una pista de auditoría. Lo he visto. No es así.console.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Elige tu Stack de Infraestructura
La respuesta honesta es que en 2026 hay un puñado de stacks que realmente recomendaría para una aplicación Next.js en producción con HIPAA.
Vercel + PlanetScale/Neon + Clerk es el stack de experiencia del desarrollador. Vercel firmará un BAA (plan empresarial — sí, cuesta dinero). PlanetScale y Neon ambos tienen niveles elegibles para HIPAA. Clerk maneja la autenticación y firmará un BAA. Es rápido de desplegar y razonable de operar. El compromiso es el costo a escala y cierta pérdida de control de la infraestructura.is the developer-experience stack. Vercel will sign a BAA (enterprise plan — yes, it costs money). PlanetScale and Neon both have HIPAA-eligible tiers. Clerk handles auth and will sign a BAA. This is fast to ship and reasonable to operate. The tradeoff is cost at scale and some loss of infrastructure control.
AWS (ECS/EKS para la aplicación Next.js) + RDS Aurora + Cognito es el stack empresarial. Más sobrecarga operativa. Mucho más control. El modelo de responsabilidad compartida de AWS está bien documentado y la cobertura del BAA es amplia. Si tu cliente es un sistema hospitalario o una aseguradora, probablemente te preguntarán sobre tu arquitectura AWS en detalle.is the enterprise stack. More operational overhead. Much more control. AWS's shared responsibility model is well-documented and the BAA coverage is broad. If your client is a hospital system or an insurer, they're probably going to ask about your AWS architecture in detail.
Render o Railway — yo me mantendría alejado para cualquier cosa seriamente regulada. Son excelentes herramientas, pero su historial de cumplimiento HIPAA es delgado.— I'd steer clear for anything seriously regulated. They're great tools, but their HIPAA compliance story is thin.
Una cosa que quiero señalar: la Edge Network de Vercel y las Edge Functions no están cubiertas por HIPAA bajo su BAA a principios de 2026. Si ejecutas lógica que toca PHI en middleware de edge, eso es una brecha. Ejecuta esa lógica en funciones serverless (runtime Node.js) en su lugar.notHIPAA-covered under their BAA as of early 2026. If you're running logic that touches PHI in edge middleware, that's a gap. Run that logic in serverless functions (Node.js runtime) instead.
---
Integraciones de Terceros: Dónde el Cumplimiento Va a Morir
Cada tercero que integres y que toque PHI necesita un BAA. Eso suena obvio. Aquí está la lista que realmente confunde a los equipos:
- Herramientas de atención al cliente (Intercom, Zendesk) — si un paciente escribe sobre su salud, eso es PHI en tu plataforma de soporte
- Herramientas de formularios (Typeform, Jotform) — los formularios de admisión de pacientes son PHI
- Proveedores de correo (SendGrid, Postmark) — si el cuerpo del email contiene información de salud, se requiere BAA
- Herramientas de feature flags (LaunchDarkly, Statsig) — generalmente está bien, pero si pasas atributos de usuario que incluyen estado de salud para evaluar flags, eso es PHI
- CRMs (HubSpot, Salesforce) — muchos equipos de healthtech sincronizan datos de pacientes en estos sin pensarlo
Postmark firmará un BAA. SendGrid (vía Twilio) también lo hará, en planes pagos. Twilio para SMS también. LaunchDarkly tiene una ruta para BAA. No son opciones oscuras — el proceso de BAA es generalmente un envío de formulario y unos pocos días hábiles.
¿Las que no firmarán o no pueden firmar un BAA? No las integres cerca de PHI. Así de simple.
---
FAQ
¿Desplegar en Vercel hace que mi aplicación Next.js sea compatible con HIPAA?
No. Vercel puede firmar un Acuerdo de Asociado de Negocios en su plan empresarial, lo que significa que asume ciertas obligaciones HIPAA por la infraestructura que controla. Pero tu código de aplicación, tu diseño de base de datos, tu logging, tus integraciones de terceros — nada de eso está cubierto por el BAA de Vercel. El cumplimiento se comparte en cada capa del stack, y la capa de aplicación es tu responsabilidad.
¿Necesito encriptar datos en una ruta de API de Next.js antes de enviarlos al cliente?
TLS maneja la encriptación en tránsito, así que no necesitas encriptar manualmente el cuerpo de la respuesta HTTP. Lo que sí necesitas hacer es asegurarte de que solo devuelves el mínimo PHI necesario para la operación — no registros completos de pacientes cuando solo necesitas un nombre, por ejemplo. El principio del "mínimo necesario" está integrado en HIPAA y debe dar forma a tu diseño de respuesta API desde el primer día.
¿Es seguro el almacenamiento en caché integrado del App Router de Next.js para PHI?
No por defecto. El Data Cache y Full Route Cache en el App Router pueden almacenar en caché respuestas que contienen PHI, lo cual es problemático. Para cualquier ruta o llamada fetch que toque datos de pacientes, usa { cache: 'no-store' } en llamadas fetch y agrega export const dynamic = 'force-dynamic' a segmentos de ruta. Revisa cuidadosamente la documentación de almacenamiento en caché de Vercel — es densa pero importante.{ cache: 'no-store' }on fetch calls and addexport const dynamic = 'force-dynamic'to route segments. Review Vercel'scaching documentationcarefully — it's dense but important.
¿Cuál es el logging mínimo que necesito para una pista de auditoría HIPAA?
Como mínimo: quién accedió a qué, cuándo y desde dónde. Eso es ID de usuario, identificador de recurso, tipo de acción, marca de tiempo y dirección IP. Los logs deben ser resistentes a alteraciones (append-only, no editables por código de aplicación) y retenidos — la mayoría de marcos de cumplimiento sugieren seis años, lo que coincide con el requisito de retención de documentación de HIPAA.
¿Puedo usar React Query o SWR para obtener datos en una aplicación HIPAA?
Sí, pero con cuidado. Ambas bibliotecas almacenan respuestas en caché del lado del cliente, lo que significa que PHI puede estar en la memoria del navegador. Establece staleTime: 0 y cacheTime: 0 (React Query) o dedupingInterval: 0 (SWR) para queries que devuelven PHI. También borra explícitamente el caché de queries al cerrar sesión — no confíes en que el desmontaje de componentes maneje esto.staleTime: 0andcacheTime: 0(React Query) ordedupingInterval: 0(SWR) for queries that return PHI. Also clear the query cache on logout explicitly — don't rely on component unmounting to handle this.
---
Quiero ser honesto sobre algo: la conformidad con HIPAA es genuinamente difícil de implementar correctamente, y ningún framework —Next.js u otro— la hace fácil. Los equipos que he visto hacerlo bien son aquellos que la tratan como un problema arquitectónico desde el primer día, no como una lista de verificación que completar antes del lanzamiento. El framework está bien. Las brechas casi siempre están en las decisiones tomadas alrededor de él.
Comienza con el mapeo del área de superficie de PHI. Todo lo demás se deduce de eso.