Historia clínica digital: pasos para su implantación

Afecta al control de accesos, a la trazabilidad y a la respuesta ante una solicitud de acceso del paciente.

La implantación de una historia clínica digital en psicología no consiste en escanear documentos ni en contratar una agenda con contraseña. Implica definir qué datos se recogen, quién puede consultarlos, durante cuánto tiempo se conservan y cómo se documenta cada operación. Los datos de salud pertenecen a una categoría especial según el artículo 9 del Reglamento General de Protección de Datos (RGPD). Una configuración defectuosa puede convertir una herramienta administrativa en un punto de exposición clínica y jurídica.

El proceso debe ejecutarse en un orden concreto: analizar el marco normativo, auditar la situación actual, seleccionar el software, diseñar la estructura del expediente clínico electrónico, migrar los datos y verificar el funcionamiento antes de cerrar el sistema anterior.

1. Delimitar el marco normativo antes de elegir el software

La primera decisión no es tecnológica. Es determinar qué obligaciones afectan a la consulta.

En España, la historia clínica psicológica se integra en el tratamiento de datos de salud. El RGPD establece requisitos reforzados para esta categoría. La Ley Orgánica 3/2018, de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD), completa su aplicación en el ámbito nacional. La Ley 41/2002, de Autonomía del Paciente, regula aspectos relacionados con la documentación clínica, el acceso y la conservación de la historia.

Esto tiene una consecuencia práctica: no basta con que una plataforma tenga una política de privacidad genérica. El responsable de la consulta debe poder demostrar que el sistema se ajusta a su tratamiento concreto.

Antes de configurar el primer expediente, hay que fijar cinco elementos:

• Responsable del tratamiento. Normalmente será el profesional o la sociedad que presta la asistencia psicológica y decide para qué se recogen los datos.
• Finalidad. La atención terapéutica no es la misma finalidad que la facturación, el envío de recordatorios o la elaboración de estadísticas.
• Categorías de datos. Deben diferenciarse los datos identificativos, los datos de contacto, la información clínica, los datos de facturación y cualquier información especialmente sensible.
• Perfiles de acceso. El psicólogo, la persona que gestiona la agenda y el proveedor tecnológico no necesitan acceder al mismo contenido.
• Plazo de conservación. La documentación de la historia clínica debe conservarse durante un plazo mínimo de cinco años desde la fecha del alta de cada proceso asistencial, conforme a la Ley 41/2002.

La consulta no debería activar módulos que no pueda justificar. Si el software incluye campañas comerciales, grabación de videollamadas, transcripción automática o análisis estadístico, cada función introduce un tratamiento adicional. El análisis debe hacerse antes de activar la opción, no después de la primera incidencia.

Una historia clínica digital bien implantada limita el acceso por diseño. No confía en que cada usuario recuerde actuar correctamente.

El Registro de Actividades de Tratamiento

El Registro de Actividades de Tratamiento (RAT) documenta cómo se utilizan los datos personales. No es una ficha comercial del proveedor ni un inventario de aplicaciones. Debe describir las operaciones reales de la consulta.

En el tratamiento de historias clínicas psicológicas, el RAT debería identificar, como mínimo:

1. La atención psicológica como actividad principal.

2. La gestión de citas y comunicaciones con pacientes.

3. La facturación y las obligaciones contables.

4. La gestión de posibles reclamaciones o solicitudes de derechos.

5. La relación con proveedores que acceden a los datos.

6. Las categorías de destinatarios y encargados.

7. Los plazos de supresión o conservación.

8. Las medidas técnicas y organizativas aplicadas.

El RAT debe coincidir con la configuración del programa. Si el documento declara que solo el psicólogo accede a las notas clínicas, pero la cuenta de administración puede exportar todos los expedientes, existe una contradicción operativa. En una auditoría, la documentación y la configuración se comparan.

La Evaluación de Impacto

