Sote-uudistuksen tekninen velka

Uudet hyvinvointialueet perivät monet edeltäjäkuntiensa veloista. On kuitenkin pirullinen velan muoto, joka tulee määrittämään suuren osan hyvinvointialueiden arjesta eikä näy lainkaan taseessa.

Ohjelmoijilla on tapana puhua teknisestä velasta. Sitä otetaan, kun teknisessä toteutuksessa oikaistaan, jotta saadaan asiakkaalle tuote ulos mahdollisimman pian. Velalla saadaan siis valmis tuote, mutta velka alkaa myös kasvaa korkoa. Huonot ratkaisut puraisevat nilkkaan seuraavaa ominaisuutta rakennettaessa ja viimeistään harmi tulee, kun esimies tajuaa, että teknistä velkaa otettaessa tiimille on välittynyt selvästi, ettei laadulla ole niin väliä.

Tekninen velka on luonnollisesti vertauskuvallista. Kyse on teknisistä puutteista ja ennen kaikkea organisaation itselleen aieheuttamasta kyvyttömyydestä muuttua. Sote-alalla tekninen velka ei ole ainoastaan rahallista, vaan myös potilasturvallisuus- ja tehokkuuskysymys. Jos järjestelmiä olisi helppo jatkokehittää, voitaisiin potilasturvallisuutta vaarantavat virheet ja henkilökuntaa jatkuvasti ärsyttävät käytettävyyskukkaset liiskata alta aikayksikön.

Liisa Hyssälä arvioi twiitissään, että jo hänen aikanaan maassa oli 4 200 erilaista sote-alan ICT-järjestelmää. Esimerkiksi Länsi-Uudenmaan alueella järjestelmiä on yli 30. Näitä ei aiotakaan yhdistää lähiaikoina, koska pelkästään kartoitukseen ja minimitason integraatioon menee koko varattu aika. Tämä jos mikä on teknistä velkaa: yhteensopimattomat järjestelmät estävät kehittämästä toimintaa koko hyvinvointialueen laajuisesti.

Asiat voisivat olla toisin. Vuonna 1991 lakkautetun lääkintöhallituksen tehtäviin kuului potilastietojärjestelmien koordinointi ja valvominen. Keskusvirastolla oli laaja toimivalta ohjata ja määrätä sote-toiminnan toteuttamisesta kunnissa. Nykyään vastaavia tehtäviä toteuttaa pääsääntöisesti THL, jonka tehtävät rajautuvat kuitenkin kuntien ja sairaanhoitopiirien tukemiseen tehtävissään.

Jos jokaisen potilastietojärjestelmähankinnan kohdalla kysyttäisiin, olisiko mahdollista hyödyntää jonkin toisen vastaavassa tilanteessa olevan kunnan järjestelmälisenssiä, jakaa oppeja eri toimittajien hankinnoista ja ehkä jopa jakaa kansallista lisenssipoolia eri järjestelmiin, oltaisiin varmasti eri kypsyyden tasolle. (Tiedän, hankintalainsäädäntö ei mahdollista huonon toimittajan rokottamista huonojen kokemusten perusteella. Ceterum censeo, sekin pitäisi korjata.)

Tykkään puhua paljon kokeilukulttuurista, ja ensi kuulemalla keskusvirastot ja kokeilukulttuuri ovat keskenään ristiriidassa. Näin ei kuitenkaan ole: laadukkaassa kokeilukulttuurissa kokeilut ovat hyvin suunniteltuja, niille on asetettu selkeät tavoitteet, niitä arvioidaan ja niiden opit levitetään systemaattisesti kaikkialle. Tällaista toimintaa varten tarvitaan prosessin omistaja, jolla on isännän elkeet, mielellään myös valtaa. Tarvitaan halukas toteuttaja ja vastuullinen kokeilun tilaaja.

Kun isäntää ei ole, kissat hyppivät pöydällä ja teknistä velkaa kertyy. Onneksi hyvinvointialueita on vähemmän kuin kuntia, joten jatkossa toivottavasti koordinointi ja yhdessä oppiminen on helpompaa.

Teknisen velan ratkaisuksi ehdotetaan usein ns. greenfield-projektia, jossa lähdetään rakentamaan uutta ratkaisua tyhjältä pöydältä. Tätä vastaan on helppo argumentoida sillä, että meillä on jo toimiva järjestelmä ja uusi projekti tekisi vain kaikki samat virheet uudestaan. On myös todennäköisesti totta, että uusi järjestelmä kokisi toisen järjestelmän syndrooman, eli se paisuisi “kaikki vanhat viat korjaavaksi” Iisakin kirkoksi, joka ei valmistu koskaan.

Onneksi tähänkin on ratkaisu. Ketterässä kehityksessä järjestelmiä kehitetään jatkuvasti yhteistyössä käyttäjien kanssa niin, että käyttäjät saavat joka kehityskierroksella toimivan järjestelmän käytettäväkseen. Uskoisin, että esimerkiksi suomalaisen Esko-järjestelmän väki voisi olla hyvin kiinnostunutta tekemään yhteistyötä yksittäisten osajärjestelmien korvaamiseksi. Korvaaminen voidaan vaikka tehdä yhdessä yksikössä niin, että ohjelmoijat näyttävät henkilöstölle prototyyppejä vaikkapa kerran viikossa. Kun järjestelmä saadaan toimimaan yksikössä hyvin, toistetaan sama toisessa, ja ohjelmoijat voivat hiljalleen siirtyä taka-alalle kun lastentaudit on liiskattu yhdessä.

Tämä ei ole utopiaa, eikä tietenkään edellytä Eskoa. Se vaatii oikean asenteen hankkijalta, jonka pitää uskaltaa vaatia perinteisestä vesiputousprojektista luopumista. Se vaatii oikean toimittajan, joka sitoutuu tekemään parasta mahdollista yhdessä hankkijan kanssa. Se vaatii henkilöstöä, joka on valmis heittäytymään prosessiin.

Vastuullisella ja laadukkaalla ohjelmistohankinnalla voidaan alkaa siivota vanhaa teknistä velkaa, mutta aivan ensiksi sen olemassaolo täytyy tunnustaa. Kun kuvaamani järjestelmistä aiheutuvat prosessiongelmat myönnetään ja arvioidaan objektiivisesti, on jo paljon luontevampaa keskustella teknisen velan vähentämisestä. Kun tämä keskustelu on käyty, voidaan ottaa modernin ohjelmistokehityksen keinot käyttöön ja tehdä sotesta paljon parempaa kaikille: henkilöstölle, asiakkaille ja veronmaksajille.