Cómo limpiar datos corruptos antes de migrar de un software médico antiguo

Una forma rápida de comprobarlo es buscar en tu sistema actual el mismo paciente de dos o tres formas distintas —con y sin segundo apellido, con una errata habitual— y ver si aparece más de una vez. Si encuentras duplicados con facilidad en una búsqueda improvisada, es muy probable que el problema sea más extenso de lo que parece a simple vista, y conviene hacer una auditoría más completa antes de migrar. Otra señal útil es preguntar al equipo de recepción si alguna vez han tenido que buscar a un paciente de varias formas distintas antes de encontrarlo: si la respuesta es que sí, con frecuencia, es una confirmación directa de que hay duplicados sin resolver en el sistema.

Sí, cuando la fusión se hace revisando cada caso antes de actuar: el historial completo de ambas fichas se une en una sola, conservando todas las citas, documentos y notas de las dos. El riesgo no está en fusionar bien, sino en fusionar mal dos pacientes que en realidad son personas distintas, por eso cada caso dudoso se revisa a mano antes de confirmar la fusión. Después de fusionar, el historial resultante muestra todas las citas, documentos y notas ordenados cronológicamente como si siempre hubieran estado en la misma ficha, sin ningún rastro visible de que antes eran dos registros separados.

Depende del volumen y de cuánto desorden acumulado tenga el sistema de origen, pero buena parte del proceso se puede automatizar con scripts para las correcciones mecánicas, dejando solo los casos dudosos para revisión manual. Una clínica con datos relativamente ordenados puede resolverlo en pocos días; una con años de inconsistencias acumuladas necesita más tiempo de revisión humana, aunque la parte automatizable sea la misma proporción. En cualquier caso, este tiempo de limpieza ocurre en paralelo a la operativa normal de la clínica con el sistema anterior, así que no supone ninguna interrupción de la actividad mientras se resuelve.

Se marca como pendiente o incompleto, con la fecha y el motivo documentados, en vez de rellenarlo con un valor inventado que parezca correcto sin serlo. Un campo vacío pero honesto es preferible a un campo lleno con un dato que nadie puede verificar, porque el segundo caso genera una falsa sensación de completitud que puede llevar a decisiones erróneas más adelante. Con el tiempo, algunos de estos campos pendientes se resuelven de forma natural, por ejemplo cuando el paciente vuelve a la consulta y se le puede preguntar directamente por el dato que faltaba.

Sí, y es precisamente antes de migrar cuando conviene hacerlo, no después. Migrar datos sucios a un sistema nuevo no resuelve el problema: lo traslada, y además lo hace más difícil de corregir después, porque el sistema nuevo ya habrá empezado a generar informes, facturas y automatizaciones basadas en esos datos incorrectos. Un paciente duplicado en el sistema antiguo se convierte en dos recordatorios de cita distintos en el nuevo; un código de acto mal escrito genera una línea de facturación que no cuadra con el tarifario. Corregir estos problemas después de migrar cuesta más tiempo y más esfuerzo que resolverlos antes, porque ya no solo es limpiar el dato: es deshacer todo lo que el sistema nuevo construyó encima.

Es posible, sobre todo si tienes acceso técnico al sistema antiguo y algo de tiempo, pero conviene tener en cuenta que las correcciones mecánicas son la parte fácil: los casos dudosos de duplicados y datos ambiguos requieren conocer bien a los pacientes de la clínica para decidir correctamente. Muchos proveedores, incluido obeliOmed, incluyen este proceso como parte de la implementación precisamente porque combinar herramienta técnica con conocimiento del centro da mejores resultados que hacerlo solo con una de las dos partes por separado.

En la mayoría de los casos sí, porque suelen seguir un patrón identificable: una codificación de caracteres antigua que convirtió letras acentuadas o eñes en símbolos extraños de forma sistemática. Detectado el patrón, se puede corregir de forma masiva con un script, aunque conviene revisar una muestra después para confirmar que la corrección no ha introducido errores nuevos en textos que ya estaban bien. Este tipo de corrección masiva es exactamente el ejemplo de tarea mecánica que se automatiza con seguridad: el patrón es consistente y la respuesta correcta no depende de interpretar ningún contexto particular de cada ficha.

Se documentan aparte, y se decide caso por caso si tiene sentido conservarlos como referencia histórica o descartarlos, siempre con el visto bueno del centro. No se migran automáticamente al sistema nuevo sin revisión, porque un registro sin vinculación clara puede generar confusión en vez de aportar valor si se traslada tal cual. En la mayoría de los casos, estos registros huérfanos resultan ser restos de operaciones incompletas del sistema antiguo —una cita que se creó y luego se borró mal, por ejemplo— y no representan ninguna pérdida real de información al descartarlos.