Samuli Niiranen ja Esa-Matti Tolppanen: Potilastietojärjestelmät vallitsevien olojen arvostelusta kohti niiden korjaamista Tampere ja Espoo 17.12.2013
Kirjoittajat Samuli Niiranen Niirasen työuraan ovat kuuluneet mm. tehtävät tutkijatohtorina Harvard Medical Schoolissa ja Brigham and Women s Hospital -sairaalassa Bostonissa (2006-2007) terveydenhuollon tietotekniikan tutkimustyössä sairaalaympäristössä ja kliinisten tietojärjestelmien tuotepäällikkönä Terivan Oy:ssä (2003-2006). Tällä hetkellä Niiranen toimii ohjelmistotuotannosta vastaavana johtajana Mylab Oy:ssä. Esa-Matti Tolppanen Tolppasen työuraan ovat kuuluneet mm. tehtävät Mecrastor Pricewaterhouse Coopers Oy:n konsultointijohtajana (1996-1999), Consulting Service Principal Digital Equipment Nordic Healthcare business unit yksikössä (1993-1996) sekä tietohallintopäällikönä HYKS:ssa (1988-1993, josta osan aikaa organisaation kehittämistehtävissä). Tällä hetkellä Tolppanen toimii johtajana Senior Advisor -tehtävissä Datawell Oy:ssä. Esimerkkejä toimeksiannoista, joissa Tolppanen on ollut keskeisessä roolissa: - HUS:n perustamisen yhteydessä tietohallintostrategian laatiminen (1999) - Turun, Oulun ja Kuopion kaupunkien sosiaali- ja terveystoimien tietohallintostrategiat (1997, 2000 ja 2001) - Pohjois-Pohjanmaan sairaanhoitopiirin potilastietojärjestelmien arviointihanke (2004) - Useita toimeksiantoja Uranus, Effica ja Mediatri -järjestelmien tietoihin perustuvan tietojärjestelmän toimittamisesta kustannus- ja laatumittareiden seurantaan (2000- ja 2010-luku). Lisäksi Tolppanen on toiminut kirjoittavana sihteerinä kansainvälisessä ryhmässä, joka laati ehdotuksen teollisuuden lähtökohdiksi EU Health Telematics neljänteen puiteohjelmaan.
Miksi tietojärjestelmät ovat niin raskaita ja kankeita, ja minkä tähden niihin kirjaaminen vie lääkäreiltä ja hoitajilta niin paljon aikaa? Ohjaako kukaan potilaan kokonaishoitoa? Entä palvelujen tuottamisen prosessia? Mitä varten tietojärjestelmiä on niin paljon, miksi ne ovat niin kovin erilaisia ja minkä tähden tieto ei kulje niiden välillä? Mistä saisi kunnon tietoa toiminnan ja organisaation johtamiseen? Milloin vihdoin tietojärjestelmät helpottavat työtä ja alentavat kustannuksia? Pitääkö tietojärjestelmien rakentamis- ja käyttöönottohankkeiden aina pitkittyä ja ylittää budjettinsa? Nämä ja muut samantyyppiset kysymykset ovat kovin tuttuja aikamme julkisesta keskustelusta. Niihin vastaaminen johtaa vallitsevien olojen arvosteluun, mikä on helppoa. Vallitsevien olojen korjaaminen sen sijaan ei ole helppoa. Tämän kirjoitus on kirjoittajien yritys osallistua sosiaali- ja terveystoimen tietojärjestelmäuudistuksia koskevaan keskusteluun ja tukea käynnissä olevia ja käynnistyviä uudistushankkeita. Kirjoitus pohjautuu tekijöiden omaan kokemukseen sekä toimittaja- että asiakaspuolella tietojärjestelmien kehittämisessä ja käyttöönotossa sekä moniin keskusteluihin asiakkaiden ja muiden toimittajayritysten edustajien kanssa. Ajattelun kirvoittajina ovat toimineet sekä julkiset tietolähteet että yksityiset keskustelut erityisesti pääkaupunkiseudun potilas- ja asiakastietojärjestelmäuudistukseen liittyen. Olemme rajanneet tarkastelun ulkopuolelle sosiaalitoimen järjestelmät ennen muuta sen takia, että nämä järjestelmät kirjoituksemme yhden perusteesin mukaisesti pitää ja voidaan jakaa toiseen urakkakokonaisuuteen, kunhan samalla huolehditaan tarpeellisesta integraatiosta ja tietojen yhteiskäytöstä. Toinen syy on se, että oma osaamisalueemme on juuri terveydenhuollon tietojärjestelmissä. Toisena rajauksena on, että lähestymme asiaa tässä kirjoituksessa pitkälti terveydenhuollon ammattilaisten ja organisaatioiden näkökulmasta. Mielestämme myös kansalaisen näkökulmasta tietojärjestelmien haastavin tavoite on se, että palveluun osallistuvien ammattilaisten tukena on organisaatiorajat ylittävä ja palvelun optimointia ja virheitä vähentämistä avustava tietojärjestelmä. Kansalaisen hoitoon osallistumista varten tarvittavat tietojärjestelmän ominaisuudet ovat sittenkin varsin suoraviivaisia toteutuskohteita, jotka riip puvat lähinnä terveyspoliittisesta ja palvelun tuottajien tahdosta. Tarvitaan potilasprosessin tietojärjestelmä POP järjestelmä! 1
1. Johdanto Ensimmäinen osa tätä kirjoitusta pyrkii tekemään diagnoosia kurkistamalla konepellin alle. Mikä voisi olla vialla nykyisissä potilastietojärjestelmissä tai niiden ympärillä olevassa tekemisessä? Kirjoittajat ovat samaa mieltä julkisuudessa esitettyjen kuvausten kanssa tietojärjestelmien oireista tai toimimattomuudesta. Mielestämme kuitenkin pohdintaa mahdollisista oireiden takana olevista perussyistä on ollut esillä liian vähän. Keskeinen nykytilanteen hallinnollinen perusongelma on mielestämme se, että potilastietojärjestelmien perustana olevat potilashallinnon prosessit ovat jossakin määrin epämääräiset eikä niihin liittyviä vastuita ole riittävän selkeästi määritelty. Toinen perusdiagnoosi liittyy nykyiseen tietojärjestelmien rakentamisen tapaan. Erityisesti eri osapuolten roolit ja vastuut kaipaavat täsmentämistä. Näitä hallinnollisia teesejä käsittelemme lukujen 2 ja 4 alussa. Potilastietojärjestelmien nykytilanteen ja tavoitteiden osalta haluamme tässä kirjoituksessa kyseenalaistaa usein tärkeimmäksi esitetyn väitteen, jonka mukaan potilastietojärjestelmän hyödyt tulisivat pääasiassa kertomustiedon laajasta saatavuudesta. On pikemminkin näyttöä siitä, että saatavuutta suuremmat hyödyt tietojärjestelmästä tulisivat siitä, että järjestelmä auttaa varmistamaan, että potilas saa oikea-aikaisesti vain hänen tarpeistaan lähtevät palvelut. Vieläpä siten, että hyödyttömät viiveet ja tarpeeton resurssien käyttö voidaan eliminoida. Järjestelmien toiminnallisuuden keskiöön tulisi asettaa potilaan hoidon sisältöä ja sujumista varmistava hoitologistiikan järjestelmä, joka aikaisempaa rakenteisemmalla tavalla tukee hoidon suunnittelua, toteuttamista ja seurantaa. Samalla tämä tietojärjestelmäosuus palvelee sairauskertomusosuutta tarjoamalla ammattilaiselle yhtenäisen näkymän potilaan kaikkiin tietoihin. Yleiskäyttöinen tilaus-vastaus-viestintäosuus muodostaa teknisen perustan tietojärjestelmän arkkitehtuurille, jossa eri toimittajien eri-ikäiset tietojärjestelmät toimivat käyttäjien ja käyttäjäorganisaatioiden kannalta kuin yksi tietojärjestelmä. Eräänlaisena todistuksena tämän logistisen osuuden tärkeydestä käynee se tosiasia, että kaikki varteen otettavat kansainvälisessä tarjonnassa olevat potilastietojärjestelmät sisältävät nämä hoidon oikea-aikaisuuden ja sisällön varmistamisen osuudet. Luvussa kolme pyrimme kuvaamaan vision siitä millainen järjestelmäkokonaisuus tai arkkitehtuuri voisi muodostua edellä mainitun tilaus vastaus-viestintäosuuden ympärille. Kutsumme näin muodostuvaa ydintietojärjestelmää potilasprosessin tietojärjestelmäksi (POP). POP-järjestelmän tulee kattaa ainakin eniten hyötypotentiaalia sisältävät perus- ja erikoissairaanhoidon prosessit sekä ne osuudet sosiaalitoimen palveluista, joiden osalta oikea ajoitus ja sisällön varmentaminen on prosessin ohjauksen kannalta tärkeätä. Oleellinen huomio on myös, että näkemyksemme mukaan itse POP-järjestelmän tulee perustua teknisesti yhtenäiseen kokonaisuuteen. Tämän ydinprosessin ulkopuolisiin järjestelmiin POP-järjestelmä kytkeytyy sopivan palveluväyläarkkitehtuurin kautta. Palveluväylä ja sen tarjoamat yhteiset palvelut ovat nekin tärkeä osa järjestelmäkokonaisuutta, vaikka sitä emme tässä kirjoituksessa tarkemmin käsittelekään. 2
Lähtökohtana vision sisältämälle arkkitehtuurille on myös se, että sen rakennuspalikoiden tulee olla mahdollisimman valmiita, koeteltuja tuotteita, joilla on riittävästi olemassa olevia asiakkaita. Rakennusurakka tulee siis pilkkoa siten, että rakennuspalikat vastaavat markkinoiden tarjontaa. Arkkitehtuuripohdintaan kuuluu, että rakennuskohteiden välinen työnjako ja rajapinnat tulee määritellä siten, että niistä löytyy kansainvälisiä standardeja tai mahdollisesti tarvittava räätälöintityö on mahdollisimman vähäistä. Neljäs luku käsittelee sitä, millaisilla periaatteilla tai toimenpiteillä tätä visiota kohti järkevästi päästään, siis strategiaa. Strategian keskeiset periaatteet tai linjaukset ovat 1. Potilastietojärjestelmällä pitää koko prosessista vastuun ottava kotiyksikkö 2. Tietojärjestelmien rakentamisessa projektin johto ja johtaminen ovat kaikki kaikessa 3. Korjaa ensin se mikä on rikki älä korjaa sitä mikä toimii 4. Pidä asiat yksinkertaisena 5. Käyttöönotettavan tietojärjestelmän tulee olla valmis, vältä itse kehittelyä 6. Onnistuminen vaatii johtamista 3
2. Nykytilan oireet ja diagnoosit Terveyskeskuksissa ja sairaaloissa käytössä olevat tietojärjestelmät ovat olleet kovan kritiikin kohteena. Kirjoittajat ovat työnsä puolesta kuulleet oman osansa nykyjärjestelmiin liittyvästä kritiikistä. Koska kyse on terveydenhuollon tietojärjestelmistä, lähtökohtatilannetta voisi ehkä kuvata alan käsitteitä käyttäen: Oireet on dokumentoitu, entäs diagnoosi?. Näkyvimpiä oireita Keskeinen oire on ainakin se, että hoitavan lääkärin tai hoitajan on varsin vaikeata muodostaa kokonaiskäsitys potilaan tilanteesta, koska tiedot ovat sirpaleisia tai eri tietojärjestelmissä. Tämä käyttöliittymän ominaisuus aiheuttaa jopa vaaratilanteita potilaille. Toinen yleisesti tunnistettu oire on, että potilaan kohtaamistilanteessa aikaa menee enemmän ruudun kuin potilaan hoitamiseen. Lisäksi on vähintäänkin epäsuoraa arviointi- ja jopa mittaustietoa siitä, että henkilötyön tuottavuus on laskenut verrattuna aikaan ennen tietojärjestelmien käyttöönottoa. Pari perusterveydenhuollon asiakastamme mittautti lääkärien avohoitokäyntien lukumääriä ennen ja jälkeen potilastietojärjestelmän käyttöönoton. Käyttöönoton jälkeen henkilötuottavuus oli laskenut, joka selvityksen tekovaiheessa tosin laitettiin uuden järjestelmän alkukankeuden piikkiin. Poliklinikoiden ajanvaraajien haastattelun perusteella, yksi erikoissairaanhoidon asiakkaistamme oli päätynyt johtopäätökseen, että uuden tietojärjestelmän käyttöönoton seurauksena päivittäisten ajanvaraussuoritteiden määrä oli pudonnut pahimmillaan jopa kolmanneksen. 1 Oireiden perussyyt - diagnoosit Pohdintaa siitä, että mitkä seikat voisivat olla perussyitä koettuihin ongelmiin, on näkynyt vähän. Ihmisten hoidossakaan diagnoosiksi ei kelpaa, että potilas on sairas tai että päätä särkee. Myös tietojärjestelmäkokonaisuuden kehittämisessä pätee periaate, että edellytys potilaan kuntoon saamiselle on pystyä tekemään oikea diagnoosi nykytilanteesta. Mitkä voisivat ovat perussyitä oireille? Liian yksinkertainen selitys on, että järjestelmä on huono. Ikään kuin kyse olisi tavaran tai tarvikkeen hankinnasta. Terveydenhuolto on laaja, samaan aikaan sekä inhimillisiä ja eettisiä että ammatillisia intressejä omaava palvelujärjestelmä. Palveluvalikoimaltaan, teknologialtaan ja osaamisvaateiltaan laajempaa palvelujärjestelmää ei yhteiskunnissa liene. Kun lisäksi terveydenhuollon rakenteet, järjestämistavat ja hallinnolliset lähtökohdat ovat nekin kovin moninaiset ja moniaineksiset, kuuluu terveydenhuollon perusolemukseen poikkeuksellisen monia eri näkökulmia. Näistä näkökulmista on aikojen kuluessa muodostunut enemmän tai vähemmän itsenäisiä malleja, joilla kullakin on oma logiikkansa. Terveydenhuollon tietojärjestelmissä nämä logiikat kohtaavat ja usein myös törmäävät. Usein toistettu julistus kuuluu: varsinaisessa terveydenhuollossa ja sen tietojärjestelmissä tulee nyt palata juurille. Terveydenhuolto on potilaita varten, ja potilaskeskeisyyttä tarvitaan myös terveydenhuollon tietojärjestelmiin. Vaikeampi asia on määritellä mitä tämä julistus tarkoittaa käytännössä. Alla hieman yritystä konkretisoida tätä missiota. 4
Erikoissairaanhoidon sairaala tai akuuttisairaala on monimutkainen kokonaisuus. Se on asiantuntijaorganisaatio, jossa on myös prosessiteollisia piirteitä ja joka on jakautunut tietyn ongelman ratkaisuun erikoistuneisiin yksiköihin erikoisaloihin. Haasteena on saada saman potilaan tutkimiseen ja hoitoon osallistuva verkosto pelaamaan yhteen siten, että potilaan ongelma saadaan hoidetuksi niin, että kaikki tarpeellinen tehdään mutta ilman viiveitä ja ilman ongelman hoidon kannalta tarpeettomia aktiviteetteja. Tämän peruspäämäärän tukeminen on myös tietojärjestelmien perustarkoitus. Diagnoosi 1 potilashallinnon prosessivastuut Ensimmäinen perushavainto on se, että potilastietojärjestelmiä rakennetaan huonosti määriteltyihin toimintaprosesseihin, joiden toiminnasta lisäksi ei vastaa oikein kukaan. Nyt emme tarkoita potilaan hoitamista vaan hoitoa tukevia tukitoimintoja, jonka tarkoituksena on, että palvelutuotantoa voidaan paremmin suunnitella ja monitoroida, dokumentoida hoitamisprosessiin kuuluvat oleelliset tiedot ja lopuksi arkistoida dokumentit turvallisesti. Kyse on siis toimintokokonaisuudesta, jota ammattilaiset kutsuvat potilashallinnoksi. Tässä mielessä potilashallinto vertautuu vaikkapa henkilöstö-, materiaali- tai kiinteistöhallintoon tai niihin liittyviin palveluihin. Potilashallintopalvelujen tuottamiseen osallistuvat mm. osasto-/klinikkasihteerit, sanelujen puhtaaksikirjoittajat, arkistohenkilöstö jne. Maailmalla on esimerkkejä siitä, että sairaalassa on potilashallinnosta vastaava yksikkö. Tämä yksikkö vastaa potilashallinnon tukipalvelusta hoitoyksiköille ja vastaa myös tietojärjestelmistä, jotka ovat sen työväline tuottaa tarvittavat palvelut. Suomalaisissa sairaanhoitopiireissä potilastietojärjestelmien omistajana toimii yleensä hallinnollinen tms. ylilääkäri. Käytännössä rooli on kuitenkin jäänyt IT-yksiköille. Heidän lähestymistapansa on luonnollisesti ollut varsin tekninen. Ja potilashallinnon prosesseja pyörittävä henkilöstö on taas ollut hoitoyksiköiden työohjauksessa tai arkiston tapaan osana hallintopalveluja tms. Diagnoosi 2 potilastietojärjestelmien urakointi Toinen perussyy ongelmiin voi olla se, että suomalaisessa erikoissairaanhoidossa tietojärjestelmien hankinta - ja varsinkin toimittamisen periaatteet ovat olleet muihin toimialoihin verrattuna erikoisia. Erityisesti yliopistosairaaloissa tietojärjestelmien toimittamisen rooli- ja vastuujaot ovat jääneet pääosiltaan aikaisempien vuosikymmenien toimintamalliin (ks. kuva 2.1). Lisäksi mielenkiintoisen näkökulman ylipäätään IT-urakointiin voi tuoda vertailu rakennusalaan. Kirjoittajat ovat keskustelleet SRV Oyj rakennusyhtiön edustajan kanssa ymmärtääkseen voisiko perinteisen alan toimijalta oppia jotakin IT-alalle. SRV Oyj on rakennusalan toimija, joka palveluissaan keskittyy rakennusprojektien johtamiseen sillä ajatuksella, että projektijohtamisen mukana urakat joko onnistuvat tai kaatuvat (Heimo Sillanpää, SRV Oy, rakennusjohtaja, suullinen tiedonanto). Projektijohtamiseen panostaminen on tuonut useita onnistumisia, joista tunnetuimpia lienevät Kampin liikekeskus ja Helsingin Musiikkitalo. Kampin liikekeskuksen kokonaisurakan loppusumma oli n. 400 milj. e ja Musiikkitalon vastaavasti n. 160 milj. e. Panostamista projektijohtamiseen kuvastaa se, että Kampin projektin ohjaustehtävissä SRV:sta oli työvaiheesta riippuen 40-60 henkeä ja Musiikkitalossa 5
vastaavasti 20-25 henkeä. Kummankin rakennushankkeen johtajana toimi sama henkilö, jolla oli takanaan yli 20 vuoden ajalta kymmeniä suuria onnistuneita projekteja. Pääurakointi ja tähän rooliin kuuluva järjestelmien integrointi on vaativin rooli tietojärjestelmien rakentamisessa. Pääurakoitsija joutuu vastaamaan järjestelmälle asetettujen toiminnallisten tavoitteiden toteutumisesta, käyttäjäkokemuksesta, pääurakan projektihallinnosta sekä tähän liittyvien aliurakoiden ja vastaavien osatietojärjestelmien yhteensovittamisesta. Pääurakoitsija tekee sopimukset alkaen verkoista ja palvelimista päätyen yksittäisten osastotietojärjestelmien integrointiin ja eri järjestelmäpalojen ylläpitopalveluihin. Hieman kärjistäen tilannetta voi tilannetta analysoida siten, että pienet ja keskisuuret sairaanhoitopiirit ja terveyskeskukset ovat ehkä resurssipulansa seurauksena toteuttaneet suuressa määrin pääurakoitsijamallia ja muutenkin verraten selkeää rooli- ja vastuujakoa. Ja myös käyttäjätyytyväisyys on selvästi paremmalla tasolla kuin suurissa yksiköissä. Kuva 2.1 Oma IT-yksikkö tai yhtiö pääurakoitsijana (järjestelmäintegraattorina) 6
Diagnoosi 3 nykyjärjestelmät Laajahkon omakohtaisen tiedonkeruumme ensimmäinen havainto on se, että terveydenhuollon tietojärjestelmiin liittyvä tyytymättömyys ei olekaan kaikkialla aivan samanlaista. Ääriesimerkkinä on tilanne Pohjois-Pohjanmaan sairaanhoitopiirissä tai Pohjois-Karjalan sosiaali- ja sairaanhoitopalvelujen kuntayhtymässä, joissa haastattelujen perusteella lääkäreiden ja hoitohenkilökunnan tyytyväisyys tai ainakin äänekkään tyytymättömyyden puuttuminen vaikuttaa ilmeiseltä. Toisessa ääripäässä taas tuntuu olevan muiden eräiden yliopistosairaaloiden Oberon-Miranda-järjestelmä, johon ammattilaiset ovat lähes yksimielisesti tyytymättömiä. Mikä voisi olla perussyy oireiden erilaisuuteen? Kirjoittajien kokemukseen perustuva vakaa käsitys on, että keskeinen diagnoosi on se, miten eri järjestelmät ja niiden muodostama kokonaisuus on rakennettu siis järjestelmäarkkitehtuuri. Oberon Miranda-maailmassa käyttäjä todellisuudessa käyttää useaa erillistä järjestelmää työpöytänsä eri ikkunoissa. Alla oleva kuva 2. 2 havainnollistaa tilannetta. Kuva 2.2 Käyttäjä käyttää työpöydällään eri tarkoituksia varten eri tietojärjestelmiä. Integraatio on hoidettu nk. työpöytäintegraation avulla. Käyttäjän kannalta kaavion työpöytäintegraatio tarkoittaa siis sitä, että käyttäjä käyttää eri valmistajien eri käyttölogiikalla tehtyjä järjestelmiä omissa ikkunoissaan. Tapa on sama, jolla toimistotyöntekijä käyttää vaikkapa Wordia yhdessä ikkunassa ja nettiselainta toisessa. Kokonaiskuvan muodostaminen potilaan tiedoista on hankalaa, sillä tiedot ovat pirstaleisena eri järjestelmissä ja käyttöliittymissä. On vaikeata varmistaa, että hoitavan lääkärin 7
tietoon tulee esimerkiksi potilaan käynnin jälkeen saapuva patologian vastaus, jossa on ehkä kiireellistä kannanottoa vaativa löydös. Syyt edellä kuvattuun pirstaleisuuteen erityisesti juuri yliopistosairaaloiden osalta saattavat olla siinä, että tietojärjestelmien toiminnallisuusvaatimukset ovat syntyneet varsin pitkälle yksikkökohtaisissa siiloissa. Puuttumaan on jäänyt näkemys siitä miten järjestelmän pitäisi toimia potilasta hoitavan ammattilaisen näkökulmasta, jotta potilaan asiat tulisivat kokonaisuutena mahdollisimman hyvin hoidetuiksi. Näin ollen tietojärjestelmät kyllä toimivat optimaalisesti kliinisen laboratorion, kuvantamisyksikön, leikkaussalin jne. näkökulmasta, mutta eivät potilaan kokonaishoidon kannalta. Vertailukohtana Effica-, Pegasos- ja Esko-järjestelmät ovat käyttöliittymän osalta Oberon-Mirandaa yhtenäisempiä kokonaisuuksia. Toisaalta näissäkään järjestelmissä ei ole toiminnallisuutta, joka tukisi potilasprosessin ohjausta kokonaisvaltaisesti. Siihen palataan tässä kirjoituksessa myöhemmin. Diagnoosi 4 Tietovirrat Tässä luvussa tarkastellaan terveydenhuollon tietovirtoja eri näkökulmista ja arvioidaan niiden vaikutusta terveydenhuollon tietojärjestelmäarkkitehtuureihin. ASIAKASPALVELUNÄKÖKULMA Terveydenhuollossa asiakkaat liikkuvat usein jo yhden ongelman hoitamisessa monien eri terveydenhuollon toimijoiden piirissä. Jos potilaalla on useita ongelmia, niin toimijoiden kokonaismäärä kasvaa entisestään. Perinteinen esimerkki tästä monitoimijamallista on suomalaisen julkisen terveydenhuollon jakaantuminen perusterveydenhuoltoon ja erikoissairaanhoitoon. Kun asiakkaat palvelua saadessaan liikkuvat tämän rajapinnan yli, myös palveluun liittyvän tiedon virtaaminen joustavammin ja kattavammin saman rajapinnan yli on yleisesti tunnistettu kehityskohde suomalaisissa terveydenhuollon tietojärjestelmäarkkitehtuureissa. Alla on tilastoyhteenveto HUS:n, Helsingin ja Espoon tuottamista palveluista. Luvut osoittavat kuinka paljon yhteisiä ja vain omassa organisaatiossa hoidettuja potilaita on kahden seurantavuoden aikana (Jorma Lauharanta 2013, suullinen tiedonanto). Asiakasprofiili Espoo Helsinki Vain kaupunki 34 % 50 % Kaupunki ja HUS 38 % 27 % Vain HUS 8 % 12 % Kunnalliset palv yht 80 % 89 % Taulukon kaupunkien terveystoimella ja HUS:lla on siis yhteisiä henkilöasiakkaita tietojärjestelmissään kahden vuoden aikana keskimäärin yli 30% väestöstä (noin 260 000). Mutta huomionarvoista taulun tiedoissa on myös se, 8
että kunnan rahoittamia palveluja on saanut väestöstä kahden vuoden aikana yli 85%. Osa vain HUS:ssa palveluja saaneista henkilöistä saa perusterveydenhuollon palvelut yksityisesti tuotetusta työterveyshuollosta, mikä perustelee sitä, että tietojärjestelmien ominaisuuksiin tulisi kuulua myös vähintään yhteisten asiakkaiden tietojen katselu yli organisaatiorajojen. PALVELUTUOTANTONÄKÖKULMA Terveydenhuollon palvelutuotannon sisällä tietoa virtaa potilaan ja kliinikon välillä ja edelleen erilaisten tietoa tuottavien ja käsittelevien tuotantojärjestelmien toimintojen kautta. Tyypillinen tietoa tuottava toiminto terveydenhuollossa on diagnostiikka, jossa kliinikon pyynnöstä potilas tai hänestä saatava näyte analysoidaan tuottamaan tietoa kliinisen päätöksenteon tueksi. Palvelutuotantoon liittyvä oleellinen havainto on, että se jakaantuu pääprosessina olevan potilaan hoitoprosessin alla useisiin toisiinsa liittyviin tukiprosesseihin, joihin liittyy erilaisia sisäisiä tietovirtoja. Niiden tapa hahmottaa tietoa voi olla lähtökohtaisesti erilainen kuin kliinikolle näkyvässä potilaan hoitoprosessissa. Kliinikko näkee esimerkiksi laboratorion osapuolena, johon hän lähettää tutkimuspyyntöjä ja saa sieltä vastauksena tuloksia tai lausuntoja osana potilaan hoitoprosessia. Laboratorioprosessin kliinikolle näkymättömässä osassa virtaa kuitenkin paljon monimutkaista tietoa, jota laboratorio tarkastelee lähtökohtaisesti näyte- eikä potilasprosessina, osana omaa toiminnanohjaustaan. Toisaalta laboratoriodiagnostiikka kehittyy tällä hetkellä eri tahtiin ja nopeammin kuin moni muu terveydenhuollon toiminto. Tämä kehityssyklien erilaisuus koskee myös eri toimintojen sisäisten tietomuotojen ja -virtojen kehittymistä. Yksi palveluntuotantoon liittyvä tietovirtanäkökulma on, että iso osa tukiprosessien tietovirroista on paikallisia, vain kyseisille prosesseille suunnattuja. Toisin sanoen tätä tietoa ei tarvita prosessin ulkopuolella, ja prosessi voi jatkaa toimintaansa varsin itsenäisesti sen varassa. Kuvassa 2.3 on havainnollistettu kliinisen laboratorion ulkoisen ja sisäisen prosessin tapahtumamäärien suhdetta (<1/100) eli sitä, miten monta tapahtumaa liittyy siihen, että laboratoriolähetettä vastaava vastaus tuotetaan laboratoriossa. Valtaosa sisäisen prosessin tiedosta on siis sellaista, jota ei välitetä koskaan kliinikolle. Kuvantamisessa, ja esimerkiksi leikkaus- ja synnytyssalitoiminnassa, vastaava ulkoisten ja sisäisten tapahtumamäärien suhde on kummassakin n. 1/200. 9
Kuva 2.3 Kliinisen laboratorion sisäisen ja ulkoisen prosessin tapahtumamäärien suhde Terveydenhuollon tietojärjestelmäarkkitehtuurissa on siis otettava huomioon, että terveydenhuollon palvelutuotantoon liittyy tietoa tuottavia ja käsitteleviä osaprosesseja, joiden vaatimukset poikkeavat merkittävästi pääprosessina toimivasta potilaan hoitoprosessista. Jos arkkitehtuuri perustuu liian kiinteään kokonaisuuteen, joka on rakennettu puhtaasti potilaan hoitoprosessin ehdoilla, ei näiden tukiprosessien oman toiminnan ohjausta voida palvella kokonaisvaltaisesti, alakohtaisesti ja oikea-aikaisesti. Tämä johtuu erilaisista lähtökohdista tarkastella tietoa ja toisaalta alojen erilaisista kehityssykleistä. Lisäksi se, että iso osa tukiprosessien tiedosta on paikallista ja vain niille suunnattua, mahdollistaa myös tehokkaan, hajautukseen perustuvan riskienhallinnan, jos tukiprosesseja palvellaan niiden omilla toiminnanohjausjärjestelmillä. Mielenkiintoisen lisämausteen tähän palvelutuotantonäkökulmaan tuo sosiaali- ja terveydenhuollon järjestämislaki ja sen pohjalta mitä ilmeisimmin tapahtuva perusterveydenhuollon ja erikoissairaanhoidon organisatorinen yhdistäminen. Tämä voisi hyvin toteutettuna merkittävästi yksinkertaistaa ja optimoida palvelutuotannon rakennetta ja siihen liittyviä tietovirtoja purkamalla päällekkäisyyksiä ja epäjatkuvuuskohtia terveydenhuollon tuotantojärjestelmästä. 10
Diagnoosi 5 tietotekniikka-alan eräät peruslainalaisuudet IT-alalla on kirjoittajien mielestä joitakin melko kiistattomia käsityksiä siitä, mitä periaatteita noudattamalla voidaan osaltaan varmistaa hankkeiden onnistumista. Kunnallispolitiikassa on mukana IT-alan ammattilaisia, jotka ovat omalta osaltaan tuoneet potilastietojärjestelmäkeskusteluun mukaan tietotekniikka-alan yleisiä oppeja ja trendejä. Yleinen näkemys alalla on, että tavoitteiltaan liian laajat tietojärjestelmähankkeet on tuomittu epäonnistumaan. Jos tietojärjestelmäarkkitehtuurin lähtökohta on yksittäisjärjestelmä, ja sille asetetut vaatimukset ovat kovin laajoja, niiden hallinta järjestelmää toteutettaessa ja käyttöönotettaessa on erittäin monimutkaista. Tällöin törmätään myös siihen tosiasiaan, ettei mikään markkinoilla oleva tuote täytä vaatimuksia. Samalla hankkeen riskit kasvavat merkittävästi. Realistisempi tapa lähestyä alueellisen potilastietojärjestelmän kaltaista kokonaisuutta on rakentaa ja käyttöönottaa sopivan kokoinen pala kerrallaan esimerkiksi palveluväyläarkkitehtuuriin tukeutuen. Valmiisiin tuotteisiin tukeutumista ja hankkeiden vaiheistamista käsitellään kohdassa 4 enemmän. Toinen alalla yleisesti tunnistettu tosiasia on, että mitä tahansa toimintaa on vaikea kehittää pelkästään tietojärjestelmää vaihtamalla. Muutoksen pitää lähteä uusien toimintatapojen määrittelystä ja käyttöönotosta, joita uusi tietojärjestelmä sitten mahdollistaa ja tukee. Edelliseen pohdintaan liittyen myös toiminnan kehittäminen on helpompaa, kun kokonaisuus koostuu sopivan kokoisista palasista. Parhaimmillaan muutoksia joudutaan tekemään vain siihen järjestelmän osaan, johon liittyvää toimintaa kehitetään. Toisaalta tulee myös pitää mielessä, että kokonaisuutta ei tule pilkkoa liian pieniksi palasiksi, sillä se voi johtaa haasteisiin kokonaisuuden hallinnassa ja kokonaiskuvan hämärtymiseen toiminnan kehittämisessä. Hyvä ohjenuora on, että palasten koko ja sisältö seurailee järjestelmän toimintaympäristön luonnollista toiminnallista rakennetta. Esimerkki tällaisesta toimintaympäristön luonnollisesta rakenteesta ovat diagnostiikka ja sen toiminnanohjausjärjestelmät. 11
3. Vallitsevien olojen korjaaminen millainen tietojärjestelmäkokonaisuus tavoitteeksi? Edellä kuvattiin joitakin lähtökohtia terveydenhuollon tietojärjestelmäarkkitehtuurin rakenteelle. Eri näkökohtia kokoavaksi perusvaatimukseksi nousee tarve potilaan hoitoprosessin ohjaukselle. Tämä koskee erityisesti potilastietojärjestelmien niitä toiminnallisuuksia, jotka näkyvät hoitavan lääkärin tai sairaanhoitajan työpöydillä. Erityisesti sairaalahoidon aikainen työ terveydenhuollossa on prosessimaista ja hyödyntää laajasti eri lähteistä peräisin olevaa tietoa. Tällaista järjestelmää, joka sisältää potilashallinto - ja kertomustoiminnallisuudet, voidaan kutsua potilasprosessin tietojärjestelmäksi, joka kattaa sekä julkisen perusterveydenhuollon että erikoissairaanhoidon kliinikon tarpeet yhdessä kokonaisuudessa. Tämä palvelu liittyy, alueellisen palveluväylän kautta, myös yksityisen terveydenhuollon (kuten työterveyshuol lon) järjestelmiin. Palveluväylä tarjoaa myös liittymät yleisiin julkishallinnon alueellisten ja kansallisten toimijoiden tietojärjestelmiin. Kuvassa 3.1 on esitetty potilasprosessin tietojärjestelmä osana palveluväyläarkkitehtuuria ja terveydenhuollon alueellisen tietojärjestelmäarkkitehtuurin ytimessä. Kuva 3.1. Terveydenhuollon potilasprosessin tietojärjestelmä osana palveluväyläarkkitehtuuria Tämä palveluväyläarkkitehtuuriin perustuva malli on sukua esimerkiksi Viron kansalliselle X-Road - integraatioalustalle, joka tarjoaa peruspalvelut julkishallinnon ja osittain myös yksityisen sektorin tietojärjestelmien yhteistoiminnalle ja tiettyjen tietojen yhteiskäytölle. 12
Usein kuulee sanottavan, että tärkeintä terveydenhuollon tietojärjestelmissä on, että kaikki tieto on käytettävissä. Kuitenkin potilaaseen liittyvän historiatiedon arvo kliinikolle laskee varsin nopeasti, kun aikaa kuluu tiedon syntyhetkestä. Iso osa kaikesta tiedosta onkin turhaa potilaan hoidolle. Ja vielä paremmin: ilman tiedon käyttötilanteeseen sovitettua suodatusta, suuri määrä epärelevanttia dataa helposti piilottaa hoidon kannalta oleellisen informaation. Alalla tehty kansainvälinen tutkimus on osoittanut, että nopein ja varmin investointien takaisinmaksu saavutetaan ratkaisuilla, jotka tukevat hoitoprosessia auttamalla poistamaan siitä erilaista hukkaa eli potilaalle lisäarvoa tuottamatonta turhaa odottelua, turhia tai vääräaikaisia tutkimuksia ja hoitotoimenpiteitä jne. Tällainen lähestymistapa on lähellä teollisuuden LEAN-ajattelua, jossa pyritään siihen että oikea määrä oikeita asioita saadaan oikeaan aikaan ja oikeaan paikkaan oikeanlaatuisina. Tällöin toteutuu myös hoitoprosessissa se tavoite, että potilaan tarpeeseen perustumaton toiminnan vaihtelu minimoituu. Hyvä esimerkki hukkaa poistavalla prosessiohjauksella saavutettavista hyödyistä on bostonilaisen Brigham and Women s Hospital -sairaalan CPOE-toiminnallisuuden (Computerized Physician Order Entry eli tietokoneavusteinen tutkimusten ja toimenpiteiden tilausjärjestelmä siis POP-järjestelmän ydin) käyttöönotosta tehty investointianalyysi 1, joka osoitti, että käyttöönotolla saavutettiin kymmenen vuoden aikana kumulatiivinen n. 20 miljoonan euron säästö. Massachusettsin osavaltiossa onkin säädetty laki, joka velvoittaa CPOE-järjestelmän käyttöönottoon kaikissa osavaltion sairaaloissa. Vertailua varten voidaan mainita, että Brigham and Women s Hospital -sairaalassa on vuodepaikkoja suurin piirtein yhtä paljon kuin Meilahden vanhassa tornisairaalassa ja uudessa kolmiosairaalassa yhteensä. CPOE-toiminnallisuudessa potilaskohtaiset tutkimus-, toimenpide- ja hoitotilaukset kertyvät yhteen tietokantaan, johon tallentuvat myös kuittaukset niiden suorittamisesta tai perustelut suorittamatta jättämiselle. Kun potilaalle tehdään tutkimus-, toimenpide-, hoito- tai materiaalitilauksia, tilauksen tekijä kirjaa sen potilaan tietoihin yhteen paikkaan. Tietojärjestelmä välittää pyynnöt tai lähetteet ( tilaukset ) sanomina erikois- ja palvelualojen toiminnanohjausjärjestelmiin (esim. laboratorion, kuvantamisen, äitiyshuollon, kirurgian, teho-osastojen, sairaalaapteekin jne.). Kun tulos, vastaus tai lausunto on valmis, järjestelmien välinen sanomaliikenne huolehtii siitä, että se, ja siihen liittyvä metatieto kuten kuvalinkit, välittyvät lääkärin tai hoitajan käyttämään potilastietojärjestelmään, jolloin kaikki potilaan hoitoon liittyvä tieto eri lääketieteen erikoisaloilta on CPOE-toiminnallisuuden kautta katsottavissa yhdessä paikassa. Yksi perinteinen vastaväite tällaista sanomapohjaista integraatiota vastaan on ollut, että näiden rajapintojen synty johtaa siihen, että tietoa joudutaan pelkistämään ja yksinkertaistamaan, jotta se saadaan siirtymään kahden järjestelmän välillä johtuen sovellettavien tiedonvälitysstandardien rajoituksista. Esimerkiksi rajapinnassa voidaan menettää osa tiedon tuottaneen järjestelmän sille määrittelemästä rakenteellisuudesta, joka johtaa sen 1 Kaushal R, Jha AK, Franz C, Glaser J et al. Return on investment for a computerized physician order entry system. J AmMed Inform Assoc. 2006 May-Jun;13(3):261-6. 13
käytettävyyden putoamiseen kohdejärjestelmän puolella, tai että tiedon esitystapaan liittyvää tietoa (värikoodaukset tms.) ei saada kattavasti siirrettyä rajapinnan yli tai sitä ei osata hyödyntää kohdejärjestelmässä. Nykypäivänä näihin tiedonvälityksen ja esityksen ongelmiin pääsääntöisesti löytyy kuitenkin toimivat tekniset ratkaisut. Juuri edellä kuvatun CPOE-järjestelmän filosofiaa noudattava ja sen pohjalta laajennettu perustoiminnallisuus on näiden nykyaikaisten potilasprosessia palvelevien tietojärjestelmien ytimessä ja muodostaa kivijalan LEAN-ajattelun mukaiselle laadunhallinnalle. CPOE-tyyppisen toiminnallisuuden luonnollisena laajennuksena se toteuttaa uudenlaisen kattavan ja rakenteellisen potilaskertomuksen, joka perustuu samanlaiseen tapahtumakohtaiseen kirjaustapaan. Lääketieteen erikois- ja palvelualojen toiminnanohjausjärjestelmien tuottaman tulos-, vastaus- ja lausuntotiedon lisäksi perusterveydenhuollon ja erikoissairaanhoidon kliinikolla on mahdollisuus kirjata omat kliiniset havaintonsa ja interventionsa (esim. kuume- ja verenpainemittaukset, haavanhoidot, lääkkeiden annot jne.) tapahtumakohtaisesti järjestelmään. Nykyaikaista potilasjärjestelmäarkkitehtuuria havainnollistaa alla oleva kuva 3.2. Kuva 3.2 Käyttäjä käyttää yhtä potilastietojärjestelmää. Integraatio tapahtuu järjestelmien välisenä sanomapohjaisena viestinvaihtona Käytännössä CPOE ja sen taustalla oleva järjestelmä toimii työkaluna potilaan hoidon vuorovaikutteiselle suunnittelulle. Kirjaustilanteessa voidaan mm. varoittaa suunnitelmaan sisältyvän lääkeaineen yhteisvaikutuksesta olemassa olevan lääkityksen kanssa tai poimia hoitokäytäntöihin liittyviä paikallisia määräyksiä tai hyviä hoitokäytäntöjä (rakenteellisia hoitoprotokollia) yhteisesti ylläpidetyistä tietämyskannoista kliinisen päätöksenteon 14
tueksi 2. Kun potilastietojärjestelmissä on toteutettu edellä kuvattuun rakenteelliseen kirjaustapaan perustuvat tietorakenteet ja toiminnallisuus, niin se mahdollistaa mahdollista laadun varmistamisen hoitotilanteessa ja jälkikäteen tapahtuvan hoitoprosessien tilastollisen laatuseurannan. Lisäksi tietomallin rakenteellisuus mahdollistaa tiedon haun, suodattamisen ja järjestämisen siten, että potilaan tiedoista voidaan muodostaa kokonaisnäkemys. Sama rakenteellisuus mahdollistaa myös edellä mainittujen erilaisten tietämyskantojen tehokkaan hyödyntäminen. Oleellinen huomio rakenteelliseen tietomalliin liittyen on, että sen ja siihen liittyvien koodistojen ja luokittelujen määrittely ja ylläpito vaatii paljon aikaa ja työtä. Kuvassa 3.2 on vielä esitetty kerroksellisesti se, miten potilasprosessin tietojärjestelmä palvelee suoraan ytimessä olevaa potilaan kliinistä ydinprosessia. Tätä tarkoitusta varten se samalla tukeutuu yhtäältä lääketieteellisten erikoisja palvelualojen toiminnanohjausjärjestelmiin, jotka tuottavat sille jalostettua tietoa omissa prosesseissaan, ja toisaalta hallinnon tietojärjestelmiin ja tietokantoihin tukijärjestelminä. Kuva 3.2. Terveydenhuollon potilasprosessin tietojärjestelmä ja sen liittymät Usein esitetään hyödylliseksi tavoitteeksi tietojärjestelmiä uusittaessa, että ne perustuvat avoimiin arkkitehtuureihin tai suorastaan avoimeen lähdekoodiin. Terveydenhuollon tietojärjestelmien arkkitehtuurin avoimuudella voidaan tarkoittaa montaa eri asiaa. Monestakin syystä on tänä päivänä mielekästä, että kuvatuntyyppinen järjestelmä rakennetaan avoimen lähdekoodin varusohjelmistojen päälle (käyttöjärjestelmä, tietokanta- ja sovelluspalvelin-ohjelmistot) siten, että se tarjoaa avoimet rajapinnat tiedon ja toiminnallisuuden jakamiseen soveltaen hyväksi todettuja kansainvälisiä standardeja kuten HL7 ja DICOM. Sovellusohjelmistot ovat kuitenkin pääasiassa suljetun lähdekoodin ohjelmistoja, ja niiden kehittämiseen ja ylläpitoon tarvitaan ammattimaiset, kaupallisesti toimivat tahot jo senkin takia, että ohjelmistot rinnastetaan 2 Esimerkkinä Kustannus Oy Duodecimin EBMeDS on kliinisen päätöksentuen palvelu, joka tuottaa käyttäjälle potilaskohtaisesti räätälöityjä toimintaohjeita. Palvelu yhdistää potilaan tilaa kuvaavat sähköiseen potilaskertomukseen tallennetut tiedot lääketieteelliseen tietoon. 15
enenevässä määrin muihin hoidollisiin teknologioihin. Tämän seurauksena tuotevastuukysymykset korostuvat ja myös viranomaissäätely on korostunut CE merkintä- tai hyväksymisvaatimuksineen. Millään toimialalla ei ole nähty laajoja onnistuneita esimerkkejä toimintaprosessien ohjausjärjestelmistä, jotka perustuisivat sovellusohjelmiston osalta avoimeen lähdekoodiin. 16
4. Vallitsevien olojen korjaaminen miten tavoitteeseen päästään? Yllä esitetystä kehittämisen tavoitteesta ja tietojärjestelmän yleiskaavasta (arkkitehtuurista) voi kohtuullisen helposti määritellä yleisesti sovellettavan kuvan, joka sopii moneen tilanteeseen. Toisin on sen tiekartan kanssa, joka kertoo, miten tähän maaliin voi päästä. Tätä tiekarttaa kutsumme tässä tietojärjestelmän kehittämisstrategiaksi. Polkuja on monia, ja valittu polku riippuu lähtötilanteesta ja mm. yleisjohtamisen näkökulmasta asetetuista prioriteeteista. Alla esitetyssä tarkastelussa on otettu esiin joitakin keskeisimpiä seikkoja, joiden toteuttaminen tai välttäminen on mielestämme tärkeätä maaliin pääsemiseksi. Ne ovat siten strategisia. Kutsumme näitä tiekartan strategisia kohtia ideoiksi. Alla esitellyt ideat eivät ole tärkeysjärjestyksessä. Ideat on koottu siten, että samaan aihepiiriin liittyvät ideat ovat pääosin allekkain. Periaate 1: Potilashallinnon organisointi Potilashallinnon organisointi ja resursointi on keskeinen kysymys. Otamme asian konkretisoimiseksi esimerkin toisesta terveydenhuollon toiminnosta, laitoshuollosta. Laitoshuollolla tarkoitamme tässä etenkin hoitoyksiköissä tapahtuvaa siivoustoiminnan, ravitsemushuollon yms. toimintoja. Laitoshuolto organisoitiin uudelleen monessa sairaanhoitopiirissä 1990- ja 2000-lukujen kuluessa. Tämä palvelutoiminta siirrettiin henkilökuntineen ammattijohdon vetämiin tukipalveluyksikköihin. Tulokset olivat sekä kustannusten että laadun kannalta hyvät. Historia tuntee useita muitakin toimintoja, joissa hallinnon historia on samantapainen. Kirjoittajat haluavat nostaa keskusteluun kysymyksen siitä, pitäisikö nyt 2010 luvulla tehdä sama potilashallinnon palveluille keskittämällä velvollisuuksia, vastuita ja resursseja. Potilashallinnon vastuuyksiköt tuottaisivat potilashallinnon palveluja, mm. osastosihteeri-, arkisto-, sanelujen purku- ja ehkä myös joitakin hoidonvarauspalveluja. Potilashallinnon yksikkö olisi myös vastuussa tietojärjestelmien kehittämistarpeista, oman henkilöstönsä ja palvelun käyttäjien osaamisesta sekä muista toimenpiteistä, joilla varmistetaan hyötyjen toteutuminen. Yksi käytännöllinen vaihtoehto potilashallinnon palvelujen terävöittämiseksi saattaisi olla sellainen ratkaisu, että nykyisten IT-yksiköiden tehtäväksi määriteltäisiin aikaisempaa selvemmin potilashallintopalvelut ja niiden kehittäminen. Nykyiset arkistointi-, sanelujen purku- ja osastosihteeritoiminnot keskitettäisiin johtamisen ja henkilöresurssien osalta IT- ja potilashallintoyksikköihin. Näin menetellen toteutuisi nykyistä selkeämmin tietojärjestelmien omistajuus tietojärjestelmät ovat potilashallintoyksikön työväline tarjota palveluja päätoiminnoille. Järjestelmän käyttäjänä toimivat sisäiset yksiköt ovat tietysti loppuasiakkaina ainoa ohjenuora tietojärjestelmätarpeille mutta potilashallintoyksikkö vastaa tarpeiden mukaisten tietojärjestelmien teettämisestä ja ylläpitoon liittyvistä pääkäyttäjätehtävistä. 17
Periaate 2: Pääurakoitsija ja projektin johtaja ovat kaikki kaikessa IT-alaa perinteisemmillä aloilla kuten rakennustoiminnassa tai laivanrakennuksessa on opittu, että onnistuneessa hankkeessa on keskeistä ostajan, rakennuttajan, pääurakoitsijan ja aliurakoitsijoiden onnistunut roolitus ja osaaminen. Ostajan ja loppukäyttäjän rooli on määritellä tavoiteltavat hyödyt ja kustannusraamit. Ostajaorganisaation tehtäviin kuuluu erityisesti toteuttaa tarvittavat toiminnalliset muutokset, jotta tavoitellut hyödyt realisoituisivat. Rakennuttajan tai pääurakoisijan osaamisen keskeisin alue on projektijohtaminen. Pääurakoitsijan tehtävänä on suunnitella kokonaisuus siten, että eri osat toimivat ostajan kannalta saumattomasti. Vain harrastelijapohjalta voidaan lähteä siitä, että talon loppukäyttäjä itse tekee suoraan sopimukset eri aliurakoitsijoiden kanssa. Mutta niinpä nämä harrastelumallilla toteutetut rakennusprojektit eivät olekaan tunnettuja siitä, että niissä aikataulu, laatu ja kustannukset vastaisivat odotuksia. Rakennusalalla on yleisesti hyväksytty hyvänä käytäntönä se, että tarvitaan hyvää osaamista ja yhteistyötä rakennuttajan ja pääurakoitsijan välillä. Keskeinen seikka on, että rakennuttajalla tulee olla hyvä osaaminen käyttäjävaatimuksista ja pääurakoitsijalla rakennusprojektin johtamisesta ja alihankkijoiden hallinnasta. Riittävä osaaminen kertyy vain toistamalla riittävän monta kertaa samantyyppisiä hankekokonaisuuksia. Sama lainalaisuus pätee IT-alalla. Rakennusalan hyvien käytäntöjen siirtäminen terveydenhuollon IT-järjestelmien rakentamiseen tarkoittaisi sitä, että etenkin suurissa hankkeissa ryhdyttäisiin systemaattisesti käyttämään rakennuttajakonsulttia tilaajan apuna. Rakennuttajakonsultti auttaisi etenkin kokonaisarkkitehtuurin suunnittelussa ja toiminnallisten tavoitteiden siirtämisessä järjestelmävaatimuksiksi. Lisäksi tilaajakonsultti auttaisi tarjousprosessien läpiviennissä. Toinen rakennusalan perusoppi pääurakoinnista ja siihen liittyvästä projektijohtamisesta tarkoittaisi sitä, että pääurakoitsija vastaisi myös ali- ja sivu-urakointien johtamisesta. Käytännössä IT -hankkeisiin siirrettynä tämä tarkoittaisi sitä, että vaikka terveydenhuollon yksikkö tekisikin erikseen sopimukset vaikkapa leikkaussalijärjestelmän käyttöönotosta ( sivu-urakka ), niin järjestelmän liittäminen alistettaisiin pääurakan johtoon. Vastaavasti, vaikka toinen urakoitsija vastaisikin perustietotekniikan tai käyttäjäkoulutuksen aliurakoinnista, pääurakoitsija vastaa kokonaisuuden johtamisesta laatu- ja kustannusnäkökohdista sekä tähän liittyvistä aliurakoitsijoiden töiden valvonnasta ja laskutuksesta (Heimo Sillanpää, SRV Oy, suullinen tiedonanto). Käytäntöjä ei luonnollisesti voi sellaisenaan siirtää alalta toiselle, mutta periaatteellisella tasolla aloilla, joilla on pitkät perinteet, on kokemukseen perustuvaa annettavaa nuoremmille aloille. IT-ala kokonaisuudessaan on vielä lapsenkengissään. Haettaessa oppeja rakennusalalta terveydenhuollon IT-järjestelmien kehittämiseen ja hankintaan tulee toki myös pitää mielessä alojen väliset suuret eroavaisuudet. Mutta mielestämme ajattelu ei 18