A kórházi számlázási hiba, amelyet három héten át senki sem vett észre

Bevezető

Egy középnyugati regionális kórházi rendszer tavaly tavasszal a szokásos változáskezelési folyamat keretében futtatta le egy ütemezési javítást. Semmi drámai – csupán egy rutinfrissítés, amely a kórházból való elbocsátás időpontjának és a számlázási modul összehangolását érintette. Három héttel később a számlázási osztály egyik munkatársa észrevette, hogy számos igénylés került visszaelutasításra az időbélyegek eltérése miatt. Mire az IT-osztály lenyomozta a problémát, a javítás már több mint négyszáz beteg biztosítási igénylését érintette. Pontosan véve senki sem tett semmi rosszat. A frissítés minden tesztet teljesített a ellenőrzőlistán. Csakhogy nem a megfelelő ellenőrzőlistát használták.

Ez a történet azért ragadt meg bennem, mert valójában nem a kórházakról szól. Arról szól, mi történik, amikor a szervezet háttérében csendben működő rendszereket készterméknek tekintik, ahelyett, hogy rendszeres ellenőrzést igénylő, élő infrastruktúraként kezelnék őket.

A két évvel ezelőtt beállított automatizálás nem az az automatizálás, aminek gondolod

A legtöbb vállalat azért hozza létre az első munkafolyamat-automatizálásait, hogy megoldjon egy konkrét, nyilvánvaló problémát. A HR-csapat belefárad a szabadságkérelmek kézi továbbításába. Egy értékesítési munkatárs automatizálja a potenciális ügyfelek kiosztását, hogy a képviselők ne válogathassanak a legjobb ügyfelek közül. Ezeket a Power Automate-hez hasonló automatizálási eszközökkel építik fel – gyorsan konfigurálhatók, könnyen átadhatók annak, aki hajlandó átvenni a felelősséget, és működésük során nagyrészt láthatatlanok maradnak.

A probléma az, hogy a „miután működnek” állapot állandósul. Senki sem tervez be felülvizsgálatot. Az a személy, aki létrehozta, átkerül egy másik csapatba, vagy elhagyja a vállalatot. Eközben az üzleti környezet az automatizálás körül megváltozik – új CRM-mezők, eltérő jóváhagyási hierarchia, egy fúzió, amely megduplázza a forgalmat egy olyan rendszeren, amelyet a terhelés felére terveztek. Az automatizálás pontosan úgy működik tovább, ahogyan megtervezték, és pont ez a probléma. Olyan vállalatra tervezték, amely már nem létezik pontosan abban a formában.

Láttam már olyan logisztikai céget, amely rájött, hogy egy automatizált kivétel-átirányítási folyamat tizenegy hónapja észrevétlenül hibásan működött, mert egy beszállító megváltoztatta egy API-mező nevét. A megoldás? Valaki kézzel újra beírta a sikertelen eseteket anélkül, hogy bárkinek is szólt volna, feltételezve, hogy ez egyszeri eset volt. Ez nem az eszköz hibája. Ez a szervezet kudarca, amiért nem vizsgálták felül azt, amit mindenki stabilnak hitt.

A kórházak ugyanazzal a kockázattal szembesülnek, de sokkal nagyobb a tét

Vegyük ugyanezt a mintát, és helyezzük át egy kórház klinikai és adminisztratív rendszerébe, és a hibalehetőségek határa drasztikusan csökken. A kórházi szoftverfejlesztés általában a megfelelőséget és az üzemidőt részesíti előnyben az alkalmazkodóképességgel szemben – ami érthető, tekintve, hogy egy sikertelen telepítés azt jelentheti, hogy egy ápoló hajnali 2-kor nem tudja előhívni a gyógyszeres kezelés előzményeit. Ugyanez az óvatosság azonban azt is jelenti, hogy a régi rendszerek gyakran sokkal tovább maradnak üzemben, mint kellene, és inkább foltozzák őket, mintsem újjáépítsék, mert senki sem akarja, hogy ő legyen az, aki tönkreteszi a rendszer egyik teherhordó elemét.

Az eredmény egy olyan architektúra, amely olyan döntéseket halmoz fel, amelyek meghozatalára senki sem emlékszik. Egy ütemezési modul egy 2016-ban kialakított integráción keresztül kommunikál a számlázási rendszerrel egy olyan beszállító számára, akinek szolgáltatásait a kórház 2019-ben már nem vette igénybe. Még mindig működik, többnyire. A „többnyire” nem olyan szó, amelyet a betegadatok közelében szeretnénk látni.

Ami lassan változik, az az a felismerés, hogy az egészségügyi informatika rugalmassága nem a változás elkerüléséről szól – hanem olyan rendszerek kiépítéséről, amelyek elég rugalmasak ahhoz, hogy felszívják a változásokat anélkül, hogy minden szabályozási változáskor vagy új EHR-modul beépítésekor kis csodára lenne szükség.

Miért helytelen a „ha nem romlott el” elv?

A következő a helyzet mindkét forgatókönyv esetében: a rendszerek nem voltak tönkrementek. Pontosan úgy működtek, ahogyan be voltak állítva. Pontosan ezért nem foglalkozott velük senki.

A meghibásodott rendszerek definíció szerint felhívják magukra a figyelmet – valaki panaszkodik, valami leáll, bejelentést tesznek. A veszélyes rendszerek azok, amelyek felszínesen jól működnek, miközben csendben eltávolodnak attól, amire a szervezetnek valójában szüksége van. Egy munkafolyamat-automatizálás, amely még mindig fut, de a rossz osztályhoz irányítja az adatokat. Egy kórházi interfész, amely még mindig továbbítja az adatokat, de kihagy egy mezőt, amelyre egy utólagos rendszer már támaszkodik.

Az ellenőrzés nem túl izgalmas, de az alternatíva sem az

A megoldás elvileg nem bonyolult, még ha a gyakorlatban unalmas is: ütemezzünk rendszeres felülvizsgálatokat minden olyan rendszerre, amely felügyelet nélkül működik, függetlenül attól, hogy korábban milyen jól teljesített. Kérdezzük meg, ki a jelenlegi felelőse. Kérdezzük meg, mi változott a rendszer előtti és utáni szakaszokban a létrehozása óta. Kérdezzük meg, észrevenné-e valaki, ha holnap csendben leállna.

A legtöbb szervezet kihagyja ezt a lépést, mert inkább karbantartásnak tűnik, mint előrelépésnek, és a karbantartás ritkán kap költségkeretet vagy elismerést. De a kihagyás költségei nem tűnnek el – csak csendben várnak arra a pillanatra, amikor valaki a számlázási osztályon észreveszi, hogy a számok nem stimmelnek.