Seguridad de datos en software sanitario: qué debe cumplir para ser legal bajo el RGPD

1. Quién responde ante la AEPD si hay un problema

1.1. Responsable del tratamiento vs encargado del tratamiento

El RGPD distingue dos roles: el responsable del tratamiento —quien decide los fines y los medios, en este caso la clínica— y el encargado del tratamiento —quien trata los datos por cuenta del responsable, el proveedor del software—. La clínica es siempre el responsable. El proveedor del software es el encargado.

1.2. Por qué la responsabilidad recae sobre la clínica

El RGPD, artículo 28, establece que el responsable del tratamiento tiene la obligación de elegir encargados que ofrezcan garantías suficientes de seguridad. Si el proveedor de software no las ofrecía y hay un problema, la clínica puede ser sancionada por haber elegido un proveedor inadecuado, incluso si nunca supo que el proveedor no cumplía. La diligencia debida en la selección del proveedor es del responsable, no del encargado.

Esto no cambia por el tamaño del centro: un médico autónomo con diez pacientes al día tiene exactamente la misma obligación de elegir bien a su proveedor que una policlínica con treinta profesionales. La diferencia de tamaño afecta a cuántos recursos hay para verificarlo, no a si hay que hacerlo. El checklist de este artículo sirve igual en los dos casos, y el detallado en auditoría RGPD para clínicas completa el resto de obligaciones que no son estrictamente de seguridad técnica.

2. Servidores y cifrado: las capas de infraestructura

Las capas de seguridad son acumulativas: si una falla sin las demás, el conjunto sigue incumpliendo.

2.1. Servidores en la Unión Europea

El almacenamiento de datos de salud fuera de la UE solo es legal si existe una decisión de adecuación de la Comisión Europea para ese país o si se han implementado garantías adecuadas —cláusulas contractuales tipo, normas corporativas vinculantes—. El «Privacy Shield» UE-EE.UU. fue invalidado en 2020 (sentencia Schrems II), y el marco que lo sustituyó sigue generando debate legal sobre su robustez. La opción más segura y sin ambigüedades es que los datos estén en servidores dentro de la UE, y más fuerte todavía, en España. Cuando la ubicación no es esa, la operación es transferencia internacional y exige vía legal específica: adecuación, cláusulas contractuales tipo con análisis de impacto o alguna de las excepciones tasadas del artículo 49.

2.2. Cifrado en reposo y en tránsito

Los datos almacenados en los servidores deben estar cifrados: el estándar de la industria para datos de salud es AES-256 o superior, de forma que aunque alguien accediera físicamente a los servidores o a una copia, los datos no serían legibles sin la clave. La diferencia entre cifrado de volumen del servidor y cifrado documental sobre los ficheros concretos —qué se cifra y qué no— vive aparte, con el desglose que la clínica necesita para justificar cada medida ante la AEPD. Cuando los datos viajan entre el ordenador de la clínica y los servidores del proveedor, tienen que hacerlo bajo TLS 1.2 o 1.3: una conexión HTTP sin TLS, o con una versión obsoleta, transmite los datos en claro y es interceptable. Comprobar que la conexión al software clínico es siempre HTTPS es el indicador más inmediato.

Conviene distinguir además el cifrado en tránsito del cifrado de extremo a extremo, que implica que ni siquiera el propio proveedor puede acceder al contenido: son cosas distintas y muchas fichas comerciales las comunican con las mismas palabras. Para el software de gestión clínica en sí —no para una videollamada— lo exigible es que el proveedor pueda operar sobre tus datos para prestar el servicio, así que el cifrado de extremo a extremo no aplica del mismo modo que en una comunicación privada entre dos personas.

3. Autenticación, control de acceso y trazabilidad

3.1. Credenciales individuales y acceso por rol

Cada usuario del sistema debe tener credenciales propias: la práctica de «compartimos el usuario admin para todos» es incompatible con el RGPD para datos de salud porque elimina toda trazabilidad de quién hizo qué. El acceso, además, debe estar limitado por rol —el médico ve los historiales, la recepción ve solo los datos de citas, dirección ve los datos financieros—, y la autenticación de doble factor es muy recomendable para los perfiles de administrador y médico.

