Historias clínicas en la nube: el error de RGPD y su solución

El problema es que una historia clínica de psicología no es un archivo cualquiera. Contiene datos de salud, una categoría especialmente protegida por el artículo 9 del Reglamento General de Protección de Datos (RGPD), y su almacenamiento activa obligaciones concretas de seguridad, custodia y control de acceso.

La combinación de cuenta personal de Gmail, carpeta privada y contraseña no resuelve esas obligaciones. Cuando un profesional utiliza Google Drive personal para almacenar información clínica, suele faltar una pieza esencial: la relación contractual que permite al proveedor actuar como encargado del tratamiento. Sin ese marco, la nube no es una solución de cumplimiento; es una superficie de riesgo con una interfaz cómoda.

El problema empieza por la naturaleza de la historia clínica

El RGPD distingue los datos de salud como categorías especiales de datos personales. En una consulta de psicología, esta clasificación puede afectar a las notas de evolución, informes, cuestionarios, diagnósticos, antecedentes, consentimientos, comunicaciones clínica y cualquier documento que permita inferir información sobre el estado psicológico o médico de una persona.

No cambia la naturaleza del dato que el archivo se llame sesion_04.pdf, que esté dentro de una carpeta con un nombre neutro o que el documento tenga una contraseña. El contenido sigue siendo información sanitaria. Tampoco deja de serlo porque el profesional trabaje por cuenta propia y no tenga una clínica con varios empleados.

Esto introduce una diferencia decisiva frente a otros documentos administrativos:

• Una factura contiene datos personales y económicos, pero no necesariamente datos de salud.
• Un calendario puede incluir el nombre del paciente y la hora de la cita, con un nivel de exposición relevante.
• Una historia clínica reúne información especialmente sensible y exige una protección proporcional al riesgo.
• Un correo con un informe adjunto puede convertirse en una copia adicional de la historia, fuera del sistema principal de custodia.

El profesional o centro sanitario actúa como responsable del tratamiento y tiene que garantizar que las personas no autorizadas no accedan a la información. Esa responsabilidad no desaparece porque el almacenamiento se delegue en una plataforma tecnológica. Al contrario: al contratar una nube, se incorpora otro actor al tratamiento de los datos y hay que documentar correctamente esa relación.

Aquí aparece el primer error de muchas consultas: interpretar la nube como un armario remoto. No lo es. Es una cadena de servicios que incluye autenticación, sincronización, copias, centros de datos, soporte técnico, administración de cuentas y, en algunos casos, transferencias internacionales. Cada eslabón forma parte de la seguridad del historial clínico digital.

Por qué una cuenta personal de Google Drive no es suficiente

Las cuentas gratuitas personales de Google Drive están diseñadas para uso individual y generalista. Permiten almacenar documentos, sincronizarlos entre dispositivos y compartirlos con terceros, pero no están planteadas como una infraestructura contractual y organizativa específica para una consulta sanitaria.

El punto crítico es el contrato de encargo del tratamiento, conocido habitualmente como DPA. El artículo 28 del RGPD exige que el responsable del tratamiento formalice esa relación con cualquier proveedor que almacene o trate datos personales por su cuenta. En el caso de una consulta de psicología, el proveedor de nube no debería acceder a las historias para sus propios fines, sino prestar un servicio bajo instrucciones documentadas y condiciones de seguridad definidas.

Una dirección @gmail.com no ofrece, por sí sola, la misma estructura contractual que una cuenta corporativa de Google Workspace. No basta con que el proveedor sea una empresa tecnológica conocida ni con que el servicio utilice cifrado durante determinadas operaciones. La reputación de la plataforma no sustituye al DPA, a la configuración de seguridad ni a la documentación del tratamiento.

La diferencia práctica puede resumirse así:

La tabla no significa que contratar Google Workspace convierta automáticamente una consulta en conforme al RGPD. El DPA es necesario, pero no suficiente. También hay que configurar permisos, aplicar autenticación robusta, controlar dispositivos, definir plazos de conservación y documentar el tratamiento. Una cuenta empresarial mal administrada puede seguir exponiendo historiales.

El error de confundir contraseña con cumplimiento

Proteger un documento de Word con contraseña o cerrar una carpeta con una clave no equivale a cumplir con las obligaciones organizativas y legales del RGPD. Puede aportar una capa adicional, pero no responde a preguntas esenciales: ¿quién tiene acceso a la carpeta?, ¿se ha compartido algún archivo mediante un enlace público?, ¿puede un antiguo colaborador seguir entrando?, ¿se sincronizan los documentos con un ordenador doméstico?, ¿existe una copia en un dispositivo sin cifrado?, ¿el proveedor está vinculado mediante un contrato de encargo?, ¿se registran los accesos y las descargas?, ¿qué ocurre cuando el paciente ejerce sus derechos?, ¿cómo se recuperan los datos tras un borrado accidental o un incidente?

Una contraseña protege, en el mejor de los casos, un objeto concreto. La seguridad del historial clínico exige gobernar todo el ciclo de vida del dato.

El DPA no es un trámite decorativo

El contrato de encargo del tratamiento define qué puede hacer el proveedor con los datos y bajo qué condiciones. En una consulta psicológica, debería formar parte de la arquitectura documental de la actividad, igual que el registro de tratamientos, las políticas de acceso o el procedimiento de gestión de incidentes.

Su función es fijar, entre otros aspectos:

1. El objeto y la duración del tratamiento. El proveedor debe saber que almacena información por cuenta del profesional y durante qué periodo.

2. La naturaleza y finalidad del servicio. La nube proporciona almacenamiento y herramientas asociadas; no puede reutilizar las historias para finalidades propias.

3. El tipo de datos tratados. En este caso, se incluyen categorías especiales de datos relacionadas con la salud.

4. Las categorías de personas afectadas. Los pacientes y, cuando corresponda, otras personas mencionadas en la documentación clínica.

5. Las medidas de seguridad. El contrato debe integrarse con controles técnicos y organizativos reales, no limitarse a una declaración genérica.

6. La confidencialidad del personal. Quienes puedan intervenir en la prestación deben estar sujetos a obligaciones de confidencialidad.

7. La asistencia al responsable. El proveedor debe colaborar en derechos de los pacientes, incidentes, evaluaciones y requerimientos de seguridad.

8. La devolución o supresión de los datos. Al finalizar el servicio, la consulta debe poder recuperar y eliminar la información conforme a sus obligaciones.

9. El uso de subencargados. La cadena de proveedores debe ser transparente y estar sometida a autorización o condiciones equivalentes.

10. Las transferencias internacionales. Si los datos salen del Espacio Económico Europeo, deben existir garantías jurídicas aplicables.

El DPA establece el marco, pero no decide quién debe acceder a una historia concreta ni si una carpeta se ha configurado correctamente. Esa parte sigue siendo responsabilidad del profesional.

Un DPA firmado no corrige una carpeta pública, una cuenta compartida entre varias personas ni un ordenador sin protección. El contrato ordena la relación; la configuración demuestra que se está cumpliendo.

Google Workspace: una mejora real, pero no un salvoconducto

Google Workspace ofrece una base más adecuada para una consulta profesional porque permite suscribir el Anexo de Tratamiento de Datos y gestionar el entorno desde una administración corporativa. También incorpora opciones relacionadas con la residencia de datos, las Cláusulas Contractuales Tipo y otros mecanismos para abordar transferencias internacionales, además de controles de identidad y seguridad que no están disponibles de la misma manera en una cuenta personal.

La ventaja principal no es simplemente tener más espacio de almacenamiento. Es la capacidad de gobernanza. Una cuenta profesional permite construir una frontera entre la identidad particular y la actividad clínica, administrar usuarios, retirar permisos, aplicar políticas y centralizar la gestión.

Para que esa mejora sea efectiva, conviene trabajar sobre varias capas:

1. Identidad profesional separada

La cuenta utilizada para la consulta debería pertenecer al dominio profesional y no depender de una dirección personal que también sirva para compras, redes sociales o documentos familiares. La separación reduce errores de compartición y facilita la continuidad de la actividad si cambia el equipo o se incorpora otro profesional.

Compartir una única cuenta entre varias personas es una mala práctica. Impide atribuir responsabilidades, dificulta revocar accesos y elimina la trazabilidad individual. Cada usuario necesita su propia identidad y el nivel mínimo de permisos que requiera.

2. Autenticación multifactor

La contraseña es una barrera insuficiente frente a reutilización, filtraciones, ataques de ingeniería social o dispositivos comprometidos. La autenticación multifactor añade una segunda comprobación y reduce el impacto de que una contraseña llegue a manos ajenas.

No convierte una cuenta en inexpugnable, pero cambia el coste del ataque. En ciberseguridad sanitaria, esa diferencia importa porque una sola cuenta puede abrir la puerta a años de documentación clínica.

3. Permisos por necesidad de acceso

No todas las personas que trabajan en una consulta necesitan consultar toda la historia clínica. La administración, la facturación y la coordinación de citas pueden requerir datos limitados, pero no necesariamente acceso a las notas terapéuticas.

La estructura de carpetas debe reflejar esa separación. Es preferible conceder acceso a una carpeta concreta durante el tiempo necesario que utilizar una carpeta raíz con todos los historiales. También hay que revisar de forma periódica los enlaces externos y evitar la opción de acceso para cualquiera que tenga el enlace.

4. Dispositivos y sincronización

El archivo puede estar protegido en la nube y quedar expuesto en un portátil sin cifrado, un teléfono sin bloqueo o una carpeta sincronizada con un equipo que utiliza toda la familia. La seguridad no termina en el centro de datos.

La consulta debe decidir qué dispositivos pueden descargar información, cómo se actualizan, quién administra sus cuentas y qué sucede si se pierden. El acceso desde redes públicas, las extensiones del navegador y las aplicaciones de terceros también pueden ampliar la superficie de ataque.

5. Registros e incidentes

La capacidad de revisar accesos, descargas y cambios ayuda a detectar comportamientos anómalos. Si un archivo se comparte por error o una cuenta resulta comprometida, la respuesta debe estar definida antes del incidente.

El procedimiento debería contemplar la identificación del problema, la contención, la conservación de evidencias, la evaluación del riesgo y las comunicaciones que correspondan. Esperar a que ocurra una filtración para decidir quién actúa es una forma cara de descubrir que la automatización también necesita un protocolo de crisis.

La custodia clínica exige controlar todo el ciclo de vida

La protección de datos de pacientes en psicología no se limita al momento de subir un documento. Hay que gobernar su creación, consulta, modificación, conservación, exportación y eliminación.

La historia clínica está sujeta a obligaciones específicas de conservación que varían según la normativa sanitaria aplicable en cada comunidad autónoma, el ámbito asistencial y la documentación concreta de que se trate. El plazo exacto de retención depende, por tanto, de la legislación sanitaria estatal y autonómica que resulte de aplicación, sin que exista un criterio único válido para todos los casos. Esto significa que la política de retención debe analizarse caso por caso antes de configurar cualquier borrado automático, porque un borrado prematuro puede incumplir obligaciones de custodia tan serias como una conservación descontrolada.

A la vez, conservar no significa acumular copias sin control. Una consulta puede terminar con:

• El archivo original en Drive.
• Una copia descargada en el ordenador.
• Un adjunto enviado por correo.
• Una versión en una aplicación de notas.
• Una exportación en un disco externo.
• Una copia automática de seguridad.
• Un documento temporal en la papelera.

Cada copia es otro punto de acceso y otra responsabilidad. La política de conservación debe distinguir entre el expediente que debe custodiarse y las copias temporales que deben eliminarse cuando dejan de ser necesarias.

También hay que planificar la portabilidad y la continuidad. Si se cambia de proveedor, se cierra la consulta o se produce una interrupción del servicio, el profesional debe poder recuperar los datos en un formato utilizable. La dependencia de una plataforma sin un plan de salida es un problema de escalabilidad y de custodia, no solo de comodidad.

Consentimiento informado digital: no es una casilla

El consentimiento informado digital puede integrarse en una plataforma de gestión, pero no debe reducirse a marcar una casilla durante el alta. El paciente necesita recibir información comprensible sobre el tratamiento de sus datos, las finalidades, los responsables, los derechos y, cuando proceda, las comunicaciones con terceros.

La firma electrónica o la aceptación registrada aportan trazabilidad, pero su valor depende del sistema que las conserva. Hay que poder demostrar qué versión de la información se mostró, cuándo se aceptó, quién la aceptó y si el consentimiento se retiró posteriormente. Además, el consentimiento clinique y la información sobre protección de datos son conceptos relacionados, pero no idénticos: no conviene fusionarlos en un único documento confuso.

Software clínico frente a nube genérica

Una solución de almacenamiento generalista puede ser válida para ciertos documentos internos, pero una consulta que gestiona historias clínicas necesita funciones que no siempre están presentes en una nube de propósito general.

El software clínico especializado acostumbra a incorporar expedientes estructurados, control de roles, agenda, consentimientos versionados, facturación integrada, registro de accesos, exportación masiva y soporte de obligaciones documentales específicas del ámbito sanitario. Eso no lo convierte en una categoría mágica ni lo hace inmune a una mala configuración, pero reduce la distancia entre la operativa del día a día y las exigencias del RGPD y la normativa sanitaria.

La comparación no debe plantearse como una elección excluyente. Muchas consultas combinan una plataforma clínica con un espacio de nube corporativa, reservando Drive o equivalentes para documentación administrativa, plantillas o material de trabajo que no contiene información identificable de pacientes. Lo importante es que cada dato termine donde pueda gobernarse.

Antes de decidirse por una herramienta, conviene revisar algunos puntos:

• Funciones clínicas reales: no vale cualquier ERP con almacenamiento; hacen falta campos, historiales y flujos pensados para psicología.
• Encaje contractual: ¿qué DPA ofrece el proveedor?, ¿está adaptado al sector sanitario?, ¿permite configurarlo para datos del artículo 9?
• Residencia de los datos: ¿dónde se almacenan los servidores?, ¿qué ocurre si la empresa cambia de jurisdicción o de país?
• Soporte y continuidad: ¿qué pasa si el proveedor cierra o deja de operar?, ¿hay un plan de exportación verificable?
• Coste total: más allá de la cuota mensual, hay que valorar tiempo de configuración, formación y mantenimiento de cumplimiento.
• Historial del proveedor: trayectoria, incidentes previos comunicados, auditorías y certificaciones disponibles.
• Actualizaciones legales: ¿incorpora cambios normativos relevantes o deja ese trabajo al profesional?

La nube genérica, por bien configurada que esté, sigue siendo una herramienta de propósito general. El software clínico especializado intenta resolver un problema concreto: custodiar documentación sanitaria con criterios profesionales. Son aproximaciones distintas a problemas distintos; confundirlas suele ser el origen del error de RGPD que da título a este artículo.

Al final, la conformidad no se demuestra con el icono de un candado en la esquina de la pantalla. Se demuestra con un mapa de tratamientos coherente, contratos firmados, accesos controlados, plazos definidos y un proveedor que sabe qué puede hacer con los datos y qué no. Cuando esa arquitectura existe, la tecnología deja de ser el problema y empieza a ser, por fin, una aliada.