Kohti suunnitelmallisia muutoksia

Transkriptio

1 KUOPION YLIOPISTON SELVITYKSIÄ E, YHTEISKUNTATIETEET 39 KUOPION UNIVERSITY OCCASIONAL REPORTS E. SOCIAL SCIENCES 39 Marika Toivanen, Irmeli Luukkonen, Anneli Ensio, Heidi Häkkinen, Pauliina Ikävalko, Juho Jaatinen, Liisa Klemola, Maritta Korhonen, Susanna Martikainen, Merja Miettinen, Anja Mursu, Päivi Röppänen, Ritva Silvennoinen, Tuula Tuomainen ja Marilla Palmén Kohti suunnitelmallisia muutoksia Opas terveydenhuollon tietojärjestelmien toimintalähtöiseen kehittämiseen

2

3 KUOPION YLIOPISTON SELVITYKSIÄ E, YHTEISKUNTATIETEET 39 KUOPION UNIVERSITY OCCASIONAL REPORTS E. SOCIAL SCIENCES 39 Marika Toivanen, Irmeli Luukkonen, Anneli Ensio, Heidi Häkkinen, Pauliina Ikävalko, Juho Jaatinen, Liisa Klemola, Maritta Korhonen, Susanna Martikainen, Merja Miettinen, Anja Mursu, Päivi Röppänen, Ritva Silvennoinen, Tuula Tuomainen ja Marilla Palmén Kohti suunnitelmallisia muutoksia Opas terveydenhuollon tietojärjestelmien toimintalähtöiseen kehittämiseen Tietojenkäsittelytieteen laitos Shiftec-tutkimusyksikkö HIS-tutkimusyksikkö Kuopion yliopisto Savonia Business Savonia-ammattikorkeakoulu KUOPIO 2007

4 Myynti: Kuopion yliopiston kirjasto PL 1627 FI KUOPIO Puh Fax Sarjan toimittajat: Jari Kylmä, FT Hoitotieteen laitos Markku Oksanen, VTT Sosiaalipolitiikan ja sosiaalipsykologian laitos Tekijän osoite: Marika Toivanen Tietojenkäsittelytieteen laitos Kuopion yliopisto PL 1672 FI KUOPIO Puh ISBN ISBN (PDF) ISSN Kopijyvä Kuopio 2007 Finland

5 Toivanen, Marika et al. Toward planned changes. Guide to the activity-driven development of health information systems. Kuopio University occasional reports E. Social sciences p. ISBN ISBN (PDF) ISSN Abstract Health care professionals need detailed information about patients as easily and quickly as possible to support their work. The delicate information of patients has to be faultless, and it requires strong data protection and patient assent for use of the information. In order for information systems and software to support work activity, analysts and designers have to understand the work activity of the people using their systems. The objective of the group of the ZipIT projects (ZipIT, ZipIT-ojo and ActAD-HIS), organized jointly by the University of Kuopio and Savonia University of Applied Sciences, is to narrow the distance between different worlds of work improvement and information system development. It was made by developing the model for activity-driven development of health information systems. With that model, it is possible to see the subject of development in context and effects of planned changes. The activity-driven information system development (ISD) model is made for health care organizations to specify needs and requirements for information systems. According to the activity-driven ISD model, the successful development presumes that the needs and the goal state of the system so that both software engineers and health care professionals can understand future systems in the same way. After all of that, it is possible to plan how to realize the goal state. Usually the development project needs information about the ensemble of the organization, even between several organizations, information about everyday staffer. The activity-driven ISD model is based on activity theory and pilot cases made during the ZipIT projects. In pilot cases, made in close cooperation with our partners, we explored, tried out, and developed various methods of activity theory, computer science, software engineering, and user interface and interaction design. Altogether there were ten pilot cases with different aims related, for example, to exploration of information needs in work activity, development of the new software product, selecting of the existing software, or changes in work activity caused by implementation of the new software. The work in the pilot projects are premised on the basis of existing methods of development and the revising and adapting of them. The research health information system development. As a conclusion it can be said that the activity-driven approach was an effective way to analyze complex work-activity and diverse elements of it. Medical Subject Headins (MeSH): Medical Informatics; Information Systems; Health Care Sector; Models; theoretical

6

7 Toivanen, Marika et al.. Kohti suunnitelmallisia muutoksia. Opas terveydenhuollon tietojärjestelmien toimintalähtöiseen kehittämiseen. Kuopion yliopiston selvityksiä E. 39. Yhteiskuntatieteet s. ISBN ISBN (PDF) ISSN Tiivistelmä Terveydenhuollon henkilöstö tarvitsee työnsä tueksi yksityiskohtaisia tietoja asiakkaistaan mahdollisimman helposti ja nopeasti. Nämä tiedot ovat usein arkaluonteisia ja edellyttävät siksi vahvaa tietosuojaa, tietojen virheettömyyttä ja asiakkaan suostumusta tietojen käyttämisestä. Jotta tietojärjestelmät ja tietotekniikka tukisivat työtoimintaa, järjestelmien suunnittelijoiden on ymmärrettävä tuotteidensa käyttäjien työtoimintaa. Kuopion yliopiston ja Savonia-ammattikorkeakoulun yhteisessä ZipIT-hankekokonaisuudessa laadittiin toiminnan ja tietojärjestelmien yhtäaikaista kehittämistä varten toimintalähtöinen tietojärjestelmien kehittämismalli, jonka avulla erilaisissa terveydenhuollon tietojärjestelmähankkeissa voidaan nähdä kehittämiskohteen sijoittuminen kontekstiinsa ja suunniteltujen muutosten vaikutukset. Mallin avulla voidaan suunnitella ja toteuttaa työn ja tietojärjestelmien kehittämiseen tähtääviä selvitys- ja vaatimusmäärittelytöitä. Toimintalähtöisen tietojärjestelmien kehittämismallin mukaan työtoimintaa onnistuneesti palveleva kehittäminen edellyttää nykytilan analysoimista kehittämistarpeiden tunnistamiseksi ja tavoitetilan suunnittelemista ja mallintamista niin, että kaikki osapuolet voivat ymmärtää kehittämistyön vaikutukset omaan työhönsä. Vasta sen jälkeen voidaan ryhtyä laatimaan käytännön suunnitelmaa siitä, miten tuo tavoite saavutetaan. Toisaalta kehittämishankkeen aikana asioita joudutaan usein tarkastelemaan monelta eri tasolta: kehittämistyöllä voi olla vaikutuksia koko organisaation ja jopa organisaatioiden rajat ylittävään toimintaan, päivittäistä työtä yhdessä tekevien ammattilaisten yhteistyöhön ja kunkin yksittäisen työntekijän työhön. Toimintalähtöinen tietojärjestelmien kehittämismalli perustuu toiminnan teoriaan ja ZipIThankekokonaisuuden aikana tehtyihin pilotteihin, joissa kokeiltiin, tutkittiin ja kehitettiin erilaisia toiminnan teorian, tietojärjestelmätieteen, ohjelmistotuotannon ja käyttöliittymäsuunnittelun menetelmiä yhteistyössä hankkeeseen osallistuneiden organisaatioiden kanssa. Mukana oli kaikkiaan kymmenen pilottikohdetta, joissa tehty työ liittyi esimerkiksi työtoiminnan tiedontarpeiden kartoittamiseen, uuden ohjelmiston suunnitteluun, valmiin ohjelmiston valitsemiseen tai käyttöönottoon liittyvään työtoiminnan kehittämiseen. Lähtökohtana olivat olemassa olevat menetelmät ja niiden muokkaaminen, kehittäminen ja täydentäminen. Tehty tutkimus oli luonteeltaan pääasiassa toimintatutkimusta, jossa käytännön kehityshankkeesta hankittuja kokemuksia käsitteellistämällä ja analysoimalla kehitettiin toimintalähtöistä menetelmää terveydenhuollon tietojärjestelmien suunnittelua varten. Pilottikohteet olivat varsin vaihtelevia sekä sisällöiltään että tavoitteiltaan, mutta yhteisenä johtopäätöksenä voidaan pitää sitä, että tässä toimintalähtöinen lähestymistapa auttoi jäsentämään kokonaisuutta ja siihen liittyviä osatekijöitä. Yleinen suomalainen asiasanasto: tietojärjestelmät; terveydenhuolto; kehittäminen; mallit; toimintatutkimus; toiminnan teoria

8

9 Esipuhe Tässä oppaassa esitellään toimintalähtöinen tietojärjestelmien kehittämismalli, joka on tarkoitettu sovellettavaksi erilaisissa terveydenhuollon tietojärjestelmien ja tietoteknisesti tuetun työtoiminnan kehittämishankkeissa. Sen tavoitteena on yhdistää terveydenhuollon ammattilaisten ja tietojärjestelmien suunnittelijoiden ja kehittäjien osaamista. Opasta kirjoitettaessa on ajateltu erityisesti niitä terveydenhuollon organisaatioiden tietohallinnon tai kehittämisyksiköiden edustajia, jotka asettavat ja vetävät tietojärjestelmien kehittämis- tai käyttöönottohankkeita. Kehittämismallin avulla voidaan kuvata ja analysoida tietoteknisesti tuetun toiminnan nykytila ja tunnistaa tiedonkulun ongelmakohtia, määritellä ja mallintaa tavoitetila ja suunnitella sen saavuttamiseksi tarvittavia konkreettisia toimenpiteitä. Oppaan ensimmäisessä luvussa määritellään tietoteknisesti tuetun työtoiminnan ja tietojärjestelmien kehittämisen näkökulmasta keskeisiä käsitteitä. Toisessa luvussa käydään läpi kehittämismallin teoriatausta ja itse malli vaihe vaiheelta. Kolmannessa luvussa esitellään kehittämisessä tarpeellisia tiedonkeruun, analysoinnin ja kuvaamisen menetelmiä ja neljännessä luvussa kerrotaan esimerkkejä kehittämismallin soveltamisesta omissa tutkimuskohteissamme. Tämä opas on tarkoitettu käytännön kehittämistyön avuksi. Tutkimukselliset tulokset on raportoitu erikseen. Terveydenhuollon toiminnan ja tietojärjestelmien rinnakkaista kehittämistä tutkivassa ZipIT-hankekokonaisuudessa ( ) on jatkettu aikaisemmissa tutkimushankkeissa aloitettua työtoiminnan tutkimuksen ja kehittämisen ActAD-mallin (Activity Analysis and Development) työstämistä. Se on muotoutumassa tässä oppaassa esiteltäväksi kehittämismalliksi. Kehittämismalli perustuu toiminnan teoriaan, ActAD-malliin ja ZipIT-hankekokonaisuuden aikana tehtyyn kymmeneen pilottiin, joissa kokeiltiin, tutkittiin ja kehitettiin erilaisia toiminnan teorian, tietojärjestelmätieteen, ohjelmistotuotannon ja käyttöliittymäsuunnittelun menetelmiä yhteistyössä hankkeeseen osallistuvien organisaatioiden kanssa. Hallinnollisesti ZipIT-hanke on jakautunut kolmeen osahankkeeseen: ZipIT: Toiminnan ja tietojärjestelmien rinnakkaisen kehittämisen vetoketjumalli (Tekes 40426/04, 40354/05, 40252/06), ZipIT-ojo: Toiminnan ja tietojärjestelmien rinnakkainen kehittäminen, prosessien organisointi ja johtaminen (Tekes 790/04, 644/05, 644/06) sekä ActAD-HIS: Toimintalähtöisen vaatimusmäärittelyn menetelmät: Työn, tietojärjestelmien ja ohjelmiston rinnakkain kehittäminen terveydenhuollossa (TSR ). Oppaan kirjoittamiseen on lisäksi osallistunut Työsuojelurahaston rahoittama Äippä-hanke, Terveydenhuollon työntekijät ja tiedonhallinnan muutos - Arjen valtaistaminen äitiyshuollossa (TSR ). Hankekokonaisuutta ovat rahoittaneet ja siihen ovat osallistuneet Tekesin FinnWell-ohjelma, Työsuojelurahasto, Helsingin ja Uudenmaan sairaanhoitopiirin kuntayhtymä, Pohjois- Savon sairaanhoitopiirin kuntayhtymä, Kainuun maakunta -kuntayhtymä, Kuopion kaupungin sosiaali- ja terveyskeskus, AtBusiness Communication Oyj, FD Systems Oy, Intensium Oy, Suomalainen lääkäriseura Duodecim, Mawell Oy, Medici Data Oy ja Oy ProWellness Ltd.

10 Kiitämme projektiin osallistuneita ja oppaan eri versioita kommentoineita hedelmällisestä yhteistyöstä sekä hyvistä ideoista ja näkökulmista. Lisäksi kiitämme arvokkaista kommenteista tutkimuspäällikkö Hannele Hyppöstä ja projektipäällikkö Jarmo Kärkeä, molemmat Stakesin sosiaali- ja terveysalan tietoyhteiskuntayksiköstä. Kuopiossa toukokuussa 2007, Tekijät

11 Sisällysluettelo 1 JOHDANTO Tietojärjestelmät suomalaisessa terveydenhuollossa Tietoteknisesti tuettu työtoiminta Osallistuminen kehittämiseen Tietojärjestelmän kehittäminen Käyttäjätarpeet ja vaatimusmäärittely Arkkitehtuurit 16 2 Toimintalähtöinen tietojärjestelmien kehittämismalli Teoriatausta Kehittämismalli Vaiheet Tasot Miten aloitan? Toiminta- ja tietokokonaisuuksien taso Yhteinen käsitys toiminta- ja tietokokonaisuuksien nykytilasta Yhteinen käsitys toiminta- ja tietokokonaisuuksien tavoitetilasta Suunnitelma konkreettisista toimenpiteistä toiminta- ja tietokokonaisuuksien tasolla Työnkulkujen ja tietovirtojen taso Yhteinen käsitys työnkulkujen ja tietovirtojen nykytilasta Yhteinen käsitys työnkulkujen ja tietovirtojen tavoitetilasta Suunnitelma konkreettisista toimenpiteistä työnkulkujen ja tietovirtojen tasolla Työtehtävien ja tietovälineiden taso Yhteinen käsitys työtehtävien ja niissä tarvittavien tietovälineiden nykytilasta ja kehittämistarpeista Yhteinen käsitys työtehtävien ja niissä tarvittavien tietovälineiden tavoitetilasta Suunnitelma konkreettisista toimenpiteistä työtehtävien ja tietovälineiden tasolla 35 3 Tiedonkeruu, analysointi ja kuvaaminen Kehittämistyön eri vaiheissa käytettävät menetelmät Nykytilan selvittäminen ja analysointi Tavoitetilan ideointi ja suunnitteleminen Konkreettisten toimenpiteiden suunnitteleminen Tutustumiskäynnit ja havainnointi Haastattelut 42

12 3.4 Työpajat ja ryhmätyöt Toimintatarina Seinätekniikka Rikastetut kuvat ja kaaviot Käyttötapaukset Käyttöliittymäkuvat ja -kuvasarjat Jäljitettävä mallinnusketju 55 4 Kokemuksia kehittämismallin soveltamisesta Hoitopalaute Röntgen Lääkehoidon sähköisen suunnittelun ja kirjaamisen kehittäminen Sähköisen potilastietojärjestelmän käyttöönotto Kotihoidon mobiilisovellus Teknologialla muutosta kotihoidon toimintaprosesseihin Toimenpidejärjestelmän hankinta ja uusiminen Käypä hoito -selvitys Selvitys silmänpohjakuvantamisesta Toimintalähtöinen tiedonhallinnan muutostuki Yhteenveto pilottikokemuksista 77 Lähdeluettelo Liite 1: Esimerkki ActAD-elementeistä johdetusta teemahaastattelulomakkeesta 81 Liite 2: Esimerkki osallistujien valinnasta ja roolien määräämisestä 83 Liite 3: Esimerkkipolut 84 Liite 4: Hankkeen aikana tuotetut julkaisut 86 Opinnäytteet 86 Kansainväliset artikkelit ja konferenssiesitykset 86 Kansalliset tieteelliset ja ammatilliset artikkelit sekä konferenssiesitykset 87 Selvitykset 88 Muut julkaisut 88

13 11 1 JOHDANTO Terveydenhuollon henkilöstö tarvitsee työnsä tueksi yksityiskohtaisia tietoja asiakkaistaan mahdollisimman helposti ja nopeasti. Tietojen pitäisi olla hoitoon osallistuvien käytössä aina oikeassa paikassa oikeaan aikaan. Toisaalta asiakkaiden hoitoon tai palveluun liittyvä tieto on arkaluontoista, ja sen käyttö edellyttää vahvaa tietosuojaa, tietojen virheettömyyttä ja lain ja asetusten mukaisesti asiakkaan suostumusta siitä, että hänen tietojansa käytetään. Jotta tietojärjestelmät ja tietotekniikka tukisivat työtoimintaa, tietojärjestelmien suunnittelijoiden on ymmärrettävä ohjelmistotuotteidensa käyttäjien työtä. Käyttäjillä puolestaan tulee olla keinoja osoittaa kehittämistarpeita. Terveydenhuollon ohjelmistojen suunnitteluun, käyttöönottoon ja käyttöön liittyy myös monia ristiriitaisia tavoitteita ja vaatimuksia (Gregory 2000, 1 25). Terveydenhuollon ja ohjelmistoalan ammattilaisten yhteistä kehittämisen työvälinettä tarvitaan. Terveydenhuollossa kehittämistoimintaa tehdään tilannekohtaisesti monella eri tavalla. Tutkimuksen mukaan julkisen sektorin tietojärjestelmähankinnoissa on puutteita hankinta- ja määrittelyosaamisessa (Sihvola 2006). Organisaatioista puuttuu kokemusta ja tietoa siitä, kuinka esimerkiksi tietojärjestelmien käyttöönottoprojekti viedään läpi ja mitä kaikkea olisi osattava ottaa huomioon sitä toteutettaessa tai siihen osallistuttaessa. Tietoa ei myöskään ole siitä, mitä mahdollisuuksia tietojärjestelmän kehittäminen tuo työn uudelleenorganisointiin. Vastaavasti ohjelmistotaloille on haasteellista kehittää terveydenhuoltoa aidosti tukevia ohjelmistoja. Tässä oppaassa tutkimusryhmä määrittelee ohjelmiston, tietojärjestelmän ja työtoiminnan suhteen niin, että ohjelmisto on osa tietojärjestelmää ja tietojärjestelmä osa työtoimintaa (kuva 1, vasen puoli). Työtoiminta on tavoitteellista toi- työtoiminta Ohjelmistotuotanto Tietojärjestelmän kehittäminen Työn kehittäminen Työn kehittäminen Tietojärjestelmän kehittäminen ohjelmisto(t) tietojärjestelmä Ohjelmistotuotanto Työtoiminta pitää sisällään tietojärjestelmän ohjelmistoineen. Silti niiden kehittäminen tapahtuu usein erillään. Tavoitteena on, että kehittämistä tehtäisiin rinnakkain eri osa-alueet huomioon ottaen. KUVA 1. Tutkimusryhmän määritelmä: työtoiminta sisältää tietojärjestelmän, joka sisältää ohjelmistot. Siksi näitä pitää kehittää yhteisesti.

14 12 mintaa jonkin yhteisen päämärän saavuttamiseksi. Tietojärjestelmällä tarkoitetaan kaikkia niitä elementtejä, jotka yhdessä varmistavat oikean tiedon saatavuuden oikeaan paikkaan oikeaan aikaan. Esimerkiksi tietoverkko, ohjelmistot, tietokoneet, työntekijät, muistiot, ilmoitustaulu, kännykät, potilaskansiot ja viestivihkot voivat muodostaa tietojärjestelmän. Ohjelmisto on tiettyyn tiedonkäsittelytarpeeseen tehty tietokoneella pyörivä ohjelma ja siihen liittyvä dokumentaatio. Vaikka ohjelmisto, tietojärjestelmä ja työtoiminta ovatkin keskenään sidoksissa, niiden kehittäminen tapahtuu useimmiten erillään. Kun pyritään tietoteknisesti tuetun työtoiminnan kehittämiseen, pitäisi tarkastella ohjelmistoja, tietojärjestelmää ja työtoimintaa osittain yhtä aikaa ja toinen toisensa huomioiden, koska niillä on yhteisiä osia (kuva 1, oikea puoli). Tässä oppaassa esitellään toimintalähtöinen tietojärjestelmien kehittämismalli, jonka avulla terveydenhuollon tietojärjestelmien kehittämishankkeissa nähdään kehittämiskohteen sijoittuminen ja muutoksen vaikutukset. Kehittämismalli on tarkoitettu erityisesti tukemaan palveluorganisaatioiden oman toiminnan suunnittelua ja sitä tukevien tietojärjestelmien vaatimusmäärittelyä, tilaamista ja hankkeiden suunnittelua. Lähtökohtana on tietojärjestelmän kehittäminen siten, että huomioidaan ympäröivä työtoiminta ja pyritään kehittämään tietojärjestelmää ja työtä yhtäaikaisesti siten, että ne tukevat toinen toisiaan. Tällainen tilanne käynnistyy useimmiten ohjelmistoja uusittaessa. Jos tietojärjestelmä muuttuu, muutoksia tulee väistämättä myös toimintatapoihin. Jos työ muuttuu, tietojärjestelmän on mukauduttava uusiin tarpeisiin. Nykyään tämä muutos on usein hal- litsematon : esimerkiksi uuden ohjelmiston aiheuttamia muutoksia työhön mietitään vasta sitten, kun ohjelmat on asennettu ja niitä pitäisi käyttää. ZipIT-hankekokonaisuudessa saatujen erilaisten pilottikokemusten pohjalta tähän oppaaseen on koottu kehittämismalli, joka hahmottaa muutostilanteissa tunnistettavia ja huomioitavia tekijöitä. Malli tukee myös kehittämistyöhön osallistumista ja antaa siten useille toimijoille mahdollisuuden vaikuttaa kehitteillä olevaan muutokseen ennen sen toteuttamista. Tämä opas pyrkii tarjoamaan eväitä henkilölle, jolla on edessään tietojärjestelmän kehittämishankkeen läpivieminen tai sellaiseen osallistuminen. Opas ei tarjoa valmiita reseptejä projektin läpiviemiseen. Projektioppaita, joissa kerrotaan projektien läpiviemisestä, aikatauluttamisesta ja resurssien suunnittelusta, on useita (mm. Pelin 2002; Ruuska 1999, 2006; Silfverberg 2001; Virtanen 2000). Tämä opas auttaa työn ja tietojärjestelmän yhtäaikaisen kehittämisen suunnittelussa. Lukijalle tarjotaan uusia näkökulmia ja muistilistoja kehittämisprojektissa huomioon otettaviin asioihin. Seuraavaksi käsitellään oppaan lähtökohtana olevia asioita ja keskeisiä käsitteitä. Luvussa 2 esitellään toimintalähtöinen tietojärjestelmien kehittämismalli aloittaen teoriataustasta. Lukuun 3 on koottu toimintalähtöistä tietojärjestelmien kehittämistä tukevia työtapoja ja tiedonkeruun, analysoinnin ja kuvaamisen menetelmiä, jotka perustuvat tutkimushankkeen aikana saatuihin kokemuksiin. Lukuun 4 on koottu kokemuksia kehittämismallin soveltamisesta erilaisissa terveydenhuollon organisaatioissa läpiviedyistä kehittämishankkeista.

15 Tietojärjestelmät suomalaisessa terveydenhuollossa Tietojärjestelmien kehittämiseen terveydenhuollossa vaikuttavat useat tekijät. Lainsäädännöllä ohjeistetaan tietojen käyttöä, luovutusta, tietosuojaa sekä asiakkaan ja henkilökunnan oikeuksia. Myös palvelujärjestelmän muutokset, uudet hoitokäytännöt sekä toiminnan seuraamisen velvoitteet on huomioitava kehittämistyössä (Laki potilaan asemasta ja oikeuksista 785/1992, Laki terveydenhuollon ammattihenkilöistä 559/1994, Laki viranomaisten toiminnan julkisuudesta 621/1999, Sosiaali- ja terveysministeriön asetus potilasasiakirjojen laatimisesta sekä niiden ja muun hoitoon liittyvän materiaalin säilyttämisestä 99/2001). Järjestelmien kehittäminen yksittäisen asiakasorganisaation ja tietojärjestelmän toimittajan yhteistyöstä on laajentunut usean asiakkaan ja toimittajan väliseksi kehittämistyöksi. Myös kansallista julkista rahoitusta ohjataan tänä päivänä laajoihin kehittämisprojekteihin. (Sosiaali- ja terveysministeriö 2002, Sosiaali- ja terveysministeriö 2004.) Kehittämistyö keskittyy sähköisen potilaskertomuksen ympärille. Vuonna 2004 laaditun selvityksen mukaan sähköinen potilaskertomusjärjestelmä oli käytössä erikoissairaanhoidossa 13 sairaanhoitopiirissä (N=21). Lisäksi kolmessa sellainen oli kokeiluvaiheessa ja viidessä suunnitteluvaiheessa. Perusterveydenhuollossa sähköinen terveyskertomus oli käytössä 93,6 % terveyskeskuksista. Kysymyksiin vastasi 100 % sairaanhoitopiireistä ja 69,2 % terveyskeskuksista. (Kiviaho, Winblad & Reponen 2004.) Kehittämistyön tavoitteena on aikaansaada laajalti käyttökelpoisia tietojärjestelmiä potilaan hoitamisen, toiminnan ohjauksen, tilastoinnin ja raportoinnin avuksi. Järjestelmiltä edellytetään yhä laajempien toimintakokonaisuuksien kattamista. Käytännön toiminnassa (esim. potilastietojen kirjaus) tuotettua tietoa edellytetään hyödynnettäväksi toiminnan ohjauksessa (esim. johtajan tietovarasto) kerran kirjattavan tiedon perustetta noudattaen. Toiminnan seurannan tietojen erillisestä työstämisestä toivotaan päästävän kertaalleen kirjatun tiedon hyödyntämiseen eri tarkoituksessa. Jotta tietoja voitaisiin käyttää useampaan tarkoitukseen tai useammassa organisaatiossa esimerkiksi alueellisten järjestelmien kautta, tulee mm. potilaskertomuksen tietosisällöissä käyttää kansainvälisesti sovittuja normeja ja standardeja, kuten ISO-standardia. Kansallisessa terveyshankkeessa on tavoitteena, että Suomessa käytössä olevissa potilaskertomuksissa hyödynnetään ydintietoja eli yhdenmukaisesti määriteltyjä rakenteisia tietoja, jolloin kirjaaminen edellyttää standardoitujen termistöjen käyttöä. (Häyrinen, Porrasmaa, Komulainen & Hartikainen 2004.) Potilaskertomustiedon yhtenäistäminen ja käytön lisääminen sekä organisaatioiden sisällä että organisaatioiden välillä on edellytys hoitoketjujen joustavalle toteutumiselle. Tietojärjestelmien lisääntyvä toiminnallisuuden vaatimus on vaikuttanut ohjelmistojen vaatimusmäärittelyiden merkityksen korostumiseen, ja erityisesti järjestelmien käyttäjien mukaanotto toimintaa tukevien järjestelmien aikaansaamiseksi on välttämätöntä. Toisaalta, jotta tietotekniikan ja tietojärjestelmien käyttöönotosta voidaan saada varsinaista hyötyä, tarvitaan muutoksia toimintaprosesseissa Tietoteknisesti tuettu työtoiminta Työtoiminta on systeeminen kokonaisuus, joka koostuu jonkun yhteisen kohteen ja päämäärän parissa työskentelevästä joukosta ihmisiä. Nämä ihmiset eivät välttämättä työskentele samaan aikaan tai samassa paikassa he eivät aina edes tiedä toistensa olemassaolosta. Esimerkiksi odottavaa äitiä palvelee raskauden eri vaiheissa joukko eri organisaatioiden palveluksessa olevia, eri koulutuksen saaneita ja eri toimipisteissä työskenteleviä ihmisiä. Tietoteknisesti tuettua työtoiminta on silloin, kun työn tekemisessä käytetään tietoteknisiä välineitä tai palveluja. Tällaisia välineitä voivat olla esimerkiksi erilaiset työvälineohjelmat, tietoverkot ja niiden palvelut. Parhaimmillaan väline toimii varsinaisen työtehtävän apuna eikä välineen käyttö vaadi ylimääräistä ponnistelua. Tällöin työntekijä voi keskittyä varsinaiseen työ-

16 14 tehtäväänsä. Tietoteknisesti tuettu työtoiminta on käsitteenä laajempi kuin tietokoneavusteinen työskentely, josta ryhdyttiin puhumaan 1980-luvulla, kun tietokoneiden käyttö erilaisissa tehtävissä alkoi yleistyä. Sillä tarkoitettiin tietokoneiden käyttämistä työvälineenä vanhojen, manuaalisten välineiden sijaan. Esimerkiksi insinööri tai arkkitehti työskenteli tietokoneavusteisesti käyttäessään tietokonetta suunnittelun apuvälineenä sen sijaan, että olisi piirtänyt suunnitelmansa tusseilla kuultopaperille piirustuspöydän ääressä. Nyt tietokoneista ja -verkoista on tullut osa lähes kaikkien ammattialojen työvälineitä. Käytön ja käyttöympäristöjen ymmärtäminen on se tekijä, joka erottaa menestyneet teknologiaprojektit epäonnistuneista. Jo 1970-luvulla tehtiin tutkimus, jossa vertailtiin satoja onnistuneita teknologiaprojekteja epäonnistuneisiin ja huomattiin, että ainoat merkittävät erot olivat käyttäjien tarpeiden ymmärtämisessä ja projektien sisäisen kommunikaation laadussa. (Esim. Coombs, Saviotti & Walsh 1987.) ZipIT-hankekokonaisuudessa saatujen kokemusten ja muiden suomalaisten tutkimusten mukaan (Miettinen, Hyysalo, Lehenkari & Hasu 2003) käytön ymmärtäminen on yhä tuotekehityksen heikoin lenkki Osallistuminen kehittämiseen Kun terveydenhuollon organisaatiossa päätetään kehittämistoiminnan käynnistämisestä, on kehittämiseen osallistuvien henkilöiden valinta, osallistaminen ja sitouttaminen tärkeää. Jos työntekijät eivät ole sitoutuneita uuden ohjelmiston käyttöön, ei siitä saada suunniteltuja hyötyjä. Organisaation toimijoilla itsellään on arvokasta tietoa toiminnan kehittämiseksi (Lumijärvi 1994, McDonagh & Coghlan 2001). Sosiaali- ja terveydenhuollon henkilöstöstä suurin osa haluaa yleensä olla mukana aktiivisesti kehittämässä omaa työtään (Elovainio & Lindström 1993). Tietojärjestelmän kehittämisen tuomaan muutokseen on helpompi sitoutua, kun on ollut sitä itse suunnittelemassa. Yleensäkin vaikutusmahdollisuus oman työn kehittämiseen motivoi työntekijöitä. Tietojärjestelmien kehittäminen johtaa muutoksiin työtoiminnassa, joten sen muutokset tulee ottaa huomioon kehittämistyössä. Organisaation kaikkien toimijoiden on oltava valmiita sitoutumaan tietojärjestelmän aiheuttamaan muutokseen toimintatavoissa (Martola & Santala 1997). Sitoutumista voidaan edistää osallistumisen lisäksi myös tiedottamalla tietojärjestelmän käyttöönoton sisällöstä ja tavoitteista (Turpeinen & Taskinen 2004). Yksilön kannalta tämä tarkoittaa sitä, että hän näkee itsensä osana kokonaisuutta ja samalla sen, mihin kaikkeen hänen työnsä vaikuttaa. Terveydenhuollon toiminnan kehittämisen onnistumisen kannalta on tärkeää, että organisaation ylin johto sitoutuu uudistuksiin ja tukee niitä aktiivisesti (Juuti & Lindström 1995, Stakes 1999). Käytännössä tämä tarkoittaa sitä, että esimerkiksi huolehditaan resurssien riittävyydestä. Lisäksi organisaation johdon on toimittava muutoksissa esikuvana (Stakes 1999, Whittaker 1999, Salmimies 2001). Muutosprosessin toteuttamiseen vaikuttaa se, kuinka organisaation eri toimijat havaitsevat muutoksen tarpeen ja ovat halukkaita toteuttamaan sen (Virkkunen, Engeström, Pihlaja & Helle 1999).

17 Tietojärjestelmän kehittäminen Yhteistä ohjelmistotuotantoprosessille ja asiakkaan tietojärjestelmän kehittämiselle on, että molempiin kuuluu esiselvitys- ja vaatimusmäärittelyvaihe. Vaatimusmäärittelyssä kartoitetaan asiakkaan tarpeet ja toiveet sekä asiakasvaatimukset toteutettavan tai hankittavan järjestelmän suhteen. Ohjelmistotalossa asiakasvaatimukset tarkennetaan ohjelmistovaatimuksiksi, joiden mukaisesti kehitetään uusi ohjelmisto. Asiakasorganisaatiossa asiakasvaatimusten avulla kuvataan ohjelmiston tarjoajille, mitä halutaan, ja tarjouksia verrataan asiakasvaatimuksiin ohjelmistoa valittaessa. Näin ollen myös vaatimusmäärittelyn muoto ja tarkkuus eroavat toisistaan. Ohjelmistojen hankkiminen markkinoilta valmiina tarkoittaa sitä, että ohjelmistot perustuvat muuhun kuin varsinaisen asiakkaan tuottamaan vaatimusmäärittelyyn, jossa kuvataan asiakkaan ja käyttäjien tarpeet ja toiveet. Hankinnan jälkeen on huolehdittava uuden ohjelmiston käyttäjien koulutuksesta sekä ohjelmiston käyttöönotosta. Koska ohjelmisto tulee osaksi organisaation tietojärjestelmää, jota käytetään työtoiminnan tukena, tietojärjestelmän ja työtoiminnan muutkin osat on huomioitava. Uusi ohjelmisto tuo muutoksia niin työkäytäntöihin kuin tiedonkulkuunkin, ja nämä muutokset on suunniteltava. Aina koko prosessia ei käydä kerralla läpi esiselvityksestä uuden ohjelmiston tuotantokäyttöön saakka, vaan ohjelmiston kehittäminen tapahtuu pienissä erissä, palanen kerrallaan. Voidaan esimerkiksi tehdä pelkkä esiselvitys kehitystarpeista ja päättää tulosten perusteella, miten edetään: mitä muutoksia ohjelmistoon, tietojärjestelmään tai työn järjestämiseen tarvitaan. Suuren organisaation osastoilla voidaan yhteisen ohjelmiston käyttöönotto toteuttaa vaiheittain, jolloin edellisestä vaiheesta saatuja kokemuksia hyödynnetään seuraavissa vaiheissa Käyttäjätarpeet ja vaatimusmäärittely Tietoväline (esim. ohjelmisto), joka tulee osaksi työtoimintaa, on parhaimmillaan käyttäjälleen työkalu, joka tukee saumattomasti työtä ja työstä nousevia tiedon tarpeita. Siksi ohjelmistoa hankittaessa tai kehitettäessä on keskeisin tehtävä selvittää sen tulevat käyttäjät sekä heidän työtoiminnasta nousevat tarpeensa. Tätä vaihetta kutsutaan ohjelmistotuotannossa vaatimusmäärittelyksi ja sillä tarkoitetaan usein koko sitä prosessia, jonka tarkoituksena on kartoittaa asiakasorganisaation tarpeet ja toiveet kattavasti toteutettavan järjestelmän suhteen. Vaatimusmäärittely voidaan nähdä myös prosessina, jossa tulevien käyttäjien tarpeista johdetaan formaaleja käyttäjävaatimuksia. (Sommerville 2001.) Vaatimusmäärittelyllä tarkoitetaan eri asioita riippuen siitä, kuka sen laatii: asiakasorganisaatio vai ohjelmistotoimittaja. Usein asiakasorganisaatio ohjelmistoa hankkiessaan laatii vaatimusmäärittelyn itse tai käyttää ulkopuolista konsulttia. Asiakasorganisaation laatima vaatimusmäärittely-dokumentti kuvaa organisaation tarpeita hankittavalle tietojärjestelmälle ja sisältää olemassa olevan tietoteknisen infrastruktuurin, toiminnalliset tavoitteet hankittavalle tietojärjestelmälle (käyttäjätarpeet) sekä rajaukset. Siinä voi olla mukana myös ei-toiminnallisia tavoitteita, kuten suorituskykyä, ylläpidettävyyttä ja tukipalvelujen saatavuutta koskevia vaatimuksia. Näitä kaikkia ominaisuuksia yhdessä kutsutaan myös asiakasvaatimuksiksi. Ohjelmistotoimittaja yleensä tarkentaa tätä asiakkaan laatimaa vaatimusmäärittelyä järjestelmän tietoteknisillä ratkaisuilla (palvelimet, ohjelmistot, työtavat jne.) sekä vielä tarkennetuilla toiminnallisilla vaatimuksilla. (Kettunen 2002.) Ohjelmistovaatimuksia kuvataan usein esimerkiksi käyttötapauskuvausten ja tietoluetteloiden avulla. Hankittaessa ohjelmistoa asiakasorganisaation itse tekemän vaatimusmäärittelyn tärkeys korostuu siinä, että sen perusteella toimittajat laativat tarjouksensa projektin läpiviemiseksi. Mitä parempi vaatimusmäärittely asiakasorganisaatiossa on laadittu, sitä parempia ja vertailukelpoisempia tarjouksia voidaan olettaa saatavan toimittajilta. Näiden tarjousten pohjalta asiakas tekee valintansa toimittajasta. (Kettunen 2002.)