La Evaluación de Impacto en la Protección de Datos (EIPD o PIA, por sus siglas en inglés) analiza los riesgos que un tratamiento puede generar para los derechos de los pacientes. En el caso de los datos psicoterapéuticos, la sensibilidad del contenido exige un análisis específico.

La evaluación no debe limitarse a una frase como el sistema está protegido. Tiene que responder a preguntas verificables:

• ¿Qué ocurre si un empleado consulta un expediente que no necesita?
• ¿Puede un usuario descargar toda la base de datos?
• ¿Se registra quién abre o modifica una nota?
• ¿Existe autenticación de doble factor?
• ¿El proveedor utiliza subencargados?
• ¿Dónde se alojan los servidores?
• ¿Cómo se recuperan los datos tras un borrado accidental?
• ¿Cuánto tarda el proveedor en comunicar una brecha?
• ¿Qué procedimiento se aplica cuando un profesional abandona la consulta?

La EIPD debe producir medidas concretas. Si identifica que todos los usuarios comparten una cuenta, la medida no es recordarles que no compartan contraseñas. Es crear cuentas individuales, aplicar permisos separados y activar la autenticación de dos factores (2FA).

2. Auditar la consulta antes de migrar datos

La migración suele fallar antes de empezar. Se intenta importar toda la información disponible sin clasificarla, sin revisar su calidad y sin definir qué debe conservarse. El resultado es un sistema nuevo con los mismos errores del anterior, pero con una interfaz más moderna.

La auditoría previa debe cubrir tres capas: documentación, procesos y tecnología.

Auditoría de la documentación

Hay que localizar todos los lugares donde se almacenan datos clínicos:

• Carpetas físicas.
• Documentos de texto.
• Hojas de cálculo.
• Correos electrónicos.
• Aplicaciones de mensajería.
• Agendas personales.
• Servicios de almacenamiento compartido.
• Copias de seguridad locales.
• Plataformas de videoterapia.
• Formularios de primera entrevista.

El objetivo no es solo reunir la información. También hay que identificar duplicados, expedientes incompletos, documentos sin fecha y archivos que mezclan varios pacientes. Un expediente clínico electrónico psicología no debe convertirse en un contenedor indiscriminado.

Cada registro debe clasificarse según su función. La cabecera identificativa no tiene el mismo nivel operativo que una nota de evolución. Un justificante de pago no debe estar en el mismo campo que una valoración clínica. La separación permite aplicar permisos y conservar cada elemento con un criterio definido.

Auditoría de procesos

El software debe reflejar el flujo real de la consulta. Conviene describirlo por escrito:

1. Cómo se solicita una primera cita.

2. Qué datos se recogen antes de la sesión.

3. Quién confirma la asistencia.

4. Cómo se documenta la sesión.

5. Cómo se registran cambios en el plan terapéutico.

6. Cómo se emiten facturas.

7. Cómo se gestionan cancelaciones.

8. Cómo se atiende una solicitud de acceso.

9. Cómo se cierra un proceso asistencial.

10. Cómo se conserva o elimina la documentación.

Si el proceso no está definido, cada profesional utilizará el sistema de una manera distinta. Esa variabilidad dificulta la supervisión y aumenta el riesgo de errores.

Auditoría técnica

La revisión técnica debe comprobar las funciones que afectan directamente a la confidencialidad y a la integridad del expediente:

• Cifrado de las comunicaciones.
• Cifrado de la información almacenada.
• Autenticación individual.
• 2FA para perfiles con acceso clínico.
• Control de permisos por rol.
• Registro de accesos y modificaciones.
• Historial de versiones.
• Exportación estructurada de los datos.
• Copias de seguridad.
• Recuperación ante fallos.
• Gestión de usuarios inactivos.
• Bloqueo de sesión.
• Restricción de descargas.
• Gestión de subencargados.
• Localización de los servidores.

El cifrado no sustituye al control de accesos. Un archivo cifrado puede quedar expuesto si todos los usuarios disponen de la misma credencial. Del mismo modo, una contraseña robusta no corrige la ausencia de registros de actividad.

3. Evaluar el proveedor y el contrato de encargado

Cuando la consulta utiliza un software alojado por un tercero, el proveedor actúa normalmente como Encargado del Tratamiento. La relación debe formalizarse mediante un contrato conforme al artículo 28 del RGPD.

El contrato no puede ser una aceptación genérica de términos de uso. Debe describir el tratamiento y limitar las actuaciones del proveedor. Como mínimo, hay que revisar:

• Objeto y duración del servicio.
• Naturaleza y finalidad del tratamiento.
• Tipos de datos tratados.
• Categorías de pacientes.
• Instrucciones documentadas del responsable.
• Obligaciones de confidencialidad.
• Medidas de seguridad.
• Régimen de subencargados.
• Asistencia en el ejercicio de derechos.
• Gestión de incidentes.
• Auditorías.
• Devolución o destrucción de los datos al finalizar el servicio.

La ubicación de los servidores también debe quedar documentada. Para esta implantación, el proveedor debe garantizar el cifrado de los datos y el alojamiento dentro de la Unión Europea. Si utiliza infraestructura de terceros, debe identificarla y explicar el flujo de información.

No debe aceptarse una respuesta comercial imprecisa. Frases como seguridad bancaria, máxima protección o plataforma certificada no describen una medida técnica. El auditor necesita saber qué se cifra, en qué momento, quién administra las claves, qué registros se generan y cómo se recuperan los datos.

Qué debe preguntar una consulta al proveedor

La evaluación puede organizarse en una secuencia breve:

1. ¿Qué datos almacena el sistema?

La respuesta debe incluir bases de datos, documentos adjuntos, copias de seguridad y registros de actividad.

2. ¿Quién puede acceder a la información?

El proveedor debe diferenciar al personal de soporte, los administradores de infraestructura y los usuarios de la consulta.

3. ¿Se puede limitar el acceso por rol?

Un programa adecuado permite restringir las notas privadas, los datos de facturación y la administración de usuarios.

4. ¿Existe 2FA?

Debe poder activarse para todas las cuentas con acceso clínico, no solo para el administrador.

5. ¿Se conserva un registro de accesos?

El sistema debe permitir saber quién consultó, creó, modificó o exportó un expediente.

6. ¿Cómo se notifica una brecha?

El contrato debe fijar un canal y un plazo operativo. La consulta no puede descubrir el incidente cuando un paciente ya ha recibido una comunicación externa.

7. ¿Cómo se recuperan los datos?

Hay que conocer la frecuencia de las copias, su separación del entorno principal y el procedimiento de restauración.

8. ¿Qué sucede al cancelar la cuenta?

Debe existir un mecanismo de exportación y una confirmación sobre la eliminación o devolución de la información.

Una herramienta que no permite responder a estas preguntas no está preparada para custodiar una historia clínica psicológica, aunque gestione bien la agenda.

4. Diseñar la estructura de la historia clínica digital

La estructura del expediente determina el nivel de control que puede aplicar el software. Si todos los datos se introducen en un único campo de texto, el sistema pierde capacidad de clasificación, acceso selectivo y exportación.

Una estructura mínima debe separar cuatro zonas.

Cabecera e identificación

Incluye los datos necesarios para identificar al paciente y gestionar la relación asistencial:

• Nombre y apellidos.
• Datos de contacto.
• Fecha de nacimiento cuando sea necesaria.
• Datos de contacto de emergencia, si procede.
• Información administrativa.
• Estado del proceso asistencial.

Estos datos no deben mezclarse con las observaciones clínicas. La persona que gestiona las citas puede necesitar consultar un teléfono, pero no una nota de evolución.

Anamnesis y evaluación inicial

La anamnesis recoge los antecedentes relevantes para la intervención. El formulario debe adaptarse al modelo de trabajo del profesional. No conviene copiar plantillas extensas que acumulen información sin finalidad clínica.

