Interoperabilidad sanitaria: qué es y por qué es más que hablar el mismo idioma

1. Qué es la interoperabilidad sanitaria, en una frase

La interoperabilidad sanitaria es la capacidad de dos o más sistemas de información sanitarios de intercambiar datos clínicos y usarlos entre sí de forma que la información conserve su significado y su valor clínico completo.

1.1. Intercambiar no es lo mismo que interoperar

Dos sistemas pueden intercambiarse ficheros y no interoperar: si uno envía un PDF y el otro lo guarda como adjunto opaco, hay transferencia pero no interoperabilidad. Interoperar exige que el sistema receptor pueda hacer algo útil con lo recibido, no solo almacenarlo. La diferencia es la que separa una integración que aporta valor de una que solo mueve papel electrónico. La segunda infla las estadísticas de proyectos «entregados» sin mejorar nada la atención al paciente.

1.2. El fin no es técnico

La razón última de la interoperabilidad es asistencial: que el profesional que atiende a un paciente disponga de la información relevante independientemente de dónde se generó. Y económica: que las clínicas puedan cambiar de proveedor, integrar sistemas nuevos y participar en redes sin quedar atrapadas por decisiones técnicas del pasado. Esa autonomía tiene un valor que aparece el día que hay que renegociar con el proveedor actual o migrar a otro.

2. Los cuatro niveles de interoperabilidad

Cualquier análisis serio distingue cuatro niveles. Un software puede cumplir uno o dos y fallar en los otros, y ahí es donde aparecen los proyectos que se atascan.

2.1. Niveles técnico y sintáctico

Los sistemas se conectan físicamente, transportan bytes entre ellos y los mensajes tienen una estructura acordada que ambos conocen. Es lo que resuelven la red y el protocolo (nivel técnico) más HL7 y FHIR como formatos (nivel sintáctico). Muchos proyectos empiezan y acaban aquí, y por eso las integraciones fracasan aunque «funcione la conexión» y «los mensajes cuadren». Son los dos niveles más fáciles de comprobar y los que menos aportan cuando faltan los otros.

2.2. Nivel semántico

Los códigos y vocabularios usados significan lo mismo en ambos lados. Un diagnóstico enviado con un código de CIE-10 significa lo mismo en el emisor y en el receptor porque los dos usan el mismo catálogo. Sin este nivel, un dato puede llegar bien estructurado y significar algo distinto de lo esperado. Aplicado a la historia clínica: ver qué es una historia clínica interoperable.

2.3. Nivel organizativo

Existen acuerdos entre las organizaciones sobre quién puede intercambiar qué, con qué autorización, con qué responsabilidades y bajo qué política de privacidad. Este es el nivel que menos suele considerarse al principio y el que más problemas causa al final, sobre todo cuando aparece el regulador de datos.

3. Por qué no es solo un problema técnico

Es la lección más importante y la que menos se entiende cuando se contrata software.

3.1. La técnica es la parte fácil

Poner en marcha un canal HL7 v2 o una API FHIR entre dos sistemas es un problema técnico resuelto hace años. Los estándares existen, las herramientas están maduras y hay ingenieros que saben hacerlo. Si tu proyecto se atasca aquí, cambia de proveedor.

3.2. Los vocabularios y códigos son el terreno intermedio

Acordar qué códigos usar para diagnósticos, procedimientos, medicamentos y catálogos administrativos ya es más difícil, porque cada sistema tiende a usar los suyos. La solución existe —los catálogos estándar están definidos— pero adoptarlos exige trabajo en el propio sistema, no solo en la integración. Es lo que resuelven páginas como la codificación ATC de medicamentos.

3.3. Los acuerdos organizativos son el verdadero cuello de botella

Quién decide qué información se comparte, bajo qué condiciones y con qué responsabilidad legal es una decisión que ningún estándar puede resolver por sí mismo. Muchos proyectos de interoperabilidad se atascan aquí durante años mientras la técnica está lista desde el primer mes. Y el motivo raramente es mala fe: es que nadie diseñó desde el principio quién decide qué se comparte y con qué responsabilidad.

4. Estándares que la hacen posible

La lista es larga y conviene conocer al menos las tres familias más importantes.

4.1. Estándares de intercambio de mensajes y recursos

HL7 v2 para intercambios tradicionales entre sistemas hospitalarios. FHIR para intercambios modernos basados en API web. DICOM para imagen médica y sus metadatos. Los tres son piezas complementarias, no alternativas. Cada uno resuelve una parte del intercambio clínico —imagen, mensajes tradicionales, API modernas— y una clínica media acaba usando los tres sin poder prescindir de ninguno.

4.2. Catálogos de códigos y vocabularios

CIE-10 para diagnósticos, LOINC para observaciones y pruebas, SNOMED CT para conceptos clínicos, ATC para principios activos. Cada país adapta o adopta los que le convienen; en España están regulados por el Ministerio de Sanidad y por las administraciones autonómicas. La versión concreta que exige cada actor —una mutua concreta, un hospital receptor, un programa autonómico— aparece en su guía técnica y hay que respetarla al pie de la letra: usar una versión próxima pero no idéntica es garantía de que los códigos no cuadren.

4.3. Marcos europeos e institucionales

El Espacio Europeo de Datos Sanitarios y los puntos nacionales de contacto sanitario definen cómo se intercambia información entre países y bajo qué condiciones. Son la capa organizativa a nivel europeo, y sostienen ejemplos concretos como el Patient Summary. Su implantación real avanza más despacio que el diseño técnico porque exige acuerdos entre estados miembros que tardan años en cerrarse.

5. Interoperabilidad frente a integración

Se confunden constantemente y son cosas distintas.

