Sote-ala kantaa mukanaan poikkeuksellisen painavaa historian painolastia moneen muuhun toimialaan verrattuna. Erilaisia järjestelmiä on paljon ja niitä on ollut käytössä pitkään.
Myös suunnitteluperiaatteet ovat muuttuneet vuosien varrella paljon. Viisitoista vuotta sitten käyttöön otetut järjestelmät on tehty sen aikaisen tiedon valossa ja ne olivat silloin hyviä. Mutta teknologia on kehittynyt ja nyt teini-iässä olevat järjestelmät tuntuvat auttamatta kömpelöiltä.
Erityisesti kolme toimintatapaa aiheuttaa käyttäjille harmaita hiuksia:
- rakenteinen tiedonkeruu pudotusvalikoineen
- tarve käyttää montaa järjestelmää yhtä aikaa
- järjestelmien yleinen hitaus.
Mistä nämä ongelmat johtuvat ja miten kehitetään järjestelmiä, joissa nämä karikot vältetään?
Rakenteisesta tiedonkeruusta ei pääse eroon – mutta sen voi tehdä käyttäjäystävällisesti
Kaikki tietävät, miten turhauttavaa on valita valmiista valikosta oikeita vastauksia. Etenkin silloin, jos mikään vastauksista ei ole ihan sitä, mitä haetaan. Tai kun valikoita on liikaa ja niiden kliksutteluun menee tuhottomasti aikaa.
Nyt on pakko olla ilonpilaaja: emme tule koskaan pääsemään kokonaan eroon rakenteisesta tiedonkeruusta. Jäsennelty tieto vastaa lainsäädännön vaatimuksiin ja auttaa keräämään dataa kansallisiin tietokantoihin sekä johtamisen tueksi. Valmiit vaihtoehdot vähentävät tulkinnanvaraa ammattilaisten välillä ja varmistavat, että potilaan terveyden tilannekuva huomioidaan mahdollisimman kattavasti.
Joskus käyttäjät pakotetaan pysähtymään valikkojen äärelle turvallisuuden vuoksi. Näin varmistetaan, ettei mikään potilasturvallisuuden kannalta kriittinen asia jää tarkistamatta.
Tarkistuslistoja käytetään esimerkiksi leikkaussalityössä. Järjestelmä pakottaa valitsemaan valikosta, onko potilaalla anestesialääkeallergia. Käyttäjän kannalta olisi ehkä nopeampaa, että järjestelmä tarjoaisi oletuksena EI-vastausta, mutta tällöin mahdollinen KYLLÄ voisi luiskahtaa liian helposti ohi.
Miten rakenteinen tiedonkeruu tehdään käyttäjäystävällisesti?
Hoitotyön arkipäivässä kirjaaminen voi silti tuntua työläältä. Lainsäädännön vuoksi ammattilaisen tulee esimerkiksi aina kertoa syy siihen, että hän katsoo tietyn ihmisen tietoja tämän henkilötunnuksella.
Paras ratkaisu on kompromissi, jossa tietyt, pakolliset asiat kerätään rakenteisesti, ja osan voi kirjata vapaisiin kenttiin.
- Intuitiivisiksi rakennetut valikot auttavat muistamaan oikeita lyhenteitä ja ne voivat tarjota käyttäjälle ohjeistuksia tai ehdotuksia. Se tekee työstä sujuvaa ja nopeaa.
- Tulevaisuudessa saamme yhä enemmän apua kirjaamiseen myös tekoälyltä. Jatkuvasti oppiva, automaattinen puheentunnistus täyttää tietoja ja kliinikko tarkistaa, että ne ovat oikein.
- Käyttäjäystävällisyys paranee myös sillä, että järjestelmä on yhteydessä mittalaitteisiin ja kerää tietoa suoraan niistä. Näin tietoa ei tarvitse kerätä manuaalisesti monesta eri paikasta eikä sitä tarvitse naputella erikseen, mahdollisesti jopa useaan eri järjestelmään.
- Käyttäjien täytyy päästä mukaan tekemään käyttöliittymää. Näin voidaan jo kehitysvaiheessa huomioida kaikki tarvittavat prosessit ja ymmärretään, miksi mitäkin valintoja tehdään.
Sydänsairaalan Kardio-toiminnanohjausjärjestelmä on hyvä esimerkki siitä, että myös sote-alalle on mahdollista kehittää käyttäjäystävällisiä järjestelmiä – vaikka niillä kerättäisiin runsaasti rakenteista tietoa.
Kardio oli ensin laaturekisteri, ja vuosien varrella sitä on laajennettu monipuoliseksi toiminnanohjausjärjestelmäksi. Kardiossa esimerkiksi tehdään rakenteisia valintoja ja niiden pohjalta luodaan automaattisia sanelutekstejä, joita voidaan viedä potilaskertomusjärjestelmiin. Tämä säästää esimerkiksi sihteerien työaikaa merkittävästi.
Lue lisää Sydänsairaalan Kardio-järjestelmästä
Sovellusten määrä vähenee, kun tieto kulkee saumattomasti järjestelmästä toiseen
Hypätään sitten toiseen hoitotyön ammattilaisia hiertävään aiheeseen. Jotta kaiken tarvittavan tiedon saa kokoon, näyttö vilisee avoimia sovelluksia sekä järjestelmän sisällä että selaimessa. Se ei ole pelkästään ärsyttävää, vaan voi johtaa myös inhimillisiin virheisiin esimerkiksi lääkityksen määräämisessä.
Tämä(kin) toimintatapa juontaa sote-alan järjestelmähistoriasta. Suomessa on kymmenien vuosien varrella ollut monenlaisia sähköisiä järjestelmiä, joihin on kerätty tietoa. Koska näillä järjestelmillä ei ole ollut mahdollista kerätä kaikkea tietoa, jota eri toiminnoissa on tarvittu, on niiden rinnalle kehitetty uusia järjestelmiä täsmätarpeisiin.
Eri järjestelmät vaihtavat tietoa integraatioiden kautta. Integraatioiden teko on kuitenkin kallista ja hidasta, joten usein niitä toteutetaan vain minimimäärä “riittävän” sujuvan käytön mahdollistamiseksi. Tällöin tiedonkulkuun jää aukkoja, joiden vaikutukset kumuloituvat, kun järjestelmien määrä kasvaa.
Miten sovellusten määrää voidaan vähentää?
Menneisyyteen ei onneksi tarvitse jäädä jumiin, vaan modernin ohjelmistoteknologian mahdollisuuksista voi päästä nauttimaan yllättävän ketterästi. Avainsanoja ovat integraatiot ja tiedon virtaaminen. Taustalla voi edelleen raksuttaa lukuisia eri järjestelmiä, mutta hoitotyön ammattilainen saa eteensä mahdollisimman paljon tietoa mahdollisimman selkeäksi jäsenneltynä.
Tälle periaatteelle on rakennettu Tilannekuva UNA, joka koostaa eri järjestelmistä kerätyt asiakas- ja potilastiedot yhteen näkymään.
Työskentelitpä sitten ambulanssissa, sairaalassa tai kotihoidossa, Tilannekuva UNA hakee tietoa eri järjestelmistä ja mallintaa kaiken keräämänsä yhteen näkymään. Ammattilainen näkee yhdellä kertaa ja nopeasti olennaisimmat tiedot, kuten lääkitykset, riskitekijät ja hoitotoimenpiteiden aikajanat. Kognitiivinen kuorma kevenee ja aikaa jää enemmän hoitotyölle.
Aina ei toki ole mahdollista tai järkevää tehdä jälleen uutta sovellusta muiden puutteita paikkaamaan. Ratkaisua voi hakea myös mm. automaation, ohjelmistorobotiikan sekä integaatioalustojen paremman hyödyntämisen kautta. Tietoaltaat ja niiden päälle rakennetut raportointiratkaisut auttavat eri lähteistä tulevan tiedon koostamisessa ja jatkoraportoinnissa.
Tärkeää on tunnistaa kokonaisuus, pahimmat kipupisteet ja kehitystarpeet ja lähteä niiden pohjalta hahmottelemaan ja priorisoimaan tarkempia parannuskohteita.
Järjestelmien hitauteen on syitä – eli myös ratkaisuja
Kolmas yleinen turhautumisen aihe on järjestelmien hidastelu. Vastaanottokäynnit viivästyvät, kun kone vain raksuttaa. Järjestelmät voivat tökkiä monesta eri syystä.
- Järjestelmien välisten integraatioiden arkkitehtuurissa on ongelmia. Vanhat sovellukset eivät reagoi tietopyyntöihin uusien lailla, ja tätä ei ole osattu huomioida suunnitteluvaiheessa.
- Toinen yleinen syypää järjestelmien hitauteen löytyy organisaatioiden omista tietohallintoympäristöistä. Jos järjestelmien sydän sykkii perinteiseen malliin sairaalan omilla on-premise -palvelimilla, pulmana saattavat olla esimerkiksi tietoliikenneyhteydet, jotka eivät kestä hyvinvointialuesiirtymän myötä kasvanutta käyttäjämäärää.
Hitaus onkin usein monen asian summa: kun lyödään yhteen hitaat tietoliikenneyhteydet ja se, että tieto siirtyy hitaasti muista sovelluksista, niin tilannetta ei auta, vaikka käyttöön otettaisiin millainen supersovellus tahansa.
Tilanne ei kuitenkaan ole toivoton. Järjestelmien hidastelu helpottaa, kun ongelmien juurisyyt diagnosoidaan onnistuneesti ja niitä lähdetään ratkomaan pala kerrallaan.
Sovelluskehityksen kumppaniksi kannattaa valita toimittaja, jolla on kokemusta ja ymmärrystä sote-tietojärjestelmien monimutkaisesta kokonaisuudesta – myös silloin, kun näyttää siltä, että hidastelu vaivaa vain tiettyjä sovelluksia. Uudistuksia ei kannata lähteä tekemään summamutikassa, vaan ensin on syytä analysoida, missä päin viiveitä tarkalleen ottaen on, mistä ne johtuvat ja miten ne kumuloituvat.
Isojen perusjärjestelmien ketteryys ei voi aina yltää kevyiden kuluttajasovellusten tasolle, mutta mahdottoman tuntuisiin viiveisiin ja odotteluun ei kannata mukisematta tyytyä. Onhan kaikki odotteluun käytetty aika pois hoitotyöstä.
Soten ICT:n käytettävyyden parantaminen voi olla pienestä kiinni
Mitä sitten on tehtävissä, kun töissä digitaalinen maailma toimiikin eri säännöillä kuin kuluttajamaailmassa? Pitääkö vain heittää kirves kaivoon ja sopeutua siihen, että sote-alalla joudutaan ikuisesti kärvistelemään surkean käyttäjäkokemuksen kanssa?
Paljon on tehtävissä.
Helpoin tie parempaan käyttäjäkokemukseen on yleensä lähteä tekemään joko kokonaan uusia sovelluksia tai kehittää aktiivisesti käytössä olevien sovelluksien teknologioita, ja varmistaa, että ne keskustelevat hyvin toistensa ja myös järeämpien perusjärjestelmien kanssa.
Liian usein yritetään kehittää järjestelmiä, jotka palvelisivat mahdollisimman monia käyttäjiä ja yksiköitä. Tällaisessa geneerisen sovelluskehityksen haasteena on kuitenkin se, että eri erikoisalojen tarpeet ovat erilaiset. Ja kun yritetään ratkoa kaikkia kohtia kerralla, ei lopputulos ole oikein kenellekään hyvä.
Useimmiten kannattaa lähteä liikkeelle jostain pienestä, omaa lääketieteen alaa palvelevasta sovelluksesta, jossa on kasvunvaraa myös laajemmin palvelevaksi järjestelmäksi. Tällainen järjestelmäkehitys on ketterää ja kustannustehokasta, ja räätälöidyt täsmäsovellukset on helppoa integroida jo olemassa olevaan kokonaisuuteen.
Hyvä esimerkki pienestä liikkeelle lähteneestä sovelluksesta on jo edellä mainittu Kardio, joka lähdettiin rakentamaan kardiologian ja sydän- ja rintaelinkirurgian tarpeisiin. Siitä on ajan myötä kasvanut iso ja yhä laajemmin yhtä lääketieteen alaa palveleva kokonaisuus. Samalla teknologiselle alustalle on myös toteutettu muun muassa endokrinologian ja haavanhoidon hoitotyötä tukevia ratkaisuja.
Lisäksi olisi äärimmäisen tärkeää, että henkilöstölle pystyttäisiin allokoimaan aikaa myös palvelumuotoiluun ja kokonaisarkkitehtuurin suunnitteluun.
Sote-alan ICT-järjestelmien ei tarvitse olla vaikeita käyttää. Kun käyttäjät otetaan mukaan kehitystyöhön alusta alkaen, huomioidaan realiteetit ja vaatimukset ja tuodaan mukaan osaaminen joustavista ja käyttäjäystävällisistä ohjelmistoarkkitehtuureista, viemme yhdessä koko alaa oikeaan suuntaan.
Lataa ilmainen opas täynnä rahanarvoisia neuvoja hoitopolkujen digitalisointiin:
