Come costruire il Sistema Informativo Unico dei servizi sociali (SIUSS) – (II)

Attualmente i servizi locali utilizzano sistemi informativi nazionali per gestire prestazioni statali che sono ciascuno costruito per la singola prestazione, come il sistema INPS per inviare le richieste del Reddito di Inclusione e seguirne l’iter, o per gli assegni per famiglie con nuovi nati o 3 minori, per i bonus energia, per i contributi per l’affitto, e altri. Applicativi che sono del tutto separati tra di loro, ed anche dagli altri sistemi per gestire i diversi interventi sociali locali. Per questi ultimi i servizi utilizzino sistemi informativi che ogni territorio ha allestito, ad esempio nei servizi sociali con lo strumento di norma denominato “cartella sociale informatizzata”.

Questo scenario produce non pochi problemi; ad esempio:

• obbliga i servizi a usare strumenti diversi per interventi sulla stessa famiglia, con evidenti aggravi operativi (tempi e carichi di lavoro): in ogni sistema va replicata l’immissione dei dati della famiglia (anagrafici, reddituali, per il progetto), occorre una contestuale conoscenza del funzionamento di ogni sistema, le credenziali di accesso possono non essere adeguatamente disponibili;
• non consente al servizio di visualizzare di quali interventi (da chiunque erogati) già fruisce la famiglia, sia per poterla informare di prestazioni che potrebbe richiedere sia per tener conto di ciò che già riceve nell’istruire una nuova prestazione, o per monitorare l’intera filiera di richieste ed interventi.

L’obiettivo di come conoscere tutte le prestazioni in una stessa famiglia, rispetto agli interventi contro la povertà era uno degli scopi del “Casellario dell’assistenza” attivato presso l’INPS, che tuttavia sinora:

• produce inadeguate funzionalità per i servizi locali, perché consente di vedere solo le prestazioni erogate dall’INPS o dallo stesso Ente che accede; ed evidenzia le prestazioni per le singole persone e non per l’intero nucleo familiare (che necessariamente è il vero utente dei servizi).
• Evidenzia grandi difficoltà nel catturare gli interventi locali perché richiede agli Enti erogatori di costruire e gestire ad hoc invii all’INPS dei dati sui loro utenti e interventi. Operazione che ha costi (finanziari ed organizzativi) non realisticamente sostenibili in molti governi locali perché implica che l’estrazione dei dati per il Casellario avvenga riconfezionando output dagli archivi gestionali locali. Peraltro non è nemmeno realistico pensare che i servizi locali possano in continuo dedicare tempo lavoro solo per popolare ad hoc i flussi per il Casellario caricandovi i loro dati gestionali.

Ma quale servizio sociale che riceve famiglie in difficoltà o povere non vorrebbe poter vedere ciò che già il nucleo riceve e poi attivare insieme tutti i possibili interventi (sia locali che nazionali), entro un sistema più unificato, riducendo il suo onere operativo ed evitando alla famiglia di dover peregrinare tra diversi servizi? E quale Ente/servizio non vorrebbe evitare oneri per costruire invii ad hoc dei propri dati ad altri livelli del sistema?

Non sono ipotesi da “fantascienza informatica”, bensì strategie che la costruzione del SIUSS potrebbe adottare. Ecco alcuni possibili vincoli ed opportunità per ricomporre i diversi sistemi informativi¹.

Non è realistico ipotizzare di sostituire gli attuali sistemi dei diversi enti che erogano prestazioni sociali, anche locali, con un sistema informativo unificato, che consenta di gestirle tutte, entro una base dati che tutte le conservi. Ossia un modello nel quale il SIUSS includa al suo interno tutte le prestazioni sociali rilevanti, comprese quelle locali, rimpiazzando ogni sistema attuale. È un’ipotesi poco sostenibile, sia per i costi di revisione che implicherebbe, sia per le difficoltà ad armonizzare tutti i front office dei diversi enti erogatori.

Parrebbe dunque opportuno muovere verso altre architetture che consentano al contempo:

• ampia interoperabilità informativa tra diversi servizi, a partire da sistemi squisitamente gestionali con logica “digital first”: i dati si immettono una volta sola e si usano per gestire utenza e prestazioni;
• di popolare un data base anche nazionale con tutte le prestazioni in atto su una famiglia, ma evitando ai servizi locali gravosi oneri di “invii” ripetuti di dati.

In merito potrebbe essere utile valutare due strategie possibili:

1. prevedere che i sistemi esistenti continuino a gestire separatamente ciascuno le proprie prestazioni (nazionali o locali), ma che venga allestita una piattaforma ad essi sovraordinata, la quale si incarichi di “pescare” in ciascun sistema le informazioni per ricomporle (all’interno di uno stesso nucleo familiare) in un data base unificato, da tutti consultabile. Ossia puntare ad una architettura nella quale non esiste un “invio di dati” dai servizi locali a livelli superiori, ma è la piattaforma di interoperabilità che lo gestisce in automatico e restituisce a tutti la visibilità su ogni prestazione.
2. Un’altra strategia potrebbe prevedere che il cittadino debba presentare la tessera sanitaria (arricchendone le funzioni come “carta dei servizi”) quando richiede qualunque prestazione anche sociale e sociosanitaria (nazionale o locale), e che i sistemi che gestiscono gli interventi scarichino sulla tessera i loro dati di prestazione. Diventa così la tessera il connettore automatico degli archivi, e scarica ad ogni accesso i suoi contenuti nel data base nazionale, il quale consente a chi accede di vedere lo stato delle richieste e degli interventi, meglio se per più settori del welfare (almeno sociale, sociosanitario e sanitario). Anche qui si evitano poco realistici “invii di dati” dai servizi locali, perché è in base alla lettura della tessera che il data base nazionale contiene le prestazioni da chiunque erogate, che vengono rese visibili ai servizi al momento dell’uso della tessera quando il cittadino presenta una richiesta.

