Uusia potilastietojärjestelmiä kilpailutetaan - mutta saadaanko niistä helppokäyttöisiä?

Länsi-Uudenmaan sairaanhoitopiiri ei ota käyttöönsä Apotti- potilastietojärjestelmää, vaan aikoo kilpailuttaa oman potilastietojärjestelmänsä. Syyksi kerrotaan, että kalleutensa lisäksi Apotti ”on työntekijöiden mielestä erityisen vaikea käyttää” (HS 12.9.). Samoin Itä-Uusimaa hylkäsi Apotin.

Kannattaa kuitenkin muistaa, että kun Apotti-hankintaa käynnistettiin vuosia sitten, helppokäyttöisyys ilmoitettiin sen keskeiseksi tavoitteeksi ja kriteeriksi. Tässä kuitenkin epäonnistuttiin. Ainakin yhtenä ratkaisevana syynä se, että käytettävyyttä tavoiteltiin kilpailutuksessa samoin käytännöin kuin aiemminkin. 

Kirjoitin - pitkästä aikaa - asiasta mielipidekirjoituksen Hesariin (ks. myös kuva). 

Saa nähdä, kilpailuttavatko kyseiset sairaanhoitopiirit potilastietojärjestelmää niin, että helppokäyttöisyyttä aidosti edellytettäisiin. Jos näin tekisivät, olisivat kyllä uranuurtajia. 

Jos käytännöt näissä kilpailutuksissa pysyvät entisenlaisina, riskinä on, että myös uudet potilastietojärjestelmät osoittautuvat vaikeakäyttöisiksi. Hyvää käytettävyyttä voidaan toki näinkin saada, mutta vain hyvällä tuurilla tai kalliilla lisätilauksilla. 

Vaikuttavuus on tärkeää - mutta miten se pitäisi ottaa huomioon julkisissa hankinnoissa?

Tietojärjestelmän vaikuttavuuden mittareiden ja tavoitteiden määrittäminen on tärkeää. Niitä ei kuitenkaan pitäisi sisällyttää sellaisinaan tarjouspyyntöön vaatimuksiksi, koska vaikuttavuuden todentaminen on mahdollista vasta käytön aikana, ehkä paljonkin kehitystyön päättymisen jälkeen. Sen sijaan haluttu vaikuttavuus olisi määritettävä tarjouspyyntöön sellaisilla alemman tason vaatimuksilla, (1) joiden saavuttaminen voidaan todentaa heti kehitystyön päättyessä ja (2) joiden saavuttaminen tarkoittaa riittävän luotettavasti, että saavutetaan myös haluttu vaikuttavuus. 

Olin mukana 13.10.2022 Hankinta-yhdistyksen aamukahveilla, jonka aiheena oli Kustannusvaikuttavuuden laskenta osana hankintaprosessia. 

Aihe on sikäli kiinnostava, että itse olen korostanut käytettävyyden vaikuttavuuden määrittämisen tärkeyttä (esimerkiksi tässä Sytyke-lehden artikkelissa). Tarkoittaa sitä, että ensin pitäisi määrittää haluttu käytettävyyden vaikuttavuus, ja vasta sen jälkeen käytettävyysvaatimukset.  

Aamukahvien esimerkki: toimittajan palkitseminen vaikuttavuuden saavuttamiseksi

Aamukahvien keskustelussa kerrottiin esimerkki julkisen hallinnon tietojärjestelmähankinnasta, jossa vaikuttavuus oli otettu huomioon näin:

• Toimittajaa palkittiin sen mukaan, kuinka paljon palvelu houkuttelisi käyttäjiä. Siis mitä enemmän käyttäjiä palvelulla, sitä enemmän palkitaan toimittajaa. Muistaakseni tavoite oli 60.000 käyttäjää. 
• Tässä ei siis suoraan vaikuttavuutta mitattu rahassa, mutta vaikuttavuudesta kyse on joka tapauksessa.

Oletan, että tämä palkitsemismalli oli osana tarjouspyyntöä; tosin tästä ei ollut puhetta tilaisuudessa.

Toimittajan palkitseminen vaikuttavuusmittarilla - miksi voi olla ongelma?

Edellä mainitussa lähestymistavassa on yksi periaatteellinen ongelma. Vaikuttavuuden käyttäminen tavoitteena tai palkitsemisperusteena (tarjouspyynnössä) on ongelma sitä kautta, että vaikuttavuuden saavuttamista ei voi todentaa kehitystyön päättyessä: 

• Vaikuttavuushan tulee esiin vasta ajan myötä, kuten edellä mainitussa esimerkissä käyttäjien lukumäärä. 
• Käytännössä tarkoittaa sitä, että haluttu vaikuttavuuden saavuttaminen jää arvoitukseksi siinä vaiheessa, kun kehitystyö on päättynyt. 

Jos käy niin, että esimerkin järjestelmä ei houkuttele käyttäjiä, niin tilaajalta säästyy toimittajan bonusrahat. Mutta mitä tilaaja tekee järjestelmällä, jota käyttäjät eivät käytä?

Jos ottaa konkreettisemman esimerkin, niin moni varmaan muistaa muutaman vuoden takaisen yrityksen käyttää äänestyskonetta kunnallisvaaleissa. Sehän päättyi epäonnistumiseen, kun jotkut äänestäjät jättivät epähuomiossa äänestysprosessin kesken (kyseessä siis selkeä käytettävyysongelma...).

Kuvitellaan, että yllämainittua vaikuttavuusajattelua olisi käytetty äänestyskoneen kehittämisessä. Siis että looginen toimittajan palkitsemisen mittari olisi se, että vaalit onnistuvat äänestyskoneella. Mutta silloin ollaan jo auttamattomasti myöhässä, koska äänestyskoneen *pitää* toimia vaaleissa. Ei oikein voi ajatella niin, että toimittajan palkitsemismekanismi on se, että vaalit onnistuvat äänestyskoneella, ja samalla ottaa riski, että vaalit eivät onnistukaan. (On muuten esimerkki vaikuttavuudesta, jonka mittaaminen rahassa on vaikeaa). 

Miten sitten ottaa vaikuttavuus huomioon hankinnoissa?

Tavoitteellista pitäisi olla, että haluttu vaikuttavuus voitaisiin mitata - riittävän luotettavasti - heti kehitystyön päättyessä. 

Miten tämä voidaan tehdä? 

Ihan niin kuin yllä, aluksi hankkijan pitää määrittää vaikuttavuusmittarit- ja tavoitteet. Määritetään esimerkiksi, kuinka paljon käyttäjiä halutaan kehitettävälle järjestelmälle. Tai että äänestyskoneen on oltava sellainen, että vaalit onnistuvat. 

Sitten perusratkaisu vaatimusten määrittämiselle tarjouspyyntöön on, että määritetään sellaiset alemman tason vaatimukset, että

1. vaatimusten saavuttaminen voidaan todentaa kehitystyön päättyessä
2. vaatimusten saavuttaminen tarkoittaa riittävän luotettavasti sitä, että myös haluttu vaikuttavuus saavutetaan

Kummatkin edellämainitut esimerkit (tietojärjestelmä, äänestyskone) ovat sellaisia, joissa haluttu vaikuttavuus (paljon käyttäjiä, onnistuneet vaalit) riippuu suoraan järjestelmän käytettävyydestä. 

Alemman tason vaatimuksia olisivat silloin käytettävyysvaatimukset. Käytettävyysvaatimukset (valituilla käytettävyysmittareilla) pitää siis määrittää sellaisiksi, että niiden saavuttaminen tarkoittaa riittävän luotettavasti sitä, että kehitetyllä järjestelmällä saavutetaan haluttu vaikuttavuus järjestelmän käytön aikana. Käytännössä käytettävyysvaatimuksilla tarkoitetaan käyttäjien suoriutumiseen perustuvia vaatimuksia, niin kuin olen useassa kirjoituksessa todennut (esimerkiksi tässä). 

