Lappican potilastietojärjestelmän tarjouspyyntö: ei uutta käytettävyyden suhteen

Lapin alueella toimiva Lappica Oy on tehnyt tarjouspyynnön potilastietojärjestelmästä. Tavoitteena on hankkia "helppokäyttöinen" järjestelmä. Kun tutkii tarjouspyynnön sisältöä, siinä ei kuitenkaan käytännössä edellytetä helppokäyttöisyyttä. Sinällään tämä ei ole yllättävää: kun isommatkaan hankintayksiköt eivät osaa aidosti vaatia käytettävyyttä tarjouspyynnössä, miten pienehköllä hankintayksiköllä olisi edellytyksiä olla uranuurtaja. 

HUOM! Korostan vielä, että tätä analyysia ei pidä ottaa erityiseksi kritiikiksi Lappica Oy:ta kohtaan. Tarjouspyyntö sattui vain osumaan silmääni, kun kyse on potilastietojärjestelmästä. Olen seurannut aika tiiviisti Apotti-potilastietojärjestelmän hankintaa (monet kirjoitukset tässä blogissa, ja esimerkiksi Helsingin Sanomissa). Otin tämän tarjouspyynnön tarkasteluun ihan tämän kiinnostuksen pohjalta. 

Mistä kyse

Pääkaupunkiseudun Apotti-potilastietojärjestelmän käytettävyysongelmat ovat tunnettuja. Nyt Apotista on tekeillä jopa kantelu. 

Keskeinen syy Apotin käytettävyysongelmiin on se, että vaikka käytettävyyttä pidettiin lähtökohtaisesti erittäin tärkeänä asiana, sitä ei edellytetty oikealla tavalla tarjouspyynnössä (analyysia esimerkiksi tässä). Käytettävyys oli kyllä keskeisenä laatutekijänä tarjouspyynnössä, mutta ei sillä tavalla, että se olisi aidosti sitonut toimittajaa tuottamaan hyvää käytettävyyttä. 

Nyt sitten osui sattumoisin silmiini uusi potilastietojärjestelmän kilpailutus, kun Lapin sairaanhoitopiirin tarjouspyyntö on julkaistu (luettavissa luultavasti 15.8.2022 asti, jolloin on tarjousten viimeinen jättöpäivä). 

Kun kyseessä on potilastietojärjestelmä, tarjouspyyntö kiinnosti sen verran, että analysoin sitä seuraavassa käytettävyyden kannalta. 

Miten käytettävyys määräytyy yleensä tarjouspyynnöissä?

Tarjouspyynnössä halutun käytettävyyden tason määrittä kaksi asiaa: 

• miten käytettävyysasioita vaaditaan pakollisissa vaatimuksissa
• miten käytettävyysasioita on sisällytetty vertailuperusteisiin, ja mitkä ovat näiden painoarvot vertailussa

Valintaprosessi menee sitten lyhyesti ilmaistuna: 

    1. Tarkistetaan, täyttyvätkö pakolliset vaatimukset: 

• Jos täyttyvät, tarjous etenee vertailuvaiheeseen
• Jos eivät täyty, tarjous tipahtaa pois kilpailutuksesta

    2. Lasketaan yhteen vertailupisteet. Tarjouskilpailun voittaja on se, joka saa eniten vertailupisteitä. 

Käytännössä keskeisin asia on se, miten käytettävyys on määritetty pakollisiin vaatimuksiin. Hyvin valmistellussa tarjouspyynnössä kaikki käytettävyysasiat on pakollisissa vaatimuksissa. Vain erityisissä tapauksissa käytettävyysasioita on perusteltua laittaa vertailuperusteisiin. 

Lappican tarjouspyynnön sisällön kuvausta

Tarjouspyynnön johdanto-osassa lukee esimerkiksi: 

"Tavoitteena on saada käyttöön helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava työterveyshuollon järjestelmä. Järjestelmän perustoiminnallisuuksien pitää olla joustavia ja käyttäjien muokattavissa...  Järjestelmän pitää tukea ja helpottaa yhteistyötä työnantaja-asiakkaiden kanssa. Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla."

Tällä perusteella käytettävyys on hankkijalle tärkeä asia.

Mutta. On huomattava, että tällaisella epäformaalilla johdantotekstillä ei ole mitään merkittävyyttä kilpailutuksessa. Toimittajien ei kannata kiinnittää tällaiseen mitään huomiota, koska tällaiset yleiset tavoitteet eivät vaikuta voittajan valintaan millään tavalla, eivätkä velvoita voittajaa mihinkää niitä ratkaisun kehittämisessä.  

Mitä käytettävyysasioita vaaditaan tarjouspyynnössä?

Tässä tarjouspyynnössä vertailuperusteet ovat:

• laadulliset vaatimukset 40 pistettä, joista
• "pisteytettävät vaatimukset" 35 pistettä 
• projektisuunnitelma 5 pistettä
• hinta 60 pistettä
• (yhteensä 100 pistettä)

"Pisteytettävät vaatimukset", samoin kuin pakolliset vaatimukset on esitetty samassa, isossa excel-taulukossa

• pakolliset vaatimukset tarkoittavat, että toimittajan on pakko täyttää ne (muuten tipahtaa pois kilpailutuksesta)
• pisteytettävät vaatimukset tarkoittavat, että toimittajan ei ole pakko niitä täyttää, mutta niiden täyttäminen tarkoittaa enemmän pisteitä vertailuperusteisiin ja sitä kautta paremmat mahdollisuudet voittaa kilpailutus

Yksittäisiä vaatimuksia - pakollisia ja pisteytettäviä - on yhteensä muutamia satoja.  Excel-taulukko sisältää noin 15 välilehteä, joihin on vaatimukset on luokiteltu aiheittain: Työterveyshuolto, Ajanvaraus, Ilmoittautuminen,  Lausunnot ja lähetteet jne. 

Ja on siellä sitten yksi välilehti nimeltään Käyttäjälähtöisyys. Alla kuvankaappaus taulukon ko. kohdasta.

Sisältäänkö tarjouspyyntö käytettävyysvaatimuksia?

Käytettävyys tarkoittaa lyhyesti ilmaistuna sitä, missä määrin käyttäjät onnistuvat saavuttamaan tavoitteensa. Tarkemmin käytettävyyden määritelmästä esimerkiksi täällä.

Kun tarkastelee "Käyttäjälähtöisyys" -vaatimuksia, niin useimmissa vaatimuksissa lukee, että jokin asia

• "pitää voida tehdä" 
• "pitää olla mahdollista" 
• "pitää päästä tekemään" 
• tms. 

Tällaiset muotoilut tarkoittavat yleensä toiminnallisia vaatimuksia eivätkä käytettävyysvaatimuksia. Ja nämä ovat eri asioita. 

Toiminnallinen vaatimus kertoo, millainen ominaisuus pitää järjestelmässä olla, kun taas käytettävyysvaatimus määrittää, missä määrin käyttäjien pitää onnistua järjestelmän käytössä. Se, että onko jokin vaatimus käytettävyysvaatimus vai toiminnallinen vaatimus, voidaan todeta yksinkertaisella kysymyksellä: 

Voiko vaatimuksen täyttää niin, että sen toteutus on vaikeakäyttöinen? 

Jos vastaus on kyllä, niin kyseessä ei ole käytettävyysvaatimus. 

Otetaan esimerkiksi yllä olevasta taulukosta vaatimus Käy_03: PTJ:ssä on sisäinen ohjeistus hakutoiminnolla. Kysytään sitten,  voiko kyseisen vaatimuksen täyttää siten, että toteutus on vaikeakäyttöinen? 

Vastaus on, että (tietenkin) voi. Vaikka ohjeet ja hakutoiminta ovat sinällään käyttäjän kannalta hyviä toimintoja, niiden olemassaolo ei ole itsessään sama kuin käytettävyys. Ne kun on periaatteessa mahdollista toteuttaa kuinka vaikeakäyttöisiksi.  

Huom. Tämä ei tietenkään tarkoita sitä, että toimittaja suunnittelisi ohjeiston tietoisesti vaikeakäyttöiseksi. Mutta jos tarjouspyyntö ei aidosti edellytä käytettävyyttä, niin se tarkoittaa, että toimittajan ei kannata kiinnittää käytettävyyteen huomiota, koska se lisäisi kehityskustannuksia ja sitä kautta huonontaisi mahdollisuuksia voittaa tarjouskilpailu. 

