Cartella sociale informatizzata: come?
Costruire una cartella sociale informatizzata ben fatta non è semplice. Ecco un elenco di suggerimenti utili e di errori da evitare
Di Maurizio Motta
Questa scheda vuole segnalare funzioni che possono essere utili in una cartella che voglia essere al contempo strumento dell’operatore dei servizi sociali e mattone fondamentale del sistema informativo. Criteri e funzioni sono qui descritti dividendo forzosamente tra “Sarebbe utile che...” e “Possibilmente evitare di...”; preghiamo il lettore di scusare questo tono un po’ pedante e didascalico, che è usato solo per far emergere in poco spazio scelte e sfide attuative. Importante invece segnalare che quelli qui esposti come “utili” non sono meccanismi solo ipotetici e desiderati, bensì già operanti in diverse esperienze concrete. E chi volesse segnalare a questa rivista proprie esperienze in atto... è benvenuto.
A) Legami con le Anagrafi comunali
Sarebbe utile che la cartella dei servizi sociali fosse connessa con gli archivi anagrafici della popolazione residente, così quando arriva un cittadino, l’operatore non deve scrivere i suoi dati anagrafici nella cartella, ma con il sistema cartella interroga l’anagrafe per cercarlo, e poi automaticamente importa nella cartella il nucleo con tutti i dati anagrafici (e toponomastici).
Ciò consente:
1) all’operatore di verificare on line, leggendo gli archivi anagrafici, dove risiede il cittadino che si rivolge al servizio, e quindi la competenza territoriale alla presa in carico;
2) di eliminare errori di scrittura dei nominativi e dei dati anagrafici nelle cartelle;
3) un importantissimo aggiornamento automatico di tutte le variazioni anagrafiche: qualora un utente deceda o emigri non è più l’operatore sociale che deve di conseguenza aggiornare la cartella, ma automaticamente nella cartella dall’anagrafe vengono variati i dati anagrafici mutati (morte, emigrazione, scomposizione e fusione di nuclei familiari, acquisizione di residenza e cittadinanza, ecc.);
4) l’automatismo descritto al punto precedente consente altre rilevanti funzionalità:
• se nella cartella sono incardinate procedure automatizzate di erogazione degli interventi (si veda il punto C seguente), la variazione anagrafica produce automaticamente variazioni o sospensioni di prestazioni. Ad esempio se decede un beneficiario di assistenza economica o di assegno di cura, queste erogazioni vengono automaticamente sospese dal sistema che importa dall’anagrafe l’informazione del decesso, senza bisogno di alcun intervento da parte degli operatori dei servizi. Lo stesso accade al variare del numero dei componenti il nucleo familiare, se il contributo
economico è stato attivato anche in base a questo dato. È ben evidente la possibilità di evitare in tal modo erogazioni indebite e successive attività di rivalsa;
• se vengono utilizzate proiezioni di spesa e controlli di budget annuali a partire dalle prestazioni che sono in corso nelle cartelle, la mancata cancellazione dei beneficiari che sono deceduti produce una sovrastima della spesa attesa in futuro (che include i deceduti). Lo stesso automatismo consente di poter disporre di liste d’attesa e di prenotazioni che siano sempre “pulite” da deceduti ed emigrati;
5) possibilità di elaborare dati e distribuzioni degli assistiti, o dei richiedenti, che li descrivano in relazione al territorio di residenza: numero, distribuzione e percentuale sui residenti di porzioni del territorio, mappato tramite l’archivio toponomastico che è sotteso a quello anagrafico;
6) possibilità di distinguere (e gestire se lo si desidera) richiedenti e assistiti non ancora anagraficamente residenti, oppure residenti in convivenze anagrafiche convenzionali (come quelle che alcuni Comuni hanno attivato per le persone senza fissa dimora);
7) possibilità di utilizzare una chiave identificativa univoca del cittadino (il codice fiscale) comune anche ad altri archivi (es. ASL, INPS, gestore dell’edilizia residenziale pubblica, ecc.), come presupposto per connettere automaticamente le cartelle dei servizi sociali con tali archivi (si veda il punto E seguente).
Possibilmente evitare, quindi, di:
- far immettere dati anagrafici scrivendoli da parte degli operatori nelle cartelle1;
- eseguire controlli sulle variazioni delle situazioni anagrafiche che hanno rilievo anche per la cartella sociale e la presa in carico (come emigrazione, decesso, trasferimento, scomposizione o fusione dei nuclei familiari) dovendo espressamente richiederlo per ogni utente agli uffici anagrafici dei Comuni.
B) Quali utenti deve gestire la cartella: il singolo o il nucleo familiare?
Sarebbe utile che la cartella sociale includesse l’intero nucleo familiare. Ciò non esclude la possibilità di tracciare i dati del singolo richiedente mo assistito, ma consente la visibilità del suo nucleo familiare per queste finalità:
- vi sono numerosi interventi dei servizi che hanno strutturalmente come beneficiario l’intero nucleo familiare, ossia non si possono erogare se non considerando (anche dal punto di vista amministrativo) tutto il nucleo. Ad esempio le prestazioni di assistenza economica, o di integrazione delle rette di ricovero per autosufficienti, quando il loro importo sia calcolato in base al numero ed al reddito anche di tutti i componenti del nucleo;
- vi sono numerosi interventi nei quali è professionalmente indispensabile considerare natura e dinamiche interne al nucleo, e consentire agli operatori di registrarle nella cartella. Basti pensare a tutti gli interventi sui minori e sui disabili, dove i familiari sono un target importante quanto il singolo utente, oppure al supporto alle famiglie affidatarie. Peraltro questa esigenza di conoscenza e permanente aggiornamento del nucleo familiare dell’utente è comune a non pochi interventi di servizi sanitari, come quelli diretti a persone (e loro famiglie) con sofferenze psichiatriche, in condizioni di dipendenza da sostanze, in lungoassistenza domiciliare.
Possibilmente evitare di:
- dover gestire cartelle separate mper diversi componenti lo stesso nucleo familiare, con proliferazione di cartelle che poi è difficile “mettere insieme” e relazionare;
- perdere nella cartella, in ragione dell’assenza del nucleo familiare, la possibilità di registrare meventi che impattano sull’intero nucleo, anche quando mriguardano singoli componenti non assistiti. Ad esempio se in una famiglia affidataria di mun minore decede uno degli adulti affidatari.
C) Gestione reale delle erogazioni e filiera completa richiesta/intervento
Sarebbe utile che la cartella non fosse solo un “luogo dove l’operatore registra gli interventi dopo che li ha attivati”, cioè dopo averli messi in opera con procedure esterne alla cartella, avendo compilato moduli “fuori” dalla cartella. Meglio se dentro alla cartella l’operatore registra una “richiesta dell’utente”, e poi da lì attiva l’intervento, ed è la cartella che produce la modulistica necessaria e scatena l’iter (anche amministrativo) per erogare. Ad esempio l’operatore inserisce la richiesta per attivare un affidamento (o un contributo economico), l’ufficio che deve autorizzare
appone (sempre dentro alla cartella) la sua approvazione o diniego, e ciò produce concretamente l’erogazione (ad esempio l’emissione del pagamento). Ciò consente:
1) di ridurre i tempi delle comunicazioni interne all’Ente della documentazione (gli uffici “centrali” che devono autorizzare gli interventri vedono la cartella, e non aspettano di ricevere modulistica);
2) un più sicuro aggiornamento dei dati della cartella: gli interventi di tipo XX sono sempre “giusti” e aggiornati non perché gli operatori riescono a registrarli in modo aggiornato, ma perché per erogarli è indispensabile attivarli dentro alla cartella;
3) di aver automaticamente tracciata nella cartella la filiera completa dalla richiesta dell’utente, alla fine dell’istruttoria degli operatori, alla erogazione. E così ogni ufficio può in ogni momento vedere quanti e quali utenti (e quali e quanti interventi) sono: in attesa di istruttoria, con istruttoria finita ed in lista d’attesa per ricevere un intervento, con intervento attivo o chiuso;
4) di ricavare aggiornamenti automatici delle cartelle, che evitino lavoro dell’operatore: ad esempio una cartella che non ha né “richieste in istruttoria” né “interventi in corso” viene chiusa dal sistema;
5) di misurare 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”. Oppure indagare “quanto durano gli affidamenti di minori piccoli”;
6) di ricavare (e monitorare) dati certi di spesa collegati agli utenti.
Possibilmente evitare:
- una cartella che non sia uno strumento di lavoro gestionale, ossia che costringa gli operatori a registrarvi ex post procedure (ad esempio la costruzione di interventi e la relativa modulistica) che devono scrivere “da un’altra parte”;
- una cartella che gestisca le procedure “dalla richiesta dell’utente” alla “erogazione effettiva della prestazione” soltanto per un pezzo di questa filiera: ad esempio senza prevedere che l’approvazione di una richiesta di erogazione (un “ufficio centrale” che autorizza un contributo
economico) generi anche l’effettiva erogazione (l’emissione del pagamento, possibile se l’approvazione immessa nella cartella è legata anche ai programmi della contabilità e bilancio che appunto emettono i pagamenti).
D) Poter scrivere in cartella un diario e relazioni per terzi
Sarebbe utile per gli operatori avere nella cartella la possibilità di scrivere il “diario” di che cosa accade nel nucleo assistito (eventi, progetti, verifiche, ecc.) e di usare (con funzioni di “copia/incolla”) questi testi anche per confezionare relazioni e documenti da inviare a terzi (ad esempio relazioni per il Tribunale per i Minori). Questo serve:
1) per trasferire ad altri colleghi i contenuti delle cartelle (diario incluso) in modo che siano leggibili;
2) per disporre di documentazione chiara nei casi di accesso da parte di terzi ai contenuti delle cartelle (accesso agli atti, sequestro da parte della Magistratura).
Possibilmente evitare:
- di costringere gli operatori ad avere “contenitori” diversi per le diverse attività di servizio: nella cartella registro gli interventi, ma devo scrivere da un’altra parte (in files tutti separati) il diario e le relazioni;
- di avere una cartella informatizzata che non contenga anche un luogo dove l’operatore usa non “codificazioni” e “menù preconfezionati”, ma anche una sua più libera scrittura, necessaria per documentare eventi e progetti.
E) Integrare la cartella con i sistemi informativi di altre amministrazioni: l’interoperabilità
Poiché nel prendere in carico gli utenti è indispensabile interagire con altri servizi, sarebbe utile che anche le informazioni dei differenti
servizi venissero automaticamente rese intercomunicabili. Sono operanti sul punto sistemi molto diversi, ma questo aspetto sembra prevalente: non è realistico immaginare una “cartella unificata” in gestione comune tra molti servizi (ad esempio sociali e sanitari). Dunque l’obiettivo è di “far comunicare” cartelle che restano diverse, affinché si ottenga in ogni caso lo scambio automatico di informazioni2. Sarebbe utile quindi che la cartella includesse il massimo di interoperabilità possibile con altri sistemi da correlare; per esempio:
1) se gli operatori di un servizio (ad esempio della UVG) registrassero sulla loro cartella dei dati (ad esempio l’esito della valutazione socio-sanitaria), gli operatori di un altro servizio (ad es. il servizio sociale) dovrebbero vederli automaticamente importati anche nella loro cartella;
2) se il dato generato da un servizio (ad esempio l’autorizzazione alla spesa di una ASL per avviare un piano di assistenza domiciliare per non autosufficienti) deve attivare una procedura d intervento congiunta con un altro servizio (ad esempio l’avvio del piano di assistenza sociosanitario
anche a cura dei servizi comunali), la sua immissione in una cartella (dell’ASL), attiva una procedura erogativa anche nell’altra cartella (ad esempio sbloccando la costruzione del piano di assistenza);
3) che nella cartella sociale possano essere importate automaticamente (oppure operi un accesso in lettura facilitato) informazioni di altre amministrazioni che sono rilevanti: ad esempio nominativo del medico di base, eventuale assegnazione (e morosità nell’affitto) dell’ente che gestisce l’edilizia residenziale pubblica;
4) che siano facilitati accessi on line agevoli alle banche dati di altre Amministrazioni necessarie per effettuare i controlli sulle autocertificazioni degli utenti sulle proprie condizioni economiche (ad esempio INPS, Agenzia delle Entrate, Agenzia del Territorio).
Possibilmente evitare, ma qui sarebbe meglio molto più modestamente dire “lavorare per ridurre”:
- la creazione di nuovi sistemi informativi gestionali dell’utenza che siano slegati e non comunicanti, ossia riguardino solo “un singolo servizio o prestazione”;
- i vincoli agli accessi e agli scambi tra diversi sistemi, ad esempio quando si rendono disponibili letture sugli archivi solo concedendo un numero di password non adeguato.
F) Ricavare prodotti informativi e dati
Sarebbe utile che dalla cartella si potessero ricavare output utilizzabili per diverse funzioni:
1) dati necessari agli operatori di front office, ad esempio elenco e numero degli utenti in situazioni da monitorare: in attesa di un termine dell’istruttoria, con interventi in corso, presenti in diverse porzioni del territorio;
2) informazioni per rispondere ai debiti informativi istituzionali (i “dati da fornire alla Regione” o “all’ISTAT”) prodotte automaticamente dal sistema cartella, senza costringere a defatiganti lavori manuali di ricostruzione dei dati per ottenerli “come li vuole la Regione”.
Con due ulteriori attenzioni:
- far in modo che i dati siano ricavati dalle procedure gestionali effettive (ossia dagli iter reali per erogare), per evitare la scarsa affidabilità e il lavoro aggiuntivo di dover richiedere agli operatori di compilare “altre statistiche”, una tantum, diverse e aggiuntive rispetto a quelle
ricavabili dalla cartella;
- producendo dati non solo perché “bisogna darli alla Regione”, ma anche mirati ad indagare fenomeni di interesse nel governo locale: ad esempio i tempi di attesa per gli utenti, le durate di interventi (specialmente quando una lunga durata è fattore di criticità), il monitoraggio non solo di “quanti utenti si sono serviti in totale” (la prevalenza), ma anche di “quanti di questi erano nuovi utenti” (l’incidenza); ciò richiede ad esempio, che la cartella sappia estrarre chi “diventa utente per la prima volta” all’interno di un periodo di tempo.
Possibilmente evitare, di introdurre flussi informativi (anche nazionali) che richiedano agli Enti gestori e agli operatori elaborazioni non fondate sui sistemi informativi gestionali, o che aggiungano flussi diversi e sovrapposti. Ad esempio se si attiva un flusso che richiede di inviare (in Regione, ad un Ministero) “quanti anziani non autosufficienti erano vedovi”, è verosimile che non ci sia speranza di risposta se il dato “essere vedovo” non è incluso nelle cartelle3. Ogni volta che si pensa di ricavare dati fornendo agli operatori una modalità di raccolta che sia diversa e parallela ai sistemi gestionali si può avere un fondato dubbio che quella raccolta:
- o non potrà essere realizzata, perché impone agli operatori una doppia registrazione (una volta nei sistemi gestionali e un’altra volta nel sistema dedicato alla raccolta dati mirata, anche se è un sistema informatico);
- oppure sarà eseguita con fatica nei primi mesi, e poi tenderà ad essere progressivamente abbandonata.
Maurizio Motta
Articolo tratto dal n° 3 (maggio-giugno 2011) della rivista "Welfare oggi" edita da Maggioli
Percorsi:
