Cómo planificar una migración de EHR sin interrumpir la atención al paciente

Migrar historias clínicas entre sistemas EHR es uno de los proyectos de mayor riesgo que puede encarar un equipo de software de salud. Si sale mal, no es solo una funcionalidad rota: son médicos que no pueden acceder al historial de un paciente, exposición de compliance, y una confianza difícil de reconstruir.

Fui parte del equipo que migró a más de 60.000 pacientes de AthenaHealth a Healthie para Brave Health, un proveedor de terapia y psiquiatría virtual, sin brechas de compliance. Esta es la guía que lo hizo posible.

El riesgo real no es el movimiento de datos

Es tentador tratar una migración de EHR como un problema de ingeniería de datos: extraer los registros, transformarlos al nuevo esquema, cargarlos en el sistema destino. Esa parte importa, pero no es donde realmente fallan las migraciones.

Fallan cuando:

• Un médico entra el día del corte y no encuentra el historial de medicación de un paciente
• Un campo mapea bien en testing pero pierde sentido en producción (un campo de “estado” que significaba una cosa en el sistema viejo y algo sutilmente distinto en el nuevo)
• Nadie validó la integridad de los datos de punta a punta antes de dar de baja el sistema anterior
• El visto bueno de compliance llegó después del trabajo técnico, en vez de en paralelo

La migración técnica es necesaria pero no suficiente. Lo que realmente protege la atención al paciente es el proceso alrededor de ella.

Un enfoque por fases que aguanta la presión

1. Descubrimiento y mapeo, con los médicos en la sala. Antes de escribir código de migración, hay que mapear cada campo, cada flujo de trabajo y cada caso límite con las personas que usan el sistema todos los días, no solo con quienes pidieron la migración. Las diferencias entre cómo “debería” funcionar un sistema y cómo se usa realmente en la práctica son exactamente donde se rompen las migraciones.

2. Validación en paralelo. Correr el sistema nuevo junto al viejo antes del corte, con datos reales (o en modo espejo), y conciliar ambos de forma continua. Ahí es donde se detectan los problemas de mapeo de campos que se ven bien en una especificación pero producen resultados incorrectos con datos del mundo real.

3. Corte por fases, no de una vez. Migrar en cohortes, no todo junto. Empezar con un subconjunto de bajo riesgo, validar a fondo, y después expandir. Si algo se rompe, se rompe para una fracción de la población de pacientes, no para todos.

4. Compliance de HIPAA como chequeo continuo, no como puerta final. La revisión de compliance tiene que pasar en cada fase, no como un visto bueno al final. Para cuando llega el corte, no debería quedar ninguna sorpresa de compliance por encontrar, porque ya se encontraron y resolvieron antes.

5. Monitoreo post-migración con un plan de rollback real. El corte no es la meta. Hay que mantener el sistema viejo accesible y monitorear de cerca las primeras semanas después de la migración, con un plan concreto de qué pasa si hay que revertir algo.

El resultado

Cero brechas de compliance, y una migración que los médicos no tuvieron que pensar porque simplemente funcionó. Esa es la verdadera medida de éxito en un proyecto así: no que los datos se movieron, sino que la atención al paciente nunca lo notó.

Si estás planificando algo similar, lo de mayor impacto que podés hacer es involucrar a compliance y a los stakeholders clínicos desde el día uno, no traerlos a revisar un plan que ya está decidido.