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


Maurizio Motta | 29 Ottobre 2018

In precedenti articoli1 si sono discussi diversi snodi che sarebbe opportuno considerare nella costruzione del SIUSS, per progettare la sua architettura complessiva verso funzionalità utili (ai servizi ed agli utenti) anche prima di approfondire “quali dati” devono essere gestiti.

 

In questo articolo terminiamo la serie con riflessioni connesse a questa domanda: se (come abbiamo cercato di dimostrare) lo strumento più efficace per i servizi locali è un sistema che consenta più funzioni, capace di gestire più interventi, come sarebbe utile si presentasse all’operatore dei servizi che riceve cittadini con richieste di interventi sociali?

Una ipotesi potrebbe essere quella di fornire un accesso che proponga all’operatore un cruscotto iniziale, una maschera di ingresso, che gli consenta di scegliere diversi domini da aprire, permettendogli di entrare negli ambienti più utili per lavorare con il vantaggio di poter navigare tra diversi ambienti e funzioni con facilità2. Il cruscotto potrebbe presentare questi ambienti:

  • Il catalogo delle prestazioni possibili: dovrebbe essere il catalogo dinamico di tutte le possibili prestazioni (ad esempio dedicate al sostegno del reddito) come strumento che serve all’operatore per informare i cittadini su che cosa potrebbero richiedere, come e dove, e non solo presso il servizio nel quale si trovano. E’ lo strumento che è stato descritto nell’articolo III di questa serie, con l’obiettivo non solo di far conoscere e attivare le prestazioni del servizio che riceve il cittadino, ma tutte quelle possibili, anche da richiedere ad altri punti di accesso
  • La mappa delle risorse locali, che potrebbe essere un ambiente liberamente popolabile dai servizi locali, nel quale descrivere le risorse del territorio che sono ritenute utili oltre alle prestazioni istituzionali, ad esempio associazioni significative, sportelli informativi, progetti e percorsi proponibili, strutture di accoglienza, e simili. Poiché si tratta sempre di “opportunità” per i cittadini (e gli operatori) questo ambiente potrebbe anche essere una parte di quello descritto al punto 1) precedente, purché abbia accesso e visibilità separate con evidenza. Si tratta di disporre di un ambiente che descrive risorse molto legate al territorio, e che richiede un costante aggiornamento. Peraltro questo segmento informativo potrebbe anche essere utile per immettere valutazioni sull’efficacia ed appropriatezza dei diversi percorsi, del tipo “si è evidenziato che il progetto/risorsa “x” è più adatto a persone/nuclei con le problematiche “y”.
  • Lettura delle prestazioni fruite. Questo ambiente dovrebbe rendere visibili le prestazioni sociali di cui già fruisce il nucleo familiare, anche se erogate da percorsi e sistemi diversi da quelli gestibili nell’ambiente 4) successivo. Lo scopo è di consentire all’operatore di visualizzare gli interventi già fruiti dal nucleo familiare, col duplice obiettivo di:
    • invitare a richiedere prestazioni che potrebbe ricevere e non ha ancora richiesto;
    • dimensionare le prestazioni da attivare tenendo anche conto di quelle che già il nucleo riceve.

 

Il contenitore di elezione di questi dati potrebbe essere il Casellario dell’assistenza in costruzione presso l’INPS. Ma su questo strumento è opportuno riflettere, sia sui nodi emersi nella messa in opera sia sui prodotti informativi che può offrire; e sul punto è stata proposta la discussione contenuta nell’articolo II di questa serie.

  • Gestione delle prestazioni erogabili. Questo è l’ambito che coincide con i sistemi gestionali, ossia che consente di istruire le richieste ed attivare le prestazioni. Dunque dovrebbe includere:
    • Le “cartelle informatizzate”, ossia i contenitori entro i quali i servizi registrano e gestiscono le richieste del nucleo familiare, le successive istruttorie, le erogazioni degli interventi. E’ questo lo snodo più complesso rispetto all’architettura informatica, perché deve aprire sistemi che localmente sono molto diversificati. Le funzionalità che sarebbe utile gestire entro le cartelle sono state discusse nell’articolo II di questa serie, e va anche ricordato il grande rilevo della possibilità di importazione automatica nella cartella informatizzata dei dati anagrafici del nucleo familiare da gestire, e delle sue variazioni nel tempo, tratte dagli archivi anagrafici dei residenti.
    • Le procedure gestionali di prestazioni nazionali, non solo il REI (o il futuro Reddito di Cittadinanza), ma anche altre prestazioni che il reddito minimo nazionale non abbia ancora incluso. L’obiettivo è duplice:
    • consentire al servizio che riceve il nucleo di attivare il numero maggiore di prestazioni nazionali senza obbligare il richiedente a peregrinare tra diversi sportelli e servizi;
    • avviare l’istruttoria delle richieste e le successive erogazioni di interventi, anche nazionali, come funzione attivabile entro la cartella informatizzata. Ossia prevedere che anche se le prestazioni nazionali richiedono che venga lanciata una specifica procedura di istruttoria e di intervento (come accade per il REI), ciò possa avvenire dall’interno della cartella informatizzata sul nucleo familiare, che già contiene eventuali altre valutazioni ed interventi locali.

Va  ricordato che è importante consentire la visibilità delle prestazioni che confluiscono sull’intero nucleo familiare anagrafico, oltre che sul singolo individuo, in quanto il nucleo è il soggetto che viene preso in carico nei servizi.

 

  • Banca dati ISEE e altri controlli. Da questo ambiente sarebbe utile fornire all’operatore:
    • l’accesso alla banca dati che gestisce gli ISEE. Ma anche per visualizzare la “DSU attestate” (ossia popolate con i dati immessi dall’INPS e dall’Agenzia delle Entrate), perché da esse deriva l’attestazione ISEE, e contengono diverse informazioni che non sono visibili né nella DSU che è in mano al cittadino, né nell’attestazione finale dell’ISEE;
    • l’accesso alle altre banche dati, ove possibile, che devono essere utilizzate dagli enti erogatori delle prestazioni per eseguire i controlli su quanto autodichiarato dai cittadini richiedenti, ossia sui dati che il sistema ISEE non controlla automaticamente ma affida a verifiche degli enti che ricevono gli ISEE3. Questi controlli sono organizzati in modo molto differente nei diversi territori locali, spesso affidandoli ad appositi servizi di back office (quindi diversi da quelli ove lavorano gli operatori di front office). Ma esistono enti gestori nei quali si è preferita una funzione di controllo eseguita dagli operatori di front office al momento nel quale il cittadino consegna la sua autodichiarazione, allo scopo di ridurre gli addebiti ex post ai dichiaranti, e le conseguenti sanzioni.

 

Ma qualunque sia l’ufficio che esegue i controlli, il cruscotto potrebbe migliorare i controlli sulle autocertificazioni con questa funzionalità: attualmente chi esegue i controlli deve accedere (tramite credenziali diverse dedicate) uno per volta successivamente a tutti gli archivi che è necessario esplorare, ad esempio INPS, Agenzia delle Entrate, PRA, e così via. Ed inoltre dopo una apposita convenzione per l’accesso con ciascuna di queste Amministrazioni. Invece il cruscotto potrebbe fornire una maschera di ingresso unica per tutti gli archivi da consultare, col duplice vantaggio di:

  • presentare sempre all’operatore una sequenza/mappa guidata di tutti gli archivi ai quali è utile che acceda,
  • evitare lo spreco dei tempi necessari per l’entrata ed uscita dai diversi singoli archivi.

 

Questa opportunità, ossia poter digitare una unica volta le credenziali di accesso per poter poi accedere a tutti i diversi archivi, presuppone la concertazione di chi allestisce il sistema con le amministrazioni alle quali appartengono gli archivi.

  • Dati e statistiche. Questo ambiente potrebbe facilitare la visione di elaborazioni utili, ad esempio per monitorare domanda ed offerta. I contenuti perciò non riguardano singole persone o nuclei, ma reportistica ed elaborazioni di dati. In merito è utile ricordare che:
    • per molte delle attuali misure nazionali contro la povertà (ad esempio gli assegni sociali Inps, gli assegni di maternità per i nuovi nati e i 3 figli minori, i bonus per gas ed elettricità, la carta acquisti) non sono resi disponibili on line, nemmeno agli enti locali, dati descrittivi sulla domanda e sull’offerta. Quindi un importante obiettivo del cruscotto potrebbe essere di far crescere le informazioni sul tema, presentando sistematicamente anche dati sinora non forniti.
    • Dati aggregati devono essere progettati evitando di limitarsi a rappresentare ex post “quanti sono stati i fruitori” e “quanto si è speso”. E’ invece opportuno mettere a fuoco anche altri indicatori significativi, ad esempio aggiungere a questo dato di prevalenza (ossia il totale dei fruitori in un intero anno solare, ed anche in un momento dato), anche dati di incidenza (i nuovi utenti diventati fruitori per la prima volta in un anno), esibendoli in serie storiche; ed anche informazioni che diano dimensioni al numero di nuclei che fruiscono contestualmente di più prestazioni (meglio se sia nazionali che locali), con evidenza delle tipologie dei nuclei e delle prestazioni.
    • Gli enti gestori locali di interventi socio assistenziali e sociosanitari devono periodicamente trasmettere informazioni sulle proprie prestazioni in base a specifici debiti informativi istituzionali (ad esempio le rilevazioni annuali Istat o quelle richieste dalle regioni). Sarebbe dunque opportuno approfondire come l’ambiente del cruscotto che qui è denominato come 6) possa anche produrre in automatico le reportistiche istituzionali richieste ai servizi.

Merita richiamare il fatto che disegnare il sistema di report ed indicatori che il SIUSS potrebbe produrre significa anche interrogarsi su quali informazioni (ed in quale modo esposte) sono davvero utili ai diversi livelli del sistema. Ossia ai servizi per monitorare la loro attività, ai governi (anche locali) per fare scelte programmatiche. Anche per evitare il rischio di rituali esposizioni di dati che poi non servono a decidere e a gestire.

 

Ma queste funzioni e questa ipotesi di “cruscotto” cosa c’entrano col SIUSS? Seguendo la logica utilizzata nei precedenti articoli di questa serie, è cruciale che il SIUSS venga costruito:

  • per massimizzare le funzionalità che offre a tutti i soggetti del sistema, ed in primis ai servizi che hanno rapporto con l’utenza;
  • come infrastruttura che viene offerta dal livello nazionale ai servizi ed enti erogatori, sia per garantire uniformità nella strumentazione (e nelle funzioni possibili), sia perché uno sviluppo nazionale ha costi molto inferiori rispetto a molteplici e ripetuti costi locali.

Se si pensa sia rischioso (ad esempio per la tutela della privacy) fornire a tutti i servizi locali un cruscotto con molte funzioni anche gestionali, il facile rimedio consiste nel prevedere nel sistema diversi profili di accesso a diverse funzioni, ciascuno dei quali potrà essere attribuito a servizi e persone abilitate a svolgere tali funzioni.

 

Che cosa sarà il SIUSS è interessante oggetto di osservazione per il futuro. Visto che richiede investimenti e lavoro sarebbe però davvero una occasione mancata se non si misurasse con gli snodi e le funzioni che abbiamo provato a discutere in questa serie di articoli.

  1. Qui i link ai precedenti articoli della serie: parte I; parte II; parte III
  2. Questa ipotesi è anche presentata nel capitolo IX  di AA.VV. Il  Reddito d’inclusione sociale (REIS). La proposta dell’Alleanza contro la povertà in Italia, Il Mulino, Bologna, 2016
  3. I dati di questa natura sono elencati all’art. 10 comma 7 del decreto sull’ISEE (il dPCM 5/12/2013 n° 159)