Risposta breve: un engine di integrazione (interface engine) è un middleware creato per lo scambio di messaggi in ambito sanitario. Ascolta su molti protocolli (MLLP per HL7 v2, HTTP per FHIR e SOAP, file, database, code), trasforma i messaggi (mappatura dei campi, traduzione dei codici, conversione di formato come da HL7 v2 a FHIR), li instrada verso una o più destinazioni con filtri, e mantiene code, tentativi di ritrasmissione, log e dashboard in modo che un messaggio non venga mai perso e ogni errore sia visibile. Gli ospedali ne usano uno in modo che ogni sistema sia connesso all'engine una sola volta invece che a tutti gli altri sistemi. I prodotti più noti sono Mirth Connect (NextGen Connect, storicamente open source), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion e una lunga coda; i provider cloud offrono equivalenti gestiti.
I componenti fondamentali
I componenti fondamentali di un motore di interfaccia sono i canali (un flusso da una sorgente alle sue destinazioni), connettori o listener sorgente come MLLP e HTTP, filtri che decidono se un messaggio continua, trasformatori che mappano campi e codici, connettori di destinazione, code con tentativi, monitoraggio con avvisi e una traccia di controllo delle modifiche ai canali e della cronologia dei messaggi.
Ogni engine, qualunque sia il vocabolario, ha le stesse parti:
- Canale (interfaccia): un flusso da una sorgente a una o più destinazioni, con le proprie impostazioni e statistiche.
- Connettore sorgente / listener: MLLP (TCP con framing per HL7 v2), endpoint HTTP(S), SFTP e polling di file, query di database, code JMS o altre, DICOM in alcuni prodotti.
- Filtro: una regola che decide se un messaggio continua (solo ADT^A01 per questa classe di pazienti).
- Trasformatore: script o mappature che modificano il messaggio: rinominare campi, mappare codici locali a LOINC tramite una tabella di ricerca, costruire un'osservazione FHIR da un segmento OBX, aggiungere un segmento Z che un sistema legacy si aspetta.
- Connettore destinazione: dove va il risultato, con il proprio protocollo e gestione degli errori.
- Coda e ritentativi: i messaggi persistono fino all'accettazione; i fallimenti vengono ritentati con back-off; i messaggi "avvelenati" finiscono in una coda di errore per gli operatori.
- Monitoraggio e allarmi: contatori per canale, latenza, tassi di errore, allarmi quando un canale tace (l'allarme più utile nell'integrazione sanitaria).
- Audit: chi ha modificato quale canale e la cronologia dei messaggi per la risoluzione dei problemi, con controlli di conservazione e accesso poiché si tratta di dati del paziente.
Compiti tipici
I compiti tipici di un motore di interfaccia sanitaria sono la distribuzione ADT dall'HIS ai reparti, l'instradamento dei risultati di laboratorio a diversi destinatari, la traduzione di codici locali in LOINC, ATC e UCUM, l'interfacciamento tra formati HL7 v2, FHIR, CDA e CSV, l'esposizione di una facciata FHIR su un database legacy, la normalizzazione dei feed dei dispositivi e l'adattamento di MLLP all'interno a HTTPS all'esterno.
- Fan-out ADT: ricevere ricoveri dall'HIS, filtrare e tradurre per dipartimento, consegnare a laboratorio, radiologia, farmacia, gestione letti e portale pazienti.
- Instradamento risultati: ORU dal LIS all'EHR, al sistema del medico curante, al registro regionale, al record FHIR del paziente, ognuno con un sottoinsieme e un formato diverso.
- Traduzione codici: codici test locali a LOINC, codici farmaci locali a ATC, unità di testo libero a UCUM, tramite tabelle di ricerca mantenute (mappatura codici di laboratorio a LOINC).
- Ponte di formato: da HL7 v2 a FHIR e viceversa, da CDA a FHIR, da CSV di un vecchio sistema a qualsiasi cosa.
- Facciata FHIR: l'engine espone endpoint FHIR e risponde interrogando il database legacy o inviando query v2, in modo che le app vedano un server FHIR dove non esiste.
- Integrazione dispositivi: feed proprietari di monitor normalizzati in osservazioni IHE PCD.
- Adattamento protocollo: MLLP all'interno dell'edificio, HTTPS con OAuth verso l'esterno.
Sceglierne uno
La scelta di un motore di interfaccia si basa su sei criteri: volume dei messaggi e quanto sono critici la latenza e i tempi di inattività, i protocolli e gli standard supportati "out of the box" (HL7 v2, FHIR R4, DICOM, formati nazionali), l'esperienza degli sviluppatori, le operazioni come il clustering e il failover, i termini di licenza, che sono cambiati per alcuni prodotti nel 2025, e le competenze disponibili per mantenere i canali.
- Volume e criticità: messaggi al giorno, latenza accettabile e se un'interruzione di due minuti è importante (lo è per ADT e risultati).
- Protocolli e standard pronti all'uso: versioni e parser HL7 v2, supporto FHIR R4 con validazione, DICOM, X12 negli USA, formati nazionali.
- Esperienza sviluppatore: linguaggio di scripting (JavaScript in Mirth, proprietario in altri), controllo versione delle definizioni dei canali, strumenti di test, deployment in diversi ambienti.
- Operazioni: clustering, failover, integrazioni di monitoraggio, percorso di aggiornamento, modello di supporto.
- Licenza: edizioni open source o community, abbonamento per canale o per core, offerte cloud gestite; le licenze di alcuni prodotti storicamente open source sono cambiate nel 2025, quindi controlla i termini attuali.
- Competenze disponibili: l'engine è valido quanto le persone che mantengono i canali.
Esecuzione in sicurezza
Eseguire un motore di interfaccia in sicurezza significa trattare le definizioni dei canali come codice sotto controllo di versione, testare con messaggi sintetici prima della produzione, gestire le tabelle di lookup del codice con proprietari nominati, avvisare quando un canale diventa silenzioso, limitare e cancellare la cronologia dei messaggi perché si tratta di dati del paziente, documentare lo scopo di ogni canale e non permettere mai al motore di diventare il sistema di registrazione.
Tratta le definizioni dei canali come codice: in controllo versione, revisionate, distribuite attraverso test e staging con messaggi sintetici. Mantieni le tabelle di ricerca (mappe di codici) sotto governance con proprietari. Imposta allarmi sul silenzio, non solo sugli errori. Limita l'accesso alla cronologia dei messaggi, che sono dati del paziente, e cancellala secondo una pianificazione. Documenta lo scopo e il proprietario di ogni canale; il canale non documentato è quello che blocca un reparto quando il suo autore se ne va. E non lasciare mai che l'engine diventi il sistema di registrazione: sposta e trasforma i dati, non li possiede.
Quando non ne hai bisogno
Un motore di interfaccia non è necessario quando tutti i partner di un sistema "greenfield" parlano FHIR, nel qual caso un server FHIR con Subscription e un API gateway coprono l'instradamento e l'autenticazione, o quando una singola interfaccia HL7 v2 può essere gestita da una libreria come HAPI HL7v2 o hl7apy. Il motore si guadagna il suo posto con molti sistemi e formati.
Un sistema greenfield i cui partner parlano tutti FHIR può utilizzare un server FHIR con Subscription e un API gateway per autenticazione, limitazione della frequenza e routing, con trasformazioni in servizi ordinari. Una singola interfaccia HL7 v2 può essere gestita da una piccola libreria (HAPI HL7v2 in Java, hl7apy o python-hl7 in Python) all'interno dell'applicazione. L'engine guadagna il suo posto quando ci sono molti sistemi, molti formati e la necessità di una console operativa che i non sviluppatori possano monitorare.
In Anpheros
Anpheros Platform si trova sul lato FHIR dell'engine: gli ospedali vi instradano i flussi che desiderano condividere (risultati, documenti, incontri) tramite il loro engine o tramite il connettore di laboratorio, e leggono indietro tramite API FHIR e webhook. Il sito per sviluppatori mostra la mappatura da HL7 v2 a FHIR che il connettore applica.
Pagine correlate
- Integrazione sistemi ospedalieri spiegata
- Come integrare un sistema di laboratorio con un EHR
- Messaggi HL7 v2 spiegati: ADT e ORU
- Come mappare codici di laboratorio locali a LOINC
- Subscription FHIR spiegate
- Mappatura da HL7 v2 a FHIR (sito sviluppatori)
Fonti
- NextGen Connect (Mirth Connect)
- Rhapsody Integration Engine
- InterSystems IRIS for Health
- Infor Cloverleaf
- Libreria HAPI HL7v2
- Guida all'implementazione da HL7 v2 a FHIR
Domande frequenti
Un engine di integrazione è la stessa cosa di un ESB o un iPaaS?
Stessa famiglia, specializzato: un engine di integrazione viene fornito con supporto HL7 v2, DICOM, CDA e FHIR, MLLP, monitoraggio specifico per la sanità e il vocabolario utilizzato dai team di integrazione. Gli ESB generici e i prodotti iPaaS possono svolgere il lavoro con più sforzo.
L'engine può convertire automaticamente HL7 v2 in FHIR?
Diversi engine includono mappature basate sulla guida da HL7 v2 a FHIR e gestiscono i segmenti comuni. Convenzioni locali, segmenti Z e mappatura dei codici richiedono sempre lavoro di progetto.
L'engine memorizza dati del paziente?
Persiste i messaggi in transito e mantiene la cronologia dei messaggi per la risoluzione dei problemi, che sono dati del paziente e devono essere protetti e cancellati. Non dovrebbe essere utilizzato come archivio a lungo termine o sistema di registrazione.
Open source o commerciale?
Entrambi sono in produzione in grandi ospedali. La decisione di solito si basa sul supporto, sulle competenze, sulle esigenze di clustering e sui termini di licenza attuali, che sono cambiati per alcuni prodotti; controlla prima di impegnarti.
Provalo gratis nella sandbox
La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.
Gratis · 30 pazienti sintetici · senza carta
Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.
Chi siamo →