Risk ManagementIncident ReportingGelli-BiancoSicurezza delle cureEasy Risk

Incident Reporting in Sanità: cos'è e come costruire un sistema di segnalazione che funziona

F

Fabio Vantaggiato

Autore

10 luglio 2026

L'incident reporting è il processo con cui le strutture sanitarie raccolgono e analizzano near miss ed eventi avversi per imparare dagli errori e prevenirli. È il cuore operativo di qualunque sistema di gestione del rischio clinico: senza segnalazioni non ci sono dati, senza dati non c'è analisi e senza analisi non c'è prevenzione. Questa guida spiega a direzioni sanitarie, risk manager e uffici qualità cos'è l'incident reporting, cosa prevede la normativa italiana, come strutturare il flusso dalla segnalazione al Piano Annuale di Risk Management e come superare gli ostacoli che, nella pratica, fanno fallire i sistemi di segnalazione.

Cos'è l'incident reporting e a cosa serve

L'incident reporting è la raccolta strutturata e volontaria delle segnalazioni di eventi — o quasi-eventi — che hanno causato o avrebbero potuto causare un danno al paziente. Non è un registro delle colpe: è uno strumento di apprendimento organizzativo. L'assunto di fondo, consolidato dalla letteratura internazionale sulla sicurezza dei pazienti, è che l'errore in sanità è raramente il fallimento di un singolo professionista e quasi sempre il risultato di fattori di sistema: processi mal disegnati, comunicazioni interrotte, carichi di lavoro, tecnologie inadeguate, farmaci dai nomi simili. Ogni segnalazione è un frammento di conoscenza su come il sistema fallisce davvero.

Perché questo meccanismo funzioni serve una precondizione culturale: la cultura giusta e non punitiva (no-blame, o più precisamente just culture). In una cultura della colpa, chi segnala teme conseguenze disciplinari, giudizi dei colleghi o ripercussioni legali: il risultato è il silenzio, e il sistema di reporting muore di inedia. In una cultura giusta, la segnalazione è protetta e incoraggiata, l'analisi si concentra sul perché l'evento è potuto accadere e non sul chi, e la responsabilità individuale resta confinata ai casi di violazioni consapevoli e ingiustificabili. Il volume e la qualità delle segnalazioni sono, non a caso, tra gli indicatori più eloquenti della maturità di un'organizzazione sanitaria.

L'incident reporting è uno dei tasselli — insieme a RCA, FMEA/FMECA, audit clinico, Safety Walkaround e M&M review — del più ampio sistema di gestione del rischio clinico: per il quadro complessivo rimandiamo alla nostra guida completa al rischio clinico in sanità.

Near miss, evento avverso, evento sentinella: le definizioni

Un sistema di segnalazione efficace inizia da un glossario condiviso. Le tre categorie fondamentali, allineate alla terminologia del Ministero della Salute, sono:

  • Near miss (quasi-evento): un errore o una condizione pericolosa che aveva la potenzialità di causare un danno al paziente, ma non lo ha causato — per caso fortuito o perché intercettato in tempo (una prescrizione errata individuata prima della somministrazione). I near miss sono la miniera più ricca di un sistema di reporting: offrono le stesse informazioni di un evento avverso, senza il danno.
  • Evento avverso: un evento inatteso correlato al processo assistenziale che ha comportato un danno al paziente, non intenzionale e indesiderabile. Non tutti gli eventi avversi derivano da un errore: interessa distinguerli in prevenibili e non prevenibili, perché è sui primi che si concentra l'azione di miglioramento.
  • Evento sentinella: un evento avverso di particolare gravità, potenzialmente indicativo di un serio malfunzionamento del sistema, che causa morte o grave danno al paziente e mina la fiducia dei cittadini nel servizio sanitario. Per gli eventi sentinella la segnalazione è un obbligo di flusso informativo verso il livello nazionale, e ogni singolo caso richiede un'indagine approfondita.

Distinguere correttamente le tre categorie al momento della classificazione non è un esercizio tassonomico: determina il percorso di analisi che la segnalazione dovrà seguire, come vedremo più avanti.

Il quadro normativo italiano

In Italia l'incident reporting non è una buona pratica facoltativa: è parte di un impianto normativo preciso, che ogni direzione sanitaria deve conoscere.

Legge 208/2015: la funzione di risk management è obbligatoria

La Legge 28 dicembre 2015, n. 208 (art. 1, commi 538-540) ha imposto a tutte le strutture sanitarie, pubbliche e private, l'attivazione di una funzione di monitoraggio, prevenzione e gestione del rischio sanitario. Tra le attività che questa funzione deve presidiare rientrano proprio la rilevazione degli eventi avversi e la predisposizione delle azioni conseguenti: senza un sistema di incident reporting operativo, la funzione richiesta dalla legge resta sulla carta.