5.1. Una integración es un puente a medida

Cuando dos sistemas concretos se conectan entre sí con reglas específicas de esa pareja, hay una integración. Funciona bien para esos dos sistemas y no vale para ningún otro. Es cara de mantener y muy difícil de replicar cuando aparece un tercer sistema.

5.2. La interoperabilidad es una capacidad general

Cuando un sistema puede intercambiar con cualquier otro que hable los mismos estándares, tiene interoperabilidad. No hace falta rehacer trabajo por cada nueva pareja: los estándares hacen el trabajo pesado y cada nueva integración es un ajuste, no un proyecto entero.

5.3. La diferencia se nota al tercer sistema

Con integraciones a medida, conectar tres sistemas cuesta tres proyectos; con interoperabilidad de verdad, cuesta uno y luego pequeñas configuraciones. Esa diferencia se agranda con cada nuevo actor y es la razón por la que los estándares se imponen aunque tengan curva de aprendizaje. Las clínicas que empiezan con integraciones a medida acaban rehaciendo el trabajo cuando aparece el tercer o cuarto sistema, y ahí es cuando el coste del atajo se paga entero.

6. Cómo llega la interoperabilidad a una clínica hoy

La foto realista es de convivencia entre lo tradicional y lo moderno.

6.1. Las conexiones tradicionales siguen vivas

Laboratorios que envían resultados por HL7 v2, mutuas que reciben facturación por HL7 v2, hospitales receptores que aceptan derivaciones por HL7 v2. Es la mayor parte del tráfico interoperable que ve una clínica media, y funciona.

6.2. Las conexiones institucionales empujan hacia FHIR

Los proyectos de administraciones autonómicas, nacionales y europeas se construyen sobre FHIR con perfiles específicos. Participar en redes públicas o en programas de coordinación asistencial exige exponer datos vía FHIR conforme al perfil que el proyecto defina.

6.3. Los portales y apps consolidan FHIR

Cualquier portal del paciente o aplicación móvil moderna consume información clínica por FHIR. Y cada vez más servicios de terceros —analítica, seguimiento, servicios de valor añadido— asumen FHIR como forma natural de conectarse al núcleo del centro.

7. Qué debe cumplir tu software para ser interoperable

Cinco criterios comprobables. Ningún proveedor cumple los cinco al 100 %, pero saber en cuáles cojea decide el proyecto.

7.1. Los tres criterios técnicos

• Soportar HL7 v2 y FHIR con demostración funcional de los dos.
• Usar catálogos estándar —CIE-10, LOINC, ATC— en los campos que los admiten, no vocabularios propios.
• Registrar cada intercambio con su origen, destino y contenido.

7.2. Los dos criterios organizativos

• Gestión de consentimientos y autorizaciones para el intercambio de datos, no solo controles técnicos.
• Portabilidad garantizada de los datos del centro fuera del propio sistema, sin dependencia técnica del proveedor.

7.3. La prueba con un caso concreto

Pídele al proveedor que enseñe cómo un dato entra por HL7 v2 desde un laboratorio y aparece luego consultable por FHIR desde una herramienta externa. Si el circuito funciona con datos reales y la codificación se conserva coherente, hay interoperabilidad de verdad. Si cada paso funciona por separado pero no encajan juntos, tienes integraciones sueltas, no un sistema interoperable.

8. Errores frecuentes al hablar de interoperabilidad

Tres malentendidos que aparecen en toda conversación de compra.

8.1. «Es solo un problema técnico»

La técnica es la parte fácil. Los vocabularios, los códigos y los acuerdos organizativos son donde los proyectos se atascan de verdad. Un proveedor que solo habla de estándares y protocolos sin mencionar catálogos y consentimientos está vendiendo la parte fácil como si fuera todo el problema.

8.2. «Con soporte a HL7 y FHIR ya está»

Soportar los estándares es el requisito de partida, no la solución. Cada intercambio concreto exige acordar el perfil, los códigos, los flujos y los permisos. La compatibilidad universal entre software interoperables es una promesa que se rompe al primer proyecto real.

8.3. «Interoperabilidad y coste bajo van juntos»

Ojalá. La interoperabilidad reduce el coste marginal de cada nueva integración, pero la infraestructura inicial —el software, los procesos, la formación— tiene su coste. Lo que hace la interoperabilidad barata es la décima integración, no la primera. Y por eso los cálculos de retorno se hacen sobre el conjunto del ecosistema, no proyecto a proyecto en isla.

9. Qué aporta obeliOmed con esto

La idea es que la clínica pueda participar en el ecosistema interoperable sin depender de un integrador por cada proyecto. Si tu centro es de oftalmología, la guía sobre software para clínicas oftalmológicas recorre cómo se junta esa conexión con las pruebas de los equipos y el expediente.

9.1. Estándares soportados

El sistema habla HL7 v2 y FHIR, y usa los catálogos estándar CIE-10 y ATC en los campos correspondientes. Los intercambios concretos con cada actor externo se acuerdan según lo que soporta ese actor, y se documentan para poder mantenerlos en el tiempo.

9.2. Consentimientos y autorizaciones

Cada intercambio de datos con un actor externo respeta los consentimientos otorgados por el paciente y las autorizaciones internas del centro, con registro de qué se compartió, con quién y cuándo. Es la capa organizativa que muchos software olvidan y que hace defendibles los intercambios ante el regulador de datos.

9.3. Portabilidad garantizada

Los datos del centro pueden exportarse en cualquier momento a los formatos estándar sin depender de una operación técnica del proveedor. Cambiar de sistema es un proyecto operativo, no un rescate; encaja con la lógica del historial clínico como bien propio del centro y no del software.