Interoperar no és només connectar dues màquines: és que una dada surti d'un sistema i l'altre l'entengui i la faci servir sense que ningú la torni a teclejar. La norma espanyola distingeix tres dimensions: tècnica, semàntica i organitzativa. En un hospital, centenars d'intercanvis diaris no van de sistema a sistema, sinó a través d'un motor d'integració que els rep, tradueix i reparteix. Aquest mòdul recorre els estàndards que viatgen per aquesta xarxa: HL7 v2, FHIR, DICOM, els perfils IHE i les terminologies.

Una definició oficial i tres dimensions

L'Esquema Nacional d'Interoperabilitat (Reial decret 4/2010) defineix la interoperabilitat com la «capacitat dels sistemes d'informació, i per tant dels procediments als quals aquests donen suport, de compartir dades i possibilitar l'intercanvi d'informació i coneixement entre ells» ¹. I obliga a entendre-la en tres dimensions (art. 6), amb les definicions al glossari ¹:

L'ENI hi afegeix una quarta mirada, la temporal: garantir l'accés a la informació al llarg del temps (art. 6) ¹. En sanitat pesa molt: una imatge o un informe s'han de poder llegir dècades després.

L'ordre de les dimensions importa. Dos sistemes poden intercanviar missatges perfectes en l'aspecte tècnic i fallar en el semàntic, perquè cadascun codifica a la seva manera. I es poden entendre en tots dos plans i tot i així fallar en l'organitzatiu, si ningú no va decidir qui corregeix una dada errònia.

Per què la sanitat necessita interoperar

Un hospital no té un sistema: en té molts. L'HIS gestiona pacients i episodis, i al seu voltant hi ha sistemes departamentals de laboratori, imatge, farmàcia, quiròfan o anatomia patològica, a més dels equips mèdics que generen dades. Què és cadascun s'explica al mòdul «Sistemes d'informació». Aquí interessa el que circula entre ells.

Fora de l'hospital, la llei també exigeix intercanviar. La Llei 16/2003 encarrega al Ministeri de Sanitat coordinar els mecanismes d'intercanvi electrònic d'informació clínica, acordats amb les comunitats, perquè pacients i professionals accedeixin a la història clínica «sigui quina sigui l'Administració que la proporcioni» (art. 56) ². Preveu una xarxa segura de comunicacions del SNS per la qual circulen, entre d'altres, el codi d'identificació personal únic, la informació clínica i la recepta electrònica (art. 54) ². I una targeta sanitària la lectura de la qual sigui tècnicament possible a tot l'Estat (art. 57) ².

El Reial decret 1093/2010 fa el pas semàntic: fixa el conjunt mínim de dades dels informes clínics i obliga les comunitats a adoptar-lo «per garantir la interoperabilitat en el Sistema Nacional de Salut» (art. 3.3) ⁷. Es veurà a l'última lliçó del mòdul.

Tres paradigmes: missatges, documents i API

Els estàndards sanitaris combinen tres formes d'intercanviar. FHIR, l'estàndard més recent d'HL7, les admet totes: arquitectures REST, i també intercanvi «using messages or documents», i serveis ³.

No competeixen: conviuen. Un mateix hospital sol fer servir missatgeria HL7 v2 dins de casa, documents per compartir amb altres centres i interfícies FHIR per a aplicacions noves. HL7 reconeix que v2 és un dels seus estàndards més adoptats i que és predominant en l'àmbit hospitalari de tot el món ⁴.

De la teranyina punt a punt al motor

La manera ingènua de connectar sistemes és punt a punt: cada parell negocia la seva interfície. Amb quatre sistemes n'hi ha prou amb sis connexions; amb vint, en caldrien fins a 190, cadascuna amb el seu format. Canviar el sistema d'admissió obligaria a refer totes les seves.

L'alternativa és una arquitectura en estrella. Cada sistema parla amb una peça central, el motor d'integració, que s'encarrega de la resta. L'ENI recull una idea semblant per a l'Administració: els nodes d'interoperabilitat, entitats a les quals s'encomana la gestió global o parcial de la interoperabilitat organitzativa, semàntica o tècnica (art. 8.3) ¹.

Què fa un motor d'integració

És un concepte d'arquitectura, no un producte: hi ha motors comercials, de codi obert i desenvolupaments propis. Les seves funcions habituals:

• Recepció i acusament. Escolta cada sistema pel seu canal (missatgeria HL7 v2 sobre la xarxa, serveis web, fitxers) i confirma la recepció.
• Validació. Comprova l'estructura i els camps obligatoris abans de propagar un error.
• Transformació. Tradueix entre versions i formats: d'un missatge HL7 v2 a un recurs FHIR, o entre dos dialectes de v2.
• Traducció de codis. Converteix el codi intern d'una prova al codi estàndard, o el d'una unitat d'infermeria al que espera el destí.
• Encaminament. Decideix a qui va cada missatge segons el tipus, l'origen o el contingut. Un ingrés a pediatria pot no interessar al mateix sistema que un a la UCI.
• Cues i reintents. Si un destí cau, guarda els missatges i els reenvia en ordre quan torna.
• Traça i monitoratge. Guarda còpia del que entra i surt, alerta d'errors i permet reprocessar.

La transformació és imprescindible per una raó que HL7 admet: un dels reptes més grans de v2 és «la variació d'implementació» ⁴. Dos sistemes que diuen «parlar HL7 v2» rarament envien exactament el mateix; el motor absorbeix aquestes diferències.

El motor també és un punt únic de fallada. Si s'atura, s'aturen les interfícies de l'hospital. Per això es desplega amb redundància i amb algú que vigili les seves cues.

El marc europeu que arriba: l'EEDS

El Reglament (UE) 2025/327 crea l'Espai Europeu de Dades de Salut. Es va publicar el 5 de març de 2025 i va entrar en vigor el 25 de març de 2025 ⁶. Fixa sis categories prioritàries de dades de salut (art. 14.1) ⁵:

1. Històries clíniques resumides.
2. Receptes electròniques.
3. Dispensacions electròniques.
4. Estudis de diagnòstic per imatge i els seus informes.
5. Resultats de proves diagnòstiques, inclosos els de laboratori.
6. Informes d'alta hospitalària.

La Comissió ha d'establir, com a molt tard el 26 de març de 2027, el format europeu d'intercanvi d'històries clíniques electròniques: «d'ús comú, llegible per màquina», amb conjunts de dades harmonitzats, sistemes de codificació i especificacions tècniques d'interoperabilitat (art. 15.1) ⁵. És a dir, les tres dimensions de l'ENI escrites en norma europea. Les obligacions s'apliquen per fases: des del 26 de març de 2029 per a les tres primeres categories, i des del 26 de març de 2031 per a les tres últimes (art. 105) ⁵. Quins estàndards concrets triarà la Comissió: [PENDIENTE: actes d'execució de l'art. 15 encara no publicats a 26 d'octubre de 2026].

Cas pràctic

Un hospital canvia el sistema de laboratori. L'antic rebia peticions i retornava resultats mitjançant deu interfícies directes: amb la història clínica, urgències, la UCI, primària, el banc de sang i d'altres.

Si les interfícies són punt a punt, el canvi exigeix refer deu integracions i coordinar deu equips. Si passen per un motor, la feina es concentra en un sol costat: connectar el laboratori nou al motor i ajustar-hi les transformacions. Els altres sistemes ni se n'assabenten.

Queda la part semàntica. El laboratori nou codifica les proves amb un catàleg propi, diferent de l'antic. Sense una taula d'equivalències, els gràfics d'evolució de la història clínica barrejarien la «glucosa» antiga i la nova com si fossin proves diferents. I queda l'organitzativa: cal decidir qui manté aquesta taula quan el laboratori afegeixi una prova.

Què implica per als sistemes

Peça	Quines dades genera o gestiona	Amb qui es relaciona
Motor d'integració	Còpia de cada missatge, estat de lliurament, errors, taules de traducció de codis	Tots els sistemes del centre; de vegades, nodes externs del servei de salut
Catàleg d'interfícies	Quin sistema envia quin esdeveniment a qui, amb quina versió i quins camps	Equips de sistemes, proveïdors, seguretat
Taules d'equivalència	Codi local enfront de codi estàndard (proves, unitats, serveis)	Laboratori, farmàcia, terminologies del servei de salut
Monitoratge	Cues pendents, temps de lliurament, alertes	Guàrdia tècnica: una cua aturada és un risc clínic