Tu sitio WordPress es una auditoría HIPAA esperando ocurrir

Por qué las organizaciones de salud están abandonando WordPress

WordPress fue construido para blogs. Luego se estiró hasta abarcar todo lo demás mediante plugins. Cuando manejas Información de Salud Protegida (PHI, por sus siglas en inglés), esa arquitectura dependiente de plugins deja de ser una molestia y se convierte en una responsabilidad legal.

Esto es lo que vemos repetidamente cuando las organizaciones de salud acuden a nosotros:

• Entornos de hosting compartido donde los datos de tus pacientes residen en el mismo servidor que el blog personal de alguien
• Proliferación de plugins que crean superficies de ataque: cada plugin de formulario de contacto, cada herramienta de analítica, cada capa de caché es una posible violación de HIPAA
• Sin registro de auditoría a nivel de infraestructura: no puedes demostrar quién accedió a qué PHI ni cuándo
• Renderizado monolítico que expone datos del lado del servidor al caché del lado del cliente, nodos perimetrales de CDN y almacenamiento del navegador
• Sin Acuerdo de Socio Comercial (BAA) por parte de la mayoría de los proveedores de hosting para WordPress

Las infracciones de HIPAA conllevan multas de hasta 1,9 millones de dólares por incidente. Operar un sitio web de salud en una plataforma que no puede ofrecer garantías de cifrado, controles de acceso ni trazas de auditoría no es un problema de deuda técnica: es una emergencia de cumplimiento normativo.

Qué te ofrece una arquitectura headless con Next.js

Next.js combinado con un CMS headless auto-alojado cambia fundamentalmente cómo tu sitio web de salud gestiona los datos. En lugar de una instalación monolítica de WordPress donde el contenido, la lógica y la PHI conviven en un único paquete vulnerable, obtienes una arquitectura separada en la que cada capa puede asegurarse y auditarse de forma independiente.

Renderizado en el servidor para la protección de PHI

Esta es la decisión arquitectónica crítica. La PHI nunca debe generarse de forma estática. La Generación de Sitios Estáticos (SSG) y la Regeneración Estática Incremental (ISR) almacenan contenido en caché en tiempo de compilación y lo sirven desde nodos perimetrales de CDN: eso es una pesadilla de cumplimiento para los datos de pacientes.

El Renderizado en el Servidor (SSR) de Next.js con verificaciones de autorización por solicitud significa que cada carga de página verifica la identidad y los permisos del usuario antes de renderizar cualquier PHI. Configuramos Cache-Control: no-store en todas las rutas sensibles. La PHI nunca toca el CDN. Nunca reside en un archivo HTML estático en un servidor de compilación.

La arquitectura HIPAA de cuatro capas

Todos los despliegues de salud que construimos siguen este patrón:

1. Cifrado — AES-256 en reposo, TLS 1.2+ en tránsito. Cifrado a nivel de base de datos más tráfico de API cifrado entre tu CMS, el frontend de Next.js y cualquier integración.
2. Control de acceso — Visibilidad basada en roles. Los médicos ven datos distintos a los de las enfermeras; los pacientes ven datos distintos a los de los administradores. Implementado a nivel de middleware en Next.js y aplicado a nivel de base de datos.
3. Registro de auditoría — Registros inmutables y a prueba de manipulaciones de cada evento de acceso a PHI. Quién accedió, cuándo, desde qué IP, qué visualizó o modificó.
4. Aislamiento de copias de seguridad — Copias cifradas almacenadas en la misma jurisdicción que los datos primarios. Fundamental para la superposición con el RGPD y las normativas de salud a nivel estatal.

Selección de CMS headless para el sector salud

El cumplimiento de HIPAA no es una característica del CMS: es una estrategia de despliegue. Dicho esto, la elección del CMS sigue siendo importante.

Trabajamos principalmente con Payload CMS y Strapi en proyectos de salud. Ambos son de código abierto, auto-alojados y te ofrecen control total sobre tu capa de datos.

Payload CMS es nuestra opción preferida para la mayoría de los proyectos de salud. Defines reglas de acceso, modelos de datos y flujos de autenticación íntegramente en código. Tu configuración de cumplimiento está versionada, es auditable y reproducible. Sin tener que hacer clic en paneles de administración esperando que la configuración se guarde.

Strapi funciona bien para organizaciones que necesitan una interfaz de administración más accesible para editores de contenido no técnicos, mientras mantiene permisos granulares basados en roles bajo el capó.

Las plataformas SaaS exclusivamente en la nube como Contentful e Hygraph no ofrecen BAAs de HIPAA para despliegues estándar. Si tu sistema de contenido toca PHI —incluso nombres de pacientes asociados a testimonios o confirmaciones de citas—, las plataformas CMS headless SaaS quedan descartadas.

Formularios seguros de admisión de pacientes

Los formularios de admisión de pacientes son el punto por donde la PHI entra en tu sistema. Son el componente de mayor riesgo de cualquier sitio web de salud.

Cómo los construimos

• Validación solo en el servidor — La validación del lado del cliente es para la experiencia de usuario. La del lado del servidor es para la seguridad. Nunca confiamos en el navegador.
• Protección CSRF — La verificación de envío de formularios basada en tokens previene la falsificación de solicitudes entre sitios.
• Cero almacenamiento de PHI en el cliente — Sin localStorage, sin sessionStorage, sin cookies que contengan datos de pacientes. Los datos del formulario van directamente a un endpoint de API cifrado.
• Subida de archivos cifrada — Las tarjetas de seguro, historiales médicos y documentos de derivación se validan en el servidor (no por extensión), se analizan en busca de malware y se almacenan en S3 cifrado o Azure Blob Storage con URLs de descarga de tiempo limitado.
• MFA para operaciones sensibles — Autenticación reforzada cuando los pacientes modifican registros de salud críticos o envían nuevos formularios de admisión.