Cada campo debe justificar su presencia. Si una pregunta no afecta a la evaluación, al plan terapéutico o a la continuidad asistencial, probablemente no debe convertirse en un requisito permanente del expediente.

También hay que controlar los campos libres. Son útiles para el razonamiento clínico, pero dificultan la homogeneidad. Una solución equilibrada combina campos estructurados para los datos recurrentes y texto libre para la información que requiere contexto.

Notas de evolución

Las notas de evolución documentan lo ocurrido en cada sesión y las decisiones asistenciales adoptadas. Deben incorporar fecha, profesional responsable y contenido clínico pertinente.

El sistema debe conservar el historial de cambios. Si una nota puede modificarse sin dejar registro de la versión anterior, se pierde la integridad documental. Corregir un error no debe equivaler a borrar el rastro de la modificación.

La nota tampoco debe funcionar como un diario personal. Debe registrar información necesaria para la asistencia, la continuidad del tratamiento y la justificación de las decisiones profesionales.

Notas privadas o subjetivas

Las anotaciones privadas del profesional deben estar técnicamente separadas de las notas asistenciales. La distinción no es una preferencia de interfaz. Afecta al derecho de acceso del paciente.

La información asistencial puede formar parte de la historia clínica accesible en los términos previstos por la normativa. Las observaciones meramente personales no tienen necesariamente el mismo tratamiento. Si el programa mezcla ambos contenidos, el profesional tendrá dificultades para responder de forma precisa a una solicitud de acceso.

Por eso, el software debe ofrecer un campo específico, con permisos diferenciados y reglas claras de conservación. La separación debe existir desde el diseño inicial. No es fiable intentar clasificar cientos de anotaciones después de una petición del paciente.

Si el sistema no distingue entre nota clínica y anotación privada, la consulta no controla qué expone cuando responde a un derecho de acceso.

5. Gestionar conservación, acceso y trazabilidad

Digitalizar no significa conservarlo todo indefinidamente. El sistema debe incorporar un ciclo de vida del dato.

La fecha relevante para la conservación clínica es la del alta de cada proceso asistencial. La Ley 41/2002 establece un plazo mínimo de cinco años desde ese momento. La consulta debe documentar qué ocurre después: conservación adicional cuando exista una razón válida, bloqueo, supresión o anonimización.

No todos los datos tienen que seguir el mismo ciclo. La documentación clínica, los datos de facturación y los registros técnicos responden a obligaciones distintas. Un programa que solo ofrece un botón general de eliminar no proporciona suficiente control.

Solicitudes de acceso

El paciente puede ejercer sus derechos conforme al marco de protección de datos y a la normativa de autonomía del paciente. La consulta necesita un procedimiento estable:

1. Registrar la solicitud y la fecha de entrada.

2. Verificar la identidad del solicitante.

3. Localizar todos los sistemas donde existan datos relacionados.

4. Separar documentación asistencial, información administrativa y anotaciones privadas.

5. Revisar la existencia de datos de terceras personas.

6. Preparar una copia legible y segura.

7. Registrar la respuesta y los elementos entregados.

El contenido no debe extraerse mediante capturas de pantalla. La exportación debe conservar fechas, autoría, versiones y estructura. Si el software solo genera un documento plano sin metadatos, la consulta debe valorar si esa salida permite acreditar la integridad del expediente.

La diferenciación entre notas asistenciales y observaciones privadas permite responder sin exponer anotaciones personales que no forman parte del contenido clínico accesible. No se debe afirmar, sin analizar el caso, que todas las notas subjetivas deban entregarse íntegramente.

Trazabilidad de los accesos

La trazabilidad responde a una pregunta concreta: qué usuario hizo qué operación y cuándo.

El registro debe contemplar al menos:

• Inicio y cierre de sesión.
• Apertura de expedientes.
• Creación de notas.
• Modificación de información.
• Exportación de documentos.
• Cambios de permisos.
• Alta y baja de usuarios.
• Accesos del soporte técnico.

