Il “Piano triennale per l’informatica pubblica” firmato qualche settimana fa dal Presidente del Consiglio dopo una lunga gestazione è un gran bel documento: meglio averci messo un anno e mezzo a scriverlo avendolo fatto bene piuttosto che un risultato deludente in tempi brevi.
Adesso la palla passa sul terreno dell’execution, ma anche in questo caso siamo sicuri che AgID saprà portare a casa il risultato anche se magari occorrerà una proroga dei termini in corso d’opera quando ci si renderà conto che raggiungere obiettivi di triennio partendo con un ritardo di diciotto mesi (ascrivibile ai tempi di produzione del piano medesimo) comporterebbe qualche piccolo problema e – soprattutto – un taglio ai costi non sostenibile.
Ma fin qui, nessun problema. Di proroghe ne abbiamo viste a profusione, l’importante è che ci si metta al lavoro e si vada tutti quanti nella medesima direzione.
Il piano, dicevo, è complessivamente molto ben fatto. Ritengo che sia stato redatto avendo in mente “la media” delle amministrazioni pubbliche, contesti fatti di migliaia di dipendenti con migliaia di PC utilizzati prevalentemente per lavorare con software applicativi ascrivibili alla famiglia dei “gestionali verticali”: contabilità, gestione del protocollo e del workflow documentale, atti amministrativi, gestione dei tributi, e via di seguito.
Molto probabilmente, il 75% della PA funziona così.
E in un contesto come quello appena descritto funziona benissimo una logica di razionalizzazione attraverso la centralizzazione: si “traslocano” dai data center locali verso un numero ancora imprecisato di data center strategici software applicativi “grandi e complessi a piacere” ma sostanzialmente costituiti da “blocchi unici” o da insiemi piccoli a piacere di ERP e verticalizzazioni più o meno integrate fra loro, raggiungendo contemporaneamente gli obiettivi di razionalizzazione delle infrastrutture IT pubbliche e il contenimento della spesa corrente.
Ottimo.
Ritengo che ci sia qualche problema allorquando passiamo da un mondo tipicamente “amministrativo” (un ministero, un comune, una regione) a uno dove l’aspetto di “produzione” è preminente.
Parlo della sanità, ovviamente.
Anche in questo caso, se consideriamo una azienda sanitaria locale nel suo profilo tipicamente amministrativo (la contabilità, la gestione del personale, il protocollo, i vari applicativi verticali basati su workflow di procedimento) il modello è applicabile.
Ma poi ci sono gli ospedali, gli ambulatori, le attività clinico-assistenziali sul territorio. E qui cominciano le difficoltà.
Proviamo a entrare in un ospedale per capire come funziona sotto il profilo dell’infrastruttura tecnologica e applicativa.
In un ospedale “medio” italiano (diciamo 300 posti letto) “girano” almeno una sessantina di applicativi differenti: dal pronto soccorso all’accettazione, dalla sala operatoria al laboratorio di analisi, dalle cartelle cliniche di reparto a quelle di patologia, e poi la gestione dei turni, la diagnostica per immagini, la radiologia, l’anatomia patologica, il software per il dosaggio dei farmaci antiblastici, i “clinical decision support system”, la centrale del 118, l’emodinamica, il servizio trasfusionale, e possiamo andare avanti così per altre dieci righe almeno.
Ciascuno di questi 60 circa applicativi è integrato con almeno una mezza dozzina di altri: in una matrice 60×60 (tutti i moduli applicativi in riga e colonna) le intersezioni dove c’è una integrazione più o meno “spinta” (non un mero “passaggio di dati anagrafici”) sono non meno di 350.
A ogni aggiornamento di release di un applicativo “qualsiasi” corrispondono almeno 4-5 integrazioni da riscrivere o comunque da aggiornare.
In una ASL che gestisce 3 ospedali non è assolutamente scontato che il parco applicativo sia omogeneo: in moltissimi casi, soprattutto laddove si sono accorpate ASL, permangono in larga misura i sistemi informativi “originari”. Quindi gli applicativi possono arrivare ad essere quasi 200 e le integrazioni da “tenere sotto controllo e aggiornare” almeno 1.000.
E infine, i devices: alla rete (LAN, MAN, WAN che sia) di un ospedale “medio” sono collegati non meno di 1.200 PC ma anche svariate centinaia di medical devices, apparecchiature elettromedicali. La sostituzione di un ventilatore/monitor in terapia intensiva o in sala operatoria produce un impatto diretto sull’infrastruttura IT dell’ospedale in termini di integrazioni coi software applicativi. Idem in diagnostica per immagini, in laboratorio di anatomia patologica, persino in reparto se consideriamo i devices di misurazione parametri vitali.
Il tutto deve funzionare 24×7, ovviamente.
Questo significa una complessità difficilmente trasportabile su un’architettura cloud di tipo SaaS, dove – per definizione – tutto si basa sull’efficienza garantita da “macro-blocchi” di software applicativo identico per tutti gli utenti. Utenti “omogenei” (tutti gli addetti alla contabilità di tutta la PA) che utilizzano un unico applicativo di gestione contabile, e così via.
Più semplice immaginare un’ASL o un’azienda ospedaliera che va sul cloud per acquistare e configurarsi qualche centinaio di server virtuali dentro ai quali far girare tutta la complicazione applicativa poc’anzi descritta. Qui le cose funzionerebbero senza grossi problemi, sempre che tutto il software applicativo attualmente utilizzato possa essere portato su virtual machines senza difficoltà. E non è affatto scontato che sia così.
Ipotizzare di sostituire tutto il software applicativo esistente con un “mega sistema informativo ospedaliero” di classe ERP completamente autoconsistente e autosufficiente (dotato, cioè, di tutti i moduli applicativi e di tutte le interfacce coi medical devices) è una simpatica esercitazione di fantasia.
Non perché non sia fattibile: di prodotti così, in giro per il mondo, ce ne sono. Molte holding della sanità privata in mezzo mondo hanno ERP clinici completamente integrati cui tutti i loro ospedali accedono via cloud.
Potendo investire non meno di 25 milioni per ogni ospedale (in Italia gli ospedali pubblici sono 561, per un totale di 160.000 posti letto), il conto della spesa è presto fatto: 14 miliardi circa, più non meno di 2,5 miliardi all’anno per la manutenzione ordinaria e straordinaria.
Se ce li abbiamo, allora il gioco è fatto.
Possiamo quindi pensare di risolvere con relativa semplicità il problema della eccessiva frammentazione dei data center delle aziende sanitarie e ospedaliere immaginando un enorme “trasloco” di applicativi che migrano su macchine virtuali nei data center strategici nazionali, quando questi saranno individuati e resi operativi (e forse non basteranno 18 mesi).
Molto più difficile pensare di portare a casa obiettivi di razionalizzazione sul versante applicativo, se non a costi insostenibili.
Il rischio è che, applicando alla lettera il Piano, tutta la mannaia della spending review “coatta” (riduzione del 50% della spesa corrente non veicolata attraverso Consip) vada a ricadere sul settore che meno di tutti – in questo momento – può trovare su Consip una risposta puntuale a tutte le sue esigenze.
La palla, quindi, passa a Consip: è necessario (e anche un po’ urgente) che si metta mano al tema “software applicativo clinico” dando vita a convenzioni specifiche. La sola Convenzione SGI non è sufficiente: sia in termini quantitativi (220 milioni in 6 anni sono briciole) che qualitativi (manca tutta la componente più strettamente clinica, oltre a quella “RIS-PACS”).
E non possiamo assolutamente permetterci di far pagare il conto della spending review ai produttori di software applicativo specifico per la Sanità. Essi hanno già dato, diciamo: se guardiamo i loro bilanci, ci rendiamo conto della differenza abissale dei loro EBITDA rispetto a un qualsiasi loro competitor internazionale.
Siamo al fondo del barile, e non è una bella cosa né per i vendor né per i loro clienti: da adesso in poi, ogni ulteriore Euro raschiato va inevitabilmente a incidere sulla qualità del prodotto/servizio venduto.