Supabase: la realidad con matices

Supabase surge con frecuencia en contextos de salud. Seamos directos: Supabase no cumple con HIPAA de forma predeterminada. Carece de la especificidad en el registro de auditoría, los acuerdos BAA y los controles de residencia de datos que requiere el manejo de PHI.

Para componentes que no involucran PHI —páginas de marketing, contenido del blog, frontends de programación de citas que no almacenan datos de pacientes—, Supabase funciona perfectamente. Para cualquier elemento que toque PHI, desplegamos PostgreSQL auto-gestionado en infraestructura cloud apta para HIPAA (AWS RDS con cifrado habilitado, o GCP Cloud SQL) donde controlamos las claves de cifrado, los registros de auditoría y las políticas de acceso.

Accesibilidad WCAG AA

Los sitios web de salud tienen la obligación legal y ética de ser accesibles. Muchos de nuestros clientes del sector salud atienden a poblaciones de edad avanzada, usuarios con baja visión y pacientes que acceden a formularios en situaciones de estrés.

Todos los componentes que construimos cumplen los estándares WCAG AA:

• Relaciones de contraste de color 4,5:1 en todo el texto, especialmente en etiquetas de formularios y mensajes de error
• Navegación completa por teclado — cada campo de formulario, botón y elemento interactivo es accesible mediante Tab, Enter y las teclas de flecha
• HTML semántico — <label>, <fieldset>, <legend> para la estructura de formularios; jerarquía de encabezados correcta en todo el sitio
• Etiquetas ARIA en todos los campos de entrada de PHI para que los lectores de pantalla comuniquen claramente qué datos se están solicitando
• Skip links para que los usuarios puedan saltarse la navegación y acceder directamente a los formularios de admisión
• Probado con NVDA y JAWS lectores de pantalla, no solo con herramientas automatizadas

La accesibilidad y la seguridad no están reñidas: se refuerzan mutuamente. Los campos de formulario correctamente etiquetados reducen los errores de los usuarios. El HTML semántico reduce tu superficie de ataque en comparación con una sopa de divs sostenida por manejadores de eventos JavaScript.

Nuestro proceso de migración

Fase 1: Auditoría de PHI y arquitectura (semanas 1-2)

Inventariamos dónde entra, fluye y sale la PHI de tu sistema WordPress actual. Cada plugin, cada formulario, cada notificación por correo electrónico, cada píxel de analítica. Clasificamos los datos por sensibilidad e identificamos los componentes no conformes.

Fase 2: Configuración de infraestructura (semanas 2-3)

Despliegue de infraestructura cloud apta para HIPAA. CMS headless auto-alojado con cifrado, RBAC y registro de auditoría desde el primer día. Firma del BAA con el proveedor de hosting.

Fase 3: Migración de contenido (semanas 3-5)

Exportación del contenido de WordPress, mapeo al nuevo esquema del CMS headless y verificación de que no existe PHI en exportaciones sin cifrar. El contenido y los datos de usuarios se migran por separado con diferentes protocolos de seguridad.

Fase 4: Construcción del frontend (semanas 4-8)

Frontend con Next.js y SSR para todas las páginas que contienen PHI, middleware de autorización por solicitud, cumplimiento WCAG AA y formularios seguros de admisión de pacientes.

Fase 5: Autenticación e integración (semanas 7-9)

Implementación de MFA, gestión de sesiones, RBAC en el middleware de Next.js e integración con sistemas EHR/EMR existentes a través de HL7 FHIR donde corresponda.

Fase 6: Verificación de cumplimiento (semanas 9-11)

Pruebas de penetración, auditoría de seguridad, auditoría de accesibilidad y documentación completa de cumplimiento normativo.

Estrategia de preservación del SEO

Los sitios web de salud suelen posicionarse para consultas locales y específicas por condición de alto valor. Protegemos cada posición:

• Mapeo completo de URLs con redirecciones 301 desde cada URL de WordPress a su equivalente en Next.js
• Preservación del marcado de esquema — datos estructurados de Medical Organization, Physician y MedicalClinic migrados y mejorados
• Mejora de Core Web Vitals — pasar de WordPress (Lighthouse típico de 45-65) a Next.js (95-100) mejora directamente las señales de posicionamiento
• Reducción del TTFB — de 1,2-2,5 segundos en WordPress a menos de 300 ms en Next.js
• Generación de sitemaps XML y monitoreo en Google Search Console durante toda la migración

Plazos e inversión

Las migraciones en el sector salud son proyectos a medida. Los requisitos de cumplimiento, las integraciones con EHR y las reglas de manejo de PHI hacen que los enfoques basados en plantillas sean imposibles.

Plazo típico: 10-14 semanas para una migración completa a producción incluyendo la verificación de cumplimiento.

Rango de inversión: entre 35.000 y 85.000 dólares según el número de formularios de admisión, integraciones con EHR, roles de usuario y volumen de contenido. Las organizaciones con configuraciones multi-sede complejas o requisitos de portal para pacientes se acercan al extremo superior.

Esto no es un cambio de tema de WordPress. Es una reconstrucción desde cero de tu presencia web en el sector salud sobre una infraestructura que realmente puede proteger los datos de los pacientes.