Sairaalan laskutusvirhe, jota kukaan ei huomannut kolmeen viikkoon

Johdanto

Eräs keskilännen alueellinen sairaalajärjestelmä otti viime keväänä käyttöön aikataulutuskorjauksen tavanomaisen muutosprosessin kautta. Mitään dramaattista siinä ei ollut – kyseessä oli rutiinipäivitys, joka koski potilaiden kotiutusaikojen synkronointia laskutusmoduulin kanssa. Kolme viikkoa myöhemmin joku myyntisaamisten osastolta huomasi joukon hylättyjä korvaushakemuksia, joiden aikaleimat eivät täsmänneet. Kun IT-osasto oli jäljittänyt vian, korjaus oli vaikuttanut yli neljän sadan potilaan vakuutuskorvaushakemuksiin. Kukaan ei ollut varsinaisesti tehnyt mitään väärää. Päivitys läpäisi kaikki tarkistuslistan testit. Se ei vain ollut oikea tarkistuslista.

Tämä tarina on jäänyt mieleeni, koska se ei oikeastaan koske sairaaloita. Se kertoo siitä, mitä tapahtuu, kun organisaation taustalla hiljaa toimivia järjestelmiä kohdellaan valmiina tuotteina sen sijaan, että niitä pidettäisiin elävänä infrastruktuurina, jota on tarkasteltava säännöllisesti.

Kaksi vuotta sitten käyttöön ottamasi automaatio ei ole se automaatio, jonka luulet sen olevan

Useimmat yritykset rakentavat ensimmäiset työnkulun automaatiot ratkaistakseen tietyn, näkyvän ongelman. Henkilöstötiimi kyllästyy käsittelemään lomapyyntöjä manuaalisesti. Myyntitoiminnan työntekijä automatisoi liidien jakamisen, jotta myyjät lakkaavat valikoimasta parhaita tapauksia. Nämä rakennetaan Power Automate -tyyppisillä automaatiotyökaluilla – ne on nopea konfiguroida, helppo siirtää kenelle tahansa, joka on valmis ottamaan vastuun, ja ne ovat suurelta osin näkymättömiä, kun ne toimivat.

Ongelmana on, että ”kun ne toimivat” muuttuu pysyväksi tilaksi. Kukaan ei ajoita tarkistusta. Automaation rakentaja vaihtaa tiimiä tai lähtee yrityksestä. Samaan aikaan liiketoiminta muuttuu automaation ympärillä – uusia CRM-kenttiä, erilainen hyväksymishierarkia, fuusio, joka kaksinkertaistaa järjestelmän läpi kulkevan volyymin, vaikka järjestelmä on rakennettu puoleen kuormitukseen. Automaatio jatkaa toimintaansa täsmälleen suunnitellusti, mikä on juuri ongelma. Se suunniteltiin yritykselle, jota ei enää ole olemassa aivan siinä muodossa.

Olen nähnyt, kuinka eräs logistiikkayritys huomasi, että automatisoitu poikkeustapausten reititysprosessi oli toiminut virheellisesti huomaamatta jo yksitoista kuukautta, koska toimittaja oli muuttanut API-kentän nimeä. Ratkaisu? Joku oli syöttänyt epäonnistuneet tapaukset manuaalisesti uudelleen kertomatta siitä kenellekään, olettaen, että kyseessä oli kertaluonteinen tapaus. Se ei ole työkalun vika. Se on organisaation epäonnistuminen tarkistaa uudelleen asia, jonka kaikki olettivat olevan vakaa.

Sairaaloissa on sama riski, mutta panokset ovat paljon korkeammat

Kun sama malli siirretään sairaalan kliiniseen ja hallinnolliseen järjestelmäympäristöön, virhemarginaali romahtaa. Sairaaloiden ohjelmistokehityksessä on tyypillisesti asetettu sääntöjen noudattaminen ja käytettävyys etusijalle mukautuvuuden kustannuksella – mikä on ymmärrettävää, kun otetaan huomioon, että epäonnistunut käyttöönotto voi tarkoittaa sitä, ettei hoitaja pysty hakemaan esiin lääkityshistoriaa kello kahdelta yöllä. Mutta sama varovaisuus tarkoittaa, että vanhat järjestelmät pysyvät tuotantokäytössä usein paljon pidempään kuin niiden pitäisi, ja niihin tehdään vain paikkauksia sen sijaan, että ne rakennettaisiin uudelleen, koska kukaan ei halua olla se, joka rikkoo jotain kantavaa osaa.

Tuloksena on arkkitehtuuri, johon kertyy päätöksiä, joita kukaan ei muista tehneensä. Aikataulutusmoduuli kommunikoi laskutusjärjestelmän kanssa integroinnin kautta, joka rakennettiin vuonna 2016 toimittajalle, jonka palveluja sairaala lopetti vuonna 2019. Se toimii edelleen, suurimmaksi osaksi. ”Suurimmaksi osaksi” ei ole sana, jota haluat käyttää potilastietojen yhteydessä.

Hitaasti on kuitenkin alettu ymmärtää, että terveydenhuollon IT:n joustavuus ei tarkoita muutoksen välttämistä – kyse on riittävän joustavien järjestelmien rakentamisesta, jotka pystyvät sopeutumaan muutoksiin ilman, että tarvitaan pientä ihmettä joka kerta, kun sääntely muuttuu tai uusi potilastietojärjestelmän moduuli liitetään järjestelmään.

Miksi ”jos se ei ole rikki” on väärä kriteeri

Molemmissa tilanteissa on yksi yhteinen piirre: järjestelmät eivät olleet rikki. Ne toimivat täsmälleen niin kuin ne oli konfiguroitu. Juuri siksi kukaan ei kiinnittänyt niihin huomiota.

Rikkoutuneet järjestelmät saavat määritelmänsä mukaan huomiota – joku valittaa, jokin pysähtyy, vikailmoitus tehdään. Vaarallisia ovat ne järjestelmät, jotka toimivat pinnallisesti hyvin, mutta ajautuvat hiljaa pois synkronista organisaation todellisten tarpeiden kanssa. Työnkulun automatisointi, joka toimii edelleen, mutta ohjaa tehtävät väärälle osastolle. Sairaalan rajapinta, joka välittää edelleen tietoja, mutta poistaa kentän, josta jatkokäsittelyjärjestelmä on nyt riippuvainen.

Tarkastaminen ei ole hohdokasta, mutta ei ole vaihtoehtokaan

Ratkaisu ei ole käsitteellisesti monimutkainen, vaikka se käytännössä onkin työläs: aikatauluta säännölliset tarkastukset kaikelle, mikä toimii ilman valvontaa, riippumatta siitä, kuinka hyvin se on aiemmin toiminut. Kysy, kuka siitä nyt vastaa. Kysy, mitä on muuttunut järjestelmän alkupäässä ja loppupäässä sen rakentamisen jälkeen. Kysy, huomaisiko kukaan, jos se huomaamatta lakkaisi toimimasta huomenna.

Useimmat organisaatiot jättävät tämän väliin, koska se tuntuu enemmän ylläpidolta kuin edistymiseltä, ja ylläpito saa harvoin budjettia tai kiitosta. Mutta sen väliin jättämisen kustannukset eivät katoa – ne vain odottavat hiljaa sitä hetkeä, kun joku myyntisaatavien kirjanpidossa huomaa, että luvut eivät täsmää.