Compartir datos clínicos con un tercero: cuándo anonimizas y cuándo firmas contrato

1. Las dos vías legales, sin puntos intermedios

Un dato clínico pertenece a la categoría más protegida por el RGPD: la del artículo 9, datos de salud, con prohibición general de tratamiento y excepciones tasadas. Para que ese dato salga del sistema del centro hacia otra organización, hay dos vías que la norma admite, y no hay puntos intermedios.

1.1. Vía uno: convertir el dato en anónimo

Si el dato se anonimiza —irreversible, sin posibilidad de reidentificación ni siquiera cruzando información adicional— sale del ámbito del RGPD porque ya no es dato personal. El centro puede compartirlo con cualquiera sin base jurídica adicional. La contrapartida es que la técnica es exigente: no basta con quitar el nombre; hay que verificar que las combinaciones que quedan no permitan volver a identificar a nadie.

1.2. Vía dos: dejar el dato personal pero atarlo al tercero por contrato

Si el dato sigue siendo personal —lo cual es casi siempre el caso cuando el tercero necesita responder algo específico del paciente— el tercero actúa como encargado de tratamiento del centro. Firma un contrato en los términos del artículo 28 del RGPD, que le prohíbe usar el dato para nada más que lo pactado, y responde jurídicamente si lo incumple. El centro sigue siendo responsable del tratamiento; el tercero pasa a ser una extensión operativa.

1.3. Por qué no hay tercera vía

Un dato clínico personal enviado a un tercero sin contrato de encargado y sin anonimización es una comunicación no amparada: el tercero recibe un dato personal sin base jurídica declarada, y ni el centro puede justificar el envío ni el tercero puede justificar el uso. Es la infracción más frecuente en flujos «que siempre se hicieron así» y la que más aparece en las sanciones publicadas de la AEPD.

2. Anonimización: cuándo aplica y cuándo no basta

La anonimización es la vía elegante cuando funciona, pero tiene un ámbito estrecho. Merece la pena entender cuándo aplica antes de intentarla.

2.1. Cuándo aplica

Cuando el tercero solo necesita el dato para producir estadística agregada o para entrenar sistemas sin necesidad de reidentificar a nadie: un estudio poblacional, una publicación con series de casos, un dataset de investigación con revisión ética. El detalle práctico aparece en la nota sobre datos clínicos para estadística: si el tercero puede trabajar con edades en tramos, códigos postales a tres dígitos y fechas relativas, la vía es viable.

2.2. Cuándo no basta con anonimizar

Cuando el tercero necesita responder algo específico del paciente al centro —un resultado de laboratorio para asociarlo a la petición, una autorización de mutua vinculada a un caso, un informe de especialista externo referido a un paciente concreto— la anonimización no aplica. Si el tercero pudiera reidentificar sería un dataset seudonimizado, no anonimizado; y si no puede reidentificar, no puede devolver la respuesta al paciente correcto.

2.3. La trampa de la anonimización defectuosa

Un dataset «anónimo» que solo ha perdido el nombre puede reidentificar por cruce con fuentes externas: el padrón, una red social, un directorio profesional. Compartir con un tercero un dataset anonimizado a medias es un incidente de seguridad esperando a ocurrir, y la responsabilidad sigue siendo del centro que lo generó. La anonimización real requiere métodos probados —agregación, k-anonimidad, supresión de cuasi-identificadores— y auditoría del resultado antes de liberar.

3. Contrato de encargado: qué es y qué debe llevar

El contrato de encargado con los siete bloques no es papel de reserva: es lo que ampara la comunicacion.

El contrato de encargado de tratamiento es la herramienta jurídica que permite a un tercero recibir datos personales del centro sin convertirse en responsable independiente. Sus requisitos están en el artículo 28.3 del RGPD y son verificables. La operativa técnica del acceso —autenticación específica, trazabilidad de la sesión, alcance limitado, revocación al finalizar— se cuenta en accesos de proveedores externos e integraciones.

3.1. Los siete bloques obligatorios

Objeto y duración del tratamiento; naturaleza y finalidad; tipo de datos y categorías de interesados; obligaciones y derechos del responsable; medidas técnicas y organizativas del encargado; sub-encargados autorizados o su prohibición; y destino de los datos al finalizar el contrato. Cualquier plantilla de contrato con encargado que no cubra los siete es incompleta y no ampara.

3.2. Las medidas de seguridad concretas

El contrato no puede limitarse a decir «medidas adecuadas»: tiene que especificar cifrado en tránsito, cifrado en reposo si aplica, control de acceso, registro de accesos, plazo de conservación en el sistema del encargado y procedimiento de notificación de incidentes al centro. Un encargado que no puede describir sus medidas concretas no debería estar recibiendo datos clínicos.

3.3. La sub-encargación

