Saltar al contenido
~/bigdatastack

lección 2

Día 1 -- Derecho al olvido en datos de salud

Una paciente ejerce su derecho de supresión. Inventarias sus datos en 6 tablas, descubres que la ley obliga a conservar su historia clínica, borras lo que no es historia, bloqueas lo que sí, generas evidencia auditable y le explicas por escrito qué se ha hecho y por qué.

⏱ 50 min

## Lunes, 9:00 AM -- La solicitud de Rosa

Datasets de esta lección (en tu carpeta datos/): datos/pacientes.csv (columnas id, nombre, email, telefono, dni, fecha_nacimiento, direccion, consent_investigacion, consent_marketing), datos/diagnosticos.csv (codigo_cie10, es_cronico, estado), datos/prescripciones.csv (medicamento, principio_activo, fecha_inicio, fecha_fin, renovada — fecha_fin vacía o futura indica tratamiento ACTIVO; activas o no, todas son historia clínica y se conservan), datos/citas.csv, datos/lecturas_wearable.csv, datos/consentimientos.csv y datos/peticiones_supresion.csv (paciente_id, fecha_recepcion, fecha_limite, dias_restantes, estado). Recuerda: el paciente de la solicitud es el 16222, el mismo número en todas las tablas (en pacientes.csv es la columna id; en las demás, paciente_id).

Llevas 3 días en MediTrack. Laura te ha enseñado el lake, te ha dado accesos (con permisos mínimos, como manda Rosa) y has empezado a entender el flujo de datos. Diego está a tu lado, aprendiendo contigo. Entonces llega el mensaje de Rosa al canal #data-privacy con prioridad máxima:

1Rosa Martínez  09:03 AM  #data-privacy
2@equipo-datos URGENTE
3

4Solicitud de supresión recibida. Paciente 16222.
5Art. 17 GDPR -- derecho al olvido.
6

7Plazo legal: 1 mes desde que la RECIBIMOS (4 de septiembre, por
8correo postal): vence el 4 de octubre. Hoy es 16: ya llevamos 12 días.
9Deadline interno: 24 de septiembre (10 días de margen por seguridad).
10

11Este paciente tiene historial desde 2021:
12- 3 consultas de telemedicina
13- 2 diagnósticos (uno de ellos crónico: diabetes tipo 2)
14- 6 prescripciones (2 finalizadas, 4 EN CURSO sin fecha de fin)
15- Lecturas de pulsera y tensiómetro IoT
16

17RESTRICCIÓN LEGAL: su historia clínica (consultas, diagnósticos y
18recetas, TAMBIÉN las finalizadas) hay que conservarla mínimo 5 años
19desde el alta de cada proceso (Ley 41/2002, art. 17). La supresión no
20aplica a eso (RGPD 17.3.b y 17.3.c): se BLOQUEA (LOPDGDD art. 32).
21Lo que NO es historia (marketing, aseguradora, wearables): se borra
22o se revoca.
23

24Necesito de vosotros:
251. Inventario completo de DÓNDE viven los datos de este paciente
262. Plan de ejecución por tabla (borrar / revocar / conservar bloqueado)
273. Script REPRODUCIBLE y AUDITABLE (nada de queries manuales)
284. Certificado de lo ejecutado para el registro de actividades
295. Borrador de la respuesta a la paciente: qué se borra, qué se
30   conserva, por qué ley y hasta cuándo
31

32@tu -- esto es tuyo. Laura revisa. Diego observa y aprende.
33

34"Los datos son personas." -- Rosa

Rosa no improvisa. Tiene plantillas para todo y deadlines legales claros.

Diego se gira hacia ti: "Oí a alguien decir ARCO, ¿eso qué es?" Le explicas rápidamente: "Ojo con esa sigla, porque está anticuada. ARCO — Acceso, Rectificación, Cancelación y Oposición — era el catálogo de derechos de la LOPD de 1999. Con el RGPD, que es lo que aplica hoy, los derechos son seis y con otros nombres: acceso, rectificación, supresión (el famoso derecho al olvido, artículo 17), limitación, portabilidad y oposición. Lo que ha pedido esta paciente es la supresión: quiere que borremos lo que tenemos de ella. Y aquí es más complejo que en otros sitios, porque su historia clínica estamos OBLIGADOS a conservarla por ley sanitaria, así que no es un simple borrar todo."

Laura se acerca a tu mesa con un café. "Tu primer borrado GDPR en salud. Es más complejo que lo de NeoBank -- allí solo tenías transacciones y datos bancarios. Aquí tienes una historia clínica que la ley obliga a conservar, prescripciones en curso, datos de wearables en S3 y consentimientos para marketing y aseguradoras. La gracia es que no puedes borrar TODO -- hay partes que la ley te OBLIGA a conservar aunque la paciente lo pida. Y lo que conservas no puede seguir usándose como si nada."

