Luotettavuus ja toimivuus keskiössä HUS:in laskutusjärjestelmän uudistuksessa

Asiakasmaksulaki ja -asetus ovat tulleet parin viime vuoden aikana tutuiksi Tommi Liljalle ja koko tiimille. Toimialan keskeiset käsitteet, säännöt ja niiden soveltaminen, HUSin omat käytännöt – kaikki täytyy ymmärtää perinpohjaisesti, kun haluaa saada aikaan laadukkaan ja luotettavan asiakaslaskutusjärjestelmän. 

”HUS-projekti on vaatinut kykyä omaksua monimutkaisia juttuja, ja sen jälkeen taitoa toteuttaa ne”, Lilja tiivistää. 

HUSin asiakaslaskutusjärjestelmän uudistaminen on iso hanke jo yksistään siksi, että HUS on Suomen suurin sairaanhoitopiiri. Siellä saa vuosittain hoitoa noin 680 000 potilasta, joten asiakaslaskutuksen on todella syytä toimia vikkelästi, täsmällisesti ja loogisesti.

Kuva: Projektin Scrum Master Tommi Lilja

HUSin asiakaslaskutus – valtava määrä dataa

twoday toteutti HUSille ison järjestelmän osakokonaisuuden, joka sijoittuu eri lähde- ja kohdejärjestelmien väliin.

Tiedot välitetään twodayn rakentamalle ”tontille” potilastietojärjestelmästä FHIR-sanomina. Järjestelmä käsittelee ne sääntöjen ja käytäntöjen mukaisesti niin, että jokaiselle potilastapahtumalle löytyy oikea hinta. Sen jälkeen tiedot välitetään standardisanomina eteenpäin: ne päätyvät HUSin kirjanpitoon ja laskuina asiakkaille. 

Kun kyse on sote-alasta, oikean hinnan löytäminen ei aina ole kovin yksinkertaista. Järjestelmän pitää ottaa huomioon esimerkiksi maksukatot, pitkäaikaishoitopäätökset, erilaiset vuosikertymät, lukuisat muut lakisääteiset ja HUS-spesifit käytännöt sekä potilaiden muuttuvat tilanteet. 

HUS-asiakaslaskutusjärjestelmä toteutettiin mikropalveluarkkitehtuurilla käyttäen Azure-pilviympäristöä. Sen ytimessä on Java-teknologia ja siinä hyödynnetään ODM-sääntömoottoria, jonka avulla HUS pystyy itse hallinnoimaan sääntöjä ja pitämään osaltaan laskutusjärjestelmää yllä.

Kehityksessä on siis käytetty moderneja ohjelmistokehitysteknologioita, joita on täydennetty tehokkuutta ja hallintaa lisäävillä automaatioratkaisuilla, kuten sääntömoottorilla, joka helpottaa muutosten tekemistä järjestelmään säännöstöjen muuttuessa. Esimerkiksi kun asiakasmaksulain uudistus muutti heinäkuussa 2021 muun muassa alaikäisten lasten käynnit maksuttomiksi, sääntömoottorin (ODM) avulla hinnoittelu pystyttiin sovittamaan muutosten mukaiseksi – ketterästi ja ilman koodaustaitoja tai erillistä IT-projektia.

HUSin asiakaslaskutusjärjestelmässä liikkuu valtava määrä dataa, joten järjestelmän luotettavuus ja toimivuus on ehdottoman tärkeää. Niinpä twoday on panostanut automaatiotestaukseen mittavasti ja projektin alusta asti.

HUSin laskutusjärjestelmän varsinainen käyttöönotto tehtiin vuodenvaihteessa. Prosessien kuvauksia tehtiin jo alkuvaiheessa, ja määrittelijöiden ja toteutustiimin jatkuvaa vuoropuhelun on jatkettu läpi koko projektin. 

”Tarkoituksena on luovuttaa ylläpitoon paketti, jossa kuvaukset ja toteutus ovat synkassa. Näin ylläpitäjäkin on heti kartalla järjestelmän suhteen”, Lilja sanoo.

Ketterää ja kurinalaista ohjelmistokehitystä

