Qué es Patient Privacy Monitoring y por qué toda app de salud debería tenerlo

Cuando se habla de seguridad en aplicaciones médicas, casi todo el mundo piensa en lo mismo: cifrado, MFA, HTTPS, BAA con el proveedor de infraestructura. Todo eso es necesario. Pero hay una capa que casi nadie discute públicamente y que, sin embargo, es la que más brechas reales detiene en el día a día.

La pregunta incómoda no es "¿están los datos cifrados?". Es:

¿Si te llamamos ahora mismo y te preguntamos quién accedió a la historia clínica de Juan Pérez en los últimos 30 días, podés respondernos en menos de un minuto?

Para responder esa pregunta existe una categoría de sistemas con nombre propio en la industria: Patient Privacy Monitoring, una aplicación específica de UEBA (User & Entity Behavior Analytics) al contexto sanitario. En este artículo te contamos qué es, por qué HIPAA lo exige, cómo funciona técnicamente y cómo lo implementamos en Brauni.

El verdadero perfil de amenaza en salud

Cuando uno imagina una brecha de datos médicos, piensa en un hacker encapuchado tipeando comandos en un teclado oscuro. La realidad es bastante menos cinematográfica.

Según los reportes anuales del OCR (Office for Civil Rights, el regulador HIPAA en EE. UU.) y de Verizon DBIR, la mayoría de los incidentes de PHI no vienen de un atacante externo rompiendo cifrado. Vienen de cuentas legítimas haciéndose preguntas que no deberían:

• Un empleado curioso revisando el legajo de un paciente conocido o famoso
• Una cuenta comprometida exportando 200 fichas a las 3 de la mañana
• Un ex-trabajador con sesión activa que nadie revocó al darlo de baja
• Alguien probando cambiar IDs en la URL para ver qué se le devuelve (lo que en seguridad se llama un IDOR, Insecure Direct Object Reference)
• Un terapeuta accediendo a expedientes que no son de sus pacientes asignados

Ninguna de estas amenazas se detiene con cifrado. El cifrado protege contra alguien que se mete por la fuerza. No protege contra alguien que tiene la llave.

¿Qué es Patient Privacy Monitoring?

Es una categoría de sistemas dedicada a observar cómo se usan los datos clínicos desde adentro de la aplicación y detectar patrones que se alejan de lo normal. En la literatura técnica se lo conoce con varios nombres según el ángulo:

• UEBA (User & Entity Behavior Analytics): el paraguas grande, usado por Gartner y proveedores como Splunk, Exabeam o Microsoft Sentinel
• Patient Privacy Monitoring o Patient Privacy Intelligence (PPI): el nombre que usan los proveedores especializados en salud (Protenus, Imprivata FairWarning, Maize Analytics)
• Insider Threat Detection & Response (ITDR): el nombre desde el ángulo de ciberseguridad pura
• Audit log monitoring: el nombre técnico y más antiguo, sin sabor a marketing

En el lenguaje de HIPAA, este tipo de sistema cubre tres requisitos formales:

No es opcional. Es ley.

Cómo funciona: las nueve preguntas que se hace el sistema

En Brauni, cada acceso a información de salud protegida (PHI) queda registrado en un log inmutable de auditoría. Sobre ese log, un motor de detección ejecuta nueve reglas en paralelo, cada una respondiendo una pregunta concreta:

1. ¿Alguien está probando cambiar IDs en la URL? (IDOR_ATTEMPT)

Severidad: HIGH

Si una cuenta acumula varios eventos ACCESS_DENIED en una ventana corta, probablemente esté probando manualmente cambiar IDs de pacientes para ver cuáles le contestan. Es el patrón clásico de descubrimiento de IDOR (Insecure Direct Object Reference). La regla agrupa los denied por user_id y dispara cuando cruza un umbral.

2. ¿Alguien está abriendo demasiadas historias en poco tiempo? (BULK_ACCESS)

Severidad: HIGH

Un terapeuta normal revisa entre 5 y 20 expedientes por día, los suyos. Si una cuenta abre 30+ historias clínicas distintas en una ventana corta, algo no está bien. Puede ser un scraper, una cuenta comprometida o un empleado curioseando. La regla cuenta pacientes distintos (no accesos repetidos al mismo paciente, eso es uso normal).

3. ¿Alguien está exportando masivamente? (BULK_EXPORT)

Severidad: CRITICAL

Exportar es la operación más peligrosa: saca PHI del perímetro controlado de la app y la convierte en un archivo que puede vivir en cualquier disco. Una sola exportación legítima es normal. Diez en una hora es una señal de alarma roja. Por eso esta regla es la única con severidad CRITICAL.

4. ¿Hay un ataque de fuerza bruta? (LOGIN_BURST)

Severidad: MEDIUM

