In un incidente multi-vittima a cavallo di un confine, a ritardare il triage condiviso non è il numero di ambulanze disponibili ma la traduzione dei dati clinici e logistici fra centrali operative che usano vocabolari, codici di triage e formati di messaggio diversi. Le risorse fisiche — mezzi, équipe, posti letto — le dimensiona da decenni la pianificazione di protezione civile. A restare fragile è lo strato informativo: chi è già stato categorizzato, dove sta andando, quale ospedale ha ancora capacità.

Contesto

Un mass casualty incident (MCI, incidente in cui i feriti eccedono le risorse immediatamente disponibili) impone una sequenza nota: categorizzazione sul posto, raccolta nei punti di smistamento, ri-categorizzazione, distribuzione verso le strutture definitive. Quando l’evento è vicino a un confine — un deragliamento, un incidente industriale, un crollo — i soccorritori che convergono appartengono a sistemi sanitari nazionali distinti. Ognuno ha la sua scala di triage (START, CESIRA, varianti locali), i suoi identificativi di paziente, le sue regole sul trattamento dei dati sanitari.

Il quadro istituzionale europeo di questa convergenza è il Meccanismo unionale di protezione civile, istituito dalla Decisione n. 1313/2013/UE e coordinato dal Centro di coordinamento della risposta alle emergenze (ERCC), attivo 24 ore su 24. La Decisione (UE) 2019/420 ha aggiunto la riserva rescEU come capacità di ultima istanza, per quando le risorse nazionali e quelle pre-impegnate nel pool europeo non bastano. Questo livello regola chi invia i mezzi e con quali procedure di richiesta; non normalizza il formato dei messaggi che mezzi e centrali si scambiano una volta sul campo.

Il problema

Il problema è semantico prima ancora che tecnico. Due centrali possono essere collegate da una rete che funziona e restare incapaci di cooperare se «paziente rosso» nell’una non corrisponde univocamente a una categoria dell’altra, se l’identificativo assegnato a un ferito in un punto di smistamento non viene riconosciuto al punto di ricezione, se la disponibilità di posti letto è espressa in unità che non si possono confrontare.

A questa classe di problemi si risponde da tempo disaccoppiando tramite standard di scambio. La famiglia EDXL (Emergency Data Exchange Language) di OASIS fa esattamente questo: messaggi in XML con semantica definita, indipendenti dall’applicativo che li produce o li consuma.

  • Il Common Alerting Protocol (CAP) v1.2, standard OASIS dal 1° luglio 2010, definisce un formato di allerta all-hazard che si può diffondere in simultanea su canali eterogenei.
  • EDXL-TEP (Tracking of Emergency Patients), nella revisione 1.1 del 2018, struttura il tracciamento del singolo paziente dal primo contatto sul posto fino al ricovero o al rilascio in campo.
  • EDXL-HAVE (Hospital AVailability Exchange) descrive la disponibilità ospedaliera in forma confrontabile — posti, specialità, capacità di accoglienza.

Sopra questi formati, la norma ISO 22320:2018 («Security and resilience — Emergency management — Guidelines for incident management») fissa i requisiti organizzativi della risposta: ruoli definiti, struttura di comando, gestione coordinata dell’informazione operativa. La norma vincola il come si gestisce l’informazione; EDXL vincola il come la si rappresenta sul filo.

Architettura

L’impianto che ne nasce è a strati, e la separazione fra gli strati è ciò che rende il sistema componibile.

Lo strato di trasporto sposta byte fra i nodi e per ipotesi di progetto lo si dà per inaffidabile, perché in un MCI le reti pubbliche sono congestionate o degradate: si preferiscono canali ridondanti e si tollera la consegna ritardata. Lo strato di rappresentazione è EDXL: ogni messaggio è autoconsistente, datato, con identificativi globali, così che un nodo che lo riceve fuori sequenza possa comunque collocarlo. Lo strato semantico è la mappatura fra scale di triage e fra vocabolari nazionali, l’elemento che richiede accordo preventivo fra i sistemi e che durante l’evento non si può improvvisare.