Legge 24/2017 (Gelli-Bianco): sicurezza delle cure e tutela del segnalatore

La Legge 8 marzo 2017, n. 24 ha elevato la sicurezza delle cure a parte costitutiva del diritto alla salute (art. 1), ha istituito i Centri regionali per la gestione del rischio sanitario (art. 2) e l'Osservatorio nazionale delle buone pratiche presso AGENAS (art. 3). Per l'incident reporting la disposizione più importante è però l'art. 16: i verbali e gli atti conseguenti all'attività di gestione del rischio clinico non possono essere acquisiti o utilizzati nell'ambito di procedimenti giudiziari. È la protezione giuridica che rende credibile la promessa di non punibilità: ciò che scrivi in una segnalazione o in un audit di rischio clinico serve a imparare, non ad accusare. Con l'entrata a pieno regime della legge — decreti attuativi inclusi, come il D.M. 232/2023 — dimostrare un sistema di reporting funzionante diventa ancora più rilevante: ne abbiamo parlato nell'approfondimento sulla Gelli-Bianco a regime dal 16 marzo 2026.

SIMES e Raccomandazioni ministeriali

Il SIMES (Sistema Informativo per il Monitoraggio degli Errori in Sanità, D.M. 11 dicembre 2009) è il flusso informativo nazionale che raccoglie gli eventi sentinella e le denunce dei sinistri: il sistema di incident reporting interno deve essere in grado di alimentarlo con dati completi e tempestivi. Accanto al flusso, il Ministero della Salute ha pubblicato le Raccomandazioni per la sicurezza dei pazienti (n. 1-19), che coprono le aree a maggior rischio — dalla corretta identificazione del paziente ai farmaci LASA, dalla prevenzione delle cadute alla sicurezza in sala operatoria. Le segnalazioni raccolte sono lo strumento con cui la struttura verifica se le Raccomandazioni sono davvero applicate o se esistono scostamenti sistematici.

Come strutturare il sistema: dal modulo di segnalazione al PARM

Un sistema di incident reporting maturo è un ciclo chiuso, non una cassetta delle lettere. Il flusso di riferimento si articola in sei passaggi.

1. Segnalazione

Il modulo deve essere raggiungibile in pochi secondi da qualunque operatore, compilabile in pochi minuti e comprensibile senza formazione specifica. Campi essenziali: cosa è successo, dove, quando, quali conseguenze per il paziente, quali fattori hanno contribuito. Il resto si raccoglie dopo: ogni campo obbligatorio in più è una segnalazione in meno.

2. Classificazione

Il risk manager (o la funzione delegata) prende in carico la segnalazione e la classifica: near miss, evento avverso o evento sentinella; area e processo coinvolti; gravità effettiva e potenziale. La classificazione determina la priorità e il percorso di analisi, e — per gli eventi sentinella — attiva gli obblighi di segnalazione verso il flusso SIMES.

3. Analisi

Non tutti gli eventi meritano lo stesso investimento analitico. Per gli eventi gravi ed eventi sentinella lo strumento di riferimento è la Root Cause Analysis (RCA): un'indagine strutturata e multidisciplinare che risale dalle cause immediate ai fattori latenti di sistema. Per i near miss e gli eventi a bassa gravità, l'analisi più produttiva è quella aggregata: i singoli casi dicono poco, ma le serie storiche per tipologia, reparto e fascia oraria rivelano pattern ricorrenti prima che producano un danno. In ottica proattiva, i dati del reporting alimentano anche le analisi FMEA/FMECA sui processi critici.

4. Azioni correttive

Ogni analisi deve chiudersi con azioni concrete: revisione di una procedura, doppio controllo su una fase critica, formazione mirata, modifica di un layout o di una tecnologia. Ogni azione ha un responsabile, una scadenza e un indicatore di verifica dell'efficacia. Un'analisi senza azioni è un costo; un'azione senza verifica è una speranza.

5. Feedback al segnalatore

È il passaggio più trascurato e uno dei più importanti: chi ha segnalato deve sapere che la sua segnalazione è stata letta, analizzata e ha prodotto qualcosa. Il feedback — individuale o attraverso momenti collettivi come le M&M review e i report periodici di reparto — è il carburante che tiene in vita il sistema. Dove il feedback manca, le segnalazioni calano nel giro di pochi mesi.

6. Confluenza nel PARM

I dati del reporting — volumi, tipologie, aree critiche, esiti delle analisi, stato delle azioni — confluiscono nel Piano Annuale di Risk Management (PARM) e nella relazione annuale a consuntivo: sono la base evidence-based con cui la direzione fissa le priorità dell'anno successivo. Un PARM costruito sui dati del proprio incident reporting è difendibile davanti a qualunque interlocutore; un PARM fotocopiato dall'anno precedente no. Al PARM abbiamo dedicato una guida specifica.