18 16 Useimmiten ohjelmistoa kehitettäessä, olipa kyseessä uuden tuotteen tai olemassa olevan kehittäminen, vaatimusmäärittelyn laatii ohjelmistotoimittaja yhteistyössä asiakkaidensa kanssa. Tällöin ohjelmistotoimittajan työtä ohjaavat helposti jo olemassa olevat tekniset ratkaisut, ja asiakasorganisaation vastuulle jää, että eri yksiköiden ja toimijoiden tarpeet tulee määritettyä riittävän tarkasti. Käyttäjien tarpeita pidetään ensimmäisenä ja epävirallisimpana käyttäjävaatimusten lähteenä. Käyttäjätarpeet siis muodostavat pohjan, johon tuotekehitys perustuu. Käyttäjällä on tiedon käsittelyyn liittyviä tarpeita ja velvoitteita. Tarve ilmenee selvimmin päätöksentekotilanteessa, esimerkiksi silloin, kun lääkäri tarvitsee tietoa potilaan lääkeaineallergioista määrätessään hänelle uutta lääkitystä. Tiedon tarve on usein myös tiedon käsittelyn automatisoinnin tarvetta. Esimerkiksi sairaanhoitaja tarvitsee tietoa potilaalle annettavan lääkeliuoksen kokonaisvahvuudesta, ja sen sijaan, että hän laskisi kokonaisvahvuuden käsin tai laskimella, ohjelmiston tulisi tuottaa tieto vahvuudesta automaattisesti. Kehittämistyössä on huomioitava myös toissijaisten käyttäjäryhmien tarpeet (mm. tilastointi ja raportointi). Terveydenhuollon toimialalla tiedon kirjaamisen velvoite on laissa määrätty. Ilman lakisääteistä velvoitettakin käyttäjän on kirjattava tietoa, sillä vain kirjattua tietoa voidaan hyödyntää tietovälineiden avulla Arkkitehtuurit Arkkitehtuurilla tarkoitetaan abstraktia kuvausta jostakin kokonaisuudesta, ja sillä kuvataan yleisesti osat, osien väliset suhteet ja toiminnan pääperiaatteet. Tietotekniikkaan liittyviä arkkitehtuurin alalajeja ovat esimerkiksi laite-, ohjelmisto-, tietoliikenne- ja tietoarkkitehtuuri. Arkkitehtuuri voidaan myös nimetä esimerkiksi käyttöjärjestelmän tai tekniikan mukaan kuten Windows-, Mac-, Bluetooth- tai GPRS-arkkitehtuuri. (Tietotekniikan termitalkoot 2006.) Arkkitehtuurikuvausten avulla on mahdollista ymmärtää ja jäsentää tulevan systeemin toimintaa, tarpeita ja rajoituksia jo suunnitteluvaiheessa. Arkkitehtuurin kuvaamisessa voidaan tarvittaessa käyttää eri näkökulmia. Esimerkiksi Herzum & Sims (2000) ovat määritelleet neljä ohjelmistotuotantoa, erityisesti ohjelmistoteknistä toteutusta ja kehittämistyötä, palvelevaa näkökulmaa seuraavasti: Tekninen arkkitehtuuri käsittää tekniset ominaisuudet, jotka tarvitaan ohjelmiston kehittämisessä ja suorittamisessa; esimerkiksi suoritusympäristö, työkalut ja käyttöliittymäkehykset. Ohjelmistoarkkitehtuuri sisältää päätökset käytetyistä arkkitehtuureista ja suunnittelumalleista, ohjeistuksesta sekä standardeista, joita tarvitaan perustoimintojen, kuten virheenkäsittelyn tai tietokannan käsittelyn, toteuttamiseen edellä lueteltujen teknisten asioiden lisäksi. Projektinhallinta-arkkitehtuuri kuvaa ohjelmistosuunnittelussa käytettävät yleiset suunnitteluperiaatteet eli ne asiat, jotka mahdollistavat suuren tiimin kustannustehokkaan yhteistyön komponenttipohjaisen ohjelmiston tuottamiseksi. Toiminnallinen arkkitehtuuri käsittää systeemin toiminnallisuuden, joka toteuttaa toiminnalliset vaatimukset. Käytännössä esiselvityksissä esille tulevia arkkitehtuuriin liittyviä ja tuleviin ratkaisuihin vaikuttavia asioita ovat esimerkiksi laitteistot: nykytilakartoitus tai tavoitetila olemassa olevat tietoliikenneverkot ja niitä koskevat vaatimukset nykyisin käytössä olevat ohjelmistot: mitkä halutaan korvata, mitkä taas säilyttää ja integroida uuteen organisaatiotason strategiat ja linjaukset: esim. onko suunnitteilla yhdistää yksiköitä, jolloin tietojärjestelmien yhteensovittaminen on huomioitava alueelliset tai valtakunnalliset strategiat ja linjaukset: esim. alueellinen arkisto, valtakunnallinen potilastietojärjestelmä. Tietoarkkitehtuurilla kuvataan esimerkiksi tiedon tarkoitus, sisältö, ryhmittely sopiviksi tietopaketeiksi, sijainti sekä käyttäjät (käyttäjäryhmät, käyttöoikeudet; tietoturva). Arkkitehtuurikuvauksessa on huomioitava, mitkä asiat ovat todennäköisesti pysyviä, sillä sellaiset aiheuttavat rajoituksia uuden systeemin suunnittelulle.

19 17 2 TOIMINTALÄHTÖINEN TIETOJÄRJESTELMIEN KEHITTÄMISMALLI Kaikissa kehittämistyön vaiheissa on tärkeää saavuttaa yhteinen ymmärrys eri osapuolten välille. Useiden tietojärjestelmähankkeiden epäonnistumiset johtuvat siitä, että suunnittelun eri osapuolet (esim. kliinisen työn tekijät, tietohallinnon edustajat ja ohjelmistosuunnittelijat) eivät ole ymmärtäneet suunnitelmia samalla tavalla. Esimerkiksi perinteiseen tapaan kirjoitettuja vaatimusmäärittelydokumentteja voidaan tulkita varsin monin tavoin, eivätkä nämä erilaiset tulkinnat tule välttämättä esiin määrittelytyön aikana. Sen vuoksi lopullinen ohjelmisto saattaa olla täysin sopimaton aiottuun tarkoitukseen. Näitä väärinymmärryksestä johtuvia ongelmia pyritään esiteltävässä kehittämismallissa ehkäisemään toisaalta mallintamalla nykyistä työtoimintaa tietohallintoa ja ohjelmistotaloja varten, toisaalta esittämällä suunnitelmat tulevista tietojärjestelmistä ja niiden käytöstä mahdollisimman havainnollisesti ja konkreettisesti. Miten ohjelmistoja tullaan käyttämään? Mitä työtoiminnan muutoksia niiden käyttöön ottaminen edellyttää? Yhteisen ymmärryksen syntyminen edellyttää tietysti myös, että näitä työtoiminnan kuvauksia ja tulevan tietojärjestelmän suunnitelmia käydään yhdessä läpi. Tässä luvussa esiteltävän kehittämismallin avulla voidaan suunnitella ja toteuttaa työn ja tietojärjestelmän kehitykseen tähtääviä selvityksiä ja vaatimusmäärittelyjä. Yhtenä keskeisenä ideana on, että samoja tuloksia voidaan käyttää niin työn kuin tietojärjestelmänkin kehittämiseen. Näin vältetään päällekkäistä suunnittelua. Kehittämismalliin kuuluu vahvasti osallistaminen, eli tietoa kohdealueelta kerätään ja työstetään yhdessä kohdealueen työntekijöiden kanssa (esim. tulevan tietojärjestelmän tai ohjelmiston käyttäjät). Tällöin tietojärjestelmän kehittämishankkeessa mukana olevat työntekijät pääsevät vaikuttamaan tuleviin muutoksiin ja voivat nähdä myös työnkehittämisen mahdollisuuksia prosessin aikana. Tietojärjestelmän kehittämistarpeen taustalla on työtoiminnan tarjoaman palvelun parantaminen, esimerkiksi terveydenhuollon palvelun tehostaminen ja paremman palvelun tuottaminen asiakkaille tai potilaille. Työtä voidaan kehittää tuomalla avuksi tietotekniikkaa, mutta se ei välttämättä ole ainoa tai oikea ratkaisu. Nykytilaa selvittämällä ja analysoimalla löydetään kehittämistarpeet ja ymmärretään niiden liittyminen työtoiminnan kokonaisuuteen. Tämän perusteella voidaan suunnitella työtoiminnan osaksi parhaalla mahdollisella tavalla soveltuvat ratkaisut, jotka mallinnetaan tavoitetilakuvauksessa. Nykytilan ja tavoitetilan peilaamisella pystytään suunnittelemaan tarvittavat muutokset. Jotta tietojärjestelmä ja ohjelmisto tukisivat aidosti työtoimintaa, tulee kehittämisen kohteena olla tietojärjestelmän ohella myös työtoiminta, sen sijaan että keskityttäisiin yksittäiseen ohjelmistoon tai muuhun tekniseen työvälineeseen. Siksi kehittämismalli pohjautuu toimintalähtöisyyteen, jonka taustat nousevat toiminnan teoriasta. Jos kehityskohdetta ympäröiviä elementtejä ei oteta huomioon, voivat kehittämisen vaikutukset jäädä huomioimatta: esimerkiksi käyttöön otettu ohjelmisto ei tue tiedon siirtymistä työprosessista toiseen. Siksi kehittämisessä on tarkasteltava asioita useammasta näkökulmasta ja eri tasoilta, keskityttävä välillä johonkin yksityiskohtaan ja palattava taas tarkastelun yleisemmälle tasolle. Toiminnan teoria antaa tähänkin hyvän perustan.

20 Teoriatausta Toimintalähtöinen kehittämismalli perustuu toiminnan teoriaan (Leontjev 1978, Engeström 1987, Kuutti 1991, Engeström 1999, Korpela, Mursu, Soriyan, Eerola, Häkkinen & Toivanen 2004), koska työtoiminnan kehittämistä pidetään tietojärjestelmien ja -tekniikan kestävän kehityksen lähtökohtana. Kehittämismallin perustuminen edellä mainittuihin lähteisiin on kerrottu tarkemmin artikkelissa (Mursu, Luukkonen, Toivanen ja Korpela 2007), tässä oppaassa teoriataustalla pyritään valaisemaan työtoiminnan käytännöllistä ymmärtämistä. Toiminnan teorialla on pitkät historialliset juuret, ja sitä on sovellettu monilla tieteenaloilla, myös tietojärjestelmätieteessä (esimerkiksi Bødker 1997, Bertelsen & Bødker 2000, Mwanza 2001). Toiminnan teorian mukaan toiminnan yhtenä ominaispiirteenä on jatkuva muutos, toiminta ei koskaan ole stabiili, muuttumaton olotila. Tämä muutosprosessi tapahtuu tietyssä sosiaalisessa kontekstissa, jossa yksilön ja yhteisön vuorovaikutus on oleellinen tekijä. Tässä oppaassa esiteltävässä toimintalähtöisessä tietojärjestelmien kehittämismallissa toiminta on työtoimintaa, ja sosiaalinen konteksti on työpaikka, organisaatio, tai mikä tahansa työtoiminnan tapahtumapaikka. Teoriataustan voi kehittämismallissa nähdä työtoiminnan tasoittaisessa tarkastelussa, jossa sovelletaan toiminnan teoriaan perustuvaa ActAD-mallia (Activity Analysis and Development; Työtoiminnan tutkimus ja kehittäminen). ActAD-mallia on kehitetty ja sovellettu Kuopion yliopistossa usean vuoden ajan eri tutkimusprojekteissa (Korpela, Soriyan & Olufokunbi 2000, Mursu 2002, Häkkinen 2003, Toivanen, Eerola & Korpela 2003). ActAD-mallin mukaan työtoiminta nähdään kolmentasoisena: yksilön toimintana, ryhmän toimintana ja sosiaalisen verkoston toimintana. Vastaavasti tietotekniikkaa välineenä voidaan käyttää kolmella tasolla: työvälineenä, ryhmän välisenä koordinoinnin ja kommunikoinnin välineenä sekä sosiaalisena verkoston toimintavälineenä. Sama tietoväline voi näkyä kaikilla tasoilla eri tehtävissä. Esimerkiksi sähköinen potilastietojärjestelmä on yksittäisen toimijan työväline työtehtävässä (hoitaja kirjaa mittaustuloksen potilaan tietoihin), ryhmän keskinäisen kommunikoinnin ja koordinoinnin välineenä (lääkäri katsoo aiemmin kirjattuja tietoja, joiden perusteella tekee päätöksen hoitotoimenpiteestä) sekä toimintaverkoston työvälineenä (potilas siirtyy toiselle osastolle, jossa käytetään samaa sähköistä potilastietojärjestelmää). ActAD-mallia voidaan käyttää ikään kuin muistilistana työtoiminnan eri elementtien analysoimiseksi eri toiminnan tasoilla. Kuvassa 2 on esitetty koko malli. TYÖTOIMINTA. Mallin keskeinen tarkastelun kohde on työtoiminta, joka sitoo ihmisten toiminnan ja tekemisen kontekstiin ja antaa merkityksen eri tekojen ja toimenpiteiden sarjoille. Toiminnalla on kohde ja tarkoitus, työnjaolla toiminta jaetaan pienempiin yksittäisiin tekoihin, joita yksittäiset ihmiset suorittavat. Työtoiminta on siis työntekijöiden välistä kollektiivista toimintaa yhteisen kohteen hyväksi ja yhteisen tavoitteen saavuttamiseksi, joka voidaan jakaa yksittäisiin tekoihin ja operaatioihin. Työtoiminnan sanotaan olevan kulttuurillisesti välittynyttä, eli toiminta määritellään siinä kontekstissa, jossa se tapahtuu. Toiminnan kehittyminen nykypäivään on myös tapahtunut tietyssä kontekstissa. Välttämättä ei ole helppoa tehdä selvää jakoa siitä, mikä on toimintaa ja mikä on yksittäisiä tekoja. Tärkeintä on kuitenkin tunnistaa keskeiset toiminnat, niiden kohteet ja tavoitteet, sekä yksittäisten ihmisten tekemät toimenpiteet ja teot. Tärkeää on tunnistaa niissä käytetyt tietovälineet ja muodostaa kuva käytetystä tietojärjestelmästä. Nykyisten tietojärjestelmien tukemassa työtoiminnassa on joskus vaikea määritellä itse toiminta, koska ihmiset voivat tehdä työtään eri paikoissa, eri aikaan ja jopa tietämättä toisistaan. TYÖTOIMINNAN RAKENNE. Mallin mukaan työtoiminta voidaan rakenteellisesti määritellä sen eri elementtien mukaan. Kuvassa voidaan erottaa yksittäinen ihminen, työntekijä, toimija, joka tekee työtään kohteen hyväksi käyttäen erilaisia työvälineitä, tietoja ja taitoja. Työntekijät yhdessä muodostavat kollektiivisen ryhmän, jonka yhteistä tekemistä sanotaan toiminnaksi. Oleellista on, että yksittäinen teko saa merkityksensä, kun sitä

21 19 Kuva 2. Työtoiminnan elementit, ActAD-malli (Korpela ym. 2004) tarkastellaan osana kollektiivista toimintaa. Tämä toiminta tarvitsee keinoja ja välineitä työn koordinointiin ja keskinäiseen kommunikointiin. Työtoiminnan prosessissa kohde muutetaan tulokseksi tavoitteellisen toiminnan avulla. Prosessia voidaan tarkastella monella tasolla, riippuen siitä, ollaanko kiinnostuneita yksilön tekemistä toimenpiteistä vai kollektiivisen ryhmän keskinäisestä toiminnasta. Yksilötasolla prosessissa tarkkaillaan ihmisen tekemiä toimenpiteitä sekä sitä, mitä tietovälineitä hän niissä käyttää hyväkseen ja miten. Kehittämismallissa puhutaan tällöin työtehtävien ja tietovälineiden tasosta. Ryhmätasolla analysoidaan ryhmän työnjakoa ja työnkulkua eri ihmisten välillä, tietovälineiden käyttöä ja tiedon jakamista sekä kommunikointia. Kehittämismallissa puhutaan työnkulkujen ja tietovirtojen tasosta. Kuvassa 3 on esitelty työnkulkukaavion elementit.

22 20 Teon keinot ja välineet Puuttuvat keinot ja välineet Toimija A Toimija B Toimija C Teko Koordinoinnin keinot eri tekojen välillä Aika Verkottumisen keinot toimintojen välillä Kuva 3. Työnkulkukaavio (Korpela ym. 2004) TYÖTOIMINNAN MUOTO. Työtoiminta noudattaa tiettyä mallia tai muotoa, se on kokonaisuus, joka on muodostunut ajan saatossa tietyssä kontekstissa. Työtoiminnan eri elementit ovat hioutuneet sopiviksi toistensa kanssa, esimerkiksi kommunikaatio noudattaa niitä rakenteita, joita organisaatioon on muodostettu. Kun tässä kokonaisuudessa tapahtuu muutos, olkoon se seurausta ristiriidasta, välttämättömästä kehityksestä, innovaatiosta tai mistä tahansa uudesta työn muodosta, täytyy työtoimintaa katsoa kokonaisuutena. Tärkeää on huomata, mihin tapahtunut muutos vaikuttaa. Siksi esimerkiksi uuden tietoteknisen työkalun käyttöönotto ei koske vain sitä toimenpidettä, mihin se on tarkoitettu, vaan koko toimintaa. Työtoiminnan muodossa on huomioitava, että se sisältää sekä pysyviä että muuttuvia rakenteita. Muun muassa työ-, organisaatio- ja ammattikulttuuri sekä arvot ja etiikka ovat niitä suhteellisen pysyviä rakenteita, joita tulisi kunnioittaa kehittämistyössä. Siksi on tunnistettava nykytila sekä sen rakenne ja historia, jotta pystyttäisiin määrittelemään kehityksen realistiset tavoitteet. Paine työtoiminnan muutokseen voi tulla monelta tasolta ja monelta taholta. Pitäisikin pystyä tunnistamaan, tuleeko syy muutokseen yksittäisen työvälineen kehityksestä, sisäisestä muutospaineesta tavoitteen suhteen, ulkopuolisista tietovälinevaatimuksista, organisaation toimintatapojen muutoksista, ympäristön muutoksista vai mistä. TOIMINTOJEN VERKOSTO. Työtoiminta on harvoin niin itsenäinen kokonaisuus, että se ei olisi jollain tavoin riippuvainen muista toiminnoista. Eri toiminnat jakavat tietoa, jakavat kohteen, antavat syötteitä ja ottavat niitä vastaan (kuva 2). Tämä kaikki tarvitsee keinoja, joilla verkosto toimii. Osa näistä keinoista voi olla tietoteknisiä. Tällä tasolla kehittämismallissa puhutaan toiminta- ja tietokokonaisuuksista. Tuloksen saavuttamiseksi esim. terveydenhuollon palveluissa tarvitaan usein toimintaketjua. Tämä ketju muodostaa kokonaisuuden, joka voi olla jakautunut eri organisaatioihin. Voidaankin puhua organisaatiotason toiminnan tarkastelusta. Joskus muutos voi kohdistua tähän palveluketjuun, jolloin vaikutukset näkyvät sen kaikissa toiminnoissa. Verkostoa voi tarkastella vielä suhteessa sosiaaliseenympäristöön,maakuntaan,lainsäädäntöön, valtakunnan tason tavoitteisiin ja kehitysohjelmiin sekä jopa globaalisti. Näiltä korkeammilta tasoilta tulevat monesti ne kehitystavoitteet ja muutospaineet, jotka näkyvät toiminta- ja jopa yksilötasolla. Siksi kaikkien näiden eri tasojen tunnistaminen on tärkeää, jotta työtoiminnan kehittämisessä tehtäisiin realistisia ja järkeviä ratkaisuja. Eri tasot ovat riippuvaisia toisistaan, vaikuttavat toisiinsa ja peilaavat toisiaan. TIETOTEKNISESTI TUETTU TYÖTOIMINTA. ActAD-mallin mukaisesti tietotekniikka voidaan hyödyntää kolmella tasolla työtoiminnan mukaisesti: yksilötason työvälineenä, kollektiivisen tason koordinointi- ja kommunikointivälineenä sekä organisaatiotason verkostoitumisvälineenä. Näitä eri tasoja ei aina voi erotella kovin yksiselitteisesti, vaan tärkeintä kaikilla tasoilla on se, että tietotekniikka tukee niitä tavoitteita, joita työssä ja organisaatiossa on asetettu. Tosiasia kuitenkin on se, että tietotekniikka tulee yhä enemmän hallitsemaan tieto-orientoitunutta työtä, ja tietotekniikan käyttöönotto tulee olemaan yhä useammin syynä työtoiminnan muutokseen. Siksi olisi tärkeää pitää mielessä, että työtoiminnan kehittäminen on ensisijainen toimenpide tietojärjestelmän käyttöönotossa.

23 Kehittämismalli Tässä oppaassa jäsennetään tietojärjestelmän ja työtoiminnan yhtäaikaista kehittämistä jakamalla se kolmeen vaiheeseen kehittämishankkeen etenemisen mukaan. Työtoimintaa onnistuneesti palvelevan tietojärjestelmän kehittäminen edellyttää sekä 1.) nykytilanteen analysoimista kehittämistarpeiden tunnistamiseksi että 2.) tavoitetilan suunnittelemista ja mallintamista niin, että kaikki osapuolet voivat ymmärtää kehittämistyön vaikutukset arkiseen työtoimintaansa. Vasta sen jälkeen voidaan ryhtyä laatimaan 3.) käytännön suunnitelmaa siitä, miten tuo tavoitetila saavutetaan. Toisaalta kehittämishankkeen aikana asioita joudutaan useimmiten tarkastelemaan monelta eri tasolta; kehittämistyöllä voi olla vaikutuksia koko organisaation ja jopa organisaatioiden väliset rajat ylittävään toimintaan, päivittäistä työtä yhdessä tekevien ammattilaisten yhteiseen ja kunkin yksittäisen työntekijän työhön. Tietoteknisesti tuetun työtoiminnan kehittämisen voidaan ajatella jakautuvan kuvassa 4 esitetyn mukaisesti kolmeen vaiheeseen (vasemmalta oikealle), jossa kutakin vaihetta tarkastellaan kolmelta eri tasolta (ylhäältä alas). Erilaisissa kehittämishankkeissa on erilaisia tavoitteita, ja sisällölliset painotukset luonnollisesti vaihtelevat niiden mukaan. Joissain hankkeissa on tärkeää keskittyä pieniin ohjelmiston yksityiskohtiin, toisissa ratkaisu löytyy vaikkapa työprosesseja parantamalla tai tekemällä hallinnollisia päätöksiä esimerkiksi käytettävistä yhteistyön välineistä. Siksi tätä opasta ei ole kirjoitettu vaihe vaiheelta eteneväksi käyttöohjeeksi, jonka mukaan työskentelemällä voisimme taata kehittämistyön onnistumisen. Yksinkertaistaen voidaan sanoa, että kehittämismalli on kolmevaiheinen ja että toimintaa sekä siinä tarvittavaa tietoa ja tietovälineitä voidaan tarkastella kolmella tarkkuustasolla. Selvityskohteen ja projektin tavoitteen mukaan voidaan keskittyä eri vaiheisiin ja eri tasoihin. Aika Nykytila Tulevaisuus Kuvaukset Yksityiskohdat Yleiskuva Toiminta- ja tietokokonaisuuksien taso Työnkulkujen ja tietovirtojen taso Työtehtävien ja tietovälineiden taso 1. Yhteinen käsitys nykytilasta 2. Yhteinen käsitys tavoitetilasta Arviointi, hyväksyminen, päätös 3. Suunnitelma konkreettisista toimenpiteistä Kuva 4. Toimintalähtöisen tietojärjestelmien kehittämismallin vaiheet ja tasot.

24 Vaiheet Ennen kehittämismalliin sukeltamista tarvitaan yleinen käynnistys- ja suunnitteluvaihe, jonka tavoitteena on määritellä kehittämiskohteen kokonaistavoite. Vaiheen aikana resursoidaan kehittämistyöhön osallistuvat henkilöt, suunnitellaan hankkeen aikataulu, toteutus ja tulokset sekä valitaan tiedonkeruu- ja kuvaamismenetelmät. Tilanteen mukaan on sovittava myös esimerkiksi siitä, missä vaiheessa ja millä ehdoin aloitetaan yhteistyö teknologiatoimittajan kanssa (jos ollaan ottamassa käyttöön tai kehittämässä ohjelmistoa). YHTEINEN KÄSITYS NYKYTILASTA. Työtoiminnan nykytilan, nykyisten työtapojen ja tietokokonaisuuksien kuvaaminen ja näkyväksi tekeminen (dokumentointi, mallintaminen erilaisin kuvin ja kaavioin) mahdollistaa niiden arvioinnin. Dokumentoitua nykytilaa voidaan systemaattisesti käydä läpi ja osoittaa, mitä heikkouksia ja kehittämisen paikkoja toiminnassa on. Samoin voidaan osoittaa myös vahvuudet ja hyvin toimivat käytännöt. Vaiheen tavoitteena on luoda yhteinen käsitys kuvattavan työtoiminnan nykytilasta ja kehitystarpeista. Vaiheen menetelmiä ovat esim. ActADmalli, tutustumiskäynnit, haastattelut, työpajat, taustatiedon kerääminen, kirjallisuuskatsaus. Tuloksena vaiheesta saadaan nykytilan kuvaus, joka sisältää esim. keskeisten toimintojen kuvaukset, prosessikuvauksia, toimintaan osallistuvat tahot ja sidosryhmät, toiminnan tavoitteet, tunnistetut toimintaan vaikuttavat tekijät ja kehityskohteet. YHTEINEN KÄSITYS TAVOITETILAS- TA. Tavoitetilakuvauksessa asetetaan tavoite siitä, miten koko toiminta järjestyy muutoksen jälkeen, kun ongelma on korjattu tai alussa tiedetty muutos on tapahtunut. Tässä huomioidaan kaikki ne asiat (esim. työkäytännöt, työtilat, ohjelmistot ja laitteet), joihin muutos kohdistuu - ei vain se, joka alussa oli tiedossa. Erilaisia vaihtoehtoja ja niiden vaikutuksia voidaan arvioida ennen muutosten toteutumista ja siten pyrkiä kohti hallittua työtoiminnan muutosta. Kaikkia muutospisteitä ei välttämättä voida nähdä tai huomata ennen kuin tavoitetilaa on jo jonkin verran hahmoteltu. Nyky- ja tavoitetilakuvaukset syntyvätkin usein limittäin, kun kokonaiskuva toiminnasta syvenee ja tarkentuu. On kuitenkin tärkeää pitää nämä kuvaukset erillisinä, jotta muutokset voidaan selvemmin nähdä. Vaiheessa käytettäviä menetelmiä ovat erilaiset työpajat, esim. tulevaisuustyöpaja, haastattelu ja havainnointi. Vaiheen tuloksena on mm. tarkennettu kuvaus kehitystarpeista, tavoitetilan skenaarioita, tavoitetilan prosesseja, tavoitepohjaisia käyttötapauksia. ARVIOINTI, HYVÄKSYMINEN, PÄÄ- TÖS. Vaiheittain edettäessä tulee hankkeeseen osallistuvilla olla yhteinen käsitys nykytilasta ja tavoitetilasta. Vasta sitten päästään suunnittelemaan muutoksia. Kehittämismallissa korostetaan yhteistä arviointia ja hyväksymistä (kuvassa 4, tumma sarake) ennen jatkotoimenpiteitä. Useimmiten tarvitaan myös päätöksiä esimerkiksi siitä, mitä muutoksia on realistista toteuttaa tai mitä laitehankintoja tehdään. Toisen ja kolmannen vaiheen väliin tarvitaan jonkinlainen hyväksyntä, esimerkiksi tilaajaorganisaation päätös ja hyväksyntä: nämä ovat ne tavoitteet ja toimenpiteet, joiden mukaan edetään. Hyväksynnän tulee mennä kaikkien tasojen läpi. Hyväksymisvaiheessa asia voi siirtyä jonkun toisen, esimerkiksi ohjelmistotalon, vastuulle. Tässä kohtaa prosessi voi jakaantua kahtaalle; asiakkaan puolella prosessi jatkuu esimerkiksi. toimenpiteiden suunnitteluna ja ohjelmistotalossa varsinaisen ohjelmiston toteutuksena. SUUNNITELMA KONKREETTISISTA TOIMENPITEISTÄ. Suunnitelmat tavoitetilan saavuttamiseksi pitää miettiä konkreettisella tasolla. Tavoitteet voivat olla asetettuna pitkällekin aikavälille, jolloin kehittämisprosessin seuraavien konkreettisten askelten tulee olla tavoitetilan suuntaan. Mitä suurempi askel tai muutos on kyseessä, sitä huolellisemmin ja tarkemmin eri toiminnan tasojen ja näkökulmien mukaiset muutostoimenpiteet on suunniteltava. Erot nykytilan ja tavoitetilan välillä osoittavat ne kohdat, joihin muutostoimenpiteiden on kohdistuttava, ja joiden suunnittelemiseen on otettava kantaa. Suunnitelmien tekijän on kysyttävä: Kuinka suuresta muutoksesta on kyse, ja miten muutos

25 23 viedään läpi? Ketkä osallistuvat muutosprosessin toteuttamiseen? Miten kaikki ammattilaiset saadaan osallistumaan muutoksen suunnitteluun? Mikä on aikataulu? Mitkä ovat konkreettiset toimenpiteet? Vaiheen tavoitteena on suunnitella toimenpiteet nykytilasta tavoiteltavaan työtoimintaan pääsemiseksi (toiminnan muutokset, laite- ja ohjelmistohankinnat tai muutokset). Vaiheen tuloksena syntyvät mm. suunnitelmat työn ja palvelujen uudelleenorganisoinnista, tietojärjestelmän kehittämisen vaiheistuksesta sekä mahdolliset ohjelmistovaatimukset, jotka voidaan kuvata esim. ohjelmiston käyttöliittymäsuunnitelmina ja käyttötapauskuvauksina Tasot Kehittämistarve voi syntyä monella tasolla, ja kehittämiskohdetta voidaan tutkia ja kuvata eri tarkkuustasoilla. Kehittämismallissa on kolme tarkastelun tasoa: 1.) toiminta- ja tietokokonaisuuksien, 2.) työnkulkujen ja tietovirtojen sekä 3.) työtehtävien ja tietovälineiden taso. Eri tasoilla huomio kohdistuu eri asioihin. Toiminta- ja tietokokonaisuuksien tasolla kuvataan toimintakokonaisuus kontekstissaan - saadaan yleiskuva, jota voidaan tutkia tarkemmilla tasoilla sopiva pala kerrallaan. Työnkulkujen ja tietovirtojen tasolla huomion kohteena ovat työprosessit ja niihin liittyvät tiedot, joita käytetään työn tai yhteistyön välineenä. Työtehtävien ja tietovälineiden tasolla tarkastellaan yksittäisen toimijan tekoja ja niissä tarvittavia välineitä. Erityisesti tässä keskitytään tiedonkäsittelytapahtumiin, joiden avulla työtehtävä suoritetaan, tai jotka muuten ovat osa työnkulkua. Näin löydetään esimerkiksi nykyisten välineiden kehittämiskohteita tai uuden tietovälineen käyttäjävaatimuksia. Tasoittainen tarkastelu sitoo yksityiskohdat kokonaiskuvaan jäljitettävästi. Yleisemmästä kuvasta tarkempaan siirrytään valituissa kohdissa, jolloin tarkasteltavat kohteet voidaan priorisoida ja keskittyä tärkeimpiin toimintoihin. Tarkemmalla tasolla saatua kuvaa peilataan seuraavaksi ylempään tasoon, jolloin voidaan nähdä esimerkiksi yksittäisen teon yhteys työprosessiin. Edelleen nähdään työprosessin sijoittuminen kokonaisuuteen ja yhteydet toisiin prosesseihin. Yleisemmällä tasolla nähdään organisaatiorajatkin ylittäviä toimintaverkostoja, joihin työprosessit sijoittuvat. Kehittämismallia voisi verrata pelilautaan, jossa jokainen kehittämishanke muodostaa ikään kuin oman, vaihtelevasti eri ruutujen kautta etenevän pelinsä - kaikissa peleissä käytetään samaa pelilautaa ja samoja nappuloita, jotka valitaan tilanteeseen sopivasti, mutta jokainen peli on kuitenkin omanlaisensa. Taulukkoon 1 on koostettu kuhunkin ruutuun asioita lyhyesti: mitä asioita selvitetään nykytilasta eri tasoilla ja mikä voi olla tavoitetilan suunnittelun tarkoitus eri tasoilla, ja mitä konkreettiset toimenpidesuunnitelmat voivat sisältää.

26 24 Taulukko 1. Toimintalähtöinen tietojärjestelmien kehittämismalli pähkinänkuoressa. Yhteinen käsitys nykytilasta ja kehittämistarpeista Yhteinen käsitys tavoitetilasta Suunnitelma konkreettisista toimenpiteistä Toiminta- ja tietokokonaisuudet TOIMINTA ORGANISAATIO- YKSIKKÖ ORGANISAATIO Toiminta = sosiaalisen verkoston toimintaa Yleiskuva kehittämisen kohdealueesta: 1. Mitkä ovat keskeiset toimintakokonaisuudet? Miten ne ovat verkottuneet ja miksi? Keitä toimintaan osallistuu? Mitä palveluja tuotetaan? Sidosryhmät, konteksti, organisaatiot, yksiköt? Miten toimintakokonaisuudet sijoittuvat suhteessa organisaatioihin ja suhteessa toisiinsa? 2. Mitkä ovat tarvittavat tietokokonaisuudet? Mitä keskeistä tietoa toimintaverkostossa käytetään ja välitetään? Millä välineillä tieto siirtyy? Tietojärjestelmän kehittämisessä (esim. uuden ohjelmiston käyttöönoton yhteydessä) tulee hahmottaa vaikutukset kokonaisuuteen: Miten ja missä kohtaa toimintojen- ja tietokokonaisuuksien verkossa se vaikuttaa? Tarkastetaan työnkulkujen ja tietovirtojen tasolla tehtävien muutosten vaikutusalue. Arviointi, hyväksyminen, päätös Otetaan huomioon: ympäristötekijät, kuten rakennukset, infrastruktuuri, lainsäädäntö yms. toimintakokonaisuuksien sijoittuminen organisaatioissa ja suhteessa toisiinsa. tietokokonaisuuksien sijoittuminen toimintojen verkkoon Suunnitellaan mm.: palvelujen ja työtoiminnan uudelleen organisointi. laite- ja ohjelmistohankinnat. Työnkulut ja tietovirrat TOIMINTA Kohdistetaan tarkastelu keskeisten toimintakokonaisuuksien sisältämiin työnkulkuihin: Miten työprosessi kulkee? Keitä siihen osallistuu? Mikä on työnjako? Miten se tehdään? Esim.: Uuden ohjelmiston käyttöönoton yhteydessä suunnitellaan, miten ja missä kohtaa työprosesseja uutta ohjelmistoa hyödynnetään? Miten tietojärjestelmän tietovirrat järjestellään? Tehdään mm.: työtoiminnan muutosten toteuttamissuunnitelma. yksikkökohtainen käyttöönottosuunnitelma. TYÖPROSESSI Toiminta = ryhmän toimintaa Mitä tietoa työprosessissa tarvitaan? Mistä se saadaan? Mitä tietoa kirjataan, minne, millä välineellä? Tarkastetaan työtehtävien ja tietovälineiden tasolla tehtävien muutosten vaikutusalue. Saadaan mm. integrointivaatimuksia. Työtehtävät ja tietovälineet KÄYTTÖTAPAUKSET OHJELMISTO Ensimmäinen valinta Toinen valinta OK KÄYTTÖLIITTYMÄT Kohdistetaan tarkastelu keskeisten työnkulkujen sisältämiin työtehtäviin: Missä työtehtävissä on kehittämiskohtia? Mistä tiedoista tarvittavat tietokokonaisuuden koostuvat? Millä tietovälineillä tarvittavia tietoja käsitellään, välitetään ja säilytetään? Esim.: Miten uutta ohjelmistoa hyödynnetään työtehtävissä? Miten uuden ohjelmiston käyttöönotto vaikuttaa muiden tietovälineiden käyttöön? Käyttäjien tarpeet ja toiveet muodostavat käyttäjävaatimukset. Suunnitellaan ja dokumentoidaan muutokset työtehtävien ja tietovälineiden tasolla mm.: asiakasvaatimukset ohjelmistotalolle työtehtävien muutos (kirjaamisvastuut tms.) Toiminta = yksilön toimintaa

27 Miten aloitan? Usein kehittämishankkeen lähtötilanteessa tiedetään, että joko tietojärjestelmässä, työtoiminnassa tai palvelujen tuottamisessa organisaatiotasolla on jokin ongelma tai johonkin näistä on tulossa muutos. Esimerkkejä tällaisista tilanteista ovat seuraavat: Nykykäytännöissä on tiedostettu ongelma, jota on tutkittava tarkemmin, jotta se osataan ratkaista. Nykyään käytettävät laitteet tai ohjelmistot ovat vanhentumassa ja pitää hankkia uudet. Työn organisointi muuttuu, esimerkiksi kaksi yksikköä yhdistetään. Jos kehittämismallia käytetään apuna, niin miten se otetaan käyttöön. Mistä sitten lähdetään liikkeelle? Miten tiedetään, minkä tason kuvauksia on laadittava ja mitä niillä kuvataan? Miten edetään? Tilanteesta riippuu miltä tarkkuustasolta lähde- tään. Vaikka keskityttäisiin yhteen tasoon, useimmiten kohdetta tarkastellaan muillakin tasoilla peilaten sekä ylöspäin (yleisempään ja laajempaan kokonaisuuteen) että alaspäin (syvempään ja yksityiskohtaisempaan). Lähtötilanteena voi olla esimerkiksi se, että terveydenhuollon organisaatiossa on tiedostettu, että sen tietoteknisesti tuetussa työtoiminnassa on jokin ongelmakohta tai kehitettävää, ja nyt pitäisi selvittää, miten asia ratkaistaan (tarvitaan monitasoista analyysia); on päätetty, että edessä on uuden ohjelmiston hankinta (tarvitaan analyysia ja suunnittelua ohjelmiston vaikutuksista työnkulkuihin, mutta myös sekä yleisempää että tarkentavaa kuvausta); ohjelmistotoimittaja lähtee kehittämään uutta tuotetta tai parantamaan vanhaa (tarvitaan ainakin analyysia tietovälineiden ja tekojen Määrittele kehittämistoiminnan tavoite. Täsmennä kehittämistoiminnan vaikutusalue. Suunnittele projektin resurssointi, työskentelytavat ja dokumentointi. Täsmennä kehittämistoiminnan keskeinen taso: työryhmien välinen ja työryhmän toiminta, toiminta- ja tietokokonaisuudet, työprosessit ja tietovirrat, yksilön toiminta, yksilön toiminta, työtehtävät ja tietovälineet. Yhteinen käsitys nykytilasta ja kehittämistarpeista Selvitä ja analysoi toiminnan nykytila valitulla tasolla. Riittääkö tarkastelutaso? Kyllä Laajenna tai syvennä tarkastelutasoa. Yhteinen käsitys nykytilasta ja kehittämistarpeista Ei Nyky- ja tavoitetilan kuvausten vertaaminen konkreettisten suunnitelmien työstämiseksi. Määrittele ja suunnittele toiminnan tavoitetila valitulla tasolla. Riittääkö tarkastelutaso? Kyllä Kyllä, mutta tarvitaan lisää tietoa. Jatketaanko? Ei Suunnitelma konkreettisista toimenpiteistä Kyllä Tavoite ohjaa Loppu Suunnittele konkreettiset toimenpiteet. Kehittämistoimenpiteiden toteutus. Kuva 5: Aloitusvaiheen tehtävistä edetään tavoitteen ohjaamina kehittämismallin tehtävien kautta kehittämistoimenpiteiden toteuttamiseen.

28 26 tasolle sekä vaikutusten huomioimista työnkulkujen tasolla sekä luultavasti myös korkeamman tason tarkastelua). Toisin sanoen, vaikka lähtökohta onkin erilainen, analysointia tarvitaan ainakin kahdella eri tasolla. Kuvassa 5 on koottuna aloitusvaiheen tehtäviä suhteessa kehittämismalliin. Liitteessä 3 on kuvattu työskentelyn eteneminen kahdessa esimerkkipilotissa. Tehtävä 1: Määrittele kehittämistoiminnan tavoite Aluksi etsitään vastauksia kysymyksiin: Mikä on hankkeen tavoite? Mihin pyrimme? Mikä on tavoiteltava tulos? Jokaisen tietojärjestelmähankkeen aluksi on syytä hahmottaa lähtötilanne ja tavoite, ts. miksi hanke aloitetaan ja mihin sillä pyritään sekä, paikantaa ongelman taso kehittämismallissa. Yleensä nykykäytännöissä on lähtötilanteessa jotakin tietojärjestelmään liittyviä ongelmia tai kehityskohtia. Esimerkkinä tutkimushankkeen piloteissa tunnistettuja kehityskohtia ovat seuraavat (suluissa ko. pilotista kertova kappale): tieto ei kulje optimaalisesti asiakkaan palveluketjussa (4.1); nykyiset laitteet ovat vanhoja (4.2.); ei ole olemassa sähköistä välinettä, jonka avulla jotain tietoa voidaan hyödyntää työssä (4.3; 4.5); on päätetty siirtyä alueelliseen tietojärjestelmään (4.2; 4.9), jotta potilaan tiedot olisivat käytettävissä häntä palvelevan moniorganisaatioisen verkon kaikissa pisteissä; on jo hankittu sähköinen tietojärjestelmä, jonka käyttöönotto on edessä (4.4). Tavoitteena voi olla tuottaa esimerkiksi tietojärjestelmähankkeen esiselvitys tai uuden järjestelmän asiakasvaatimukset. Konkreettisia tavoitteita voivat olla esimerkiksi ongelmakohtien täsmentäminen (4.1), ratkaisuvaihtoehtojen puntaroiminen (4.2; 4.7), uuden välineen työtoimintaan tuomien muutosten arviointi ja suunnittelu (4.2; 4.4), käyttäjien tietovälineelle asettamien, työtoiminnasta johdettujen tarpeiden kuvaaminen (4.3). Tehtävä 2: Täsmennä kehittämistoiminnan vaikutusalue ja taso Etsitään vastauksia kysymyksiin: Mikä on ongelmakohta nykyisessä toiminnassa tavoitteen saavuttamisen kannalta? Missä ongelma on havaittavissa toiminnassa? Aluksi on tärkeää tunnistaa, millä tasolla ongelma tai kehityskohde on ja mikä on sen vaikutusalue: toiminta- ja tietokokonaisuuksien taso, työnkulkujen ja tietovirtojen taso vai työtehtävien ja tietovälineiden taso (organisaatioiden välinen tiedonkulku, moniammatillinen yhteistoiminta, vai yksittäinen työnkulku). Seuraavaksi esittelemme kehittämismallia yksityiskohtaisemmin tarkastelun tasojen mukaisesti niin, että ensin esitellään eri vaiheet toiminta- ja tietokokonaisuuksien näkökulmasta, sitten työnkulkujen ja tietovirtojen näkökulmasta ja lopuksi työtehtävien ja tietovälineiden näkökulmasta. Kehittämismallin tasoilla työskentely on jaettu kolmeen eri vaiheeseen. Erilaisissa projekteissa näiden eri vaiheiden painotus vaihtelee, ja niiden järjestyskin voi olla toinen. Usein ajatellaan, että säästetään aikaa ja rahaa, jos keskitytään suoraan tavoitetilan kuvaamiseen, eikä pidetä nykytilan analysoimista tärkeänä. Kuitenkaan tulevaisuuden suunnittelu ei perustu todellisuuteen, jos nykytilannetta ei tunneta kunnolla. Siksi nykytilan analysointiin on usein palattava, vaikka aloitettaisiinkin tavoitetilan suunnittelusta. Kokemuksiamme tämän mallin kehittämisestä ja soveltamisesta on esitelty luvussa 4.

29 Toiminta- ja tietokokonaisuuksien taso TOIMINTA ORGANISAATIO- YKSIKKÖ ORGANISAATIO Toimintakokonaisuuksien tasolla selvitetään ja dokumentoidaan tietoteknisesti tuetun työtoiminnan kokonaiskuva kontekstissaan. Toimintakokonaisuuden voi muodostaa yhden organisaation sisäinen tai useamman organisaation välinen palveluketju, -prosessi tai -verkosto. Tavoite ja lähtötilanne ohjaavat, mitä organisaation osia kuvataan ja mitä toimintaa mallinnetaan. Keskeistä on tunnistaa kehitettävän työtoiminnan keskeiset toiminnat ja niiden väliset suhteet (toimintojen verkko). Tietojärjestelmien kehitystyössä on kiinnitettävä huomiota erityisesti myös toiminnassa tarvittaviin tietoihin, jotka ovat joko työvälineenä (esim. potilastiedot) tai kommunikoinnin ja yhteistyön välineenä (esim. säännöt, työvuorolistat). Toimintakokonaisuuksien tasolla tietoa tarkastellaan melko yleisellä tasolla, tietokokonaisuuksina (esim. lähete, hoitopalaute, lääkitystieto, hoitosuunnitelma). Myös toimintaympäristön, toiminnan kontekstin sekä tietojärjestelmäkokonaisuuden kartoitus ja kuvaaminen yleistasolla on tärkeää. Toimintaympäristöstä voidaan kuvata esimerkiksi ne olosuhteet, joissa työtä tehdään ja jotka siihen vaikuttavat, esimerkiksi fyysiset toimitilat ja työpisteet sekä asiakas- ja työntekijämäärät. Tietojärjestelmäkokonaisuuteen kuuluvat esimerkiksi käytössä olevat ohjelmistot ja niiden käyttämiseksi tarvittavat laitteet (esim. kannettava tietokone, tulostin), tietoverkot (esim. GPRS, valokaapeli) sekä manuaaliset tietovälineet (esim. lomakkeet, viestivihko). Toimintakokonaisuuksien tason kuvaamiseen, tai antamaan tietoa siitä, tarvitaan osallistujia, joilla on laaja-alainen näkökulma kohdealueeseen: esimerkiksi sairaalan osastonhoitajalla on näkemys koko osaston toiminnasta, ja tietohallintoyksikön suunnittelijalla on käsitys osastorajat ylittävistä tietojärjestelmistä. Nyky- ja tavoitetilan kuvausten tekijät voivat olla tietohallinnosta tai atk-osastolta, tietolähteinä voivat toimia lähiesimiestason sekä suunnitelmien hyväksyjänä hallinnossa työskentelevät ja organisaatiossa päätäntävaltaa käyttävät ihmiset. Keskeisenä tavoitteena on yhteisen näkemyksen saavuttaminen kohdealueen toimijoiden kesken. Pelkkä keskustelu ei tässä riitä, vaan yhteinen näkemys tulee dokumentoida. Tuloksena tasolta saadaan nykytilan ja tavoitetilan kuvauksia, jotka sisältävät toiminta- ja tietojärjestelmäkokonaisuuden yleiskuvan kontekstissaan (toimintaan osallistuvat tahot ja toiminnan sidosryhmät), toiminnassa tarvittavat tietokokonaisuudet ja tavoitetilan skenaarioita. Kuvausten avulla voidaan paikantaa toiminnan kehityskohteita sekä tunnistaa toimintaan vaikuttavia pysyviä tekijöitä. Näitä voivat olla esimerkiksi lait, organisaation strategiat ja rakenteet, jotka vaikuttavat toimintaan ja sen kehittämiseen, mutta joiden muuttaminen on suunnitellun kehittämistoiminnan ulottumattomissa. Tyypillisiä toimintakokonaisuuden tasolla tuotettuja dokumentteja ovat erilaiset esiselvitykset ja alkukartoitukset, jotka voivat sisältää yleisluonteisia suosituksia siitä, mihin suuntaan olisi edettävä. Toiminnan nykytilan dokumentaatiota voidaan työyhteisössä hyödyntää esim. uusia työntekijöitä perehdytettäessä, määriteltäessä asiakasvaatimuksia ohjelmistohankinnan yhteydessä sekä perusteltaessa vaatimuksia (esimerkiksi organisaation sisällä hankinnoista päättäville). Dokumentaatiota voidaan käyttää myös ennen uuden ohjelmiston käyttöönottoa suunniteltaessa sitä, miten nykyisiä työtapoja, työnjakoa jne. voitaisiin muuttaa ja mitä uusi työväline mahdollistaa. Yleiskuvasta voidaan nähdä mahdollisia kehityskohtia ja tarpeita: esimerkiksi toimintaverkon tiedonkulussa voi olla ongelmia. Syynä voi olla yhteisten työtapojen tai vaikkapa sopivien laitteiden puuttuminen. Tunnistamalla näitä kehityskohtia voidaan valita ne toimintakokonaisuuden osat, joita pitää tutkia tarkemmin. Tarkastelun kohdentamiseen vaikuttaa tietoteknisesti tuetun työtoiminnan kehittämisen tavoite ja reaalimaailman asettamat rajoitteet

30 28 kuten voimassa olevat (kenties myös tulevat) lait ja käytettävissä olevat resurssit (raha, henkilöt ja tietotaito) Yhteinen käsitys toiminta- ja tietokokonaisuuksien nykytilasta Tehtävä: selvitä ja analysoi toiminta- ja tietokokonaisuuksien nykytila Tehtävänä on vastata kysymykseen: miten toimintakokonaisuudet ovat verkottuneet tällä hetkellä ja miksi? Toimintakokonaisuuksien nykytilan määrittelyssä kuvataan toimintaverkoston tämänhetkistä toimintaa mm. seuraavien kysymysten avulla: Mikä on palvelumme? Ketkä ovat asiakkaitamme? Mihin he käyttävät palveluitamme? Keitä muita sidosryhmiä palveluumme liittyy ja miten? Miten kommunikoimme ja vaihdamme tietoa sidosryhmien kanssa? Miten sidosryhmätoimintaa hallitaan tai ohjataan? Mistä saamme välineet sidosryhmien kanssa käytävään kommunikointiin? Mitkä ovat toimintamme kannalta keskeisimmät tietokokonaisuudet? Toimintakokonaisuuden kontekstia hahmotetaan mm. seuraavien kysymysten avulla: Mikä on organisaatiomme, mitä muita organisaatioita meihin liittyy? Millaisissa toimitiloissa toimimme (sijainti, keskitetty / hajallaan)? Millainen infrastruktuuri on käytettävissämme (tietoliikenneverkot, sähkö )? Mitä tietojärjestelmiin liittyviä standardeja, yleisiä määrityksiä yms. käytetään tai on kehitteillä (esim. ydintietomääritykset, rajapinnat)? Millaisia erityispiirteitä toiminnassamme on? Vaikka työtoiminnan yleiskuvan dokumentointi saattaa tuntua itsestään selvien asioiden kertaamiselta, niin käytännössä jokainen toimintaan osallistuva työntekijä näkee ja kokee toiminnan omasta näkökulmastaan. Kokonaiskuvan avulla nähdään yhteys yksilötasolta toimintakokonaisuuteen ja vastaavasti toimintakokonaisuuden yhteydet yksilötasolle, oman yksikön toimintaan sekä edelleen organisaation tai organisaatioiden toimintaan. Työtoiminnan kehittämisen taustalla saattaa olla erilaisia syitä, esimerkiksi lakimuutokset, tarve toiminnan tehostamiseen, organisaatiomuutokset - esimerkiksi osastojen tai yksiköiden toiminnan uudelleen organisointi - tai tietojärjestelmään kohdistuvat muutokset, kuten uuden ohjelmiston käyttöönotto. Olipa syy mikä tahansa, nykyinen toiminta pitää jollakin tavalla käydä läpi ja analysoida ennen kuin sen kehittäminen on mahdollista. Sidosryhmäanalyysissä selvitetään, minkä tahojen kanssa tehdään yhteistyötä tai ollaan muuten tekemisissä: nimetään siis kehittämisen kohteena olevan työtoiminnan sidosryhmät. Sidosryhmien nimeämisen lisäksi on hyödyllistä miettiä, miksi ne ovat sidosryhmiä juuri tässä asiassa, mitä sidosryhmä meiltä tarvitsee ja mitä me tarvitsemme heiltä. Sidosryhmäanalyysin lisäksi tulee selvittää, mikä on toiminnan tarkoitus ja tavoite ( miksi tätä työtä teemme ), ketkä osallistuvat toimintaan, mitä osallistujat tekevät ja mitä tietokokonaisuuksia tai tietovälineitä he käyttävät Yhteinen käsitys toiminta- ja tietokokonaisuuksien tavoitetilasta Tehtävä: määrittele toiminta- ja tietokokonaisuuksien tavoitetila Tehtävänä on vastata kysymyksiin: Miten pyrimme toimimaan seuraavassa kehitysvaiheessa? Miten haluaisimme toimia tulevaisuudessa? Mitä tietoja tarvitsemme tuossa toiminnassa, miten ne saadaan? Miten voidaan hyödyntää valtakunnallisen tai alueellisen tason päätöksiä ja strategioita? Toimintakokonaisuuksien tavoitetilan määrittelyssä kuvataan, miten toimintaverkoston tulee toimia tulevaisuudessa. Määrittelyssä voidaan hyödyntää samoja kysymyksiä kuin nykytilan kuvauksissa. Käytännössä tietoteknisesti tuetun työtoiminnan kehittäminen käynnistyy yleensä jonkinlaisen tavoitteen kautta: tavoitteena voi olla ottaa käyttöön tai kehittää uusi ohjelmisto tai kehittää jo olemassa olevaa ohjelmistoa. Jotta löydetään ja voidaan suunnitella toimenpiteet tavoitetilaan

31 29 pääsemiseksi, pitää ensin tarkastella toiminnan nykytilaa. Nykytilan selvittäminen ja kuvaaminen on apuväline, keino, jonka avulla voidaan tehdä suunnitelmat. Oleellista on, että nykytilan ja tavoitetilan kuvaukset ovat samalla tasolla. Ne ovat peilejä keskenään eli ne kuvataan samalla tasolla riippumatta siitä, kumpi tehdään ensin. Kuvauksia voidaan tehdä rinnakkain ja täydentäen, mutta ne on kuvattava selvästi erillisinä asioina. Sabluuna voi olla sama, mutta asiasisältö siis erilainen. Saatujen kokemusten mukaan toiminnan ja tietojärjestelmäkokonaisuuden yleiskuvan puuttuminen johtaa vaikeuksiin siinä vaiheessa, kun pitäisi kuvata tarkemmin toiminnan ja tietojärjestelmän yhteyksiä muuhun ympäristöön. Erityisesti tietoteknisesti tuetun työtoiminnan tavoitetilan kuvaaminen tarkemmalla tasolla on osoittautunut vaikeaksi, jos tavoitetilan yleiskuva toiminnan ja myös tietojärjestelmien muodostamasta kokonaisuudesta puuttuu. Tällöin on jouduttu tarkemman määrittelytyön yhteydessä hakemaan ratkaisuja myös ylemmän tason toimintaan. Aluksi on syytä selvittää esimerkiksi organisaation tulevaisuuden strategiat ja linjaukset, työtoiminnan ulkopuolelta tulevat kehittämisen reunaehdot sekä määritellä organisaation tietojärjestelmäkokonaisuuden yleistaso ja tavoitetila, jotta pystytään tekemään kokonaisuuteen sopivia yksittäisiä hankintoja Suunnitelma konkreettisista toimenpiteistä toiminta- ja tietokokonaisuuksien tasolla Tehtävä: laadi toiminta- ja tietokokonaisuuksien kehittämissuunnitelma Kun toimintakokonaisuuksien tasolla on kuvattu ja dokumentoitu nykytila ja tavoitetila ja ne on myös hyväksytty, on edessä muutosten suunnittelu. Tämä tarkoittaa esimerkiksi koulutustarpeiden, laite- ja ohjelmistohankintojen ja henkilöresurssoinnin suunnittelua. Tässä vaiheessa tunnistetaan ja nimetään, mitä suunnitelmia tarvitaan: Tarvitsemme koulutussuunnitelman ja suunnitelman hankittavista laitteista ja niiden sijoittamisesta, meidän tulee resursoida ohjelmiston käyttöönottoon henkilöstöä osastoilta x ja y.

32 Työnkulkujen ja tietovirtojen taso TOIMINTA TYÖPROSESSI Työnkulkujen ja tietovirtojen tasolla tarkennetaan yleiskuvaa, joka on muodostettu toimintakokonaisuuksien tasolla. Jotta toiminnan ja tietojärjestelmien kehittäminen osataan kohdistaa oikein, tarvitaan prosessien sisällön mallintamista työnkulkujen ja tietovirtojen tasolla. Joskus voidaan edetä myös toisin päin: aloitetaan keräämällä tietoja yksittäisistä prosesseista, jotka voidaan yhdistää kokonaiskuvaksi tai yleistää koko organisaatiota koskevaksi analyysivaiheessa. Kuvattavan prosessin valintaan ja kuvaamistasoon vaikuttavat kehitystyön tai -hankkeen lähtökohta ja tavoite. Kuvattaviksi valitaan toiminnan kannalta yleiset ja keskeiset prosessit. Prosesseja on hyödyllistä tarkastella usean toimijaroolin näkökulmasta. Työtoimintaan liittyvistä prosesseista voidaan kuvata esimerkiksi asiakkaan palveluprosessi, työntekijän työpäivän kulku, työn organisointi ja tiedonkulun prosessit. Työnkulkujen ja tietovirtojen tasolla selvitetään, analysoidaan ja suunnitellaan uudelleen tietoteknisesti tuetun työtoiminnan prosessit ja niihin liittyvät tietovirrat (tai tiedot ja tiedon saatavuus). Vain yhdenlaisia prosesseja tutkimalla voi kehitystyön kannalta olennaisia asioita jäädä huomaamatta. Esimerkiksi jos tutkitaan pelkästään työntekijän työpäivän kulkua, voi jäädä huomaamatta harvemmin toistuvat työtehtävät. Asiakkaan palveluprosessi voi olla esimerkiksi asiakkaan hoito osastolla. Sitä voidaan kuvata eri tavoin, esimerkiksi toimintatarinoilla tai työnkulkukaaviolla. Työnkulkukaavio on vuokaavion laajennus ja sillä saadaan selville työn järjestys, palveluprosessiin liittyvät yksiköt ja yhteydet toisiin prosesseihin. Työnkulkukaavioon kirjataan lisäksi prosessiin osallistuvat toimijat, teot ja niiden järjestys, tietovälineet, tiedon muoto sekä se, miten tieto liikkuu. Toimintatarinat toimivat hyvinä välineinä asiakkaan palveluprosessin tai työprosessien nykytilan läpikäynnissä. Työntekijän näkökulmasta prosessia voidaan tarkastella useammalta kannalta. Ensinnäkin voidaan kuvata yksittäisen työntekijän työpäivän tai työnosan kulku. Toisaalta voidaan kuvata työntekijän osallistuminen yksikön yhteistoiminnallisiin tehtäviin, esimerkiksi lääkärinkiertoon. Hallinnollinen näkökulma on toiminnan organisointia. Siinä voidaan kuvata osatoimintojen välisiä yhteyksiä. Tässä näkökulmassa kuvataan harvoin tapahtuvat säännölliset hallinnolliset tapahtumat, kuten kotihoidon viikoittainen työnjako. Yhteistyön ja kommunikoinnin välineet ovat usein työprosessin kuvauksessa, esimerkiksi työlistassa. Hallinnollisessa näkökulmassa kuvataan työlistan synty Yhteinen käsitys työnkulkujen ja tietovirtojen nykytilasta Tehtävä: selvitä ja analysoi työnkulkujen ja tietovirtojen nykytila Työtoiminnan nykytilan määrittelyssä kuvataan tämänhetkistä toimintaa mm. seuraavien kysymysten avulla: Mitkä ovat palvelun keskeiset toiminnat? Miten toiminta saa alkunsa, mikä on alkutilanne? Miten toimintaprosessi kulkee? Keitä toimintaan liittyy, ketkä osallistuvat prosessiin? Miten prosessin työnjako sovitaan? Kenellä on päätöksentekovastuu prosessin eri vaiheissa? Minkälaisia työmenetelmiä tai standardeja toiminnassa sovelletaan? Kuka määrää toiminnassa käytettävistä menetelmistä tai standardeista? Miten toimintaan liittyvää työtä voisi kuvailla: onko se tiimityötä vai yksilöllistä työtä? Miten asiakkaat tai sidosryhmät vaikuttavat

33 31 prosessissa? Mitä työvälineitä ja taitoja prosessissa tarvitaan? Mitä tietoja ja tietovälineitä prosessissa tarvitaan? Miten tieto kulkee eri toimijoiden välillä? Miksi tieto on tärkeää? Missä tarvittavaa tietoa säilytetään, mistä se saadaan? Miten ja minne tietoa tallennetaan? Kuka muu käyttää / kirjaa / tarvitsee samaa tietoa? Kehityskohdan paikantaminen: missä näkyy ja miten, ketä koskee? Nykytilaa kuvattaessa on tärkeää tunnistaa ne prosessit tai osat, jotka eivät muutu: on tärkeää, etteivät hyvät tai pakolliset työkäytännöt vahingossa häviä muutosten myötä. Myös poikkeustapaukset on syytä kuvata, sillä niiden tunnistamista tarvitaan esimerkiksi tietojärjestelmän kehittämistä varten. Nykytilan prosesseja voidaan selvittää erilaisin menetelmin. Tietoja voidaan kerätä esimerkiksi havainnoimalla, haastatteluin tai työpajoissa keskustellen pienryhmissä taikka kahdestaan. Joissakin yksiköissä on saatettu jo aikaisemmin kuvata työtoimintaa esimerkiksi laatutyötä varten. Aiemmin tehtyjä kuvauksia voidaan hyödyntää tarkentamalla niitä ja nostamalla niihin mukaan tiedonhallinta. Tämä tarkoittaa sitä, että kuvauksiin merkitään myös se, mitä tietoa työprosesseissa käsitellään, mistä se saadaan ja mitä tietoa tuotetaan ja minne. Tiedot ovat kiinteässä yhteydessä toimintaan. Kuvattavan tiedon on oltava toiminnan kannalta olennaista ja keskeistä. Työprosessikaavioita tehtäessä etsitään tiedon elinkaaren palasia: missä tieto syntyy, kuka sen tuottaa ja tallentaa, mihin tieto tallennetaan ja millä välineillä sekä kuka tietoa tarvitsee, missä ja millä välineellä sen saa. Kuvauksissa selvitetään, mistä tietoyksiköistä tietokokonaisuus muodostuu tai mistä sen pitäisi muodostua: esimerkiksi lääkitystietoon voisi kuulua lääkkeen nimi, annostus, aloittamispäivämäärä ja lääkkeen määränneen lääkärin nimi. Tietokokonaisuuksien sijainti kuvataan tietoarkkitehtuurilla. Esimerkiksi toimintojen verkkoon tai työnkulkukaavioon voidaan merkitä tiedon sijainti ja muoto.

34 Yhteinen käsitys työnkulkujen ja tietovirtojen tavoitetilasta Tehtävä: määrittele työnkulkujen ja tietovirtojen tavoitetila Tehtävänä on vastata kysymykseen: miten pyrimme toimimaan seuraavassa kehitysvaiheessa ja miten haluaisimme toimia tulevaisuudessa? Työtoiminnan tavoitetilan määrittelyssä kuvataan, miten työtoiminnan tulee toimia tulevaisuudessa. Määrittelyssä voidaan hyödyntää samoja kysymyksiä kuin nykytilan kuvauksissa. Tavoitetilan kuvauksessa muutos havainnollistuu. Tavoitetilaan kuvataan, miten työprosessien pitäisi olla järjestetty, jotta ne toimisivat, kun työtoiminnassa tehdään muutoksia ja mahdollinen uusi tietoväline on käytössä. Tavoitetilassa huomioidaan, miten uuden ohjelmiston käyttöönotto tai käyttäminen vaikuttaa yksikön ja organisaation toimintaprosesseihin sekä miten tiedon tulisi olla tuotettu, varastoitu ja saatavilla, jotta sitä voisi hyödyntää mahdollisimman hyvin. Myös rajoitteet on huomioitava. Tulevan toiminnan suunniteluun voidaan käyttää esimerkiksi aivoriihiä tai tulevaisuuteen suuntautuneita toimintatarinoita. Kun työnkulkujen tasolla mietitään toimintaa, nousee esille vaatimuksia, jotka pitää huomioida esimerkiksi hankittaessa uutta ohjelmistoa. Samalla saatetaan myös havaita, ettei toiminnan tavoitetilan määrittelyssä pystytä etenemään, ennen kuin on käytettävissä lisätietoa esimerkiksi uuden teknologian mahdollisuuksista. Nykytilaa voidaan tarkastella ja analysoida samanaikaisesti kun ideoidaan tai suunnitellaan tavoitetilaa, mutta nykytilan ja tavoitetilan kuvauksista on tehtävä erilliset. Nykytilan ja tavoitetilan kuvauksien on oltava samalla tarkkuustasolla, jotta niitä voidaan verrata toisiinsa. Jos nykyisiä työnkulkuja tai asiakkaan palveluprosesseja ei ole dokumentoitu, ei pelkistä tavoitetilakuvauksista pystytä päättelemään niitä askelia, joita tarvitaan tavoitteen toteuttamiseen. Kokonaisuus on tarkistettava ja toimijoiden yhteisymmärrys prosesseista saavutettava ennen toimenpiteiden suunnitteluun siirtymistä Suunnitelma konkreettisista toimenpiteistä työnkulkujen ja tietovirtojen tasolla Tehtävä: laadi työnkulkujen ja tietovirtojen kehittämissuunnitelma Toimenpiteitä, joilla tavoitetila saavutetaan, voi olla suunnittelemassa sama työryhmä kuin nykyja tavoitetilan kuvaamisessa. Aina työryhmän asiantuntemus ei kuitenkaan riitä esimerkiksi tietohallinnon saralle, ja silloin suunnittelun voivat tehdä tietohallinnon asiantuntijat tai ulkopuolinen konsultti. Työryhmästä ja suunnitelman hyväksynnästä päättää kuitenkin se taso, jolla on päätösvalta. Tavoitetilan toteutuksen suunnittelussa nousee usein esille toimintatapojen muutoksia, joiden toteutuksesta päätetään myös yksikön ja organisaation tasolla. Esimerkiksi sairaalassa nestevuorokausi voi vaihtua eri yksiköissä eri aikaan, ja vaihtumisajankohta ilmenee yksiköiden omista lomakkeista. Vaihtumisajankohdasta on päästävä organisaatiotasolla yksimielisyyteen, jotta tietoa voidaan käyttää oikein, kun siirrytään käyttämään yhteistä sähköistä tietojärjestelmää koko organisaatiossa. Nestevuorokauden vaihtumisajankohdan muuttuminen voi joissakin yksiöissä puolestaan johtaa muutoksiin työprosesseissa. Laaja-alaisissa kehittämiskohteissa osatoimintojen toimijoiden tulee sopia yhteisistä keskinäisistä käytännöistä. Kuvattaessa prosesseja työnkulkujen ja tietovirtojen tasolla esille nousee niitä käytännön vaatimuksia, joiden yhteensopivuutta ja toimivuutta tulee tarkastella myös ylemmällä toimintakokonaisuuksien tasolla. Tällaisia yhteistyön kohtia ovat esimerkiksi eri osastojen välinen kommunikointi ja tiedon siirtyminen samassa hoitoprosessissa. Suunniteltaessa konkreettisia toimenpiteitä työtoiminnan tasolla on useimmiten väistämättä palattava myös toimintakokonaisuuksien tasolle, jotta muutostoimenpiteiden vaikutus ympäristöönsä voidaan ennakoida ja ottaa huomioon. Tilanteissa, jossa tuleva muutos on uuden ohjelmiston käyttöönotto, täytyy hahmotella tarvittavat muutokset myös ympäröivään tietojärjestelmään integrointia varten.

35 33 OHJELMISTO 2.6 Työtehtävien ja tietovälineiden taso KÄYTTÖTAPAUKSET Ensimmäinen valinta Toinen valinta OK KÄYTTÖLIITTYMÄT Tässä kappaleessa tarkastellaan työtehtäviä sekä niissä käytettävää tietoa ja välineitä, joiden avulla tieto saadaan tai tallennetaan. Toisin sanoen tarkastelun kohteena ovat tiedonkäsittelytehtävät ja niiden kontekstina ovat työtehtävät ja työnkulut, joihin ne osana liittyvät. Tällainen tarkastelu on tarpeellista erityisesti silloin, kun ollaan suunnittelemassa uutta, kehittämässä olemassa olevaa tai ottamassa käyttöön uutta ohjelmistoa. Uuden ohjelmiston tai ohjelmiston osan suunnittelussa käyttäjien tarpeista johdetaan vaatimuksia välineen toteutukselle: Mitä tietoja tarvitaan ja missä muodossa? Miten työntekijä on vuorovaikutuksissa välineen kanssa? On pohdittava uuden tietovälineen vaikutuksia työtehtäviin: Mitä mahdollisuuksia sähköinen tietojärjestelmä antaa tiedon välittymiselle monitoimijaisessa verkostossa? Mitä rajoitteita uusi väline asettaa? Viimeistään käyttöönottovaiheessa on suunniteltava, mitä käytännön toimenpiteitä tarvitaan muutoksen toteuttamiseksi (esim. käyttökoulutus, toiminnan muutosten suunnittelu) ja miten muutokset vaikuttavat yksittäisten toimijoiden työtehtäviin (esim. kirjaamisvastuut ja -tavat, raportointi, tulostukset, käyttökatkot). Samaan tapaan kuin koko tässä kehittämismallissa, myös itse välineen suunnittelussa on aloitettava suurista linjoista ja edettävä sitten yksityiskohtiin, sillä mitä pidemmälle kehitystyö etenee, sitä vaikeampaa ja kalliimpaa muutosten tekeminen on. Toisin sanoen, vaikka tavoitteena olisi suunnitella uusi väline, on toiminnan konteksti organisaatiotasolta lähtien otettava huomioon. Minkä tahansa ison asian muuttaminen tekee turhaksi siitä johtuvan yksityiskohtien suunnittelun (esim. Hyysalo 2006). Huonosti suunnitelluista terveydenhuollon ohjelmistoista kärsivät ennen kaikkea niitä käyttävät terveydenhuollon ammattilaiset. Tietovälineiden käyttöä ja käyttäjien tarpeita koskeva tieto on keskeistä myös esimerkiksi tuotteen tekniselle toteutukselle, jossa käyttöä koskeva tiedon puute näkyy usein pakkona tehdä merkittäviä korjauksia - tai pahimmassa tapauksessa suunnitella koko tuote uudelleen - pian käyttöönoton jälkeen. Uudelleensuunnittelu on kallista itsessään, mutta kulut kertautuvat vielä tuotannossa ja markkinoinnissa (Hyysalo 2006). Terveydenhuollon organisaatioille aiheutuu kustannuksia huonojen järjestelmien aiheuttaman ajanhukan lisäksi ainakin niiden vaatimasta lisääntyvästä koulutuksen ja teknisen tuen tarpeesta. Tietoteknisesti tuetussa työtoiminnassa tietokone ohjelmistoineen on yksi työn tekemisen väline, ei toiminnan kohde. Välineiden suunnittelussa tai niiden käyttöönotossa on tärkeä ymmärtää sitä toimintaa, jonka osaksi ne tulevat; pelkkä välineen itsensä ymmärtäminen ei riitä. Toiminnasta, eli tällä tasolla työtehtävistä, löytyvät perusteet useille asioille: Mitä tietoa tarvitaan? Milloin, millaisessa muodossa tai millaisina kokonaisuuksina tietoa tarvitaan, jotta työntekijä voi tehtävän suorittaa? Kun jokainen työtehtävä ajatellaan osana suurempaa kokonaisuutta, jolla on käytössä yhteinen tietojärjestelmä, osa työvälineisiin ja työtehtäviin kohdistuvista vaatimuksista (esimerkiksi tarve yhteneville kirjaamiskäytännöille) löytyy tarkastelemalla työprosessia ja edelleen toimintakokonaisuuksien verkkoa. Tavoitteena on siis varmistaa se, että toimijoilla on saatavillaan työtehtävissä tarvitsemansa tiedot ilman erityisiä tai hankalia ylimääräisiä töitä. Yksi osa tätä tavoitetta on saada tuleva ohjelmisto palvelemaan parhaalla mahdollisella tavalla sitä tehtävää, johon se hankitaan. Ohjelmistoja suunniteltaessa pitää ottaa huomioon myös esimerkiksi alan olemassa olevat standardit, luokitukset ja nimikkeistöt, jotka määrittelevät tietoyksiköiden tarkemman muodon. Tärkeäksi näkökulmaksi nousee terveydenhuollon ammattilaisten ja ohjelmistosuunnittelijoiden tai tietohallinnon edustajien välisen vuoro-

36 34 vaikutuksen helpottaminen. Jotta uuden välineen suunnittelu onnistuisi mahdollisimman hyvin, terveydenhuollon ammattilaisten, eli ohjelmiston tulevien käyttäjien, tarpeet on saatava välitettyä ohjelmistojen kehittäjille niin, että molemmat osapuolet ymmärtävät ne samalla tavalla. Toisaalta uuden välineen ominaisuuksista tulisi olla riittävästi tietoa ennen käyttöönottoa: tulevan työvälineen tuomat muutokset työtehtäviin olisi ymmärrettävä ja osattava suunnitella Yhteinen käsitys työtehtävien ja niissä tarvittavien tietovälineiden nykytilasta ja kehittämistarpeista Nykytilan analysoinnin tavoitteena on se, että ymmärretään nykyinen toiminta ja löydetään toisaalta kehityskohdat ja puutteet nykyisessä tietojenkäsittelyssä ja tietovälineissä ja toisaalta tunnistetaan myös hyvät ja pysyvät käytännöt. Tehtävä: selvitä ja analysoi työtehtävien, tietovälineiden ja niiden käyttämisen nykytila Työtehtävien ja tietovälineiden tasolla nykytilan määrittelyssä kuvataan tämänhetkistä toimintaa mm. seuraavien kysymysten avulla: Mikä on tehtävän tavoite? Kuka tehtävän suorittaa? Mitä taitoja ja työvälineitä tarvitaan? Mitä ja missä muodossa olevia tietoja tehtävän suorittamiseksi tarvitaan? Miksi? Mistä tietoa saadaan? Mitä tietoa tehtävässä tuotetaan? Mihin ja miten tehtävän jälkeinen tieto tallennetaan? Mihin tieto menee seuraavaksi, kenen käyttöön? Mitä ongelmia tai puutteita tiedonkäsittelyssä on? Miksi? Mitä ongelmia tai puutteita nykyisin käytössä olevissa tietovälineissä on? Onnistunut uuden tietovälineen suunnittelu tai käyttöönotto edellyttää, että eri osapuolet (terveydenhuollon ammattilaiset ja tietohallinnon tai ohjelmistotalon edustajat) ymmärtävät työn ja siihen liittyvät tiedontarpeet samalla tavalla yksi- tyiskohtia myöten. Joskus on hyödyllistä selvittää ja analysoida tarkastikin nykyisin käytössä olevaa ohjelmistoa, mutta yleensä se ei riitä. Pitää nähdä tiedon käsittely osana laajempaa järjestelmää, johon saattaa kuulua ohjelmiston lisäksi esimerkiksi erilaisia tiedon käsittelyyn käytettäviä lomakkeita eri tilanteissa, tiedon välittymistä esimerkiksi keskusteluissa jne. Samoin on nähtävä tietojärjestelmä ja sen käyttö edelleen osana työtoimintaa, josta perusteet tiedon ja myös sen käsittelyn (missä tilanteessa, kuka, miten, miksi) tarpeille tulevat. Taustatietoja voidaan saada esimerkiksi alan oppikirjoista (termit, käsitteet ym.) tai vaikkapa ohjelmiston käyttäjien antamasta palautteesta (ohjelmiston käyttäminen, puutteet yms.) Yksityiskohtaista tietoa saadaan erilaisten kenttätutkimusten avulla, esimerkiksi haastattelemalla tietovälineen käyttäjiä sekä havainnoimalla ja simuloimalla välineen käyttöä. Todellisten käyttötilanteiden havainnointi tuo esille kontekstiin sidottuja asioita, esimerkiksi miten tiedon hakeminen tai tallentaminen istuu työnkulkuun. Erilaisilla käytettävyystutkimuksen menetelmillä, kuten esimerkiksi heuristisella arvioinnilla (Kuutti 2003) saadaan tietoja ohjelmiston puutteista ja ongelmista. Kenttätutkimusten jälkeen tuloksia analysoidaan ja mallinnetaan ne kaikille osapuolille soveltuvalla tavalla ja varmistetaan, että eri osapuolet ymmärtävät kehittämistarpeet samalla tavalla Yhteinen käsitys työtehtävien ja niissä tarvittavien tietovälineiden tavoitetilasta Tämän vaiheen tavoitteena on suunnitella ja mallintaa tietoteknisesti tuetun toiminnan tavoitetila. Suunnittelutyö on luonnollisesti riippuvaista siitä, ollaanko suunnittelemassa kokonaan uutta ohjelmistoa vai ottamassa käyttöön valmista. Työtehtävien ja tietovälineiden tasolla tämä tarkoittaa esimerkiksi sitä, että määritellään tulevan ohjelmiston käyttäjätarpeet tai mallinnetaan, miten uutta ohjelmistoa tullaan käyttämään työtehtävissä. Menetelminä voidaan käyttää esimerkiksi protoilua, läpikäyntejä, simulointia jne. Tavoitetilaa ja eri vaihtoehtoja on kuvattava sillä tarkkuudella, että kuvausten perusteella voidaan tehdä päätökset esimerkiksi ohjelmiston valinnasta tai suunnitella

37 35 käyttöönotto. Ohjelmiston toiminnallisuutta ja tietosisältöjä voidaan kuvata tässä vaiheessa esimerkiksi käyttöliittymäkonseptin avulla. Kun tästä edetään kohti varsinaista ohjelmistosuunnittelua esimerkiksi käyttötapausten ja tietoluetteloiden laatimisen muodossa, voidaan käyttöliittymäkonseptia käyttää hyväksi. Tehtävä: määrittele työtehtävien ja niissä käytettävien tietovälineiden tavoitetila Tehtävänä on vastata kysymykseen: miten pyrimme toimimaan seuraavassa kehitysvaiheessa ja miten haluaisimme toimia tulevaisuudessa? Tavoitetilan määrittelyssä kuvataan, miten työtehtävät suoritetaan tulevaisuudessa ja miten niissä käsitellään tietoja. Määrittelyissä voidaan hyödyntää samoja kysymyksiä kuin nykytilan kuvauksissa. Lisäksi tulee ottaa huomioon, mitkä ovat olemassa olevien (ja pysyviksi jäävien) ohjelmistojen vaatimukset tiedon muodolle (rajapinnat yms.). Tietovälineiden ja niiden käytön tavoitetilan määrittelyssä yksi keskeisistä tehtävistä on terveydenhuollon ammattilaisen ja tietovälineen välisen vuorovaikutuksen suunnittelu, eli ideoidaan ja suunnitellaan, mitä tietoja haetaan ja kirjataan sekä miten tämä tapahtuu. On myös huomioitava, miten tieto välittyy eri ammattilaisten kesken. Vuorovaikutusta suunniteltaessa voidaan samanaikaisesti pohtia ja arvioida sekä ohjelmiston käyttäjätarpeita että työtehtävien muuttumista. Lähtökohtana on ensimmäisessä vaiheessa tehty nykytilakuvaus, mutta yleensä kaikkia tiedon tarpeita ei ole osattu ennakoida, vaan lisätietoja ja täsmennyksiä tarvitaan myös tässä toisessa vaiheessa. Suunnittelutyön alkaessa saatetaan esimerkiksi tietää, että lääkärit tarvitsevat lääkkeitä määrätessään yksityiskohtaisia tietoja potilaasta, tämän vaivoista ja tehdyistä hoitotoimenpiteistä. Kuitenkin vasta suunnittelutyön edetessä selviää, miten tiedot on mahdollista esittää, ja tällöin on selvitettävä, mikä tapa sopii parhaiten lääkärin päätöksentekoprosessiin. On huomattava, että toimijan ja tietovälineen vuorovaikutus on suunniteltava siinäkin tapauksessa, että ollaan ottamassa käyttöön jo valmista ohjelmistotuotetta. Esimerkiksi sähköisen tietojärjestelmän käyttö sinänsä eroaa manuaalisesta, ja erilainen tiedonkäsittely aiheuttaa muutoksia ympäröiviin työtehtäviin. Lisäksi yhteisesti käytettävä sähköinen tietojärjestelmä antaa mahdollisuuksia tiedon nopeaan välittymiseen monitoimijaisessa verkostossa. Jotta voitaisiin saavuttaa yhteinen käsitys tietovälineiden ja niiden käyttämisen tavoitetilasta, on suunnittelussa käytettävä osallistavia ja yhteistä ymmärrystä lisääviä menetelmiä. Esimerkkinä on protoilu, jossa käyttöliittymäkuvia voidaan käyttää tiedon keräämisvälineenä. Protoilussa työskentely etenee iteratiivisesti; kliinisen työn tekijät esittävät ohjelmistoon kohdistuvia tarpeita ja suunnittelijat mallintavat ne yksittäisiksi käyttöliittymäkuviksi, joita käydään yhdessä läpi. Terveydenhuollon ammattilaisten tehtävänä on kertoa, mitä he suunniteltavalta ohjelmistolta odottavat; suunnittelijoiden tehtävänä on suunnitella perusteltuja vuorovaikutus- ja käyttöliittymäratkaisuja, joiden avulla nämä odotukset täytetään. Käytännössä käyttöliittymäkuvat on koettu sekä ohjelmistosuunnittelijoiden että terveydenhuollon ammattilaisten ymmärtämäksi tavaksi kuvata käyttäjätarpeita. Ne konkretisoivat muuten abstraktin tiedon käsittelyn, ja eri terveydenhuollon ammattilaiset pystyivät niiden avulla arvioimaan ja kuvaamaan, mitä tietoja missäkin työvaiheessa tarvitaan. Käyttöliittymäkuvista voidaan edelleen koostaa käyttöliittymäkonsepti, jolla kuvataan ohjelmistotuotteen käyttöliittymän yleinen rakenne ja käyttäjän ja ohjelmiston vuorovaikutus. Käyttöliittymäkonseptin perusteella voidaan tehdä prototyyppi, jonka avulla puolestaan voidaan varmistaa, että ohjelmisto todella sopii tarkoitettuun käyttöön. Lisäksi on varmistettava, että käyttöliittymäkonsepti on toteutettavissa olemassa olevilla tekniikoilla, mutta esimerkiksi ohjelmistoalustaan ei oteta kantaa (Martikainen, Silvennoinen & Ikävalko 2006).

38 Suunnitelma konkreettisista toimenpiteistä työtehtävien ja tietovälineiden tasolla Tehtävä: laadi tietovälineiden ja niiden käytön kehittämissuunnitelma Kolmannessa vaiheessa suunnitellaan ne konkreettiset työvaiheet, joiden avulla suunniteltu tavoitetila voidaan saavuttaa. Tämä voi tapauksesta riippuen tarkoittaa esimerkiksi ohjelmistovaatimusten määrittelyä, käyttöönoton vaiheistamista, aikatauluttamista jne. Kun nykytila ja tavoitetila on mallinnettu ja tarvittavat, varsinaisen kehittämistyön käynnistämiseen liittyvät päätökset on tehty, on suunniteltava konkreettiset toimenpiteet tavoitetilan saavuttamiseksi. Tietovälineen käytön kehittämissuunnitelma voi liittyä edellisissä vaiheissa tehtyjen selvitysten perusteella uuden tietovälineen käyttöönoton suunnitteluun ja sen aiheuttamiin työtehtävien ja esimerkiksi kirjaamisvastuiden muutoksiin. Toisaalta samoja selvityksiä voidaan käyttää myös ohjelmistotaloissa asiakasvaatimusten laatimiseen, jolloin tavoitetilakuvaus on yksi vaatimusmäärittelyn lähtökohta. Piloteissa saatujen kokemusten mukaan ainakin käyttöliittymäkuvat ovat hyvä tapa havainnollistaa määrittelyä, lisätä yhteistä ymmärrystä ja helpottaa siten eri osapuolten välistä yhteistyötä.

39 37 3 TIEDONKERUU, ANALYSOINTI JA KUVAAMINEN Usein on tarpeen käyttää eri tapoja tiedon keräämiseen selvitystyön eri vaiheissa, ja selvitystyötä suunniteltaessa onkin tärkeää pohtia menetelmien valintaa suhteessa selvitystyön tavoitteeseen ja käytettävissä oleviin resursseihin. Millaista tietoa on kerättävä? Millä tavalla saadaan kerättyä parhaiten juuri tavoitteen mukaista tietoa? Onko kyseessä useiden organisaatioiden muodostama toimintaverkko vai yhden toiminnan sisällä tapahtuva pieni kokonaisuus? Minkä verran aikaa on käytettävissä? Tietoja voidaan kerätä erilaisilla tiedonkeruun menetelmillä, kuten esimerkiksi erilaisilla haastatteluilla tai havainnoinnilla. Kerätyt tiedot analysoidaan ja kuvataan selvitystyön tavoitteen mukaisesti. Tiedon kuvaamisessa olennaista on tiedon näkyväksi tekeminen, dokumentointi. Dokumentointi voi tarkoittaa paitsi suoran tekstin, erilaisten listojen tai tarinoiden tuottamista niin myös kuvioiden ja kaavioiden piirtämistä. Tiedon kerääminen, analysointi ja kuvaaminen tapahtuvat limittäin ja iteratiivisesti, toisin sanoen, kun tietämys kohdealueesta analyysin myötä kasvaa, huomataan usein, että jo kerätyt tiedot ovatkin riittämättömiä, ja joudutaan hakemaan lisää tietoa. Toimintalähtöisyys antaa oman sävynsä käytettäviin menetelmiin. ActAD-malli toimii muistilistana selvitettävistä asioista ja esimerkiksi haastattelukysymyksiä laadittaessa Liitteessä 1 on esimerkki, joka havainnollistaa, miten teemahaastattelun avulla löydetään ActAD-elementit. Lisäksi voidaan käyttää hyväksi kehittämismallin taso-luvuissa esitettyjä kysymyksiä. Toimintalähtöisyys antaa osviittaa myös siihen, miten osataan valita oikeita henkilöitä tietolähteiksi: otetaan huomioon keskeisten toimintojen erityyppiset toimijat (esimerkki liitteessä 2). Moniammatillinen yhteistyö on myös yksi työkalu jo sinänsä. Kun tietoa tuottava ammattilaisryhmä koostuu eritaustaisista ihmisistä, joilla jokaisella on oman erityisen historiansa ja taustansa tuoma näkökulma, selvitettävästä kohteesta saadaan monipuolinen kuva. Keskustelu ja yhdessä pohtiminen on tärkeä tiedon välittämisen ja luomisen muoto, jota ei voi dokumenttien avulla korvata. Osallistaminen mahdollistaa tämän. Kun halutaan ymmärtää syvällisesti tietyn organisaation toimintaa ja tavoitteena on esimerkiksi muutosprosessin läpivieminen, voi kyseeseen tulla toimintatutkimus. Toimintatutkimus on lähestymistapa, jossa tutkija osallistumalla tutkittavan yhteisön toimintaan pyrkii ratkaisemaan jonkin tietyn ongelman yhdessä yhteisön jäsenten kanssa (Eskola & Suoranta, 1998). Toimintatutkimuksessa työtä kehitetään ulkopuolisen tutkijan avulla, toisin sanoen siihen liittyy aina jonkinlainen tutkijavetoinen interventio. Tutkija ei kuitenkaan tarjoa työyhteisölle mitään valmista kehittämisen mallia, vaan tutkija pikemminkin toimii yhteistyössä tutkittavien kanssa. Hän tarjoaa mahdollisuuden siihen, että tutkittavat voisivat aktiivisesti pohtia omaa toimintaansa sekä siihen liittyviä ongelmia ja tämän jälkeen löytää niihin ratkaisut omista lähtökohdistaan. Tutkittavat voivat myös arvioida toimintansa tuloksia sopivin väliajoin. Toimintatutkimuksen aikajänne on yleensä pidempi kuin perinteisten työpajojen ja ryhmätyösessioiden, se voi kattaa useampia kuukausia tai jopa vuosia, sillä perimmäisenä tavoitteena on aina saada aikaan pysyviä myönteisiä muutoksia työyhteisön toiminnassa. (Eskola & Suoranta 1998, Aspvik 2003.) Olipa kyseessä pienimuotoinen kehittämistilanne tai mittavampi toimintatutkimusta hyö-

40 38 dyntävä muutosprosessi, tarvitaan menetelmiä kehittämistyössä tarvittavan tiedon keräämiseen ja käsittelyyn. Tässä luvussa esitellään ZipIThankekokonaisuudessa käytettyjä tiedonkeruun, analysoinnin ja kuvaamisen menetelmiä ja apuvälineitä, joita voidaan käyttää kehittämistyön eri vaiheissa. Lisätietoja ja yksityiskohtaisempia ohjeita on saatavilla esimerkiksi kirjoista Käyttäjätieto ja käyttäjätutkimuksen menetelmät (Hyysalo 2006) ja Participatory IT Design Designing for Business and Workplace Realities (Bødker, Kensing & Simonsen 2004). Lisäksi liitteissä 1-5 sekä luvun 4 pilottikuvauksissa on esitelty esimerkkejä analysoinnissa ja raportoinnissa käyttämistämme kuvioista ja kaavioista.

41 Kehittämistyön eri vaiheissa käytettävät menetelmät Nykytilan selvittäminen ja analysointi TOIMINTA- JA TIETOKOKONAISUU- DET. Nykytilan analysoimisessa tarvitaan tietoa toimintaan osallistuvista tahoista, sidosryhmistä ja tarvittavista tietokokonaisuuksista. Näiden tietojen hankkimiseksi voidaan käyttää esimerkiksi työpajoja, ja lisäksi tietoa voidaan hakea kirjallisesta materiaalista. Tiedon kuvaamisessa ja analysoimisessa voidaan käyttää apuna mm. toimintatarinoita ja kaavioita (esim. kalanruotokaavio, ActAD-malliin pohjautuva rikastettu kaavio toimintojen verkosta). Tuloksena voidaan dokumentoida esiselvitysraporttiin mm. toimintaympäristön kuvaus, fyysinen ympäristö, sidosryhmät, asiakasmäärät, tietojärjestelmästä tietokokonaisuudet sekä niiden säilytys- ja käsittelymuoto (sähköinen, paperi) sekä tiedon kulku toimintakokonaisuuksien välillä. TYÖNKULUT JA TIETOVIRRAT. Nykytilan analysoimisessa tarvitaan tietoa työprosesseista ja niihin liittyvien tietojen käytöstä ja tiedonkulusta (yhteistyön työvälineet, työtavat ja erityispiirteet). Näiden tietojen hankkimiseksi voidaan käyttää esimerkiksi tutustumiskäyntejä, havainnointeja, haastatteluja sekä työpajoja, ja lisäksi tietoa voidaan hakea kirjallisesta materiaalista. Tiedon kuvaamisessa ja analysoimisessa voidaan käyttää apuna mm. seinätaulutekniikkaa ja työnkulkua kuvaavia kaavioita ja taulukoita (vuokaavio, uimaratakaavio, ActAD-malliin pohjautuva rikastettu kaavio, taulukko työyksikön päivärytmistä). Tuloksena voidaan dokumentoida selvitysraporttiin mm. työprosessit, työnkuluissa käytettävät tiedot, tietovälineet sekä tiedon kulku työyksikössä. TYÖTEHTÄVÄT JA TIETOVÄLINEET. Nykytilan analysoimisessa tarvitaan tietoa tietovälineistä, työtehtävistä ja käsiteltävistä tiedoista. Tämän hankkimiseksi voidaan käyttää esimerkiksi tietovälineen käytön havainnointia tai simulointia, käytettävyysarvioinnin ja testauksen menetelmiä, ryhmähaastatteluja tai -keskusteluja sekä työpajoja, ja lisäksi tietoa voidaan hakea kirjallisesta materiaalista sekä keräämällä artefakteja (esimerkiksi täytettyjä lomakkeita). Tiedon kuvaamisessa ja analysoimisessa voidaan käyttää apuna mm. seinätaulutekniikkaa, miellekarttoja (mind map), kuvaruutukaappauksia, piirrettyjä kuvia ja käyttötapauksia. Tuloksena voidaan dokumentoida selvitysraporttiin mm. tehtävissä käytettävät tiedot ja tietoryhmät, tietovälineen käyttö ja sen kehityskohdat Tavoitetilan ideointi ja suunnitteleminen TOIMINTA- JA TIETOKOKONAISUU- DET. Tavoitetilan suunnittelussa voidaan käyttää apuna mm. vastaavien toimintakokonaisuuksien vertailua, ryhmäkeskusteluja ja asiantuntijahaastatteluja. Kuvaamistapoina tulee olla nykytilan kuvausten kanssa yhtenevä tyyli, joka helpottaa tarvittavien muutosten huomioimista. TYÖNKULUT JA TIETOVIRRAT. Tavoitetilan määrittelyssä tietoa tarvitaan eri ammattiryhmien tarpeista käytettäville yhteistyön välineille ja tiedon saatavuudelle. Näiden hankkimiseksi voidaan käyttää esimerkiksi työpajaa, pienryhmä- tai aiheryhmätyöskentelyä. Suunnittelussa voidaan käyttää apuna mm. työnkulku- ja tietovirtakaavioita (vuokaavio, uimaratakaavio, ActAD-malliin pohjautuva rikastettu kaavio). Tuloksena voidaan dokumentoida suunnitelma mm. ohjelmiston tulevasta käytöstä yksikössä tai työryhmän kesken ja kirjaamisvastuista. TYÖTEHTÄVÄT JA TIETOVÄLINEET. Tavoitetilan määrittelyssä ja suunnittelussa tarvitaan tietoa käyttäjien tarpeista ja toiveista tietovälineelle sekä tietovälineen teknisistä mahdollisuuksista. Näiden hankkimiseksi voidaan käyttää esimerkiksi ryhmäkeskustelua ja havainnointia. Suunnittelussa voidaan mm. piirtää käyttöliittymäkuvia

42 40 ja kuvasarjoja, joiden käyttöä voidaan arvioida, testata tai simuloida, ja lisäksi fyysisen laitteen käyttötuntumaa voidaan testata. Tuloksena voidaan dokumentoida mm. käyttäjien vaatimukset ohjelmistolle Konkreettisten toimenpiteiden suunnitteleminen Konkreettiset toimenpiteet suunnitellaan vertailemalla nyky- ja tavoitetilakuvauksia. Toimintakokonaisuuksien tasolla voidaan tehdä laite- ja ohjelmistohankintoihin liittyviä kehittämissuunnitelmia sekä suunnitella (lyhyen ja pitkän tähtäimen) muutoksia palvelujen organisoimiseksi. Työnkulkujen ja tietovirtojen kehittämissuunnitelma voi sisältää tietoja muutosten toteuttamisesta, priorisoinnista ja aikatauluista, esimerkiksi yksikkökohtaisen tietojärjestelmän ja toiminnan muutosten käyttöönottosuunnitelman. Myös tarvittavat koulutukset suunnitellaan. Työtehtävien ja tietovälineiden tasolla suunnitelmat kirjataan ohjelmistoon kohdistuviksi asiakasvaatimuksiksi ja työtehtävien muutossuunnitelmiksi. Seuraavaksi kerrotaan tarkemmin muutamista keskeisistä ZipIT-hankekokonaisuudessa käytetyistä tiedonkeruun, kuvaamisen ja analysoinnin menetelmistä. KUOPION YLIOPISTO / SUSANNA MARTIKAINEN 2006 Kuva 6. Havainnollistava valokuva erilaisten tietovälineiden käytöstä lääkärinkierrolla.

43 Tutustumiskäynnit ja havainnointi Tiedonkeruumenetelminä käytettiin mm. tutustumiskäyntejä terveydenhuollon organisaatioihin toiminnan yleiskuvan hahmottamiseksi. Tutustumiskäynneillä havainnoitiin esimerkiksi työprosessien ja työpäivän kulkua, kuten lääkärinkiertoa, sairaanhoitajien raportteja tai lääkkeiden jakoa, sekä seurattiin ohjelmistojen käyttöä. Tutustumiskäyntejä voidaan hyödyntää myös esimerkiksi valmisteltaessa uuden ohjelmiston hankintaa. Tutustumiskäynneillä jo ohjelmiston hankkineeseen organisaatioon tulevat käyttäjät voivat keskustella ohjelmiston käyttökokemuksista vertaiskäyttäjien kanssa ja havainnoida ohjelmistojen käyttöä oikeassa käyttötilanteessa. Näin voidaan arvioida erilaisten järjestelmien soveltuvuutta omaan organisaatioon. Tutkimusryhmän edustajien tekemillä tutustumiskäynneillä myös läpikäveltiin asiakasprosesseja, esimerkiksi röntgenkuvausprosessi. Röntgenosastolle tehdyn tutustumiskäynnin tavoitteena oli tutustua röntgenin tiloihin ja laitteisiin (tutkimushuoneet, kuvantamisessa käytettävät laitteet, arkistointi). Tämä auttoi toimintaympäristön hahmottamisessa: mitä asioita missäkin tilassa tapahtuu. Röntgentoiminnassa tämä oli todella keskeistä, sillä toimistotila, tutkimushuoneet, konehuone, lääkärin saneluhuone ja arkisto ovat toiminnan kannalta hyvin erilaisia. Lisäksi käynnin aikana selvitettiin taustatietoja toiminnan yleiskuvan hahmottamiseksi, esimerkiksi tilastoja tehtävistä tutkimuksista, henkilöstömäärästä, työnjaosta sekä toiminnan suuntaviivoista. Havainnointi tapahtui kävelemällä konkreettisesti tavallisen röntgenkuvausprosessin läpi (lähete, ajanvaraus, ilmoittautuminen, kuvaus, lausunto, kuvien arkistointi) Tällöin prosessi ja työnkulut konkretisoituivat, ja oli mahdollista havaita sellaisiakin asioita, joita esimerkiksi haastattelussa ei ehkä olisi tullut ilmi (ulkopuolinen henkilö ei osaa kysyä, eikä haastateltava pidä tärkeänä kertoa, sillä ne ovat hänelle itsestäänselvyyksiä). Samalla tuli esille myös toiminnassa ilmeneviä ongel-mia ja kehittämistarpeita. Lisäksi tehtiin tutustumiskäynnit erikoissairaanhoidon röntgenyksikköön (tärkeä sidosryhmä) sekä muutosprosessin (digitalisoinnin) jo toteuttaneeseen perusterveydenhuollon röntgenyksikköön. Näin näkökulma kohdetoimintaan laajenee, kun sitä tarkastellaan esim. sidosryhmän edustajien toiminnasta käsin, saadaan ideoita tavoitetilasta ja siitä, miten sitä lähdetään määrittelemään. Tutustumiskäyntien anti konkretisoitui dokumentiksi, jossa sanallisesti ja kuvioiden avulla kuvattiin röntgentoiminnan yleiskuvaa ja tavallisinta työprosessia. Myös valokuvaus havaittiin hyödylliseksi menetelmäksi tukemaan havainnointia ja muistiinpanoja. Aina ei ehdi huomata tai kirjoittaa ylös kaikkea oleellista, jota voi valokuvista jälkikäteen huomata. Valokuvaukseen tulee kuitenkin aina olla lupa, ja valokuvia tulee ottaa tai käsitellä jälkikäteen niin, ettei niistä ole tunnistettavissa esimerkiksi potilastietoja. ZipIT-hankekokonaisuuden piloteissa valokuvattiin erilaisia tietovälineitä, niiden sijaintia ja käyttötilanteita, kuten kannettavan tietokoneen ja paperisen potilaskansion samanaikaista käyttöä lääkärinkierrolla (kuva 6). (Vrt. Hyysalo 2006, ; Bødker, Kensing ja Simonsen 2004, )

44 Haastattelut Haastattelut ovat yleisin tapa kerätä laadullista aineistoa. Myös ZipIT-hankekokonaisuuden piloteissa ne olivat keskeinen tiedonkeruumenetelmä selvitettäessä jonkin toiminta- ja tietojärjestelmäkokonaisuuden nykytilaa. Kysymyksiä mietittäessä hyödynnettiin pitkälti ActAD-mallia ja sen tapaa jäsentää työtoimintaa: Mikä on kyseisen työtoiminnan kohde ja tavoite? Keitä toimintaan osallistuu ja mitä tietoa he tarvitsevat työssään? Keneltä, miten ja millä välineillä he saavat tarvitsemansa tiedon? Ketkä puolestaan tarvitsevat heidän tuottamaansa tietoa? Perinteisen strukturoidun haastattelun sijaan piloteissa käytettiin lähinnä teemahaastatteluja, avoimia haastatteluja sekä ryhmähaastatteluja. Erilaisista haastattelutyypeistä, kuten muistakin laadullisen tutkimuksen aineistonkeruumenetelmistä, on olemassa runsaasti kirjallisuutta. Tässä oppaassa lähteinä on käytetty Eskolan ja Suorannan kirjaa Johdatus laadulliseen tutkimukseen sekä teemahaastatteluun keskittyvää Hirsjärven ja Hurmeen kirjaa Teemahaastattelu. Lisäksi esimerkiksi Stakes on koonnut Ihmisiin kohdistuvien vaikutusten arviointi -käsikirjan (Stakes 2006) Menetelmät-osioon kuvauksia erilaisista nykytilan kartoittamisen ja tiedonhankinnan menetelmistä. TEEMAHAASTATTELU on puolistrukturoitu haastattelumenetelmä, jonka avulla saadaan aikaan melko vapaamuotoinen ja luonteva haastattelutilanne, joka etenee kuitenkin valittujen aiheiden ympärillä. Kysymyksiä ei ole tarkkaan muotoiltu tai järjestetty, vaan tarkkojen kysymysten sijaan haastattelijalla on jonkinlainen tukilista käsiteltävistä asioista. Teemahaastattelun käyttäminen edellyttää jonkinasteista kohdealueen tuntemusta, jotta teemat ja kysymykset voidaan suunnitella. (Hirsjärvi & Hurme 1991, Eskola & Suoranta 1998.) Esimerkiksi tehtäessä selvitystä diabeetikoiden silmänpohjien kuvaamisen nykytilasta teemahaastateltiin kuuden terveyskeskuksen edustajia, yhteensä kahtatoista henkilöä. Teemoina olivat kuvantamisessa käytettävän ohjelmiston käytön nykytila, diabeetikoiden silmänpohjien kuvaaminen sekä silmänpohjakuvien arkistointi. Teemaan liittyi seuraavanlainen tukikysymyslista: Miten diabeetikoiden silmänpohjien kuvaaminen on kunnassasi organisoitu (kuinka usein kuvauksia tehdään, kuka kuvat ottaa ja tulkitsee, missä kuvaus suoritetaan jne.)? Kerro kuvausprosessin eri vaiheista (kutsuminen, kuvaaminen, kuvien tulkinta, arkistointi...) Mitkä ovat mahdolliset jatkotoimet (kuka tekee, miten / millä välineillä...)? Mitä tapahtuu, jos kuvista löytyy muutoksia? Lähetetäänkö kuvat erikoissairaanhoitoon silmälääkärin tulkittavaksi (jos, niin miten lähetetään ja miten saadaan vastaus)? Onko kuvausprosessissa jotain ongelmia / kehittämistarpeita? Teemahaastattelu on siis muodoltaan sangen avoin, ja haastateltava pääsee ilmaisemaan itseään varsin vapaamuotoisesti. Kuitenkin käytettävien teemojen ansiosta jokaisen haastateltavan kanssa puhutaan samoista asioista, ja teemat antavat haastattelulle tietyn rungon. (Eskola & Suoranta 1998.) Yksilöhaastattelujen lisäksi tai sijasta voidaan käyttää ryhmähaastatteluja. Ryhmähaastattelussa tavoitteena on saada aikaan ryhmäkeskustelu haastattelijan haluamasta aiheesta tai teemoista. Ideana on, että osallistujat voivat innostaa toinen toisiaan puhumaan, ja erilaiset mielipiteet tulevat samalla esille. Sopivaksi ryhmäkooksi suositellaan kiksi Hoitopalaute-pilotissa valittiin haastateltavat siten, että ensimmäisessä ryhmässä oli perusterveydenhuollon erityyppisiä toimijoita: lääkäri, sairaanhoitaja sekä kotisairaanhoitaja, ja toisessa ryhmässä haastateltiin erityyppisiä erikoissairaanhoidon toimijoita. Seuraavissa ryhmähaastatteluissa oli mukana toimijoita molemmista organisaatioista. Ryhmähaastattelun etuihin kuuluu tuotettavan tiedon monipuolisuus ja rikkaus: varsinaisten faktojen lisäksi saadaan kerättyä tietoa myös mm. toiminnan sosiaalisesta ympäristöstä. Ryhmähaastattelu on myös haastateltavien ajankäytön kannalta taloudellinen haastattelumuoto,

45 43 mikä korostuu erityisesti terveydenhuollon kontekstissa. Ryhmätapaamisissa toimintakokonaisuuden eri vaiheisiin osallistuvat toimijat voivat keskustella keskenään ja siten lisätä ymmärrystään toistensa töistä ja rikastaa toiminnan kokonaiskuvaa. Ryhmähaastattelussa on kuitenkin myös omat haasteelliset piirteensä. Ryhmän kokoon saaminen saattaa olla työlästä. Henkilöiden valintaan vaikuttavat paljon mm. käytännön mahdollisuudet irrottautua työpaikalta sekä osallistujien hierarkkiset ja muut valtasuhteet. Lisäksi ryhmähaastattelujen purkaminen on haasteellista: se tulisi tehdä mahdollisimman pian haastattelun jälkeen, ja siihen olisi syytä varata riittävästi aikaa. Haastattelujen purkamisessa havaittiin hyväksi muistiinpanojen ja keskustelujen perusteella tehdyt koosteet haastattelujen annista. Vaikka haastatteluja nauhoitettiinkin, niitä ei juurikaan litteroitu, vaan nauhoitukset toimivat pääasiassa muistiinpanojen tukena. (Vrt. Hyysalo 2006, ; Bødker, Kensing & Simonsen 2004, )

46 Työpajat ja ryhmätyöt Työpajoissa voidaan varmistaa osallistujien yhteinen käsitys kohteena olevasta asiasta tai toiminnasta. Työpaja soveltuu tietojärjestelmien ja työtoiminnan kehittämisen siihen vaiheeseen, jossa tietojärjestelmä- ja toimintakokonaisuuden nykytilasta on jo jonkinlainen esikäsitys ja sitä halutaan tarkentaa. Se sopii myös tilanteeseen, jossa halutaan etsiä ratkaisuehdotuksia esille tulleisiin kehityskohtiin. Työpajoissa voidaan käydä läpi ja tarkentaa nykyisiä toimintatapoja ja käytäntöjä sekä miettiä yhdessä tulevaa toimintaa (esimerkkinä kuva 7). Työpajan osallistujilla on tässä aktiivinen rooli, ja myös vetäjällä on keskeinen rooli keskustelun johdattelussa. Röntgenkohteessa saatujen kokemusten mukaan työyhteisön ulkopuolinen vetäjä on hyvä nimenomaan työpajassa, jossa tarkoituksena on nostaa esiin ongelmia ja toiminnan kehittämistarpeita. Vaikka työpajan suunnittelu- ja toteutusvastuu olisikin ulkopuolisella taholla, täytyy työyhteisöstä nimetä yhteyshenkilö, joka on mukana suunnitteluvaiheessa ja auttaa käytännön järjestelyissä. Mikäli työpajoja järjestetään useampia, voidaan niiden suunnittelu- ja vetovastuuta jakaa tarpeen mukaan. Työpajat edellyttävät huolellista suunnittelua ja tavoitteenasettelua. Tärkeää on, että vastuut ja roolit ovat selkeät ja jokainen tietää, mitä häneltä edellytetään. ZipIT-tutkimusryhmän saamien kokemusten mukaan työpajat on koettu erittäin positiivisena paitsi työyhteisön, myös yksittäisen työntekijän oman työnkuvan ja sen kehittämisen näkökulmasta. Työpajoissa voidaan myös kirkastaa, mistä työyhteisön toiminnassa pohjimmiltaan on kyse ja miten eri rooleissa toimivat työntekijät siihen linkittyvät, mitä välineitä he käyttävät, mitä tietoa he työssään tarvitsevat, mistä ja millä välineillä he tarvittavan tiedon saavat. Työpajat mahdollistavat keskustelun ja työhön liittyvien käytäntöjen yhdessä pohtimisen, jopa koko henkilöstön mukanaolon, ja niiden avulla voidaan motivoida osallistujia aktiivisesti osallistumaan työnsä kehittämiseen sekä edistää muutoksiin sitoutumista. Tietojärjestelmähankintaa valmisteltaessa työpajoja voidaan järjestää myös ohjelmistotoimittajille. Toimittajatyöpajat palvelevat hyvin ohjelmistotuotteisiin tutustumista. Ne kerryttävät hankintaprosessiin osallistuvien tietämystä markkinoilla olevista järjestelmistä, ja niiden aikana on mahdollista tutustua järjestelmien ominaisuuksiin. Toimittajatyöpajan tarkoituksena on, että järjestelmän tulevat käyttäjät ja ohjelmistotoimittajat voivat keskustella vuorovaikutteisesti tarjottavan tuotteen eli ohjelmiston toiminnallisuudesta ja sen soveltuvuudesta oman organisaation käyttöön. Työpajan etenemistä ja omien tavoitteiden saavuttamista edistää se, että jo etukäteen on valmisteltu kysymyksiä, joihin ohjelmistotoimittajilta halutaan saada vastauksia. Valmiiden kysymysten myötä myös tilaisuuksien dokumentointia voidaan parantaa. Järjestettäessä useampia toimittajatyöpajoja etukäteen mietityt kysymykset helpottavat erityisesti tulosten keskinäistä vertailua ja niiden analysointia. Ryhmätyöt pienryhmissä (esim. työpajojen sisällä) on havaittu hyväksi keinoksi työstää esimerkiksi toiminnan tavoitetilaa. Niistä on etua myös pohdittaessa hankittavan tietojärjestelmän asiakastarpeita. Ryhmätyöskentelyä varten kannattaa suunnitella jonkinlainen tavoite tai tehtävänanto, johon ryhmän tulee antaa vastaus. Esimerkiksi Röntgen-pilotissa röntgentoiminnan tavoitetilaa määriteltiin ryhmätöiden avulla. Röntgenkohteessa ryhmätöillä tarkoitettiin 3-5 henkilön pienryhmiä, joissa jokaisessa oli ryhmänvetäjä sekä muistiinpanojen tekijä. Ryhmissä tulevaa toimintaa määriteltiin toimintatarinoiden avulla sekä valitsemalla etukäteen mietityistä tulevaisuuden toiminnan järjestämisvaihtoehdoista sopivimmat. Ryhmäjaon perusteena voi käyttää ammattirooleja, joko niin, että samaa roolia edustavat työntekijät muodostavat oman ryhmänsä, tai niin, että samaan ryhmään valitaan eri rooleissa toimivia henkilöitä. Työpajoissa voidaan myös kokeilla aivoriihityöskentelyä ja vapaata ideointia suunniteltaessa toiminnan tavoitetilaa tai erilaisia ratkaisumalleja nykyisen toiminnan kehittämiseksi. Tällöin pyritään tuottamaan mahdollisimman paljon ideoita ja luovia ratkaisuja ilman kritiikkiä, ja esimerkiksi nykytekniikan asettamia rajoitteita ei huomioida. Kaikki ideat huomioidaan ja arvioidaan vasta jälkeenpäin. (Stakes 2006; vrt. Bødker, Kensing & Simonsen 2004, )

47 45 KUOPION YLIOPISTO / MARIKA TOIVANEN 2005 Kuva 7. Röntgenkuvausprosessin läpikäyntiä työpajassa.

48 Toimintatarina Toimintatarina on kuvitteellinen käytännön esimerkki, joka personoi kohdealueen, työyhteisön, toimintaa. Toimintatarina tuo toiminnan konkreettisemmaksi ja siten helpommin ymmärrettäväksi, ja se toimii apuvälineenä selvitettäessä kohdealueeseen liittyviä tietoja. Toimintatarinan avulla voidaan miettiä erilaisia tiedonkulkuja ja vastuuhenkilöitä. Samalla voidaan löytää solmukohtia, joissa tieto ei kulje niin kuin pitäisi. Toimintatarinoiden ja niiden varioinnin avulla löydetään ongelmakohtia ja voidaan pohtia syitä ongelmiin. Vastaavalla tavalla voidaan myös kuvata ehdotuksia siitä, miten asioiden pitäisi olla. Toimintatarinan näkökulma voi olla esimerkiksi asiakkaan tai työntekijän. Erilaisilla tarinoilla saadaan esille erilaisia asioita. Toimintatarinoita voidaan laatia myös eri tarkkuustasoille. Esimerkiksi työntekijän näkökulmaa voitaisiin kuvata vaikkapa lääkärin työpäivää tai yhtä asiakaskäyntiä kuvaavilla tarinoilla. Jo pelkkä tarinan laatiminen tuo esille kohtia, joista tarvitaan lisää tietoa: Mitä tietoja toiminnassa tarvitaan? Kuka tiedot tuottaa? Miten ja mihin tiedot nyt kirjataan? Miksi näin tehdään ja mikä vaikuttaa kaikkiin näihin asioihin? Kun tarina laaditaan yhteistyössä, saadaan yhteisen käsitys tarinan sisältämästä toiminnasta. Toimintatarinaa voidaan käyttää myös keskustelun herättäjänä ryhmätapaamisissa. Esimerkiksi Hoitopalautepilotissa käytetty toimintatarina, Saaran tarina (kuva 8), on asiakkaan näkökulmasta kirjoitettu, ja se tuo esille asiakkaan hoitoketjuun liittyviä tiedontarpeita ja -kulkuja. Se laadittiin tutkijoiden ja terveydenhuollon ammattilaisten yhteistyönä. Seuraavassa on pohdintoja toimintatarinan kirjoittamisvaiheesta Hoitopalaute-pilotissa: Miten valitaan toimintatarinan näkökulma? Kun on kyseessä monen organisaation yhteisen potilaan hoito, on asiakas organisaatioita yhdistävä tekijä. Tiedonkulun ongelmat ovat usein organisaatioiden välisiä, kun asiakkaan hoitovastuu siirtyy organisaatiosta toiseen (onko myös toimipisteen toimijoiden välillä?). Näin luonteva lähestymistapa on seurata asiakasta kronologisesti hoidon kulun mukaan. Tässä toimintatarinassa kuvataan asiakkaan lähtötilanne ja se, miten hän tuli ihopoliklinikan hoidettavaksi (lähete- ja toimintakäytännöt), poliklinikkakäynnin kulku (Kuka tekee mitäkin ja missä järjestyksessä? Erityisesti kiinnitetään huomiota kaikkeen, missä tietoa kysytään, haetaan ja kirjataan), asiakkaan siirtyminen pois ihopoliklinikan hoidosta seuraavalle hoitovastuiselle (Mitä tietoja asiakkaasta lähetetään minnekin ja millä välineellä? Miksi?) sekä jälkihoito (Mihin asiakkaan hoitoa koskeviin kyselyihin joudutaan vastaamaan ihopoliklinikalla tapahtuneen hoidon jälkeen? Kuka kysyy?). Miten valitaan toimintatarinan subjekti? Vaikka asiakkaita on hyvin paljon ja jokaisella on oma tarinansa, on hyödyllistä pohtia ensin tyypillisen asiakkaan hoitoa. Tässä tapauksessa mukana on kaksi organisaatiota (perusterveydenhuolto ja erikoissairaanhoito), jolloin on löydettävä sellainen asiakas, joka on molemmille tyypillinen. Esimerkiksi tyypillinen kotihoidon asiakas on iäkäs, ja säärihaava on tyypillinen vaiva, jota hoidetaan ihotautipoliklinikalla. Hoitopalaute-pilotin toimintatarina kirjoitettiin näistä lähtökohdista. Lisäksi tyypillisen tapauksen hoidon seuraamisessa voidaan löytää variaatiopisteitä. Variaatiopisteiden avulla voidaan pohtia erilaisia hoidon kulkuja muuttamalla voin pientä osaa tarinasta ( entäs jos -vaihtoehdot). Tässä muutama: Asiakkaan moniongelmaisuus: Asiakkaalla on säärihaavan lisäksi muitakin vaivoja, esim. sydänvika tai allergia, jotka aiheuttavat joko erilaisen hoitoprosessin ihopoliklinikalla tai erilaisen lähete palaute -käytännön. Asiakkaan hoidon lähtötilanne: Lähtötilanne vaikuttaa niin ihopoliklinikalle tulemiseen kuin jatkohoitoonkin. Asiakas voi olla erilaisten kotihoito-instituutioiden tai muun palvelun tai sitten ei minkään palvelun piirissä. => Ihopoliklinikkakäynti voi johtaa esim. kotihoidon aloittamiseen tai muuntamiseen. Asiakkaan kotikunta: Maksatus- tai lähete palaute -käytännöt sekä ohjelmistot ovat erilaisia.

49 47 Alla on kertomus vanhuksesta, joka tarvitsee kotihoidon lisäksi erikoissairaanhoidon palveluita. Tarinaa käytetään apuna kun etsitään hoitopalautteeseen liittyviä kehittämistarpeita. Pyydämme sinua miettimään Saaran tapausta oman työsi näkökulmasta: millaisia tietoja tarvitset työn eri vaiheissa, jotta Saaran hoito ja työn suunnittelu onnistuu, keihin olet yhteydessä, mistä lähteistä saat ja millä keinoilla käsittelet (hankit, välität muille, tallennat jne.) tietoja. Tarinan lomassa on kysymyksiä, joihin etsimme tapaamisessa yhdessä vastauksia ja käytännön esimerkkejä. KOTIPALVELU Saaran tarina 84-vuotias Saara S. asuu rivitalossa yksinään X-kaupungin lähiössä. Hän on kotihoidon asiakas: liikkuminen on vaikeaa, ja kotipalvelu käy aamuisin avustamassa aamutoimissa ja iltaisin vuoteeseen menossa. Saara käyttää tarvittaessa myös kotisairaanhoitajan palveluita. Eräänä aamuna Saara oli yrittänyt nousta sängystä omin voimin, mutta kaatui ja kolhi jalkansa yöpöydän kulmaan. Kotipalvelun työntekijä löysi Saaran sängyn vierestä lattialta. Hän oli muuten kunnossa, mutta vasemmassa jalassa oli pintaruhje, josta valui vähän verta. Haavaan laitettiin laastari ja aamutoimet sujuivat muuten tavalliseen tapaan. Kun kotipalvelun työntekijä varmistui, ettei Saaralla ole muuta hätää, tuumattiin, että kotipalvelu tarkistaa haavan aamukäyntien yhteydessä ja asiasta tiedotetaan tarvittaessa myös kotisairaanhoitajalle. Mitä tässä vaiheessa tiedotetaan ja kirjataan? Miten se tapahtuu? Ketkä siihen osallistuvat? KSH TK SAIRAALA IHOPKL Aika kului ja kotisairaanhoitaja kävi viikoittain, mutta haava ei ottanut parantuakseen. Parin viikon kuluttua sairaanhoitaja arvioi, että olisi paras käydä näyttämässä haavaa lääkärille. Saaralle varattiin aika terveyskeskuksen vastaanotolle ja kyyti sinne menoa varten. Kotipalvelun työntekijä auttoi Saaran taksiin ja taksikuski sisään terveyskeskukseen. Lääkäri tutki haavan ja päätti, että se tulisi tutkia Sairaalan ihotautipoliklinikalla ja kirjoitti lähetteen. Kotilääkitystä varten hän kirjoitti lääkevoidereseptin ja kotimatkalla taksinkuljettaja haki voiteen apteekista. Miten tieto kulkee kotisairaanhoitajan ja lääkärin välillä? Millaista tietoa lääkärillä on asiakkaasta jo ennestään? Mitä tietoa lähete sisältää? Mitä tietoa lääkärillä käynnistä kirjataan? Miten kotihoidossa tiedotetaan ja sovitaan muuttuneesta tilanteesta/hoidosta? Poliklinikalla osastosihteeri otti vastaan terveyskeskuksen lähetteen ja välitti sen lääkärille. Saaran tapaus arvioitiin kiireelliseksi, aika varattiin seuraavalle viikolle ja lähetettiin kutsu kotiin. Lähetteen tiedot kirjattiin sairaalan tietojärjestelmiin (asiakastietojärjestelmään ja sähköiseen potilaskertomukseen). Kutsu sairaalaan saapui. Saara lähti poliklinikkakäynnille ja otti mukaan potilaskortin sekä kotihoidon hoito- ja palvelusuunnitelman, josta näkyivät mm. lääkitykset ja kotihoidon yhteystiedot. Miten aika varataan ja potilas kutsutaan? Mitä tietoa poliklinikkakutsu sisältää ja miten se toimitetaan? Kenen tarvitsee tietää kutsussa olevat asiat ja miten tieto kulkee? Miten sairaalakäynti järjestetään? Miten järjestetään käynnin yhteydessä tai sitä ennen tarvittavat tutkimukset? SAIRAALA IHOPKL KOTI Saara ilmoittautui potilastoimistossa, josta neuvottiin tie ihotautipoliklinikan vastaanottotiskille. Poliklinikalla hoitaja kutsui Saaran hoitohuoneeseen. Hän puhdisti haavan, otti näytteitä ja lääkäriä odotettaessa jutusteltiin Saaran voinnista. Lääkityksiään Saara ei muistanut nimeltä, joten ne katsottiin hoito- ja palvelusuunnitelmasta. Hetken kuluttua lääkäri tuli ja tutki haavan. Hän kertoi Saaralle haavan syystä ja sen hoitoperiaatteista, kirjoitti uuden reseptin sekä pyysi hoitajaa varaamaan kontrolliajan kahden viikon päähän. Tämän jälkeen lääkäri poistui sanelemaan epikriisin, jonka konekirjoittaja myöhemmin kirjoitti puhtaaksi. Hoitaja sitoi haavan ja varasi Saaralle uuden käyntiajan. Hän kertoi Saaralle seikkaperäisesti, miten haavaa tulee hoitaa, kirjoitti haavanhoito-ohjeen poliklinikan omalle hoito-ohjekortille sekä antoi monisteen, jossa kerrotaan, miten haavasidos tehdään. Saara lähti kotiin ja käyntiä koskeva epikriisi lähetettiin terveyskeskukseen. Minne poliklinikkakäyntiin liittyvät tiedot toimitetaan? Miten tieto liikkuu? Miten tarina jatkuu? Ketkä osallistuvat jatkohoitoon? Mitä tehtäviä heillä missäkin vaiheessa on? Miten tehtävistä sovitaan? Mitä tietoa tarvitaan? Kuka tarvitsee sairaalakäyntiin liittyviä tietoja kotona/terveyskeskuksessa? Millaisissa tilanteissa tietoja tarvitaan (esim. kotiutuminen, vastaanottokäynti jne.) Mitä muuta tietoa tarvitaan? Miten muut tiedot saadaan? Miten jatkohoidon järjestäminen muuttuu jos Saaralla on muita ongelmia, esim. jokin perussairaus, sairas puoliso tai taloudellisia ongelmia? Entä jos Saaralla on paljon muitakin sairaalakäyntejä? Mikä rooli tiedonkulussa voi olla Saaralla itsellään tai hänen omaisillaan? Kuva 8. Esimerkki toimintatarinasta.

50 Seinätekniikka Analysointivaiheessa voidaan käyttää hyväksi seinätekniikkaa hahmotettaessa toiminnan kokonaiskuvaa. Seinätekniikassa huoneen seinälle asetettuun isoon pohjapaperiin kootaan irrallisista symboleista tai tekstilapuista halutun mallin mukaisia ryhmittymiä. Symbolit kiinnitetään esimerkiksi teipillä tai tarralla, jolloin niitä voidaan helposti siirtää ja ryhmitellä uudelleen (Saaren- Seppälä 1987). Esimerkiksi Sähköisen potilaskertomusjärjestelmän käyttöönotto -pilotissa tuotettiin seinätekniikalla yhden osaston toimijoita ja tietovälineitä kuvaava seinätaulu (kuva 9). Taulun yläreunaan ryhmiteltiin kaikki osaston toimijat, ja näiden alapuolelle koottiin heidän käyttämänsä olennaisimmat tietovälineet ja -kokonaisuudet. Erillisillä punaisilla lapuilla merkittiin ne tietokokonaisuudet, joiden käyttöön sähköisen potilaskertomuksen käyttöönotto tulee vaikuttamaan. Taulun oikeaan reunaan koottiin osaston keskeisimmät toiminnat. Ne ryhmiteltiin vastaamaan suunnilleen asiakkaan hoidon kulkua, alkaen osastolle tulosta ja päättyen kotiutukseen. KUVA 9. Esimerkki seinätekniikan soveltamisesta.

51 Rikastetut kuvat ja kaaviot Kun kehittämistyön kannalta tarvittavaa tietoa työtoiminnasta ja tietokokonaisuuksista on kerätty eri menetelmillä, pitää tämä tieto tehdä näkyväksi eli kuvata ja dokumentoida. Saamiemme kokemusten mukaan kuvaamisessa erittäin havainnollistavia ja informatiivisia ovat erilaiset ActAD-malliin pohjautuvat rikastetut kuvat ja kaaviot. Niiden avulla voidaan konkretisoida esimerkiksi yhteyksiä eri sidosryhmien välillä sekä asiakas- ja työprosesseja tai koota yhteen työtoiminnan elementit. Esimerkiksi Röntgen-pilotin aluksi radiologisen tutkimuksen yleiskuvaa jäsenneltiin ActAD-mallin mukaisesti kuvaksi 10. Kuvaan koottiin röntgentoiminnan peruselementit vastaamalla mm. seuraaviin kysymyksiin: mikä on röntgentoiminnan tavoitteena ja kohteena, keitä röntgenosastolla työskentelee, mitä erilaisia tietoon liittyviä välineitä he työssään käyttävät, ja mitkä toiminnat seuraavat ja edeltävät radiologisia tutkimuksia. Yleiskuvasta voidaan nähdä esimerkiksi se, mitä eri ammattiryhmiä tiettyyn toimintakokonaisuuteen osallistuu sekä se, keitä olisi syytä osallistaa kehittämistyöhön. Rikastettujen kuvien ja kaavioiden piirtäminen onnistuu paitsi erilaisilla ohjelmistoilla, myös kynällä ja paperilla. Kuvaan 11 on hahmoteltu KUOPION YLIOPISTO / LIISA KLEMOLA 2006

52 50 Kuva 10. Radiologisen tutkimustoiminnan peruselementit koottuna ActAD-mallin mukaisesti. Toimenpide-pilottiin liittyvän toimenpidejärjestelmän hankinnan vaatimusmäärittelytyön keskeisiä elementtejä. Vaatimuksia määriteltiin monissa eri työvaiheissa ja työhön osallistui useita eri toimijoita. Kuvan avulla pyrittiin jäsentämään vaatimusmäärittelytyön monia työvaiheita ja niiden koordinointia. Toiminnan kuvaamisen avulla koostettiin yleiskuva vaatimusmäärittelyvaiheesta, jonka aikana alustavat tarpeet muotoutuivat hankittavan tietojärjestelmän vaatimuksiksi ja lopulta tarjouspyynnöksi. Puhtaaksi piirretty kuva on Toimenpide-pilottikuvauksen yhteydessä (kappale 4.7). Kuvaan 12 on puolestaan käsin hahmoteltu työnkulkukaaviota tulevaisuuden röntgenkuvausprosessista. Valmiiseen kaaviopohjaan on nimetty prosessiin osallistuvat toimijat, mutta prosessin kulkua röntgenosaston työntekijät ideoivat yhdessä. Kaavio löytyy puhtaaksi piirrettynä Röntgen-pilotin kuvauksesta (kappale 4.2). Työnkulkukaavioiden lisäksi erilaisia prosesseja voidaan mallintaa myös perinteisten vuo- tai kalanruotokaavioiden avulla. Kalanruotokaaviosta on esimerkki Hoitopalaute-pilotin pilottikuvauksessa. Siinä asiakkaan hoitoprosessi muodostaa kalan selkärangan. Selkärangan alapuolelta tulevilla ruodoilla on kuvattu hoitoon osallistuvat toimijat ja heidän tavoitteensa, ja yläpuoliseen ruotoon on

53 51 liitetty ne tiedot, jotka tämän tavoitteen toteuttamiseksi tarvitaan sekä se, mistä ja miten ne saadaan. Prosessitason kuvauksista voidaan tarvittaessa edetä tekojen ja välineiden tasolle ja ohjelmistovaatimusten kuvaamiseen esimerkiksi käyttötapauskuvausten avulla. Käyttötapauskuvauksia käytetään yleisesti ohjelmistosuunnittelun apuvälineenä, erityisesti kommunikointivälineenä ohjelmistosuunnittelijoiden ja ohjelmiston tulevien käyttäjien välillä. Käyttötapaukset voidaan kuvata sanallisina käyttötapauksina sekä mallintaa UMLnotaation mukaisina käyttötapauskaavioina. (Haikala & Märijärvi 2004.) Esimerkiksi kuvassa 12 vasemmalla olevasta ajanvaraustehtävästä voitaisiin muodostaa käyttötapaus tee ajanvaraus. Tällöin keskityttäisiin kuvaamaan yksityiskohtaisesti sitä, miten terveyskeskusavustaja tekisi ajanvarauksen ohjelmiston avulla, minkälaisia esi- ja jälkiehtoja ajanvarauksen tekemiselle olisi, ja minkälaisia poikkeus- tai virhetilanteita ajanvaraamisessa saattaisi syntyä. Kuva 11. Toimenpidejärjestelmän vaatimusmäärittelyprosessin peruselementtejä hahmoteltuna ActADmallin mukaisesti. Kuva 12. Käsin hahmoteltua tulevaisuuden röntgenkuvausprosessia.

54 Käyttötapaukset Käyttötapauksia ja -kuvauksia käytetään tietojärjestelmäkehitystyössä eri muodossa eri tarkoituksiin, mutta yleisimmin niitä käytetään vaatimusmäärittelyvaiheessa työnkulkuja sekä niihin liittyviä työtehtäviä kuvattaessa ja analysoitaessa. Yhteinen piirre kaikille käyttötapauksille on se, että ne kuvaavat konkreettisia työtilanteita, esimerkiksi yksittäisen työntekijän tai työryhmän toimintaa tai asiakasprosessia. Työnkulut ja työtehtävät selvitetään kenttätutkimuksen avulla, esimerkiksi haastatteluilla ja havainnoinneilla. (Hyysalo 2006.) Ohjelmistosuunnittelussa yleisemmin tunnettuja ovat UML-käyttötapaukset (use cases). Käyttö-tapauksilla kuvataan käyttäjän ja ohjelmiston välistä vuorovaikutusta. Tyypillinen käyttötapaus on skenaario, jossa käyttäjä suorittaa jonkin keskeisen tehtävän ohjelmiston avulla. Näistä skenaarioista saadaan ohjelmiston toiminnallisia vaatimuksia (Fowler 2004). Käyttötapauksia voidaan katsoa olevan myös erilaisten toimintatarinoiden. Toimintatarinoiden avulla voidaan kuvata nykykäytäntöjä, esimerkiksi asiakkaan kulkua palveluprosessissa. Toimintatarinat pohjautuvat todellisuuteen, mutta ne ovat toimintatarinoista voidaan tehdä myös kuvitteellisia kuvauksia tulevaisuudesta ja siihen liittyvistä tapahtumista, ja niide avulla pyritään löytämään uudenlaisia ratkaisuja ja huomioimaan pitkän aikavälin kehitystrendit. Ohjelmiston käyttöliittymäsuunnittelun avuksi on kehitetty GUIDe-prosessimalli (Goals User Interface Design Implementation), jonka osana ovat tavoitepohjaiset käyttötapaukset (goalbased use cases, Laakso & Laakso 2004). Tavoitepohjaisissa käyttötapauksissa jäsennetään käyttäjän tavoite ja tietämys sekä järjestelmän tarjonta. Kenttätutkimuksen aikana havainnoidut tilanteet on helpointa kuvata tavoitepohjaisiksi käyttötapauksiksi, koska niistä on riittävästi tietoa ja dataa käytettävissä. Käyttötapausten etsiminen on helpointa aloittaa käyttäjien päätöksenteko-kohdista ja edetä siitä muihin käyttötilanteisiin, esimerkiksi tietojen kirjaamistehtäviin. GUIDe-mallin mukaan käyttöliittymäsuunnittelu tehdään käymällä tavoitepohjaisia käyttötapa-uksia simuloiden läpi. Suunnittelija etsii käyttäjälle juuri tähän tilanteeseen optimaalisen ratkaisun ja mallintaa sen käyttöliittymäkuvasarjoiksi. Käyttötapauksia simuloidaan yksi kerrallaan, ja niissä tarvittavat tiedot ja toiminnot piirretään kuvasarjoiksi, simuloidaan uudelleen ja poistetaan suurin vaivannäkö käyttäjän näkökulmasta. Skenaarioita ja toimintatarinoita hyödynnetään erityisesti tavoitepohjaisten käyttötapausten tunnistamisessa sekä korkeamman tason toiminnan analysoinnissa ja suunnittelussa. UML-käyttötapaukset taas puolestaan keskittyvät käyttäjän ja ohjelmiston välisen vuorovaikutuksen kuvaamiseen ja niissä kiinnitetään ohjelmiston toiminnalliset vaatimukset. Tavoitepohjaisten käyttötapausten avulla tehdyistä käyttöliittymäkuvista voidaan johtaa UML-käyttötapauksia ohjelmiston teknisen suunnittelun pohjaksi. (Laakso 2006.)

55 Käyttöliittymäkuvat ja -kuvasarjat Käyttöliittymäkuvia voidaan käyttää kehittämishankkeessa niissä tilanteissa, joissa on tarve havainnollistaa ohjelmiston käyttöä. Kuvat ovat konkreettinen esitystapa, jota sekä kliinisen työn tekijöiden että ohjelmistosuunnittelijoiden on helppo ymmärtää. Kuvien käyttö on hyödyllistä nykytilannetta analysoitaessa sekä konkretisoitaessa käyttäjävaatimusten suunnitteluideoita. Lääkehoidon sähköisen suunnittelun ja kirjaamisen kehittäminen -pilotissa käytettiin käyttöliittymäkuvia käyttäjävaatimusten ja ohjelmiston kehitysehdotusten mallintamisessa ja suunnittelussa. Käyttäjävaatimuksia kerättiin iteratiivisesti ja tiiviissä yhteistyössä ohjelmiston tulevien käyttäjien kanssa: terveydenhuollon ammattilaiset kertoivat, mitä he lääkehoidon sähköisen kirjaamisen järjestelmältä tarvitsevat; tutkimusryhmän edustajat puolestaan suunnittelivat vuorovaikutusja käyttöliittymäratkaisuja, joiden avulla nämä tarpeet voitaisiin toteuttaa. Ensimmäiset käyttöliittymäluonnokset piirrettiin paperille (kuva 13), ja sen jälkeen käytettiin esitysteknisiä välineitä kuvien ja kuvasarjojen toteuttamisessa. Keskeistä välineen valinnassa oli se, että kuvia voitiin muokata helposti ja nopeasti. Kokemusten mukaan on tärkeää, että osallistujat tiedostivat näyttökuvien olevan vain kuvia, vaikka ne saattoivatkin näyttää jo valmiilta ohjelmistolta. Tällöin heidän oli helppo ottaa kantaa ja esittää muutoksia. Käyttöliittymäkuvat ja -kuvasarjat toimitettiin osallistujille ennen tapaamista tutustumista ja muiden ammattilaisten kanssa läpikäyntiä varten. Kommentteja ja keskustelua ohjattiin käyttämällä kuvissa tiettyyn kohtaan kohdennettuja puhekuplia (ks. kappale 4.3). Käyttöliittymäkuvien suunnittelun tukena Kuva 13. Käsin hahmoteltu käyttöliittymäluonnos.

56 54 tarvittiin ehdottomasti taustatietoa lääkehoidosta ja sen prosesseista, joita selvitettiin kirjallisuuden, havainnointien ja haastattelujen avulla sekä keräämällä täytettyjä lomakkeita. Tietoanalyysi (esimerkki kuvassa 14) oli myös yksi merkittävä apuväline toiminnassa käytettävien käsitteiden ja tietojen jäsentämisessä. Analyysin tuloksena syntynyttä ymmärrystä tarvittiin mm. käyttöliittymän elementtien ja tietojen ryhmittelyyn. Oikeita potilastapauksia ja niissä käytettyjä tietoja hyödynnettiin suunnittelussa ja käytön simuloimisessa. Vuorovaikutus- ja käyttöliittymäratkaisujen suunnittelussa oli hyödyllistä etsiä ensin ratkaisu tietyn työtehtävän ns. vaikeaan tapaukseen (esim. alenevan lääkityksen suunnittelu). Lisäksi keskeistä oli huomioida suunnittelussa ne tilanteet, jotka tapahtuvat harvoin, mutta ovat kriittisiä esimerkiksi potilasturvallisuuden vuoksi. Lisäksi Lääkehoidon sähköisen suunnittelun ja kirjaamisen kehittäminen -pilotin alkuvaiheessa käytettiin käyttöliittymäkuvia (ohjelmiston kuvaruutukaappauksia) heuristisen arvion havaintoja analysoitaessa ja tuloksia esitettäessä. Tutkimushankkeessa saatujen kokemusten mukaan käyttöliittymäkuvien käyttö oli erittäin hyvä kuvaamistapa ohjelmiston käyttäjävaatimuksia kerättäessä ja suunnitteluideoita esitettäessä sekä niitä edelleen kehitettäessä. Lisäksi käyttäjävaatimusten kuvaaminen käyttöliittymäkuvasarjoiksi mahdollistaa niiden testaamisen (esim. pöytätestin tai läpikävelyn avulla) ennen teknistä suunnittelua ja toteutusta, toisin kuin esimerkiksi UML:n avulla kuvatut käyttäjävaatimukset. (Vrt. Hyysalo 2006, ; Bødker, Kensing & Simonsen 2004, ) puhelinresepti telefaxresepti paperiresepti eresepti Lääkemääräys Ne rep Resepti Sairaalamääräys Sic! Toimitusrajoitukset Voimassaoloaika Määrääjä Kirjaaja Lääke Huume Aloitus Lopetus Ex tempore Valmis lääke Kauppanimi Määrä/ pakkauskoko Vaikuttava aine Vahvuus Muoto Lääkeainehistoria Lääkevaihto Huomautus / erityistieto Käyttötarkoitus Annostelu Kuva 14. Esimerkki tietoanalyysin esitysmuodosta. Pilotin aikana suunnittelijoiden omaan käyttöön työstämä tietoanalyysi lääkitykseen liittyvistä käsitteistä.

57 Jäljitettävä mallinnusketju Terveydenhuollon tietojärjestelmien kehittämisen tulee hallitusti palvella toimintaprosessien kehittämistä terveydenhuollon organisaatioissa. Tietojärjestelmäratkaisujen eri osa-alueiden kuvaaminen etenee usein toimintakokonaisuuksien kuvaamisesta kohti tarkkoja toiminnan ja sovellusten suunnittelupäätöksiä. Eri kuvaukset muodostavat ketjun, jossa samoja seikkoja kuvataan useilla eri tavoilla ja eri tarkkuuksin. Tietokuvaukset muuttuvat ketjun eri vaiheissa yleisistä toimialan käsitteistä kohti ohjelmistojen tarkkoja ja usein rakenteisia esitysmuotoja. Tällöin on huolehdittava monen tyyppisestä jäljitettävyydestä: toiminnan rakenneosien jäljitettävyydestä toimintakokonaisuuteen, tietojen jäljittämisestä eri toimijoihin ja paikkoihin sekä tietojenkäsittely tapahtumien jäljitettävyydestä työprosesseihin. Jäljitettävyyden avulla voidaan todeta, että ratkaisu vastaa vaatimuksia ja kehittämistarpeita. Lisäksi ohjelmistovaatimukset on kuvattava yksiselitteisesti siten, että niistä päästään tekemään suunnittelupäätöksiä ohjelmistoratkaisujen kehityksessä. Toimintalähtöisessä tietojärjestelmien kehittämismallissa kohdealuetta mallinnetaan kolmella tasolla. Ylimmällä tasolla tarkastelun kohteena on kohdealueen työtoiminta kokonaisuutena. Toimintaa jäsennetään ActAD-mallin avulla kokonaiskuvaukseksi, jossa lintuperspektiivistä kuvataan mukana olevat organisaatiot, (osa)toiminnat, toimijat sekä yhteydet toimintojen tai toimintojen ja organisaatioiden välillä. Kokonaiskuvasta valitaan ne kohdat, joita halutaan tutkia tarkemmin. Yleensä on kyseessä niin sanottu kehityskohta, tiedonkulun tai työtoiminnan ongelmakohta. Keskitasolla kuvataan valittuja työprosesseja, joista kuvataan työprosessin kulku tehtävä tehtävältä, siihen osallistuvat toimijat sekä heidän kussakin työvaiheessa käyttämänsä välineet ja tiedot. Tarkimmalla tasolla tutkitaan yksittäistä tekoa tai välinettä osana työprosessia, esimerkiksi tiedonkäsittelytapahtumaa ja siinä tarvittavaa ohjelmiston tämismallia sovelletaan nykytilan ja kehityskohteiden mallintamiseen ja tavoitetilan sekä ratkaisuehdotusten ideointiin ja suunnitteluun. Osa tavoitetilasta muodostaa vaatimuksia ohjelmistoratkaisuille (esim. sovellukset, integrointiratkaisut). Haasteena on kuvata vaatimukset siten, että tietojärjestelmien kehittäjät ja tulevat käyttäjät ymmärtävät kuvaukset samoin ja siten, että vaatimukset ovat riittävän tarkkoja suunnittelupäätösten tekemiseen. Esimerkiksi UML:n käyttötapauskuvaukset ovat yleinen tapa kuvata ohjelmistovaatimuksia, mutta niistä ei saa kokonaiskuvaa siitä, miten ratkaisu tulee tukemaan kokonaistoimintaa, eivätkä ne useinkaan ole riittävän ymmärrettäviä loppukäyttäjille. Käyttöliittymien tai käyttöliittymäkuvien suunnittelua voidaan käyttää hyväksi vaatimusten ja käsitteiden keräämisessä, tarkentamisessa ja validoinnissa. Tällöin ohjelmistoratkaisuja voidaan jo ennen ohjelmistosuunnitteluvaihetta peilata työprosesseihin, joissa ohjelmistoja tullaan käyttämään. Kuva käyttöliittymästä on havainnollinen tapa sitoa yhteen ketjun eri vaiheet ja lisätä erityyppisten asiantuntijoiden yhteistä ymmärrystä. Myös valmiiden prosessimallien täydentäminen käyttöliittymäkuvilla auttaa havainnollistamaan ratkaisuja käyttäjien näkökulmasta. Tietojärjestelmähankkeissa mallinnuksessa on kiinnitettävä huomiota tietovaatimusten jäljitettävyyteen. ActAD-malli mahdollistaa tiedon ja tietojärjestelmien kuvaamisen toimintajärjestelmän osana, ja jo yleiskuvan tai työprosessitason kuvauksien perusteella voidaan hahmottaa alustava tietoarkkitehtuuri. Itse tiedon yksityiskohtaiseen mallintamiseen ja luokitteluun tietojärjestelmän osana ActAD ei anna valmista ratkaisua, vaan vaatimusten tarkentamisessa ja ratkaisujen suunnittelussa on hyödynnettävä tarkempia tietomalleja, joita voidaan kuvata esim. UML:n luokkakaavioilla ja tietohakemistoilla. Mallinnuksessa on huolehdittava tietomallien jäljitettävyydestä korkeamman abstraktiotason malleihin sekä toimialan omiin käsitteisiin. Kuvaan 15 on koostettu esimerkki jäljitettävästä mallinnusketjusta, jossa toiminnan kokonaiskuvaa mallinnetaan ActADin avulla, halutut koh-

58 56 teet tarkennetaan prosessikuvauksiksi ja edelleen käyttöliittymäkuviksi ja käyttötapauskaavioiksi. Toimintalähtöinen kehittämismalli kattaa kohdealueen mallintamisen sekä asiakasvaatimusten keräämisen ja dokumentoinnin mallinnusketjussa tähän saakka. Ohjelmistosuunnittelun tehtävänä on huolehtia jäljitettävyyden takaamisesta ketjussa eteenpäin. (Mykkänen ym ) Kuva 15. Jäljitettävä mallinnusketju (Mykkänen ym. 2006).

59 57 4 KOKEMUKSIA KEHITTÄMISMALLIN SOVELTAMISESTA Tässä luvussa esitellään sitä käytännön työtä, toimintatutkimusta (Aaltola & Syrjälä 1999), jonka avulla edellä esitettyä toimintalähtöistä tietojärjestelmien kehittämismallia on työstetty. Lähtökohtana olivat aikaisemmat kokemukset sekä olemassa olevat menetelmät ja niiden muokkaaminen, kehittäminen ja täydentäminen. Piloteissa osallistuttiin organisaatioiden omiin kehittämishankkeisiin. Näin organisaatiot saivat käyttöönsä tutkimushankkeen edustajien asiantuntemusta ja tutkijat käytännön kokemuksia. Seuraavana on kooste piloteista, joihin ZipIT-hankekokonaisuuden tutkimusryhmä on osallistunut. Pilotin nimen jälkeen on lyhyesti kuvattu, mistä pilotissa oli kyse. Joihinkin pilotteihin tutkimusryhmän jäsenet osallistuivat aktiivisesti suunnittelijoina ja toteuttajina, joissakin oltiin lähinnä tarkkailijan roolissa. Kuvassa 16 pilotit on sijoiteltu tietojärjestelmän kehittämisen eri vaiheisiin. 1. HOITOPALAUTE (HOPA). Tiedontarpeiden ja tiedonkulun kehityskohtien kartoitus. Kartoitettiin yhteisen potilaan hoitoon osallistuvien toimijoiden tiedon tarpeet tilanteessa, jossa hoito tapahtuu perusterveydenhuollon ja erikoissairaanhoidon organisaatiossa monen eri toiminnan muodostamassa verkossa. 2. RÖNTGEN. Toiminnan muutosten ja tiedontarpeiden kartoitus tilanteessa, jossa manuaalisesta kuvantamisesta ollaan siirtymässä digitaaliseen. 3. LÄÄKEHOIDON SÄHKÖISEN SUUNNITTELUN JA KIRJAAMISEN KEHITTÄMINEN. Selvitettiin lääkehoidon tietojärjestelmien nykytilaa vuodeosastolla ja mallinnettiin potilastietojärjestelmän lääkehoito-osion käyttäjätarpeita käyttöliittymäkonseptiksi. "Asiakas" Esiselvitys Markkinointi Koodaus Vaatimusmäärittely Suunnittelu Testaus Ohjelmisto- Ohjelmistotaltuotantoprosessi Myynti Ylläpito Tietojärjestelmän kehittäminen asiakasorganisaatiossa Asiakas 9 Koulutus Käyttöönotto Esiselvitys Valinta ja ostaminen Tuotantokäyttö Tarjouspyyntö Vaatimusmäärittely 8 Kuva 16. ZipIT-pilotit sijoiteltuna kohdeorganisaation tietojärjestelmän kehittämisprosessia kuvaavalle nuolelle

60 58 4. SÄHKÖISEN POTILASJÄRJESTELMÄN KÄYT- TÖÖNOTTO. Suunniteltiin uuden ohjelmiston käyttöönottoon valmistautumista. Pilotissa tutkittiin keinoja siihen, miten käyttäjät voivat itse osallistua tulevan muutoksen suunnitteluun sekä siihen, miten tässä syntyneitä tietoja voidaan hyödyntää esimerkiksi käyttökoulutuksissa. 5. KOTIHOIDON MOBIILISOVELLUS. Osallistuttiin ohjelmistoyrityksen hankkeeseen, jossa suunniteltiin ja pilotoitiin kotihoidon kenttätyötä tukevaa tietojärjestelmää. 6. TEKNOLOGIALLA MUUTOSTA KOTIHOI- DON TOIMINTAPROSESSEIHIN (TEKO). Laadittiin alkukartoitus kotihoidon nykykäytännöistä ja toimintaympäristöstä Sotkamossa. Seurattiin kotihoidon kenttätyötä tukevan tietojärjestelmän prototyypin kehittämistä. 7. TOIMENPIDEJÄRJESTELMÄN HANKINTA JA UUSIMINEN. Pilotissa työskentely jakaantui kahteen tavoitteeseen: 1.) osallistumiseen järjestelmähankinnan vaatimusmäärittelytyöhön ja 2.) työssä käytetyn vaatimusmäärittelyprosessin kuvaamiseen ja arviointiin, joka toteutettiin työskentelyyn osallistuneiden itsearviointina. 8. KÄYPÄHOITO. Selvitys Käypähoito-suositusten käytöstä. Tehtiin ohjelmiston käytettävyystutkimus sekä käyttäjähaastattelut ohjelmiston käytöstä. 9. SILMÄNPOHJAKUVANTAMINEN. Selvitettiin silmäpohjakuvantamisen nykykäytännöt. 10. TOIMINTALÄHTÖINEN TIEDONHALLINNAN MUUTOSTUKI. Hankkeessa tutkittiin sitä, miten tiedonhallinnan muutosten keskellä kamppailevat äitiyshuollon työntekijät sekä perusterveydenhuollon että erikoissairaanhoidon puolella voisivat omista lähtökohdistaan kehittää teknistä ja sosiaalista työympäristöään arjen realiteettien puitteissa. Seuraavissa kappaleissa käsitellään yksityiskohtaisemmin kunkin pilotin tavoitteita, hankkeen etenemistä ja syntyneitä tuloksia. Niiden toivotaan auttavan tämän oppaan soveltajia löytämään sopivia tapoja hyödyntää esitettyä toimintalähtöistä tietojärjestelmien kehittämismallia omissa hankkeissaan.

61 Hoitopalaute Sähköisen potilaskertomuksen käyttöönotto sekä perusterveydenhuollossa että erikoissairaanhoidossa mahdollistaa teknisesti sähköisen tiedonvälityksen eri organisaatioiden välillä. HoPa-pilotti liittyi sähköisen lähete-palaute-konsultaatiokäytännön kehittämiseen. Yksi kehittämisen osa-alue on laajennettu hoitopalaute, joka käsittää lääketieteellisen epikriisin lisäksi muutakin asiakkaan hoidossa tarvittavaa tietoa. Nykyään näitä tietoja kirjataan sekä manuaalisiin että sähköisiin järjestelmiin; osa tiedoista jää lähettävään tai palauttavaan organisaatioon ja vain osa siirtyy toiseen. Tässä pilotissa haettiin käsitystä siitä, mitä asiakokonaisuuksia hoitopalautteeseen tulisi sisällyttää, miten ja milloin tietojen tulisi olla käytettävissä ja kuka näitä tietoja tuottaa. Pilotti suunniteltiin ja toteutettiin yhteistyössä kahden sairaanhoitajan (erikoissairaanhoito) kanssa. Aluksi hahmotettiin yleiskuvaa lähete-hoitopalauteketjun kontekstista eli asiakkaan hoitoketjusta perusterveydenhuollon ja erikoissairaanhoidon yhteistyössä. Selvitystyön tavoite määriteltiin seuraavasti: Halutaan turvata potilaan saaman hoidon jatkuvuus. Selvitetään ja kuvataan, mitkä ovat ne oikeat, riittävät, ajantasaiset ja helposti käytettävät tiedot, joita jatkohoidossa tarvitaan ja ketkä niitä tarvitsevat. Selvitystä tehtiin neljässä työpajassa, joissa tarkennettiin kuvaa hoitoketjusta: ketkä hoitoon osallistuvat, mitä toisessa organisaatiossa tuotettua tietoa tarvitaan, kuka tätä tietoa tarvitsee, missä hoidon vaiheessa ja miten tietoa nyt saadaan. Lisäksi nostettiin esille tiedonkulun kehityskohtia ja pohdittiin ratkaisuehdotuksia. Työpajoihin osallistui eri ammattiryhmien edustajia molemmista organisaatioista. Hoitoketjua tarkasteltiin täsmällisemmin palasissa: tarkasteltiin asiakkaan hoitoa perusterveydenhuollossa ennen erikoissairaanhoitokäyntiä ja käynnin jälkeen sekä erikoissairaanhoidossa tapahtuvaa hoitoa. Asiakaan hoitoketjua hahmoteltiin ActAD-mallin avulla (kuva 17) ja mallinnettiin tarkemmin kalanruotokaaviolla (kuva 18). Hoitoketjua konkretisoitiin myös toimintatarinan avulla (kuva 8 sivulla 47). Moniammatillisuus oli tärkeä tekijä sekä suunnittelu- että tiedonkeruuvaiheiden ryhmäkeskusteluissa. Eri ammattiryhmien välillä syntyneistä keskusteluista nousi esille hoitoketjuun liittyviä seikkoja, joita ketjun ulkopuolinen ei välttämättä olisi osannut edes kysyä. Toisaalta moniammatillisten ryhmähaastattelujen järjestäminen oli haasteellista esimerkiksi kalenterien yhteensovittamisen vuoksi. Erilaisten kaavioiden ja toimintatarinan käyttö oli hyödyllistä keskustelujen tukena. Tuotoksena HoPa-projektista on Laajen- PERUSTERVEYDENHUOLTO TERVEYSKESKUS ERIKOISSAIRAANHOITO PERUSTERVEYDENHUOLTO TERVEYSKESKUS LAB.HOIT. SAIR.HOIT. TERVEYSKESKUS- HOIDOT LÄÄKÄRI LAB.HOIT. LABORATORIO NÄYTTEENOTTO JA TULOKSET LÄÄKÄRI ASIAKAS SAIR.HOIT. LABORATORIO NÄYTTEENOTTO JA TULOKSET LÄÄKÄRI SAIR.HOIT. LAB.HOIT. LABORATORIO NÄYTTEENOTTO JA TULOKSET KOTI- SAIR.HOIT. OHJELMISTO Y LÄHETE OHJELMISTO X Haava Hoidettu haava EPIKRIISI KOTI- SAIR.HOIT. OHJELMISTO Y TERVEYSKESKUS- OMAINEN HOIDOT KODIN- HOITAJA ASIAKAS KODIN- HOITAJA OMAINEN HOITOTOIMET ASIAKAS KOTIHOITO KOTIHOITO Kuva 17. Asiakkaan hoitoketju (yleiskuva).

62 60 netun hoitopalautteen tiedon tarpeet -selvitys. Selvityksessä kuvataan sekä kaavioina että sanallisesti nykyisiä sairaalan ihotautipoliklinikan ja kaupungin terveyskeskuksen välistä lähete- ja hoitopalautekäytäntöä sekä sen keskeisimpiä kehityskohtia (asiakokonaisuuksia; laboratoriokokeiden ja -tulosten näkyvyys, lääkitystiedon eheys ja ajantasaisuus, haavapiirrosten tallennus ja näkyvyys, hoitajan antaman hoito-ohjeen liittäminen hoitopalautteeseen). Selvitystä voidaan hyödyntää tietojärjestelmien, työnkulun ja -rutiinien kehittämisessä sekä erikoissairaanhoidon että perusterveydenhuollon organisaatioiden sisällä että organisaatioiden välillä. Lisätietoja Hoitopalaute-pilotista: Laajennetun hoitopalautteen tiedon tarpeet: Raportti Hoitopalaute-projektin tutkimustuloksista (Minkkinen, Mursu & Häkkinen 2006). Kutsu POLI- KORTTI - siirrosta sopiminen ASIAKAS TK VASTAAN OTTO - käyntitiedot OHJELMISTO Y TK KOTISAI- RAANHOI TO - tiedot + hoidot - muut palvelutarpeet KOTI- PALVELU HAAVA- HOITO-OHJE RESEPTI MAREVAN LÄHETE Ohjelmisto Z Suunnitelma (kiireellisistä) OHJELMISTO X Sairaala labra - bakteeriviljelytulos Bakteeriviljely Labrat (vastaukset Antibioottiresistenssi luvalla & pyynnöt) potilaan nähtävillä Sairaala osasto - siirrosta OHJELMISTO Y sopiminen TK Sairaala KOTISAIpotilas- RAANHOI toimisto TO -lisätiedot - ilmoitus hoidosta siirrosta Kotihoitokansio potilaan mukana ja sisältää ajantasaiset tiedot (lääkehoito) HAAVA- HAAVA- HOITO-OHJE HOITO-OHJE Oma tekstipohja - sairauskertomukseen - potilaan mukaan Hoito-ohje Ohje sähköisesti epikriisin terveyskeskukseen mukaan LÄÄKE KORTTI POLI KORTTI SAIRAAN- HOITAJA (POLI) SAIRAAN- HOITAJA (OSASTO) SAIRAAN- HOITAJA (POLI) LÄÄKÄRI SAIRAAN- HOITAJA (POLI) SAIRAAN- HOITAJA (OSASTO) LÄÄKÄRI V KONE- KIRJOITTAJA POTILAS- TOIMISTON ASIAKAS VIRKAILIJA Ohjelmisto Z OSASTO- SIHTEERI OSASTON YLILÄÄKÄRI LÄÄKÄRI V OSASTO- SIHTEERI Lähetteen vastaanotto HERÄTE? Kiireellisyyden arviointi Ajanvaraus ja kutsu Ilmoittautuminen Laskutustietojen asiakkaalle varmistaminen ASIAKKAAN RESURSSIEN VASTAAN- HOITO VARAAMINEN OTTO POLILLA Hoitopäätös SIIRTO OSASTOLLE Hoitosuunnitelma Epikriisi sanelu kirjotus, tulostus, postitus HOITO OSASTOLLA Kotiutuksen valmistelu KOTIUTUKSEN VALMISTELU Todistukset esim. KELAkorvausta varten Kotiutuskyydin tilaaminen KOTIUTUS Kuva 18. Asiakkaan hoitoketju erikoissairaanhoidossa.

63 Röntgen Röntgen-pilotissa lähtötilanteena oli se, että perusterveydenhuollon organisaatiossa valmisteltiin selvitystä vantamisesta ja digitaalisesta levykuvantamisesta raan digitaaliseen kuvantamiseen ja arkistointiin. Tähän selvitystyöhön liittyvässä pilotissa mallinnettiin ja analysoitiin röntgentoiminnan nykytilaa sekä visioitiin toiminnan tavoitetilaa yhdessä röntgenosaston työntekijöiden kanssa. Liikkeelle lähdettiin röntgentoiminnan nykytilan ja toiminnan yleiskuvan hahmottamisesta sekä röntgenosaston toimintaympäristön, -prosessien, tiedonkulun ja sidosryhmien selvittämisestä. Ensimmäiseksi tutkimusryhmän edustaja suunnittelija teki tutustumiskäynnin röntgenyksikköön. Käynnillä tutustuttiin röntgenin tiloihin ja kuvantamisessa käytettäviin ohjelmistoihin ja laitteisiin sekä tavalliseen röntgenkuvausprosessiin. Lisäksi hankittiin myös taustatietoa kohdeorganisaation röntgentoiminnasta: koottiin tilastoja tehtävistä tutkimuksista, henkilöstömäärästä, työnjaosta, sidosryhmistä, toiminnan suuntaviivoista ja tulevaisuuden strategioista. Tutustumiskäynnin pohjalta tutkimusryhmän edustaja työsti erilaisia kuvia ja kaavioita (esim. kuva 19) röntgentoiminnasta sekä kirjoitti dokumentin, joka sisälsi yleistasoisen kuvauksen nykytilasta sekä tavallisen röntgenkuvausprosessin päävaiheista. Seuraavaksi röntgenosaston työntekijöille järjestettiin kaksi työpajaa. Röntgenosaston kannalta tärkeintä oli miettiä, miten digitaaliseen kuvantamiseen ja arkistointiin siirtyminen vaikuttaisi nykyisiin toimintatapoihin ja työkäytäntöihin ja minkälaisia toiminnan reunaehtoja digitalisoinnissa on huomioitava. Ensimmäisessä työpajassa käytiin yhdessä myös läpi röntgentoiminnan nykytilaa kuvaa 16 apuna käyttäen sekä visioitiin tulevaisuuden toimintaa. Toisessa työpajassa pääpaino oli digitaaliseen kuvantamiseen tutustumisessa sekä tulevaisuuden röntgentoiminnan vaihtoehtojen tarkastelussa. Työpajojen aikataulut, ohjelmat ja käytettävät menetelmät pyrittiin suunnittelemaan niin, että työpajoissa syntyisi mahdollisimman paljon keskustelua. Menetelminä käytettiin muiden muassa toimintatarinoita, pienryhmätyöskentelyä, työnkulkukaavioiden piirtämistä (kuva 20), dokumentointia (muistiot), vertaisvierailijaa sekä tulevaisuuden toiminnan eri vaihtoehtojen läpikäymistä ja niistä valitsemista. Erityisesti toiseen työpajaan mukaan saatu vertaisvierailija jo digitaaliseen kuvantamiseen ja arkistointiin siirtyneestä perusterveydenhuollon röntgenyksiköstä osoittautui hedelmälliseksi tavaksi saada tietoa ja kokemuksia odotettavissa olevista työprosessien muutoksista. Myös työpajatyöskentelyn ja erityisesti oman työn ja sen kehittämisen pohtimisen röntgenosaston työntekijät kokivat erittäin positiivisena. Röntgen-pilotin suunnittelu- ja vetovastuu oli tutkimusryhmällä, josta pilottiin nimettiin yhteyshenkilö. Lisäksi tutkimusryhmän edustajia oli mukana suunnittelemassa ja toteuttamassa työpajoja. Myös röntgenosaston yhteyshenkilö oli tiiviisti mukana suunnittelussa, ja osaston kaikki työntekijät osallistuivat työpajoihin. Pilotissa tuotettiin esiselvitysraportti osaston siirtymisestä digitaaliseen kuva-arkistojärjestelmään. Raporttiin koottiin eri vaiheiden tulokset, ja sen työstivät röntgenosaston ja tutkimusryhmän yhteyshenkilöt. Selvitysraporttia voidaan tulevaisuudessa hyödyntää varsinaisessa digitaalisen arkiston käyttöönottoprojektissa. Uuden tekniikan mahdollistamien toiminnan muutosten hahmottaminen osoittautui varsin hankalaksi tehtäväksi, ja pilotin aikana pidetyissä kahdessa työpajassa se saatiin vasta alkuun. Pilotissa röntgentoiminnan tavoitetilaa hahmoteltiin lähinnä prosessi- ja työnkulkutasolla, mutta myöhemmin myös tavoitteen yleiskuvaa pitää vielä täsmentää sekä tarkentaa toimintalähtöisiä vaatimuksia laite- ja järjestelmähankinnoille. Ennen tarkemman tason määrittelyjä pitää myös selvittää tavoitetilan reunaehtoja, kuten taloudellisia edellytyksiä toiminnan järjestämiseen toivotulla tavalla ja alueellisen yhteistyön mahdollisuuksia, sekä laajentaa näkökulmaa ottamalla mukaan röntgenin eri sidosryhmiä. Lisätietoja Röntgen-pilotista raportissa Esi-

64 62 selvitys digitaaliseen kuva-arkistojärjestelmään siirtymisestä Kuopion kaupungin sosiaali- ja ter- veyskeskuksen röntgenosastolla - Toiminnan nykytila ja tavoitetila (Mononen 2005). Kuva 19. Työnkulkukaavio röntgenkuvausprosessista. Kuva 20. Tulevaisuuden röntgenkuvausprosessin työnkulkukaavio.

65 Lääkehoidon sähköisen suunnittelun ja kirjaamisen kehittäminen Tässä pilottihankkeessa tutkimusryhmän edustajat osallistuivat suuren sairaalan lääkehoidon kirjaamisen kehittämishankkeeseen. Tutkimusryhmän edustajat keskittyivät ensisijaisesti potilaan lääkehoidon sähköisen suunnittelun ja seurannan kokonaisnäkymän määrittelyyn. Tavoitteena oli tuottaa ohjelmistotalolle ehdotuksia potilaskertomusjärjestelmän lääkitystietoja koskevan osion kehittämiseksi. Suunnittelun lähtökohtana oli kliinisen työn tekijöiden esittämä tarve nähdä potilaan lääkityksen kokonaistilanne kertasilmäyksellä. ZipIT-hankkeen suunnittelijat perehtyivät aluksi lääkehoitoon lukemalla alan oppikirjoja ja haastattelemalla vuodeosastolla työskennellyttä sairaanhoitajaa. Vaikka suunnittelutehtävä rajoittui lääkehoidon sähköiseen suunnitteluun ja seurantaan, oli kokonaiskuvan saamiseksi tärkeä perehtyä lääkehoitoon laajemmin. Tässä vaiheessa tunnistettiin lääkehoitoon liittyviä kliinisiä ja tukiprosesseja (mm. lääkkeiden säilytys ja tilaus) ja jäsenneltiin suunnittelijoiden työn tueksi vuodeosaston potilaan lääkehoidon ydinprosessi. Myöhemmässä vaiheessa suunnittelijat havainnoivat lääkkeiden annostelua vuodeosastolla, lääkärin kiertoa ja sähköisen potilaskertomusjärjestelmän käyttöä sekä keräsivät lääkehoidossa käytettäviä, täytettyjä paperilomakkeita. Havainnoinnit dokumentoitiin pääasiassa valokuvin ja nauhoittamalla haastatteluja. Paljon tietoa saatiin myös osallistumalla lääkehoidon kirjaamisprojektin työskentelyyn. Potilaskertomusjärjestelmän osaksi toteutettua lääkitystieto-osiota arvioitiin heuristisesti, ja lääkehoidon kirjaamisen kehittämisprojektin kliinisen työn tekijöitä pyydettiin arvioimaan löy- vioinnin tulokset raportoitiin kehittämisprojektille, sairaalan tietohallinnolle ja lääkitystieto-osion toteuttaneelle ohjelmistotalolle. Suunnittelijoiden oman ymmärryksen lisäämiseksi lääkehoidon termejä ja tietoja koottiin miellekarttoihin (mindmap). Niitä analysoitiin seinätaulutekniikalla, jonka avulla pyrittiin kuvaamaan käsitteiden suhteita toisiinsa ja ryhmittelemään tiedot loogisiksi kokonaisuuksiksi ja tietohierarkioiksi. Joidenkin keskeisten tai hankalien tietokokonaisuuksien analysointia jatkettiin esimerkiksi piirtämällä niistä tietokoneavusteisesti yksityiskohtaisempia kaavioita. Tällaisia kokonaisuuksia olivat esimerkiksi lääkityksen suhde aikaan sekä lääkkeen annosteluun ja lääkemääräykseen liittyvät tiedot. Tässä vaiheessa tunnistettiin joitain lääkehoidon sähköiselle kirjaamiselle asetettavia yleisen tason käyttäjätarpeita, jotka täsmentyivät ja yksityiskohtaistuivat tavoitetilan suunnittelussa. Huomattiin myös lääkehoidon tietojen olevan hyvin moninaisia ja erilaisia poikkeuksia olevan paljon. Tiedon rakenteistaminen ilman, että se hankaloittaa kirjaamista, on hyvin haasteellista ja ehkä mahdotonta. Yhtenä vaikeimmin rakenteistettavana asiana pidettiin lääkemääräyksen annostelua ja annosteluohjetta muissa kuin aivan yksinkertaisimmissa tapauksissa. Tässä lääkehoidon kirjaamisen kehittämisprojektissa tutkimusryhmän edustaja mallinsi tiedonhankintavaiheessa tunnistetut vaatimukset käyttöliittymäkuviksi (kuva 18), joita käytiin läpi sairaalan lääkehoidon kehittämisryhmän työpalavereissa. Kliinisen työn tekijät arvioivat ja kommentoivat ehdotuksia, ja näiden kommenttien perusteella suunnitelmia kehitettiin edelleen. Työ eteni iteratiivisesti. Terveydenhuollon ammattilaiset kertoivat, mitä he lääkehoidon sähköisen kirjaamisen järjestelmältä odottavat; tutkimusryhmän edustajat puolestaan suunnittelivat vuorovaikutus- ja käyttöliittymäratkaisuja, joiden avulla nämä odotukset pyrittiin täyttämään. Tällaista suunnittelutapaa sanotaan yleisesti protoiluksi. Käyttöliittymäluonnokset piirrettiin ensin käsin paperille ja seuraavissa vaiheissa Microsoft Visio ja PowerPoint-ohjelmilla. Piirtovälineellä ei sinänsä ole väliä, kunhan suunnittelijalla on riittävästi vuorovaikutus- ja käyttöliittymäsuunnittelun osaamista. Suunnittelijat testasivat käyttöliittymäratkaisuja käyttäjän tavoitteen ja siihen liittyvien tietojen avulla jo ennen kuin niitä esitettiin käyttä-

66 64 jille. Pieniä muutoksia käyttöliittymäkuviin tehtiin myös yhdessä käyttäjien kanssa työpalavereissa, mikä nopeutti suunnitteluprosessia. Suunnittelutyön rinnalla tiedonhankintaa jatkettiin havainnointien ja haastattelujen avulla, sillä suunnitteluongelmat toivat esiin sellaisia tiedontarpeita, joita ei ennen suunnittelun etenemistä ollut osattu ennakoida. Tässä pilottihankkeessa käyttöliittymäkuvia käytettiin sairaalan oman työn tukena ja kliinisen työn tekijöiden työvälineohjelmistolle asettamien tarpeiden mallintamiseen. Käyttöliittymäkuvien avulla ei siis määritelty käyttäjävaatimuksia ohjelmistotaloa varten, vaikka kuvattujen työvaiheiden ja käytettyjen suunnittelumenetelmien avulla se olisi ollut täysin mahdollista. Myöhemmin käyttöliittymäkonseptia käytettiin ohjelmistotalon järjestämän määrittelyryhmän palavereissa esittämään sairaaloissa työskentelevien kliinisen työn tekijöiden tarpeita ohjelmistotalon edustajien ymmärtämässä muodossa. Sitä käytettiin myös ohjelmistotalon määrittelytyön yhtenä lähtökohtana. Saatujen kokemusten mukaan kaikki käyttäjävaatimukset voitiin kuvata käyttöliittymäkuviksi tai kuvasarjoiksi, Kuvat muodostivat yhteisen mallinnuskielen vaatimusmäärittelyyn osallistuvien osapuolten välille, joten yhteisen ymmärryksen varmistaminen oli mahdollista. Lisäksi käyttöliittymäkuvat konkretisoivat kliinisen työn tekijöille ohjelmiston työtoimintaan tuomat mahdollisuudet ja rajoitukset. Sen ansiosta heidän oli helpompi suunnitella siirtymistä paperijärjestelmästä sähköiseen sekä siirtymän aiheuttamia työtoiminnan muutoksia. Lisätietoja Lääkehoidon sähköisen suunnittelun ja kirjaamisen kehittämispilotista on saatavilla Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivien tutkimuspapereiden artikkelista Tapaus lääkehoito: Kokemuksia käyttöliittymäkuvista ohjelmiston käyttäjävaatimusten määrittelyssä (Martikainen, Silvennoinen & Ikävalko 2006) ja pohjoismaisen Iscar-konferenssin esitelmästä Participatory and Collaborative Methods in User Interface Designing: The Case of Electronic Planning and Follow-Up Medical Care in the Finnish University Hospital Unit (Ikävalko et. al 2007). Lisäksi on saatavilla raportti lääkehoidon sähköisen suunnittelun ja seurannan käyttöliittymäkuvien suunnitteluperusteista (Martikainen ja Silvennoinen 2006). Kuva 21. Puhekuplat vuorovaikutuksen työkaluina.

67 Sähköisen potilastietojärjestelmän käyttöönotto Tämän pilottihankkeen lähtötilanne oli se, että erikoissairaanhoidon organisaatiossa oltiin valmistautumassa sähköisen potilastietojärjestelmän käyttöönottoon. Sellainen oli otettu jo aikaisemmin käyttöön poliklinikoilla, ja pilotointivaiheen jälkeen, vuoden 2007 loppuun mennessä se oltiin ottamassa käyttöön kaikilla vuodeosastoilla ja diagnostisilla erikoisaloilla. Tavoitteena oli ottaa huomioon ja suunnitella etukäteen sitä toiminnan muutosta, jonka uuden tietovälineen tuominen osastoille aiheuttaisi. Osastojen henkilökunnan ja kouluttajien väliseen yhteistyöhön haettiin uusia toimintatapoja ja apuvälineitä, joita voitaisiin hyödyntää käyttöönottokoulutuksessa ja joiden avulla osastojen henkilökunta voisi myös itsenäisesti valmistautua muutokseen. Osastoilla oli valittu muutama henkilö mentoreiksi, jotka koulutettiin muuta henkilökuntaa aikaisemmin potilastietojärjestelmän käyttöön ja joiden tehtävänä oli osallistua valmisteluun ja toimia muun henkilökunnan tukena käyttöönottovaiheessa. ZipIT-tutkimusryhmä aloitti yhteistyön mallintamalla kahden potilastietojärjestelmän käyttöönottoon osallistuvan pilottiyksikön tyypillisimmän asiakasryhmän palveluprosessit. Molemmat yksiköt valitsivat itse kohderyhmän, jonka palveluprosessin nykytila kartoitettiin haastattelemalla yksikön henkilökuntaa (sairaanhoitajia, fysioterapeuttia ja osastonsihteeriä). Tällä haluttiin saada selville, minkä ammattiryhmien kautta asiakas yksikössä kulkee. Lisäksi selvitettiin, mihin asiakkaan käynnillä muodostuva tieto tallennetaan ja mitä jo aiemmin syntynyttä tietoa tarvitaan. Samalla kartoitettiin, mitä tietovälineitä (esimerkiksi paperinen sairauskertomus, perinnejärjestelmät tietokoneella) asiakkaan hoitojakson aikana tarvitaan. Kaaviot tarkistutettiin haastatteluihin Päivitys Sairaanhoitaja Sähköinen potilasraportti Sairaanhoitaja Aamu-,ilta-, ja yövuoro Sokeri Keskustelu Lab. hoitaja Potilas Toiminta: Laboratorio PEF Saturaatio Potilasraporttituloste Laboratoriojärjestelmän arkisto Potilaskansio Kuvaarkisto Lääk. Sh Os.siht. Aikaisemmat Sairaalakäynnit (poli, osastot) Seurantalaitteen tulosten purku Sairaanhoitaja Lääkäri Sairaanhoitaja Potilas Lääkäri Muistilaput Kooste osaston potilaiden tilanteen seurannasta Toiminta: Lääkärin kierto Kannettava Päätös potilaiden tarvittavista toimenpiteistä ja jatkohoidoista Lääkäri Pyyntö, ajanvaraus määräys Potilaskansio Havainnointi toimiston tussitaulu Potilas Toiminta: Röntgen Potilas Fys. ter. Kuva 22. ActAD-malliin pohjautuva rikastettu kaavio lääkärinkierrosta. Toiminta: Fysioterapia

68 66 osallistuneilla, jotta päästiin yhteiseen ymmärrykseen. Kaavioihin tehtiin pieniä korjauksia, minkä jälkeen kaaviot katsottiin vielä kerran yhdessä haastateltujen kanssa. Asiakasprosessien ja niissä tarvittavan tiedon ja tietovälineiden kartoittamisen jälkeen haastateltiin ja havainnoitiin eri henkilöstöryhmiä ja työprosesseja, jotta saataisiin selville yksikön toiminnan yleiskuva henkilökunnan näkökulmasta. Haastateltavat henkilöt ja havainnoitavat prosessit valittiin siten, että ne edustivat yksikön toimintaa mahdollisimman moniammatillisesti ja kattavasti. Haastatteluihin ja havainnointeihin osallistui useita tutkijoita kerrallaan. Esimerkiksi lääkärinkiertoa oli havainnoimassa neljä tutkimusryhmäläistä, joista jokaisella oli oma havainnointialue, esimerkiksi tietojen kirjaaminen ja tietovälineiden käyttö. Lisäksi tutkimusryhmälle järjestettiin potilastietojärjestelmän käyttökoulutusta, jotta työryhmä pystyi ymmärtämään järjestelmän toimintaa. Henkilökunnan haastattelut kirjoitettiin auki. Haastatteluissa ja havainnoinneissa kerätty tieto analysoitiin. Yksikön toiminnan kokonaisuutta ja niihin liittyviä tietovälineitä havainnollistettiin seinätaulutekniikan, taulukoiden ja kaavioiden avulla, esimerkkinä tästä on kuva lääkärinkierrosta (kuva 22). Kun nykyinen toiminta ja tietovälineet oli kuvattu, nimettiin ne tehtäväkokonaisuudet, joihin tuleva potilastietojärjestelmän käyttöönotto vaikuttaa. Muuttuvien tehtäväkokonaisuuksien kartoittamiseen käytettiin apuna myös yksiköissä pidettyjä työpajoja, joihin osallistui yksikön henkilökuntaa sekä mentorit. Tässä vaiheessa tarkastelua laajennettiin ottamaan huomioon yksikön useimmat asiakasryhmät. Näin jo aiemmin kartoitetut asiakasprosessit saatiin linkittymään henkilökunnan työprosesseihin. Samaan aikaan kartoitettiin myös yhteistyön välineitä, työtapoja ja yksiköiden erityispiirteitä. Esimerkki eri ammattiryhmien välisen yhteistyön välineestä on vaikkapa kanslian viestitaulu, johon kirjataan kotiutuvien ja fysioterapiaa tarvitsevien asiakkaiden nimet. Tältä viestitaululta osastosihteerit saivat tiedon vapautuvista vuodepaikoista ja fysioterapeutti näkee työpäivälle suunnitellut asiakkaat. Esimerkki yksikön erityispiirteestä on muun muassa lukuisten kontrollimittausten (verenpaine, pulssi ja erikoisalaan liittyvät erityismittaukset) merkitseminen erillisille lomakkeille. Haastatteluin ja havainnoinnein kerätyn aineiston työstämisen jälkeen tutkimusryhmä havaitsi, että käytettävissä olevin resurssein ei ole mahdollista mallintaa kattavasti koko osaston nyky- ja tavoitetiloja sekä suunnitella toimenpiteitä tavoitteiden saavuttamiseksi. Keskustelujen perusteella päädyttiin kohdistamaan huomio niihin toimintoihin ja tietovälineisiin, jotka muuttuvat potilastietojärjestelmän tullessa käyttöön. Tutkimusryhmässä nousi esille asioita, jotka on sovittava yksiköissä ennen käyttöönottoa (esimerkiksi kuka tulostaa arkistoitavan hoitokertomustekstin). Lisäksi tuli esille asioita, jotka on sovittava organisaation tasolla (esimerkiksi nestevuorokauden vaihtumisaika on yhtenäistettävä eri yksiköissä). Tutkimusryhmä tuotti yhteistyöorganisaation käyttöön ja edelleen työstettäväksi Mentoripaketin, joka toimii yhtenä käyttöönottoon valmistautumisen apuvälinenä osastoilla. Mentoripaketissa kuvataan ja ohjeistetaan, mitä asioita osastoilla tulisi ottaa huomioon ennen käyttöönottoa ja miten osaston henkilökunta voi koulutuksen lisäksi valmistautua käyttöönottoon mentorien opastuksella. Ohjeissa kuvataan esimerkiksi sitä, kuinka toimintatarinan ja esimerkkipotilaan kansion avulla voidaan etsiä toimintakokonaisuuksia, joihin sähköisen järjestelmän käyttö tuo muutoksia. Lisätietoja Sähköisen potilastietojärjestelmän käyttöönotto-pilotista on luettavissa ZipIT-hankekokonaisuuden selvityksessä Sähköisen potilastietojärjestelmän käyttöönotto, työpaperi (Klemola ja Luukkonen 2007).

69 Kotihoidon mobiilisovellus Kotihoito poikkeaa muusta terveydenhuollon toiminnasta siinä, että se tapahtuu asiakkaan kotona. Hoitokokonaisuuteen osallistuu useita eri ammattiryhmiä, jotka voivat olla eri organisaatioista. Päävastuu kotihoidon järjestämisestä on perusterveydenhuollolla. Sen käytössä on sähköinen tietojärjestelmä, johon asiakkaan hoito suunnitellaan ja toteutumat kirjataan. Ohjelmisto on käytössä vain toimistolla, eli sen avulla asiakastietoja ei voida katsella eikä kirjata kotikäyntien aikana. Mobiili-pilotissa ohjelmistoyrityksen tavoitteena oli kehittää ja pilotoida kotikäynneillä käytettävä sovellus. Lähtötilanteessa ohjelmistoyritys oli jo tehnyt esiselvitys- ja kehitystyötä. Vastuu pilotin vetämisestä ja toteuttamisesta oli ohjelmistoyrityksellä. Terveydenhuollon organisaation rooli oli antaa tietoa kotihoidosta toimintana sovelluksen kehittämiseksi sekä koekäyttää sovellusta. Tutkimusryhmän rooli oli havainnoida käytettyjä työtapoja, olla aktiivisesti mukana työpajoissa (keskustelu ja muistiinpanot) sekä kerätä haastattelemalla pilotointikokemuksia. Työpajojen välissä ohjelmistoyrityksen ja tutkimusryhmän edustajat tapasivat palavereissa, joissa arvioitiin käytettyjä työtapoja ja saatuja tuloksia sekä suunniteltiin seuraavia toimenpiteitä. Pilotoinnin tavoitteet ja painotukset käytiin ennen työpajoja läpi osapuolten vastuuhenkilöiden kokouksessa. Kotihoidon toiminnan osa-alueita kartoitettiin kolmessa kotihoidon prosesseja valottavassa työpajassa, joissa mukana oli kotihoidon toimijoita (kotipalvelun ohjaajia, kodinhoitajia). Keskustelua ohjasi ohjelmistoyrityksen edustaja. Työpajoissa kerättiin tietoa kotihoidon kontekstista (mm. asiakas- ja työntekijämäärät, työalueet), asiakkaista (mm. asiakkaiden luokittelu ja hoitoisuus), kotihoidon työprosesseista (mm. työnjako, asiakkaan hoidon suunnittelu, asiakaskäynnit, kotimittaukset), kotihoidossa tarvittavista tiedoista (mm. lääkitys- ja ravitsemustiedot, erilaiset seurannat). Työpajojen jälkeen keskusteluista koostettiin muistiinpanot, joissa listattiin esille tulleet asiat sekä tavoitteet ja tehtävät seuraavaksi kerraksi. Ohjelmistoyrityksen edustaja osallistui kotihoidon asiakaskäynneille. Asiakaskäyntien havainnointi toi konkreettista tietoa työstä, esimerkiksi sen moninaisuudesta, rajoitteista ja asiakaskunnasta. Sovelluksen käyttöliittymää käytiin läpi myös työpajassa kotihoidon toimijoiden kanssa. Ohjelmistoyrityksen edustaja esitteli käyttöliittymää, joka heijastettiin dataprojektorilla seinälle kaikkien nähtäväksi. Kotihoidon toimijat tarkastivat ja kommentoivat käyttöliittymässä käytettyjä käsitteitä sekä sovelluksen toiminnallisuutta. Muutoksista osa korjattiin välittömästi sovellukseen, ja osa kirjattiin ylös myöhemmin toteutettavaksi. Kotihoidon ohjaajat kävivät keskenään läpi ja tarkistivat ohjelmistoyrityksen tuottaman tietoluettelon, listan prototyypin käsitteistä. Listan läpikäyminen koettiin haasteelliseksi, vaikka tukena oli prototyypin käyttöliittymäkuvat. Lisäksi ohjelmistoyrityksen edustajat ja terveydenhuollon organisaation tietotekninen väki tapasivat teknisessä työpajassa, jossa selviteltiin esimerkiksi teknisiä mahdollisuuksia tiedon siirtoon perusjärjestelmän ja uuden sovelluksen välillä, laitteistovaatimuksia, tietoliikenneverkon ominaisuuksia ja tietoturvakysymyksiä. Kotihoidon kaksi edustajaa koekäyttivät sovelluksen prototyyppiä ennen pilotointia. Ohjelmistoyritys pystyi saatujen kommenttien avulla hiomaan ja korjaamaan prototyyppiä ennen varsinaista pilotointia. Sovelluksen pilotointiin osallistui viisi kotihoidon työntekijää noin kuukauden ajan. Sovelluksen toimisto-osa toimi päätelaitteella kotihoidon toimistossa ja mobiili-osa matkapuhelimessa. Pilotoinnin aikana ilmenneisiin ongelmatilanteisiin löytyi ratkaisut joko ohjelmistoyrityksen tai terveydenhoidon organisaation teknisen tuen avulla. Käyttäjäkokemukset sovelluksesta ja laitteista kerättiin ryhmäkeskustelussa, jossa mukana olivat pilottikäyttäjät sekä ohjelmistoyrityksen ja tutkimusryhmän edustajia. Ohjelmistoyritys hyödynsi käyttäjäkokemuksia sovelluksen edelleenkehittämiseen. Pilotoinnin tulokset ja kokemukset esiteltiin yhteenvetona terveydenhuollon organi-

70 68 saation toimialajohdolle. Lisäksi tutkimusryhmä keräsi haastattelemalla osallistujien kokemuksia kehittämishankkeeseen osallistumisesta. Osallistujat kokivat osallistumisen positiivisesti, vaikka aikataulu olikin tiukka. Erityisen positiivisena koettiin mahdollisuus vaikuttaa oman työvälineen kehittämiseen. Prototyyppi ja käyttöliittymäkuvat toimivat hyvin havainnollisina työvälineinä kehitysvaiheessa. Myös prototyypin koekäyttäminen todellista työtilannetta mukaillen tuntui hyödylliseltä. Pilotointivaiheessa tärkeää oli sekä vertaistuki toisilta pilotoijilta että tekninen tuki ohjelmistoyritykseltä ja omalta tietotekniikan osastolta.

71 Teknologialla muutosta kotihoidon toimintaprosesseihin Vanhusten asumista kotona tutussa ympäristössä tuetaan mm. järjestämällä heille kotipalvelua ja kotisairaanhoitoa. Jotta pienenevälle joukolle kotihoidon ammattilaisia jäisi enemmän aikaa kotihoidon perustyöhön, joissakin kunnissa ollaan ottamassa tietotekniikkaa avuksi työhön liittyvien rutiinien hoitoon. Tämän pilotin kohteena oli kotihoito kuntayhtymän yhden kunnan alueella. Pilotti liittyi kohdeorganisaation omaan kolmiosaiseen hankkeeseen, jossa tavoitteena oli hakea teknologian avulla muutosta kotihoidon toimintaan. Hankkeen osa-alueet olivat seuraavat: Mobiili: Ohjelmistoyritys oli kehittämässä sovellusta, joka mahdollistaisi kotihoidon työhön liittyvän tiedon saannin ja kirjaamisen asiakkaan kotona. Ohjelmistoyrityksellä oli kehittämistyöhön oma projekti, jota tutkimusryhmän edustajat havainnoivat. Huoli: Kuntayhtymässä haluttiin kehittää huolimittari mittaamaan työntekijöiden kokemaa huolta asiakkaasta, mahdollistamaan tarpeenmukainen hoito asiakkaan toimintakyvyn jostakin syystä laskiessa ja mahdollistamaan asiakkaan siirtyminen kitkatta asumispalveluiden piiriin, kun kotona asuminen ei ole enää turvallista, inhimillistä tai muusta syystä mahdollista. Netti: Kuntayhtymässä haluttiin kokeilla tietoteknisiä mahdollisuuksia kotihoidon asiakkaiden omaisten kanssa tehtävään yhteistyöhön. Tämä osio käynnistyi tutkimusryhmän osallistumisen jälkeen. Pilotille asetettiin tavoitteeksi selvittää kotihoidon prosessikokonaisuus sekä se, miten prosessit muuttuvat uuden teknologian käyttöönoton myötä. Tutkimusryhmältä odotettiin apua mallintamiseen sekä terveydenhuollon ja IT-alojen lähentämiseen ja kommunikoinnin helpottamiseen. Pilottiin osallistui tutkimusryhmän kaksi edustajaa sekä kuntayhtymästä seitsemän kotihoidon työntekijää ja hankevastaava. Tiedot nykytilan kuvausta varten kerättiin ja tarkistettiin kuudessa työpajassa. Työpajat suunniteltiin hankevastaavan ja tutkimusryh- män edustajien yhteistyönä. Työpajoissa oli tarvittaessa myös ohjelmistoyrityksen edustus sekä kuntayhtymän asiantuntijoita. Tutkimusryhmän aktiivinen rooli painottui kotihoidon nykyisen toimintaympäristön ja tiedonkulun kartoitukseen ja dokumentointiin. Kotihoidon työntekijät kuvasivat pienryhmissä työpäivän kulkua ja asiakaskäynnillä tarvittavaa ja tuotettavaa tietoa. Apuvälineinä käytettiin muun muassa seinätekniikkaa ja ennalta suunniteltuja lomakepohjia. Työpajakeskustelut myös nauhoitettiin, ja tutkimusryhmän jäsenet kirjoittivat työpajoista muistioita, piirsivät seinätauluja sähköiseen muotoon ja työstivät keskustelujen pohjalta kaavioita ja kuvauksia. Työpajoista tuotetut materiaalit lähetettiin aina ennen seuraavaa työpajaa projektiryhmän jäsenille, ja tuotoksia käsiteltiin myöhemmissä työpajoissa. Alkukartoitukseen kuvattiin kaavioina ja teksteinä kotihoidon toimintaympäristö (kuvassa 23), suunnitellut ja suunnitelmista poikkeavat työpäivänkulut sekä käynnin kirjaamisen ongelmat. Tavoitetilaa hahmoteltiin työpajassa kotihoidon työntekijöiden kanssa yhdessä keskustellen. Kukin työntekijä nimesi yhden asian, jonka muutos helpottaisi hänen työtään. Muutosehdotukset liittyivät sekä työtoiminnan organisointiin että työvälineisiin. Keskustelussa pohdittiin näiden muutosten heijastumista kotihoitoon kokonaisuutena: miten oma ja toisten työntekijöiden työ muuttuisi. Lisäksi keskusteltiin siitä, mitä tietoja tulisi voida käsitellä sähköisesti ja miten sähköinen käsittely helpottaisi työpäivää. Keskustelujen perusteella tutkimusryhmän jäsenet kirjoittivat alustavan listan asiakasvaatimuksista. Mobiililaitteen asiakasvaatimuksia käsiteltiin ja asetettiin tärkeysjärjestykseen edellisissä työpajoissa tuotettujen kaavioiden pohjalta. Laitteen suunnitellut ominaisuudet ja toiminnot esiteltiin kotihoidon työntekijöille seuraavassa työpajassa. Työntekijöillä oli mahdollisuus vaikuttaa suunnitelmiin. Ohjelmistoyritys toi tuleville käyttäjille erilaisia mobiililaitevaihtoehtoja kokeiltavaksi. Lait-

72 70 teisiin oli ohjelmoitu lyhyt sovellus havainnollistamaan laitteen toimintaa. Kotihoidon toimijat saivat tuntumaa laitteen soveltuvuudesta työhön: sen toimintalogiikasta, painosta, näytön koosta jne. Lisäksi kotihoidon työntekijät tutustuivat sovellusprotoon: tulevat käyttäjät kävivät protoa läpi yhdessä koodaajien kanssa ja antoivat näille arvokkaita kommentteja ja muutosvaatimuksia. Lisätietoja Teknologialla muutosta kotihoidon toimintaprosesseihin -pilotista löytyy Toimintaympäristön ja tiedonkulun kuvaus Sotkamon kotihoidossa - alkukartoitusraportista (Luukkonen, Tuomainen & Hyvönen 2007). Alkukartoitus oli pohjatietoa kuntayhtymässä tehtävälle kehittämistyölle. Kuva 23: Esimerkki toimitilojen ja niissä olevien tietovälineiden mallintamisesta.

73 Toimenpidejärjestelmän hankinta ja uusiminen Toimenpide-pilotissa oli kyseessä terveydenhuollon organisaation leikkaustoiminnan ohjaukseen käytettävän tietojärjestelmän hankinta ja uusiminen. ZipIT-hankekokonaisuuden tutkimusryhmän työskentely Toimenpide-pilotissa keskittyi kahteen tehtävään, 1) osallistumiseen järjestelmähankinnan vaatimusmäärittelyvaiheeseen ja 2) sovelletun vaatimusmäärittelyprosessin kuvaamiseen ja arviointiin. Vaatimusmäärittelyprosessin kuvaamisen ja arvioimisen taustalla oli organisaation tarve kehittää tietojärjestelmien hankinta- ja vaatimusmäärittelyprosessin työskentelymenetelmiä. Arviointi toteutettiin itsearviointina, eli sen tulokset perustuvat prosessiin osallistuneiden kokemuksiin käytetyistä työtavoista. Kuvassa 24 on kuvattu vaatimusmäärittelyn työtoiminnan kokonaisuus ActAD-mallin mukaisella notaatiolla sekä määrittelytyön sijoittuminen hankintaprosessiin. Hankintaprosessiin kuului useita eri vaiheita, kuten esimerkiksi hankinnan valmistelu, kilpailutukseen osallistuvien toimittajien valinta ja vaatimusmäärittely. Tutkimusryhmän osallistuminen pilottiin keskittyi vaatimusmäärittelyvaiheeseen ja sen arviointiin. Toimenpidejärjestelmän hankintaa varten terveydenhuollon organisaatiossa oli perustettu hankintaryhmä, johon oli nimetty järjestelmän tulevien käyttäjien edustajia. Hankinta käynnistyi valmistelulla, jonka aikana terveydenhuollon organisaatio teki esiselvityksen. Esiselvitysraportissa kuvattiin yleisluontoisella tasolla hankittavan ohjelmiston toiminnallisuutta sekä selvitettiin markkinoilla olevien leikkaustoiminnan ohjaamiseen soveltuvien ohjelmistojen tarjontaa. Varsinaisen vaatimusmäärittelyvaiheen työskentelyn aikana hankintaryhmään kuului myös tutkimusryhmän edustaja, ja osa ryhmän jäsenistä muodosti ns. tiimin, joka keskittyi erityisesti suunnittelemaan ja koordinoimaan vaatimusmäärittelyvaiheen työskentelyä. Tässä käytettiin paljon osallistavia menetelmiä ja ryhmätyötä erilaisissa kokoonpanoissa, koska haluttiin varmistaa mahdollisimman laaja ja monipuolinen näkemys hankittavan ohjelmiston toiminnallisuudesta. Esiselvitysvaiheen jälkeen asiakkaan oma vaatimusmäärittelytyö aloitettiin ennen tarjouspyynnön julkistamista ohjelmistotoimittajille. Määrittelytyö käynnistyi tavoitetilakuvauksien tekemisellä, ja työhön osallistui laajasti hankittavan järjestelmän tulevia käyttäjiä eli kirurgeja, sairaanhoitajia, osastonhoitajia, apulaisosastonhoitajia, anestesiologeja, osastosihteerejä sekä sairaalan tietohallinnon, atk-osaston ja lisäksi tutkimushankkeen edustaja. Työskentelyyn osallistunut kliininen henkilöstö valittiin oman erikoisalaosaamisensa ja tehtävänkuvansa perusteella. Tavoitetilakuvauksia tuotettiin asiantuntijaryhmissä, ja terveydenhuollon organisaation työntekijät kuvasivat niissä hankittavaan tietojärjestelmään kohdistuvia tarpeita. Tavoitetilakuvauksissa kuvatut tarpeet ja kehitysehdotukset tunnistettiin käytössä olevan järjestelmän ongelmakohtien perusteella. Näiden muutoskohtien esille tuominen koettiin tärkeäksi ja lopullinen ohjelmistotoimittajille lähetetty vaatimusmäärittely muokkautui tavoitetilakuvausten yhteenvedon pohjalta. Vaatimusmäärittelyprosessin aikana siihen osallistuville henkilöille järjestettiin työpajoja ohjelmistotoimittajien kanssa ja tutustumiskäyntejä. Työpajoissa ohjelmistotoimittajat esittelivät tarjoamaansa ohjelmistoa. Työpajat mahdollistivat henkilöstön tutustumisen sekä tarjottuihin ohjelmistoihin että ohjelmistotoimittajiin. Työpajoihin suunniteltiin yhtenäinen ohjelma, jotta tarjolla olevista ohjelmistoista saataisiin keskenään vertailukelpoista tietoa. Tutustumiskäynnit tehtiin sairaaloihin, joihin jokin tarjolla olevista toimenpidejärjestelmistä oli hankittu. Tutustuminen mahdollisti järjestelmien käytön havainnoimisen oikeassa työympäristössä ja oikeassa käyttötilanteessa. Käynti antoi myös tilaisuuden keskustella vertaiskäyttäjien kokemuksista ja auttoi siten hahmottamaan järjestelmän soveltuvuutta omaan työorganisaatioon. Kuvatun toiminnan lähtökohtana terveydenhuollon organisaatiossa oli hankittavan toimenpidejärjestelmän vaatimusmäärittelyn ja tarjousasia-

74 72 kirjojen tuottaminen. Määrittelytyössä sovellettiin aiemmasta käytännöstä poiketen runsaasti osallistavia menetelmiä, ja työskentelyyn osallistui muutamia kymmeniä henkilöitä. Työmenetelmien kehittämisen tueksi tutkimushanke teki pilotissa arviointikyselyn määrittelytyöhön sovelletuista työmenetelmistä. Arviointi pohjautui prosessiarvioinnin ideaan, jossa määrittelytyöhön osallistuneet henkilöt saivat itse kokemuksiensa perusteella arvioida käytettyjen menetelmien soveltuvuutta ja hyödyllisyyttä sekä esittää ehdotuksia organisaation vaatimusmäärittelyvaiheen työskentelyn kehittämiseen. Arvioinnin tuloksien perusteella monet työskentelyyn osallistuneet henkilöt kuvasivat kokemusta oppimisprosessiksi, jonka myötä tavoitteet vähitellen selkiytyivät, ja joka opetti monia asioita tietojärjestelmän hankinnasta monitoimijaiseen ympäristöön. Myös työskentelyyn osallistuneiden henkilöiden valmius tuottaa vaatimuksia hankittavalle tietojärjestelmälle kasvoi erilaisten työmenetelmien ja vaiheiden kautta. Määrittelyn vie kuitenkin aikaa, ja arvioinnin perusteella tähän tulisi tulevaisuudessa kiinnittää enemmän huomiota. Ajankulusta huolimatta erityisen positiivisena koettiin henkilöstön mielipiteen kysyminen ja se, että he saivat olla vaikuttamassa hankittavan järjestelmän vaatimuksiin. Lisätietoja Toimenpide-pilotista ZipIT-hankekokonaisuuden selvityksessä KYS:n toimenpidejärjestelmän hankintaprosessin vaatimusmäärittelyvaiheen kuvaus ja arviointi (Miettinen, Röppänen, Pitkänen & Tuovinen 2006). Päätös leikkaustoiminnan ohjaamiseen tarkoitetun tietojärjestelmän uusinnasta Hankkeen valmistelu Hankinnan valmistelun aloitus Kilpailutukseen osallistuvien toimittajien valinta Tiedotustilaisuus Tarjouspyyntö asiakirjojen tuottaminen Tarjousten arviointi ja hankintaehdotuksen tekeminen Lokakuu Syyskuu Marraskuu Tammikuu Helmikuu Toukokuu Lokakuu Vuosi 2004 Vuosi 2005 Vuosi 2006 Toimenpidejärjestelmän vaatimusten määrittely Hankintaryhmä Hankintaryhmän työskentely ja työnjako asiantuntijarooleittain, sähköposti, tavoitetilakuvausryhmät, toimittajatyöpajat, tutustumiskäynnit Tietohallintojohtaja Sairaalainsinööri Suunnittelija ZipIT Kirurgi Osaston - hoitaja Sairaanhoitaja Kohde: Tavoite: Esiselvitysraportti Tietojärjestelmän uusimiseen liittyvien toiminnallisten tarpeiden tunnistaminen Vaatimusmäärittelyn tuottaminen Vaatimusmäärittely Hankkeen valmistelu Tarjouspyyntöasiakirjojen tuottaminen Kuva 24. Vaatimusmäärittelyvaiheen työtoiminta ja sijoittuminen hankintaprosessiin

75 Käypä hoito -selvitys Käypä hoito -selvityksen taustalla oli pilottiyhteistyökumppanin mielenkiinto selvittää Käypä hoito -suositusten käyttöä ja käytettävyyttä terveydenhuollon työtilanteissa sekä kartoittaa terveydenhuollon toimijoiden suhtautumista kehitteillä olevaan päätöksenteon tukeen. Selvitys liittyi Päätöksentukipilottiin, jossa tavoitteena oli protoversion kehittäminen. Sen tavoitteena on tuottaa potilastietoja käsiteltäessä tilannekohtaisia muistutteita yhdistämällä potilastietoja ja lääketieteellistä tietämystä, kuten esimerkiksi Käypä hoito -suosituksia. Käypä hoito -suositusten käyttöselvitys aloitettiin tutustumalla asiaan kirjallisuuden avulla. Seuraavassa vaiheessa haastateltiin perusterveydenhuollon parissa työskenteleviä henkilöitä. Yksilöllisten teemahaastattelujen avulla kartoitettiin Käypä hoito -suositusten käytön nykytilannetta, käyttötilanteita ja -tarkoituksia sekä niiden vaikutusta hoitotilanteessa tehtäviin päätöksiin. Toisena teemana haastattelussa oli päätöksenteon tuki. Kartoitettaessa terveydenhuollon ammattilaisten näkemyksiä tulevaisuudesta kysyttiin myös, mitä mieltä nämä ovat päätöksenteon tuen kehittämisestä ja tuomisesta terveydenhuoltotyön tueksi. Lisäksi Käypä hoito -suositusten käyttöä havainnoitiin järjestämällä käytettävyystestejä, joissa testiin osallistuneita terveydenhuoltoalan opiskelijoita pyydettiin käyttämään suositusten www-versioita. Testitehtävät suunniteltiin toimintatarinan tavoin siten, että ne vastaavat päivittäisiä rutiininomaisia tiedonhakuja, joita esimerkiksi lääkäri tekee normaalin työpäivän aikana vastaanotollaan. Selvitystyössä terveydenhuollon toimijat toimivat tiedonlähteenä, ja heidät valittiin erilaisten työnkuvien perusteella. Tämän vuoksi Käypä hoito -suositusten käytöstä saatiin nostettua esille erilaisia näkökulmia. Haastatteluiden ja käytettävyystestien havainnontien analysoinnin tuloksena tutkimushankkeen julkaisuna valmistui Käypä hoito -suositukset ja päätöksenteon tuki terveydenhuollon prosesseissa -raportti (Miettinen & Korhonen 2005).

76 Selvitys silmänpohjakuvantamisesta Silmänpohjakuvantamisen alueellista yhteistyötä on yliopistollisen sairaalan näkökulmasta selvitetty aiemmin kahdessa erillisessä selvitystyössä. Taustalla on pyrkimys rakentaa sairaanhoitopiirin alueelle keskitetty alueellinen silmänpohjakuva- ja lausuntoarkisto, jota on suunniteltu jo useamman vuoden ajan. Osana kuvantamispalveluiden ja arkistoinnin alueellista kehittämistä yliopistosairaala esitti tutkimushankkeelle diabeetikoiden silmänpohjien kuvaamisen nykytilan selvittämistä sairaanhoitopiirin terveyskeskuksissa. Tavoitteena oli selvittää erityisesti perusterveydenhuollonosuus silmänpohjakuvaamisprosessissa, se miten kuvantamisessa käytettävä ohjelmisto siihen kytkeytyy ja se miten ohjelmistoa käytetään käytännön työssä. Samalla haluttiin saada kokemuksia terveydenhuollon organisaatioiden rajat ylittävästä toiminnan ja tietojärjestelmien kehittämisestä. Ensimmäiseksi pilotissa mukana olleet tutkimusryhmän edustajat tutustuivat silmänpohjakuvantamiseen liittyvään taustamateriaaliin, kuten aiemmin tehtyihin selvityksiin. Tämän jälkeen he suunnittelivat teemahaastattelulomakkeen, jossa teemoina olivat silmänpohjakuvantamisessa käytettävän ohjelmiston käytön nykytila, diabeetikoiden silmänpohjien kuvausprosessi sekä kuvien arkistointi. Pilotissa teemahaastateltiin kuuden terveyskeskuksen edustajia; yhteensä haastatteluihin osallistui 12 henkilöä. Heistä osa käyttää kuvantamisohjelmistoa työssään esimerkiksi diabeetikoiden silmänpohjien kuvaamiseen tai kuvien katseluun ja osa on organisaationsa tietotekniikan asiantuntijoita. Haastattelujen ohessa tutustuttiin kahdessa terveyskeskuksessa kuvantamisohjelmistoon ja sen käyttöön. Kuva 25. Diabeetikoiden silmänpohjakuvausprosessi eräässä kunnassa.

77 75 Teemahaastatteluihin osallistuneet terveyskeskukset valittiin sen perusteella, että niiden silmänpohjakuvauskäytäntöjen tiedettiin eroavan toisistaan. Terveyskeskusten yhdyshenkilöille lähetettiin sähköpostitse tiedote haastattelusta sekä kysymykset, ja niiden perusteella terveyskeskukset valitsivat itse sopivat henkilöt haastateltavaksi. Haastattelut nauhoitettiin ja tulokset koottiin raportiksi, jossa kerrotaan miten ja millä välineillä kuusi perusterveydenhuollon organisaatiota toteuttaa silmänpohjien seurantaa digitaalisen kuvantamisen keinoin. Raportti sisältää sanalliset prosessikuvaukset käytännöistä, ja lisäksi siihen mallinnettiin yleiskuvat jokaisen organisaation kuvausprosesseista. Tästä on esimerkkinä kuva 25. Kuvaukset tarkastutettiin haastatteluihin osallistuneissa organisaatioissa. Pilotin lopputuloksena syntyneessä raportissa on tehty näkyväksi silmänpohjien seurannassa olevia alueellisia ja paikkakuntakohtaisia eroja. Yliopistollinen sairaala toimitti raportin myös muihin sairaanhoitopiirin terveyskeskuksiin, ja niitä pyydettiin kommentoimaan, mitä raportissa kuvattua kehittämismallia heidän kuvaamiskäytäntönsä muistuttaa. Raportti on siis toiminut yhteistyön välineenä yliopistosairaalan ja perusterveydenhuollon organisaatioiden välillä. Tätä yhteistyötä tullaan syventämään, mikäli keskitettyä alueellista silmänpohjakuva- ja lausuntoarkistoa ryhdytään rakentamaan. Lisätietoja silmänpohjakuvantamisen pilotista saatavilla ZipIT-hankekokonaisuuden selvityksessä Diabeetikoiden silmänpohjien kuvaaminen Pohjois-Savon sairaanhoitopiirissä. Selvitys MediMaker-ohjelmiston käytön nykytilasta (Röppänen & Tuomainen 2006).

78 Toimintalähtöinen tiedonhallinnan muutostuki Tiedonhallinnan prosessit ja tekniikat muuttuvat terveydenhuollossa jatkuvasti. Työntekijöiden näkökulmasta muutokset tulevat useimmiten jostakin ulkoapäin valmiina ja työntekijöiden haasteeksi jää oman työn sopeuttaminen niihin. Tässä pilotissa kehitettiin toimintamallia siihen, miten tiedonhallinnan muutosten keskellä kamppailevat äitiyshuollon työntekijät sekä perusterveydenhuollossa että erikoissairaanhoidossa voisivat omista lähtökohdistaan kehittää teknistä ja sosiaalista työympäristöään arjen realiteettien puitteissa. Toimintamallin pohjana oli osallistava toimintatutkimus. Pilottiin osallistui kahdeksan äitiysneuvolan terveydenhoitajaa neljältä terveysasemalta, kahdeksan kätilöä kahdesta eri synnytyssairaalasta sekä yksi tutkimusryhmän edustaja. Kokeiltu toimintamalli oli kolmivaiheinen. Ensimmäisessä vaiheessa tutkija ohjasi ryhmäkeskustelutilaisuuksia, joissa äitiyshuollon työntekijät kuvasivat ja pohtivat arkityötään tiedonhallinnan tekniikoiden ja prosessien näkökulmasta, nostivat esiin niihin liittyviä arkityössään kohtaamiaan vaikeuksia sekä mahdollisia ratkaisuvaihtoehtoja. Toisessa vaiheessa tutkija laati keskusteluista yhteenvedon, joka esiteltiin yhteisessä kokouksessa keskusteluun osallistuneille, heidän lähiesimiehilleen sekä muiden samaa organisaatiota edustavien terveysasemien tai sairaalan osastojen vastaaville työntekijöille. Tulokset jäivät tämän jälkeen organisaatioiden haltuun apuvälineiksi työn kehittämiseen. Kolmannessa vaiheessa samat työntekijät kutsuttiin ryhmäkeskusteluun arvioimaan toimintamallia ja sen vaikutuksia arkityöhön tiedonhallinnan muutosten kanssa kamppailevissa terveydenhuollon organisaatioissa. Kehittämissykli kesti kokonaisuudessaan organisaatiosta riippuen 6 12 kuukautta. KUOPION YLIOPISTO / PAULIINA IKÄVALKO 2007 Kuva 26. Tiedonhallinnan välineitä kätilön työpöydällä.

79 Yhteenveto pilottikokemuksista Pilottikohteet olivat varsin vaihtelevia sekä sisällöiltään että tavoitteiltaan. Mukana oli kaikkiaan kymmenen pilottikohdetta, joissa työ liittyi esimerkiksi työtoiminnan tiedon tarpeiden kartoittamiseen, uuden ohjelmiston suunnitteluun, valmiin ohjelmiston valitsemiseen tai käyttöönottoon liittyvään työtoiminnan kehittämiseen. Kaikissa pilottikohteissa kehittämismalli auttoi jäsentämään työtoiminnan kokonaisuuteen liittyviä osatekijöitä. Pilottikohteisiin osallistuttiin eri tavoin ja erilaisella intensiteetillä, ja kussakin kohteissa liikuttiin kehittämismallin tasoilla ja vaiheissa pilottikohtaisten tavoitteiden ja tarpeiden mukaan. Kaikissa pilottikohteissa pidettiin nykytilan läpikäyntiä ja analysointia, tavalla tai toisella, edellytyksenä toiminnan tai tietojärjestelmän kehittämiselle. Toiminnan kokonaiskuvan mallintamista ja dokumentointia pidettiin tärkeänä; jokainen toimintaan osallistuva näkee tilanteen omasta roolistaan käsin ja kokee toiminnan sen mukaisesti. Ilman näiden eri näkökulmien koostamista yhteen ei voitu varmistua esimerkiksi yhteisesti käytettävän tietojärjestelmän soveltuvuudesta tai tarkoituksenmukaisuudesta kaikille toimijoille. Kokonaiskuvaa tarvittiin myös tietojärjestelmistä, sillä terveydenhuollon tietojärjestelmät ovat monimutkaisia ja osittain ikään kuin näkymättömiä. Ulkopuolisten suunnittelijoiden ja myös työntekijöiden itsensä oli vaikea hahmottaa tietojärjestelmäkokonaisuuksia ilman erityistä perehtymistä asiaan. Työntekijät itse kokivat tärkeäksi myös sen, että hankkeen aikana kokoonnuttiin yhteen pohtimaan omaan työhön liittyviä käytäntöjä ja sitä tukevan tietojärjestelmän toimintaa. Tämä auttoi myös suhtautumaan myönteisesti hankittavaan järjestelmään ja sen mukanaan tuomiin muutoksiin. Tavoitetilan suunnittelussa pidettiin tärkeänä sen kuvaamista ikään kuin nykytilanteen peilikuvana; tavoite voitiin suunnitella vain sillä tarkkuudella, jolla nykytila tunnettiin. Lisäksi välillä oli tarpeen palata selvittämään nykykäytäntöjä, jotta suunnittelussa voitiin jatkaa eteenpäin. Myös suunnittelukohteen rajaamista ja tavoitteiden asettamista pidettiin tärkeänä, sillä yksittäisen järjestelmän hankinnan yhteydessä ei voida ratkaista koko organisaatiota koskevia ongelmia. Ilman tavoitteiden rajaamista myös keskustelut rönsyävät helposti käsittelemään sellaisiakin asioita, joita ei hankkeen aikana pystytä ratkaisemaan. Tietojärjestelmähankkeiden liittäminen ja yhteyksien näkeminen koko organisaation kehittämistavoitteisiin ja kokonaisuuden suunnitteluun on myös tarpeellista. Tietoteknisesti tuetun työtoiminnan tavoitetilan yhteinen läpikäyminen auttoi löytämään niitä huomattaviakin epäkohtia ja hankaluuksia, joita usein huomataan vasta käyttöönoton jälkeen.

80 78 LÄHDELUETTELO Aaltola, J. ja Syrjälä, L., Tiede, toiminta ja vaikuttaminen. Teoksessa Heikkinen, H., Huttunen, R. ja Moilanen, P. (toim.) Siinä tutkija missä tekijä - toimintatutkimuksen perusteita ja näköaloja. Jyväskylä: Atena Kustannus. s Aspvik, U., Psyykkisesti vajaakuntoisten avotyötoiminta - toiminnan kehittämisprosessi ja merkitys osallistujien elämänlaadulle. Väitöskirja. Oulun yliopisto, Hoitotieteen ja terveyshallinnon laitos. Bødker, K., Kensing, F. ja Simonsen, J Participatory IT Design Designing for Business and Workplace Realities. MIT Press. Bertelsen, O.W. ja Bødker, S., Introduction: Information technology in human activity, Scandinavian Journal of Information Systems, 12(1), Bødker, S., Computers in Mediated Human Activity. Mind, Culture, and Activity, 4(3), s Coombs, R., Saviotti, P. ja Walsh, V., Economics and Technological change. Rowman & Little- Elovainio, M. ja Lindström, K., Sosiaali- ja terveydenhuollon työyhteisöjen toimivuus Suomessa. Stakes. Raportteja 113. Jyväskylä. Engeström, Y., Learning by expanding. Helsinki: Orienta-konsultit. Engeström, Y., Activity theory and individual and social transformation Teoksessa Engeström, Y., Miettinen, R. ja Punamäki, R. (toim.), Perspectives on Activity Theory. Cambridge, UK: Cambridge University Press. s Eskola, J. ja Suoranta, J., Johdatus laadulliseen tutkimukseen. Vastapaino, Tampere. Fowler, M., UML distilled: a brief guide to the standard object modeling language. 3rd ed. Addison-Wesley. Gregory, J., Sorcerer s Apprentice. Creating the Electronic Health Record, Re-inventing Medical Records and Patient Care. Väitöskirja, University of California, USA. Haikala, I. ja Märijärvi, J., Ohjelmistotuotanto. Talentum, Helsinki. Häkkinen, H., Rapid method for integration requirements assessment case maternity care. Teoksessa S. Laukkanen and S. Sarpola (toim.), Electronic Proceedings of the 26th Information Systems Research Seminar in Scandinavia, Helsinki: Helsinki School of Economics. 10 sivua. Häyrinen, K., Porrasmaa, J., Komulainen, J. ja Hartikainen, K., Sähköisen potilaskertomuksen yhdenmukaiset rakenteiset ydintiedot - Loppuraportti. Osaavien keskusten verkoston julkaisuja 5/2004 Herzum, P. ja Sims, O., 2000: Business component factory: a comprehensive overview of componentbased development for the enterprise. New York Wiley cop. Hirsjärvi, S. ja Hurme, H., Teemahaastattelu. Yliopistopaino, Helsinki. Hyysalo, S., Käyttäjätieto ja käyttäjätutkimuksen menetelmät. IT Press. Ikävalko, P., Participatory and Collaborative Methods in User Interface Designing: The Case of Electronic Planning and Follow-Up Medical Care in the Finnish University Hospital Unit. Tii-

81 vistelmä. ISCAR2007. Fourth Nordic Conference on Cultural and Activity Research. June 15-17, 2007 Oslo, Norway. Hyväksytty. Juuti, P. ja Lindström, K., Postmoderni ajattelu ja organisaation syvällinen muutos. Työ ja ihminen, tutkimusraportti 4. Työterveyslaitos, Johtamistaidon opisto. Helsinki. Kettunen, S., Tietojärjestelmän ostaminen - käytännön opas yrityksille. WSOY Kiviaho, K., Winblad, I. ja Reponen J., Terveydenhuollon toimintaprosesseja ja asiointia tukevat atk-sovellukset Suomessa. Sosiaali- ja terveysalan osaavien keskusten verkoston julkaisuja 8/2004. Stakesin monistamo, Helsinki. Korpela, M., Mursu, A., Soriyan, A., Eerola, A., Häkkinen, H. ja Toivanen, M., I.S. Research and Development by Activity Analysis and Development - Dead horse or the next wave? Teoksessa Kaplan B, Truex III D, Wastell D, Vood-Harper A.T. & DeGross J (toim.), Information Systems Research Relevant Theory and Informed Practice. Boston: Kluwer Academic Publishers. s Korpela, M., Soriyan, H.A., ja Olufokunbi, K.C., Activity analysis as a method for information systems development: General introduction and experiments from Nigeria and Finland. Scandinavian Journal of Information Systems 12(1), Kuutti, K., Activity Theory and its applications to information systems research and development. Teoksessa Nissen, H-E., Klein, H. K. ja Hirscheim R., (toim.), Information Systems Research: Contemporary Approaches and Emergent Traditions. Amsterdam: Elsevier. s Laakso, S. A., Käyttöliittymälähtöinen vaatimusmäärittely. Systeemityö 2/ ) Laakso, S. A. ja Laakso, K., Hyvän käyttöliittymän varmistaminen GUIDe-prosessimallilla. Laki potilaan asemasta ja oikeuksista 785/1992. Laki terveydenhuollon ammattihenkilöistä 559/1994. Laki viranomaisten toiminnan julkisuudesta 621/1999. Leontjev,A.N., Activity, Consciousness and Personality. Engelwood Cliffs, NJ: Prentice Hall. Lumijärvi, I., Laadun arviointi sosiaali- ja terveysalan palveluyksiköissä. Tutkimuksia No 186, Vaasan yliopisto. Vaasa. Martikainen, S., Silvennoinen, R. ja Ikävalko, P., Tapaus lääkehoito: Kokemuksia käyttöliittymäkuvista ohjelmiston käyttäjävaatimusten määrittelyssä. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Tutkimuspaperit Työpapereita 4/2006, Stakes. s Martola, U. ja Santala, R., Liiketoimintaprosessit BPR muutoksenjohtaminen. WSOY, Porvoo. McDonagh, J. ja Coghlan, D The Art of Clinical Inquiry in Information Technologyrelated Change. Teoksessa Reason P & Bradbury H (toim.). Handbook of Action Research. Sage. s Miettinen, R., Hyysalo, S., Lehenkari, J. ja Hasu, M., Tuotteesta työvälineeksi? Uudet teknologiat terveydenhuollossa. Stakes. Mursu, A., Information systems development in developing countries. Risk management and sustainability analysis in Nigerian software companies. Doctoral dissertation. University of Jyväskylä, Jyväskylä Studies in Computing 21. Mursu, A., Luukkonen, I., Toivanen, M. ja Korpela, M. 2007, Activity Theory in information systems research and practice: theoretical underpinnings for an information systems development model, Information Research 12 (3). (haettu ) Mykkänen, J., Minkkinen, I., Pöyhölä, A. ja Riekkinen, A Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä. Kirjassa: Janne Lehenkari & Kristiina Häyrinen, (toim.) SoTeTiTe Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Tutkimuspaperit. Työpapereita 4/2006, Stakes. s

82 80 Mwanza, D., Where theory meets practice: A case for an Activity Theory based methodology to guide computer system design. Teoksessa Hirose, M., (toim.), Proceedings of INTERACT 2001, Oxford, UK: IOS Press. s Pelin, R., Projektinhallinnan käsikirja. Projektijohtaminen Oy. Ruuska, K., Projekti hallintaan. Suomen Atk-kustannus Oy. Jyväskylä. Ruuska, K., Terveydenhuollon projektinhallinta. Mallit, työkalut, ihmiset. Helsinki, Talentum. Saaren-Seppälä, K., Seinätekniikka, Seinäkuvien käyttö suunnittelussa ja ryhmätyössä, Vihdin Kirjapaino Oy. Salmimies, P., Nykyaikaisen johtajuuden psykologia. Teoksessa Castrén Paavo (toim.). Viisas valta - johtamisen paradoksit. Ekonomia sarja. WSOY. s Sihvola, I., Onnistunut julkinen ICT-hankintaprosessi, Helsingin kauppakorkeakoulu, Helsinki. Silfverberg, P., Ideasta projektiksi. Projektisuunnittelun käsikirja. Helsinki, Edita. Sommerville, I., 2001: Software Engineering 6th Edition. Pearson Education Limited, USA. Sosiaali- ja terveysministeriö Kansallinen projekti terveydenhuollon tulevaisuuden turvaamiseksi. Sosiaali- ja terveysministeriön työryhmämuistioita 2002:3. Helsinki. Sosiaali- ja terveysministeriö Sähköisten potilasasiakirjajärjestelmien toteuttamista ohjaavan työryhmän loppuraportti. Sosiaali- ja terveysministeriön työryhmämuistioita 2004:18. Helsinki. Sosiaali- ja terveysministeriön asetus potilasasiakirjojen laatimisesta sekä niiden ja muun hoitoon liittyvän materiaalin säilyttämisestä 99/2001. Stakes Sosiaali- ja terveydenhuollon laadunhallinta 2000-luvulle. Valtakunnallinen suositus. Stakes Ihmisiin kohdistuvien vaikutusten arviointi. Kehittämistyön menetelmiä. Osa 2, tie- 28ED3DFCC870/0/menetelmatosa2.pdf. (haettu ) Toivanen, M., Eerola, A. ja Korpela, M., From information systems requirements to software components home care case Teoksessa Laukkanen, S., & Sarpola, S. (toim.), Electronic Proceedings of the 26th Information Systems Research Seminar in Scandinavia, Helsinki: Helsinki School of Economics. 14 sivua. Turpeinen, M. ja Taskinen, H., Henkilöstön arviot organisaatiofuusion yhteydessä tehdyistä tietojärjestelmä muutoksista. Teoksessa Kinnunen, J. ja Lindström, K. (toim.). Rakenteellisen ja toiminnallisen muutoksen vaikutukset HUSin johtamiseen ja henkilöstön hyvinvointiin. Kuopion yliopiston julkaisuja E. yhteiskuntatieteet 129. Kuopio. s Virkkunen, J., Engeström, Y., Pihlaja, J. ja Helle, M., Muutoslaboratorio. Uusi tapa oppia ja kehittää työtä. Kansallinen työelämän kehittämisohjelma. Työministeriö, Raportteja 6. Oy Edita Ab. Helsinki. Virtanen, P., Projektityö. WSOY. Whittaker, B., What went wrong? Unsuccessful information technology projects. Information Management & Computer Security. 7/1, s

83 Liite 1: Esimerkki ActAD-elementeistä johdetusta teemahaastattelulomakkeesta Kotihoito HAASTATTELULOMAKE Pvm Haastattelijat Taustatiedot Nimi Ammatti Koulutus Ikä Työkokemus kotihoidosta Yhteystieto Ketkä ovat kotihoidon asiakkaita? (Mainitse yleisimmät asiakasryhmät) Mitä palveluita kotihoidossa tuotetaan? (Kuka tarvitsee kotihoitoa ja mihin?) Kerro esimerkkitapaus? Mistä/miten saadaan tarvittavat? (Mitä kotihoidon palvelujen tuottaminen edellyttää?) Miten kotihoidon palvelujen piiriin? (Kuka lähettää/ottaa yhteyttä, keneen ja miten?) Esim. lääkärin lähete (perusterv.huolto/erikoissh?), asiakas/omainen soittaa jne. Onko eroja siinä, miten eri asiakasryhmät tulevat kotihoidon asiakkaiksi? Mitä saadaan ensimmäisessä yhteydenotossa? Onko tämä tieto riittävää palveluprosessin käynnistämiseksi? Tarvitaanko lisäksi muuta tietoa? Mistä ja miten sitä saadaan? (Sairauskertomuksesta, omaisille soittamalla, jne.) Määritelläänkö asiakkaan kotihoidolle?miten ja miksi se määritellään? Kuka/ketkä määrittelevät ja missä yhteydessä? Mitä tietoja tarvitaan? Miten tarvittavat tiedot saadaan? (Mistä ja millä välineillä?) Miten määritelty tavoite ilmaistaan ja kenelle (kenen tarvitsee se tietää)? (Hoito- ja palvelusuunnitelma, jne.) Mistä saat työsi kannalta, kun olet? Entäs Käytätkö jotain tietoteknisiä välineitä? Miten ja mihin tarkoitukseen?

84 Jos et itse käytä tietotekniikkaa, niin tietojärjestelmään? Kuka sen tekee ja milloin? Mistä saat käyttämäsi työvälineet (tietoon liittyvät)? Ketä kotihoidossa työskentelee? kotihoidon palvelujen tuottamiseen? (Ammattiryhmät; Miksi ammattiryhmiä on niin monia?) Missä nämä määritellään ja kuka sen tekee? Onko kh:lla Ketä muita asiakkaan luona käy? Saadaanko heistä jotain tietoa? Jos saadaan, niin miten? Viestitäänkö heidän kanssaan? Miten? Miten kaikki osalliset saadaan tietoiseksi asiakkaan palvelun/hoidon tavoitteesta ja keinoista? Miten toimintasuunnitelmasta tiedotetaan? Miten suoritetaan kotihoidossa? (Organisaatiotasolla/käytännön toiminnassa.) Miten työnjaosta tiedotetaan? Esim. Kp, ksh, naapuri jne. tietoisia siitä, kuka tekee mitäkin. Miten työnjaon onnistumista seurataan? Mitä yhteisiä ja sovittuja toimintatapoja kotihoidossa on? Eri ammattiryhmien sisällä ja välillä? Esim. uuden työntekijän perehdytys. Mistä ne löytyvät? Miten niitä muutetaan? Mihin säännöt ja sovitut toimintavat kohdistuvat ja miksi niitä tarvitaan? Milloin saat, kuinka pitkälle ajalle ne on tehty? Entä työvuoroihin tulevat muutokset? Jos niitä tulee, miten tiedotetaan? Mitä käytät työssäsi? (Kahvitauot, palaverit jne.) Millaisia välineitä käytät kommunikointiin? Mistä ne saat? Käytätkö tiedonvaihtoon? Minkä verran? Tiedonkulusta: Missä yhteyksissä mielestäsi tiedonkulku toimii hyvin kh:ssa? Miten tieto tällöin kulkee? Onko tiedonkulkua joskus muutettu jotenkin? Milloin tiedonkulussa olisi mielestäsi eniten parannettavaa?

85 Liite 2: Esimerkki osallistujien valinnasta ja roolien määräämisestä

86 Liite 3: Esimerkkipolut

87

88 Liite 4: Hankkeen aikana tuotetut julkaisut Opinnäytteet PROJEKTIN AINEISTOON OSITTAIN TAI KOKONAAN PERUSTUVAT PRO GRADU -TYÖT Ikävalko, P Terveydenhuollon rakenteisten tietojen tallentaminen käyttöliittymäsuunnittelun näkökulmasta. Lapin yliopisto, taiteiden tiedekunta. Jaatinen, J Osallistavan suunnittelun lähestymistavat tietojärjestelmien käyttöönoton tukena. Kuopion yliopisto, tietojenkäsittelytieteen laitos. Martikainen, S Käyttöliittymäsuunnittelu osana vaatimusmäärittelyä: Esimerkkinä lääkehoidon käyttöliittymä. Kuopion yliopisto, tietojenkäsittelytieteen laitos. PROJEKTIN AINEISTOON OSITTAIN TAI KOKONAAN PERUSTUVAT KANDIDAATINTUTKIELMAT Miettinen, M Päätöksenteon tukijärjestelmä terveydenhuollon tietojärjestelmäkontekstissa. Jyväskylän yliopisto, tietojenkäsittelytieteiden laitos. PROJEKTIN AINEISTOON OSITTAIN TAI KOKONAAN PERUSTUVAT AMMATTIKORKEAKOULUN OPIN- NÄYTTEET Kononen, Juha Kliininen päätöksentukijärjestelmä potilaiden hoidon parantamiseksi: Tieto-järjestelmän määritys käyttötapausten avulla. Savonia-ammattikorkeakoulu, Savonia Business, tietojenkäsittelyn koulutusohjelma. Kaipainen, Sirpa Tietoturvan tilanne Pohjois-Savon terveydenhuollon toimintayksiköissä. Savonia-ammattikorkeakoulu, Savonia Business, tietojenkäsittelyn koulutusohjelma. Kansainväliset artikkelit ja konferenssiesitykset Bertelsen O., Korpela M. ja Mursu A. (toim.) Proceedings of the First International Workshop on Activity Theory Based Practical Methods for IT-Design, Copenhagen, Denmark, 2-3 September Häkkinen H Acquiring information about IS development needs from the viewpoint of an organizational unit. Teoksessa: Bertelsen O, Korpela M & Mursu A (toim.) Proceedings of the First International Workshop on Activity Theory Based Practical Methods for IT-Design, Copenhagen, Denmark, 2-3 September Häkkinen H Drawn together: combining the people and methodologies of software design and work development. Teoksessa: Bamidis PD., Bath P., Eaglestone B. ja Sotiriadou A. (toim.) Improving the Quality of Health Information: an international perspective. Proceedings of the 10th International Symposium on Health Information Management Research, ishimr 2005, Thessaloniki, Greece, September SEERC, Thessaloniki 2005, ss Häkkinen H. ja Korpela M A participatory assessment of IS integration needs in maternity clinics using activity theory. International Journal of Medical Informatics. Ikävalko, P., Participatory and Collaborative Methods in User Interface Designing: The Case of Electronic Planning and Follow-Up Medical Care in the Finnish University Hospital Unit. Konferenssiesitelmä. ISCAR2007. Fourth Nordic Conference on Cultural and Activity Research. June 15-17, 2007 Oslo, Norway. Hyväksytty julkaistavaksi. Korhonen M Changing work practices with software. Innovations in organizational development. 5th European Conference of ACENDIO, Bled, Slovenia, 7-9April Minkkinen I. ja Eerola A Improving requirements engineering from the Client s Perspective in the Health Care Domain. Teoksessa: Hasselbring, W. (toim.): Proceedings of the IASTED International Conference on Software Engineering as part of the 25th IASTED International Multi-Conference on Applied Informatics. February 13-15, 2007 Innsbruck, Austria. ACTA Press, 2007.pp Minkkinen I AT-based requirements engineering method as a starting point of software engineering, ISCAR, Sevilla, Espanja,

89 Minkkinen I., Toivanen M. ja Eerola A Importance of the approach to Requirements Engineering. Teoksessa: Proceedings of IRIS-28: Information systems research seminar in Scandinavia, Kristiansand, Norja. Mursu A Analyzing the present state of an activity. Teoksessa: Bertelsen O, Korpela M & Mursu A (toim.) Proceedings of the First International Workshop on Activity Theory Based Practical Methods for IT-Design, Copenhagen, Denmark, 2-3 September Mursu A Analysing technological sustainability in organization: an activity-theoretical approach, ISCAR, Sevilla, Espanja, Mursu A., Minkkinen I. ja Ensio A Combining work development with information systems development - ZipIT project, Abstract in CIDC 2006 Community Informatics for Developing Countries, Cape Town, Mursu A., Luukkonen I., Toivanen M. ja Korpela M Activity theory in information systems research and practice - theoretical underpinnings for an information systems development model. Elektronisessa julkaisussa: Information Research, 12(3). Mursu A., Luukkonen I., Toivanen M. ja Ensio A Sustainable health care information systems by activity driven design model. Posteri: MedInfo07. Hyväksytty julkaistavaksi. Mykkänen J., Minkkinen I., Pöyhölä A. ja Riekkinen A Improving traceability of functional requirements to information needs and applications in healthcare. 6th Nordic Conference on ehealth and Telemedicine August 31 - September 1, 2006 Helsinki, Finland. Palmen M., Korpela M. ja Saranto K Information management tools and changing work practices: Experiences of Finnish maternal healthcare workers. ITHC2007-konferenssiin lähetetty artikkeli. Toivanen M IT needs exploration. Teoksessa: Bertelsen O., Korpela M. ja Mursu A. (toim.) Proceedings of the First International Workshop on Activity Theory Based Practical Methods for IT- Design, Copenhagen, Denmark, 2-3 September Kansalliset tieteelliset ja ammatilliset artikkelit sekä konferenssiesitykset Häkkinen H Tiedon ja viestinnän välineiden kehittäminen sosiaali- ja terveydenhuoltotyössä. Toiminnan teorian ja sosiokulttuurisen tutkimuksen päivät. Espoo. Ikävalko P Käyttöliittymäratkaisu rakenteisten tietojen syöttämiseksi sähköiseen potilaskertomusjärjestelmään. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Ikävalko P. ja Toivanen M Toiminnan teoriaa käyttöliittymäsuunnittelijoille. Toiminnan teorian ja sosiokulttuurisen tutkimuksen päivät. Espoo. Klemola L., Ikävalko P., Miettinen M. ja Röppänen P Osallistavat menetelmät tietoteknisesti tuetun työtoiminnan kehittämisessä. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Korhonen M. ja Tuomainen T Aluetietojärjestelmä - toiminnan muutos vai tietotekniikan käyttöönottohanke. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Martikainen S., Silvennoinen R. ja Ikävalko P Tapaus lääkehoito: Kokemuksia käyttöliittymäkuvista ohjelmiston käyttäjävaatimusten määrittelyssä. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Miettinen M. ja Korhonen M Käypä hoito -suositukset ja päätöksentuki terveydenhuollon työtoiminnan kehittämisen tukena. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Miettinen M. ja Korhonen M Potilastiedon laatu edellytyksenä päätöksentuen käyttöönotolle ja tietojärjestelmien integraatiolle. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Minkkinen I Toiminnan teoriaan pohjautuva vaatimusmäärittelymenetelmä ohjelmistotuotannon aloituspisteenä. Toiminnan teorian ja sosiokulttuurisen tutkimuksen päivät. Espoo.

90 Minkkinen I., Häkkinen H. ja Mursu A Yhteisen asiakkaan jatkohoidossa hyödynnettävän hoitopalautteen toimintalähtöinen kehittäminen. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Mononen R. ja Röppänen P Radiologisten tutkimusten digitalisointi lähtökohtana toiminnan kehittäminen. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Mursu A. ja Ikävalko P Tietojärjestelmät palvelemaan työtä - Apuna toimintalähtöinen kehittämismalli. Systeemityö 1/2007. Mykkänen J., Minkkinen I., Pöyhölä A. ja Riekkinen A Toiminnallisten vaatimusten jäljitettävyys tietotarpeisiin ja ohjelmistoratkaisuihin terveydenhuollon tietojärjestelmissä. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Toivanen M., Häkkinen H., Minkkinen I., Röppänen P., Ikävalko P. ja Riekkinen A Toimintalähtöisyys terveydenhuollon tietojärjestelmien kehittämisessä. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Toivanen M., Luukkonen I. ym Kohti suunnitelmallisia muutoksia - Malli terveydenhuollon tietojärjestelmien toimintalähtöiseen kehittämiseen. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Selvitykset Klemola, L. ja Luukkonen, I Sähköisen potilastietojärjestelmän käyttöönotto. Projektiraportti. Komulainen A Päätöksenteon tuki: selvitys päätöksentukipalvelun toteuttamisesta. Leskinen J. ja Seppänen S Alueellinen yhteistyö terveydenhuollon toiminnan kehittämisessä. Henkilöstön näkemyksiä alueellisesta laboratoriotoiminnasta. Silmänpohjakuvantamisen hallinta alueellisena toimintana. Luukkonen I., Tuomainen T. ja Hyvönen P. 2007: Toimintaympäristön ja tiedonkulun kuvaus Sotkamon kotihoidossa. Kartoitus ennen mobiililaitteen käyttöönottoa. Martikainen, S. ja Silvennoinen R Lääkehoidon sähköisen suunnittelun ja seurannan kokonaisnäkymän käyttäjävaatimuksia. Käyttöliittymäkuvien suunnitteluperusteet. Miettinen M., Röppänen P., Pitkänen P. ja Tuovinen T KYS:n toimenpidejärjestelmän hankintaprosessin vaatimusmäärittelyvaiheen kuvaus ja arviointi. Miettinen M. ja Korhonen M Käypä hoito -suositukset ja päätöksenteon tuki terveydenhuollon prosesseissa. Tapaustutkimus Käypä hoito -suositusten käytöstä ja terveydenhuollon ammattilaisten näkemyksistä päätöksenteon tuesta. Minkkinen I., Mursu A. ja Häkkinen H Laajennetun hoitopalautteen tiedon tarpeet: Raportti Hoitopalaute-projektin tutkimustuloksista. Mononen R Esiselvitys digitaaliseen kuva-arkistojärjestelmään siirtymisestä Kuopion kaupungin sosiaali- ja terveyskeskuksen röntgenosastolla - Toiminnan nykytila ja tavoitetila. Mykkänen J., Korhonen M., Porrasmaa J., Tuomainen T. ja Ensio A Tietojärjestelmien standardointityön organisointi ja kehittäminen terveydenhuollossa: nykytila ja toimenpide-ehdotukset. Standardointiselvitystyön loppuraportti. Osaavien keskusten verkoston julkaisuja 3/2005, Helsinki. Röppänen P. ja Tuomainen T Diabeetikoiden silmänpohjien kuvaaminen Pohjois-Savon sairaanhoitopiirissä. Selvitys MediMaker-ohjelmiston käytön nykytilasta.

91 Muut julkaisut Ensio A, Saranto K: Kansallinen terveyshanke - elektronisen potilaskertomuksen yhtenäistämiseen liittyvät toimenpiteet. Sairaanhoitaja 78(3), Häyrinen K, Ensio A, Hartikainen K. Sähköisten potilaskertomusten käyttöönotto edellyttää uusia tietoja ja taitoja. Sairaala 2006(4): Hyppönen H., Salmela H., Salmivalli L., Martikainen O., Juntunen K., Winblad I., Saranto K., Klemola L., Niska A. ja Kuusimäki M-L Tuki systeemisten innovaatioiden kehittämiseen sosiaali- ja terveydenhuollossa. Sosiaali- ja terveydenhuollon tietotekniikan ja tiedonhallinnan tutkimuspäivät. Jylhä V., Klemola L. ja Saranto K Assessing the Hyvis Enquiry Service by applying the process model of information management. MedInfo Hyväksytty. Jylhä V., Klemola L. ja Saranto K Users and Health Care Professionals Opinions of the Hyvis Enquiry Service. NCeHT-kongressi , Helsinki Klemola L. Tietosuoja- ja turvakoulutuksen tarve terveydenhuollossa Abstrakti. Julkaisussa: Montin L. (toim.) Sairaanhoitajapäivät 2006, Helsinki, , s. 45. Helsinki: Sairaanhoitajaliitto. Sairaanhoitajaliiton julkaisuja. Monisteita. Klemola L. ja Ensio A Eri toimijoiden valmiudet ja mahdollisuudet uusien toimintakäytäntöjen omaksumisessa. Posteri-abstrakti. Julkaisussa: Lehtomäki S, Grönvall U, toim. Sairaanhoitajapäivät 2007, Helsinki, , s Helsinki: Sairaanhoitajaliitto. Sairaanhoitajaliiton julkaisuja. Monisteita. Klemola L. ja Ensio A Eri toimijoiden valmiudet ja mahdollisuudet uusien toimintakäytäntöjen omaksumisessa. ARVO-projektin tutkimushankkeen loppuraportti. Kuopio: Savonia-ammattikorkeakoulu. 48 s. Klemola L., Ensio A. ja Saranto K Perceptions of Health Care Professionals Concerning Development of Clinical Pathways. Proceedings of 9th International Conference on Nursing Informatics, Soul, Korea, Klemola L., Saranto K., Ensio A. ja Kivekäs E Lonkka- ja sydänpotilaiden hoitoketjujen toimivuus ja niiden kehittäminen henkilökunnan näkökulmasta. Lääkärilehti Klemola L., Vinkanharju A., Häyrinen K., Kuusisto-Niemi S. ja Paukkala M Luotettava nettineuvonta yhdistää ohjeet ja tiedon. Dialogi-lehti 2007/1. Klemola L., Vinkanharju A., Jylhä V., Saranto K. ja Ensio A Hyvis-portaalin arviointi. Etelä-Savon sairaanhoitopiiri. Etelä-Savon sairaanhoitopiirin julkaisuja s. Korhonen M. ja Iivari A Terveydenhuollon tietojärjestelmäkehitys - suuntana yhtenäinen kansallinen arkkitehtuuri. Systeemityö 1/2007. Korhonen M. ja Niiranen P A Virtual Visit to the Childbirth Clinic. Proceedings of 9th International Conference on Nursing Informatics, Soul, Korea, Korhonen M. ja Niiranen P A Virtual Visit to the Hospital: Childbirth Clinic in Internet. 6th Nordic Conference on ehealth and Telemedicine, Helsinki, Finland, Komulainen J., Kunnamo I., Nyberg P., Kaila M., Mäntyranta T. ja Korhonen M Developing an Evidence Based Medicine Decision Support System Integrated with EPRs Utilizing Standard Data Elements. ECAI 2006 (esitys Peter Nyberg, Duodecim). Reponen K. ja Ensio A.: Sähköisten työvälineiden juurruttaminen käytännön hoitoprosesseihin sekä näihin liittyvä tietoturva. Loppuraportti. Kuopion yliopisto. Terveyshallinnon ja - talouden laitos, Shiftec tutkimusyksikkö, 86 s, Saranto K, Ensio A, Häyrinen K: Tietotekniikan ja tietojärjestelmien käytön mahdollisuudet terveydenhuollossa. Terveydenhoitajalehti 37(9), 32-33, Saranto K, Ensio A, Jokinen T. Patient Medication - How is it Documented? Teoksessa: Park H-A.,

92 90 Murray P., Delaney C., (toim.) Consumer-Centered Computer-Supported Care for Healthy People. Proceedings of NI2006, Seoul, p Amsterdam: IOS Press, Saranto K, Ensio A, Valtonen H. Medication Management and Documentation in the EHR. Teoksessa: Proceedings of the 6th Nordic Conference on ehealth and Telemedicine. From Tools to Services., Helsinki, Finland, 31 Aug. - 1 Sept., p Helsinki: Nordic Telemedicine Association, Valta M, Saranto K, Ensio A, Valtonen H. Addressing the Project Management Issues into the Implementation of Hospital Information System - Project team perspective. In: Proceedings of the 6th Nordic Conference on ehealth and Telemedicine. From Tools to Services, Helsinki, Finland, 31 Aug - 1 Sept 2006, p Helsinki: Nordic Telemedicine Association, 2006.