Haigla arveldusviga, mida keegi kolme nädala jooksul ei märganud

Sissejuhatus

Eelmisel kevadel viis üks Kesk-Lääne piirkonna haiglasüsteem läbi tavapärase muudatusprotsessi raames ajakava paranduse. Midagi dramaatilist selles ei olnud – tegemist oli rutiinse uuendusega, mis puudutas väljakirjutamise aegade sünkroniseerimist arveldusmooduliga. Kolm nädalat hiljem märkas keegi võlgnevuste osakonnas, et mitmed nõuded lükati tagasi ajamärkide mittevastavuse tõttu. Kui IT-osakond probleemi üles leidis, oli parandus mõjutanud üle neljasaja patsiendi kindlustusnõudeid. Keegi ei olnud tegelikult midagi valesti teinud. Uuendus läbis kõik kontrollnimekirjas olevad testid. Lihtsalt ei olnud tegemist õige kontrollnimekirjaga.

See lugu on mulle meelde jäänud, sest tegelikult ei räägi see haiglatest. See räägib sellest, mis juhtub, kui organisatsiooni taustal vaikselt töötavaid süsteeme koheldakse valmis toodetena, mitte elava infrastruktuurina, mis vajab regulaarset kontrolli.

Automatiseerimine, mille sa kaks aastat tagasi paigaldasid, ei ole see, milleks sa seda pead

Enamik ettevõtteid loob oma esimesed töövoo automatiseerimised, et lahendada konkreetne, silmaga nähtav probleem. Personaliosakond väsib puhkuseavalduste käsitsi edastamisest. Müügiosakonna töötaja automatiseerib potentsiaalsete klientide jaotamise, et müügiesindajad ei valiks endale parimaid kliente. Need luuakse Power Automate’iga sarnaste automatiseerimistööriistadega – need on kiiresti seadistatavad, lihtne üle anda kellelegi, kes on valmis neid haldama, ja peaaegu nähtamatud, kui need kord töötavad.

Probleem on selles, et „kui need kord töötavad”, muutub see püsivaks. Keegi ei planeeri ülevaatamist. Selle loonud inimene vahetab meeskonda või lahkub. Samal ajal muutub äri automaatika ümber – uued CRM-väljad, teistsugune heakskiitmishierarhia, ühinemine, mis kahekordistab läbivoolava mahu süsteemis, mis oli loodud poole väiksema koormuse jaoks. Automaatika töötab edasi täpselt nii, nagu see oli kavandatud, ja just selles peitubki probleem. See oli kavandatud ettevõttele, mis sellisel kujul enam ei eksisteeri.

Olen näinud, kuidas üks logistikaettevõte avastas, et automatiseeritud erandite suunamise voog oli üksteist kuud märkamatult valesti töötanud, sest tarnija oli muutnud API-välja nime. Lahendus? Keegi oli ebaõnnestunud juhtumeid käsitsi uuesti sisestanud, kellelegi sellest rääkimata, eeldades, et tegemist oli ühekordse juhtumiga. See ei ole tööriista viga. See on organisatsiooniline ebaõnnestumine vaadata uuesti üle midagi, mida kõik pidasid stabiilseks.

Haiglatel on sama risk, kuid palju suuremad tagajärjed

Võtke sama muster ja paigutage see haigla kliinilisse ja halduslikku süsteemide kogumisse, ning vea varu kaob täielikult. Haiglate tarkvaraarenduses on tavaliselt eelistatud nõuetele vastavust ja töökindlust kohanemisvõimele – see on mõistetav, arvestades, et ebaõnnestunud kasutuselevõtt võib tähendada, et õde ei saa kell 2 öösel ravimite ajalugu üles otsida. Kuid sama ettevaatus tähendab, et vanad süsteemid jäävad tootmisse sageli palju kauemaks, kui nad peaksid, neid parandatakse lappimise teel, mitte ei ehitata ümber, sest keegi ei taha olla see, kes rikub midagi olulist.

Tulemuseks on arhitektuur, milles kogunevad otsused, mida keegi ei mäleta teinud olevat. Ajakava moodul suhtleb arveldusmooduliga 2016. aastal loodud integratsiooni kaudu, mis oli mõeldud tarnijale, kelle teenuseid haigla 2019. aastal enam ei kasutanud. See toimib ikka veel, enamasti. „Enamasti“ ei ole sõna, mida tahaks patsiendiandmete läheduses näha.

Aeglaselt muutub arusaam, et tervishoiu IT-s ei tähenda vastupidavus muutuste vältimist – see tähendab piisavalt paindlike süsteemide ehitamist, mis suudavad muutusi vastu võtta ilma, et iga kord, kui määrus muutub või uus EHR-moodul lisatakse, oleks vaja väikest imet.

Miks „kui see pole katki“ on vale kriteerium

Mõlema stsenaariumi puhul on asi selles, et süsteemid ei olnud katki. Need töötasid täpselt nii, nagu need olid konfigureeritud. Just seetõttu keegi neid ei vaadanudki.

Rikkis süsteemid pälvivad määratluse järgi tähelepanu – keegi kaebab, midagi seisab, esitatakse veateade. Ohtlikud on need süsteemid, mis töötavad pealtnäha hästi, kuid kalduvad vaikselt kõrvale sellest, mida organisatsioon tegelikult vajab. Töövoo automatiseerimine, mis küll endiselt töötab, kuid suunab andmed valesse osakonda. Haigla liides, mis küll edastab andmeid, kuid jätab välja välja, millest allavoolu süsteem nüüd sõltub.

Auditeerimine ei ole glamuurne, kuid seda ei ole ka alternatiiv

Lahendus ei ole kontseptsioonilt keeruline, isegi kui see on praktikas tüütu: planeerige perioodilised ülevaatused kõigile järelevalveta töötavatele süsteemidele, hoolimata sellest, kui hästi need varem on toiminud. Küsige, kes on praegu selle eest vastutav. Küsige, mis on muutunud üles- ja allavoolus alates süsteemi loomisest. Küsige, kas keegi märkaks, kui see homme vaikselt töötamise lõpetaks.

Enamik organisatsioone jätab selle vahele, sest see tundub pigem hooldustööna kui edasiminekuks, ja hooldustööle eraldatakse harva eelarvet või kiidetakse seda. Kuid selle vahele jätmise kulud ei kao kuhugi – need ootavad lihtsalt vaikselt hetke, mil keegi arvelduste osakonnas märkab, et numbrid ei klapi.