## El framework legal: Art. 17 vs Art. 17.3

Antes de tocar una sola línea de código, necesitas entender el marco legal. Rosa te manda un documento interno que resume las reglas:

  1. 01.Art. 17.1 GDPR: El paciente tiene derecho a obtener la supresión de sus datos personales sin dilación indebida.
  2. 02.Art. 17.3.b: EXCEPCION -- No aplica a lo que hay que conservar por una obligación legal. En salud, la principal es la de conservar la historia clínica (Ley 41/2002, abajo); las recetas tienen además la suya (Ley 29/2006 del medicamento).
  3. 03.Art. 17.3.c: EXCEPCION -- No aplica a lo que se trata por razones de interés público en el ámbito de la salud, que remite al Art. 9.2.h (asistencia sanitaria) e i (salud pública).
  4. 04.Art. 17.3.d: EXCEPCION -- Fines de archivo en interés público, investigación científica o histórica, o fines estadísticos (si la supresión hace imposible el objetivo).
  5. 05.Art. 17.3.e: EXCEPCION -- Para la formulación, ejercicio o defensa de reclamaciones.
  6. 06.Ley 41/2002 (Autonomía del Paciente), art. 17: la historia clínica se conserva COMO MINIMO 5 años desde la fecha del alta de cada proceso asistencial. MediTrack presta la asistencia con sus propios profesionales (las consultas de telemedicina), así que la historia que generan es suya y la obligación también.
  7. 07.LOPDGDD art. 32: lo que se conserva por obligación legal se BLOQUEA. Sigue guardado, pero nadie lo usa para nada que no sea esa obligación o la asistencia, y se borra cuando vence el plazo.
  8. 08.AEPD: lo ha resuelto así varias veces. La petición del paciente no obliga a cancelar los datos de la historia que la ley manda conservar (por ejemplo, la resolución TD/01738/2015, que cita su informe 189/2003).

La lección del día: el derecho de supresión no es absoluto. En salud, la ley de historia clínica manda conservar, y lo que toca es BLOQUEAR, no borrar ni anonimizar. Cuando hay conflicto, la obligación legal de conservación GANA al derecho de supresión. Pero tienes que documentar POR QUE conservas cada dato y HASTA CUANDO, y decírselo a la paciente -- no puedes simplemente "no borrar" sin justificación jurídica, ni seguir usando lo conservado como si no hubiera pedido nada.

## El inventario de datos -- Donde vive el paciente 16222

El primer paso es mapear TODOS los lugares donde existen datos de este paciente. Laura te da una pista: "No son solo las tablas de PostgreSQL. También hay Parquets en S3 con datos de wearables, logs de acceso en el audit trail, y potencialmente backups cifrados. El inventario tiene que ser COMPLETO o Rosa no lo acepta."

Lo que no es historia se borra; la historia se conserva bloqueada hasta que venza su plazo

## Diseño del proceso de supresión

Rosa necesita que el proceso sea REPRODUCIBLE y AUDITABLE. No vale hacer queries manuales en un DBeaver y "confiar" en que fue bien. Necesitas un script Python que ejecute cada paso, verifique el resultado, genere logs y produzca un certificado de supresión. Laura añade: "Y necesita tests. Si el día de mañana cambia el esquema y el script falla silenciosamente, tenemos un problema legal."

El proceso tiene 6 fases obligatorias:

  1. 01.VERIFICACION: Comprobar que el paciente existe y qué obligaciones impiden borrar (historia clínica dentro de plazo, reclamaciones abiertas, procedimientos judiciales).
  2. 02.INVENTARIO: Localizar todos los datos del paciente en todas las fuentes (PostgreSQL, S3, backups), contando registros en cada una.
  3. 03.CLASIFICACION: Determinar la acción correcta para cada tabla/fuente: BORRAR o REVOCAR lo que no es historia, CONSERVAR BLOQUEADO lo que sí.
  4. 04.EJECUCION: Aplicar las acciones en orden seguro, con transacciones y rollback en caso de error. Bloquear es marcar (bloqueado_desde) y cortar el uso, no copiar ni mover.
  5. 05.EVIDENCIA: Generar certificado de lo ejecutado firmado digitalmente para el registro de actividades de tratamiento (Art. 30 GDPR).
  6. 06.RESPUESTA: Contestar a la paciente dentro de plazo (Art. 12): qué se ha borrado, qué se conserva, por qué ley y hasta cuándo.

