Cómo cambiar de software psicológico sin perder datos ni interrumpir la actividad

Para un psicólogo autónomo, unas pocas horas repartidas a lo largo de varias semanas: la sesión de configuración inicial con el equipo de implementación, la revisión de que los datos de pacientes y bonos están correctos, y la sesión de formación. El resto —importación de datos, configuración técnica— lo hace el equipo de implementación. En centros con varios terapeutas, hay que sumar el tiempo de formación individual de cada uno, aunque el grueso del trabajo técnico sigue sin recaer sobre el equipo clínico.

La portabilidad de datos es un derecho reconocido por el RGPD: el centro es el responsable del tratamiento y tiene derecho a exportar los datos de sus pacientes en un formato legible. Si el proveedor no facilita esa exportación en un formato estándar, está incumpliendo ese principio. La vía razonable es solicitarlo formalmente por escrito a su soporte técnico; si no hay respuesta, cabe una reclamación ante la AEPD. En la práctica, la mayoría de proveedores la facilitan en cuanto se pide explícitamente, porque el problema suele ser de interfaz, no de negativa activa.

Sí, si eso implica un cambio en el encargado del tratamiento de sus datos. El nuevo proveedor pasa a tratar los datos de los pacientes en nombre del centro, así que hay que actualizar la política de privacidad y notificarlo a los pacientes activos. No hace falta un nuevo consentimiento si la base legal del tratamiento no cambia, solo informar del cambio de proveedor y, si aplica, de dónde se alojan ahora los datos. Un aviso breve centrado en la mejora del servicio suele ser suficiente para la gran mayoría de pacientes.

Como documentos adjuntos, sí, aunque no como notas de sesión nativas con todos los campos estructurados del sistema nuevo. La distinción es práctica: los historiales migrados son legibles y consultables en el expediente, pero no editables ni tan estructurados como los que se generan a partir de la migración. Eso significa que, al abrir la ficha de un paciente antiguo, verás sus notas previas en PDF junto con las sesiones nuevas ya en formato nativo. Con el tiempo, la mayoría del historial clínico realmente activo pasa a ser el creado en el sistema nuevo, mientras el migrado queda como referencia del proceso anterior al cambio, sin que desaparezca del expediente.

Durante el periodo en paralelo, sí, sin pérdida de datos, porque el sistema anterior sigue activo y disponible. Una vez cerrado ese periodo y con sesiones nuevas ya creadas en el sistema nuevo, revertir exigiría migrar también esos datos recientes hacia atrás, un proceso bastante más complejo que el cambio original. Por eso el periodo en paralelo importa tanto: da margen real para evaluar el sistema nuevo con datos reales de la propia consulta antes de cerrar cualquier puerta atrás.

Normalmente sí: la exportación del sistema anterior suele incluir tanto pacientes activos como archivados. Los pacientes dados de alta siguen sujetos a la obligación legal de conservación del historial, así que deberían quedar como expedientes archivados en el sistema nuevo aunque no tengan sesiones activas. Para pacientes inactivos que ya han superado el plazo legal de conservación, es razonable no migrarlos y gestionar su supresión directamente en el sistema anterior antes de cancelarlo, en vez de arrastrar un dato que ya no hay obligación de mantener.

No, la migración desde el sistema anterior forma parte de la implementación incluida en la suscripción. El equipo de implementación gestiona la importación de pacientes, la configuración inicial y la verificación posterior de los datos migrados. Tampoco hay coste por la formación del equipo durante esas primeras semanas ni por las sesiones de ajuste fino de la configuración. El único coste real asociado suele venir del lado del sistema anterior, no del nuevo: si ese contrato tiene penalización por cancelación anticipada o un periodo mínimo de permanencia, ese coste existe con independencia de a qué sistema se cambie después, y conviene tenerlo presente al calcular la fecha óptima del cambio.

Revisar sus condiciones de cancelación antes de fijar la fecha de la migración: si hay un periodo de preaviso mínimo, si existe penalización por cancelación anticipada en caso de contrato anual, y si la exportación de los propios datos está incluida en el precio o se cobra aparte. Una vez clara la fecha hasta la que hay que pagar el sistema anterior, conviene planificar la migración para completarla dentro de ese plazo, de modo que no se termine pagando dos sistemas más tiempo del estrictamente necesario.