Eroarea de facturare a spitalului pe care nimeni nu a observat-o timp de trei săptămâni

Introducere

Un sistem spitalicesc regional din Midwest a implementat o actualizare de programare prin procesul său obișnuit de schimbare în primăvara trecută. Nimic dramatic — o actualizare de rutină a modului în care orele de externare se sincronizau cu modulul de facturare. Trei săptămâni mai târziu, cineva de la departamentul de creanțe a observat o serie de cereri de rambursare respinse din cauza unor timestamp-uri neconcordante. Până când departamentul IT a identificat problema, actualizarea afectase cererile de rambursare pentru peste patru sute de pacienți. Nimeni nu greșise cu nimic, strict vorbind. Actualizarea a trecut toate testele de pe lista de verificare. Doar că nu era lista de verificare potrivită.

Povestea aceasta mi-a rămas în minte pentru că, de fapt, nu este despre spitale. Este despre ce se întâmplă când sistemele care funcționează în tăcere în fundalul unei organizații sunt tratate ca produse finite, în loc să fie considerate o infrastructură vie care necesită o verificare regulată.

Automatizarea pe care ați configurat-o acum doi ani nu este automatizarea pe care o credeți

Majoritatea companiilor își construiesc primele automatizări ale fluxurilor de lucru pentru a rezolva o problemă specifică și vizibilă. O echipă de resurse umane se satură să proceseze manual cererile de concediu. Un angajat din departamentul de operațiuni de vânzări automatizează alocarea clienților potențiali, astfel încât reprezentanții de vânzări să nu mai aleagă doar clienții cei mai profitabili. Acestea sunt construite cu instrumente de automatizare similare cu Power Automate — rapide de configurat, ușor de predat oricui este dispus să le preia și, în mare parte, invizibile odată ce funcționează.

Problema este că „odată ce funcționează” devine o stare permanentă. Nimeni nu programează o revizuire. Persoana care a creat-o se mută în altă echipă sau pleacă. Între timp, afacerea se schimbă în jurul automatizării — câmpuri CRM noi, o ierarhie de aprobare diferită, o fuziune care dublează volumul care trece printr-un sistem construit pentru jumătate din încărcătură. Automatizarea continuă să funcționeze exact așa cum a fost proiectată, ceea ce reprezintă tocmai problema. A fost proiectată pentru o companie care nu mai există în acea formă.

Am văzut o firmă de logistică descoperind că un flux automatizat de redirecționare a excepțiilor funcționa greșit în tăcere de unsprezece luni, deoarece un furnizor a schimbat numele unui câmp API. Soluția de compromis? Cineva reintroducea manual cazurile eșuate fără să spună nimănui, presupunând că era o situație izolată. Aceasta nu este o defecțiune a instrumentului. Este o eșec organizațional de a reevalua ceva ce toată lumea presupunea că era stabil.

Spitalele se confruntă cu același risc, dar miza este mult mai mare

Luați același model și aplicați-l în cadrul sistemelor clinice și administrative ale unui spital, iar marja de eroare se reduce drastic. Dezvoltarea de software pentru spitale a acordat, de obicei, prioritate conformității și disponibilității în detrimentul adaptabilității — ceea ce este de înțeles, având în vedere că o implementare eșuată poate însemna că o asistentă medicală nu poate accesa istoricul medicației la ora 2 dimineața. Dar aceeași prudență înseamnă că sistemele vechi rămân adesea în producție mult mai mult decât ar trebui, fiind doar „peticite” în loc să fie reconstruite, deoarece nimeni nu vrea să fie cel care strică ceva esențial.

Rezultatul este o arhitectură care acumulează decizii pe care nimeni nu-și amintește să le fi luat. Un modul de programare comunică cu sistemul de facturare printr-o integrare realizată în 2016 pentru un furnizor pe care spitalul a încetat să-l mai folosească în 2019. Încă funcționează, în mare parte. „În mare parte” nu este un cuvânt pe care ți-l dorești în legătură cu datele pacienților.

Ceea ce se schimbă, încet, este recunoașterea faptului că reziliența în domeniul IT din sănătate nu înseamnă evitarea schimbării — ci construirea unor sisteme suficient de flexibile pentru a absorbi schimbarea fără a avea nevoie de un mic miracol de fiecare dată când se modifică o reglementare sau se adaugă un nou modul EHR.

De ce „dacă nu e stricat” nu este un criteriu corect

Iată care este problema în ambele scenarii: sistemele nu erau defecte. Funcționau exact așa cum fuseseră configurate. Tocmai de aceea nimeni nu le-a acordat atenție.

Sistemele defecte atrag atenția prin definiție — cineva se plânge, ceva se oprește, se înregistrează un tichet. Sistemele periculoase sunt cele care funcționează bine la suprafață, în timp ce se îndepărtează în tăcere de ceea ce are nevoie de fapt organizația. O automatizare a fluxului de lucru care încă se execută, dar redirecționează către departamentul greșit. O interfață a spitalului care încă transmite date, dar elimină un câmp de care depinde acum un sistem din aval.

Auditul nu este strălucitor, dar nici alternativa nu este

Soluția nu este complicată ca concept, chiar dacă este plictisitoare în practică: programați revizuiri periodice ale oricărui sistem care funcționează nesupravegheat, indiferent de cât de bine a funcționat în trecut. Întrebați cine este responsabil de el acum. Întrebați ce s-a schimbat în amonte și în aval de la momentul creării sale. Întrebați dacă cineva ar observa dacă mâine ar înceta să funcționeze în tăcere.

Majoritatea organizațiilor omit acest pas deoarece pare mai degrabă o activitate de întreținere decât un progres, iar întreținerea beneficiază rareori de buget sau de aprecieri. Însă costul omiterii acestui pas nu dispare — ci așteaptă, în tăcere, momentul în care cineva de la contabilitatea creanțelor va observa că cifrele nu se potrivesc.