Migración de datos clínicos: pasos previos para evitar pérdidas

El traslado afecta a historiales, documentos adjuntos, notas evolutivas, consentimientos, citas, facturas y comunicaciones con pacientes. Cada elemento puede utilizar un formato distinto. Cada conversión puede alterar su estructura.

El error más frecuente es cancelar el software antiguo después de obtener una exportación. Exportar no equivale a recuperar. Un archivo puede abrirse y seguir incompleto. Un PDF puede conservar el texto, pero perder metadatos. Un CSV puede incluir pacientes, pero omitir relaciones entre citas, documentos y procesos asistenciales.

La consecuencia no es solo operativa. La Ley 41/2002 exige conservar la historia clínica durante un mínimo de cinco años desde el alta de cada proceso asistencial. Además, el RGPD obliga a controlar quién accede a esos datos, con qué finalidad y bajo qué condiciones contractuales. Las infracciones graves relacionadas con historiales clínicos pueden alcanzar sanciones desde 40.000 euros.

Una exportación que no se ha cargado, reconciliado y revisado no es una copia de seguridad. Es una hipótesis.

Auditoría y preparación: el mapa de tus expedientes antes del traslado

Antes de elegir un método de migración, hay que conocer el contenido real del sistema de origen. El proveedor puede hablar de una exportación completa. Ese término no tiene valor técnico si no especifica qué entidades incluye, en qué formato y con qué relaciones.

La auditoría debe identificar, como mínimo:

• Fichas identificativas de pacientes.
• Historias clínicas y cursos evolutivos.
• Documentos adjuntos.
• Consentimientos informados.
• Citas pasadas y futuras.
• Recordatorios y comunicaciones.
• Facturas, recibos y estados de pago.
• Usuarios internos y permisos.
• Etiquetas, categorías y campos personalizados.
• Registros de actividad o auditoría.
• Copias de documentos firmados.
• Historial de mensajes o chat.

No todos estos datos tienen el mismo riesgo de pérdida. Los registros estructurados suelen exportarse con mayor facilidad. Los adjuntos, las notas sin formato normalizado y los mensajes presentan más problemas. Pueden quedar fuera de la exportación, perder su relación con el paciente o aparecer como ficheros aislados sin contexto clínico.

El inventario debe distinguir datos clínicos y administrativos

Una migración no debe tratar todos los registros como una sola tabla. El expediente clínico tiene una lógica distinta de la agenda o la facturación.

Un paciente puede tener varias citas, varios documentos y más de un proceso asistencial. Una nota clínica puede estar vinculada a una fecha concreta, a un profesional y a una intervención. Si la plataforma nueva importa solo el texto, pero no conserva la fecha o el autor, la información pierde valor probatorio y operativo.

Conviene elaborar un inventario con esta estructura:

El inventario permite formular preguntas concretas al proveedor de origen:

1. ¿Qué módulos se pueden exportar?

2. ¿La exportación incluye todos los pacientes o solo los activos?

3. ¿Se incluyen los registros eliminados o archivados cuando existe una obligación de conservación?

4. ¿Los documentos mantienen su nombre, fecha y relación con el expediente?

5. ¿Las notas clínicas se exportan como texto editable, PDF o ambos?

6. ¿Se conservan las fechas originales y el autor de cada anotación?

7. ¿Se exportan los mensajes y las comunicaciones?

8. ¿Se incluyen los datos de facturación?

9. ¿Existe un límite de tamaño o número de archivos?

10. ¿Cuándo se purgan los datos después de cancelar la suscripción?

La respuesta debe quedar documentada. Las promesas comerciales no sustituyen una especificación de exportación.

Localiza los registros que no pueden desaparecer

La obligación de conservación no se resuelve manteniendo una cuenta activa sin más. Hay que asegurar que la documentación clínica pueda recuperarse, leerse y asociarse correctamente al paciente y al proceso asistencial correspondiente.