Hankkijan on tehtävä sisäisesti käytettävyysvaatimusten analyysi- ja määrittämistyö ennen hankintaa. Tarjouspyyntöön määritettäisiin sitten käytettävyysvaatimukset (eikä vaikuttavuusmittarit). Kyseiset käytettävyysvaatimukset olisivat sitten osa järjestelmän hyväksymiskriteereitä kehitystyön päättyessä. Ja jos käytettävyysvaatimukset on määritetty oikein, niin järjestelmällä pitäisi tulla saavuttamaan myös haluttu vaikuttavuus.  

Seitsemän (7) väärää ja neljä (4) oikeaa tapaa ottaa käyttäjät mukaan järjestelmän hankinnassa ja kehityksessä

Kirjoitin elokuussa blogikirjoituksen potilastietojärjestelmän tarjouspyynnöstä. Sen jälkeen tuli keskustelua LinkedInissä liittyen siihen, miten käyttäjien pitäisi olla mukana järjestelmien hankinnassa ja kehityksessä, ja miten ei. 

Olen kirjoittanut asiasta aiemmin seikkaperäisesti, esimerkiksi kappaleen Miten käyttäjät mukaan tietojärjestemäkehitykseen - ja miten ei? Eduskunnan tulevaisuusvaliokunnan julkaisuun Katse kohti IT-etiikkaa. 

Nyt sitten ajattelin kerrata lyhyesti: luettelo niin laadullisesti kuin eettisesti vääristä ja oikeista tavoista. 

Väärät tavat ottaa käyttäjät mukaan: 

1. Käyttäjiä pyydetään määrittelemään järjestelmän ominaisuuksia ja kertomaan mielipiteitä tulevasta järjestelmästä 
2. Käyttäjiä pyydetään määrittelemään vaatimukset järjestelmälle 

3. Suunnitellaan yhdessä käyttäjien kanssa
4. Käyttäjiä pyydetään antamaan käyttöliittymistä laadullisia ”asiantuntija-arviointeja” 

5. Käyttäjiä pyydetään katselmoimaan käyttöliittymiä 
6. Käyttäjiltä kysytään ehdotuksia paremmiksi suunnitteluratkaisuiksi 
7. Käyttäjät laitetaan pisteyttämään järjestelmän käytettävyys toimittajien esittämien demojen perusteella 

Oikeat tavat ottaa käyttäjät mukaan:

1. Sisällölliset haastattelut: käyttäjiltä haastatellaan heidän työstään tai ammattiosaamisestaan 
2. Käyttäjiä havainnoidaan heidän työssään 
3. Käyttäjiä pyydetään käytettävyystestien testihenkilöiksi 
4. Käyttäjiltä kysytään heidän käyttökokemuksestaan 

Jos nämä vetää yhteen periaatteiksi, niin voisi tiivistää, että käyttäjät otetaan mukaan laadullisesti ja eettisesti oikein, kun  

• Käyttäjien ei pidä olla missään muussa roolissa kuin oman ammattinsa ja työtehtävänsä edustajana (käyttäjät ovat siis ainoastaan omalla mukavuusalueellaan)
• Käyttäjiä ei pidä vastuuttaa mistään asiasta järjestelmän hankinnan ja kehitystyön aikana; ei esimerkiksi siitä, että osaavatko jäsentää haastatteluissa vastauksiaan oikein ("oikeat tavat" kohta 1). Kaikki vastuu suunnitteluratkaisujen  - ja myös vaatimusten - oikeellisuudesta on aina suunnittelutiimillä. 

Jos kiinnostaa, miten tehdään tuloksellisesti ja tehokkaasti sisällöllisiä haastatteluja ("Oikeat tavat" kohta 1),  olen kirjoittanut menetelmästä kirjan Kohdemaailma-analyysi. Menetelmässä kerrotaan, miten haastatella asiakkaita niin, että saadaan nopeasti syvällinen ymmärrys asiakkaan tarpeista samalla, kun haastateltavia kohdellaan eettisesti oikein. 

PS. Jos sinulla on kommentoitavaa ym. oikeisiin ja vääriin tapoihin (tai muuten kirjoitukseen), niin mielellään sellaisia kuulisin!