3.2. Trazabilidad, no un log que nadie puede tocar por decreto

El sistema debe registrar cada acceso a los datos: usuario, fecha, hora y acción realizada. Lo que exige la Ley 41/2002 no es un bloqueo del dato en sí —un profesional puede corregir un error—, sino que cada cambio quede registrado con su autor, su fecha y el valor anterior. Ese registro es la evidencia ante una inspección de que solo accedieron a los datos las personas autorizadas y cuándo lo hicieron, y de que cualquier corrección quedó documentada, no oculta.

4. Cómo verificar que tu proveedor cumple

Las respuestas del proveedor deben constar por escrito, no de palabra.

4.1. Las preguntas que hay que hacerle al proveedor por escrito

1. ¿En qué país están físicamente los servidores donde se almacenan mis datos? ¿Hay algún dato que se almacene fuera de la UE?
2. ¿El almacenamiento está cifrado, y con qué algoritmo?
3. ¿La transmisión de datos usa TLS 1.2 o 1.3?
4. ¿Pueden firmar un DPA específico para datos de salud, categoría especial bajo el RGPD?
5. ¿Cómo se registra el acceso a los datos por usuario, y ese registro es consultable?
6. ¿Puedo descargar una copia de mis propios datos cuando quiera?
7. ¿Los datos se usan para entrenar modelos de IA propios o de terceros?
8. ¿Pueden facilitarme documentación técnica de las medidas de seguridad aplicadas?

4.2. Por qué la respuesta tiene que ser por escrito

Una respuesta verbal en una demo no sirve como evidencia ante una inspección de la AEPD —el propio contrato de encargado del tratamiento es el documento que la Agencia pide como base de la relación con el proveedor—. Lo que hay que exigir es documentación: un párrafo del contrato, una ficha técnica o un correo formal que se pueda archivar en el dossier de cumplimiento de la clínica. Si el proveedor solo puede responder de palabra, esa es ya información relevante sobre su nivel real de cumplimiento.

5. Lo que es verificable en obeliOmed hoy

A las preguntas anteriores, esto es lo que se puede responder con precisión y sin adornarlo: los datos se alojan en servidores situados en España. Los documentos clínicos y los campos marcados como sensibles se cifran con AES-256-GCM, cada tipo de dato con una clave derivada distinta, y la conexión viaja bajo TLS 1.3. Ningún cambio se pierde: cuando alguien corrige una prueba o un dato del expediente, queda registrado quién lo hizo, cuándo y qué valor había antes. Cada centro puede descargar en cualquier momento una copia de sus propios datos.

Lo que no se afirma porque no es cierto: obeliOmed no cuenta hoy con una certificación ENS ni ISO 27001, y no tiene copias de seguridad automáticas ejecutándose sin intervención del centro. Es preferible decir esto con precisión a dejar que una ficha comercial lo dé por sentado.

Una obligación del RGPD que casi ninguna clínica cumple y que se le acaba pidiendo en cualquier inspección seria es la evaluación de impacto en protección de datos (EIPD). El RGPD la exige cuando el tratamiento implica categoría especial de datos —salud lo es, sin discusión— y se hace a gran escala, lo que en la práctica incluye a cualquier centro con actividad continuada. La EIPD documenta qué datos se tratan, para qué, quién accede, cómo se protegen y qué se hace si algo falla. No la sustituye ninguna certificación —esas son otra cosa— y no se puede improvisar la semana en que llega un requerimiento. La forma sana de tenerla es hacerla una vez con el DPO y revisarla cuando cambie el software o entre un nuevo tipo de tratamiento. Los supuestos concretos en los que la ley exige la evaluación de impacto (DPIA), cómo se documenta y cuándo hay consulta previa a la AEPD se cuentan aparte. Sin EIPD, la primera brecha o la primera reclamación deja al centro sin la defensa documental que la ley presupone que existe, y esa carencia pesa más que cualquier medida técnica que sí se haya adoptado.

