Il progetto VALKYRIES (Grant Agreement 101020676, Horizon 2020) chiude il 30 settembre 2023 dopo due anni di lavoro su un problema preciso: far cooperare i servizi di primo soccorso di paesi diversi quando un disastro con molte vittime attraversa un confine. La domanda non è retorica. Un incendio boschivo tra Spagna e Portogallo, un incidente industriale alla frontiera tra Slovacchia e Austria, un terremoto tra Bulgaria e Grecia, un sinistro navale in acque internazionali tra Norvegia, Paesi Bassi e Danimarca: sono i quattro scenari dimostrativi su cui ha lavorato il consorzio (CORDIS, 101020676).

Contesto

Un mass-casualty incident (MCI, incidente con un numero di vittime che supera la capacità di risposta locale) mette sotto stress prima di tutto il coordinamento. Quando l’evento è transfrontaliero, allo stress operativo se ne aggiunge uno strutturale: ogni servizio nazionale arriva con la propria centrale, i propri protocolli di triage, la propria nomenclatura, spesso la propria lingua. La letteratura sui template di reporting in medicina dei disastri lo registra da oltre dieci anni. Il template Utstein per la raccolta uniforme dei dati nella risposta medica ai disastri, pubblicato nel 2012 su PLOS Currents Disasters, nasce esattamente per dare definizioni e indicatori condivisi a comunità che altrimenti misurano cose diverse chiamandole allo stesso modo.

Il consorzio VALKYRIES — coordinato da INDRA, con partner clinici e di protezione civile tra cui la Scuola Superiore Sant’Anna e l’Agenzia Regionale Emergenza Urgenza in Italia — ha trattato questo scarto come problema di pre-standardizzazione, non di sviluppo software.

Problema

In progetti del genere la tentazione è costruire una piattaforma che integri tutto. È anche la parte più facile da finanziare e da mostrare in una demo. Il nodo difficile sta a monte: due centrali operative possono scambiarsi messaggi solo se concordano sul significato dei campi.

Prendiamo il triage. La codifica del colore (rosso, giallo, verde, nero) sembra universale, ma le soglie cliniche che portano a un colore cambiano da protocollo a protocollo — START, SALT, le varianti nazionali. Un paziente che una squadra classifica come priorità immediata può finire in una categoria diversa nel sistema dell’altra squadra. Se i due sistemi si limitano a inoltrarsi il colore senza il dato clinico sottostante, l’informazione attraversa il confine corrotta, e nessuno se ne accorge finché non è troppo tardi. Lo stesso vale per l’identificazione delle vittime, per la posizione (sistemi di riferimento geografici diversi), per lo stato delle risorse ospedaliere.

Il problema, insomma, è semantico prima che di trasporto. Una rete radio interoperabile e un’API ben documentata non risolvono nulla se i due capi della conversazione non condividono un minimum data set: l’insieme minimo di campi, con definizioni concordate, che deve viaggiare con ogni vittima e con ogni risorsa.

Architettura

Il lavoro di armonizzazione di VALKYRIES, presentato ad ARES 2023 (Benevento, agosto 2023, DOI 10.1145/3600160.3605060), tiene separati tre livelli che spesso si confondono.

Il primo è il trasporto: come i messaggi viaggiano tra sistemi. Qui la famiglia di standard OASIS EDXL (Emergency Data Exchange Language) offre mattoni già ratificati e indipendenti dal fornitore. L’EDXL Distribution Element 2.0 (OASIS, 2013) è un involucro per instradare qualunque payload di emergenza verso destinatari e aree geografiche; il Common Alerting Protocol 1.2 (OASIS, 2010) standardizza gli allarmi; EDXL-SitRep i situation report aggregati; EDXL-TEP il tracciamento dei pazienti tra più luoghi e custodi; EDXL-HAVE la disponibilità delle risorse ospedaliere. Nessuno di questi è nuovo, ed è proprio il punto: l’interoperabilità si costruisce su standard stabili e verificabili, non su formati inventati per il singolo progetto.

