El sistema sanitari per dins · Mòdul 13 · Fitxa resum

Interoperabilitat i màquines

HL7 v2, FHIR, DICOM i PACS, perfils IHE, monitors i constants, motors d'integració, terminologies i identificació del pacient.

Què és interoperar: nivells, paradigmes i motor d'integració

Les tres dimensions de la interoperabilitat, missatges, documents i API, i per què un hospital centralitza les interfícies en un motor d'integració.

Una definició oficial i tres dimensions
Per què la sanitat necessita interoperar
Tres paradigmes: missatges, documents i API
De la teranyina punt a punt al motor
Què fa un motor d'integració
El marc europeu que arriba: l'EEDS
Cas pràctic
Què implica per als sistemes

Interoperabilitat: Capacitat dels sistemes d'informació, i dels procediments als quals donen suport, de compartir dades i intercanviar informació i coneixement (Reial decret 4/2010).
Interoperabilitat tècnica: Dimensió de la interoperabilitat que tracta d'interfícies, interconnexió, integració de dades i serveis, presentació i seguretat entre sistemes.
Interoperabilitat semàntica: Dimensió de la interoperabilitat que aconsegueix que la informació intercanviada s'interpreti de manera automàtica i la reutilitzin aplicacions que no van intervenir en la seva creació.
Interoperabilitat organitzativa: Dimensió de la interoperabilitat que tracta que les entitats i els seus processos col·laborin per assolir fites acordades en els serveis que presten.
Motor d'integració: Peça central d'una xarxa d'interfícies: rep els missatges de cada sistema, els valida, transforma i encamina cap als destins, i deixa traça de cada intercanvi.
Interfície punt a punt: Connexió directa entre dos sistemes, feta a mida per a aquest parell. Amb molts sistemes, el nombre de connexions creix molt de pressa i cada canvi obliga a tocar-ne diverses.
EEDS: Espai Europeu de Dades de Salut: marc creat pel Reglament (UE) 2025/327 per a l'accés de les persones a les seves dades de salut i el seu intercanvi a la UE, i per a la seva reutilització.
Format europeu d'intercanvi d'històries clíniques electròniques: Especificació comuna, llegible per màquina, que fixarà la Comissió Europea per a les categories prioritàries de dades de salut de l'EEDS.

HL7 v2: admissions, peticions i resultats

Com es construeix un missatge HL7 v2, quins esdeveniments ADT avisen d'ingressos i altes, i com viatgen peticions i resultats amb ORM, OML i ORU.

Un estàndard nascut dels esdeveniments
Anatomia d'un missatge
ADT: el pols de l'hospital
Peticions: ORM i OML
Resultats: ORU
Acusaments, transport i dialectes
Cas pràctic
Què implica per als sistemes

