Reemplazar una historia clínica vieja sin perder el pasado

Sector: Hospitales, redes de clínicas

El escenario

Imagina un hospital cuya historia clínica electrónica tiene quince años. El proveedor dejó de agregar funciones, y quizás dejó de atender el teléfono. La base de datos guarda década y media de historial clínico que los médicos todavía necesitan, y nadie está seguro de cómo sacarlo.

La pregunta que frenó todos los intentos de reemplazo es: ¿qué pasa con los datos viejos? Los médicos tienen un temor más simple: que el resumen de alta de 2014 que explica la alergia de un paciente sea inaccesible al día siguiente de la puesta en marcha.

Qué es Atomik, y qué no, en este escenario

Atomik no es la nueva historia clínica ni una aplicación de uso clínico. No tiene pantallas para médicos ni enfermeras. Es la capa de gestión de datos detrás de las aplicaciones: un backend que guarda los datos clínicos y demográficos de forma estandarizada y consistente, y da a todas las aplicaciones la misma manera de leerlos y escribirlos, mediante la misma API.

Las pantallas que usan los clínicos (el front-end de la historia clínica, un sistema de laboratorio, un portal del paciente, una herramienta de reportes) son aplicaciones aparte que se conectan a Atomik. Eso es lo que facilita el reemplazo: puedes cambiar o agregar esas aplicaciones sin tocar los datos que hay debajo.

Qué sale mal sin la herramienta adecuada

• Convertir todo al formato del nuevo proveedor: quedas atado otra vez, y el próximo reemplazo tendrá el mismo problema.
• Mantener el sistema viejo en modo lectura para siempre: sigues pagando, parcheando y preocupándote por un sistema en el que nadie confía.
• Archivar en PDF: el historial se conserva pero no se puede consultar.
• Los datos pertenecen a la aplicación, así que cambiar la aplicación significa mudar los datos con ella.

Cómo se puede usar Atomik

1. Separa las dos decisiones. Qué aplicación usan los médicos y dónde vive el registro no tienen que ser la misma decisión. Atomik guarda el registro en un estándar abierto, independiente de cualquier aplicación. No reemplaza la interfaz de usuario de la historia clínica; esa la sigues eligiendo, comprando o construyendo.
2. Modela por dominio. Define plantillas openEHR para los dominios a migrar: consultas, alergias, medicación, resultados, etc.
3. Mapea y migra por fases. Mapea los datos heredados a las plantillas y guárdalos por la API REST, empezando por lo que los médicos más necesitan y verificando contra el origen antes de seguir. Es un proyecto de migración, no un botón (ver la sección siguiente).
4. Mantén la historia intacta. Los datos guardados en Atomik están versionados y auditados. La identidad de los pacientes se gestiona en el repositorio demográfico, y si hay duplicados heredados, las capacidades del Índice Maestro de Pacientes ayudan a resolverlos.
5. Conecta las aplicaciones al mismo registro. La nueva aplicación clínica, y todos los sistemas que vengan después (laboratorio, portal, reportes), leen y escriben los mismos datos por la misma API.
6. Apaga el sistema viejo cuando sus datos estén en Atomik y verificados, y consulta el historial con las mismas herramientas que los datos nuevos.

Lo difícil: darle sentido a los datos heredados

Cargar datos en Atomik es el paso fácil. Lo difícil es saber qué significan los datos viejos, y ahí es donde suelen fallar las migraciones:

• Mismo nombre de campo, distinto significado. Un valor que parece equivalente en el sistema viejo y en el nuevo modelo puede usar otra unidad, otro sistema de codificación u otra convención, así que los datos se ven bien pero significan otra cosa.
• Problemas de calidad descubiertos después de la puesta en marcha. Pacientes duplicados, registros incompletos y valores que no se transformaron bien suelen notarse cuando los clínicos empiezan a usar el sistema nuevo.
• Mapeos que nadie puede explicar. Si las reglas de transformación no están documentadas, nadie puede rastrear por qué un valor se ve como se ve, y cada cambio posterior arriesga romperlas en silencio.
• Poca o ninguna documentación de la base de datos vieja. Los sistemas de quince años suelen no tenerla.

Atomik es el destino y la capa de gestión de datos a futuro. Analizar los datos heredados, diseñar el mapeo y ejecutar la migración es un proyecto, y ahí es donde un equipo con experiencia marca la diferencia.

Cómo puede ayudar CaboLabs

Atomik fue creado por CaboLabs, una empresa especializada en integración de sistemas de salud, migración y consolidación de datos, y gestión y auditoría de datos clínicos. Además del software, CaboLabs ofrece los servicios alrededor, para que no tengas que resolver sola la parte heredada:

• Análisis del modelo de origen. Entender el modelo de datos heredado, incluso en sistemas sin documentación formal: qué representa cada campo, qué valores son válidos, cómo se relacionan los registros y dónde están los problemas de calidad.
• Diseño del mapeo conceptual. Mapear conceptos antes que datos, documentando cada decisión, de modo que haya una explicación de por qué los datos se ven como se ven tras la migración. Ver Mapeo y migración de datos.
• Reglas de transformación e implementación. Reglas formales y documentadas, y un mapeador de datos funcional y probado que tu equipo pueda operar y extender, si quieres que lo implementemos.
• Migración de datos. Análisis del origen, diseño de la transformación, carga en etapas y verificación posterior, hacia destinos basados en estándares como openEHR, con registros de auditoría y planes de reversión para cuando las cosas no salgan como se espera.
• Auditoría de bases de datos y revisión de calidad de datos. Encontrar duplicados, valores inconsistentes y problemas estructurales en la base heredada antes de que lleguen a la nueva.
• Integración de los sistemas que rodean al registro. Conectar laboratorio, imágenes, farmacia y otros sistemas al registro compartido (HL7 v2, FHIR, DICOM). Ver los servicios para hospitales y clínicas.
• Evaluación de arquitectura. Una revisión de la arquitectura actual y una hoja de ruta por fases, para que el reemplazo no interrumpa la operación.

Puedes hacer este trabajo con tu propio equipo o con otro proveedor; nada en Atomik requiere los servicios de CaboLabs. Si quieres conversar sobre tu caso, contacta a CaboLabs.

Qué te da esto

Un registro que no pertenece a ninguna aplicación, y una única forma consistente de acceder a él para todas ellas. La próxima vez que cambie el front-end, los datos no tienen que mudarse con él.

Por qué Atomik encaja

El problema central al reemplazar una historia clínica no es la aplicación nueva, sino que los datos pertenecen a la vieja. Atomik guarda el registro en un estándar abierto propiedad del hospital, lo que convierte el próximo reemplazo en una decisión más chica.

← Todos los casos de uso