Detecta cuando una sola IP acumula muchos fallos de login. La sutileza técnica importante: esta regla no se indexa por usuario sino por IP de origen, porque un ataque de fuerza bruta o de credential stuffing dispara muchos intentos distintos: a veces contra emails que ni existen, a veces con la contraseña incorrecta de un usuario que sí existe. Por eso agrupa los intentos fallidos por IP independientemente de si el email corresponde a un usuario real o no, y es la única regla del motor que no necesita un user_id válido para disparar.

5. ¿La cuenta hizo "teletransporte"? (IMPOSSIBLE_TRAVEL)

Severidad: HIGH

Si la misma cuenta inicia sesión en Buenos Aires a las 14:00 y diez minutos después en Madrid, hay un problema físico: nadie viaja a 60.000 km/h. El sistema calcula la velocidad implícita entre dos sesiones consecutivas y dispara cuando supera un umbral configurable. Es uno de los indicadores más fuertes de cuenta comprometida.

6. ¿La cuenta entró desde un país nuevo? (NEW_GEO)

Severidad: MEDIUM

Una cuenta que históricamente solo entró desde Argentina y de pronto inicia sesión desde Rumania merece una revisión. No siempre es ataque (puede ser un viaje), pero merece atención.

7. ¿Es un dispositivo nuevo? (NEW_DEVICE)

Severidad: MEDIUM

Brauni asigna un identificador estable a cada dispositivo (cookie firmada + huella mínima). Si una cuenta usa un dispositivo que nunca vio antes, queda registrado como evento. Útil para detectar cuentas compartidas o sesiones secuestradas.

8. ¿Hubo acceso fuera de horario? (OFF_HOURS)

Severidad: LOW

Una lectura de PHI a las 3 de la mañana no es necesariamente sospechosa, pero es información útil para correlacionar. Si además se cruza con IMPOSSIBLE_TRAVEL o BULK_ACCESS, la puntuación total sube.

9. ¿La cuenta está en proceso de baja? (AFTER_TERMINATION)

Severidad: LOW

Si un usuario tiene fecha de baja agendada y sigue accediendo a PHI, queda flagged. Es una de las amenazas más comunes y peor cubiertas: el ex-empleado con sesión viva.

Cómo se combinan: scoring agregado

Cada regla suma puntos a un score por ventana de tiempo. Una sola regla LOW no escala. Tres LOW + una MEDIUM en la misma ventana puede cruzar el umbral global de alerta y marcar el evento como alerted=true, que es lo que dispara la notificación al panel admin y a CloudWatch.

Esto evita dos extremos malos: fatiga de alertas (todo es urgente, entonces nada lo es) y subdetección (cada regla por separado no alarma, pero la suma debería).

Break-glass auditing: la otra mitad del problema

Detectar lo sospechoso es solo la mitad del trabajo. La otra mitad es poder reconstruir la historia después.

En cualquier institución de salud hay momentos en que se necesita romper la regla normal de acceso: una emergencia, una investigación interna, una orden judicial. Esto se llama break-glass access, "romper el vidrio". HIPAA lo permite, pero exige que quede registrado quién lo hizo y cuándo.

Brauni expone una vista de break-glass por paciente. Dado un patient_id, devuelve quién accedió a su historia clínica, en qué fecha y hora, desde qué IP, desde qué dispositivo, y qué operación realizó (READ, EXPORT, UPDATE...).

El problema del observador observado

Hay un detalle técnico fácil de pasar por alto que aprendimos rápido: el sistema que mira también tiene que ser mirado.

Cuando un administrador consulta la timeline de un paciente, esa consulta es en sí misma un acceso a PHI. Si no se audita, el panel admin se vuelve el único lugar donde se puede acceder a datos sin dejar rastro. Eso es exactamente el agujero que el sistema viene a tapar.

En Brauni, cada consulta de break-glass:

1. Se registra como un audit log propio (READ sobre audit_timeline)
2. Se excluye de sus propias estadísticas de detección, para que un administrador investigando 30 timelines distintas no se autoincrimine con un BULK_ACCESS
3. Valida la existencia del paciente antes de escribir, para evitar logs "fantasma" sobre pacientes que no existen

Respuesta inmediata: cuatro acciones desde el panel

Detectar es necesario pero no suficiente. Si el administrador ve una alerta CRITICAL a las 2 de la mañana, necesita actuar ahora, no abrir tres pestañas distintas.

Por eso desde el evento mismo se pueden disparar cuatro acciones de respuesta:

1. Revocar todas las sesiones del usuario - invalida el JWT activo (bump del token_version) y borra todos los refresh tokens. La próxima request del atacante recibe un 401.
2. Resetear el 2FA - borra TOTP, WebAuthn y backup codes. El usuario legítimo va a tener que reconfigurar; el atacante con la clave física robada queda fuera.
3. Desbloquear cuenta - útil en el escenario inverso: tras un LOGIN_BURST accidental sobre la cuenta de un usuario legítimo.
4. Forzar reseteo de contraseña - dispara el flujo de email con link de cambio obligatorio.

Cada acción exige confirmación explícita (confirm: true), CSRF token y deja una traza en el evento. Un administrador no puede actuar sobre su propio user_id (auto-defensa contra cuentas admin comprometidas).

Lifecycle del evento

Un evento pasa por estados: OPEN → ACKNOWLEDGED → RESOLVED o FALSE_POSITIVE. La primera acción exitosa lo mueve automáticamente a ACKNOWLEDGED (así el equipo ve que alguien lo está trabajando). Un evento cerrado rechaza nuevas acciones hasta que un admin lo reabra. Esto evita "reabrir la herida" sin querer después de que el incidente se cerró formalmente.

Cómo encaja en la arquitectura de Brauni

El sistema corre en dos planos:

• Plano de captura: cada operación sobre PHI escribe un AuditLog en una tabla append-only. Esto sucede de forma sincrónica con la request del usuario, en la misma transacción: es una decisión deliberada para garantizar atomicidad (si el acceso no queda registrado, el cambio sobre la PHI tampoco se concreta) y cero pérdida de eventos por caída del worker. El costo es una escritura extra en el camino crítico de cada request; si el volumen llegara a justificarlo, el paso natural es derivar ese registro a una cola persistente intermedia, sin resignar durabilidad ni inmutabilidad.
• Plano de detección: un job de APScheduler corre el motor de detección sobre ventanas de tiempo configurables. Lo ejecuta el proceso worker (separado de la API), con leader election por advisory lock de PostgreSQL para que solo una instancia lo corra a la vez aun cuando haya varias réplicas.

Cada evento detectado emite además una métrica a CloudWatch vía metric filter, que dispara alarmas SNS hacia el equipo de guardia. Así un evento CRITICAL no depende de que alguien esté mirando el panel a las 3 de la mañana: el panel notifica al teléfono, no al revés.

Los datos del sistema de monitoreo no contienen PHI: solo IDs internos, IPs, geolocalización, identificadores de dispositivo y conteos. La regla es estricta: el sistema que vigila el acceso a datos sensibles no puede él mismo ser una segunda copia de esos datos.

Cómo elegir un proveedor de software clínico mirando esto

Si estás evaluando una plataforma para tu consultorio o clínica, preguntá esto antes de firmar:

1. ¿Mantienen un audit log inmutable de cada acceso a datos clínicos? Si la respuesta es "los logs están en CloudWatch", no es suficiente: CloudWatch es operativo, no es un audit log retenido seis años como HIPAA exige.
2. ¿Tienen reglas activas de detección sobre ese log o solo lo guardan? Guardar sin mirar es como tener cámaras de seguridad apagadas.
3. ¿Pueden mostrarme la timeline de quién accedió al expediente de un paciente concreto? Si la respuesta tarda más de un minuto, no tienen break-glass real.
4. ¿Qué pasa si un empleado mío renuncia hoy? ¿Cómo sé que no se llevó datos antes de irse? La regla BULK_EXPORT y la respuesta revoke-sessions deberían ser parte de la respuesta.
5. ¿El sistema de monitoreo se audita a sí mismo? Si la pregunta los toma por sorpresa, asumí que no.

¿Qué significa esto para vos?

Significa que cuando guardás la nota de una sesión en Brauni, ese acto queda registrado de forma permanente. Si mañana se sospecha que un dato se filtró, hay forma de reconstruir exactamente qué pasó, quién lo vio y desde dónde. Si una cuenta del equipo se comporta de forma rara, el sistema lo detecta antes de que alguien revise los logs a mano. Y si se confirma un incidente, se puede cortar el acceso en segundos.

Cifrado, BAA con el proveedor de infraestructura, no usar datos para entrenar IA, cifrado campo por campo. Todo eso son condiciones necesarias. Patient Privacy Monitoring es la capa que convierte la confianza en algo verificable.

Porque al final, en salud, la pregunta correcta no es "¿están los datos seguros?". Es "¿cómo sabés que lo están?". Y a esa pregunta solo se le contesta con evidencia.

¿Tenés dudas sobre cómo protegemos la privacidad o querés profundizar en algún aspecto técnico de este sistema? Escribinos a soporte@brauni.io. Estamos para darte tranquilidad.

---

Brauni cumple con los principios de la Ley 25.326 de Protección de Datos Personales de Argentina y se alinea con los estándares internacionales de HIPAA para el manejo de información de salud protegida (PHI). El sistema de Patient Privacy Monitoring cubre los requisitos de Audit Controls (45 CFR §164.312(b)), Information System Activity Review (§164.308(a)(1)(ii)(D)) y Security Incident Procedures (§164.308(a)(6)). Brauni provee la infraestructura y las herramientas de monitoreo compatibles con estos estándares; la responsabilidad sobre el tratamiento de los datos y la activación de los protocolos de respuesta corresponde a cada profesional o institución, en su rol de responsable del tratamiento.