Mirth Connect: l'integration engine open source della sanità

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 →

Che cos’è un integration engine

In un ospedale reale i sistemi informativi non sono pochi: cartella clinica aziendale, HIS, LIS, RIS/PACS, anagrafica pazienti, farmacia, laboratori dedicati (anatomia patologica, microbiologia), dipartimentali di reparto, sistema tessera sanitaria, portali regionali, gateway FSE. Ciascuno parla il proprio dialetto di HL7 v2, ciascuno ha la propria versione dei segmenti, ciascuno aspetta ACK in modo lievemente diverso. Connettere tutti con tutti in modo point-to-point porta a un grafo ingestibile che cresce come n², dove ogni aggiunta o modifica richiede interventi su decine di integrazioni esistenti.

L’integration engine è il componente che spezza questa complessità introducendo un punto centrale di ingresso e uscita dei messaggi: i sistemi scrivono e leggono dall’engine, non tra loro. L’engine ascolta, valida, trasforma, filtra, instrada, registra — lasciando ai sistemi applicativi il compito di fare medicina, non traduzione.

Nel mondo open source il riferimento più diffuso è Mirth Connect.

Storia

Mirth Connect è nato nel 2006 per opera di Mirth Corporation (California). La versione 1.x definisce l’architettura fondamentale — channel, listener, destination, transformer, filter — che è rimasta sostanzialmente invariata nelle successive major release. La versione 2.x (2010-2014) ha introdotto la separazione tra destinations multiple, la coda dei messaggi, il modello di retry.

Nel settembre 2013 Mirth Corporation è stata acquisita da Quality Systems Inc., holding dell’ecosistema NextGen Healthcare. L’acquisizione non ha chiuso il progetto open source: Mirth Connect è rimasto disponibile sotto licenza Mozilla Public License, con rilasci regolari. Nel 2017-2018 è stato avviato il rebrand ufficiale a NextGen Connect Integration Engine, anche se il nome storico Mirth Connect continua a essere quello con cui il prodotto è universalmente noto.

La serie 3.x (2014-2020) ha accompagnato la maturazione del prodotto, con supporto per nuovi formati (JSON, FHIR), connettori aggiuntivi, miglioramenti di performance. La versione 4.0, rilasciata nel 2021, ha introdotto una serie di modernizzazioni — aggiornamento del motore JavaScript, supporto Java 11/17, migliorata gestione dei segreti, rinnovamento delle dipendenze — mantenendo retrocompatibilità sui canali.

L’architettura a canali

Il modello operativo di Mirth è il canale (channel). Un canale è una pipeline con questa forma:

Source connector (listener)
      │
      ▼
Source filter  ──►  Source transformer
      │
      ▼
      ┌── Destination 1 (connector + filter + transformer)
      │
      ├── Destination 2 ...
      │
      └── Destination N ...

Il Source connector riceve messaggi da una sorgente:

• MLLP — listener TCP per HL7 v2 incapsulato in MLLP, il caso più comune
• TCP — listener TCP grezzo, per protocolli non-MLLP
• HTTP — listener HTTP o HTTPS, per API RESTful o SOAP
• File — polling di directory file system
• Database Reader — lettura periodica o triggered da database (JDBC)
• Web Service — endpoint SOAP
• JMS — code ActiveMQ, IBM MQ, altri broker
• DICOM — listener DICOM C-STORE
• SMTP/IMAP/POP3 — flussi email

I filter e transformer operano sul messaggio in ingresso o su ciascuna destinazione. Un filter è una funzione JavaScript che decide se un messaggio procede; un transformer è una funzione JavaScript che modifica il payload. Gli sviluppatori possono usare i Mapper grafici per mapping campo-a-campo banali, o scrivere codice JavaScript per logiche più complesse.

Le Destination inoltrano il messaggio. Ogni destination ha lo stesso repertorio di connettori del source, più alcune specifiche di output (FHIR client HTTP, database writer, file writer).

I tipi di dato

Mirth supporta nativamente numerosi formati di dati sanitari, con parser ottimizzati:

• HL7 v2.x — il caso d’uso più comune. Parser MLLP, accesso ai segmenti tramite notation E4X/XML (msg['MSH']['MSH.3']['MSH.3.1']), validation verso profili, generazione di ACK automatici
• HL7 v3 / CDA R2 — supporto XML con XPath per navigazione degli header e sezioni
• FHIR — supporto JSON/XML; l’engine espone API Java per creazione di client FHIR REST e gestione di Bundle
• X12 — messaggi amministrativi/assicurativi (meno rilevanti nel contesto italiano)
• XML / JSON / Delimited — formati generici
• DICOM — parsing dei metadata e incapsulamento degli oggetti

Questa multivalenza rende Mirth utile non solo come gateway ospedaliero classico, ma anche come convertitore di standard — un caso d’uso crescente negli ultimi anni: ricezione di HL7 v2 da vecchi HIS, trasformazione in FHIR R4, invio a una data platform FHIR moderna.

Funzionalità operative

Oltre alla pipeline base, Mirth offre strumenti che sono vitali in esercizio:

• Message Browser — consultazione storica di tutti i messaggi transitati, con ricerca per stato, contenuto, canale, tempo
• Message Pruner — gestione della ritenzione dei messaggi, configurabile per canale (cruciale su sistemi che processano milioni di messaggi/giorno)
• Error Handler — ripresa dei messaggi falliti, con retry esponenziale
• Code Templates Library — repository condiviso di funzioni JavaScript riutilizzabili (parser, validator, client API esterne)
• User Roles e Audit Log — gestione degli accessi al configuratore, tracciabilità delle modifiche
• Command-Line Interface — mirthcli per automazione di deploy e backup
• Clustering (Premium, non open source) — alta affidabilità attiva-attiva

Il deployment tipico è Java su Linux con database esterno (PostgreSQL, MySQL, Oracle, SQL Server). L’architettura è resistente ma richiede attenzione operativa: le configurazioni dei canali sono asset di primo livello e devono essere versionate, sottoposte a code review, integrate in pipeline CI/CD come qualunque altro codice.

Usi tipici in sanità

Gli scenari più ricorrenti:

• Gateway HL7 aziendale — un’unica istanza Mirth riceve tutti i messaggi dai sistemi dipartimentali e li instrada in cartella clinica, FSE, sistemi amministrativi, data warehouse
• Broker tra RIS e PACS — conversione di ORM/ORU tra vendor, gestione MWL/MPPS
• Bridge HL7 → FHIR — modernizzazione progressiva, mantenendo i sistemi legacy sul proprio dialetto e esponendo una vista FHIR REST ai sistemi nuovi
• Alimentazione del FSE regionale — conversione dei messaggi HL7 v2 prodotti dai sistemi in documenti CDA R2 italiani, firma digitale, invio a XDS.b Document Source
• Integrazione con piattaforme di telemedicina — raccolta di parametri da dispositivi, inoltro come Observation FHIR alle cartelle
• Data pipeline verso lakehouse — capture dei flussi clinici, pseudonimizzazione, scrittura su topic Kafka o file Parquet

Alternative

Mirth non è l’unica scelta. Nel perimetro open source:

• Apache Camel + componenti sanitari (camel-hl7, camel-fhir, camel-dicom) — framework di integrazione più generale di Mirth, richiede più codice ma è estremamente flessibile, si integra con Spring Boot in architetture a microservizi
• WSO2 Enterprise Integrator — broker ESB open source (Apache 2.0), connettori sanitari via Apache Camel
• Apache NiFi — orchestrazione di dataflow generici con processor HL7
• Orthanc routers — per flussi DICOM
• LinuxForHealth (IBM/Red Hat) — suite di componenti FHIR-centric con licenza Apache 2.0

Nel perimetro commerciale i concorrenti storici sono Rhapsody (Lyniate, già Orion), InterSystems IRIS for Health / HealthShare, Cloverleaf (Infor). Sono prodotti più strutturati sul piano enterprise — scalabilità, supporto di vendor, funzionalità verticali — ma con costi di licenza e dipendenza dal fornitore.

In Italia

L’adozione di Mirth Connect nelle infrastrutture ospedaliere italiane è estesa, sia come engine principale sia come motore di conversione affiancato a prodotti commerciali. Diverse Regioni hanno standardizzato porzioni del proprio stack FSE su Mirth; numerose aziende ospedaliere lo utilizzano come broker tra cartella clinica e dipartimentali.

Il modello di adozione è tipicamente community edition: l’engine è deployato su server aziendali, configurato e gestito dal team IT interno o da un fornitore di servizi. La mancanza di una licenza ricorrente e la piena trasparenza del codice sono i fattori che lo rendono particolarmente adatto al contesto pubblico italiano. Il limite — percepito — è l’assenza del clustering open source e la dipendenza operativa dalla competenza JavaScript del team.

Traiettoria

Lo scenario in cui Mirth si muove sta cambiando. Le ragioni per cui esiste — tradurre tra dialetti HL7 v2 di vendor diversi, coesistere con standard di generazioni diverse — non scompariranno presto. I sistemi HL7 v2 sono ancora la maggioranza, e saranno in produzione per anni. In parallelo, però, la maturità di FHIR R4 e la crescita delle piattaforme dati sanitari rendono il ruolo dell’integration engine progressivamente più orientato a conversione cross-standard e a integrazione con sistemi moderni, meno a routing puro.

In prospettiva, il successore naturale di un engine come Mirth in un’architettura FHIR-first sarà un insieme di microservizi di trasformazione dispiegati su Kubernetes, con broker di eventi (Kafka) al posto del message store proprietario. Il punto di continuità resterà il modello — canale, trasformazione, destinazione — su cui Mirth ha formato una generazione di integratori sanitari.

Riferimenti: Mirth Connect / NextGen Connect Integration Engine, NextGen Healthcare, licenza MPL. Repository GitHub ufficiale. Apache Camel. WSO2 Enterprise Integrator. HL7 v2.x, HL7 CDA R2, HL7 FHIR R4.