6. El DPA: el contrato que documenta las garantías

6.1. Qué debe incluir el DPA con un proveedor de software sanitario

El DPA, o contrato de encargado del tratamiento según la nomenclatura de la LOPDGDD, debe incluir como mínimo:

• Las categorías de datos que el proveedor trata por cuenta de la clínica.
• Los fines para los que puede tratar los datos, solo los necesarios para prestar el servicio.
• Las medidas de seguridad técnicas y organizativas que el proveedor aplica.
• La prohibición de usar los datos para fines propios del proveedor: entrenamiento de IA, análisis de negocio, marketing.
• La ubicación de los servidores y las condiciones de cualquier transferencia internacional.
• El procedimiento ante una brecha de seguridad: qué comunica el proveedor a la clínica y en qué plazo.
• Las condiciones de supresión de los datos al finalizar la relación contractual.

6.2. Lo que no debe aceptarse en un DPA

Cláusulas que deben generar alerta: la posibilidad de que el proveedor use los datos «para mejorar sus servicios» sin más precisión, la ubicación de servidores «en centros de datos de terceros» sin especificar la región, el derecho del proveedor a ceder o transferir los datos a subencargados sin notificación, y la limitación de responsabilidad del proveedor por brechas debidas a sus propias medidas de seguridad insuficientes.

7. Qué pasa cuando algo falla: brechas de seguridad

7.1. La obligación de notificar

Si se produce una brecha de seguridad que afecte a datos de salud, el RGPD, artículo 33, obliga a notificarla a la autoridad de control en un plazo de 72 horas desde que se tiene conocimiento, salvo que sea improbable que suponga un riesgo para los derechos de los pacientes. El proveedor, como encargado, tiene que avisar a la clínica sin dilación indebida para que esta pueda cumplir ese plazo: si el DPA no fija un plazo concreto de aviso del proveedor a la clínica, el margen para reaccionar a tiempo se reduce.

7.2. Cuándo hay que avisar también al paciente

Si la brecha entraña un alto riesgo para los derechos del paciente —por ejemplo, la exposición de historiales clínicos completos—, el artículo 34 obliga a comunicárselo directamente, sin intermediarios ni lenguaje ambiguo. Tener un protocolo escrito de antemano, con quién avisa, a quién y con qué plantilla, es lo que marca la diferencia entre una respuesta ordenada y una reacción tardía e improvisada.

8. El dossier RGPD que tiene que mantener la propia clínica

8.1. Lo que no resuelve el software por sí solo

Un software bien diseñado cubre buena parte de las medidas técnicas, pero el Registro de Actividades de Tratamiento y la política de privacidad de la clínica los tiene que redactar la propia clínica, o su asesoría, no el proveedor de software. Delegar ciegamente esa parte en «ya lo hace el sistema» es uno de los huecos más frecuentes que se descubren en una inspección. El marco completo de qué corresponde a cada parte está en RGPD en clínicas privadas: guía de cumplimiento.

8.2. La formación del equipo, documentada

El RGPD exige que quienes tienen acceso a datos personales conozcan las instrucciones para tratarlos. La formación mínima cubre qué son los datos de categoría especial, qué se puede y no se puede hacer con ellos, cómo responder a una solicitud de derechos de un paciente y qué hacer ante una sospecha de brecha. Esa formación debe registrarse con fecha, contenido y asistentes: ese registro es, en sí mismo, parte del dossier de cumplimiento.

9. Qué aporta obeliOmed y cómo empezar

obeliOmed incluye el DPA como parte del contrato de servicio, servidores en España, cifrado AES-256-GCM y TLS 1.3, y el registro de trazabilidad descrito en el apartado 3. Los planes empiezan desde 29 €/⁠mes, con cada módulo adicional facturado aparte. El desglose completo está en la página de precios y planes, y puedes solicitar una demo desde la página de demo de obeliOmed.