HL7 v2: Estàndard de missatgeria d'HL7 basat en esdeveniments: un fet assistencial desencadena un missatge de text, format per segments i camps separats per delimitadors, cap als sistemes interessats.
Esdeveniment desencadenant: Fet real (un ingrés, un resultat disponible) que crea la necessitat d'enviar dades a altres sistemes. A HL7 v2 es codifica a la taula 0003, per exemple A01 o R01.
Segment: Línia d'un missatge HL7 v2 que agrupa dades d'un tema, identificada per tres caràcters: MSH (capçalera), PID (pacient), PV1 (visita), OBX (resultat).
ADT: Admission, discharge and transfer: família de missatges HL7 v2 que comunica ingressos, altes, trasllats, registres i canvis de dades del pacient.
ORU: Missatge HL7 v2 d'observacions no sol·licitades: el sistema que produeix un resultat l'envia sense que l'hi demanin (esdeveniment R01).
OML: Missatge HL7 v2 específic per a peticions de laboratori (esdeveniments O21 i O33, entre d'altres).
ORM: Missatge HL7 v2 de petició general (esdeveniment O01), usat històricament per demanar proves i serveis a altres departaments.
ACK: Missatge d'acusament de recepció d'HL7 v2. El seu segment MSA diu si el receptor ha acceptat (AA), ha trobat un error (AE) o ha rebutjat (AR) el missatge.
Segment Z: Segment propi que una implementació afegeix a HL7 v2 per a dades no previstes per l'estàndard. El seu significat només el coneix qui l'ha pactat.

FHIR: recursos, API web i perfils

Què aporta FHIR davant d'HL7 v2: recursos modulars, una API REST amb JSON, perfils i guies d'implementació, i el resum internacional de pacient.

Què és FHIR i d'on ve
Recursos: peces petites i enllaçades
L'API: llegir, cercar i crear pel web
Perfils i guies d'implementació
Un exemple de guia: el resum de pacient
Cas pràctic
Què implica per als sistemes

Recurs FHIR: Unitat modular d'informació de FHIR, amb estructura definida i identificador propi: Patient, Encounter, Observation, ServiceRequest, DiagnosticReport…
Perfil FHIR: Conjunt de restriccions sobre un recurs base per a un ús concret: quins elements són obligatoris, quins codis s'admeten, quines extensions s'hi afegeixen.
Extensió FHIR: Element afegit a un recurs, identificat per una adreça web única que en defineix el significat, per recollir dades que el nucli de l'estàndard no preveu.
Guia d'implementació: Conjunt coherent de perfils, extensions i regles publicat com una unitat per a una comunitat: internacional, nacional, regional o d'una sola institució.
IPS: International Patient Summary: conjunt mínim de dades clíniques d'una persona, pensat per a l'atenció no planificada i transfronterera; l'especifica la norma ISO 27269.
REST: Estil d'arquitectura web en què cada recurs té la seva adreça i es manipula amb les operacions estàndard del protocol HTTP: llegir, crear, actualitzar, esborrar, cercar.

DICOM, PACS i el flux de treball de la imatge

Com s'identifica i es desa una imatge mèdica amb DICOM, quins serveis uneixen la petició, l'equip i el PACS, i què ordena el perfil IHE de flux programat.

Què és DICOM
La jerarquia: pacient, estudi, sèrie, instància
Els serveis que mouen la imatge
El PACS i el RIS
El flux programat: el perfil SWF.b
Cas pràctic
Què implica per als sistemes

Estudi DICOM: Conjunt de sèries d'imatges i objectes d'una mateixa exploració d'un pacient. L'identifica de manera única l'Study Instance UID.
Accession Number: Número que identifica la petició o el procediment d'imatge en el sistema del servei. Uneix l'ordre, les imatges del PACS i l'informe.
Modality Worklist: Servei DICOM amb què l'equip d'imatge consulta la llista d'exploracions programades i rep les dades del pacient i de la petició sense teclejar-les.
MPPS: Modality Performed Procedure Step: servei DICOM amb què l'equip avisa que una exploració ha començat i ha acabat, i de què s'ha fet realment.
Storage Commitment: Servei DICOM amb què l'arxiu confirma a l'equip que ha assumit la custòdia de les imatges, perquè l'equip les pugui esborrar sense risc.
DICOMweb: Serveis web de DICOM (part 18) per cercar (QIDO-RS), recuperar (WADO-RS) i emmagatzemar (STOW-RS) objectes DICOM per HTTP.
SWF.b: Perfil IHE de radiologia Scheduled Workflow.b: ordena el flux des del registre del pacient i la petició fins a l'adquisició, l'arxiu i la disponibilitat de les imatges.
RIS: Radiology information system: sistema departamental que gestiona les peticions, l'agenda, la realització i l'informe de les proves d'imatge.

Perfils IHE i la integració de monitors i constants

Què és un perfil IHE, els d'identitat i documents (PIX, PDQ, XDS.b) i com arriben a la història clínica les dades de monitors, respiradors i bombes.

IHE: dels estàndards als perfils
Els perfils d'identitat: PIX i PDQ
Compartir documents: XDS.b i la seva família
Monitors i constants: el perfil DEC
Semàntica de dispositius: 11073 i RTM
Cas pràctic
Què implica per als sistemes

Perfil d'integració IHE: Especificació que resol un cas d'ús concret combinant estàndards existents (HL7, DICOM…): defineix actors, transaccions i opcions.
Actor IHE: Paper funcional d'un sistema dins d'un perfil IHE (per exemple, qui envia dades de dispositius o qui les consumeix). Un mateix producte pot fer de diversos actors.
Declaració d'integració IHE: Document en què un fabricant declara quins perfils, actors i opcions IHE implementa el seu producte.
PIX: Patient Identifier Cross-referencing: perfil IHE que relaciona els identificadors que una mateixa persona té en diferents dominis d'identificació.
PDQ: Patient Demographics Query: perfil IHE per consultar a un servidor de dades de pacients una llista de candidats segons criteris demogràfics.
XDS: Cross-Enterprise Document Sharing (avui XDS.b): perfil IHE per registrar, distribuir i consultar documents clínics entre organitzacions d'un mateix domini d'afinitat.
DEC: Device Enterprise Communication: perfil IHE que porta les dades de dispositius de capçalera (monitors, respiradors, bombes) als sistemes corporatius amb una semàntica comuna.
RTM: Rosetta Terminology Mapping: conjunt de valors d'IHE que harmonitza els termes, unitats i valors dels dispositius mèdics amb la nomenclatura ISO/IEEE 11073-10101.

Terminologies i identificació del pacient

SNOMED CT, LOINC i UCUM perquè una dada signifiqui el mateix a tot arreu, i TSI, CIP i CIP-SNS perquè es refereixi a la mateixa persona.

Per què no n'hi ha prou amb el text
SNOMED CT, la terminologia de referència
LOINC i UCUM: proves i unitats
El conjunt mínim dels informes clínics
Identificar el pacient: de la història al CIP-SNS
La Història Clínica Digital del SNS
Cas pràctic
Què implica per als sistemes

SNOMED CT: Terminologia clínica multilingüe i codificada per registrar i intercanviar dades clíniques. És la terminologia de referència del SNS per acord del Consell Interterritorial.
Concepte SNOMED CT: Significat clínic identificat per un codi numèric únic i invariable (conceptId), amb descripcions en diversos idiomes i relacions amb altres conceptes.
LOINC: Logical Observation Identifiers Names and Codes: codis per identificar proves de laboratori i altres observacions. El manté el Regenstrief Institute.
UCUM: Unified Code for Units of Measure: sistema de codis per expressar totes les unitats de mesura de manera inequívoca.
Terminologia enfront de classificació: Una terminologia (SNOMED CT) representa el detall clínic per a l'assistència; una classificació (CIM-10-ES) agrupa en categories per a estadística, gestió i finançament.
CMDIC: Conjunt mínim de dades dels informes clínics: les dades i els codis que han de portar els informes clínics del SNS segons el Reial decret 1093/2010.
Text codificat: Tipus de dada del Reial decret 1093/2010 format per l'identificador de la font (un OID), el codi que permet la interoperabilitat i el terme llegible.
Servidor de terminologies del SNS: Plataforma del Ministeri de Sanitat, en producció des del 2023, que distribueix SNOMED CT, CIM-10-ES, LOINC i altres recursos, amb serveis REST i FHIR.
Domini d'identificació: Àmbit en què un identificador de pacient és únic: un hospital (número d'història), un servei de salut (CIP autonòmic) o tot el SNS (CIP-SNS).

El sistema sanitari per dins