Ainoastaan taulokon viimeinen vaatimusta - Käy_36: Tutkimustulosten ja lähetteiden palautteiden siirtyy automaattisesti sijaistajalta seuraavalle sijaistajalle - voi pitää käytettävyysvaatimuksena. On tietenkin  parempaa käytettävyyttä, jos jokin toiminto tehdään automaattisesti ilman, että käyttäjän tarvitsee tehdä mitään. 

Jos ottaa esiin toisen piirteen vaatimuksista, niin yksi käyttäjäryhmä nousee ylitse muiden: peräti 8 vaatimuksen käyttäjäryhmä on pääkäyttäjät. Käytettävyyden kannalta tietenkin pitäisi keskittyä "tavallisiin" loppukäyttäjiin, joita tässä tapauksessa ovat työterveydenhuollon henkilökunta ja järjestelmää käyttävät yritysten edustajat. 

Pakolliset vaatimukset vs. pisteytettävät vaatimukset

Kun en ole työterveyshuollon asiantuntija, niin minun on vaikea arvioida, ovat kaikki pakolliset vaatimukset todellakin välttämättömiä. Tai toisaalta, ovatko jotkut pisteytettävät vaatimukset sellaisia, jotka pitäisivät olla pakollisia. Joka tapauksessa ne ovat nähtävästi hyödyllisiä, koska niistä saa vertailupisteitä.   

Yleisesti tällainen jako on vähän keinotekoinen. Parempi ratkaisu olisi yksinkertaisesti, että kaikki vaatimukset olisivat pakollisia. Ja pisteytettäviä vaatimuksia käytettäisiin vain hyvin harkitusti sellaisissa tapauksissa, joissa hyvin tullaan toimeen kyseisiä ominaisuuksia mutta joiden olemassa olosta kannattaa maksaa vähän enemmän. 

Muut vaatimuskategoriat

Tarjouspyynnössä on siis noin 15 samantyyppistä vaatimuslistaa kuin Käyttäjälähtöisyys -vaatimukset. 

Hyvin monessa julkisessa tarjouspyynnössä käytettävyysvaatimuksia on paljon muuallakin kuin mahdollisessa käytettävyysosiossa. Niin luultavasti tässäkin. Tätä blogia varten en käynyt systemaattisesti läpi muiden osioiden vaatimuksia, mutta esimerkiksi seuraavia käyttäjiin liittyviä osui silmään: 

• Käyttäjät voivat valita valmiin kalenteripohjan kalenterimallista tai luoda oman kalenteripohjan erilaisia aikatyyppejä käyttäen
• Ammattilainen voi tarkastella PTJ:n ajanvarausnäkymässä olevia aikatauluja esimerkiksi päivä- ja viikkokohtaisesti
• Lääkärillä on oltava tieto uudistamista odottavien lääkemääräysten uudistuspyynnön voimassaolosta

Nämäkin ovat siis käytännössä toiminnallisia vaatimuksia: järjestelmä voi täyttää tällaiset vaatimukset, vaikka ne olisivat vaikeakäyttöisesti toteutettu. 

Yhteenveto

Johtopäätös on, että Lappican tarjouspyyntö ei millään tavalla takaa, että valituksi tulisi sellainen järjestelmä, joka on esitetty tavoitteeksi tarjouspyynnön johdannossa: 

"helppokäyttöinen, käyttäjää ohjaava ja ammattilaisten työtä helpottava... Työnantajaorganisaatioiden rakenteen ja näkymien tulee olla käyttäjäystävällisiä ja selkeitä. Ajanvarauksessa ja vastaanotolla tulee organisaatioiden ja potilaiden taustatietojen olla selkeästi ja vaivatta saatavilla".

Mutta. Eipä tämä tarjouspyyntö ole sen huonompi käytettävyyden osalta kuin julkisen hallinnon tarjouspyynnöt yleensäkään. 

Ja itse asiassa tässä tarjouspyynnössä on hyviäkin puolia: 

