Cuánto cuesta migrar de software clínico: las partidas que no salen en el presupuesto

1. Qué implica migrar de software clínico

1.1. No es instalar un programa: es trasladar una clínica entera

Migrar de software clínico no es copiar archivos de un ordenador a otro. Es trasladar historiales clínicos, plantillas, agendas, tarifarios, permisos de usuario, documentos escaneados, configuraciones de facturación y la forma en que el equipo trabaja con todo eso cada día. El software antiguo organiza la información de una manera; el nuevo la organiza de otra. El trabajo de la migración es convertir la primera en la segunda sin perder nada, sin duplicar nada y sin romper la continuidad del expediente del paciente.

1.2. Cada migración es distinta porque cada clínica ha usado el software de una forma distinta

Dos clínicas con el mismo software de origen pueden tener migraciones muy diferentes: una ha rellenado todos los campos del expediente y la otra solo usa tres. Una tiene diez años de historiales y la otra dos. Una ha creado plantillas propias y la otra usa las de serie. El coste de la migración depende tanto del software de origen como de cómo la clínica lo ha usado, y eso solo se sabe cuando se abre la base de datos y se mira qué hay dentro.

2. Las cinco partidas de una migración

2.1. Exportación, limpieza, importación, formación y convivencia

El coste de una migración se reparte en cinco bloques: sacar los datos del sistema antiguo, limpiar lo que no sirve o está mal, meter los datos en el sistema nuevo, formar al equipo para que trabaje con el nuevo sistema y mantener ambos sistemas abiertos durante las semanas de transición. Cada bloque tiene su propio coste en horas, en dinero y en riesgo, y ninguno se puede saltar sin asumir las consecuencias.

2.2. El coste que nadie presupuesta: la productividad perdida

Las cuatro primeras partidas se pueden presupuestar con cierta precisión. La quinta —la productividad que se pierde durante la transición— es la que más clínicas subestiman y la que más duele. Consultas que se alargan porque el profesional no encuentra lo que busca en el nuevo sistema, citas que se pierden porque la agenda no se migró bien, facturas que se emiten tarde porque el módulo de facturación funciona diferente. Todo eso se paga, aunque no aparezca en ninguna factura del proveedor.

3. El coste de la exportación: sacar los datos del sistema antiguo

3.1. Cuando el sistema antiguo colabora

Algunos software clínicos ofrecen una exportación estructurada de los datos: un archivo CSV, XML o un volcado de base de datos que incluye pacientes, historiales, documentos y configuraciones. Si el software tiene esa opción y la documentación es clara, la exportación es la parte más barata de la migración. Pero «exportar» no siempre significa «exportar todo»: muchos sistemas exportan los datos básicos del paciente pero no las plantillas, los permisos ni los documentos adjuntos, así que conviene comprobar antes qué entrega de serie cada programa, como en qué se puede exportar desde flowww.

3.2. Cuando el sistema antiguo no colabora

Si el software antiguo no ofrece exportación o la condiciona al pago de una tarifa, la clínica tiene un problema. El RGPD reconoce el derecho de portabilidad de los datos, pero ejercerlo puede requerir una solicitud formal al proveedor, un plazo de espera y, en algunos casos, un formato de exportación que no es directamente importable al sistema nuevo. Si el proveedor pone trabas, el coste de la exportación puede multiplicarse por el tiempo legal de resolución y por las horas de adaptación del formato.

3.3. Los documentos adjuntos: el dato que más espacio ocupa y menos estructura tiene

Las imágenes, los PDF de informes, los consentimientos escaneados y las fotografías clínicas pueden representar el grueso del volumen de datos. Exportarlos es fácil si están en una carpeta accesible; importarlos y vincularlos al paciente correcto en el sistema nuevo es otra cosa. Un historial con cien documentos adjuntos necesita que cada uno se asocie al paciente, al episodio y a la fecha correcta, y eso rara vez se hace de forma automática.

4. El coste de la limpieza: lo que no sirve no se migra

4.1. Pacientes duplicados, inactivos y datos incompletos

Cualquier base de datos clínica con más de tres años tiene duplicados, pacientes que no han vuelto desde el primer día y registros con campos vacíos o inconsistentes. Migrar todo eso al sistema nuevo es trasladar el desorden. Limpiarlo antes de migrar tiene un coste en horas —alguien tiene que decidir qué se fusiona, qué se descarta y qué se completa—, pero limpiarlo después cuesta más porque el desorden ya está en el sistema nuevo y afecta a los informes, las búsquedas y la facturación desde el primer día.

4.2. Mapeo de campos: traducir la estructura del sistema antiguo al nuevo

El sistema antiguo puede llamar «observaciones» a lo que el nuevo llama «antecedentes personales». El campo «diagnóstico» puede ser texto libre en uno y codificado en otro. La dirección puede estar en un solo campo o en cinco. Mapear cada campo del sistema antiguo al campo correspondiente del nuevo es un trabajo que parece trivial hasta que se descubren los casos que no encajan: datos que están en el campo equivocado, campos que no existen en el destino o formatos incompatibles que requieren una conversión manual.

5. El coste de la importación: meter los datos en el sistema nuevo

5.1. Importación automática: el mejor caso

