Ligoninės sąskaitų išrašymo klaida, kurios niekas nepastebėjo tris savaites

Įvadas

Praėjusį pavasarį vienoje Vidurio Vakarų regiono ligoninių sistemoje buvo įdiegtas tvarkaraščių koregavimo pataisymas, laikantis įprastos pakeitimų tvarkos. Nieko ypatingo – tai buvo įprastas atnaujinimas, skirtas suderinti išrašymo iš ligoninės laiką su sąskaitų išrašymo moduliu. Po trijų savaičių vienas iš debitorinių skolų skyriaus darbuotojų pastebėjo, kad susikaupė daugybė pretenzijų dėl nesutampančių laiko žymų. Kol IT skyrius išsiaiškino, kas nutiko, pataisymas jau buvo paveikęs daugiau nei keturių šimtų pacientų draudimo paraiškas. Niekas, tiesą sakant, nepadarė nieko blogo. Atnaujinimas išlaikė visus kontrolinio sąrašo testus. Tiesiog tai buvo ne tas kontrolinis sąrašas.

Ši istorija man įstrigo, nes iš tikrųjų ji ne apie ligonines. Ji apie tai, kas atsitinka, kai sistemos, tyliai veikiančios organizacijos fone, traktuojamos kaip gatavi produktai, o ne kaip gyva infrastruktūra, kurią reikia reguliariai tikrinti.

Automatizavimas, kurį įdiegėte prieš dvejus metus, nėra toks, kokiu jį įsivaizduojate

Dauguma įmonių kuria pirmuosius darbo srautų automatizavimo sprendimus, siekdamos išspręsti konkrečią, akivaizdžią problemą. Personalo skyrius pavargsta rankiniu būdu nukreipinėti atostogų prašymus. Pardavimų operacijų specialistas automatizuoja potencialių klientų priskyrimą, kad pardavėjai nustotų rinktis tik pačius geriausius. Tai daroma naudojant automatizavimo įrankius, panašius į „Power Automate“ – juos greitai sukonfigūruoti, lengva perduoti bet kam, kas nori juos prižiūrėti, o kai jie pradeda veikti, jie tampa beveik nematomi.

Problema ta, kad „kai jos pradeda veikti“, tai tampa nuolatinis reiškinys. Niekas nenumato peržiūros. Asmuo, kuris jas sukūrė, pereina į kitą komandą arba išeina iš darbo. Tuo tarpu verslas aplink automatizavimą keičiasi – atsiranda nauji CRM laukai, pasikeičia patvirtinimo hierarchija, įvyksta susijungimas, dėl kurio dvigubai padidėja srautas sistemoje, sukurtoje tik pusei to krūvio. Automatizavimas toliau veikia tiksliai taip, kaip buvo suprojektuotas, ir būtent tai yra problema. Jis buvo suprojektuotas įmonei, kuri tokia, kokia buvo anksčiau, jau nebeegzistuoja.

Mačiau, kaip logistikos įmonė atrado, kad automatizuotas išimčių nukreipimo srautas vienuolika mėnesių tyliai veikė netinkamai, nes tiekėjas pakeitė API lauko pavadinimą. Kaip buvo išspręsta problema? Kažkas rankiniu būdu iš naujo įvedė nesėkmingus atvejus niekam nepranešęs, manydamas, kad tai buvo vienkartinis atvejis. Tai ne įrankio gedimas. Tai organizacinė nesėkmė, nes nebuvo peržiūrėta tai, ką visi laikė stabiliu.

Ligoninėms kyla ta pati rizika, tačiau pasekmės yra daug rimtesnės

Paimkite tą patį modelį ir pritaikykite jį ligoninės klinikiniam ir administraciniam sistemų kompleksui – ir klaidų tolerancija smarkiai sumažės. Ligoninių programinės įrangos kūrime paprastai pirmenybė teikiama atitikčiai reikalavimams ir nepertraukiamam veikimui, o ne prisitaikymui – tai suprantama, turint omenyje, kad nesėkmingas diegimas gali reikšti, jog slaugytoja 2 val. nakties negalės peržiūrėti vaistų vartojimo istorijos. Tačiau tas pats atsargumas reiškia, kad senosios sistemos dažnai lieka eksploatuojamos kur kas ilgiau, nei turėtų, ir yra tik taisomos, o ne pertvarkomos iš naujo, nes niekas nenori būti tuo, kuris sugadins kažką, kas yra esminis sistemos elementas.

Rezultatas – architektūra, kurioje kaupiasi sprendimai, kurių niekas neprisimena priėmęs. Tvarkaraščių sudarymo modulis bendrauja su apskaitos sistema per 2016 m. sukurtą integraciją, skirtą tiekėjui, kurio paslaugomis ligoninė nustojo naudotis 2019 m. Ji vis dar veikia, daugiausia. „Daugiausia“ nėra žodis, kurį norėtumėte matyti šalia pacientų duomenų.

Kas pamažu keičiasi, tai supratimas, kad atsparumas sveikatos priežiūros IT srityje nereiškia vengimo pokyčių – tai reiškia pakankamai lanksčių sistemų kūrimą, kurios galėtų prisitaikyti prie pokyčių be to, kad kiekvieną kartą, kai pasikeičia reglamentai ar pridedamas naujas EHR modulis, reikėtų mažo stebuklo.

Kodėl „jei neveikia“ yra netinkamas kriterijus

Štai kas būdinga abiem scenarijams: sistemos nebuvo sugedusios. Jos veikė tiksliai taip, kaip buvo sukonfigūruotos. Būtent todėl niekas į jas nekreipė dėmesio.

Sugedusios sistemos, pagal apibrėžimą, sulaukia dėmesio – kažkas skundžiasi, kažkas sustoja, pateikiamas prašymas. Pavojingos yra tos sistemos, kurios išoriškai veikia puikiai, tačiau tyliai nutolsta nuo to, ko organizacijai iš tikrųjų reikia. Darbo eigos automatizavimas, kuris vis dar veikia, bet nukreipia užklausą ne į tą skyrių. Ligoninės sąsaja, kuri vis dar perduoda duomenis, bet pašalina lauką, nuo kurio dabar priklauso tolesnė sistema.

Auditas nėra patrauklus, bet alternatyva taip pat nėra

Išspręsti šią problemą koncepciškai nėra sudėtinga, net jei praktikoje tai varginantis darbas: planuokite periodiškus visų be priežiūros veikiančių sistemų patikrinimus, nepriklausomai nuo to, kaip gerai jos veikė anksčiau. Paklauskite, kas dabar už jas atsakingas. Paklauskite, kas pasikeitė tiek prieš, tiek po sistemos sukūrimo. Paklauskite, ar kas nors pastebėtų, jei rytoj ji tyliai nustotų veikti.

Dauguma organizacijų tai praleidžia, nes tai atrodo labiau kaip priežiūra, o ne pažanga, o priežiūrai retai skiriamas biudžetas ar skiriami plojimai. Tačiau praleidimo kaina neišnyksta – ji tiesiog tyliai laukia, kol kas nors iš debitorinių skolų skyriaus pastebės, kad skaičiai nesutampa.