Un cliente me llamó un jueves por la tarde a finales de 2023 —fintech reconvertida en healthtech, acababan de contratar a un consultor de cumplimiento que había revisado su código en Next.js y devolvió una lista de tres páginas con problemas. "Pensamos que ponerlo en AWS era suficiente", dijo el fundador. De verdad lo creía. Y honestamente, había escuchado la misma frase de probablemente seis equipos diferentes antes que el suyo.
El cumplimiento de HIPAA es uno de esos temas donde todos piensan que entienden la superficie —firma un BAA, elige un proveedor de nube compatible, listo. Pero la Regla de Seguridad de 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 marco— no es ni compatible ni incompatible de fábrica. Todo depende de lo que construyas encima.thinks they understand the surface -- sign a BAA, pick a compliant cloud provider, done. But the HIPAA Security Rule doesn'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.
---
Los tres caminos reales de HIPAA en 2026 —elige el tuyo antes de elegir un stack
Si estás construyendo algo con forma de healthcare este año, tienes tres rutas que realmente se traducen en un Acuerdo de Socio Comercial firmado y un registro de auditoría defendible. La mayoría de blogs de ingeniería solo cubren el primero. Los otros dos son más baratos, más rápidos, y son la respuesta correcta más a menudo de lo que admite la comunidad de Next.js.
- Camino 1 —Next.js + Vercel BAA: la decisión correcta cuando tu producto tiene dashboards autenticados, flujos de trabajo personalizados, datos en tiempo real, características de IA, o cualquier cosa más allá de contenido estático. Vercel finalmente abrió los BAA de HIPAA a equipos Pro en 2025 con un complemento de $350/mes, así que ya no necesitas un contrato Enterprise para lanzar.Vercel BAA: the right call when your product has authenticated dashboards, custom workflows, real-time data, AI features, or anything past static content. Vercel finally opened HIPAA BAAs to Pro teams in 2025 at a $350/month add-on, so you no longer need an Enterprise contract to ship.
- Camino 2 —WordPress en un host elegible para HIPAA: la decisión correcta cuando tu sitio de healthcare es un sitio de marketing más formularios de admisión más un equipo editorial que ya conoce wp-admin. Atlantic.Net firma un BAA desde $350/mes, Liquid Web desde $600/mes, HIPAA Vault para completamente gestionado. El camino que la mayoría de los sitios de clínicas de healthcare deberían tomar.WordPress on a HIPAA-eligible host: the right call when your healthcare site is a marketing site plus intake forms plus an editorial team that already knows wp-admin. Atlantic.Net signs a BAA from $350/month, Liquid Web from $600/month, HIPAA Vault for fully managed. The path most healthcare clinic sites should take.
- Camino 3 —JotForm Gold a $99/mes: la decisión correcta cuando la única PHI que manejas es formularios —admisión de pacientes, registro de síntomas, comentarios. JotForm incluye HIPAA en el plan Gold sin complemento. PHI nunca toca tu infraestructura. Incrusta el formulario, firma el BAA, lanza en una tarde.
El resto del artículo cubre las decisiones de arquitectura para la ruta 1 en profundidad, pero la sección del BAA de Vercel, la sección de WordPress y la sección de JotForm explican cuándo cada ruta es la correcta. Si estás a punto de leer 2.000 palabras sobre registro de auditoría de Next.js cuando JotForm habría resuelto tu proyecto real en una hora, los próximos tres minutos son los más valiosos en esta página.
Qué significa realmente "Next.js Cumplidor de HIPAA"
La gente confunde el cumplimiento de infraestructura con el cumplimiento de aplicación. No son lo mismo.
Tu proveedor de nube (AWS, GCP, Azure —elige uno) puede firmar un Acuerdo de Asociado de Negocios contigo. Ese 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 marcar. Pero un BAA de AWS no significa que tu aplicación de Next.js sea compatible. Ni de cerca.HIPAA-eligible services list that'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.your responsibility. Always. The framework is just a vehicle.
La cosa es que Next.js 14+ (y en 2026, el App Router está completamente maduro) te da componentes de servidor, acciones de servidor, 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? ¿Por 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 realice un ejercicio: mapear cada lugar donde PHI podría posiblemente tocar la aplicación. No donde debería tocarlo. Donde podría.should touch it. Where it could.
Eso incluye:
- Parámetros de URL (he visto IDs de pacientes en cadenas de consulta —no lo hagas)
- localStorage y sessionStorage del navegador
localStorageandsessionStorage - Gestión de estado del lado del cliente (tiendas Zustand, Redux, incluso React context)
- Next.js fetch cache y la capa Data Cache
- Salida de log de console.log durante desarrollo que se cuela 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 generan más problemas 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 error boundaries capturaban el objeto de props completo en caso de crash —lo que incluía detalles de citas y banderas de salud del usuario. Sentry no estaba cubierto por su BAA. Eso es una filtración a punto de ocurrir.
Desinfectando 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:beforeSend hook 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 aún necesitas configurar qué datos les envías. El BAA no desinfecta automáticamente tus payloads.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 dan por terminado. Auth.js es una librería sólida. Pero los valores predeterminados no son valores predeterminados 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 lo 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. - Expiración de sesión —El estándar de Cierre de Sesión Automático de HIPAA (§164.312(a)(2)(iii)) requiere que las sesiones 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. Normalmente construyo esto 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 es estrictamente obligatorio por el texto de HIPAA, pero intenta explicarle a un auditor de OCR por qué no lo implementaste después de una filtración. Usa TOTP a través de 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, login fallido y logout necesita ser registrado con una marca de tiempo 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 voy a decirte que Auth.js es incorrecto para este caso de uso —lo he desplegado en producción en proyectos HIPAA. Pero tienes que aplicar los requisitos de cumplimiento encima deliberadamente.
---
Datos en tránsito y en reposo
El tránsito es la parte fácil. TLS 1.2 mínimo, TLS 1.3 preferido, en todas partes. No solo tu dominio principal —tus rutas de API, tus edge functions, cualquier webhook. Si estás en Vercel, esto está manejado. Si estás alojando por tu cuenta en EC2 o ejecutando Next.js en un contenedor Docker detrás de un reverse proxy NGINX, necesitas configurar esto tú mismo. He revisado bases de código donde las llamadas internas entre servicios aún estaban en 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:
- Encriptación de base de datos —AWS RDS con encriptación habilitada (usa AES-256 a través de AWS KMS). Es un checkbox, pero necesitas marcarlo realmente y documentarlo. -- 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.
- Encriptación a nivel de campo para datos altamente sensibles —Para cosas como SSNs, diagnósticos o listas de medicamentos, frecuentemente agrego una segunda capa de encriptación a nivel de aplicación usando una librería como @aws-sdk/client-kms para envolver/desenvovler claves. El overhead es real, pero el riesgo también. -- 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 es el que sorprende a muchos. El App Router cachea las respuestas de fetch por defecto. Si estás obteniendo datos de pacientes en un server component con fetch(), necesitas { cache: 'no-store' } a menos que estés gestionando deliberadamente la revalidación. Una respuesta cacheada que contiene PHI sentada en la memoria o filesystem 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 -- Encriptadas. Probadas. Documentadas. Obvio, pero he auditado sistemas donde los backups existían pero nunca habían sido restaurados. -- 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í hay algo que diré claramente -- audit logging es lo más aburrido y lo más importante que construirás en una health-tech app. 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 procedimientos que registren y examinen la actividad en sistemas de información que contengan o usen ePHI." Lo que eso significa en la práctica: necesitas un registro de solo-anexión de quién accedió a qué datos del paciente, 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.
Construyo esto como una middleware layer en Next.js. Para proyectos con App Router, intercepto en middleware.ts para logging a nivel de rutas y agrego un thin service wrapper alrededor de cualquier función de database query que toque tablas PHI. Los registros de log 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.middleware.ts for 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 (anonimizada 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 application logs-- to correlate with your application logs
No dejes que los desarrolladores añadan console.log(patientRecord) y lo llamen un registro de auditoría. He visto esto. No lo es.console.log(patientRecord)and call it an audit trail. I've seen this. It's not.
---
Elegir 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 developer-experience stack. Vercel firmará un BAA (enterprise plan -- sí, cuesta dinero). PlanetScale y Neon ambos tienen HIPAA-eligible tiers. Clerk maneja auth y firmará un BAA. Esto es rápido para shipped y razonable para operar. El tradeoff es costo a escala e alguna pérdida de control de 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 van a preguntar en detalle sobre tu arquitectura en AWS. 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 evitaría ambos para cualquier cosa seriamente regulada. Son herramientas excelentes, pero su historial de cumplimiento HIPAA es débil. -- 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 y Edge Functions de Vercel no están cubiertas por HIPAA bajo su BAA a principios de 2026. Si estás ejecutando lógica que toca PHI en middleware edge, eso es una brecha. Ejecuta esa lógica en funciones serverless (runtime Node.js) en su lugar.not HIPAA-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.
---
HIPAA BAA de Vercel -- qué te compra realmente ese $350/mes
Hasta 2025, firmar un BAA con Vercel requería un contrato Enterprise -- típicamente alrededor de $45,000 por año en el gasto medio. Eso dejó fuera a la mayoría de equipos de health-tech pre-Series-A y los empujó hacia AWS o Cloudflare. En 2025 Vercel cambió eso: los BAA HIPAA ahora están disponibles como un complemento self-serve de $350/mes en el plan Pro.
El BAA de Pro es un acuerdo de aceptación por clic, firmado a través del dashboard de Vercel. No hay negociación, sin compromiso mínimo, sin llamada de ventas Enterprise. Si estás en Pro a $20/asiento/mes y añades el complemento HIPAA, tu equipo de tres personas con una aplicación de salud cuesta $410/mes todo incluido en la capa de plataforma.
Qué cubre el BAA de Pro
- Vercel actúa como tu socio de negocios para propósitos HIPAA -- tienen los controles técnicos y organizacionales que una entidad cubierta necesita en un proveedor.
- Auditorías anuales de terceros, notificación de brechas dentro de los plazos HIPAA, y el conjunto estándar de salvaguardas administrativas.
- Edge runtime, Functions, ISR, optimización de imágenes, y el resto de la plataforma de Vercel están dentro del alcance del BAA.
Lo que el BAA Pro NO cubre -- lee esto antes de comprometerte
La función de seguridad mejorada de Vercel -- Secure Compute -- es solo Enterprise. Secure Compute te da redes de nube aisladas, direcciones IP dedicadas y peering VPC. Si tu arquitectura de seguridad requiere aislamiento de red entre tu app y la infraestructura pública de Vercel (una petición justa si tu auditor se preocupa por defensa en profundidad), el BAA Pro no es suficiente. Necesitas Enterprise.
Traducción práctica: el BAA de Pro a $350/mes funciona para la mayoría de aplicaciones de salud en etapa temprana donde la postura de auditoría se basa en controles apropiados. Si estás vendiendo a sistemas hospitalarios o tienes un oficial de cumplimiento que haya leído NIST SP 800-66 de tapa a tapa, de todas formas estarás en el plan Enterprise.
Si también necesitas SSO
SAML SSO en Vercel Pro es un complemento separado de $300/mes. Combinado con el BAA HIPAA, estás en $650/mes en complementos de cumplimiento. Ese es aproximadamente el umbral donde la cotización Enterprise comienza a parecer comparable en TCO -- a $45K/año medio, Enterprise se cotiza alrededor de $3,750/mes, pero incluye BAA, SSO, Secure Compute, soporte dedicado y varias otras características. Las matemáticas se cierran en el año dos para la mayoría de equipos.
El camino de WordPress que la mayoría de los ingenieros nunca consideran
Si has pasado las últimas seis semanas decidiendo qué librería de autenticación de Next.js tiene la mejor historia de HIPAA, aquí hay una pregunta para interrumpir ese hilo: ¿tu producto realmente necesita autenticación? ¿O el brief es un sitio de marketing, un blog editorial y un formulario de admisión compatible con HIPAA?
Si la respuesta es la segunda -- y para la mayoría de clínicas de salud, consultorio dentales, proveedores de salud mental y clínicas de fisioterapia, la respuesta es la segunda -- WordPress en un host elegible para HIPAA es el camino que deberías tomar. El costo es menor, el flujo de trabajo editorial está resuelto, y el modelo de seguridad es genuinamente más simple. Los plugins siguen siendo la superficie de ataque que siempre han sido, pero puedes lanzarte con un conjunto pequeño de plugins y un host WordPress gestionado que audite el resto.
Hosts que firman un BAA para WordPress
- Atlantic.Net -- hosting WordPress HIPAA gestionado desde $350/mes con BAA firmado, acceso VPN encriptado, backups diarios, MFA, y garantía de 100% de uptime. Dos décadas en IT de salud. La opción predeterminada para clínicas.
- Liquid Web -- servidores dedicados, VPS o cloud completamente gestionados desde $600/mes con configuraciones alineadas a HIPAA y BAA firmado. Soporte sólido, operaciones maduras.
- HIPAA Vault -- diseñado específicamente para HIPAA desde el inicio. Precio más alto, postura de cumplimiento más profunda, utilizado por organizaciones de salud más grandes.
- ScalaHosting -- VPS administrado desde $29.95/mes con BAA firmada, copias de seguridad diarias, transferencia encriptada. El extremo más económico de la curva; ideal para tráfico temprano y pequeño.
- AWS / Azure / GCP con WordPress administrado encima -- toda nube importante firmará una BAA, pero tú eres responsable de la configuración, endurecimiento y postura continua. La respuesta correcta si ya tienes un equipo en la nube.
Dónde la ruta de WordPress deja de funcionar
- Dashboards de pacientes autenticados -- posible en WordPress, complicado, y la brecha de plugins es real. Cambia a Next.js + Vercel BAA.
- Datos en tiempo real, características de IA, flujos de trabajo personalizados -- WordPress te pondrá resistencia. Next.js + Supabase + Vercel BAA es la llamada correcta.Supabase + Vercel BAA is the right call.
- Cualquier cosa pasada 100 plugins o un sistema de membresía complejo -- la superficie de ataque del plugin por sí sola es un riesgo HIPAA que vale la pena diseñar.
Si tu proyecto se ubica en el carril de WordPress, la ruta de migración práctica es la opción WordPress headless -- wp-admin para editores, un front end Next.js o Astro en el lado público, WPGraphQL conectando los dos. Mantienes el flujo editorial, el sitio público es rápido, y la superficie pública obtiene la historia de hosting moderna. Antes de comprometerte de cualquier forma, WordPress Stack Advisor toma tu URL y te dice cuál camino realmente se ajusta.headless WordPress option -- wp-admin for editors, a Next.js or Astro front end on the public side, WPGraphQL bridging the two. You keep the editorial workflow, the public site is fast, and the public surface gets the modern hosting story. Before you commit either way, the WordPress Stack Advisor takes your URL and tells you which path actually fits.
JotForm Gold a $99/mes: cuándo el atajo es la decisión correcta
Si el único PHI que tu producto toca es lo que viene a través de un formulario -- intake de pacientes, check-in de síntomas, retroalimentación post-visita, solicitudes de cita -- no necesitas construir formularios compatibles con HIPAA en tu aplicación. JotForm Gold a $99/mes por usuario incluye HIPAA sin costo adicional. PHI se recopila en la infraestructura auditada HIPAA de JotForm y nunca toca tus servidores.
Qué incluye realmente JotForm Gold
- Cumplimiento HIPAA incorporado -- BAA firmada a través del panel de JotForm, sin cargo adicional.
- 100 formularios, 10,000 envíos mensuales, 100 GB de almacenamiento. Más que suficiente para una clínica con múltiples ubicaciones.
- Tipos de campos elegibles para HIPAA: captura de firma, carga de archivos (encriptada), lógica condicional, prellenado, integraciones de pago con procesadores compatibles con HIPAA.
- Incrusta mediante iframe en tu sitio WordPress, tu app Next.js, tu página Webflow, en cualquier lugar. El formulario se ejecuta en la infraestructura de JotForm; tu sitio nunca ve el PHI.
- Integraciones de flujo de trabajo con CRM, EHR y plataformas de farmacias elegibles para HIPAA. La lista es más corta que en modo no-HIPAA pero cubre las piezas comunes.
Cuándo JotForm gana en TCO
Construir un formulario de ingreso compatible con HIPAA de forma nativa en Next.js es un compromiso de 2 a 3 semanas: columna de base de datos encriptada en reposo, registro de auditoría, BAA con tu proveedor de almacenamiento, revisión de seguridad, documentación de modelo de amenazas, y el mantenimiento continuo que conlleva una canalización de formulario personalizada. JotForm a $99/mes lo hace en una tarde. Si tu formulario es el único punto de contacto con PHI, las matemáticas siempre favorecen a JotForm.
Dónde JotForm deja de ser suficiente
- Tu portal de pacientes -- cualquier cosa que necesite leer PHI de interacciones anteriores, representar una línea de tiempo del paciente, o integrarse profundamente con tus datos de aplicación. Constrúyelo en tu aplicación.
- Restricciones de marca que demanden UX de formulario pixel-perfect. La personalización de JotForm es buena, no perfecta.
- Flujos de trabajo clínico de múltiples pasos que van más allá del llenado de formularios -- lógica de triaje, chat en tiempo real con clínicos, árboles de soporte para decisiones. Desarrollo personalizado.
- Si tu auditor quiere que cada byte de PHI viva dentro de tu VPC. JotForm es la llamada correcta cuando delegar a un proveedor auditado por HIPAA es aceptable; es la llamada incorrecta cuando tu modelo de seguridad exige aislamiento.
Integraciones de Terceros: Donde el Cumplimiento va a Morir
Todo tercero que integres y que toque información de salud protegida (PHI) necesita un BAA. Suena obvio. Aquí está la lista que realmente confunde a los equipos:
- Herramientas de atención al cliente (Intercom, Zendesk) -- si un paciente envía un mensaje sobre su salud, esa es información protegida (PHI) en tu plataforma de soporte
- Herramientas de formularios (Typeform, Jotform) -- los formularios de admisión de pacientes son PHI
- Proveedores de correo electrónico (SendGrid, Postmark) -- si el cuerpo del correo contiene información de salud, se requiere BAA
- Herramientas de feature flags (LaunchDarkly, Statsig) -- normalmente están bien, pero si estás pasando 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 (a través de Twilio) también lo hará, en planes pagos. Twilio para SMS también. LaunchDarkly tiene una ruta de BAA. Estas no son opciones oscuras -- el proceso de BAA suele ser un envío de formulario y unos pocos días hábiles.
¿Los que no firmarán o no pueden firmar un BAA? No los integres cerca de PHI. Así de simple.
---
FAQ
¿Cuál es el costo real del BAA de HIPAA de Vercel?
El Acuerdo de Asociado de Negocio de HIPAA de Vercel está disponible en el plan Pro como un complemento de $350/mes, firmado mediante un click-through de autoservicio en el panel. SAML SSO en Pro es un complemento separado de $300/mes, llevando una configuración de cumplimiento típica a $650/mes combinados. El plan Enterprise, que ronda los $45,000/año en la mediana, incluye el BAA, SSO, y Secure Compute (redes aisladas, IPs dedicadas, peering de VPC).
¿Puedo ejecutar un sitio WordPress compatible con HIPAA?
Sí, en un host elegible para HIPAA que firme un BAA. Las cuatro opciones comunes en 2026 son Atlantic.Net (desde $350/mes), Liquid Web (desde $600/mes), HIPAA Vault (diseñado específicamente para salud), y ScalaHosting managed VPS (desde $29.95/mes). La ruta de WordPress es la correcta para sitios de marketing de salud, sitios de clínicas, y contenido de mucho texto. Deja de funcionar cuando necesitas paneles de pacientes autenticados, datos en tiempo real, o algo que supere los 100 plugins de superficie de ataque.
¿Es JotForm suficiente para formularios compatibles con HIPAA?
Si los formularios son el único punto de contacto con PHI, sí. JotForm Gold a $99/mes incluye HIPAA sin costo adicional -- BAA firmado, 100 formularios, 10,000 envíos, 100 GB de almacenamiento. El PHI se recopila en la infraestructura auditada por HIPAA de JotForm, incrustada por iframe en tu sitio. JotForm deja de ser suficiente cuando tu producto necesita leer PHI nuevamente entre sesiones, renderizar cronogramas de pacientes, o ejecutar flujos de trabajo clínicos de múltiples pasos.
¿Cuándo la ruta de WordPress supera la ruta de Next.js para HIPAA?
Cuando tu producto de salud es un sitio de marketing más un blog más un formulario de entrada. WordPress es más rápido de desplegar, más barato de alojar, y el flujo de trabajo editorial ya está resuelto para el personal no técnico. La ruta de Next.js gana cuando necesitas autenticación, paneles personalizados, datos en tiempo real, características de IA, o cualquier cosa que se beneficie de una arquitectura de aplicación moderna. Un híbrido común: WordPress en un host HIPAA administrado para el sitio público, Next.js en Vercel BAA para la aplicación autenticada, JotForm para el formulario de entrada.
¿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 de HIPAA para la infraestructura que controla. Pero el código de tu aplicación, el diseño de tu base de datos, tus registros, tus integraciones de terceros -- nada de eso está cubierto por el BAA de Vercel. El cumplimiento se comparte en cada capa de la pila, y la capa de aplicación es tu responsabilidad.
¿Necesito encriptar datos en una ruta 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 PHI mínimo necesario para la operación -- no registros completos del paciente cuando solo necesitas un nombre, por ejemplo. El principio de "mínimo necesario" está integrado en HIPAA y debe moldear el diseño de tu respuesta de API desde el primer día.
¿Es seguro el caché integrado del App Router de Next.js para PHI?
No por defecto. El Data Cache y Full Route Cache en App Router pueden cachear respuestas que contienen PHI, lo cual es problemático. Para cualquier ruta o llamada fetch que acceda a datos de pacientes, usa { cache: 'no-store' } en llamadas fetch y añade export const dynamic = 'force-dynamic' a los segmentos de ruta. Revisa cuidadosamente la documentación de caché de Vercel — es densa pero importante.{ cache: 'no-store' }on fetch calls and add export const dynamic = 'force-dynamic'to route segments. Review Vercel's caching documentation carefully -- it's dense but important.
¿Cuál es el logging mínimo que necesito para una auditoría HIPAA?
Como mínimo: quién accedió a qué, cuándo y desde dónde. Es decir, ID de usuario, identificador de recurso, tipo de acción, timestamp e dirección IP. Los logs necesitan ser a prueba de manipulación (solo agregar, 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 librerías cachean respuestas del lado cliente, lo que significa que PHI puede permanecer en la memoria del navegador. Establece staleTime: 0 y cacheTime: 0 (React Query) o dedupingInterval: 0 (SWR) para consultas que devuelven PHI. También limpia explícitamente el caché de consultas al cerrar sesión — no confíes en que el desmontaje de componentes maneje esto.staleTime: 0 and cacheTime: 0(React Query) or dedupingInterval: 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: cumplir HIPAA es genuinamente difícil hacerlo correctamente, y ningún framework — Next.js u otro — lo hace fácil. Los equipos que lo hacen bien son quienes lo tratan como un problema arquitectónico desde el día uno, no como una lista de verificación que ejecutar antes del lanzamiento. El framework está bien. Las brechas casi siempre están en las decisiones tomadas alrededor de él.
Comienza con el mapeo de la superficie de PHI. Todo lo demás se desprende de eso.
Lecturas relacionadas
Pilas de hosting que realmente firman BAA de HIPAA en 2026 — el post de comparación de hosting más profundo, con rangos de costo anual y notas de alcance de BAA para cada proveedor. -- the deeper hosting comparison post, with annual cost ranges and BAA scope notes for each provider.
WordPress vs Next.js: cuándo cada uno es la llamada correcta — la decisión de framework sin el encuadre de HIPAA, útil como el preludio. -- the framework decision without the HIPAA framing, useful as the prequel.
WordPress sin cabeza + Astro: una configuración que funciona — si tomas el camino de WordPress pero quieres un front end público moderno. -- if you take the WordPress path but want a modern public front end.
WordPress Stack Advisor — pega tu URL, obtén una recomendación personalizada que incluya la ruta de HIPAA que se ajuste a tu caso en 30 segundos. -- paste your URL, get a tailored recommendation that includes the HIPAA path that fits your brief in 30 seconds.
Si estás a punto de lanzar un producto de salud y no puedes determinar cuál de los tres caminos anteriores es el correcto para tu especificación, los próximos treinta minutos lo resolverán.
Reserva una llamada de stack HIPAA de 30 minutos — describes el producto, te digo si la respuesta es Next.js + Vercel BAA, WordPress en un host manejado con HIPAA, JotForm, o un híbrido. Al final de la llamada tienes una elección de stack, un rango de precio y una ruta de migración si ya estás en el stack incorrecto. -- you describe the product, I tell you whether the answer is Next.js + Vercel BAA, WordPress on a managed HIPAA host, JotForm, or a hybrid. By the end of the call you have a stack pick, a price range, and a migration path if you are already on the wrong stack.