La Ley 41/2002 fija, con carácter general en España, un plazo mínimo de cinco años desde el alta de cada proceso asistencial. Este plazo no convierte todos los datos de la consulta en equivalentes. La historia clínica, los documentos asociados y la información necesaria para reconstruir la asistencia requieren un tratamiento más estricto que una etiqueta interna o un recordatorio administrativo.

Si existen dudas sobre plazos adicionales, normativa autonómica, obligaciones profesionales o documentación específica, el análisis debe escalarse a asesoramiento jurídico especializado. No conviene reducir una obligación de conservación a la duración de la suscripción contratada.

Protocolos de extracción: formatos universales y riesgos de desestructuración

Los formatos de exportación de datos psicológicos más compatibles suelen ser CSV, XLSX y PDF. Cada uno resuelve una parte distinta del problema.

• CSV: útil para datos tabulares. Puede contener pacientes, citas, etiquetas o campos simples. No conserva bien relaciones complejas, estilos ni documentos incrustados.
• XLSX: facilita la revisión manual y permite trabajar con varias hojas. Sigue dependiendo de una estructura tabular y puede introducir errores al transformar fechas, identificadores o valores vacíos.
• PDF: adecuado para preservar la apariencia de historiales, informes y consentimientos. No siempre permite reutilizar el contenido como dato estructurado.
• Archivos adjuntos originales: deben conservarse con su identificador y su vínculo al paciente. Un directorio lleno de documentos sin relación verificable no constituye una migración completa.

No existe un archivo propietario universal que todos los programas de psicología importen directamente. Cada plataforma define sus propios campos, relaciones y reglas de validación. Por eso, el traslado de historial clínico digital puede requerir una transformación intermedia.

La exportación debe hacerse en más de una forma

Una práctica prudente consiste en obtener:

1. Una exportación estructurada en CSV o XLSX.

2. Una copia documental en PDF de los historiales que deban conservar su presentación.

3. Los archivos adjuntos en su formato original.

4. Un listado de correspondencias entre identificadores, pacientes y documentos.

5. Un registro de la fecha, usuario y método utilizado para generar la exportación.

6. Una copia local cifrada y con acceso restringido.

La copia local no sustituye a las medidas del proveedor. Añade control. Permite comprobar el contenido sin depender de que la plataforma antigua siga operativa. Debe cifrarse, limitarse a las personas autorizadas y conservarse durante el tiempo necesario para completar la verificación.

No se debe guardar una copia clínica en un ordenador compartido, una memoria USB sin cifrado o una carpeta personal de almacenamiento en línea. El problema no es solo el robo del dispositivo. También existe riesgo de sincronización automática, accesos heredados, duplicación no controlada y eliminación accidental.

Verifica la extracción antes de transformar nada

La primera comprobación debe ser cuantitativa. El número de pacientes exportados debe poder compararse con el número de pacientes existente en el sistema de origen. Lo mismo se aplica a citas, documentos, facturas y otros módulos.

No basta con comparar totales. Hay que seleccionar una muestra de expedientes y revisar:

• Identificación del paciente.
• Fecha de alta o apertura del expediente.
• Número y fecha de las sesiones registradas.
• Notas clínicas.
• Documentos adjuntos.
• Consentimientos.
• Citas futuras.
• Comunicaciones relevantes.
• Facturación asociada, si se migra.
• Estado del expediente: activo, archivado o cerrado.

La muestra debe incluir casos sencillos y casos complejos. Un expediente con una sola nota no revela los problemas de un paciente con años de evolución, múltiples documentos y cambios de profesional.

Limpieza y transformación: corregir sin alterar la historia clínica

La migración exige limpiar datos. Eso no significa reescribir la historia clínica. Significa corregir inconsistencias técnicas que impedirían importar o localizar los registros.

Hay que diferenciar entre:

• Corrección técnica: normalizar un formato de fecha o eliminar espacios invisibles.
• Corrección administrativa: fusionar duplicados confirmados.
• Modificación clínica: cambiar el contenido de una nota o diagnóstico.

Las dos primeras pueden formar parte del proceso de transformación. La tercera no debe ejecutarse como una tarea automática de migración. Una nota clínica no es un campo defectuoso porque contenga texto libre, abreviaturas profesionales o una estructura que el nuevo programa no reconozca.

Problemas habituales durante la limpieza

Los errores más comunes aparecen en estos puntos:

• Pacientes duplicados por variaciones en nombre, teléfono o correo electrónico.
• Fechas interpretadas con formatos distintos.
• Campos vacíos convertidos en valores como “0”, “N/A” o una fecha ficticia.
• Caracteres especiales dañados por una codificación incorrecta.
• Números de teléfono con prefijos inconsistentes.
• Documentos con nombres repetidos.
• Adjuntos sin extensión o con extensiones incorrectas.
• Notas clínicas partidas en varias columnas.
• Saltos de línea eliminados.
• Citas canceladas importadas como confirmadas.
• Profesionales asignados a usuarios inexistentes en el sistema nuevo.

La normalización debe producir un registro de cambios. El equipo tiene que poder responder qué se modificó, por qué, cuándo y mediante qué regla. Sin esta trazabilidad, una alteración puede confundirse con un dato original.

No fusiones duplicados solo por coincidencia nominal

Dos registros con el mismo nombre no representan necesariamente al mismo paciente. La identificación debe apoyarse en varios campos y, cuando sea necesario, en una revisión manual.

Un algoritmo puede detectar candidatos a duplicado. No debería decidir por sí solo la fusión de expedientes clínicos. Un error de asociación puede mezclar información de dos personas. Ese fallo afecta a la confidencialidad, a la integridad de los datos y a la seguridad clínica.

La fusión debe conservar:

• El identificador de los registros originales.
• La fecha de la decisión.
• La persona que la autoriza.
• Los campos combinados.
• Los posibles conflictos.
• La relación de documentos afectados.

Si no se puede demostrar que dos registros pertenecen a la misma persona, se mantienen separados hasta resolver la discrepancia.

Cumplimiento normativo: RGPD, encargados del tratamiento y conservación

En una consulta de psicología, el responsable del tratamiento suele ser el psicólogo o la clínica. El proveedor del software actúa como encargado del tratamiento cuando procesa los datos siguiendo instrucciones del responsable. Esta diferencia no es formal. Define quién debe gobernar el tratamiento y quién debe ejecutar las medidas pactadas.

El cambio de plataforma puede implicar un cambio de encargado del tratamiento. Según el artículo 13 del RGPD, si el traslado de datos personales de pacientes activos a un nuevo proveedor modifica la información relevante del tratamiento, hay que informar a esos pacientes conforme a las obligaciones de transparencia aplicables.

La migración no debe iniciarse sin revisar:

• El contrato con el proveedor saliente.
• El acuerdo de encargo de tratamiento.
• El contrato con el proveedor entrante.
• Las instrucciones de exportación y eliminación.
• Las subcontrataciones comunicadas.
• La ubicación de los servicios y las transferencias internacionales, si existen.
• Los controles de acceso.
• Las medidas de cifrado.
• El procedimiento de notificación de brechas.
• Los plazos de devolución y supresión de datos.

El contrato de salida importa tanto como el de entrada

El proveedor saliente debe especificar cómo devuelve los datos y cuándo elimina sus copias. Una purga definitiva puede producirse aproximadamente treinta días después de la baja de la suscripción, según las condiciones del servicio. Ese plazo no debe darse por supuesto. Hay que confirmarlo por escrito.

La devolución debe cubrir todas las categorías necesarias. Si el proveedor solo entrega pacientes en CSV, pero excluye documentos, mensajes y registros de auditoría, la entrega es parcial. La consulta necesita conocer exactamente qué queda fuera.

También debe determinarse si existen copias de respaldo. El proveedor puede mantenerlas durante un periodo adicional por razones de continuidad o recuperación. Eso no autoriza una conservación indefinida. El contrato debe describir el ciclo de borrado y las condiciones de acceso durante ese periodo.

El cambio de proveedor requiere actualizar la información al paciente

La transparencia no consiste en enviar un aviso genérico sobre mejoras del servicio. El paciente debe poder entender quién tratará sus datos, con qué finalidad y cómo ejercer sus derechos dentro del nuevo esquema.

La información debe coordinarse con la documentación de privacidad de la consulta. Si el cambio no altera las finalidades ni las categorías de datos, el análisis será distinto que si también se modifica el alojamiento, la gestión de citas, la mensajería o la facturación.

La consulta debe conservar evidencias de la información facilitada y de la fecha en que se realizó. No es necesario convertir la migración en una comunicación comercial. Es una modificación operativa del tratamiento de información de salud.

Fases técnicas de la transferencia: de la limpieza a la conciliación en QA

Una migración controlada debe dividirse en cinco fases: evaluación, extracción, limpieza y transformación, carga y verificación. Saltarse una fase no acelera el proceso. Traslada el riesgo a la siguiente.

1. Evaluación y auditoría

En esta fase se define el alcance. Se identifican módulos, formatos, relaciones, restricciones y datos que no pueden quedar fuera.

El resultado debe ser un documento operativo con:

• Inventario de datos.
• Requisitos legales y contractuales.
• Mapa de correspondencias entre campos.
• Lista de elementos incompatibles.
• Criterios para tratar duplicados.
• Método de respaldo.
• Responsables de cada aprobación.
• Calendario de pruebas.
• Condiciones para mantener activo el sistema antiguo.

No se debe contratar una migración a medida sin cerrar este alcance. La complejidad depende de la estructura real de la base de datos. El precio o la duración no pueden estimarse de forma fiable con una descripción comercial genérica.

2. Extracción

La extracción debe ejecutarse desde el sistema de origen con una cuenta autorizada y trazable. Se generan los archivos previstos y se calcula su integridad mediante mecanismos técnicos apropiados, como sumas de comprobación cuando el proveedor los facilite.

La consulta debe guardar:

• Fecha y hora de cada exportación.
• Usuario que la ejecutó.
• Archivos generados.
• Tamaño de los archivos.
• Formato utilizado.
• Incidencias comunicadas por el proveedor.
• Confirmación de que no existen módulos pendientes.

Si se generan varias exportaciones, no se deben mezclar sin control. Cada versión debe identificarse. Una segunda extracción puede incluir nuevas citas o notas y no ser idéntica a la primera.

3. Limpieza y transformación

Aquí se normalizan campos y se prepara el modelo de datos de la plataforma nueva. El equipo debe conservar la información original y trabajar sobre una copia transformada.

Las reglas deben estar aprobadas antes de ejecutarse. Por ejemplo:

• Cómo se transforman las fechas.
• Cómo se representan los campos vacíos.
• Cómo se asignan profesionales.
• Cómo se nombran los documentos.
• Cómo se conserva el texto libre.
• Cómo se tratan los pacientes duplicados.
• Cómo se importan las citas canceladas.
• Cómo se vinculan los adjuntos a cada expediente.

Las notas clínicas no deben resumirse, fragmentarse ni corregirse lingüísticamente durante una conversión automática. Si el software nuevo impone campos obligatorios que no existían antes, se documenta la limitación. No se inventan valores para satisfacer el formulario.

4. Carga en un entorno de pruebas

La primera importación debe realizarse en un entorno de prueba o en una instancia aislada. El objetivo es detectar errores antes de que la información se convierta en parte del trabajo diario.

La carga debe probar diferentes perfiles:

• Administrador.
• Psicólogo.
• Profesional sin permisos sobre todos los expedientes.
• Personal administrativo.
• Usuario con acceso limitado a agenda o facturación.

El expediente debe mostrar solo lo que corresponde a cada rol. Una migración que conserva los datos, pero amplía el acceso de usuarios, no ha sido validada correctamente.

5. Verificación y conciliación

La conciliación compara origen y destino. Debe combinar recuentos globales con revisión de expedientes concretos.

Una matriz útil puede incluir:

La columna de diferencia no debe ocultarse con una fórmula que fuerce el resultado a cero. Si existen discrepancias, se registran y se resuelven.

Cómo validar la integridad de los expedientes

La validación debe incluir casos representativos:

1. Un expediente con una sola sesión y sin adjuntos.

2. Un expediente con varias sesiones y notas extensas.

3. Un expediente con documentos en distintos formatos.

4. Un expediente con citas futuras y canceladas.

5. Un expediente archivado.

6. Un expediente con más de un profesional.

7. Un expediente con comunicaciones o mensajes.

8. Un registro con datos incompletos o duplicados potenciales.

Cada caso debe comprobarse en pantalla y, cuando sea posible, mediante exportación desde el sistema nuevo. Si el sistema permite exportar lo importado, se puede comparar el resultado con la copia inicial.

La revisión debe verificar también las fechas. Un desplazamiento de día por una interpretación incorrecta del formato puede alterar la secuencia clínica. Lo mismo ocurre con las horas de las citas, especialmente cuando el software aplica zonas horarias o conversiones automáticas.

Seguridad durante la migración: accesos, cifrado y trazabilidad

La seguridad en la migración de pacientes depende del recorrido completo de los datos. No basta con que ambas plataformas anuncien cifrado en reposo. Hay que proteger la exportación, el almacenamiento temporal, la transferencia, la importación y las copias intermedias.

Las medidas mínimas deben cubrir:

• Acceso restringido al equipo que ejecuta la migración.
• Autenticación multifactor, preferiblemente 2FA, para cuentas administrativas.
• Cifrado de copias locales.
• Transferencia mediante canales protegidos.
• Eliminación segura de archivos temporales.
• Registro de accesos y operaciones.
• Separación entre datos de prueba y datos reales cuando sea posible.
• Prohibición de usar herramientas personales no autorizadas.
• Revisión de permisos después de la importación.
• Confirmación documentada de la supresión en el proveedor saliente.

La autenticación de dos factores no corrige una mala asignación de permisos. El cifrado no evita que un usuario autorizado descargue todos los expedientes. Cada control mitiga un riesgo distinto.

No utilices datos clínicos reales para pruebas sin necesidad

El entorno de pruebas debe contener solo los datos necesarios. Si la plataforma permite anonimizar o seudonimizar los registros, esa opción debe valorarse antes de cargar expedientes completos.

Anonimizar no es cambiar el nombre visible y mantener el mismo teléfono, correo electrónico y documento identificativo. La reidentificación puede seguir siendo trivial. La seudonimización conserva una relación reversible mediante una clave separada. Por tanto, continúa existiendo tratamiento de datos personales.

Si se usan datos reales, el acceso debe limitarse, registrarse y justificarse. Tras completar la prueba, las copias deben eliminarse conforme al procedimiento aprobado.

Estrategia de solapamiento: por qué mantener ambos sistemas activos durante un mes

La baja inmediata del software antiguo crea un punto de no retorno. Si la importación contiene errores, la consulta pierde la posibilidad de contrastar los registros en condiciones normales.

Se recomienda mantener un periodo de convivencia de al menos un mes entre la plataforma antigua y la nueva. El objetivo no es duplicar indefinidamente el trabajo. Es detectar incidencias que solo aparecen durante la actividad diaria:

• Citas creadas o modificadas después de la primera extracción.
• Nuevos pacientes.
• Notas añadidas durante la transición.
• Cambios en documentos.
• Facturas emitidas o rectificadas.
• Mensajes pendientes.
• Problemas de permisos.
• Dificultades para localizar expedientes.
• Errores de integración con agenda o facturación.

Durante el solapamiento hay que definir un sistema de registro. Si una cita se modifica en la plataforma antigua y no se replica en la nueva, la discrepancia debe quedar anotada. Si una nota se incorpora a un expediente durante el periodo de transición, debe establecerse qué sistema actúa como fuente principal y cómo se incorpora el cambio.

Evita trabajar en dos sistemas sin una regla de autoridad

Mantener dos plataformas activas no significa que ambas sean igualmente válidas para cualquier operación. Esa ambigüedad genera duplicados y contradicciones.

Una política temporal puede establecer:

• La plataforma nueva gestiona las citas futuras.
• La plataforma antigua se consulta para verificar históricos no conciliados.
• Las notas clínicas nuevas se registran solo en el sistema designado.
• Las facturas se emiten desde una única plataforma.
• Los documentos recibidos se incorporan siguiendo un procedimiento único.
• Cada incidencia se registra con fecha, paciente afectado y resolución.

La decisión debe comunicarse a todas las personas con acceso. Un protocolo desconocido no controla el proceso.

Al finalizar el periodo de solapamiento, se realiza una última extracción incremental o una revisión equivalente. Después se valida la supresión o el bloqueo del acceso en el proveedor antiguo según las obligaciones de conservación y las condiciones contractuales.

Errores que invalidan una migración

Algunos fallos se repiten porque reducen el proceso a una tarea administrativa.

Cancelar antes de verificar

Es el error más grave. La baja puede activar la purga de datos y eliminar información que no se había detectado como necesaria. La exportación debe estar cargada y conciliada antes de cancelar.

Aceptar una exportación parcial como completa

Un archivo con pacientes no demuestra que incluya historias, documentos, comunicaciones y facturas. El alcance debe detallarse por módulos.

Importar todos los datos sin revisar permisos

La migración puede convertir a un usuario administrativo en alguien con acceso a historiales completos. La revisión de roles forma parte de la validación, no de una tarea posterior.

Corregir notas clínicas durante la transformación

La limpieza técnica no autoriza a modificar el contenido asistencial. El sistema nuevo debe adaptarse al registro existente o conservarlo como documento íntegro.

Fusionar duplicados automáticamente

Un algoritmo de coincidencia puede detectar posibles duplicados. No debe decidir sin revisión cuando existe riesgo de mezclar expedientes.

Mantener copias sin inventario

Las copias en ordenadores, discos, carpetas temporales y servicios de transferencia también contienen datos de salud. Deben localizarse y eliminarse cuando termine su finalidad.

Confiar en el marketing del proveedor

Expresiones como migración sencilla, importación completa o cambio sin interrupciones no describen un procedimiento. Exige formatos, módulos, límites, responsables y evidencias.

Orden de actuación recomendado

La secuencia correcta reduce el riesgo y evita decisiones irreversibles:

1. Revisar obligaciones y contratos. Identifica el responsable, los encargados, los plazos de conservación y las condiciones de devolución y borrado.

2. Inventariar el sistema antiguo. Cuenta pacientes, historias, documentos, citas, facturas, mensajes y usuarios.

3. Solicitar una especificación de exportación. Exige formatos, módulos incluidos, relaciones conservadas y limitaciones.

4. Generar una copia local cifrada. Restringe el acceso y registra quién la crea.

5. Extraer en CSV, XLSX, PDF y formatos originales cuando proceda. No dependas de un único archivo.

6. Comprobar recuentos y muestras. Verifica que la exportación contiene lo que el proveedor afirma.

7. Definir reglas de transformación. Documenta fechas, duplicados, campos vacíos, documentos y permisos.

8. Cargar en QA. No uses la plataforma nueva como entorno de prueba improvisado.

9. Conciliar origen y destino. Compara totales, expedientes complejos, documentos y citas.

10. Mantener el solapamiento operativo. Conserva ambos sistemas activos al menos un mes mientras se registran incidencias.

11. Ejecutar una revisión final. Incluye altas, cambios y documentos generados durante la transición.

12. Cerrar el servicio antiguo con evidencias. Confirma la devolución, la supresión y el tratamiento de copias de respaldo.

La migración de datos clínicos a software de gestión es un proyecto de control de información. La plataforma nueva solo es una parte. El resultado depende de la calidad de la exportación, de la transformación, de los permisos y de la capacidad de demostrar que ningún expediente relevante ha desaparecido.

La regla operativa es simple: no se cancela el sistema antiguo porque la descarga ha terminado. Se cancela cuando la nueva plataforma contiene los datos necesarios, los expedientes han sido conciliados, los accesos se han revisado y la conservación legal sigue garantizada. Hasta ese momento, la migración no está cerrada.