• Tarjousten käsittely ei vie käytettävyyden osalta paljon resursseja - katsotaan vain, mitä tarjoajat ovat ruksanneet. Joissakin kilpailutuksissa käytettävyysvaatimusten osalta on hyvinkin raskaita testejä ilman, että lopputulos on sen kummempi. Hyvänä esimerkkinä pääkaupunkiseudun paikallisliikenteen matkakortin lukija, jossa massiivisista testeistä huolimatta lopputuloksessa oli jopa ihan perustason käytettävyysongelmia. Lue tästä lisää.

• Laatutekijöiden painoarvo vertailuperusteissa oli "vain" 40%. Hyvin laaditussa tarjouspyynnössä laatutekijöiden painoarvon pitäisi olla lähellä nollaa, joka tapauksessa korkeintaan 20%. Mutta pahimmillaan on tarjouspyyntöjä, joissa laatutekijöiden painoarvo on peräti 70%. (Päinvastoin kuin usein luullaan, laatu vertailutekijöissä nimenomaan ei takaa tuotteen laatua). Eli siinäkään mielessä tämä tarjouspyyntö ei missään tapauksessa ollut pahimmasta päästä. 

Mikä olisi oikea tapa sisällyttää käytettävyys tarjouspyyntöön?

Jotta tarjouspyyntö edellyttäisi aidosti käytettävyyttä, niin 

• Käytettävyys olisi sisällytettävä pakollisiin vaatimuksiin. Vain erityistapauksissa käytettävyyttä voisi olla valintakriteereissä, ja silloinkin korkeintaan pienellä painoarvolla. 
• Käytettävyysvaatimukset olisi määritettävä suhteessa käyttäjien suoriutumiseen.  Silloin, kun käyttäjät suoriutuvat tehtävistään riittävän hyvin, järjestelmä on käytettävyydeltään hyvä. 

Miten sitten määritetään käytettävyysvaatimukset suhteessa käyttäjien suoriutumiseen? Sitä varten tarvitsee määrittää

• mittarit: millä mittarilla mitataan käyttäjien suoriutumista
• tavoitetasot: mikä mittaustulos ko. mittarilla on riittävän hyvä
• mittausinstrumentit: miten mittaus käytännössä suoritetaan (yleensä tämä tarkoittaa käyttäjätestejä, mutta ei välttämättä)

Ja vielä pitää ottaa huomioon, että mitkä tahansa mittarit, tavoitetasot ja instrumentit eivät kelpaa. Käytettävyysvaatimusten on oltava

• valideja: vaatimusten on aidosti kuvattava haluttua käytettävyyttä
• riittävän kattavia: niin, että vaatimukset ottavat huomioon riittävästi erilaiset käyttäjät ja heidän erilaiset käyttötarpeensa
• (tähän luetteloon yleensä kuuluva todennettavuus tuleekin täytetyksi sitä kautta, että määritetään mittarit ja mittausinstrumentit)

Olen kirjoittanut näistä asioista useammassa tämän blogin kirjoituksessa, ja pitänyt myös kursseja. Ehkä kirjakin on tulossa tässä lähiaikoina. Yksi yhteenvetovideo tässä.  

--------

Vastaus Sepon alla olevaan kommenttiin 

(blogialusta ei antanut tehdä pitkää kommenttia, niin kirjoitan sen tähän): 

Seppo: "1. Jos järjestelmää ollaan vasta tilaamassa, eikä se ole millään tarjoajalla vielä valmiina, niin miten käytettävyyttä voi arvioida? Käytännössä kai nämä järjestelmät rakennetaan aika suurelta osin vasta sitten, kun tilaus on saatu. Järjestelmistä lienee yleensä olemassa ”backend” eli tiedostojärjestelmä, joka ehkä on joissain toimitetuissa järjestelmissä pohjalla, mutta itse näkyvä osa eli käyttöliittymä tehdään vasta, kun tilaajalta saadaan siihen toiminnalliset vaatimukset. Ja siten käytettävyyttä pystytään mittaamaan vasta jälkeenpäin. Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten”, mutta vertailua ei pysty tarjousvaiheessa tekemään."

Timo: Muutama huomio tähän: 

a) Tässä nyt on eri vaihtoehtoja, riippuen siitä, kuinka valmista järjestelmää ollaan tilaamassa. Tässä videossa selitän vähän asiaa https://www.youtube.com/watch?v=WJHHExdIwlU. 

