En salud digital hablamos cada vez más de interoperabilidad. Hablamos de HL7 FHIR, APIs, terminologías clínicas, historias clínicas electrónicas, repositorios, buses de interoperabilidad y plataformas nacionales. Esto es, sin duda, una buena noticia, especialmente en una región donde durante años buena parte de los sistemas de información en salud han funcionado como islas, con capacidades limitadas para intercambiar información de manera segura, consistente y útil.
Sin embargo, durante las últimas semanas, en el curso regional Arquitectura de Interoperabilidad basada en Estándares de HL7 Centroamérica y República Dominicana, una pregunta comenzó a aparecer una y otra vez desde distintos ángulos: ¿qué ocurre después de conectar los sistemas? La respuesta fue llevándonos progresivamente hacia una conclusión que, aunque parece evidente, no siempre está presente en las conversaciones sobre interoperabilidad: lograr que la información viaje entre dos sistemas es apenas una parte del problema.
El curso reunió perfiles profesionales muy diversos. Participaron especialistas en tecnología, medicina, ingeniería biomédica, gestión hospitalaria, integración clínica, seguridad de la información, desarrollo de software, gobernanza y transformación digital. Algunos contaban con años de experiencia trabajando con HL7 v2, RIS, PACS, HIS o motores de integración; otros llegaban desde la gestión, la regulación o el diseño de sistemas de salud. Algunos ya habían trabajado con FHIR, mientras que otros estaban comenzando a aproximarse al estándar.
Esa diversidad terminó convirtiéndose en uno de los elementos más valiosos del proceso formativo, porque hablar de arquitectura obliga precisamente a reunir a personas que normalmente observan el mismo problema desde perspectivas diferentes. Un ingeniero puede concentrarse en cómo intercambiar los datos, mientras que un clínico puede preguntarse si esos datos representan realmente lo que ocurre con el paciente. Un especialista en seguridad puede identificar riesgos que no son visibles para quien diseña una API, mientras que alguien desde la gestión o la regulación puede cuestionar quién tiene la autoridad para compartir la información, bajo qué reglas y con qué responsabilidades.
La interoperabilidad no comienza con FHIR
Una de las primeras ideas que trabajamos durante el curso fue que adoptar FHIR, por importante que sea, no significa haber resuelto la interoperabilidad. FHIR nos ofrece una forma moderna, estructurada y estandarizada de representar e intercambiar información, pero antes de llegar a esa capa necesitamos responder preguntas más básicas y, en muchos casos, bastante más complejas.
¿Qué problema queremos resolver? ¿Qué actores participan en ese proceso? ¿Qué sistemas necesitan comunicarse? ¿Qué información se requiere intercambiar? ¿Quién la genera y quién debe poder utilizarla? ¿Qué significado tienen esos datos para cada una de las partes? ¿Qué reglas permiten compartirlos? ¿Quién será responsable cuando algo falle? ¿Cómo se financiará y sostendrá el ecosistema una vez que termine el proyecto inicial?
Estas son preguntas de arquitectura y explican por qué uno de los principios que atravesó todo el curso fue comenzar por el caso de uso, y no por la tecnología. Una arquitectura de interoperabilidad debería construirse alrededor de un problema concreto que el sistema de salud necesita resolver. La continuidad de la atención de un paciente, una receta electrónica, una referencia entre establecimientos o un certificado digital de vacunación pueden compartir ciertos componentes tecnológicos, pero cada uno requiere actores, flujos, reglas, responsabilidades y decisiones específicas.
En otras palabras, no existe una arquitectura universal que pueda copiarse de un país o institución y trasladarse automáticamente a otro contexto. Los estándares proporcionan piezas fundamentales, pero la arquitectura define cómo esas piezas deben organizarse para responder a una necesidad real.
Cuando las capas empiezan a encontrarse
Para ordenar esa discusión trabajamos la interoperabilidad desde diferentes capas: tecnológica, sintáctica, semántica, organizacional y regulatoria, incorporando además la seguridad, la privacidad y la sostenibilidad como elementos transversales. En una presentación estas capas pueden parecer una clasificación académica; cuando se aplican a un caso concreto, rápidamente muestran por qué los proyectos de interoperabilidad son mucho más complejos que conectar dos aplicaciones.
Durante una de las sesiones construimos un país ficticio con tres provincias: Villamar, Nortesal y Río Verde. Cada una tenía condiciones diferentes de madurez. Villamar poseía mayores capacidades tecnológicas, pero presentaba debilidades organizacionales y regulatorias. Nortesal contaba con mejores condiciones normativas, pero sus sistemas estaban fragmentados y buena parte de su información se encontraba en texto libre. Río Verde se encontraba en una situación intermedia, con fortalezas en algunas áreas y limitaciones en otras.
El ejercicio no buscaba identificar cuál provincia estaba mejor preparada, sino responder una pregunta mucho más práctica: ¿qué tendría que ocurrir para que un paciente atendido en una de ellas pudiera ser atendido posteriormente en otra y su información clínica estuviera disponible de manera segura y comprensible?
La discusión permitió observar cómo cada fortaleza encontraba rápidamente una limitación en otra capa. Una provincia podía tener APIs y datos estructurados, pero no los acuerdos necesarios para compartirlos. Otra podía contar con voluntad institucional y respaldo regulatorio, pero carecer de sistemas capaces de producir información interoperable. Una tercera podía tener información digital disponible, pero utilizar códigos locales que perdían significado al salir de su institución.
A partir de allí, la conversación dejó de concentrarse exclusivamente en software y empezó a incorporar registros maestros de pacientes, identificación de profesionales y establecimientos, servicios terminológicos, calidad de datos, gestión del cambio, acuerdos institucionales, protección de datos, mecanismos de gobernanza y sostenibilidad financiera. Esa transición refleja precisamente lo que significa pensar en arquitectura de interoperabilidad: dejar de observar componentes aislados y comenzar a analizar cómo deben relacionarse dentro de un ecosistema.
Transportar información no significa compartir significado
Otra de las discusiones centrales se concentró en las capas sintáctica y semántica. Naturalmente, FHIR tuvo un papel importante: analizamos recursos, APIs, perfiles, extensiones y guías de implementación. Sin embargo, también apareció una idea que resulta fundamental para cualquier programa de interoperabilidad: dos organizaciones pueden utilizar FHIR y construir soluciones técnicamente válidas y, aun así, no lograr una interoperabilidad efectiva entre ellas.
La flexibilidad que hace poderoso a FHIR también exige acuerdos sobre cómo utilizarlo en un contexto determinado. De allí la importancia de las guías de implementación, que permiten establecer reglas comunes respecto de recursos, perfiles, extensiones, terminologías y casos de uso. Algo similar ocurre con estándares terminológicos como SNOMED CT o LOINC, cuyo valor no reside únicamente en disponer de códigos, sino en permitir que distintas organizaciones compartan una interpretación común de la información.
Un sistema puede transmitir perfectamente un diagnóstico, un resultado de laboratorio o una observación clínica desde el punto de vista técnico y, sin embargo, el sistema receptor puede no comprenderlo de la misma manera. Por eso, interoperar no consiste solamente en transportar información. El verdadero desafío es lograr que esa información conserve su significado y pueda ser utilizada correctamente en otro contexto.
Cuando la tecnología funciona y el ecosistema todavía no
La cuarta sesión llevó esa conversación todavía más lejos. Planteamos el escenario de un país que había realizado una importante inversión en una infraestructura nacional basada en FHIR. Los hospitales estaban conectados y los datos podían circular entre las instituciones. Desde una perspectiva estrictamente tecnológica, el proyecto parecía exitoso.
Sin embargo, al analizar con mayor detalle el ecosistema aparecieron diferencias en terminologías, códigos locales, procesos institucionales, niveles de calidad de datos y formas de implementar los lineamientos nacionales. La infraestructura funcionaba, pero la capacidad de reutilizar la información de manera consistente seguía siendo limitada.
Esto nos llevó inevitablemente hacia la gobernanza. ¿Quién define las reglas comunes? ¿Quién prioriza los casos de uso? ¿Quién decide qué estándares y perfiles deben utilizarse? ¿Cómo se supervisa la calidad de los datos? ¿Quién verifica el cumplimiento de las reglas acordadas? ¿Cómo se resuelven los conflictos entre instituciones? ¿Cómo se financia y mantiene el ecosistema cuando deja de ser un proyecto y pasa a convertirse en infraestructura permanente del sistema de salud?
Posteriormente llevamos el ejercicio más allá de las fronteras nacionales mediante casos relacionados con certificados digitales de vacunación, International Patient Summary y telesalud. En ese momento las preguntas comenzaron a incorporar protección de datos, reconocimiento de profesionales, firmas digitales, responsabilidades jurídicas y mecanismos de confianza entre países. Nuevamente, ninguna de estas cuestiones podía resolverse exclusivamente desde la capa tecnológica.
Necesitamos hablar más de arquitectura
Quizás uno de los principales aprendizajes de esta experiencia sea que durante mucho tiempo hemos hablado de interoperabilidad a partir de sus componentes. Hablamos de un estándar, una API, un servidor, una terminología, una plataforma o una normativa. Todos estos elementos son necesarios, pero observarlos por separado puede llevarnos a construir soluciones técnicamente correctas que no necesariamente resuelven el problema que originó la inversión.
La arquitectura ofrece una mirada diferente porque obliga a entender cómo todas estas piezas deben funcionar juntas alrededor de un caso de uso y de una necesidad concreta del sistema de salud. También obliga a reconocer dependencias que a veces aparecen demasiado tarde en los proyectos: capacidades institucionales, reglas de gobernanza, calidad de la información, acuerdos entre organizaciones, regulación, financiamiento, recursos humanos y sostenibilidad.
Las conversaciones multidisciplinarias desarrolladas durante el curso hicieron especialmente evidente esta realidad. Cada perfil profesional identificaba riesgos y oportunidades que los demás no necesariamente habían considerado. Esa interacción permitió comprender que un ecosistema interoperable difícilmente puede diseñarse desde una sola disciplina o desde una única institución.
Necesitamos especialistas que comprendan estándares, APIs y arquitectura tecnológica, pero también profesionales que conozcan los procesos clínicos, la gestión de servicios, la seguridad, las terminologías, la protección de datos, la regulación y la gobernanza. Sobre todo, necesitamos espacios en los que todas esas perspectivas puedan encontrarse antes de que las decisiones queden atrapadas en plataformas, contratos o tecnologías difíciles de cambiar.
Tal vez por eso necesitamos hablar más de arquitectura de interoperabilidad. No porque debamos reemplazar la conversación sobre FHIR, sino precisamente porque necesitamos ubicar a FHIR, y al resto de los estándares, dentro de una visión más amplia de lo que queremos construir.
Los estándares nos permiten conectar sistemas. La arquitectura nos ayuda a decidir qué debemos conectar, por qué hacerlo, bajo qué reglas y para generar qué valor dentro del sistema de salud.
Disclaimer:
HL7® y FHIR® son marcas registradas de Health Level Seven International. El uso de estas marcas no constituye respaldo, patrocinio o afiliación por parte de HL7 International.