Cuando el tercero, a su vez, subcontrata parte del tratamiento —el proveedor de IA usa un servicio de infraestructura de otro, el laboratorio usa una plataforma cloud de un tercero— el contrato debe declarar quién sub-encarga qué, y el centro debe autorizarlo por escrito. Una sub-encargación no declarada es tan grave como una comunicación no amparada, y aparece con frecuencia en los proveedores «pequeños» que se apoyan en infraestructura de gigantes sin decirlo.

4. Los seis terceros habituales y qué le toca a cada uno

Un centro ambulatorio comparte datos con seis tipos de tercero, cada uno con vía distinta. Merece la pena enumerarlos.

4.1. Laboratorio de análisis clínicos

Recibe una petición identificada del paciente y devuelve el resultado. Vía: encargado de tratamiento. El centro firma contrato con el laboratorio, y el intercambio va por canal seguro con el paciente identificado. La anonimización no aplica porque el resultado se asocia a la persona real.

4.2. Aseguradora o mutua

Recibe el informe del proceso del paciente para justificar la facturación. Vía: encargado de tratamiento con el volumen mínimo de datos —solo el motivo, los procedimientos y las visitas del proceso concreto—; nunca la historia clínica completa. La transferencia de más información de la necesaria es exceso de tratamiento y se sanciona.

4.3. Especialista externo (derivación)

Recibe la información clínica del paciente para atender la interconsulta. Vía: cuando el especialista actúa como responsable independiente y no como extensión del centro, no es un caso de encargado sino de comunicación con base jurídica en la asistencia sanitaria (art. 9.2.h del RGPD). El envío se hace por canal seguro y con el consentimiento razonable del paciente para la derivación.

4.4. Gestoría o asesoría fiscal

Recibe la factura del proceso para la contabilidad. Vía: encargado de tratamiento. El detalle: la factura debería salir sin diagnósticos ni descripciones clínicas —«consulta especializada» basta— porque la gestoría no necesita saber por qué vino el paciente para llevar la contabilidad.

4.5. Mensajería y comunicación con paciente

Proveedor de SMS, email, WhatsApp que envía recordatorios de cita al paciente en nombre del centro. Vía: encargado de tratamiento. El contenido de los mensajes tiene su propia disciplina: el recordatorio no debe revelar diagnóstico ni especialidad, para no exponer el dato de salud si un tercero ve la pantalla del paciente.

4.6. Proveedor de IA

Recibe texto clínico para procesarlo —redactar borradores, extraer información, sugerir códigos—. Vía: encargado de tratamiento, con datos seudonimizados antes de la llamada. La combinación —encargado firmado más seudonimización— es la que hace el flujo aceptable para la AEPD.

5. Qué se rompe cuando eliges la vía equivocada

Elegir mal entre anonimización y encargado —o directamente no elegir— tiene consecuencias concretas que aparecen antes de lo que parece.

5.1. Sanción de la AEPD

El régimen sancionador del RGPD y de la LOPDGDD llega a millones de euros para infracciones graves. En sanidad, la AEPD ha sancionado repetidamente comunicaciones sin base jurídica a proveedores externos y a aseguradoras. Las sanciones publicadas muestran patrones que se repiten y que serían evitables con una revisión anual de los flujos.

5.2. Responsabilidad civil frente al paciente

Un paciente cuya información clínica llegó a un tercero sin base jurídica puede reclamar por daño moral, y los tribunales han reconocido indemnizaciones incluso cuando el impacto material era acotado. La responsabilidad recae en el centro como responsable del tratamiento; que el tercero receptor «no hizo nada malo» con el dato no cambia la posición jurídica del centro.

5.3. Ruptura de la relación con el paciente

Un incidente que llega al paciente —una llamada de una aseguradora que menciona un diagnóstico que no le habían comunicado— rompe la confianza más deprisa que cualquier otra causa. Y no es reparable con explicaciones: en centros pequeños, un caso se convierte en boca a boca en semanas.

6. Base jurídica del RGPD, artículo por artículo

La normativa aplicable no es solo el RGPD europeo: la LOPDGDD española añade obligaciones concretas, y la AEPD ha publicado orientaciones específicas sobre datos de salud.

6.1. Artículo 9 RGPD: datos de salud

La regla general es la prohibición del tratamiento. Las excepciones tasadas incluyen la asistencia sanitaria por profesional sujeto a secreto (9.2.h), el consentimiento explícito (9.2.a), el interés vital (9.2.c) y los intereses públicos en salud pública (9.2.i). Cualquier comunicación de dato de salud debe apoyarse en una de esas excepciones, no en una base jurídica genérica.

6.2. Artículo 28 RGPD: encargado de tratamiento

El contrato debe formalizarse por escrito, tener el contenido de los siete bloques ya descritos y ser vinculante para las partes. Un encargado que trata datos sin contrato firmado es una infracción tanto del centro como del propio encargado.

6.3. LOPDGDD y AEPD

La LOPDGDD, en su artículo 26, obliga a que las clínicas designen un delegado de protección de datos si tratan datos de salud a gran escala. La AEPD ha aclarado que la escala hospitalaria implica designación obligatoria, y en centros ambulatorios la evaluación depende del volumen —hay más detalle en la nota sobre DPO obligatorio—.