"b) ”Jos tarjouspyynnössä on käytettävyysvaatimuksia, niin kaikki tarjoajat voivat sanoa ”joo, me täytetään nuo kyllä sitten””. Niin, mielestäni vaatimukset pitää olla toimittajia sitovia. Jos ei täytä vaatimuksia, tilaajan ei tarvitse hyväksyä toimitusta. En tiedä onko toimittajat tällaiseen tottuneet, mutta jos oikeasti halutaan käytettävyyttä edistää, niin jotain tällaista pitää tehdä. 

c) ”Vertailua ei pysty tarjousvaiheessa tekemään”. Niin, pointti on se että vertailuja ei tehdä. Vaan testataan, täyttääkö järjestelmä vaatimukset. Käytettävyys on siis pakollisena vaatimuksena. 

 

Seppo: "2. Tai sitten pitäisi jo tarjousvaiheeseen sisällyttää tehtävä, jossa tarjouskilpailuun osallistujan pitää toimittaa jokin ”sample”, jolle on annettu täsmälliset arviointkriteerit. Tässä on ainakin se ongelma, että jonkin pienen palikan tekeminen käytettäväksi voi olla helppoa verrattuna koko järjestelmään, koska sen ei silloin tarvitse toimia koko järjestelmän kanssa yhteen, mutta siinä ei silloin myöskään luultavasti näy, miten hyvä koko järjestelmä on käytettävyydeltään silloin, kun kaikki osat oikeasti ovat olemassa."

Timo: Tässä olet ihan oikeassa. Käytettävyysvaatimuksilla on kolme pääkriteeriä: niiden itää olla validit, todennettavat ja riittävän kattavat. Ja tuo jälkimmäinen tarkoittaa juuri sitä mitä kommentoit.

Seppo: "3. Käytettävyyskriteerien pitäisi olla hyvin tarkat, ja niiden pitäisi kattaa periaatteessa koko systeemi. Muuten tulos voi olla se, että vaaditut osat täyttävät vaatimukset, mutta muut osat ovat sutta ja sekundaa. Käytettävyys kun on asia, jossa jokaisen lenkin pitää olla kunnossa, tai homma ei toimi."

Timo: Kylläpä näin. Ks. edellisen kohdan kommenttini. 

Seppo: "Sitten hieman sivuun tästä tarjouspyyntöasiasta. Olen seuraillut näitä tietojärjestelmäuutisia ja lukenut myös tutkimusartikkeleita. On alkanut muodostua sellainen käsitys, että iso osa ongelmaa on siinä. että järjestelmissä on rakenteinen tietokanta, jossa kaikki diagnoosit ja muut tiedot pitää luokitella tarkasti. Tämä johtaa siihen, että käyttäjät saavat eteensä loputtomasti valikoita ja ruudukoita, joista pitää klikkailla oikeat vaihtoehdot, jotka sitten tallentuvat järjestelmään. Vaikka käyttöliittymäsuunnittelijat tietenkin pyrkivät tekemään kaikista näkymistä mahdollisimman käytettäviä, niin näkymiä on vain liikaa ja niissä liikaa läpi käytäviä kohtia. Tämä lomakkeiden täyttely vie kohtuuttomasti aikaa verrattuna vanhaan systeemiin, jossa lääkäri saneli potilaan epikriisin suoraan proosana. Tästä monimutkaisuudesta pitäisi päästä eroon, mutta kuitenkin niin, että järjestelmään tallentuisi täsmällinen tieto, joka myös olisi käytettävissä myöhemmin. Arvelen, että tekoäly jossain muodossa olisi tässä mahdollinen ratkaisu: lääkäri voisi sanella vastaanoton jälkeen potilastapaamiseen liittyvät asiat, ja tekoäly tulkitsisi ja muodostaisi sanelusta rakenteisen datan, jonka lääkäri sitten vain tarkistaisi, ja se menisi tietokantaan."

Timo: Ihan mielenkiintoisia ajatuksia. Itse kyllä olen ajatellut, että rakenteinen tietokanta on hyvä lähestymistapa. Ja olettanut, että paremmalla suunnittelulla ne voitaisiin saada käytettävyydeltään hyviksi. Mutta. Minulla ei ole käytännön kokemusta niistä, enkä osaa varmuudella sanoa mitään.