IHE XDS: la condivisione documentale che fa funzionare i FSE regionali

AIHealth

Piattaforma clinica on-premise con LLM locali, RAG su dati FHIR/DICOM, supporto alla diagnosi, follow-up remoto. Architettura progettata per il percorso MDR.

Scopri AIHealth →

Digital Health

Sviluppo di software medicale conforme agli standard normativi CE e MDR. Sistemi di supporto alle decisioni cliniche, integrazione AI nei flussi di lavoro clinici.

Scopri →

Il problema che IHE risolve

Standard come HL7 CDA R2 e DICOM stabiliscono come rappresentare rispettivamente documenti clinici e immagini. Non dicono però come due o più sistemi sanitari appartenenti a organizzazioni diverse — aziende ospedaliere, laboratori, ambulatori — si scambino documenti in un’infrastruttura condivisa. Tra lo standard e l’implementazione concreta c’è spazio per un livello ulteriore: le regole di orchestrazione di attori, servizi e metadati, con profili di interoperabilità che gli implementatori possono dichiarare di supportare.

Questo livello è l’oggetto di IHE — Integrating the Healthcare Enterprise — un’iniziativa internazionale nata nel 1998 negli Stati Uniti e successivamente articolata in affiliate nazionali e regionali (IHE Europe, IHE Italia tra le altre). IHE non produce nuovi standard, ma pubblica Technical Framework strutturati in Integration Profile, ciascuno dei quali combina e vincola standard esistenti — HL7, DICOM, W3C, OASIS — attorno a un caso d’uso.

Affinity Domain

Il concetto organizzativo su cui si regge IHE è l’Affinity Domain: un gruppo di strutture sanitarie che concordano politiche condivise (identificazione dei pazienti, autenticazione degli utenti, terminologie, modello di consenso) e scambiano documenti tra loro. Un Affinity Domain tipico in Italia corrisponde a una Regione: il FSE regionale è il dominio, gli erogatori sono gli attori, i documenti clinici sono gli oggetti condivisi.

Domini differenti si incontrano quando serve scambiare documenti tra Regioni diverse, o tra Stati diversi nel caso dei servizi transfrontalieri.

XDS e XDS.b

Il profilo centrale del framework è XDS (Cross-Enterprise Document Sharing), nato nei primi anni 2000 nel dominio ITI (IT Infrastructure) di IHE. La versione attualmente in uso è XDS.b, che adotta come trasporto SOAP con MTOM/XOP per l’allegato binario dei documenti.

Gli attori di XDS sono:

• Document Source — il sistema che produce e pubblica un documento (l’HIS di un ospedale, un LIS, un RIS)
• Document Repository — l’archivio che conserva fisicamente i documenti, tipicamente ospitato presso l’erogatore o presso il Data Center della Regione
• Document Registry — il registro che indicizza i metadati dei documenti, consentendo la ricerca
• Document Consumer — il client che interroga il registro e recupera il documento (una cartella clinica, il portale FSE, un visualizzatore medico)
• Patient Identity Source — sorgente autoritativa dell’identità del paziente nel dominio

Le transazioni standardizzate (identificate da codici ITI-xx) coprono:

• ITI-41 Provide and Register Document Set-b — il Document Source pubblica un documento al Repository e ne registra i metadati nel Registry
• ITI-42 Register Document Set-b — registrazione metadati quando il documento è già nel Repository
• ITI-18 Registry Stored Query — il Consumer interroga il Registry
• ITI-43 Retrieve Document Set — il Consumer recupera il documento dal Repository

I metadati: ebXML e le classificazioni

I metadati di un documento in XDS sono modellati secondo ebXML Registry Information Model (ebRIM) di OASIS. Ogni documento è un ExtrinsicObject con Slot, Name, Description e Classification associate. Le classification ancorano il documento a vocabolari controllati:

• classCode — tipo di documento (referto, lettera di dimissione, patient summary)
• typeCode — sottotipo più specifico (es. referto di radiologia TC addome)
• formatCode — formato tecnico (CDA R2 HL7 Italia PSS, CDA R2 LDO, PDF, …)
• confidentialityCode — livello di riservatezza
• practiceSettingCode — contesto di pratica (cardiologia, pediatria, medicina generale)
• healthcareFacilityTypeCode — tipo di struttura
• eventCodeList — codici degli eventi clinici documentati
• languageCode — lingua del documento

Ogni Affinity Domain pubblica un Value Set per ciascuna classificazione: l’allineamento dei vocabolari è condizione necessaria per una ricerca cross-erogatore significativa.

Identificazione del paziente: PIX e PDQ

XDS presuppone che l’identità del paziente sia univoca nell’Affinity Domain. Poiché ciascun erogatore mantiene i propri identificativi locali, IHE fornisce profili complementari per l’allineamento delle anagrafi:

• PIX (Patient Identifier Cross-referencing) — un Patient Identifier Cross-reference Manager mantiene le corrispondenze tra identificativi di domini diversi; i sistemi possono chiedere “a quale MPI locale corrisponde questo identificativo regionale?”
• PDQ (Patient Demographics Query) — interrogazione dei dati demografici del paziente
• PIX V3 e PDQ V3 — versioni che usano HL7 v3 al posto di v2; più pulite sul piano formale, meno adottate in pratica

L’integrazione del FSE con l’Anagrafe Nazionale Assistiti e con le anagrafiche regionali passa, nelle implementazioni italiane, attraverso varianti di questi profili.

XCA: tra Affinity Domain

Quando un paziente si sposta tra Regioni, le richieste di documenti escono dall’Affinity Domain di residenza ed entrano in quello di destinazione. Il profilo dedicato è XCA (Cross-Community Access):

• ITI-38 Cross Gateway Query — interrogazione attraverso il gateway della home community verso quelli di altre comunità
• ITI-39 Cross Gateway Retrieve — recupero del documento attraverso il gateway

Il modello di INI (Infrastruttura Nazionale per l’Interoperabilità) gestita da Sogei per il FSE italiano è un’applicazione di XCA: i FSE regionali si parlano tramite i gateway XCA nazionali.

Sicurezza e privacy: ATNA, CT, BPPC, XUA

XDS e XCA si appoggiano a profili trasversali:

• ATNA (Audit Trail and Node Authentication) — autenticazione TLS mutua tra nodi e registrazione di audit trail conformi a RFC 3881 in formato syslog
• CT (Consistent Time) — sincronizzazione NTP dei nodi per coerenza dei timestamp nei log
• BPPC (Basic Patient Privacy Consents) — gestione dei consensi del paziente tramite un documento CDA dedicato, referenziato come policy di accesso ai documenti
• XUA (Cross-Enterprise User Assertion) — asserzioni SAML sull’identità dell’utente finale che originano la richiesta, propagate tra i nodi

Nel contesto italiano questi profili si integrano con i meccanismi nazionali (SPID, CIE, CNS, carte operatore regionali) per l’autenticazione forte.

Content Profile

Sopra l’infrastruttura di trasporto di XDS si innestano i Content Profile — definizioni di quali documenti vengono scambiati e come devono essere strutturati. I più rilevanti:

• XDS-SD (Scanned Documents) — incapsulamento di PDF firmato in un CDA R2 wrapper
• XDS-MS (Medical Summaries) — riassunti clinici
• XPHR (Personal Health Records) — documenti PHR del paziente
• XDS-I.b — condivisione di imaging DICOM nel frame XDS (con manifest CDA contenente riferimenti agli oggetti DICOM)

I profili italiani CDA R2 di HL7 Italia — LDO, Referto di Laboratorio, Verbale PS, PSS — sono di fatto Content Profile adottati dai FSE regionali, con i relativi formatCode registrati nel Value Set regionale.

Strumenti e test

Le conformità IHE sono verificate nei Connectathon: eventi annuali (Vienna per anni, ora itineranti) in cui vendor, enti sanitari e ricercatori fanno girare i propri sistemi contro strumenti e partner di test. La piattaforma di testing — Gazelle — è aperta ed è sviluppata dal consorzio IHE.

Lato implementazione, l’ecosistema open source include:

• OpenXDS — reference implementation java di Document Registry e Repository, Apache License
• IHE Profile Kit — librerie Java per implementare gli attori
• Gazelle Test Management — piattaforma di test di conformità
• Integrazioni XDS nei principali integration engine open source (Mirth Connect con canali IHE)

Nel FSE italiano

Tutti i FSE regionali italiani adottano il frame IHE come riferimento architetturale: XDS.b per la condivisione infra-Regione, XCA via INI per l’interoperabilità nazionale, PIX/PDQ per l’allineamento anagrafico, ATNA per audit e sicurezza, BPPC per la gestione dei consensi. I profili italiani CDA R2 forniscono il livello di contenuto.

La compattezza del modello — registrare metadati, conservare i documenti presso chi li produce, recuperare on-demand — regge bene su casi d’uso di consultazione. Mostra i suoi limiti su casi d’uso di secondary use, analitica e integrazione con AI clinica — dove un modello strutturato a risorse (FHIR) o a dati osservazionali (OMOP CDM) offre vantaggi più evidenti. È questo lo spazio in cui si muoverà l’evoluzione dei FSE nella seconda metà degli anni venti.

Riferimenti: IHE IT Infrastructure Technical Framework (profili XDS.b, XCA, PIX, PDQ, ATNA, CT, BPPC, XUA). ebXML Registry Information Model (OASIS). OpenXDS. IHE Gazelle.