La Brecha de SimonMed: Lo Que Debes Tener en Orden Antes de Lanzar Cualquier App con Datos de Salud

SimonMed Imaging es una de las redes de diagnóstico por imagen más grandes de Estados Unidos. Cientos de ubicaciones. Millones de estudios. Y a principios de 2025, reportó una brecha de datos que expuso la información personal y médica de cientos de miles de pacientes.

La brecha de datos médicos no fue un titular más. El tipo de datos expuesto es el que no deja de ser sensible después de un año.

Qué pasó en SimonMed

Los atacantes tuvieron acceso a los sistemas de SimonMed entre finales de 2024 y principios de 2025. Lo que encontraron dentro incluía:

• Nombres completos y fechas de nacimiento
• Números de Seguro Social (SSNs)
• Datos de planes de seguro médico
• Información sobre diagnósticos y tratamientos
• Datos de contacto y direcciones

Toda esta información cae bajo la categoría de PHI (Protected Health Information) — la categoría regulatoria que hace que las brechas en salud sean particularmente costosas, legalmente y reputacionalmente.

SimonMed lo reportó al HHS (Department of Health & Human Services). Eso no es opcional. Bajo HIPAA, cuando una brecha afecta a 500 o más personas, la notificación al HHS es obligatoria — y debe hacerse en 60 días desde el descubrimiento de la brecha.

Por qué los datos médicos son diferentes

Las contraseñas se pueden cambiar. Los números de tarjeta de crédito también. Los registros médicos, no.

Tu número de Seguro Social es tuyo para toda la vida. Tu historial de diagnósticos no expira. Una sola brecha puede habilitar fraude de identidad durante años. Fraude de seguros médicos. Phishing dirigido usando información que solo debería saber tu médico.

Es por eso que el sector salud es uno de los más atacados. Los registros médicos valen más en el mercado negro que los datos financieros precisamente porque tienen vida larga y son imposibles de revocar.

Cuando escaneas repositorios de healthcare, el patrón es consistente: los developers tratan PHI con la misma mentalidad que datos de perfil de usuario. Pero no es lo mismo, ni legalmente ni en términos de impacto real.

El ángulo del developer: ¿cuándo aplica esto a tu app?

Puede que no estés construyendo un EHR (Electronic Health Record). Pero la pregunta correcta no es "¿es mi app un sistema médico?" — la pregunta es "¿qué datos estoy almacenando?"

Bajo HIPAA, si tu app maneja cualquiera de estos campos y los vincula a usuarios identificables, probablemente estás manejando PHI:

• Datos de citas médicas (fecha, proveedor, tipo de consulta)
• IDs de pólizas de seguro o planes de salud
• Campos de diagnóstico, síntomas o condiciones
• Cualquier campo que vincule a un usuario con un proveedor de salud
• Registros de medicamentos o tratamientos

Si estás en zona gris, la respuesta no es ignorarlo — es hablar con un abogado especializado en HIPAA antes de lanzar. El costo de una consulta es órdenes de magnitud menor al costo de una multa.

Cómo se ve PHI en una base de datos

Acá está el tipo de schema que los developers arman sin pensar dos veces:

-- BAD: tabla de citas sin protecciones
CREATE TABLE appointments (
  id          uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id     uuid NOT NULL,
  provider    text NOT NULL,
  date        date NOT NULL,
  diagnosis   text,
  notes       text,
  insurance_id text,
  created_at  timestamptz DEFAULT now()
);
-- Sin RLS. Sin cifrado de columnas sensibles.
-- Sin logs de auditoría. Cualquier rol puede leer todo.

Esta tabla almacena PHI. Con diagnósticos, notas clínicas e IDs de seguro, cualquier exposición de esta tabla es una brecha HIPAA.

Lo que necesita esa misma tabla bajo los requisitos mínimos:

-- GOOD: tabla de citas con controles básicos
CREATE TABLE appointments (
  id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id      uuid NOT NULL REFERENCES auth.users(id) ON DELETE CASCADE,
  provider     text NOT NULL,
  date         date NOT NULL,
  diagnosis    text,    -- considerar pgcrypto para cifrado de columna
  notes        text,    -- ídem
  insurance_id text,
  created_at   timestamptz DEFAULT now()
);
 
-- RLS habilitado: nadie puede leer sin permiso explícito
ALTER TABLE appointments ENABLE ROW LEVEL SECURITY;
 
-- Solo el dueño del registro puede verlo
CREATE POLICY "patient_own_appointments"
  ON appointments
  FOR ALL
  USING (auth.uid() = user_id);
 
-- Los proveedores autorizados solo ven sus citas asignadas
CREATE POLICY "provider_assigned_appointments"
  ON appointments
  FOR SELECT
  USING (
    EXISTS (
      SELECT 1 FROM provider_access pa
      WHERE pa.provider_id = auth.uid()
        AND pa.appointment_id = appointments.id
    )
  );

Y para el log de auditoría — el registro de quién accedió a qué y cuándo — necesitás algo así:

-- Tabla de auditoría para accesos a PHI
CREATE TABLE phi_audit_log (
  id           uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  accessor_id  uuid NOT NULL,
  table_name   text NOT NULL,
  record_id    uuid NOT NULL,
  action       text NOT NULL, -- SELECT, UPDATE, DELETE
  accessed_at  timestamptz DEFAULT now()
);
 
-- Solo inserts, nunca updates ni deletes en audit logs
ALTER TABLE phi_audit_log ENABLE ROW LEVEL SECURITY;
CREATE POLICY "append_only_audit"
  ON phi_audit_log
  FOR INSERT
  WITH CHECK (auth.uid() = accessor_id);

Los logs de auditoría son append-only por diseño. Nadie debería poder borrar o modificar un registro de auditoría — ni siquiera el admin.

El checklist mínimo de HIPAA para developers

Si tu app toca PHI, esto no es opcional. Es el piso mínimo:

Cifrado en reposo Supabase y la mayoría de los servicios PostgreSQL hosteados lo tienen habilitado por defecto. Pero "habilitado por defecto" no es lo mismo que "verificado explícitamente". Revisa con tu proveedor que el cifrado en reposo esté activo y documéntalo.

Cifrado en tránsito TLS en todo. Sin excepciones. Sin HTTP. Si tu app llama a un endpoint interno sin TLS, ese tráfico puede ser interceptado.

Controles de acceso con RLS Como mostramos arriba, RLS en PostgreSQL/Supabase es tu primera línea de defensa. Cada tabla con PHI necesita políticas explícitas. El default es denegar todo.

Cuentas de servicio con mínimo privilegio Tu worker de backend no necesita permisos de SUPERUSER. Tu API de lectura no necesita permisos de escritura. Asigná el mínimo privilegio necesario para cada operación.

Logs de auditoría HIPAA requiere que puedas responder: ¿quién accedió a los datos de este paciente, cuándo, y desde dónde? Si no tenés eso registrado, no podés demostrarlo en una auditoría.

BAA firmado con cada proveedor SaaS Acá está el gap que la mayoría de los developers no sabe que tiene.

El gap del BAA que nadie te dice

Si usás Supabase, Vercel, Resend, AWS, o cualquier otro servicio SaaS para almacenar o procesar PHI, necesitás un BAA (Business Associate Agreement) firmado con cada uno de ellos.

Un BAA es básicamente un contrato donde el proveedor acepta sus obligaciones bajo HIPAA y asume responsabilidad por proteger la PHI que manejan en tu nombre. Sin ese contrato firmado, si hay una brecha de su lado, la responsabilidad legal cae sobre vos.

Algunos proveedores ofrecen BAAs:

Si estás procesando PHI en producción y no tenés BAAs firmados, no estás cumpliendo HIPAA — aunque todo lo demás esté bien implementado.

Notificación de brecha HIPAA requiere notificar al HHS y a los pacientes afectados dentro de los 60 días de descubrir la brecha. Si afecta a más de 500 personas en un estado, también hay notificación a medios. Tener este proceso documentado antes de necesitarlo es parte del cumplimiento.

Lo que la brecha de SimonMed le dice a cualquier developer de healthcare

SimonMed no es una startup de un developer solo. Es una empresa con recursos, equipos de IT, y procesos establecidos. Y aún así, los atacantes tuvieron acceso durante meses.

Eso no debería paralizarte — debería decirte que la seguridad en healthcare no es un estado que alcanzás y mantenés para siempre. Es un proceso continuo: auditorías, revisiones de acceso, monitoreo de anomalías.

Como developer, tu trabajo es asegurarte de que las capas técnicas que dependen de vos estén bien implementadas. RLS, cifrado, logs de auditoría, BAAs. El resto — detección de intrusiones, respuesta a incidentes, formación del equipo — también importa, pero empieza por lo que controlás directamente.

Si tu app toca datos de salud y querés saber si tenés PHI hardcodeada, políticas RLS faltantes en tablas críticas, o patrones de seguridad que no están a la altura, Data Hogo escanea tu repo y te muestra exactamente qué está expuesto — sin que tengas que ir archivo por archivo.

TL;DR

• SimonMed Imaging reportó una brecha que expuso SSNs, datos de seguros e historiales médicos de cientos de miles de pacientes.
• Los datos médicos no rotan como contraseñas — una brecha hoy puede habilitar fraude de identidad durante años.
• HIPAA aplica si tu app almacena PHI, aunque no seas un hospital. Los campos de citas, IDs de seguros y diagnósticos cuentan.
• El checklist mínimo: cifrado en reposo, TLS en tránsito, RLS en todas las tablas con PHI, logs de auditoría append-only, y BAAs firmados con cada proveedor SaaS.
• El gap más común que los developers no saben que tienen: usar Supabase o Vercel para PHI sin un BAA firmado.
• HIPAA requiere notificar al HHS y a los pacientes en 60 días desde el descubrimiento de la brecha — no desde que la publicás.
• Data Hogo puede escanear tu repo en busca de PHI hardcodeada y políticas RLS faltantes en tablas de salud.