Gli ostacoli tipici e come superarli

La maggior parte dei sistemi di incident reporting non fallisce per ragioni tecniche: fallisce per ragioni organizzative e culturali, quasi sempre le stesse.

  • Paura di ritorsioni. È l'ostacolo numero uno. Si supera con un impegno esplicito e scritto della direzione sulla non punibilità della segnalazione in buona fede, richiamando la tutela dell'art. 16 della Legge 24/2017, e con la coerenza dei comportamenti: basta un caso di segnalazione usata in chiave disciplinare per azzerare anni di lavoro.
  • Moduli complessi. Schede lunghe, gergo da qualità, campi obbligatori ridondanti, moduli cartacei da consegnare fisicamente: ogni attrito riduce le segnalazioni, e le riduce di più proprio nei reparti sotto pressione, dove il rischio è maggiore.
  • Mancanza di feedback. Se segnalare equivale a scrivere in un buco nero, gli operatori smettono. Serve un riscontro sistematico, anche solo di presa in carico, e la comunicazione periodica dei miglioramenti ottenuti grazie alle segnalazioni.
  • Ambiguità sull'oggetto. Se gli operatori non sanno cosa segnalare, segnalano solo gli eventi gravi — che sono i più rari. Formazione breve e ricorrente su definizioni ed esempi concreti, con particolare enfasi sul valore dei near miss.
  • Dati che non diventano decisioni. Se le segnalazioni si accumulano senza analisi aggregata né azioni visibili, il sistema perde credibilità anche agli occhi della direzione. Il rimedio è il ciclo chiuso descritto sopra, con responsabilità e scadenze esplicite.

Incident reporting clinico e incident reporting cyber: la dualità NIS2

Per le strutture sanitarie che rientrano nel perimetro della NIS2 (D.Lgs. 138/2024), la parola "incident reporting" ha ormai un secondo significato: la gestione e la notifica degli incidenti informatici significativi. La logica di fondo è la stessa del rischio clinico — rilevare, classificare, analizzare, correggere, imparare — ma il flusso esterno è diverso: l'art. 25 impone la notifica ad ACN con pre-allarme entro 24 ore, notifica entro 72 ore e relazione finale entro un mese dalla conoscenza dell'incidente. Ne abbiamo descritto il funzionamento operativo nell'articolo sulla procedura di notifica 24h / 72h / 1 mese verso ACN.

Per una direzione sanitaria la lezione è duplice. Primo: le competenze maturate sull'incident reporting clinico — cultura della segnalazione, classificazione, analisi delle cause — sono un patrimonio riutilizzabile sul fronte cyber. Secondo: i due flussi vanno tenuti distinti ma coordinati, perché un incidente informatico in sanità — si pensi a un blocco dei sistemi di prescrizione — è spesso anche un rischio clinico. Le organizzazioni più mature fanno dialogare risk manager e responsabili della sicurezza informatica dentro un modello di governo del rischio integrato.

Digitalizzare il flusso: il ruolo del software di incident reporting

Tutto ciò che abbiamo descritto si può fare su carta e fogli di calcolo — ma con costi di gestione alti, dati frammentati e nessuna tracciabilità end-to-end, proprio mentre la normativa chiede di dimostrare il funzionamento del sistema. Una piattaforma come Easy Risk digitalizza l'intero ciclo: segnalazione semplificata di near miss, eventi avversi ed eventi sentinella, accessibile a tutti gli operatori; workflow di analisi con presa in carico, classificazione, azioni correttive e chiusura interamente tracciati; reportistica aggregata che alimenta il PARM e la relazione annuale senza rielaborazioni manuali. Il risultato è un sistema di reporting che produce evidenze organizzate, pronte per direzione, organi di vigilanza e assicurazioni.

Se stai valutando come informatizzare la gestione del rischio clinico nella tua struttura, abbiamo pubblicato anche una guida alla scelta del software di risk management sanitario, con i criteri da considerare prima dell'acquisto.

Vuoi un sistema di incident reporting che funziona davvero?

Il team Easy Health affianca direzioni sanitarie, risk manager e uffici qualità nella progettazione del flusso di segnalazione e nella sua digitalizzazione con la piattaforma Easy Risk.

Scopri la piattaforma Easy Risk oppure contattaci per una call dedicata.

Ti interessa approfondire?

Contattaci per scoprire come le nostre soluzioni possono supportare la tua organizzazione sanitaria.

Parla con un esperto

Parla con noi

Siamo pronti ad ascoltare le esigenze di ogni struttura sanitaria. Compilare il modulo per richiedere una demo o una consulenza specialistica.

Incident Reporting in Sanità: cos'è e come costruire un sistema di segnalazione che funziona | Easy Health