Ketterää kehitystä ei pidä runnoa joka projektiin, mutta sote-järjestelmien kehittämiseen se soveltuu yleensä mainiosti. Scrum-menetelmälle on ominaista kokeilevuus. Otetaan askel, ja jos jää vaikuttaa ritisevän jalan alla, palataan takaisin ja yritetään toista kautta – sen sijaan, että pyrittäisiin väkisin etenemään ennalta määrättyä reittiä, koska suunnitelmat kerran niin sanovat. 

”Ketterä tekeminen on kurinalaista toimintaa. Tehdään tiettyjä asioita säännöllisessä rytmissä, mikä heijastuu siihen että projektin osat pysyvät paremmin synkronissa ja ajan tasalla”, Lilja sanoo.

Monitoimittajaympäristö vaatii tiivistä yhteistyötä

On kuvaavaa, että Lilja haluaa aloittaa twodayn tiimin esittelyn asiakkaan puolelta projektiin tulleesta tuoteomistajasta – tuoteomistaja nimittäin on monessa mielessä projektin onnistumisen avainhenkilö. HUSin Susanna Hanelius-Leppälä saa Liljan varauksettomat kiitokset: taitava selittämään, miten monimutkaisten asioiden kuuluu toimia, pystyy näkemään laajan kokonaisuuden ja sukeltamaan pieniin yksityiskohtiin. Apuna ovat olleet twodayn tiimin määrittelijät.

”Kuvasimme määrittelijöiden kanssa HUSin työnkulkuja. Kuvaukset ja määrittelyt auttavat ymmärtämään, mitä järjestelmän tuleva käyttäjä, HUSin työntekijä siis, haluaa tehdä”, Lilja sanoo.

HUS-projektin asiakaslaskutustiimi on ollut 15–20 hengen vahvuinen, ja naapurissa, HUSin organisaatiolaskutuksen parissa, on tehnyt omaa työtään vastaavan kokoinen tiimi Vincitiltä. Lisäksi HUS-projektin parissa ahkeroi integroivia ja testaavia tiimejä – todellinen monitoimittajaympäristö siis, ja sen mukaiset ovat olleet myös vaatimukset eri tiimien yhteistyön sujuvuudesta. ”Yhteisponnistus”, tiivistää Lilja.

Lilja itse on toiminut HUS-projektin alusta lähtien Scrum Masterina eli ketterän kehitystiimin valmentajana. Hän kertoo viihtyvänsä monitoimittajaympäristössä ja nauttivansa verkostoitumisesta, yhdessä innovoimisesta ja oppimisesta.

twodayn tiimi toimii läpinäkyvästi

twodayn tiimin työskentely on Liljan mukaan ollut erinomaisen itseohjautuvaa. Porukka on auttanut mielihyvin toinen toistaan ja käyttänyt pitkiäkin aikoja pulmatilanteiden ratkaisemiseen yhdessä.

”Tiimin itsenäisyys ja sitoutuminen oma-aloitteisuuteen on ollut tärkeä tekijä projektin onnistumisessa. Kun vielä muistetaan, että hanke on toteutettu korona-aikana, jolloin suurin osa tiimiläisistä ei edes tavannut livenä, porukan hyvä fiilis on todella hieno onnistuminen”, Lilja sanoo.

Myös asiakkaat arvostavat projektin aitoa avoimuutta ja läpinäkyvyyttä, sillä silloin asiakas pääsee kiinni tiimin tekemiseen ja pystyy ohjaamaan työn suuntaa. Lilja antaa tästä esimerkin: "Etenkin työn alkuvaiheessa tiimi halusi asiakkaalta nopeasti palautetta. Niinpä järjestettiin demotilaisuuksia, joissa sidosryhmät pääsivät antamaan palautetta kahden viikon kehityssprintin jälkeen."

Omassa tehtävässään Lilja kokee keskeisimmäksi viestintäkanavien pitämisen auki. Hän varmistaa, että oikeat ihmiset löytävät tavat keskustella keskenään. Scrum Masterin pelikenttää on se, että tieto saadaan liikkumaan.

”Tuoteomistaja ymmärtää parhaiten, mitä järjestelmällä halutaan tehdä. Kehitystiimi taas tietää, miten se toteutetaan. Minun tehtäväni on varmistaa, että molemmat osapuolet ymmärtävät asiat samalla tavalla”, Lilja sanoo.