7. Qué debe hacer tu software antes del envío

Cada tercero tiene su ficha, su via y su contrato: sin ficha no sale envio.

La decisión sobre qué vía aplica no debería depender de que el usuario recuerde el reparto: el software del centro tiene que sostener la disciplina. Tres criterios verificables.

7.1. Cataloga cada tercero con su vía y su contrato

En el sistema del centro debe existir una lista de terceros a los que se envían datos, con la vía —anonimización o encargado—, el contrato firmado si aplica y la fecha de última revisión. Un tercero sin ficha no debería recibir envío desde el sistema. Sin ese registro, la conversación sobre qué se compartió con quién es reconstrucción manual cada vez.

7.2. Aplica la vía por defecto según el destino

Al preparar un envío a la aseguradora X, el sistema debe saber que ese destino requiere encargado y montar el paquete con los campos autorizados —motivo, procedimientos, visitas— y no con la historia completa. Al preparar un envío a un dataset de investigación, debe pasar antes por la capa de anonimización y verificar que el resultado no permite reidentificar por cruce.

7.3. Registra el envío como acto trazable

Cada envío queda registrado con destino, contenido, vía aplicada, fecha, autor. Es lo que después permite responder a una petición del paciente sobre qué se ha hecho con sus datos —el derecho de acceso lo cubre— y a una auditoría RGPD del centro cuando toque revisión anual.

Y un cuarto criterio, más operativo que técnico. La revisión anual de la lista de terceros —contratos vigentes, direcciones actualizadas, medidas de seguridad renovadas— es responsabilidad del centro. El software puede recordarlo con avisos por vencimiento, pero no puede firmar contratos por su cuenta.

8. Errores frecuentes al compartir con terceros

• Mandar la historia completa al pagador cuando solo hacía falta el informe del proceso.
• Compartir «datos anónimos» que solo perdieron el nombre. Un cruce con el padrón reidentifica en minutos.
• Usar proveedores de IA sin contrato de encargado. Es infracción formal aunque el dato esté seudonimizado.
• No autorizar los sub-encargos del tercero, dejando fuera del contrato a quien realmente aloja los datos.

8.1. El error que más caro sale: adjuntos «por si acaso»

El sistema pide mandar el informe del proceso a la aseguradora y quien lo prepara adjunta la historia entera «por si acaso les hace falta más contexto». La aseguradora ya no puede alegar que solo recibió lo justo: tiene la historia completa, con diagnósticos y evolución de otros procesos. Cualquier revisión posterior detecta el exceso, y la sanción va contra el centro. La disciplina de que el envío contenga solo lo pactado ahorra este escenario, y el software puede facilitarla montando el paquete por él.

8.2. Confundir consentimiento del paciente con base jurídica de comunicación

Que el paciente firme un consentimiento para el uso de sus datos no exime al centro de mantener el catálogo de terceros y los contratos correspondientes. El consentimiento es una base jurídica para el tratamiento por parte del centro; el envío a un tercero requiere además la vía correspondiente. Un centro que confía en el consentimiento como cobertura para todo se encuentra con que la AEPD sanciona igualmente por ausencia de contrato con el encargado.

8.3. Compartir por email personal del clínico

Un clínico manda el informe del paciente a un especialista externo desde su correo personal para agilizar. El envío queda fuera de todo registro del sistema, y si más tarde hay incidente, la trazabilidad es un intercambio de correos entre dos personas. Los canales oficiales del centro —integrados con el sistema, con registro— son incómodos al principio y salvan mucho después. El software puede ofrecer una vía de derivación integrada que sea igual de rápida y quede trazada por defecto.

9. Qué aporta obeliOmed con esto

9.1. Cada envío pasa por catálogo de destinos

obeliOmed no permite el envío a un tercero que no esté catalogado con su vía y su contrato vigente. Al preparar un informe para una aseguradora, el sistema aplica el catálogo: qué campos van, con qué formato, contra qué contrato de encargado. La ficha del envío queda registrada con destino, contenido y autor, y forma parte del expediente del paciente como cualquier otra pieza de la historia.

9.2. La anonimización y la seudonimización son capas del sistema

Cuando el flujo requiere anonimizar —dataset para investigación, cifras para publicación— la capa se aplica antes de que el dato salga y verifica que el resultado no permita reidentificar. Cuando requiere seudonimizar —llamada a IA con texto clínico— la capa aplica sin depender de que el usuario final lo recuerde. Las dos capas son parte del producto, no configuración opcional.

9.3. Lo que no hace, dicho antes de que lo preguntes

obeliOmed no firma los contratos de encargado por el centro ni negocia con los terceros: eso lo hace la clínica, con su asesor legal si conviene. Lo que hace el sistema es imponer que sin contrato registrado no salga un envío, y avisar cuando un contrato se acerca a la fecha de revisión. La responsabilidad del cumplimiento sigue siendo del centro; el software se limita a que no se cumpla por descuido.