RGPD y software de salud mental con VR: requisitos que tu proveedor debe cumplir

Por qué este artículo, en una palabra

El RGPD no es un trámite. Es un marco que define qué puedes y qué no puedes hacer con los datos de tus pacientes. Cuando incorporas un software de realidad virtual a tu consulta, estás introduciendo un tratamiento de datos de categoría especial (salud) ejecutado por un tercero (el proveedor de software). Eso te convierte a ti, el psicólogo o el centro, en responsable del tratamiento, y al proveedor en encargado del tratamiento.

La asimetría es importante: ante una inspección de la Agencia Española de Protección de Datos (AEPD) o una reclamación de un paciente, la responsabilidad principal recae sobre ti. Por eso conviene saber qué exigir al proveedor antes de firmar, no después. home home

Aviso obligado: este artículo es divulgativo. No sustituye asesoría legal individualizada. Si tienes dudas concretas sobre tu caso, consulta con tu Delegado de Protección de Datos o con un abogado especializado en protección de datos sanitarios.

Qué datos genera un software clínico de VR

Antes de discutir cumplimiento, conviene saber qué datos están en juego. Un software de VR en consulta psicológica genera, dependiendo del producto, hasta seis categorías de datos.

Datos identificativos del profesional: nombre, email, colegiación, centro clínico. Categoría general, no especial.

Datos identificativos o pseudonimizados del paciente: en muchos productos, incluido VRET, no se solicita identificación real del paciente, sino un pseudónimo o referencia clínica decidida por el psicólogo ("Paciente A", "P-2026-014"). Si el pseudónimo permite reidentificación cruzada con tus registros clínicos internos, sigue siendo dato personal en cabeza del responsable.

Datos de sesión clínica: escenarios usados, duración, fecha y hora, controles ajustados durante la sesión, notas del clínico. Son datos de salud (Art. 9 RGPD).

Datos biométricos del paciente (si el producto los recoge): frecuencia cardíaca, movimientos oculares, ritmo respiratorio, postura corporal, conductancia de la piel. Algunos sistemas de eye tracking recogen datos que pueden ser categorizados como biométricos en sentido RGPD.

Voz del paciente, si hay micrófono activo durante la sesión: en muchos productos no se graba; en otros sí. Es relevante saberlo.

Grabaciones audiovisuales de la sesión: algunos productos permiten grabación de vídeo en perspectiva externa o de la pantalla del casco. Si se generan, son datos de salud y posiblemente biométricos.

El primer paso, antes de firmar nada, es saber qué de esto genera el producto que estás evaluando.

El marco legal aplicable, en breve

Reglamento (UE) 2016/679, General de Protección de Datos (RGPD): marco europeo aplicable directamente.

Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD): desarrollo nacional español del RGPD, con artículos relevantes sobre datos sanitarios.

Real Decreto 1720/2007 (en lo aún vigente tras LOPDGDD): reglamento histórico que mantiene elementos aplicables sobre medidas de seguridad.

Código Deontológico del Psicólogo (COP, Madrid 2010 actualizado): obligaciones deontológicas de confidencialidad que se suman a las legales.

Para datos de salud, el Art. 9.1 RGPD prohíbe el tratamiento, salvo las excepciones del Art. 9.2. La más relevante para tu consulta es la letra h): tratamiento necesario para fines de medicina preventiva, diagnóstico médico, prestación de asistencia social y sanitaria, sobre la base de derecho de la UE o nacional o en virtud de contrato con profesional sanitario sujeto a deber de secreto.

El paciente, por tanto, no necesita consentir explícitamente el tratamiento de sus datos de salud para que tú le trates psicológicamente (la base jurídica está en el Art. 9.2.h y en la relación asistencial). Pero sí necesita ser informado adecuadamente, conforme al Art. 13 RGPD.

Requisito 1: contrato de encargado del tratamiento (Art. 28 RGPD)

Cualquier proveedor que procese datos personales por tu cuenta es, jurídicamente, un encargado del tratamiento. El Art. 28 RGPD exige que la relación entre responsable y encargado se documente por contrato.

Ese contrato debe incluir, como mínimo: objeto y duración del tratamiento, naturaleza y finalidad, tipo de datos personales y categorías de interesados, obligaciones y derechos del responsable, instrucciones documentadas del responsable, deber de confidencialidad, medidas de seguridad técnicas y organizativas, condiciones para subcontratación, asistencia al responsable, devolución o supresión de datos al finalizar, y auditoría.

Si un proveedor no te ofrece contrato de encargado del tratamiento firmado antes de empezar a usar el software, esa es señal de alarma. No es un detalle administrativo: es el documento que define la responsabilidad legal compartida.

Requisito 2: Data Processing Addendum (DPA) operativo

El DPA es la documentación operativa que detalla cómo se ejecuta lo pactado en el contrato de encargado. Suele incluir: relación de subencargados (sub-procesadores) con derecho de oposición del responsable, ubicación geográfica de los servidores, mecanismos de transferencia internacional cuando aplique (cláusulas contractuales tipo, decisiones de adecuación, certificaciones), medidas técnicas concretas (cifrado, control de accesos, registro de auditoría, copia de seguridad), procedimiento de notificación de incidentes y plazos.

Un DPA bien hecho es revisable página a página. Si el proveedor te entrega un documento genérico de tres páginas sin detalle operativo, es difícil que cubra lo que el RGPD exige.

Requisito 3: cifrado en tránsito y en reposo

Cifrado en tránsito: los datos que viajan entre el casco VR, tu ordenador, el dashboard web del proveedor y los servidores del proveedor deben ir cifrados. El estándar de facto es TLS 1.2 o superior con suites modernas. Pregunta explícitamente al proveedor qué protocolos usa.

Cifrado en reposo: los datos almacenados en los servidores deben estar cifrados con algoritmos estándar (AES-256 es el habitual). Esto protege ante el robo físico de discos o el acceso indebido a la infraestructura.

Cifrado especialmente de los datos clínicos sensibles: notas de sesión, datos biométricos identificables, audio o vídeo si lo hubiera. Algunos proveedores aplican cifrado a nivel de columna en la base de datos para estos campos específicos, con claves gestionadas separadamente. Es buena práctica.

Requisito 4: ubicación de los servidores

Para tu tranquilidad y la del paciente, la opción más limpia es: servidores ubicados en la Unión Europea, operados por proveedores de infraestructura cloud establecidos en la UE.

Si el proveedor de software usa AWS, Google Cloud o Microsoft Azure (proveedores estadounidenses con presencia europea), eso no es automáticamente un problema, pero introduce complejidad jurídica adicional por el régimen de transferencia internacional de datos. Tras la sentencia Schrems II y el actual marco UE-EE.UU. (Data Privacy Framework, 2023), el cumplimiento es viable pero requiere documentación.

Si el proveedor tiene servidores en jurisdicciones sin decisión de adecuación (Reino Unido tras Brexit cuenta con adecuación; otros países, no), exige garantías adicionales (cláusulas contractuales tipo modelo Comisión Europea, evaluación de impacto sobre transferencias).

Pregunta directa al proveedor: ¿en qué país están físicamente los servidores donde se almacenan los datos clínicos de mis pacientes? Una respuesta concreta es señal de seriedad. Una respuesta evasiva, lo contrario.

Requisito 5: política de retención

¿Cuánto tiempo guarda el proveedor tus datos? ¿Qué pasa cuando dejas de ser cliente? ¿Qué pasa cuando un paciente pide ejercicio de derecho de supresión?

El proveedor debe tener política de retención escrita, ajustada a la finalidad del tratamiento y a las obligaciones legales aplicables. La normativa sanitaria española obliga a conservar la historia clínica un mínimo de cinco años desde la última asistencia (Ley 41/2002 de Autonomía del Paciente), con matices autonómicos.

Cuando termina la relación contractual con el proveedor, este debe ofrecerte dos opciones: devolución de los datos en formato exportable a ti (responsable) y posterior supresión, o supresión directa con certificación de borrado. Lo razonable es que el proveedor ofrezca ambas y tú elijas.

Requisito 6: notificación de brechas en 72 horas

El Art. 33 RGPD obliga al responsable a notificar las violaciones de seguridad a la AEPD en un plazo no superior a 72 horas desde que tenga conocimiento. Para cumplir ese plazo, necesitas que el proveedor te avise rápido cuando algo pase.

Pregunta al proveedor: ¿cuál es vuestro plazo contractual de notificación de incidentes al cliente? El razonable es 24-48 horas desde la detección.

Pregunta también: ¿cómo me notificarías? ¿Por correo? ¿Con qué información mínima? ¿Quién es el contacto técnico al que puedo escalar?

Las brechas pasan. Lo relevante no es prometer que no pasarán, sino tener procedimiento serio cuando ocurren.

Requisito 7: evaluación de impacto (DPIA) cuando proceda

El Art. 35 RGPD obliga a realizar evaluación de impacto sobre la protección de datos (DPIA) cuando el tratamiento implique alto riesgo para los derechos y libertades de los interesados. Tratar datos de categoría especial (salud) a escala, o usar nuevas tecnologías, son criterios que apuntan a obligación de DPIA.

En la práctica, la AEPD ha publicado listas orientativas: una clínica psicológica usando VR para tratar a un volumen significativo de pacientes con datos biométricos y registros de sesión probablemente entre en el umbral de DPIA.

Un buen proveedor te ofrecerá ayuda para realizar tu DPIA: documentación de los flujos de datos, descripción de medidas técnicas, riesgos identificados, mitigaciones. La DPIA es responsabilidad tuya, pero el proveedor está obligado a colaborar (Art. 28.3.f RGPD).

Cómo hacer la entrevista al proveedor en quince minutos

Si estás evaluando un software clínico VR y tienes una primera llamada con el proveedor, las preguntas que te dan más señal en menos tiempo son estas.

¿Me podéis enviar el contrato de encargado del tratamiento y el DPA antes de firmar el contrato comercial?

¿En qué país están físicamente los servidores y quién es el proveedor cloud subyacente?

¿Qué subencargados intervienen en el tratamiento de mis datos y puedo oponerme a alguno?

¿Cómo cifráis los datos en tránsito y en reposo, y qué datos clínicos específicos están cifrados con clave separada?

¿Cuál es vuestro plazo de notificación de brechas al cliente?

¿Qué pasa con mis datos cuando dejo de ser cliente? ¿Devolución, formato, plazo de borrado?

¿Disponéis de DPO y, en su caso, de certificación ISO 27001 o equivalente?

Un proveedor profesional responderá las siete con concreción. Uno que improvise estará improvisando en otras cosas más graves cuando algo importe.

Qué hace VRET en este terreno

Documentamos públicamente nuestro régimen de tratamiento de datos en /privacidad y /legal/dpa. Operamos con contrato de encargado del tratamiento estándar conforme al Art. 28 RGPD, ubicación de servidores en la UE, cifrado TLS 1.2+ en tránsito y AES-256 en reposo con cifrado específico para campos clínicos sensibles (notas y referencia de paciente), política de retención alineada con Ley 41/2002, notificación contractual de incidentes en 24 horas y colaboración documentada para DPIA del responsable.

Lo decimos por completitud, no como autopromoción: el objetivo de este artículo es darte criterio para evaluar a cualquier proveedor, no para venderte el nuestro.

VRET es herramienta de apoyo a la intervención psicológica, no producto sanitario con marcado CE.