Cómo migrar historiales clínicos a un nuevo software sin perder datos

1. Por qué migrar historiales da tanto miedo, y qué es razonable temer

1.1. Los miedos que sí tienen fundamento

Perder antecedentes clínicos, que un curso evolutivo quede asociado al paciente equivocado o tener que parar la facturación varios días: son los tres miedos que de verdad frenan a una dirección médica a la hora de cambiar de software. No son irracionales —han pasado en migraciones mal planteadas—, y por eso el proceso descrito en esta guía existe: para que no dependan de la suerte.

Detrás de esos tres miedos suele haber una misma causa: alguien intentó volcar la base de datos antigua directamente sobre el sistema nuevo, sin pasar por un entorno de prueba ni por una revisión previa. Cuando eso sale mal, no falla porque migrar historiales sea imposible de hacer bien, sino porque se saltó el paso que existe precisamente para detectar el problema antes de que llegue a producción.

1.2. Lo que no debería darte miedo, pero lo hace

El coste de la migración en sí y el tiempo del equipo suelen preocupar más de lo necesario, porque casi siempre son menores de lo que se anticipa cuando el proceso está bien planteado: se ejecuta en paralelo a la actividad normal, no en lugar de ella. Lo que sí conviene temer es lo contrario: quedarse en un software que ya no cumple la normativa vigente solo por evitar el proceso de cambio.

Hay un tercer miedo que rara vez se dice en voz alta: que el equipo no se adapte y que la productividad baje durante semanas. Esto depende menos de la tecnología y más de cómo se reparte la formación: cuando cada perfil aprende solo los flujos que va a usar, la curva de aprendizaje se acorta mucho más que con una sesión genérica para todo el mundo a la vez. Conviene incluir ahí el criterio de cómo se trabaja cuando varios profesionales comparten un mismo proceso.

2. El marco legal que toda migración tiene que respetar

2.1. Conservación y trazabilidad de la historia clínica

La Ley 41/2002 obliga a conservar la historia clínica con integridad y trazabilidad, con un plazo mínimo de conservación tras el alta de cada proceso asistencial. Una migración no puede acortar ese plazo ni perder el rastro de quién ha tocado cada expediente: el historial de accesos y cambios tiene que sobrevivir al cambio de sistema igual que los propios datos.

2.2. Portabilidad y categoría especial bajo el RGPD

Los datos de salud son categoría especial según el RGPD, artículo 9, y el artículo 20 reconoce el derecho a la portabilidad: el paciente —y por extensión el centro que custodia sus datos— tiene derecho a que estos se puedan mover. Si un proveedor pone trabas para exportar tus propios datos cuando quieres cambiar de sistema, esa resistencia es en sí misma una señal de alarma, no solo una incomodidad técnica.

Esto también determina quién es responsable durante la propia migración: mientras los datos viajan de un sistema a otro siguen siendo datos de categoría especial, y el proveedor que los recibe pasa a ser encargado del tratamiento desde el primer registro que carga, no solo cuando termina el proceso. Conviene que el contrato de encargado del tratamiento esté firmado antes de que empiece la carga de datos, no como trámite posterior.

3. Antes de migrar: auditoría y depuración de los datos de origen

3.1. Qué revisar antes de mover nada

Antes de tocar el sistema nuevo hay que entender el de origen: en qué formato están los datos —base de datos SQL, ficheros propietarios, papel—, cuántos registros duplicados hay y qué campos llevan años sin normalizar. Saltarse esta auditoría es la causa más frecuente de que una migración se alargue mucho más de lo previsto.

3.2. El vendor lock-in: pídelo por escrito antes de avisar de la baja

Algunos proveedores dificultan el acceso a los datos en cuanto saben que el cliente se va. La norma práctica es exportar primero y avisar de la baja después, y pedir por escrito en qué formato se entregan los datos —idealmente SQL o CSV estándar, no un volcado propietario ilegible fuera de su sistema—. El detalle completo de esta comprobación está en seguridad de datos en software sanitario.

Una parte de los datos casi nunca vive donde se espera: imágenes y documentos adjuntos suelen guardarse en carpetas del servidor local, aparte de la base de datos principal. Si la auditoría solo revisa las tablas SQL y da por hecho que ahí está todo, esos archivos se quedan fuera de la exportación sin que nadie lo note hasta que un paciente pregunta por un informe antiguo que ya no aparece.

4. El checklist técnico, paso a paso

Auditoría, entorno de prueba y puesta en marcha: cada fase se revisa antes de pasar a la siguiente, no se salta ninguna para ir más rápido.

4.1. Auditoría y mapeo de campos

• Inventario de los datos: qué campos existen en el sistema de origen y a qué campo del nuevo sistema corresponde cada uno.
• Consentimientos firmados: comprobar que conservan su vínculo con el paciente y su fecha, no solo el documento suelto.
• Imágenes diagnósticas: si hay estudios DICOM, separarlos del resto de tablas para no ralentizar la carga del resto de datos.

4.2. Migración a un entorno de prueba