## Bloquear no es anonimizar (y la anonimización llega al final del plazo)

El Dr. Martín te para en el pasillo antes de comer: "Oye, esa paciente que ha pedido la supresión -- tiene una diabetes tipo 2 diagnosticada con 24 años. Es un caso interesante para mi estudio sobre detección precoz. Si la vais a anonimizar, pásamela." Rosa, que pasaba por allí (siempre pasa por allí cuando se habla de datos), interviene: "Hoy no se anonimiza nada. Su historia se conserva porque la ley obliga, y se conserva BLOQUEADA: solo se puede usar para atenderla o para cumplir con la ley. Ni para tu estudio, ni para estadística. Cuando venza el plazo, se borra o se anonimiza de verdad, sin vuelta atrás -- no pseudonimización con clave. Y para tu estudio usarás a los pacientes que sí han dado su consentimiento, que es lo de mañana."

Lo que Rosa describe para el final del plazo es lo que se llama "anonimización funcional": transformar el registro de forma que sea IMPOSIBLE reidentificar al paciente, pero conservando el valor analítico. En la práctica significa eliminar todos los identificadores directos (nombre, DNI, email, teléfono) y generalizar los quasi-identificadores (fecha nacimiento -> rango de edad, código postal -> provincia, fecha exacta -> trimestre). Hoy no toca: anonimizar la historia de alguien a quien la ley obliga a conservársela sería incumplir esa obligación, porque una historia que ya no se puede atribuir a nadie no sirve para atenderla ni para responder ante un juez.

1# Ejemplo conceptual: anonimización funcional de un historial clinico,
2# CUANDO VENCE el plazo de conservacion (hoy, este registro se bloquea)
3

4# Registro ORIGINAL (tal como está en la BD):
5registro_original = {
6    "paciente_id": 16222,
7    "nombre": "Patricia de Sainz",
8    "fecha_nacimiento": "1998-11-05",
9    "codigo_postal": "46615",
10    "diagnostico_cie10": "E11.9",  # Diabetes mellitus tipo 2 sin complicaciones
11    "fecha_diagnostico": "2023-09-23",
12    "notas_medicas": "Detectada en analitica de rutina. Asintomatica. "
13                     "Trabaja como profesora en el IES Lluis Vives.",
14    "medico_id": "MED-0451",
15    "especialidad": "cardiologia"
16}
17

18# Registro ANONIMIZADO (conserva valor clinico, persona irrecuperable):
19registro_anonimizado = {
20    "paciente_id": "ANON-8f2a4b9c",      # Hash irreversible (SHA-256 + salt)
21    "nombre": None,                        # ELIMINADO
22    "rango_edad": "25-29",                 # Generalizado (edad exacta -> rango 5 años)
23    "provincia": "Valencia",               # Generalizado (46615 -> Valencia)
24    "diagnostico_cie10": "E11.9",          # CONSERVADO (valor clinico, no identifica)
25    "trimestre_diagnostico": "2023-Q3",    # Generalizado (fecha exacta -> trimestre)
26    "notas_medicas": None,                 # ELIMINADO (texto libre = riesgo alto)
27    "medico_id": "MED-0451",              # Conservado (identifica al medico, no al paciente)
28    "especialidad": "cardiologia"          # Conservado (no identifica al paciente)
29}
30

31# POR QUE se elimina cada campo:
32# - nombre: identificador directo obvio
33# - fecha_nacimiento exacta: quasi-identificador (combinado con otros = reidentificacion)
34# - codigo_postal completo: quasi-identificador (un CP puede tener solo unos miles de habitantes)
35# - notas_medicas: contienen información que reidentifica ("profesor en IES Lluis Vives")
36# - fecha exacta: quasi-identificador temporal

Al vencer el plazo, el dato clínico (E11.9) puede quedarse para estadística; la persona desaparece para siempre

Las notas médicas en texto libre son una bomba de privacidad. Un médico puede escribir "el paciente, que trabaja de profesor en el IES Lluis Vives de Valencia, comenta que su mujer Maria le ha notado arritmias por la noche" -- eso reidentifica al paciente aunque borres su nombre. Las notas médicas SIEMPRE se eliminan en anonimización. NUNCA se generalizan ni se resumen.

## El flujo completo de supresión

1# flujo_supresion_gdpr.py -- Proceso completo de right-to-be-forgotten
2# Este es el 20% de código que se te DA como referencia.
3# Tu implementaras el 80% restante en los ejercicios.
4

5import logging
6from datetime import datetime, date
7from typing import Dict, List, Any, Optional
8from dataclasses import dataclass, field
9from enum import Enum
10