Il secondo livello è la semantica: il vocabolario condiviso. Qui sta il contributo originale di un progetto del genere, perché gli standard di trasporto lasciano deliberatamente liberi molti campi. Concordare un minimum data set transfrontaliero — quali dati su vittima, triage, posizione e risorsa, con quali definizioni e quali codifiche — è un lavoro di consenso clinico e organizzativo, non di ingegneria.

Il terzo livello è la procedura: chi parla con chi, in quale ordine, con quale autorità. Due sistemi tecnicamente interoperabili restano inutilizzabili se le rispettive catene di comando non hanno concordato a priori chi coordina quando l’incidente è a cavallo del confine.

Punto critico

Un progetto come VALKYRIES si misura da quanto lavoro semantico e procedurale sopravvive alla fine del finanziamento, più che dal software consegnato. Una piattaforma dimostrata in quattro esercitazioni e poi spenta non lascia nulla. Un minimum data set, una mappatura dei protocolli di triage nazionali, un profilo d’uso degli standard EDXL concordato tra più paesi continuano a valere anche dopo l’archiviazione del codice, perché altri possono riprenderli, criticarli e adottarli.

Costruire un sistema è una cosa, costruire le condizioni perché molti sistemi diversi possano parlarsi è un’altra. La seconda strada è più lenta, rende poco in una demo, e produce risultati che assomigliano più a documenti che a prodotti. Per questo viene regolarmente sottovalutata, e per questo è la parte decisiva.

Implicazioni

Per chi progetta sistemi che devono integrarsi con infrastrutture preesistenti — non solo nell’emergenza — la lezione operativa è sempre la stessa: partire dal contratto semantico, non dall’integrazione. Definire il minimum data set e le sue codifiche prima di scrivere l’adattatore. Scegliere standard stabili e indipendenti dal fornitore (EDXL, CAP) invece di formati proprietari, anche quando il proprietario è più comodo nell’immediato. Trattare la mappatura tra nomenclature diverse come un artefatto di prima classe, versionato e testato, non come una tabella di conversione nascosta nel codice di un singolo modulo.

Sul piano della governance, un progetto transfrontaliero rende esplicito un fatto che i progetti nazionali tendono a mascherare: l’interoperabilità non è una proprietà del software, è un accordo tra organizzazioni che il software si limita a far rispettare. Quando l’accordo manca, nessuna quantità di codice lo sostituisce. Lato implementazione, noze ha partecipato come consulente tecnico per la Scuola Superiore Sant’Anna, sviluppando due web application React in modalità wizard — una per una checklist operativa, una per il data management plan — oltre all’hosting del sito di progetto: il consuntivo del suo contributo è nell’insight pubblicato da noze (https://www.noze.it/insights/valkyries-conclusione/).

Limiti

Tutto questo riguarda la dimensione tecnica e semantica. Restano fuori i fattori che in un MCI reale pesano spesso di più: la copertura radio in aree compromesse, la latenza decisionale delle catene di comando, la disponibilità fisica delle risorse, l’addestramento congiunto. Un minimum data set ben definito non serve a nulla se le squadre non si sono mai esercitate a usarlo insieme, sotto pressione.

C’è poi un limite di metodo che vale per l’intera famiglia di progetti finanziati a termine: una dimostrazione in quattro scenari controllati è una prova di fattibilità, non una validazione operativa. La validazione vera arriva solo dall’uso ripetuto in eventi reali, che per definizione non si possono pianificare. Alla chiusura di VALKYRIES la domanda aperta non è se la piattaforma funzioni in esercitazione, ma quali parti del lavoro semantico verranno raccolte dagli enti di protezione civile nazionali e mantenute nel tempo.

Immagine di copertina: Squadra di soccorritori della protezione civile, con caschi ed elmetti e divise ad alta visibilità, durante una ricognizione… — foto di Dipartimento della Protezione Civile, CC BY 2.0 — https://commons.wikimedia.org/wiki/File:Esercitazione_Belice_2018_(45566391211).jpg