• Carga en un entorno aislado: los datos depurados se cargan primero en un entorno de pruebas, no directamente en producción.
• Comprobación con el equipo real: el personal de recepción y los médicos revisan expedientes reales en ese entorno antes del arranque, para detectar algo que la auditoría no vio.

Mientras tanto, la clínica sigue trabajando con normalidad en su sistema actual: nada de esto para la actividad.

4.3. Puesta en marcha

• Ventana de corte: se bloquea el sistema antiguo para nuevas anotaciones durante un periodo corto, normalmente un fin de semana, y se migra el delta final.
• Acceso de lectura al sistema anterior: se mantiene unos días por seguridad, por si hace falta consultar algo que no se detectó antes.

Trabajar en los dos sistemas a la vez más allá de ese periodo corto de transición genera duplicidad de citas y de facturación: por eso la ventana de corte tiene que ser corta y bien planificada, no indefinida.

5. Qué migra y qué no

5.1. Lo que siempre migra

Datos de filiación del paciente, historia clínica estructurada, historial de citas y facturas: esto forma el núcleo del expediente y tiene que migrar siempre, con independencia del volumen. El desglose completo de qué formatos suele tener cada bloque de datos está en migrar de software legacy a la nube sin perder datos.

5.2. Lo que se reconfigura, no se migra

Las tarifas, las plantillas de historia clínica y los usuarios no se importan del sistema antiguo: se crean de nuevo en el nuevo sistema durante la fase de configuración. No es una limitación, es una oportunidad para limpiar configuraciones obsoletas que se habían ido acumulando durante años.

6. Qué gana el centro con un núcleo abierto

6.1. Un núcleo contable abierto, no un formato cerrado

obeliOmed se apoya en un núcleo ERP de código abierto para la parte contable y de facturación, con los módulos clínicos propios de una consulta encima: historia clínica, agenda, consentimientos. Esto evita el problema típico de los sistemas cerrados, donde el formato de los datos solo lo entiende el propio software.

6.2. Propiedad y exportación sin peajes

Al basarse en un motor relacional abierto, la propiedad de las tablas SQL es del centro, no del proveedor: los datos se pueden exportar en cualquier momento sin coste añadido. Es justo la garantía que conviene exigir a cualquier proveedor antes de migrar hacia él, para no volver a encontrarte con el mismo problema en la próxima migración.

Esto tiene una consecuencia práctica poco comentada: si en el futuro decides volver a cambiar de sistema, la exportación no depende de negociar con obeliOmed, porque el formato de tus propios datos ya es un estándar abierto desde el primer día. La migración de entrada no debería ser el único momento en que se piensa en la portabilidad.

7. Seguridad y cumplimiento durante y después de migrar

El cifrado y el alojamiento en España no se interrumpen durante la migración: siguen aplicando desde el primer dato movido.

7.1. Cifrado y alojamiento durante el traslado

Los datos se alojan en servidores situados en España. Los documentos clínicos y los campos marcados como sensibles se cifran con AES-256-GCM, cada tipo de dato con una clave derivada distinta, y la conexión viaja bajo TLS 1.3, también durante el propio proceso de migración.

7.2. Trazabilidad, no bloqueo permanente

Un dato clínico migrado no queda bloqueado de forma permanente: si alguien lo corrige después de la migración, la plataforma registra quién lo hizo, cuándo y qué valor había antes, tal y como exige la Ley 41/2002. obeliOmed no cuenta hoy con una certificación ENS ni ISO 27001, y no se anuncia como si las tuviera: lo verificable es la infraestructura descrita, no un sello.

8. Qué muestra el único caso publicado con cifras auditadas

Es fácil encontrar cifras de migración —«70.000 historias en un fin de semana», «cero minutos de parón»— sin ninguna fuente que las respalde. El caso más detallado que tenemos publicado, con cifras auditadas por la propia dirección del centro, es el de la Clínica Masera: la migración duró cinco semanas para 70.000 historiales repartidos en tres formatos de origen distintos y cuatro especialidades, con el equipo trabajando en paralelo con ambos sistemas los tres primeros días, por seguridad. No es una cifra válida para cualquier clínica —una consulta con un único origen de datos migra en menos tiempo—, pero muestra el orden real del proceso, no una promesa de fin de semana.

9. Qué aporta obeliOmed en la migración y cómo empezar

9.1. Migración incluida, sin coste añadido

La auditoría, la depuración de datos y la carga en el entorno de prueba están incluidas en la implantación, sin coste adicional por volumen estándar de historiales. Lo que puede requerir una valoración aparte es un origen especialmente complejo —varios formatos mezclados, datos muy corruptos—, y en ese caso se presupuesta antes de empezar, no a mitad de proceso. El equipo que ejecuta la migración es el mismo que después da soporte, así que quien conoce tus datos de origen sigue disponible cuando surge una duda semanas después del arranque, en lugar de tener que explicárselo todo de nuevo a otra persona.

9.2. Precio y cómo empezar

Los planes empiezan desde 29 €/⁠mes, con cada módulo adicional facturado aparte. El desglose completo está en la página de precios y planes.