Peraltro le strategie “1” e “2” potrebbero essere contestuali, ad esempio usando la “1” per i flussi che la “2” gestisce con più difficoltà, ad esempio le revoche degli interventi o le scadenze fisiologiche delle prestazioni attive.

Naturalmente entrambe queste architetture implicano anche investimenti locali per far dialogare i sistemi gestionali dei servizi territoriali con il meccanismo complessivo. Ma è ragionevolmente certo che questo costo una tantum è ampiamente inferiore agli attuali oneri di costante “invio di dati” e di “navigazione multipla” in diversi applicativi.

Ma oltre a robusti meccanismi di interoperabilità tra sistemi/prestazioni diverse (anche tra livello locale e nazionale), c’è un altro requisito importante: usare nei servizi di front office strumenti informatici che consentano di gestire davvero le prestazioni.

• Con un’architettura che opera in questo modo: il servizio che riceve l’utente usa una cartella informatizzata che non è un luogo dove l’operatore registra gli interventi dopo che li ha messi in opera con procedure esterne alla cartella, ossia dopo aver compilato moduli “fuori” dalla cartella. Invece entro la cartella l’operatore registra una richiesta dell’utente, una conseguente valutazione e progetto, e da questi dati attiva l’intervento: è la cartella che produce la modulistica necessaria e che scatena l’iter (anche amministrativo) per erogare. Ad esempio l’operatore inserisce la richiesta per avviare un contributo economico (o un affidamento), l’ufficio che deve autorizzarlo appone (sempre entro la cartella informatizzata) la sua approvazione o diniego, e ciò produce concretamente l’erogazione (ad esempio l’emissione del pagamento e/o dell’assicurazione per gli affidatari). Questa funzione gestionale è di norma presente entro i sistemi che attivano le prestazioni nazionali, ma è opportuno attivarla anche nella gestione delle cartelle informatizzate locali.
• A che cosa serve questo funzionamento? 

1. A ridurre i tempi delle comunicazioni interne all’ente erogatore: gli uffici “centrali” che devono autorizzare gli interventi vedono on line nella cartella informatizzata le proposte dei servizi di front office, e non devono aspettare di ricevere modulistica.
2. Per un più sicuro aggiornamento dei dati della cartella: gli interventi sono sempre esatti ed aggiornati non perché gli operatori riescono a registrarli in modo aggiornato, ma perché per erogarli è indispensabile costruirli dentro alla cartella.
3. Di aver traccia automatica nella cartella della filiera completa dalla richiesta dell’utente, alla fine dell’istruttoria degli operatori, alla erogazione. E dei relativi tempi di ogni fase. Così ogni ufficio autorizzato può in ogni momento vedere quanti e quali utenti (e quali e quanti interventi) sono: in attesa di istruttoria, con istruttoria terminata ed in lista d’attesa per ricevere un intervento, con intervento attivo o chiuso (e per quale motivo).
4. Di introdurre aggiornamenti automatici delle cartelle, che evitino lavoro dell’operatore o sovrastima dei “casi in carico”: ad esempio una cartella che non ha né “richieste in istruttoria” né “interventi in corso” viene chiusa dal sistema e non risulta più attiva.
5. Di misurare e monitorare i tempi e le durate importanti: ad esempio “dalla richiesta dell’utente” alla “entrata in lista d’attesa”. Oppure “dall’entrata in lista d’attesa” alla “attivazione dell’intervento”.
6. Di ricavare (e monitorare) dati certi di spesa collegati agli utenti.

Naturalmente questi sviluppi, in quanto dedicati a gestire le prestazioni locali, implicano investimenti e progettazione dei territori, appropriata ai diversi sistemi in essere. Ma l’avvio del SIUSS potrebbe prevedere anche incentivi per muovere in questa direzione. E in ogni caso il SIUSS, restando irrealistica l’ipotesi di sostituire tutti i sistemi gestionali con un unico applicativo, potrebbe offrire ad ogni servizio di front office una unica maschera di ingresso nella quale l’operatore possa scegliere il sistema da usare (quello che attiva prestazioni locali o quello/i che gestiscono prestazioni nazionali), evitando replicazioni di dati.

Nei successivi articoli sul SIUSS approfondiremo ipotesi su altri diversi strumenti utili ai servizi di front office ed agli attori dei sistemi di welfare².

1. Analisi e discussioni più ampie sul tema sono in M. Motta, REI. Contrasto alla povertà e reddito minimo, Maggioli editore, 2018, e nel capitolo IX di AA.VV. “Il Reddito d’inclusione sociale (REIS). La proposta dell’Alleanza contro la povertà in Italia “, Il Mulino, 2016.
2. Qui i link agli altri articoli della serie: parte I; parte III, parte IV