11logging.basicConfig(
12    level=logging.INFO,
13    format='%(asctime)s [%(levelname)s] %(message)s'
14)
15logger = logging.getLogger('gdpr_supresion')
16

17

18class AccionSupresion(Enum):
19    """Acciones posibles sobre datos de un paciente."""
20    BORRAR = "borrar"                    # Eliminacion fisica (no es historia)
21    REVOCAR = "revocar"                  # Se basaba en su consentimiento: deja de usarse
22    CONSERVAR_BLOQUEADO = "bloquear"     # Historia clinica: Ley 41/2002 obliga a guardarla
23    CONSERVAR = "conservar"              # Registro de la propia peticion (audit log)
24

25

26@dataclass
27class ResultadoInventario:
28    """Resultado del inventario de datos de un paciente."""
29    tabla: str
30    registros: int
31    accion: AccionSupresion
32    justificacion_legal: str
33    ejecutado: bool = False
34    timestamp_ejecucion: Optional[str] = None
35

36

37@dataclass
38class CertificadoSupresion:
39    """Certificado generado tras completar la supresión."""
40    solicitud_id: str
41    paciente_id: str
42    fecha_solicitud: str
43    fecha_ejecucion: str
44    acciones_ejecutadas: List[Dict[str, Any]] = field(default_factory=list)
45    restricciones_encontradas: List[str] = field(default_factory=list)
46    hash_evidencia: str = ""  # SHA-256 del log completo
47

48

49# Este es el ESQUELETO. Tu implementas la clase GDPRSupresionSalud
50# en el ejercicio siguiente.

Estructura base -- tú implementas la lógica completa

## La respuesta a la paciente

Queda una pieza que no es código y que Rosa revisa con lupa: la respuesta a la paciente. El RGPD (Art. 12) obliga a contestar dentro del mes, y cuando no se suprime todo, a decir por qué. Un «hemos tramitado su solicitud» no vale: ella pidió que se borrara todo, y tiene derecho a saber qué se ha borrado, qué se conserva, por qué ley y hasta cuándo. Es también lo que haría un profesional: nadie se fía de un «hecho» que no explica nada.

1Asunto: Su solicitud de supresión de datos (ref. SUPR-16222)
2

3Estimada Sra. de Sainz:
4

5Hemos atendido su solicitud de supresión del 4 de septiembre. Esto es lo
6que hemos hecho:
7

8SE HA BORRADO O REVOCADO
9- Las lecturas de sus dispositivos (tensiómetros y pulsera).
10- Su email, su teléfono y su dirección postal. No volverá a recibir
11  comunicaciones comerciales.
12- Sus autorizaciones para comunicaciones comerciales y para ceder datos a
13  su aseguradora. Guardamos solo la constancia de que las retiró.
14

15SE CONSERVA, BLOQUEADO
16- Su historia clínica: consultas, diagnósticos y recetas, también las
17  finalizadas, con los datos que la identifican (nombre, DNI y fecha de
18  nacimiento).
19- Por qué: la Ley 41/2002, art. 17, nos obliga a conservar la historia
20  clínica al menos cinco años desde el alta de cada proceso, y el RGPD
21  (art. 17.3, letras b y c) excluye esos datos del derecho de supresión.
22- Qué quiere decir «bloqueado» (LOPDGDD art. 32): nadie los usará para
23  nada que no sea atenderle a usted o cumplir esa obligación legal. Ni
24  estudios, ni estadística, ni comunicaciones.
25- Hasta cuándo: cinco años desde el alta de su último proceso. Su
26  tratamiento de la diabetes sigue abierto, así que el plazo todavía no
27  ha empezado a contar. Cuando venza, los borraremos sin que tenga que
28  pedirlo de nuevo.
29

30Si no está de acuerdo, puede reclamar ante la Agencia Española de
31Protección de Datos (www.aepd.es).
32

33Rosa Martínez
34Delegada de Protección de Datos, MediTrack

Qué se borra, qué se conserva, por qué ley y hasta cuándo: las cuatro cosas, y en lenguaje de paciente

Consejo de senior: El proceso de borrado GDPR en salud nunca es "DELETE FROM pacientes WHERE id = X". Es un workflow multi-paso con verificaciones legales en cada punto. Diséñalo como una máquina de estados donde cada transición requiere una comprobación: hay prescripción activa? hay reclamación abierta? hay obligación de archivo? Solo si todo dice "no restricción", procedes al borrado físico. Si hay alguna restricción, BLOQUEAS, documentas POR QUE no borras y QUE harás cuando la restricción expire, y se lo dices al paciente.

Regístrate para guardar tu progreso.