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 →Uno standard maturo, ancora dominante
Health Level Seven Version 2 — universalmente abbreviato HL7 v2 — è nato nel 1987 come standard per lo scambio di messaggi tra sistemi informativi sanitari. A venticinque anni di distanza resta il protocollo di integrazione più diffuso negli ospedali italiani e internazionali: nella quasi totalità degli scenari reali, le comunicazioni tra HIS (Hospital Information System), RIS (Radiology), LIS (Laboratory), farmacia clinica e sistemi dipartimentali passano attraverso messaggi HL7 v2.
Le versioni in uso sul campo coesistono: v2.3 (1997) e v2.3.1 (1999) sono ancora presenti in installazioni legacy; v2.4 (2000) e v2.5 (2003) rappresentano la base più comune nei deployment italiani; v2.5.1 (2007) e v2.6 (2007) sono adottate dai sistemi più recenti; v2.7 (ANSI 2011) è la versione attualmente più aggiornata dello standard.
L’encoding: segmenti, campi, separatori
HL7 v2 definisce un formato testuale con separatori gerarchici. Ogni messaggio è una sequenza di segmenti delimitati da carriage return; ogni segmento è una sequenza di campi separati dal carattere pipe |; i campi possono contenere componenti separate dal caret ^, sub-componenti separate dall’ampersand &, e ripetizioni separate dal tilde ~. Il backslash \ è il carattere di escape.
Il primo segmento di ogni messaggio è MSH (Message Header), che dichiara i separatori, il mittente, il destinatario, il tipo di messaggio e l’identificativo di controllo. Un ADT di ricovero ospedaliero inizia tipicamente così:
MSH|^~\&|HIS|OSP|RIS|RAD|201202201030||ADT^A01|MSG00001|P|2.5
EVN|A01|201202201030
PID|1||123456^^^OSP^MR||ROSSI^MARIO||19501225|M
PV1|1|I|REP1^101^1|...I segmenti più comuni sono PID (Patient Identification), PV1 (Patient Visit), OBR (Observation Request), OBX (Observation/Result), ORC (Common Order), AL1 (Allergy Information), DG1 (Diagnosis), NK1 (Next of Kin).
Tipi di messaggio
Ogni flusso clinico ha uno o più tipi di messaggio dedicati. I principali:
- ADT (Admission, Discharge, Transfer): gestione anagrafica e movimenti del paziente. Eventi come
A01(ricovero),A03(dimissione),A08(aggiornamento dati),A11(annullamento ricovero) - ORM / OMG / OML: ordini — per farmaci, esami di laboratorio, prestazioni radiologiche. Da v2.5
ORM^O01è formalmente deprecato a favore di messaggi specifici per dominio (OMG,OML,OMP) - ORU^R01: risultati di osservazioni e referti di laboratorio/strumentazione
- SIU: scheduling — prenotazioni, spostamenti, cancellazioni
- MDM: gestione documenti medici (referti testuali, lettere di dimissione)
- DFT: transazioni finanziarie/contabilità
- VXU: aggiornamento anagrafica vaccinale
Trasporto: MLLP su TCP
HL7 v2 non specifica un protocollo di trasporto unico, ma l’uso di fatto è MLLP (Minimal Lower Layer Protocol): incapsulamento del messaggio tra un byte di inizio <SB> (0x0B), il payload, un byte di fine <EB> (0x1C), seguito da carriage return <CR> (0x0D). La connessione viaggia su TCP, tipicamente su porte dedicate tra server interni alla rete ospedaliera. Il riscontro applicativo è un messaggio ACK con MSA-1 a AA (Application Accept), AE (Application Error) o AR (Application Reject).
Lo scenario italiano
In Italia HL7 v2 è il linguaggio comune delle integrazioni ospedaliere. I progetti regionali di Fascicolo Sanitario Elettronico, i collegamenti tra HIS e dipartimentali, gli scambi tra laboratori e richiedenti passano per HL7 v2. La comunità HL7 Italia, affiliata di HL7 International, coordina localmente le attività di standardizzazione — anche se i profili italiani più articolati riguardano il livello documentale (CDA R2) più che il messaging v2.
La convivenza tra versioni differenti e l’ampia personalizzazione dei messaggi da parte dei vendor rendono il tema dell’integrazione un lavoro concreto: un ADT di uno specifico HIS deve essere mappato e adattato al formato atteso dal sistema ricevente, anche quando entrambi dichiarano conformità alla stessa versione dello standard.
Strumenti open source
L’ecosistema open source fornisce due componenti maturi:
- Mirth Connect (Mirth Corporation) è un integration engine Java a canali: ogni canale consuma messaggi da una sorgente (listener MLLP, file, database, HTTP), li filtra e trasforma via JavaScript, e li instrada a destinazioni multiple. La versione 2.x è quella correntemente disponibile e utilizzata in produzione. Licenza Mozilla Public License
- HAPI (HL7 Application Programming Interface) è la libreria Java di riferimento per parsing, validazione e costruzione di messaggi HL7 v2. Sviluppata originariamente presso lo University Health Network di Toronto, è usata come motore di parsing da numerosi engine — incluso Mirth Connect
Entrambi i progetti coprono le versioni da v2.1 a v2.6/v2.7 e consentono di realizzare nodi di integrazione senza dipendere da prodotti commerciali proprietari.
Limiti e prospettive
I limiti di HL7 v2 sono noti: formato non auto-descrittivo, opzionalità diffusa nei campi, tolleranza agli errori che si traduce in forte variabilità tra implementazioni, assenza di una semantica clinica formale. Proprio su questi limiti si innestano gli sforzi di standardizzazione successivi — il CDA (Clinical Document Architecture) per i documenti clinici strutturati, e i lavori in corso in HL7 per un modello basato su risorse e API REST. HL7 v2 resta però, per la generazione di sistemi attualmente in esercizio, il protocollo su cui è costruita l’integrazione reale degli ospedali.
Riferimenti: HL7 Version 2.5, 2.6, 2.7 (ANSI-approved), HL7 International. Mirth Connect (Mirth Corporation). HAPI — The Open Source HL7 API for Java (University Health Network).