Todo proyecto de integración, migración tecnológica y adopción de estándares termina enfrentando la misma pregunta: ¿cómo llevamos los datos del modelo que tenemos al modelo que necesitamos? La pregunta parece simple. En la práctica, es donde la mayoría de los proyectos pierden tiempo, introducen errores y acumulan deuda técnica. Nos especializamos en resolverlo bien.
El error más común es tratar el mapeo de datos como una tarea técnica en lugar de una tarea de diseño — pasar directamente a escribir código de transformación sin entender primero qué significan los datos en cada sistema.
Dos sistemas pueden almacenar lo que parece el mismo campo con el mismo nombre, pero representar conceptos distintos, usar unidades diferentes o seguir convenciones de codificación distintas. Los mapeos campo a campo que ignoran la semántica producen datos que parecen correctos pero significan algo diferente en el destino.
Registros incompletos, entradas duplicadas y valores que no se transformaron correctamente suelen descubrirse semanas después de que una migración entra en producción, cuando los usuarios empiezan a usar el nuevo sistema y notan que los datos no se ven bien.
Los mapeos construidos sin documentación formal se convierten en cajas negras. Cuando los datos no se ven bien en el destino, nadie puede rastrear las reglas de transformación para saber por qué. Cualquier cambio futuro en cualquiera de los sistemas puede romper el mapeo sin que nadie lo note.
Abordamos el mapeo de datos como una disciplina de diseño: primero los conceptos, luego los datos. Analizamos qué significa cada campo en contexto, identificamos las brechas semánticas y producimos mapeos documentados, comprobables y mantenibles, ya sea que los implemente tu equipo o nosotros.
Antes de diseñar cualquier mapeo, hay que entender el modelo de origen. Analizamos las fuentes de datos existentes — incluidos sistemas sin documentación formal — y producimos una descripción clara del modelo: qué representa cada entidad y campo, qué valores son válidos, cómo se relacionan los registros y dónde están los problemas de calidad. Esta es la base sobre la que se construye todo lo demás.
Mapeamos conceptos antes de mapear datos. Esto implica identificar qué concepto del origen corresponde a qué concepto en el destino, resolver diferencias terminológicas, manejar conceptos ausentes o divididos, y documentar cada decisión. Los mapeos conceptuales son la especificación que deben implementar los mapeos técnicos, y el registro de auditoría que explica por qué los datos se ven como se ven tras la transformación.
Del mapeo conceptual derivamos reglas de transformación precisas: cómo se convierte cada campo, qué ocurre con los valores ausentes, cómo se traducen los conceptos codificados y cómo se resuelven las diferencias estructurales entre modelos. Entregamos las reglas como documentación formal. También podemos implementarlas, entregando un mapeador de datos funcional y probado que tu equipo puede operar y extender.
Cuando un cambio tecnológico o una consolidación requiere mover datos históricos a un nuevo sistema, diseñamos y ejecutamos la migración completa: análisis de origen, mapeo conceptual, diseño de transformaciones, staging y carga, y verificación post-migración. Gestionamos migraciones hacia destinos basados en estándares como openEHR y FHIR, donde el modelo destino tiene requisitos estructurales y semánticos específicos.
Después de cargar los datos en el sistema destino, los verificamos. Revisamos completitud (ningún registro perdido), unicidad (ningún duplicado introducido), consistencia (los registros relacionados permanecen coherentes) y corrección semántica (los valores significan lo que deben significar en el modelo destino). Entregamos un informe de auditoría que da a la organización confianza en que la migración fue exitosa, y documenta todo lo que no pudo resolverse completamente.
Mapear hacia openEHR, FHIR o HL7 requiere más que conocer la especificación destino. Requiere entender la semántica clínica detrás de las estructuras de datos del estándar y tomar decisiones justificadas cuando el origen no encaja de forma limpia. Hemos hecho esto en múltiples proyectos y estándares, documentando cada decisión de mapeo para que pueda revisarse y reproducirse.
Dinos cómo podemos ayudarte.