La salud funciona con datos, pero con demasiada frecuencia esos datos no parecen diseñados para quienes los usan. Médicos y administradores se encuentran con códigos crípticos cuando lo que realmente necesitan es un nombre, un identificador o una confirmación clara de qué hospital está a cargo.
Ese fue exactamente el reto con los recursos FHIR EpisodeOfCare. Por defecto, seguían los episodios de atención con referencias por código, pero esas referencias eran poco útiles en la práctica. Eran difíciles de consultar, ralentizaban el flujo de trabajo y generaban fricción al compartir información entre organizaciones.
Decidimos solucionarlo enriqueciendo los EpisodeOfCare con referencias más ricas, añadiendo identificadores del paciente, nombres para mostrar y nombres de organización directamente en el recurso. La razón era sencilla: referencias detalladas facilitan las consultas, reducen la ambigüedad y mejoran drásticamente la interoperabilidad, especialmente en entornos federados donde múltiples hospitales, clínicas y sistemas intercambian datos.
Había otro desafío: la escala. No se trataba de unos pocos recursos, sino de más de 10 000 registros EpisodeOfCare. Enriquecer tantos elementos exigía un enfoque fiable, escalable y rentable.
La solución llegó mediante procesamiento por lotes, impulsado por Google Cloud Healthcare API, un motor de mejora basado en Python y despliegue sin servidor en Cloud Run. El resultado fue notable: miles de recursos mejorados en minutos, a bajo coste y con una tasa de éxito del 100 por ciento. Lo más importante, los datos se volvieron más útiles para personas y sistemas.
1. Introducción: el reto de la interoperabilidad
Hoy los datos de salud viven en todas partes. Un paciente puede recibir atención en múltiples centros y regiones, cada uno con su propio sistema de información. Y esos sistemas no siempre acuerdan cómo representar los datos.
FHIR nació como un puente, proporcionando una forma estándar de compartir información sanitaria. Pero los estándares dejan margen de interpretación, y a veces ese margen se convierte en una brecha.
EpisodeOfCare es un buen ejemplo. Registra el periodo durante el cual un paciente está bajo atención, pero la forma de referenciar a pacientes y organizaciones suele omitir detalles que hacen los datos útiles en la práctica. Con referencias que solo incluyen un código, faltan el nombre del paciente, su identificador nacional NIK y el nombre de la organización, lo que complica consultas como filtrar episodios por nombre de paciente o localizar todos los pacientes gestionados por un hospital concreto sin buscar códigos por separado. En sistemas federados, esta falta de contexto vuelve frágil la interoperabilidad.
2. Nuestro enfoque: añadir lo que faltaba
Buscamos que EpisodeOfCare fuera más útil, más consultable y más interoperable. La clave fue enriquecer las referencias para que aportaran no solo códigos, sino también contexto.
Incorporamos tres mejoras principales: identificadores de paciente NIK dentro de EpisodeOfCare para facilitar la búsqueda por ID y el matching entre sistemas, nombres para mostrar del paciente para que el personal identifique al instante a quién corresponde el registro y para admitir consultas por nombre, y nombres visibles de la organización gestora para mejorar la usabilidad y la federación de datos.
Con estas mejoras, las consultas son mucho más simples. Si necesitas localizar a todos los pacientes gestionados por un hospital, puedes filtrar por el nombre visible de la organización. Si quieres detectar NIK duplicados, el identificador ya está disponible en el mismo recurso.
3. El gran reto: escalar
Mejorar un EpisodeOfCare es sencillo. Mejorar más de 10 000 es un desafío serio. Procesar cada registro de forma individual habría sido lento y frágil, con riesgo de topar con límites de API, sobrecargar memoria y perder tiempo. En un entorno federado, donde rendimiento y fiabilidad son críticos, eso es inaceptable.
La respuesta fue el procesamiento por lotes. En lugar de tratar cada registro como un trabajo aislado, los procesamos en grupos, controlando el throughput, recuperándonos con gracia de errores y optimizando el rendimiento. Con paginación inteligente y parámetros configurables, el sistema manejó datasets de cualquier tamaño. En la práctica, miles de recursos se procesaron en menos de media hora, se sostuvieron cientos de llamadas por minuto sin alcanzar límites y la ejecución completa costó menos de un dólar incluso a gran escala.
4. Dentro del motor
El corazón del sistema fue un motor de mejora en Python. Su cometido: recuperar recursos EpisodeOfCare, enriquecer sus referencias y guardarlos de nuevo en forma mejorada. Detrás de una lógica aparente y compacta, el motor entiende múltiples formatos de NIK, compone nombres a partir de distintos componentes y omite mejoras si faltan datos sin bloquear el flujo.
La resiliencia fue esencial: trazas detalladas en logs, reintentos automáticos, gestión de errores sin interrumpir el lote y reanudación del progreso en cualquier momento. Todo ello con seguridad y cumplimiento: cifrado en tránsito y en reposo, autenticación robusta y auditoría completa de cada cambio.
5. Despliegue en el mundo real
Elegimos Google Cloud Run para desplegar el servicio. Obtuvimos una plataforma serverless que escala automáticamente y exige una gestión mínima de infraestructura. Cada región contó con su despliegue y configuración específica, con endpoints dedicados y parámetros afinados a la carga de trabajo. Añadimos endpoints de salud, paneles de monitorización, modo de prueba sin cambios y scripts de despliegue automatizados para iterar con rapidez.
6. Resultados
Las cifras hablan por sí solas: más de 10 000 EpisodeOfCare mejorados, 100 por ciento de éxito, cero pérdida de datos y hasta 293 llamadas a API por minuto sostenidas. Más allá de los números, médicos consultan por nombre o ID sin pasos extra, administradores ya no traducen códigos de organización y los sistemas federados intercambian episodios con contexto útil directamente en las referencias.
7. Mirando al futuro
El ecosistema sanitario es federado por naturaleza. Los pacientes transitan entre clínicas, hospitales, aseguradoras y programas públicos. El reto y la gran oportunidad aparecen cuando esas organizaciones deben compartir datos. Al incrustar identificadores, nombres visibles y nombres de organización en las referencias de EpisodeOfCare, eliminamos fricción: las consultas entre instituciones son más sencillas, el intercambio es más fiable y el seguimiento del viaje del paciente es más fluido incluso cuando la atención ocurre en múltiples entidades.
8. Conclusión: datos que funcionan mejor
El punto de partida era claro: los EpisodeOfCare no ayudaban lo suficiente a las personas. Llevaban referencias sin detalle. Al enriquecer esas referencias, resolvimos tres problemas a la vez: facilitamos las consultas, mejoramos la usabilidad diaria y fortalecimos la interoperabilidad en sistemas federados. Escalar a más de 10 000 registros demostró que la solución no era un prototipo, era producción. Hacerlo en la nube lo volvió seguro, eficiente y operativo con bajo coste.
En Q2BSTUDIO impulsamos proyectos de interoperabilidad sanitaria con software a medida y aplicaciones a medida, combinando ingeniería de datos clínica con inteligencia artificial, ciberseguridad, automatización de procesos, servicios cloud AWS y Azure, servicios de inteligencia de negocio y power bi, además de agentes IA e ia para empresas. Si tu organización necesita una solución interoperable de extremo a extremo, descubre cómo abordamos la modernización con aplicaciones a medida y cómo operamos a escala con servicios cloud aws y azure.
Cuando los datos funcionan mejor, la salud funciona mejor. Y en un mundo federado, pequeñas mejoras aplicadas a gran escala marcan la diferencia entre sistemas aislados y un ecosistema sanitario que colabora de manera fluida e inteligente.