5 Aprendizajes de una integración de EHR transfronteriza
Pasé meses conectando registros de pacientes entre dos países diferentes. Trabajé con una Analista de Negocios (BA) Principal con diez años de experiencia clínica. Su enfoque cambió mi forma de ver el software de salud.
Aquí hay cinco lecciones de ese proyecto.
- El mapeo de terminología es más difícil que el mapeo de datos
Los ingenieros suelen tratar la integración como un problema de esquema. Mapeas el campo A al campo B y terminas. En el sector salud, esto falla.
Un sistema utilizaba ICD-10 y el otro utilizaba ICD-11. No se mapean de forma limpia. Un sistema usaba LOINC para laboratorios, mientras que el otro usaba códigos internos antiguos.
Nuestra BA construyó un cruce de conceptos (crosswalk) antes de que escribiéramos código. Mapeó los códigos locales a un conjunto estándar como SNOMED CT. Sin esto, habríamos corrompido el significado clínico.
Un mapeo de campos defectuoso crea valores incorrectos. Un mapeo de terminología defectuoso crea valores plausibles pero clínicamente erróneos. Esto último es mucho más peligroso.
- Las leyes de datos moldean la arquitectura desde el principio
Pensé que diseñaríamos el modelo de datos primero y nos encargaríamos del cumplimiento después. Me equivoqué.
Los datos de pacientes que cruzan fronteras se rigen por múltiples leyes como HIPAA o GDPR. Algunos países prohíben que los datos de salud salgan de sus fronteras.
Nuestra BA trabajó con los equipos legales desde el principio. Decidió qué campos podían replicarse y cuáles necesitaban desidentificación.
Esto cambió nuestra arquitectura. Construimos una capa de consulta federada en lugar de una única base de datos replicada. Añadimos etiquetas de clasificación de datos directamente en nuestro esquema.
Reúne a expertos en cumplimiento y a un BA antes de diseñar tu modelo de datos.
- Los estándares no son suficientes
Ambos sistemas soportaban HL7. Sin embargo, uno usaba HL7 v2 y el otro usaba FHIR R4. No podían comunicarse sin una capa de traducción.
Incluso dentro de FHIR, nos encontramos con desajustes de perfiles. Ambos sistemas afirmaban cumplir con el estándar, pero utilizaban guías de implementación diferentes.
No asumas que la integración es fácil solo porque un sistema soporta un estándar. Pregunta siempre por la versión y el perfil específicos. Presupuesta tiempo para una capa de adaptador.
- Los diagramas de flujo de trabajo detectan casos de borde ocultos
Solía ver los diagramas de flujo de trabajo como documentación adicional. Me equivoqué.
Nuestra BA mapeó los traslados de pacientes en detalle. Analizó qué sucede cuando un paciente se traslada a mitad de un tratamiento o cuando un resultado de laboratorio llega después del alta.
Estos no son casos aislados en un hospital. Ocurren todos los días.
Estos diagramas cambiaron nuestro modelo de datos. Añadimos un concepto de episodio de atención para rastrear la atención continua en ambos sistemas.
- Construye un glosario compartido pronto
Palabras como encounter (encuentro/consulta) o discharge (alta) significan cosas distintas en diferentes sistemas. Perdimos tiempo porque los equipos interpretaban los términos de manera diferente.
Nuestra BA construyó un glosario compartido. Cada parte interesada revisó y acordó estas definiciones. Hicimos referencia a este documento en cada requisito.
Asume que cada término de dominio es ambiguo. Defínelo en un documento que ambas partes firmen.
Resumen
Un buen BA hace más que escribir tickets. Actúan como arquitectos para las restricciones regulatorias y el significado clínico. Si construyes software complejo, no veas este rol como una carga adicional. Evita que el éxito técnico se convierta en un fracaso clínico.
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi