Terveydenhuollon tietojärjestelmät: eväitä järkeviin hankintoihin. Näkökulmana käytettävyys

E-Hoito & Connected Health 2012 © Timo Jokela www.joticon.fiwww.joticon.fi

Terveydenhuollon tietojärjestelmät: eväitä järkeviin hankintoihin

Näkökulmana käytettävyys

Timo Jokela, FT, dos.Joticon Oy & Aalto yliopisto


Käytettävyyseminaari Oulu [email protected]

040-5118250

??


Timo Jokela

• Työhistoriaa– 1990-luvun alussa VTT:llä käyttöliittymien mallinnusta– 1995 Nokia Mobile Phones, käytettävyyspioneeri, ”paras projekti”– 1999 Oulun yliopisto, TOL (professori ma.)– 2007 -> Joticon Oy– Dosentti: Oulun yliopisto 2009, Helsingin yliopisto 2010

• Kehittänyt alan menetelmiä ja lähestymistapoja– käytettävyyden vaikuttavuustavoitteet, käyttäjätarpeiden ja

käytettävyysvaatimusten määrittäminen, prototypointi, käytettävyysarvioinnit, prosessimallit, käytettävyyskypsyysmallit, käytettävyysattribuutit, mittarit ja mittaaminen,

– Viime aikoina käytettävyys tietojärjestelmien hankinnoissa /tarjouspyynnöissä

– Kirja ”Navigoi oikein käytettävyyden vesillä”, blogit– 100+ julkaisua, eniten referoituja suomalaisten joukossa (Arnetminer

indeksi = 10)• Sovellusalat

– biologinen analysaattori, toiminnanohjausjärjestelmä, koulutusjärjestelmä, omahoitopalvelu, matkanhallinta, urheilu, kartta- ja navigointi, lupahallinto, kulunvalvonta, ilmoittautumisjärjestelmä, verkkosovellukset, laajat verkkosivut, CAD, hankehallinta,…

• ISO-standardointi (13407, 9241-210, 18529, 20282)• Kotimaiset ja kansainväliset verkostot

– KäytettävyysOSYn pj, TwinTide (Eur), UPA (USA), HCD-Net (Japani)


Timo aiheesta “Käytettävyys

tietojärjestelmien hankinnoissa”• Tekemisiä

– mukana useissa käytännön hankinnoissa– tutkinut n. 200 tarjouspyyntöä– kehittänyt ratkaisumalleja, pitänyt esityksiä,

tuottanut julkaisuja (HS, muut lehdet, blogit…), keskustelufoorumit (LinkedIn)

– kansainväliset tieteelliset julkaisut ja kirja• Avoimia asioita

– aidosti haastava asia, vaatii lisää caseja, lisää resursseja

– “muuttaa maailmaa”


Sidonnaisuudet• Toimeksiantoja julkisen sektorin kanssa

– Helsingin yliopisto, HUS, Oulun kaupunki, Oulun yliopisto, Pohjois-Pohjanmaan SHP, Senaatti Kiinteistöt, Sitra, TTL, Valvira, (muita?)

• Tutkijana Aalto-yliopistolla– määräaikainen, osapäiväinen (FlowIT –projekti)

• Toimeksiantoja yritysten kanssa– Useiden eri toimialojen yritysten kanssa

• rakennusyrityksen ERP -järjestelmät, CRM-järjestelmät, urheilusovellukset, navigointisovellukset, kiinteistöihin liittyvät hallintajärjestelmät, turvajärjestelmät, laajat verkkosivustot, pankit, tietoliikennesovellutukset,…

– Ei kuitenkaan yhdenkään terveydenhuollon tietojärjestelmätoimittajan kanssa (muistaakseni)


Sisältö

I. Julkisen hankinnan kulku ja käytettävyysII. Huomioita ApotistaIII. Miten käytettävyyttä ei kannata laittaa

tarjouspyyntöön? (esimerkkejä)– “hyvät uutiset”

IV. Miten käytettävyys olisi laitettava tarjouspyyntöön? (vähemmän esimerkkejä)

– “huonot uutiset”

V. Miten käyttäjät mukaan (ja miten ei)


1. Käytettävyys ja julkisen hankinnan kulku


Käytettävyys

”Mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta määrätyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja miellyttävästi” (ISO 9241-11)

Käytettävyys

= miten järjestelmä tukee käyttäjän työtä


Julkinen kilpailutus

Hankkija

Tarjouspyyntö

TarjouksetTarjoukset

Tarjoukset

Tilaus

toimitettu järjestelmä

3. Toimittajan valinta- kuka täyttää vähimmäisvaatimukset?- kuka saa eniten pisteitä?

2. Miten pärjäisin kilpailussa- täytän vähimmäis-

vaatimukset?- saisin hyvät pisteet?

1. Mitä haluan?- mitä ovat vähimmäisvaatimukset?- mitkä valintaperusteet (pisteytysperusteet)?

4. Miten täytän sen, minkä lupasin (mahd. hyvällä katteella?)

Toimittaja

Ratkaiseva asia: tarjouspyyntö

Järjestelmän ”valinta” on mekaaninen vaihe: 1. Karsi pois ne, jotka eivät täytä vähimmäisvaatimuksia2. Laske jäljelle jääneiden valintaperustepisteet yhteen3. Eniten pisteitä saanut voittaa


” Mikä on sähköisten

potilastietojärjestelmien

tarjouspyyntöjen

vähimmäisvaatimusten ja

valintaperusteiden määrittämisen

tilanne tänään”


Tarjouspyynnön keskeiset elementit

1. Vähimmäisvaatimukset (pakolliset vaatimukset)– mitä hankittavalta järjestelmältä vähintään

edellytetään• riittävä laatu

2. Valintaperusteet– millä perusteilla järjestelmä/ toimittaja valitaan

niiden joukosta, jotka täyttävät (ilmoittavat täyttävänsä) pakolliset vaatimukset

– perusteita• hinta• laatuominaisuuksia





Jos halutaan laatua,

päävalintakriteeri pitää olla

hinta!


Jos haluaa laatua, laatu pitää

laittaa vähimmäisvaatimuksiin

eikä vertailuperusteisiin


Miten hankinta pitäisi tehdä?

• Määritä, mitä haluat saavuttaa käytettävyydellä liiketoiminnassa

• Laita käytettävyys pakollisiin (vähimmäis-) vaatimuksiin• Määritä vaatimukset niin, että ne ovat

– todennettavia: vaatimuksen täyttyminen voidaan tarkistaa niin, että ei erimielisyyksiä vaatimuksen toteutumisesta

– valideja: vaatimuksen toteutuminen tarkoittaa oikeasti käytettävyyttä

– kattavia: riittävän laajalti koko järjestelmä• Määritä käytettävyyskriteerit perustuen käyttäjien

suoriutumiseen työstään• Hankintaprosessin aikana kohtele käyttäjiä ainoastaan

oman työnsä ammattilaisina• (Ja vältä kaikkea muuta!)


II. Apotti

Huomioita julkisesta keskustelusta


Terveydenhuollon ATK-päivät 5/2012

http://www.mylab.fi/fi/puheenvuoro/tietoj%C3%A4rjestelm%C3%A4n+uusimisen+tavoite+on+entist%C3%A4+parempi+k%C3%A4ytett%C3%A4vyys/


Terveydenhuollon ATK-päivätTällaiset käskyt periaatteessa

hyvää käytettävyysasiaa.

Mutta epätodennettavilla

vaatimuksilla ei ole mitään

merkittävyyttä kilpailutuksessa.









III Miten käytettävyttä EI kannata laittaa

tarjouspyyntöön?“Hyvät uutiset”


Esimerkki 1

Ensihoito-/ päivystysjärjestelmä



Ei-todennettavia ”vaatimuksia”

• eivät vaatimuksia lainkaan

Älä käytä! (vahingollista)


Osittain todennettavia mutta

• laatu kyseenalainen

• vain marginaalinen osa

käytettävyydestä

Älä käytä! (vahingollista)



- eivät pakollisia

- eivät käytännössä

todennettavia


Yhteenveto

• Mitä tarjouspyyntö edellytti käytettävyydeltä?– Ei yhtään mitään!– (ensihoito-/ päivystysjärjestelmä)

• Suositus– Älä ota mallia! (haitallista)


Esimerkki 2

Kotihoidon toiminnanohjaus



periaatteessa hyvää

• vaatimukset pakollisia

• aika moni todennettava

ongelmia• monet ei-todennettavat (eivät siis

vaatimuksia)

• todennettavatkaan eivät takaa

laatua• voidaan toteuttaa laaduttomasti

• marginaalinen osa

käytettävyydestä


Yhteenveto

• Mitä tarjouspyyntö edellytti käytettävyydeltä?– Ei yhtään mitään!



Esimerkki 3

Terveydenhuollon organisaation HR-järjestelmä




Käytettävyystestaus ei (eikä

muukaan aktiviteetti ) takaa

itsessään yhtään mitään

käytettävyydestä!


Standardit eivät takaa

käytettävyyttä!


Yhteenveto

• Mitä tarjouspyyntö edellytti käytettävyydeltä?– Ei yhtään mitään!



Esimerkki 4

Potilastietojärjestelmä




Käytettävyyden arviointi demojen

perusteella: Älä koskaan laita

käyttäjiä tekemään sellaista!

• maailma ei tunne sellaista

käytettävyysmenetelmää

• käyttäjät laitetaan tekemään

sellaista, johon heillä ei ole aidosti

kunnon edellytyksiä

• suuri riski siihen, että tulokset

eivät valideja


Yhteenveto

• Mitä tarjouspyyntö edellytti käytettävyydeltä?– Ei mitään!



Hyvät uutiset!

• Älä laita esimerkkien tapaisia vaatimuksia tarjouspyyntöihin– yleensä kaikki epätodennettavat “Järjestelmän on

oltava helppokäyttöinen” –tyyppiset vaatimukset– ei johdantoon– “standardeja oltava noudatettu”– “suunnittelusääntöjä oltava noudatettu”– “käytettävyystestejä on oltava tehty” – käyttäjien tekemät demojen katselmoinnit/ pisteytykset– jne.

• Hyvä uutinen: pääset vähemmällä (säästät turhaa työtä)


Haitallista?

• väärää mielenrauhaa…


IV Miten käytettävyys olisi laitettava

tarjouspyyntöön? “Huonot uutiset”


Ratkaisuperiaatteet• Määritä, mitä haluat saavuttaa käytettävyydellä

liiketoiminnassa• Laita käytettävyys pakollisiin (vähimmäis-) vaatimuksiin• Määritä vaatimukset niin, että ne ovat







Oikean suuntaista

• perustuu käyttäjien

suoriutumiseen

Ongelmallista

• epätarkkoja, ei todennettavia



Hyvää• perustuu käyttäjien

suoriutumiseen

• vähimmäisvaatimuksia

käytettävyydelle

määriteltyOngelmallista

• määrällinen käytettävyystestaus

demoilla ei anna valideja tuloksia!

• epätarkasti määritelty


Ratkaisuperiaatteet• Määritä, mitä haluat saavuttaa käytettävyydellä

liiketoiminnassa• Laita käytettävyys pakollisiin (vähimmäis-) vaatimuksiin• Määritä vaatimukset niin, että ne ovat







Käyttäjien suoriutumiseen perustuvat vaatimukset

(todennettavat, validit, kattavat)• Määritä käyttäjien työ

– aikaansaannokset, jotka käyttäjien pitäisi saavuttaa– riittävän kattavasti

• Määritä oleelliset käytettävyysmittarit suhteessa käyttäjien työhön

– missä määrin käyttäjät saavuttavat oikeat aikaasaannokset hankittavalla järjestelmällä? (tuloksellisuus)

– missä määrin käyttäjät tarvitsevat resursseja (aikaa) tavoitteisiin päästäkseen? (tehokkuus)

– mikä on subjektiivinen käyttäjätyytyväisyys? (miellyttävyys)

• Määritä halutut tavoitetasot


Esimerkki: Oulun omahoitopalvelu

Käyttäjätehtävä- ja aikaansaannosmääritykset• 63-sivuinen

dokumentti


Esimerkki: Oulun omahoitopalvelu

Mittari ja tavoitetaso


Esimerkki: Oulun omahoitopalvelu/mittausinst

rumentti

Mittausinstrumentti


“Huonot uutiset”

• Kaikki edellä mainitut aktiviteetit – vaativia– eivät kuulu järjestelmäkehityksen

perinteeseen, puuttuu koeteltuja ratkaisuja• Lisäksi eri hankintatilanteet erilaisia

– asiakaskohtainen järjestelmä– asiakaskohtaisesti sovitettava järjestelmä– valmisohjelmisto

• ”Muuta maailmaa”– 90% käytettävyystyöstä ennen tarjouspyyntöä


V. Miten käyttäjät mukaan tuloksellisesti ja eettisesti

oikein?


Käyttäjien osallistamisen periaatteet

• käyttäjien oikea rooli on olla oman työnsä/ ammattinsa asiantuntija– niin sisällöllisesti kuin eettisestikin– eikä muuta

• käyttäjien vääriä rooleja ovat– vastuuttaa vaatimuksista tai

suunnitteluratkaisuista – laittaa rooleihin, joihin heillä ei ole aidosti

valmiuksia – laittaa rooleihin, jotka menevät ohi heidän

ammatillisen työnkuvansa


Käyttäjille asetettuja vääriä rooleja

• pyydetään esittämään vaatimuksia järjestelmälle• pyydetään jäsentämään analyyttisesti omaa

työtään• pyydetään katselmoimaan ja kommentoimaan

käyttöliittymiä, tai kertomaan mielipiteensä niistä• pyydeetään pisteyttämään käyttöliittymät

demojen perusteella• toimenpiteet, joilla käyttäjiä vastuullistetaan

vaatimuksista valinnoista tai suunnitteluratkaisuista

• …


• Katselmoinnit käytettävyyden

vihollinen nro 1 (ja niihin liittyen

rautalankamallit)

• Yhtä yleinen vihollinen ehkä

käyttötapaukset…


Käyttäjien kaksi OIKEAA roolia

1. kertoa omasta työstään, olla havainnoitavana työssään– mutta työn jäsentäminen EI ole käyttäjän tehtävä!

2. olla testihenkilönä käyttämässä järjestelmää/ sen prototyyppiä– käytettävyystesteissä– testien keskeiset tulokset perustuvat

suunnittelutiimin tekemiin mittauksiin, analyyseihin ja johtopäätöksiin• ei käyttäjien mielipiteisiin• käyttökokemusta voidaan mitata


EIKÄ OLISI

PITÄNYTKÄÄN!


Yhteenveto

• Kilpailutuksessa tarjouspyyntö keskeinen– 90% käytettävyystyöstä ennen tarjouspyyntöä

• Käytettävyys (ja laatu yleensäkin) vähimmäisvaatimuksiin– ainoa validi kriteeri: käyttäjien suoriutuminen– käytäntöön vieminen todellinen haaste

• Käyttäjien oikea rooli oman työnsä asiantuntija– älä laita rooleihin, joihin heillä ei aidosti ole

valmiuksia


Lisää tietoa

• Navigoi oikein käytettävyyden vesillä (kirja + Fcebook-sivut)– https://www.facebook.com/kaytettavyyskirja

• Blogit– http://kaytettavyysnavigoija.blogspot.com/– http://hankikaytettavyytta.blogspot.com/

• Julkaisuja– www.joticon.fi – Esitysten kalvoja

• KäytettävyysOSY (LinkedIn-ryhmä)

https://www.facebook.com/kaytettavyyskirja

http://kaytettavyysnavigoija.blogspot.com/

http://hankikaytettavyytta.blogspot.com/

http://www.joticon.fi/


Kiitos!

Kysymyksiä, kommentteja?

Technology

Terveydenhuollon tietojärjestelmät: eväitä järkeviin hankintoihin. Näkökulmana käytettävyys