Quando un paziente viene ricoverato, il gestionale dell’ospedale spedisce ai sistemi dipartimentali una riga di testo che apre con MSH e prosegue con campi separati da pipe. È un messaggio Health Level Seven Version 2 (HL7 v2), il formato nato nel 1987 su cui ancora oggi viaggia gran parte delle comunicazioni interne agli ospedali.

Contesto

Lo standard ha venticinque anni e nessun ricambio operativo all’orizzonte. Sul campo convivono più versioni: la 2.3 (1997) e la 2.3.1 (1999) resistono nelle installazioni legacy; la 2.4 (2000) e la 2.5 (2003) sono la base più diffusa nei collegamenti italiani; la 2.5.1 e la 2.6 (entrambe del 2007) si trovano nei sistemi più recenti. L’ultima revisione è la 2.7, approvata ANSI nel gennaio 2011. La numerazione avanza, ma le versioni vecchie non spariscono: un sistema informativo ospedaliero (Hospital Information System, HIS) installato dieci anni fa continua a emettere quello che ha sempre emesso, e chi riceve deve saperlo leggere.

Il perimetro è quello dei flussi clinico-amministrativi: anagrafe e movimenti del paziente, ordini di laboratorio e radiologia, referti, prenotazioni, documenti clinici. Tutto questo passa tra HIS, sistema di radiologia (Radiology Information System, RIS), sistema di laboratorio (Laboratory Information System, LIS) e gli altri dipartimentali sotto forma di messaggi v2.

Anatomia del messaggio

HL7 v2 è un formato testuale con separatori gerarchici che il messaggio dichiara da sé. Ogni messaggio è una sequenza di segmenti divisi da carriage return; ogni segmento è una sequenza di campi divisi dal pipe |; i campi si articolano in componenti divise dal caret ^, sotto-componenti divise dall’ampersand &, e ripetizioni divise dalla tilde ~. Il backslash \ fa da escape.

Il primo segmento è sempre MSH (Message Header) e, ai suoi caratteri 2-8, dichiara i separatori usati nel resto del messaggio, oltre a mittente, destinatario, tipo di messaggio e identificativo di controllo. Un ricovero (evento A01) si apre di solito 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

Tornano ricorrenti PID (identificazione paziente), PV1 (visita/episodio), OBR e OBX (richiesta e risultato di osservazione), ORC (ordine comune), AL1 (allergie), DG1 (diagnosi), NK1 (contatto di riferimento). Ogni segmento ha una posizione e una struttura fissate dal capitolo dello standard che lo governa.

I tipi di messaggio mappano gli eventi clinici. ADT copre ammissioni, dimissioni e trasferimenti, con eventi come A01 (ricovero), A03 (dimissione), A08 (aggiornamento dati). ORU^R01 porta risultati e referti. SIU gestisce le agende. MDM i documenti clinici testuali. Gli ordini hanno una storia che dice molto: al vecchio ORM^O01, generico, si sono affiancati messaggi specifici per dominio — OMG per gli ordini generali, OML per il laboratorio, OMP per la farmacia — segno che lo standard ha provato a restringere l’ambiguità di un unico tipo tuttofare.

Trasporto

HL7 v2 non impone un protocollo di trasporto, ma sul campo si usa quasi sempre il Minimal Lower Layer Protocol (MLLP), oggetto di una specifica di trasporto pubblicata da HL7 (Transport Specification: MLLP, Release 1). Il meccanismo è elementare. TCP consegna un flusso continuo di byte, quindi il messaggio va incorniciato perché chi riceve ne riconosca inizio e fine: MLLP antepone al payload un byte di start block <VT> (0x0B) e lo chiude con <FS> (0x1C) seguito da carriage return (0x0D).

La cornice impone un vincolo sull’encoding dei caratteri: una codifica multi-byte che produca byte uguali a 0x0B o 0x1C rompe il framing. Il riscontro applicativo è un messaggio ACK il cui campo MSA-1 vale AA (accettato), AE (errore applicativo) o AR (rifiutato). La connessione vive su porte TCP dedicate dentro la rete ospedaliera.

Il costo vero dell’integrazione

Il costo dell’integrazione HL7 v2 non sta nel parsing del formato — quello è risolto da tempo. Sta nella distanza tra due implementazioni che dichiarano la stessa versione. Lo standard è permissivo per scelta: molti campi sono opzionali, molti ammettono valori definiti localmente, e la specifica tollera gli elementi che non riconosce invece di scartare il messaggio. È una tolleranza utile, perché non blocca i flussi clinici, ma sposta a valle l’onere dell’accordo: due fornitori possono essere entrambi conformi alla 2.5 e mappare lo stesso dato in posizioni diverse, oppure usare tabelle di codici locali incompatibili.

L’effetto sul campo è che un ADT in arrivo da un certo HIS va mappato e adattato al formato che il ricevente si aspetta, anche quando entrambi si dichiarano conformi alla stessa versione. L’integrazione, in pratica, è lavoro di traduzione tra dialetti dello stesso standard, non semplice instradamento.

Strumenti

Due componenti open source maturi coprono il grosso del lavoro. Mirth Connect (Mirth Corporation) è un integration engine Java organizzato a canali: ogni canale legge i messaggi da una sorgente — listener MLLP, file, database, HTTP — li filtra e trasforma con passi JavaScript eseguiti sul motore Rhino, e li smista verso più destinazioni. In produzione gira oggi la serie 2.x; la licenza è la Mozilla Public License. HAPI (HL7 Application Programming Interface), nato all’University Health Network di Toronto, è la libreria Java di riferimento per leggere, validare e costruire messaggi v2, distribuita sotto Apache License 2.0 e usata come motore di parsing da diversi integration engine. Entrambi coprono le versioni dalla 2.1 in avanti: con questi si costruiscono nodi di integrazione senza legarsi a prodotti proprietari.

Lo scenario italiano

In Italia HL7 v2 è il linguaggio comune delle integrazioni ospedaliere: collegamenti tra HIS e dipartimentali, scambi tra laboratori e richiedenti, alimentazione dei progetti regionali di Fascicolo Sanitario Elettronico. HL7 Italia, affiliata di HL7 International, coordina sul territorio la standardizzazione, ma i profili italiani più elaborati riguardano il livello documentale — la Clinical Document Architecture (CDA) — più che il messaging v2, che resta personalizzato fornitore per fornitore.

Limiti

I limiti del formato sono strutturali e arcinoti: non è auto-descrittivo, l’opzionalità è ovunque, la tolleranza agli errori si traduce in variabilità tra implementazioni, e dentro il messaggio non c’è una semantica clinica formale. Su questi limiti si innestano gli sforzi successivi di HL7 — la CDA per i documenti strutturati e i lavori in corso verso un modello a risorse — ma per la generazione di sistemi oggi in esercizio l’integrazione reale degli ospedali continua a poggiare su righe di testo che cominciano con MSH.

https://www.hl7.org/implement/standards/ansiapproved.cfm https://www.hl7.org/documentcenter/public/wg/inm/mllp_transport_specification.PDF https://www.hl7.eu/HL7v2x/v26/std26/hl7.html https://www.hl7italia.it/

Immagine di copertina: Diagramma di un segmento HL7 PID: una riga di testo separata da pipe (“PID|||0815|1234567890|Doe^John…”) con fumetti gialli che… — diagramma di Dipl.-Inform. Oliver S. Lazar, pubblico dominio — https://commons.wikimedia.org/wiki/File:HL7_pid.png