Interoperar no es solo conectar dos máquinas: es que un dato salga de un sistema y el otro lo entienda y lo use sin que nadie lo vuelva a teclear. La norma española distingue tres dimensiones: técnica, semántica y organizativa. En un hospital, cientos de intercambios diarios no van de sistema a sistema, sino a través de un motor de integración que los recibe, traduce y reparte. Este módulo recorre los estándares que viajan por esa red: HL7 v2, FHIR, DICOM, los perfiles IHE y las terminologías.

Una definición oficial y tres dimensiones

El Esquema Nacional de Interoperabilidad (Real Decreto 4/2010) define la interoperabilidad como la «capacidad de los sistemas de información, y por ende de los procedimientos a los que éstos dan soporte, de compartir datos y posibilitar el intercambio de información y conocimiento entre ellos» ¹. Y obliga a entenderla en tres dimensiones (art. 6), con sus definiciones en el glosario ¹:

El ENI añade una cuarta mirada, la temporal: garantizar el acceso a la información a lo largo del tiempo (art. 6) ¹. En sanidad pesa mucho: una imagen o un informe deben poder leerse décadas después.

El orden de las dimensiones importa. Dos sistemas pueden intercambiar mensajes perfectos en lo técnico y fallar en lo semántico, porque cada uno codifica a su manera. Y pueden entenderse en ambos planos y aun así fallar en lo organizativo, si nadie decidió quién corrige un dato erróneo.

Por qué la sanidad necesita interoperar

Un hospital no tiene un sistema: tiene muchos. El HIS gestiona pacientes y episodios, y a su alrededor hay sistemas departamentales de laboratorio, imagen, farmacia, quirófano o anatomía patológica, además de los equipos médicos que generan datos. Qué es cada uno se explica en el módulo «Sistemas de información». Aquí interesa lo que circula entre ellos.

Fuera del hospital, la ley también exige intercambiar. La Ley 16/2003 encarga al Ministerio de Sanidad coordinar los mecanismos de intercambio electrónico de información clínica, acordados con las comunidades, para que pacientes y profesionales accedan a la historia clínica «cualquiera que fuese la Administración que la proporcione» (art. 56) ². Prevé una red segura de comunicaciones del SNS por la que circulan, entre otros, el código de identificación personal único, la información clínica y la receta electrónica (art. 54) ². Y una tarjeta sanitaria cuya lectura sea técnicamente posible en todo el Estado (art. 57) ².

El Real Decreto 1093/2010 da el paso semántico: fija el conjunto mínimo de datos de los informes clínicos y obliga a las comunidades a adoptarlo «para garantizar la interoperabilidad en el Sistema Nacional de Salud» (art. 3.3) ⁷. Se verá en la última lección del módulo.

Tres paradigmas: mensajes, documentos y API

Los estándares sanitarios combinan tres formas de intercambiar. FHIR, el estándar más reciente de HL7, las admite todas: arquitecturas REST, y también intercambio «using messages or documents», y servicios ³.

No compiten: conviven. Un mismo hospital suele usar mensajería HL7 v2 dentro de casa, documentos para compartir con otros centros e interfaces FHIR para aplicaciones nuevas. HL7 reconoce que v2 es uno de sus estándares más adoptados y que es prominente en el ámbito hospitalario de todo el mundo ⁴.

De la telaraña punto a punto al motor

La forma ingenua de conectar sistemas es punto a punto: cada par negocia su interfaz. Con cuatro sistemas basta con seis conexiones; con veinte, harían falta hasta 190, cada una con su formato. Cambiar el sistema de admisión obligaría a rehacer todas las suyas.

La alternativa es una arquitectura en estrella. Cada sistema habla con una pieza central, el motor de integración, que se encarga del resto. El ENI recoge una idea parecida para la Administración: los nodos de interoperabilidad, entidades a las que se encomienda la gestión global o parcial de la interoperabilidad organizativa, semántica o técnica (art. 8.3) ¹.

Qué hace un motor de integración

Es un concepto de arquitectura, no un producto: hay motores comerciales, de código abierto y desarrollos propios. Sus funciones habituales:

• Recepción y acuse. Escucha a cada sistema por su canal (mensajería HL7 v2 sobre la red, servicios web, ficheros) y confirma la recepción.
• Validación. Comprueba estructura y campos obligatorios antes de propagar un error.
• Transformación. Traduce entre versiones y formatos: de un mensaje HL7 v2 a un recurso FHIR, o entre dos dialectos de v2.
• Traducción de códigos. Convierte el código interno de una prueba al código estándar, o el de una unidad de enfermería al que espera el destino.
• Enrutamiento. Decide a quién va cada mensaje según su tipo, su origen o su contenido. Un ingreso en pediatría puede no interesar al mismo sistema que uno en la UCI.
• Colas y reintentos. Si un destino cae, guarda los mensajes y los reenvía en orden cuando vuelve.
• Traza y monitorización. Guarda copia de lo que entra y sale, alerta de errores y permite reprocesar.

La transformación es imprescindible por una razón que HL7 admite: uno de los mayores retos de v2 es «la variación de implementación» ⁴. Dos sistemas que dicen «hablar HL7 v2» rara vez envían exactamente lo mismo; el motor absorbe esas diferencias.

El motor también es un punto único de fallo. Si se detiene, se detienen las interfaces del hospital. Por eso se despliega con redundancia y con alguien que vigile sus colas.

El marco europeo que llega: el EEDS

El Reglamento (UE) 2025/327 crea el Espacio Europeo de Datos de Salud. Se publicó el 5 de marzo de 2025 y entró en vigor el 25 de marzo de 2025 ⁶. Fija seis categorías prioritarias de datos de salud (art. 14.1) ⁵:

1. Historias clínicas resumidas.
2. Recetas electrónicas.
3. Dispensaciones electrónicas.
4. Estudios de diagnóstico por imagen y sus informes.
5. Resultados de pruebas diagnósticas, incluidos los de laboratorio.
6. Informes de alta hospitalaria.

La Comisión debe establecer, a más tardar el 26 de marzo de 2027, el formato europeo de intercambio de historias clínicas electrónicas: «de uso común, legible por máquina», con conjuntos de datos armonizados, sistemas de codificación y especificaciones técnicas de interoperabilidad (art. 15.1) ⁵. Es decir, las tres dimensiones del ENI escritas en norma europea. Las obligaciones se aplican por fases: desde el 26 de marzo de 2029 para las tres primeras categorías, y desde el 26 de marzo de 2031 para las tres últimas (art. 105) ⁵. Qué estándares concretos elegirá la Comisión: [PENDIENTE: actos de ejecución del art. 15 aún no publicados a 26-oct-2026].

Caso práctico

Un hospital cambia su sistema de laboratorio. El antiguo recibía peticiones y devolvía resultados mediante diez interfaces directas: con la historia clínica, urgencias, la UCI, primaria, el banco de sangre y otras.

Si las interfaces son punto a punto, el cambio exige rehacer diez integraciones y coordinar a diez equipos. Si pasan por un motor, el trabajo se concentra en un único lado: conectar el laboratorio nuevo al motor y ajustar ahí las transformaciones. Los demás sistemas ni se enteran.

Queda la parte semántica. El laboratorio nuevo codifica sus pruebas con un catálogo propio, distinto del antiguo. Sin una tabla de equivalencias, los gráficos de evolución de la historia clínica mezclarían «glucosa» antigua y nueva como si fueran pruebas distintas. Y queda la organizativa: hay que decidir quién mantiene esa tabla cuando el laboratorio añada una prueba.

Qué implica para los sistemas

Pieza	Qué datos genera o gestiona	Con quién se relaciona
Motor de integración	Copia de cada mensaje, estado de entrega, errores, tablas de traducción de códigos	Todos los sistemas del centro; a veces, nodos externos del servicio de salud
Catálogo de interfaces	Qué sistema envía qué evento a quién, con qué versión y qué campos	Equipos de sistemas, proveedores, seguridad
Tablas de equivalencia	Código local frente a código estándar (pruebas, unidades, servicios)	Laboratorio, farmacia, terminologías del servicio de salud
Monitorización	Colas pendientes, tiempos de entrega, alertas	Guardia técnica: una cola detenida es un riesgo clínico