Exportar datos clínicos: quién debería poder hacerlo y por qué es una operación distinta

1. Exportar no es consultar: por qué son operaciones distintas

Consultar un dato en pantalla deja el dato dentro del sistema. Lo ves, lo usas para tomar una decisión clínica y la información sigue protegida por los controles del sistema: el registro de acceso, el filtrado por centro, el cierre de sesión. Exportar saca el dato fuera. A partir de ese momento, el sistema ya no lo controla.

1.1. La diferencia está en la reversibilidad

Si un profesional consulta un historial sin justificación, la auditoría de accesos lo detecta y la clínica puede tomar medidas. Si ese profesional exporta los datos a un fichero, la auditoría detecta la exportación, pero los datos ya están fuera. El fichero puede copiarse, reenviarse y almacenarse en sitios que la clínica no controla. La exportación es una operación irreversible: una vez que el dato ha salido, no se puede deshacer.

1.2. No todo el que consulta necesita exportar

Un médico que pasa consulta necesita ver la historia clínica del paciente. No necesita exportarla a un fichero. Un enfermero que registra constantes necesita escribir en la ficha. No necesita descargarla. La inmensa mayoría de las operaciones clínicas son de lectura y escritura dentro del sistema. La exportación es una operación excepcional que solo unas pocas funciones necesitan.

2. Quién necesita exportar datos clínicos en la práctica

Los casos en los que alguien necesita exportar datos clínicos son menos de los que parece. La mayoría del trabajo se hace dentro del sistema.

2.1. El DPO: informes de auditoría y ejercicio de derechos

El delegado de protección de datos necesita exportar datos cuando un paciente ejerce su derecho de acceso —tiene derecho a una copia de sus datos en formato electrónico—. También cuando prepara informes de acceso para una inspección. Son exportaciones puntuales, justificadas por una obligación legal y documentadas.

2.2. El administrador: migraciones y copias de seguridad

El administrador del sistema puede necesitar exportar datos para una migración entre sistemas o para generar una copia de seguridad manual. Son operaciones infrecuentes y planificadas. Una migración se hace una vez; las copias de seguridad automatizadas no requieren exportación manual.

2.3. El médico: informes y derivaciones

Un médico puede necesitar generar un informe de alta o una carta de derivación que el paciente se lleva. En esos casos, lo que se exporta no es la historia clínica completa, sino un documento específico con la información relevante para la derivación. El sistema genera el documento, no exporta la base de datos.

3. El permiso de exportación tiene que ser independiente

El sistema de control de acceso define qué pantallas ve cada rol. Pero la exportación no es una pantalla más: es una acción dentro de una pantalla que tiene consecuencias distintas.

3.1. Pantalla de consulta y botón de exportar: dos permisos

La forma más directa de gestionar la exportación es separar el permiso. La pantalla que muestra los datos del paciente tiene un acceso; la acción que genera un fichero con esos datos tiene otro. Un rol puede tener permiso para consultar la pantalla y no tener permiso para exportar. Esa separación es la que convierte la exportación en una operación controlada en lugar de un efecto secundario de la consulta.

3.2. Por qué no basta con auditar la exportación sin restringirla

Auditar sin restringir significa que cualquiera que pueda consultar puede exportar, y la clínica se entera después. En la mayoría de los casos «después» es suficiente, pero con la exportación no lo es, porque el dato ya está fuera. La restricción previa complementa a la auditoría: primero limitas quién puede exportar, y después registras cada exportación que se haga. Las dos cosas juntas; ninguna sola.

4. Qué sale cuando se exporta: el contenido del fichero

Cuando el sistema genera un fichero de exportación, el contenido depende de qué se exporta y para qué.

4.1. Exportación para el paciente: sus datos, nada más

Cuando un paciente ejerce su derecho de acceso, el fichero contiene sus datos personales y clínicos. No contiene los datos de otros pacientes, ni los registros de auditoría internos, ni la configuración del sistema. Es una extracción limitada al titular y al período solicitado.

4.2. Exportación para auditoría: registros de acceso

Los informes de auditoría contienen quién accedió a qué dato, cuándo y desde dónde. No contienen los datos clínicos del paciente, sino los metadatos del acceso. La distinción es importante: un informe que diga «el doctor García accedió a la ficha de María López a las 14:32» no contiene la ficha de María López, solo el hecho de que se accedió.

4.3. Exportación masiva: cuándo y por qué

La exportación masiva —todos los pacientes, todos los datos— solo tiene sentido en dos escenarios: migración a otro sistema y entrega al responsable del tratamiento en caso de fin de contrato. Fuera de esos escenarios, si alguien necesita exportar todo, hay que preguntar por qué antes de conceder el permiso.

5. El registro obligatorio de cada exportación

Cada exportación genera un registro que dice quién la hizo, cuándo, qué datos incluía y en qué formato. Ese registro no es opcional: es la trazabilidad que permite a la clínica responder si alguien pregunta.

5.1. Qué debe contener el registro

Como mínimo: la identidad del usuario que exportó, la fecha y hora, el alcance de la exportación —qué pacientes, qué período, qué tipo de datos— y el motivo declarado. Si la exportación está vinculada a un derecho del paciente, la referencia a la solicitud. Si es una migración, la referencia al proyecto de migración.

La traza de exportación incluye quién, cuándo, qué datos y en qué formato: si no queda registrado, nadie puede auditar la salida.

5.2. El registro como evidencia ante una inspección

Si la AEPD investiga una brecha, una de las primeras preguntas es quién pudo sacar los datos del sistema. Si la clínica tiene un registro completo de exportaciones, puede responder con precisión. Si no lo tiene, la respuesta es «cualquiera con acceso a la pantalla», y eso no es la respuesta que un inspector quiere oír.

6. El riesgo real de una exportación no controlada

El riesgo no es teórico. Hay casos documentados de empleados que descargaron datos antes de dejar la empresa, de exportaciones masivas sin justificación que se detectaron meses después, de ficheros con datos de pacientes almacenados en dispositivos personales.

6.1. El empleado que se va con los datos

Si un profesional que deja la clínica tiene permiso de exportación y no se le revoca a tiempo, puede descargar datos antes de su última jornada. La gestión de la baja incluye revocar el acceso al sistema, pero si el permiso de exportación no es un permiso separado, no se puede revocar antes: o se cierra la cuenta entera —dejando al profesional sin acceso durante su último período— o se deja como está y se confía en que no exporte nada.

6.2. La exportación que nadie necesitaba

Cuando la exportación no tiene una justificación obligatoria, se usa para cosas que no la necesitan. Un médico que exporta una ficha para «tenerla a mano» en su portátil. Un administrativo que descarga un listado para trabajar en Excel en lugar de en el sistema. Son usos legítimos desde el punto de vista de la intención, pero ilegítimos desde el punto de vista de la protección de datos: el dato está fuera del perímetro sin justificación documentada.

7. Cómo limitar el alcance de la exportación

Limitar el alcance no es prohibir la exportación, sino acotarla a lo que se necesita.

7.1. Exportación por paciente, no en masa

La mayoría de las exportaciones legítimas son de un paciente concreto: un derecho de acceso, una carta de derivación, un informe de alta. El sistema puede ofrecer la exportación unitaria y reservar la exportación masiva para un permiso adicional que solo tengan el administrador y el DPO. Esa separación cubre el 95 % de los casos sin crear fricción.

7.2. Exportación con motivo obligatorio

Antes de generar el fichero, el sistema pide un motivo. No un texto libre de dos palabras, sino una selección entre motivos válidos: derecho de acceso del paciente, derivación, informe de alta, migración, auditoría. El motivo se graba en el registro y se convierte en la justificación que la clínica puede presentar. Si un profesional intenta exportar sin seleccionar motivo, la operación no se ejecuta: el sistema bloquea la descarga hasta que el campo esté cumplimentado. Eso elimina las exportaciones de las que nadie recuerda el porqué, que son precisamente las que más preguntas generan cuando llega una inspección.

8. Qué dice la normativa sobre sacar datos fuera del sistema

La normativa no prohíbe la exportación de datos clínicos, pero exige que sea justificada, limitada y trazable.

8.1. El principio de minimización aplicado a la exportación

El RGPD exige que el tratamiento de datos se limite a lo necesario para la finalidad. Si la finalidad es atender una derivación, lo necesario es el informe de derivación, no la historia clínica completa. Si la finalidad es responder a un derecho de acceso, lo necesario son los datos del titular, no los de todos los pacientes. La exportación tiene que estar proporcionada a lo que se necesita.

8.2. La obligación de registrar

El artículo 30 del RGPD obliga al responsable del tratamiento a mantener un registro de las actividades de tratamiento. La exportación de datos clínicos es una actividad de tratamiento, y como tal, tiene que estar registrada. No hay excepción para exportaciones pequeñas ni para exportaciones con buena intención.

8.3. La responsabilidad cuando el dato sale del sistema

Mientras el dato está dentro del sistema, la responsabilidad de protegerlo es de la clínica. Cuando sale —en un fichero exportado—, la responsabilidad no desaparece: la clínica sigue siendo responsable de haber permitido la exportación, y de que esa exportación estuviera justificada. Si los datos acaban donde no debían, la pregunta no es solo quién los llevó allí, sino quién permitió que salieran.

9. Qué aporta obeliOmed

obeliOmed separa el permiso de consultar del permiso de exportar. La pantalla donde se consulta la historia clínica y la acción que genera un fichero de exportación son dos permisos distintos que se asignan por separado a cada rol.

9.1. Permiso de exportación separado por diseño

El catálogo de roles que viene con la instalación asigna el permiso de exportación solo a los roles que lo necesitan. El médico puede consultar, pero no exportar de forma masiva. El DPO puede exportar los datos de un paciente para responder a un derecho de acceso. El administrador puede exportar para migraciones. Cada rol tiene exactamente lo que necesita.

9.2. Registro automático de cada exportación

Cada exportación genera un evento en el registro de auditoría: quién, cuándo, qué paciente, qué datos y qué motivo. El informe de accesos del DPO incluye una sección específica de exportaciones, separada de los accesos de consulta. No hay exportación silenciosa.