Registrar no es suficiente. Hay que revisar. Una cuenta de administración que consulta expedientes clínicos a diario puede revelar un problema de permisos. Un volumen anómalo de exportaciones puede indicar una extracción no autorizada.

La revisión puede programarse con una periodicidad definida según el tamaño de la consulta y el número de usuarios. Lo que no debe hacerse es activar el registro y olvidarlo.

6. Migrar los datos al software especializado

La migración requiere una copia controlada, una limpieza previa y una verificación posterior. El orden reduce errores.

Preparar los datos

Antes de importar, hay que establecer una tabla de correspondencia entre el sistema antiguo y el nuevo. Por ejemplo:

• Nombre completo → identificación del paciente.
• Teléfono → contacto.
• Documento de evaluación → anamnesis.
• Registro fechado → nota de evolución.
• Archivo personal del profesional → notas privadas, si el sistema las admite.
• Factura → módulo administrativo.

No debe trasladarse información a un campo distinto solo porque el programa lo permite. Una clasificación incorrecta puede afectar a los permisos y a futuras exportaciones.

También hay que depurar:

• Duplicados.
• Expedientes sin identificación suficiente.
• Archivos ilegibles.
• Documentos de pacientes inactivos.
• Versiones repetidas.
• Adjuntos sin fecha.
• Información que ya no responde a una finalidad válida.

La eliminación debe estar documentada. Borrar sin criterio también puede incumplir las obligaciones de conservación.

Ejecutar una migración piloto

La primera importación debe realizarse con un conjunto limitado y representativo de expedientes. Conviene incluir casos con documentos adjuntos, varias sesiones, cambios de profesional y diferentes estados administrativos.

Después se comprueba:

• Que cada paciente aparece una sola vez.
• Que las fechas se mantienen.
• Que los documentos se abren.
• Que las notas quedan en la sección correcta.
• Que los permisos funcionan.
• Que los registros de actividad se generan.
• Que la exportación produce un resultado legible.
• Que las copias de seguridad incluyen los datos migrados.

La migración piloto debe ejecutarse en un entorno controlado. No se debe modificar el sistema antiguo hasta completar la validación.

Verificar y cerrar

La transición se completa cuando la consulta puede reconstruir un expediente sin consultar el sistema anterior. Durante un periodo definido, puede mantenerse el acceso de solo lectura a la plataforma antigua. Ese acceso debe estar limitado y registrado.

El cierre requiere documentar:

• Fecha de finalización de la migración.
• Responsable de la validación.
• Número de expedientes procesados.
• Incidencias detectadas.
• Datos excluidos y motivo.
• Copias de seguridad realizadas.
• Usuarios autorizados.
• Fecha de retirada o bloqueo del sistema anterior.

No conviene conservar aplicaciones antiguas activas por inercia. Cada sistema adicional amplía la superficie de acceso y complica la respuesta ante derechos, incidentes y solicitudes internas.

7. Formar al equipo y probar el sistema

La formación debe centrarse en operaciones concretas. No basta con explicar dónde está cada botón.

El equipo debe saber:

1. Crear una cuenta individual.

2. Activar y utilizar la 2FA.

3. Seleccionar el expediente correcto.

4. Registrar una sesión en la sección adecuada.

5. Evitar datos clínicos en mensajes o campos administrativos.

6. Separar notas asistenciales y privadas.

7. Compartir documentos mediante el canal aprobado.

8. Informar de un acceso incorrecto.

9. Bloquear la sesión al abandonar el puesto.

10. Responder a una solicitud del paciente sin improvisar.

Las cuentas compartidas deben quedar excluidas. También debe existir un procedimiento para bajas, sustituciones y accesos temporales. Un usuario que deja la consulta conserva un riesgo activo mientras sus credenciales sigan habilitadas.

Las pruebas deben simular errores reales:

• Un usuario administrativo intenta abrir una nota clínica.
• Un profesional exporta un expediente.
• Un paciente solicita acceso.
• Se elimina accidentalmente un documento.
• El proveedor interrumpe el servicio.
• Se pierde un segundo factor.
• Un profesional cambia de consulta.
• Se detecta un acceso fuera de horario.

Cada prueba debe producir una acción correctora. Si el sistema permite una operación que la política interna prohíbe, hay que cambiar la configuración, el procedimiento o la herramienta. Repetir la norma no corrige el fallo técnico.

Errores que degradan una implantación aparentemente correcta

Algunas decisiones se repiten en consultas pequeñas y centros con varios profesionales:

Elegir primero la agenda y añadir después la historia clínica

Una agenda médica digital resuelve citas. No necesariamente resuelve custodia clínica, permisos, trazabilidad o conservación. El criterio de selección debe partir del expediente y de sus riesgos, no del calendario.

Confundir alojamiento en la Unión Europea con cumplimiento automático

Que los servidores estén dentro de la UE no demuestra que el proveedor cumpla todas las obligaciones. Siguen siendo necesarios el contrato de encargado, la configuración de permisos, el cifrado, la gestión de usuarios y la documentación del tratamiento.

Usar el correo electrónico como archivo clínico

El correo puede intervenir en una comunicación concreta. No debe convertirse en la base documental de la terapia. Los mensajes se duplican, se reenvían y pueden quedar accesibles para personas que no necesitan consultar el contenido.

Activar la transcripción o la grabación sin analizar el tratamiento

Una grabación de sesión contiene datos clínicos de alta sensibilidad. La función introduce nuevos riesgos, nuevos proveedores y posiblemente nuevos subencargados. Si no existe una finalidad definida, una base jurídica adecuada y una configuración de seguridad verificable, la función debe permanecer desactivada.

Exportar expedientes completos por comodidad

La exportación masiva amplía el riesgo. Debe limitarse a una finalidad concreta, con permisos específicos y registro de la operación. El archivo descargado necesita el mismo nivel de protección que el sistema original.

Mantener notas privadas en documentos externos

Una carpeta personal sin control de acceso rompe la separación que debería ofrecer el expediente. Las notas privadas, cuando sean necesarias, deben estar ubicadas en un espacio con permisos y reglas de conservación definidos.

El protocolo final de implantación

La puesta en marcha puede cerrarse con una secuencia de control:

• Definir las finalidades y las categorías de datos.
• Actualizar el RAT.
• Realizar la EIPD.
• Inventariar los sistemas existentes.
• Seleccionar el software según sus controles técnicos.
• Formalizar el contrato de Encargado del Tratamiento.
• Confirmar el cifrado y la ubicación de los servidores.
• Diseñar los perfiles de acceso.
• Activar la 2FA.
• Configurar la separación entre cabecera, anamnesis, evolución y notas privadas.
• Preparar la política de conservación.
• Ejecutar una migración piloto.
• Validar permisos, documentos, fechas y exportaciones.
• Formar al equipo.
• Registrar incidencias.
• Migrar el conjunto completo.
• Mantener una fase de verificación.
• Revisar periódicamente accesos, usuarios y copias de seguridad.

La implantación no termina cuando el sistema empieza a funcionar. Termina cuando la consulta puede explicar qué datos trata, quién los consulta, cómo se protegen, cuánto tiempo se conservan y qué sucede cuando un paciente ejerce sus derechos.

La historia clínica digital psicología implantación exige una arquitectura mínima y una disciplina operativa. El software puede cifrar, registrar y restringir. No puede decidir por la consulta qué información necesita, qué usuario debe verla ni cuándo debe dejar de conservarse. Esa responsabilidad permanece en el responsable del tratamiento.

La herramienta adecuada no es la que ofrece más módulos. Es la que permite reducir accesos, documentar decisiones, recuperar información y demostrar control sobre cada etapa del expediente clínico electrónico.