L'errore nella fatturazione ospedaliera che nessuno ha notato per tre settimane

Introduzione

La scorsa primavera, un sistema ospedaliero regionale del Midwest ha implementato una patch di pianificazione seguendo la consueta procedura di aggiornamento. Niente di eclatante: un aggiornamento di routine relativo alla sincronizzazione degli orari di dimissione con il modulo di fatturazione. Tre settimane dopo, un addetto alla contabilità clienti ha notato un gruppo di richieste di rimborso respinte a causa di timestamp non corrispondenti. Quando il reparto IT è riuscito a individuare il problema, la correzione aveva interessato le richieste di rimborso assicurativo di oltre quattrocento pazienti. Nessuno aveva fatto nulla di sbagliato, a rigor di termini. L’aggiornamento aveva superato tutti i test previsti dalla checklist. Solo che non era la checklist giusta.

Quella storia mi è rimasta impressa perché in realtà non riguarda gli ospedali. Riguarda ciò che accade quando i sistemi che funzionano silenziosamente dietro le quinte di un’organizzazione vengono trattati come prodotti finiti invece che come un’infrastruttura viva che necessita di un controllo regolare.

L’automazione che hai configurato due anni fa non è l’automazione che credi che sia

La maggior parte delle aziende realizza le prime automazioni dei flussi di lavoro per risolvere un problema specifico e evidente. Un team delle risorse umane si stanca di inoltrare manualmente le richieste di ferie. Un addetto alle operazioni di vendita automatizza l’assegnazione dei lead in modo che i rappresentanti smettano di scegliere solo i casi più facili. Queste automazioni vengono realizzate con strumenti simili a Power Automate: veloci da configurare, facili da affidare a chiunque sia disposto a occuparsene e in gran parte invisibili una volta che funzionano.

Il problema è che «una volta che funzionano» diventano permanenti. Nessuno programma una revisione. La persona che le ha create cambia team o se ne va. Nel frattempo, l’azienda cambia intorno all’automazione: nuovi campi nel CRM, una gerarchia di approvazione diversa, una fusione che raddoppia il volume che passa attraverso un sistema progettato per metà del carico. L’automazione continua a funzionare esattamente come è stata progettata, ed è proprio questo il problema. È stata progettata per un’azienda che non esiste più in quella forma.

Ho visto un’azienda di logistica scoprire che un flusso automatizzato di instradamento delle eccezioni funzionava male in modo silenzioso da undici mesi perché un fornitore aveva modificato il nome di un campo dell’API. La soluzione provvisoria? Qualcuno aveva reinserito manualmente i casi falliti senza dirlo a nessuno, supponendo che si trattasse di un caso isolato. Questo non è un fallimento dello strumento. È un fallimento organizzativo nel riesaminare qualcosa che tutti davano per stabile.

Gli ospedali corrono lo stesso rischio, ma con una posta in gioco molto più alta

Prendete lo stesso schema e inseritelo nello stack clinico e amministrativo di un ospedale, e il margine di errore si riduce drasticamente. Lo sviluppo di software ospedaliero ha tipicamente dato priorità alla conformità e al tempo di attività rispetto all’adattabilità — cosa comprensibile, dato che un’implementazione fallita può significare che un’infermiera non riesca a recuperare la cronologia dei farmaci alle 2 del mattino. Ma quella stessa cautela fa sì che i sistemi legacy rimangano spesso in produzione molto più a lungo di quanto dovrebbero, rattoppati anziché ricostruiti, perché nessuno vuole essere colui che rompe qualcosa di fondamentale.

Il risultato è un’architettura che accumula decisioni che nessuno ricorda di aver preso. Un modulo di pianificazione comunica con quello di fatturazione tramite un’integrazione realizzata nel 2016 per un fornitore che l’ospedale ha smesso di utilizzare nel 2019. Funziona ancora, più o meno. «Più o meno» non è un’espressione che si vorrebbe vedere in relazione ai dati dei pazienti.

Ciò che sta cambiando, lentamente, è la consapevolezza che la resilienza nell’IT sanitario non consiste nell’evitare il cambiamento, ma nel costruire sistemi sufficientemente flessibili da assorbirlo senza aver bisogno di un piccolo miracolo ogni volta che cambia una normativa o viene aggiunto un nuovo modulo della cartella clinica elettronica.

Perché “se non è rotto” è il criterio sbagliato

Ecco il punto in entrambi gli scenari: i sistemi non erano guasti. Funzionavano esattamente come erano stati configurati. Ed è proprio per questo che nessuno li ha presi in considerazione.

I sistemi malfunzionanti attirano l’attenzione per definizione: qualcuno si lamenta, qualcosa si blocca, viene aperto un ticket. I sistemi pericolosi sono quelli che apparentemente funzionano bene, ma che silenziosamente si stanno allontanando da ciò di cui l’organizzazione ha effettivamente bisogno. Un’automazione del flusso di lavoro che continua a funzionare ma indirizza le richieste al reparto sbagliato. Un’interfaccia ospedaliera che continua a trasmettere dati ma omette un campo da cui ora dipende un sistema a valle.

L’audit non è affascinante, ma nemmeno l’alternativa lo è

La soluzione non è complicata in teoria, anche se è noiosa nella pratica: programmare revisioni periodiche di tutto ciò che funziona in modo autonomo, indipendentemente da quanto bene abbia funzionato in passato. Chiedere a chi ne è responsabile ora. Chiedere cosa è cambiato a monte e a valle da quando è stato realizzato. Chiedere se qualcuno se ne accorgerebbe se domani smettesse di funzionare in silenzio.

La maggior parte delle organizzazioni tralascia questo passaggio perché sembra più manutenzione che progresso, e la manutenzione raramente ottiene budget o applausi. Ma il costo di tralasciarlo non scompare: aspetta semplicemente, in silenzio, il momento in cui qualcuno della contabilità clienti si accorga che i conti non tornano.