La capacidad que tiene una sistema de acoplarse a otros sistemas, no es un tema nuevo no tampoco extraño para nadie, pero para poder entender esto vamos al año del 2002 cuando Jeff besos con su mandato API https://gist.github.com/chitchcock/1281611
Pero en una ocasión —creo que allá por 2002, un año más o menos—, [Bezos] emitió un mandato tan ambicioso, tan enorme y descomunal, que hizo que todos sus demás mandatos parecieran bonificaciones no solicitadas. Su Gran Mandato decía algo así:
- A partir de ahora todos los equipos expondrán sus datos y funcionalidades a través de interfaces de servicio.
- Los equipos deben comunicarse entre sí a través de estas interfaces.
- No se permitirá ninguna otra forma de comunicación entre procesos: enlaces directos, lecturas directas del almacén de datos de otro equipo, modelo de memoria compartida ni puertas traseras de ningún tipo. La única comunicación permitida es mediante llamadas a la interfaz de servicio a través de la red.
- No importa qué tecnología usen. HTTP, Corba, Pubsub, protocolos personalizados… da igual. A Bezos le da igual.
- Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores externos. Sin excepciones.
- «Quien no haga esto será despedido».
Ni Jeff Bezos ni sus ingenieros de alto nivel han negado el Mandato, y se ha convertido en un clásico de la tecnología. Con razón, porque lo que encapsula ha transformado la informática —y los negocios— para siempre.
es importante entender que La interoperabilidad es la capacidad de que sistemas, aplicaciones o componentes “se entiendan” lo suficiente como para comunicarse, ejecutar funciones o transferir datos sin que el usuario tenga que aprenderse las rarezas internas de cada uno, el modelo asociado a ISO/IEC 25010 ubica la interoperabilidad como parte de compatibilidad, y la describe como el grado en que un sistema puede intercambiar información y usarla mutuamente con otros productos o componentes.
La interoperabilidad suele confundirse con “conectar sistemas”, pero en realidad es una capacidad más exigente: que diferentes componentes puedan comunicarse, ejecutar funciones o transferir datos de forma que el usuario necesite poco o ningún conocimiento de las particularidades internas de cada uno. Así la describen definiciones normativas clásicas en estándares internacionales. En términos de calidad de software, además, la interoperabilidad se asume como un atributo medible: el grado en que un sistema puede intercambiar información y usar la información intercambiadacon otros sistemas o componentes, lo que obliga a pensar en diseño, pruebas y gobierno, no solo en “pasar mensajes”.
Para que esa capacidad sea real (y no una demo bonita), conviene abordarla por capas: legal, organizacional, semántica y técnica. En el sector salud, esta visión es crítica porque el valor no está en mover datos, sino en preservar significado clínico, habilitar continuidad del cuidado y reducir fricciones entre historia clínica, laboratorio, imágenes, farmacia, facturación y vigilancia en salud pública. La agenda global también empuja en esa dirección: la OMS ha enfatizado la adopción de estándares abiertos y la necesidad de guías y enfoques prácticos para convertir recomendaciones clínicas y de salud pública en sistemas digitales interoperables, articulándolo con su estrategia global de salud digital 2020–2025.
Desde mi experiencia implementando interoperabilidad en entornos sanitarios, el salto de “integración” a “interoperabilidad” ocurre cuando se define un lenguaje común y se sostiene con arquitectura y gobierno. En la práctica, esto suele traducirse en adoptar un estándar de intercambio clínico moderno como HL7 FHIR (hoy ampliamente usado como base para APIs), apoyarse en guías de implementación para aterrizar los “campos opcionales” a reglas concretas, y complementar con un esquema robusto de autorización y contexto clínico para aplicaciones (por ejemplo, marcos tipo SMART App Launch). Dicho sin vueltas: interoperabilidad no es “API y ya”; es API + perfiles/IG + terminología + seguridad + trazabilidad.
Un patrón que me ha funcionado para salud es avanzar por casos de uso de alto impacto y baja ambigüedad (p. ej., resumen clínico, resultados de laboratorio, medicación activa, citas/encuentros), y construir una “columna vertebral” interoperable: (1) modelo canónico (basado en recursos/perfiles), (2) servicio de terminologías para garantizar semántica consistente, (3) identidad y consentimiento (quién accede y por qué), (4) auditoría y (5) conectores hacia sistemas heredados (HIS/LIS/RIS) para evitar el “big bang”. En el frente de seguridad, cuando se habilitan apps o integraciones de terceros, el uso de estándares abiertos como OAuth 2.0 y OpenID Connect dentro del ecosistema SMART on FHIR ayuda a sostener el principio mínimo necesario y a controlar accesos por alcance (scopes).
En síntesis, una estrategia seria de interoperabilidad en salud se mide menos por cuántas integraciones existen y más por tres resultados: (a) datos clínicos reutilizables sin reinterpretaciones manuales, (b) flujos interinstitucionales sostenibles (gobierno y acuerdos), y (c) confianza (seguridad, auditoría, cumplimiento). El camino recomendado es incremental, guiado por estándares y con disciplina de ingeniería: definir qué se comparte, con qué significado, bajo qué reglas y cómo se opera en el tiempo. Y cuando eso se hace bien, la interoperabilidad deja de ser un proyecto “de TI” y se convierte en una capacidad organizacional que mejora la atención y habilita innovación (analítica, IA clínica, telemedicina, salud pública digital) sin romper la coherencia del dato.
Aplicación práctica en el sector salud: lo que sí funciona en campo
Desde mi experiencia implementando interoperabilidad en entornos sanitarios, el avance sostenido ocurre cuando se construye una “columna vertebral” que combine estándar, seguridad y gobierno. Un estándar moderno y ampliamente adoptado para intercambio de información clínica es FHIR, desarrollado por Health Level Seven International, diseñado para facilitar el intercambio electrónico de datos de salud y habilitar integraciones más ágiles (incluyendo enfoques basados en APIs). Pero el estándar por sí solo no resuelve el problema: en la práctica, la interoperabilidad clínica se consolida cuando se adoptan perfiles/guías de implementación (para fijar reglas de uso), un enfoque de terminologías(para coherencia semántica), y mecanismos de auditoría y trazabilidad (para confianza operativa).
En seguridad, mi enfoque ha sido asumir que “interoperabilidad sin control de acceso” es como dejar la historia clínica en una mesa de cafetería: innovador, sí… pero no en el buen sentido. Para integraciones y aplicaciones que acceden a datos clínicos, es común apoyarse en OAuth 2.0, estándar publicado por la Internet Engineering Task Force para delegar acceso limitado a servicios HTTP. Cuando además se requiere una capa de autenticación interoperable, OpenID Connect define ese rol sobre OAuth 2.0, estandarizando cómo verificar identidad y transportar “claims” de usuario. Y en el mundo FHIR, el marco SMART App Launch formaliza el “enganche” de aplicaciones de terceros a sistemas clínicos, incluyendo contexto de lanzamiento y autorización. En conjunto, esto permite que el acceso sea sustituible, controlado y auditable, algo clave para escalar sin convertir el ecosistema en una colección de accesos especiales.
Por qué esto importa a nivel global
La interoperabilidad es un habilitador directo de continuidad del cuidado, salud pública digital, analítica y (sí) IA clínica, pero solo si se sostiene con estándares y gobernanza. La World Health Organization, en su estrategia global de salud digital 2020–2025, resalta la importancia de la interoperabilidad (incluida la sintáctica y semántica) y el uso de normas/estándares para posibilitar el intercambio y uso de información en salud a escala. Eso conecta con una realidad operativa: la salud es un sistema multi-actor (IPS, aseguradores, laboratorios, imágenes, farmacia, vigilancia), y sin interoperabilidad lo que crece no es el valor… es la duplicación de datos, la fricción y el riesgo.
En salud, hablar de interoperabilidad no es un lujo académico: es la diferencia entre atención continua y “vuelva a traer los exámenes”. Con esa idea como brújula, cerré esta investigación construyendo un prototipo de historia clínica distribuida que pone el foco donde normalmente se rompe todo: el modelo de datos, el significado clínico y la capacidad de integrar componentes sin que cada integración sea una cirugía a corazón abierto. La meta no fue “conectar sistemas” por deporte, sino demostrar cómo una arquitectura bien pensada puede permitir que la información clínica viaje y se entienda de forma consistente, con trazabilidad y estructura.
El resultado es un repositorio público que documenta el proceso y deja el proyecto reproducible: código, módulos, evidencias visuales y una ruta clara para ejecutar y extender el prototipo. Este trabajo refleja una idea simple: la interoperabilidad en salud es una disciplina de ingeniería, no un parche; combina estándares, diseño modular, validación, seguridad y gobierno del dato. Para quienes enseñamos e implementamos, es la mejor forma de cerrar el ciclo: no solo “lo expliqué”, también lo construí y lo dejé listo para que otros lo revisen, lo desplieguen y lo mejoren.
Repositorio del proyecto: https://github.com/jaiderreyes/historia-clinica-distribuida.
Este proyecto está pensado como base para investigación aplicada y laboratorios de formación: un punto de partida para discutir interoperabilidad, arquitectura distribuida y modelado clínico sin depender de presentaciones bonitas… porque el código, como la historia clínica, no debería improvisarse.
Jaiderreyes 