Si el sistema nuevo tiene un importador para el formato de exportación del sistema antiguo, la importación es rápida y el coste es bajo. El importador lee el archivo, asocia cada campo y carga los datos. Pero incluso en el mejor caso, la importación automática necesita una verificación: un porcentaje de registros no encaja y se queda en una cola de errores que alguien tiene que revisar a mano. El coste de la importación no es solo el tiempo de la carga, sino el tiempo de la revisión.

5.2. Importación manual: el caso más caro

Si no hay importador y el volumen de datos es grande, la importación se convierte en un proyecto de desarrollo: alguien tiene que escribir un script que lea el formato de exportación, transforme los datos y los cargue en el sistema nuevo. Ese script es un proyecto a medida, y su coste depende de la complejidad de los datos y de la calidad de la exportación. Migrar historiales clínicos no es copiar filas de una tabla a otra: es reconstruir la relación entre pacientes, episodios, pruebas y documentos en una estructura diferente.

6. Formación y reciclaje del equipo

6.1. El equipo no cambia de hábitos por leer un manual

Cada persona de la clínica tiene una forma de trabajar con el software actual: atajos, trucos, un orden de pantallas que ha memorizado. El sistema nuevo rompe todo eso. La formación no es solo enseñar dónde está cada botón, sino conseguir que el equipo deje de buscar las cosas donde estaban antes y las busque donde están ahora. Eso requiere sesiones prácticas con datos reales, no presentaciones genéricas con capturas de pantalla. El coste es el tiempo de las sesiones y el tiempo que el equipo no atiende mientras se forma.

6.2. La formación continua después del arranque

La primera semana con el sistema nuevo genera más preguntas que todas las sesiones de formación juntas. Las dudas aparecen cuando el profesional está delante del paciente y el sistema no hace lo que esperaba. Si no hay un canal de soporte rápido para resolver esas dudas, el profesional busca su propio atajo —a veces correcto, a veces no— y lo convierte en hábito. La formación de las primeras semanas después del arranque es tan importante como la formación previa, y su coste se suma al de la migración aunque nadie lo presupueste por separado.

7. Convivencia de sistemas y caída de productividad

7.1. Las semanas con dos sistemas abiertos

Durante la transición, la clínica trabaja con el sistema antiguo —para consultar historiales que aún no se han migrado— y con el nuevo —para registrar lo que pasa a partir de hoy—. Cada consulta puede requerir abrir los dos, comparar datos y decidir en cuál se registra cada cosa. Esa duplicación tiene un coste directo en tiempo y un coste indirecto en errores: un dato que se registra en el sistema equivocado es un dato que hay que buscar dos veces después.

7.2. La cuesta de la productividad

Las primeras semanas con el sistema nuevo son las más lentas. El profesional tarda más en cada tarea, la recepcionista necesita más pasos para lo mismo y el administrador no encuentra los informes donde antes. Esa caída de productividad es temporal —suele durar entre dos y seis semanas—, pero su coste acumulado puede superar el de la formación. La clínica que planifica la migración para su periodo de menor actividad reduce ese impacto; la que migra en temporada alta lo multiplica.

8. Cómo reducir el coste de la migración

8.1. Preguntar antes de contratar: qué equipos tiene ya integrados el proveedor de destino

Si el proveedor del sistema nuevo ya ha migrado clínicas desde el mismo sistema antiguo que usa la tuya, el coste es menor porque el mapeo de campos, el importador y la experiencia con los problemas habituales ya existen. Preguntar «¿habéis migrado alguna clínica desde X?» antes de firmar puede ser la pregunta que más dinero ahorre de toda la migración.

8.2. Limpiar antes de migrar, no después

Cada duplicado, cada paciente inactivo y cada campo incorrecto que se limpia antes de exportar es un problema menos en la importación. La limpieza previa reduce el volumen de datos que se migran, acelera la importación y mejora la calidad del sistema nuevo desde el primer día. Hacerlo después es más caro porque el sistema nuevo ya tiene informes, búsquedas y automatizaciones que se ven afectadas por los datos sucios.

8.3. Planificar la convivencia y acotar su duración

La convivencia de sistemas debería tener una fecha de fin: un día concreto en el que el sistema antiguo se apaga y todo el mundo trabaja solo con el nuevo. Sin esa fecha, la convivencia se alarga indefinidamente y su coste crece cada semana. Planificar la implantación con plazos cerrados reduce la incertidumbre y obliga a resolver los problemas pendientes antes de que se acumulen.

9. Cómo aborda obeliOmed la migración desde otros sistemas

9.1. Un servicio de migración con presupuesto cerrado

obeliOmed ofrece un servicio de migración asistida: el equipo analiza la base de datos del sistema antiguo, identifica los datos que se van a migrar, realiza la limpieza y la importación, y verifica el resultado con la clínica antes de dar la migración por terminada. El presupuesto es cerrado y se acuerda antes de empezar, no después de terminar.

9.2. Sin atadura: los datos de la clínica son de la clínica

Si en algún momento la clínica decide cambiar de sistema, obeliOmed exporta los datos en un formato estándar y documentado, sin tarifas de salida ni plazos de retención artificial. Los datos se alojan en servidores situados en España, con cifrado AES-256-GCM y retención legal incluida. El retorno de la inversión durante los primeros doce meses empieza a contarse desde el primer día operativo, no desde el día del contrato.