Il punto architetturale che torna in questi sistemi è il rifiuto dell’integrazione punto-a-punto. Collegare n centrali a coppie produce un numero di adattatori che cresce con il quadrato di n e diventa ingestibile in uno scenario transfrontaliero a più paesi. Un formato di scambio comune sostituisce gli n² adattatori bilaterali con n adattatori verso un’unica rappresentazione canonica. È lo stesso argomento con cui si giustifica un message broker rispetto a un grafo di connessioni dirette, applicato a un dominio dove il costo dell’errore è clinico.

Punto critico

Il punto critico non è nessuno dei singoli standard, ma la mappatura semantica fra di essi sotto vincolo giuridico. I dati clinici di un ferito sono dati sanitari, categoria particolare ai sensi del Regolamento (UE) 2016/679 (GDPR). Il trattamento per finalità di soccorso vitale ha le sue basi giuridiche — interesse vitale dell’interessato, compito di interesse pubblico — ma il trasferimento del dato attraverso un confine, fra titolari distinti e con sistemi che lo conservano per durate diverse, deve restare tracciabile e minimizzato.

Ne nasce una tensione di progetto che non si scioglie scegliendo «più dati» o «meno dati». Servono abbastanza informazioni perché il punto di ricezione tratti il paziente correttamente; serve che il dato non si diffonda oltre i nodi che ne hanno bisogno operativo; serve che, a evento chiuso, si possa ricostruire chi ha visto cosa. EDXL-TEP veicola l’identificativo e lo stato clinico, ma è il disegno del flusso — quali campi attraversano il confine, verso quali titolari, con quale ritenzione — a decidere se il sistema è conforme.

Implicazioni

Per chi progetta lo strato software, la parte difficile sta a monte del codice. Le decisioni che pesano sono la tabella di corrispondenza fra le scale di triage dei paesi coinvolti, lo schema di identificazione del paziente concordato prima dell’evento, la matrice di chi può leggere quali campi. Scritte queste, l’implementazione EDXL è meccanica: serializzare, validare contro lo schema, instradare.

Poi c’è la verificabilità. Un sistema di scambio in emergenza va esercitato con dati sintetici prima di fidarsene: messaggi fuori ordine, nodi che cadono e rientrano, identificativi duplicati per errore umano sul campo. Le proprietà che pesano — un messaggio EDXL resta interpretabile fuori sequenza, un identificativo duplicato è rilevabile, una centrale che rientra si riallinea — si misurano in esercitazione, non si deducono dal diagramma.

Limiti

Gli standard di scambio risolvono la rappresentazione, non la fonte. Se la categorizzazione sul posto è sbagliata, EDXL la trasporta fedelmente sbagliata: nessun formato corregge un triage errato. La mappatura semantica fra scale nazionali è un’approssimazione, perché le scale non sono in biiezione e la categoria di confine resta aperta all’interpretazione. La continuità di rete in scenario degradato non la garantisce nessuna norma: è un requisito infrastrutturale a sé, indipendente dal modello dei dati.

Resta il fatto che, in un incidente a cavallo di un confine, la prima cosa a rompersi non è il mezzo ma il significato condiviso di un campo dati — e quel guasto si previene molto prima dell’evento, in tabelle di corrispondenza concordate a freddo.

Questo strato di coordinamento fra veicoli di primo soccorso e centrali operative è quello su cui noze lavora nel progetto europeo VALKYRIES, descritto nell’insight pubblicato da noze: https://www.noze.it/insights/valkyries/.

https://eur-lex.europa.eu/legal-content/IT/TXT/?uri=celex:32013D1313 https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32019D0420 https://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html https://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html https://docs.oasis-open.org/emergency/edxl-have/v2.0/edxl-have-v2.0.html https://www.iso.org/standard/67851.html

Immagine di copertina: Cartellini di triage color-coded (rosso, giallo, verde, nero) usati per categorizzare i feriti in emergenza, disposti uno accanto… — foto di Genppy, pubblico dominio — https://commons.wikimedia.org/wiki/File:Triage_tags_(Tokyo_Fire_Department).jpg