Terveydenhuoltoa tietojärjestelmille

Alkuperäinen aikomukseni oli päättää Tampereen tietotekniikkamokia käsittelevä blogaussarja idean lähtökohtaan eli terveydenhuollon tietojärjestelmiin. Tulin kuitenkin siihen tulokseen, että Tampereen kaupunkia tai edes Pirkanmaan sairaanhoitopiiriä on turha syyttää valtakunnallisesta kaaoksesta. Kunnat ja sairaanhoitopiirit olisivat toki tälläkin saralla voineet paremmin noudattaa samaisia periaatteita, joita olen sarjan aiemmissa osissa esittänyt ratkaisuiksi ohjelmistohankintojen monenkirjaviin ongelmiin, mutta tällä hetkellä paras teko niiltä olisi painostaa valtiota toteuttamaan rooliaan ohjaajana.

Terveydenhuollossa on tietysti meneillään muitakin, vielä isompia haasteita. Joustamattomat työolot aiheuttavat lääkäripulaa ja hoitajapulaa, perusterveydenhuoltoon on puolihuolimattomasti luotu kolmen tason porrastus ja palvelut pitäisi saada järjestymään sellaisella päätöksenteon tasolla, johon kansalaiset voisivat oikeasti vaikuttaa. Tätä kirjoittaessani näyttää lisäksi pahasti siltä, että ainakaan valtion tasolta uudistuksia ei ole ihan heti odotettavissa. Asioita ei kuitenkaan auta, jos terveydenhuollon tietojärjestelmien pelkkään kehittämiseen palaa 2,7 prosenttia julkisen terveydenhuollon kokonaismenoista ja laskennallisesti 600 lääkärin työpanos kuluu tuijottaessa toimimattomien tietojärjestelmien tiimalasia. Vakavin juttu ovat tietenkin käytettävyysongelmat, jotka vaarantavat potilasturvallisuuden.

Tampereella on toiminut yli kymmenen vuotta potilastietojärjestelmänä Pegasos, jota käyttää myös Helsingin kaupunki. Pirkanmaan sairaanhoitopiirillä kuten myös Helsingin ja Uudenmaan sairaanhoitopiirillä käytössä on puolestaan Uranus. Muita Suomessa käytössä olevia järjestelmiä ovat ainakin Effica sekä vähemmässä määrin Mediatri ja Finstar. Potilasjärjestelmät eivät juttele keskenään, minkä ovat huomanneet myös yhdistymishaluttomat kunnat, ja niiden lisäksi käytössä on tuhansia muitakin järjestelmiä. Yhden hoitotoimenpiteen aikana lääkäri saattaa pahimmillaan joutua kaivamaan tietoa kymmenestä eri järjestelmästä, joihin tiedot myös täytyy syöttää erikseen. Hankinnoissa on tyydytty järjestelmätoimittajien valmiisiin paketteihin ilman, että kokonaisuus on kenenkään hallinnassa.

Kohutussa Apotti-hankkeessa ajatuksena oli yhtenäistää tätä sekamelskaa korvaamalla Helsingin ja Uudenmaan sairaanhoitopiirin alueella vanhoja järjestelmiä uudella ja toimivalla. Hieno ja kannatettava tavoite siis, mutta valitettavasti käytännön valmistelu on ollut kammottavaa jokaisella mahdollisella tavalla. Kauhuskenaariossa tuo avaruussukkulan hintainen hökötys pakotettaisiin HUS-alueen jälkeen käyttöön myös muualle maahan, jolloin koko Suomi olisi sen yhden ainoan monopoliyrityksen eli Accenturen armoilla.

Terveydenhuollon tietojärjestelmissä on kaikesta huolimatta saatu aikaan hyvääkin, kuten sähköinen lääkemääräys, sähköinen potilastiedon arkisto ja potilaiden omien tietojen katselu. Viron tehokkaaseen tapaan hoitaa tietojärjestelmähankinnat onkin kiinnitetty jo laajasti huomiota, mutta myös Savonlinnassa on selvästi tehty jotain oikein. Yhteinen piirre toimiville järjestelmille näyttää olevan, että ne maksavat monin verroin vähemmän kuin vastaavat kuolleena syntyneet projektit.

Mitä tässä tilanteessa siis kannattaisi tehdä? Tähän mennessä tapahtuneen uutisoinnin perusteella kaikille lienee jo selvää, että Apotin kaltainen yhden ainoan massiivimonoliitin tilaaminen kerralla yhdeltä ulkopuoliselta tekijältä voi johtaa vain entistä huonompaan tilanteeseen. Suuren siirtymän sijaan järjestelmiä olisikin syytä yhdistää pikku hiljaa. Aivan aluksi valtion tulisi ottaa tiukka ohjaus asiassa määrittämällä avoimet rajapinnat ja perussäännöt, joita järjestelmiä päivitettäessä vastaisuudessa tulisi noudattaa. Valmiin suljetun koodin paketin sijaan tulisi pyrkiä rakentamaan oma järjestelmä alusta lähtien ja mielellään aloittaen kokeilualueelta, jolloin ongelmien korjaaminen käy vielä helposti. Ratkaisun tulisi olla avointa lähdekoodia, jolloin sen luomisessa voitaisiin käyttää hyväksi joukkoälyä. Tietojenkäsittelytieteen peruskursseilla esimerkkinä toimimattomasta ohjelmistokehityksestä esitellyn vesiputousmallin sijaan järjestelmän rakentaminen tulisi aloittaa pienestä ja laajentaa sitä vähä vähältä jatkuvan palautteen kautta.

Tampereen tietotekniikkamokat, osa 4: Puurekisteri

Tässä sarjassa nostan esiin joitain Tampereella sattuneita tietotekniikkamokia. Tarkoituksena ei ole kuitenkaan erityisesti jumiutua näihin yksittäistapauksiin, vaan käyttää niitä esimerkkeinä miettiäkseni perustavamman tason ongelmia, joiden takia nämäkin ongelmat ovat ylipäätään olleet mahdollisia. Pääajatukseni on, että asiantuntevalla hoidolla tietotekniikasta olisi mahdollista säästää paljon rahaa, jolle löytyisi tarpeellisempaa käyttöä muualla. Neljännessä osassa nostan esiin tapauksen, joka on kaupungin mittakaavassa pieni, mutta huomionarvoinen juuri siksi, että se on niin tavanomainen.

Mitä tapahtui?

Korostan heti alkuun, etten tunne tapauksen taustoja, enkä osaa arvioida hankitun järjestelmän hyvyyttä. Toistan ainoastaan pöytäkirjoista löytyviä lukuja, koska ne havainnollistavat jotain olennaista tietojärjestelmien hankinnasta yleensä. Itse pöytäkirjat haltuuni on toimittanut eräs kaupungin työntekijä. Vaikka kyseessä ovat julkiset asiakirjat, en käytännössä muulla tavoin olisi päässyt tietoihin käsiksi, sillä papereita ei löydy kaupungin nettisivuilta, enkä olisi arvannut mitä pyydellä nähtäville, jos olisin kävellyt kaupunginkansliaan.

Helmikuussa 2008 tietohallintojohtaja Teppo Sulonen teki päätöksen infraomaisuuden hallintajärjestelmän hankinnasta. Järjestelmällä pidetään kirjaa kaupungin omistamista yleisistä alueista, katu- ja liikennevalojen kunnossapidosta, kadunvarsien puista ja venepaikoista. Kilpailutuksen perusteella ”Tampereen kaupunkiympäristön kehittämisen tilaajayksikön, konsernin tietohallintoyksikön, Tampereen kaupungin yhdyskuntatuotannon ja Tampereen Logistiikan henkilöstöstä” koostunut arviointiryhmä totesi, että ”kokonaistaloudellisesti edullisin tarjous” oli yhdyskuntatekniikan ohjelmistoihin erikoistuneen Vianova Systemsin kehittämä Novapoint Iris -järjestelmä. Käyttökustannukset laskettiin seitsemälle vuodelle. Hankintahinta oli 68 500 euroa ja käyttökustannukset noin 24 800 euroa vuodessa.

Seuraavat pöytäkirjat ovatkin sitten melko yksitotista luettavaa. Näissä on kaikissa kyseessä samalta toimittajalta tilattu laajennos tai päivitys Irikseen:

  • 05.06.2009 Laajennustyö 13 650 euroa (alv 0%)
  • 09.06.2009 Selvitystyö järjestelmän kehittämisestä 26 000 euroa (alv 0%)
  • 01.07.2009 Katurekisterin laajennustyö 10 500 euroa (alv 0%) ja vuosittaisen ylläpitomaksun korotus laajennuksen johdosta 1 040 euroa (alv 0 %)
  • 01.07.2009 Puurekisterin laajennustyö 9 450 euroa (alv 0%) ja vuosittaisen ylläpitomaksun korotus laajennuksen johdosta 800 euroa (alv 0 %)
  • 16.10.2009 Yleisten alueiden hallinnan laajennustyö 18 300 euroa (alv 0%)
  • 09.12.2009 Venepaikkarekisterin laajennustyö 10 500 euroa (alv 0%)
  • 09.12.2009 Web-laajennustyö 9 450 euroa (alv 0%)
  • 26.08.2010 Mobiilikäytön pilotti 5 500 euroa (alv 0 %)
  • 23.09.2010 Muutostyö 7 000 euroa (alv 0 %)
  • 30.11.2010 Laajennuksen suorahankinta 52 900 euroa (alv 0 %) ja vuotuinen ylläpitohinta 4 600 euroa
  • 28.03.2011 Laajennuksien hankinta 21 000 euroa (alv 0 %)
  • 11.11.2011 WFS-rajapinta 9 000 euroa (alv 0 %)
  • 12.4.2012 Versiopäivitys 24 000 euroa (alv 0 %)

Esittelijöiden ja tietohallintopäällikön virkaa toimittavien nimet vaihtelevat jonkin verran, mutta kaava on kaikissa sama. Päättäjäksi on merkitty yksi ainoa henkilö. Muutostöiden hinnaksi esitetään enintään tähän listaamani summa, jonka päälle tulevat matkakustannusten korvaukset. Jos oletetaan, että ylläpitomaksujen korotukset ovat käytännössä astuneet voimaan päätöstä seuranneen vuoden alusta, olisi järjestelmä tähän mennessä maksanut kaupungille 419 870 euroa. Tämä on yli tuplasti siihen nähden, mikä näille viidelle vuodelle laskettu kustannus olisi tarjouksen perusteella ollut.

Miksi tämä on moka?

Ainakin päälle päin tapaus vaikuttaa oppikirjaesimerkiltä niin kutsutusta vendor lock-in -tilanteesta eli yhden toimittajan loukosta. Nostan päämokaksi kuitenkin hiukan perustavamman ongelman, joka papereista varmasti nousee esiin. Olen aikaisemminkin käsitellyt sitä, miksi tietotekniikan eriyttäminen sillä tehtävistä toiminnoista on huono idea. Näidenkin kyseessä olevien päätösten takana on tietotekniikasta vastaava tilaaja eli Tietohallintoyksikkö. Yksikkö koostuu hallintoalan eikä tietotekniikan osaajista. Tavallisesti suuret hankinnat täytyy hyväksyttää valtuustolla, missä on se hyvä puoli, että valtuustolistat yleensä silmäilee läpi ainakin joku kiireinen toimittaja ja muutama kansalaisaktivisti, toivon mukaan myös osa valtuustosta. Tietohallinto pystyy kuitenkin päättämään jopa satojentuhansien hankkeista virkamiespäätöksinä, jotka tulevat julkisuuteen yleensä vain puolivahingossa tämänkaltaisia kummallisia reittejä pitkin. Koska alaa oikeasti tuntevat henkilöt eivät pääse kuulemaan päätöksistä ja siten kantamaan korttaan kekoon arvioinnissa, hämärien sisäpiirikauppojen tekeminen muuttuu turhan houkuttelevaksi, ja toisaalta myös hyvin toteutetut hankinnat vaikuttavat helposti epäilyttäviltä, koska ne on tehty puolittain pimennossa.

Miten moka voitaisiin välttää tulevaisuudessa?

  • Vähänkään monimutkaisempien tietojärjestelmien kehittäminen ja räätälöinti on pitkäjänteistä työtä, eikä oikeastaan ole olemassa pistettä, jolloin kaikki olisi valmista. Tietojärjestelmää ei olekaan mielekästä ajatella hankintana samassa mielessä kuin vaikkapa työkoneen hankintaa, vaan pikemminkin jatkuvana sijoituskohteena siinä kuin itse organisaatiota, johon se kuuluu.
  • Niin luottamuselinten päätösten kuin viranomaispäätösten tulisi olla helposti saatavilla kaupungin nettisivuilta. Päätöksiä tulisi voida hakea sanahaulla leipätekstiin ja päättäjien nimillä. Vanhojen asiakirjojen skannaus tulisi aloittaa välittömästi, ja digitointiprosessin ollessa vielä kesken pitäisi papereita voida helposti pyytää nähtäville.
  • Kilpailutukset tulisi hoitaa tavalla, jossa ei jouduta sidoksiin yhden ainoan toimittajan kanssa. Tietojärjestelmien osalta tämä tarkoittaa avoimien rajapintojen vaatimista ja avoimen lähdekoodin ratkaisujen suosimista. Ylläpito ja päivitysten teko pitäisi olla aina mahdollista toteuttaa kaupungin omana toimintana, vaikkei tähän käytännössä tarvitsisikaan mennä. Nykyisellään kunnat kannustavat softafirmoja tekemään hankintahinnaltaan vaikka tappiollisia mutta samalla mahdollisimman huonosti toimivia järjestelmiä, joihin joudutaan tekemään mahdollisimman paljon korjauksia.

Näin tavallisena kuntalaisena ihmettelen, mikseivät kunnat voisi toimia enemmän kuten tavallisen järkevä yksittäinen kuluttaja. Jos tarvitsen auton, ostan halvimman tarpeisiini riittävän enkä Porschea. Jos kuitenkin haluan Porschen, en osta Ladaa ja maksa kauppiaalle sen muuttamisesta Porscheksi. Jos ostamani televisio on valmiiksi rikki, palautan sen kauppaan. Jos kauppias yrittää rahojeni palauttamisen sijaan nyhtää minulta lisää rahaa telkkarin korjaamisesta, otan yhteyttä kuluttaja-asiamieheen.

Tampereen tietotekniikkamokat, osa 1: Bussiaikataulunäytöt

Viimeisten viikkojen ajan on kohistu Helsingin ja Uudenmaan sairaanhoitopiirin potilastietojärjestelmän kilpailutuksesta, tai oikeammin sellaisen täydellisestä puutteesta. Vastaavia tapauksia putkahtelee julkisuuteen säännöllisin väliajoin. Julkissektori vaikuttaa olevan poikkeuksellisen lahjakas upottamaan IT-hankintoihin suunnattomia summia ilman, että veronmaksajat samalla saisivat edes jonkinlaista vastinetta rahoilleen. Päätinkin aloittaa sarjan blogauksia, jossa nostan esiin joitain Tampereella sattuneita tietotekniikkamokia. Tarkoituksena ei ole kuitenkaan erityisesti jumiutua näihin yksittäistapauksiin, vaan käyttää niitä esimerkkeinä miettiäkseni perustavamman tason ongelmia, joiden takia nämäkin ongelmat ovat ylipäätään olleet mahdollisia. Pääajatukseni on, että asiantuntevalla hoidolla tietotekniikasta olisi mahdollista säästää paljon rahaa, jolle löytyisi tarpeellisempaa käyttöä muualla. Ensimmäisessä osassa käsittelen asiaa, joka on näkynyt useimpia tietotekniikkaongelmia selkeämmin tavallisille kaupunkilaisille, mutta josta siitä huolimatta on puhuttu vähän: bussien tulosta kertovia aikataulunäyttöjä pysäkeillä.

Mitä tapahtui?

Bussien seurantajärjestelmää on yritetty rakentaa Tampereella vuosikausia. Pöytäkirjoja päätöksenteosta on kaupungin sivuilla nähtävillä vain vuodesta 2010 asti (ei siis edes koko kuluvaa valtuustokautta), joten seuraava perustuu Tampereen joukkoliikenteen vuosikertomuksiin, Kansalaiskioski-palvelun vastauksiin, Liikenne- ja viestintäministeriön joukkoliikennehankeraportteihin sekä kuulopuheisiin. Jos huomaat virheitä, kerrothan asiasta, jotta voin korjata ne.

Suunnittelu aloitettiin ensimmäisen kerran vuonna 1997. Tarjouspyyntöjen pyytelyyn päästiin lokakuussa 1999 ja sopimus tamperelaisen Insta Visual Solutionsin kanssa tehtiin kesäkuussa 2000, joskin mukana oli ilmeisesti myös keskieurooppalainen alihankkija. Pilottivaiheessa järjestelmään oli tarkoitus liittää muiden asioiden ohella 20 pysäkkinäyttöä ja lopullisena tavoitteena oli 200 näyttöä. Lopulliseksi hinnaksi kaavailtiin 5–6 miljoonaa euroa. Koekäytön oli tarkoitus alkaa 2002, mutta hanke viivästyi vuodella. Aikatauluja oli tarkoitus saada myös puhelimeen, mutta toimittajaksi valittu Port Able Media Platforms lopetti toimintansa ennen valmistumista, eikä kaupunki ollut vaatinut jatkuvaa dokumentaatiota, jotta joku toinen olisi voinut jatkaa työtä.

PARAS-informaatiojärjestelmään liittyviä näyttöjä ilmestyi katukuvaan vuosina 2006 ja 2007. Näytöt olivat jatkuvasti epäkunnossa. Vuoden 2006 aikana kaupunki ryhtyi toteuttamaan järjestelmää hyödyntäviä joukkoliikenteen liikennevaloetuuksia. Aikatauluinformaatiojärjestelmien käyttäjämäärät jatkoivat kasvuaan ja palvelut olivat kysyttyjä. 2009 järjestelmän tuki lakkasi kokonaan.

Yhdyskuntalautakunta päätyi marraskuussa 2009 sopimukseen Logican kanssa. Lissu Liikenteenseuranta julkistettiin seuraavana vuonna osana IJ-2010-järjestelmää. Vanhat näytöt poistettiin kokonaan ja uudet asennettiin kesäkuussa 2011, joskin vain muutamille paikoille. Kaupunki osti laitteet busseihin, pysäkeille ja risteyksiin, mutta itse järjestelmä, tiedonsiirto, paikannus ja ylläpito ostetaan palveluna. Ylen mukaan hinnaksi uudelle järjestelmälle tuli reilut miljoona euroa, mutta jutusta ei selviä, mitä summaan sisältyy.

Miksi tämä on moka?

Matkan varrella on tapahtunut useampiakin virhesiirtoja, joista kannattaa ottaa opiksi, mutta ylivoimaisesti ratkaisevin niistä ei johtunut ainoastaan huolimattomuudesta tai asian uutuudesta. Tampereen kaupunki osti toimittajalta sekä infran että softan, siis sekä fyysiset näyttölaitteet että ohjelman, joka niissä pyörii. Näyttöpäätteet siirtyivät kaupungin omaisuudeksi, mutta varsinainen sisältö jäi sen toimittaneen yrityksen omaisuudeksi ja oli siis kaupungilla ainoastaan vuokralla. Sopimuksen umpeuduttua näytöt lakkasivat kerta kaikkiaan toimimasta, ja bussinodottelijat saattoivat vain ihmetellä mustia ruutuja, jotka olivat toimineet käytännössä vain kolme vuotta. Vuoden tauon jälkeen kaupunki osti uudet näytöt. Viime kerrasta ei ilmeisesti otettu opiksi, sillä sopimus toimittajan kanssa on täysin vastaava kuin edellinenkin. Julkisuudessa vaihtoa on selitetty tekniikan vanhentumisella, minkä vaikutusta en sinällään aio tässä vähätellä, vaikka kehittämisen mahdottomuus tosin sekin kertoo huonosta suunnittelusta.

Miten moka voitaisiin välttää tulevaisuudessa?

  • Julkisten varoin tuotettujen materiaalien tulisi aina siirtyä julkiseksi omaisuudeksi, mikä ei estä alkuperäistä kehittäjääkään hyödyntämästä työtään tulevissa ratkaisuissaan. Toisin sanoen kaupungin tulee ostaa mieluummin itse järjestelmiä kuin ylihintaisia lisenssejä niihin. Parhaimmillaan esimerkiksi Turun kaupunki ottaisi käyttöön saman järjestelmän ja tekisi siihen parannuksia, joista myös Tampere hyötyisi.
  • Tietojärjestelmähankinnoissa tulisi suosia avointa lähdekoodia ja vaatia avoimia rajapintoja sekä kunnollista dokumentaatiota pitkin matkaa, jottei vapaiden markkinoiden sijaan päädytä yhden toimittajan armoille. Jos pienetkin muutokset pystyy hoitamaan ainoastaan yksi taho, tämä voi pyytää aivan niin korkeaa hintaa kuin ilkeää. Rajapinnat mahdollistaisivat myös sen, että järjestelmän voisi hankkia oikeasti toteuttamiskelpoisen suuruisina osina ja mahdollisesti eri toimittajilta.
  • Kaupungin toimintaa tulee suunnitella pitkäjänteisesti eikä vuosi kerrallaan. Kilpailutuksessa tämä tarkoittaa, että hintoja vertaillessa tulisi huomioida tuotteen tai palvelun koko elinkaari, ei ainoastaan hankintahintaa.
  • Yksi ongelma on jo korjattu. Aikaisempi hankintalaki esti kuntia ottamasta tarjouskilpailussa huomioon aikaisempia kokemuksia samoista toimittajista. Hyvänä tarkoituksena oli estää kauppojen valuminen aina samoille luotettaviksi havaituille yrityksille, mutta käytännössä laki pakotti myös jättämään huomiotta tarjoajan kyvyttömyyden pitää kiinni aikaisemmistakaan lupauksistaan. Syyskuun alussa voimaan tullut uusi laki ei tietenkään edelleenkään takaa sitä, että hankintojen suunnitteluun osallistuisivat kaupungilla työskentelevät käytännön asiantuntijat tilattavaa tekniikkaa ymmärtämättömien hallintoviranomaisten (saati kilpailutuksiin osallistuvien firmojen) sijaan. Se korjaa kuitenkin tämän yhden ongelman. Logicoilta ja Accentureilta ei ole vastedes pakko ostaa sutta ja sekundaa, paitsi tietysti jos ne osoittavat kohentaneensa toimintaansa edellisistä näytöistään. Ohjelmistofirmoja on turha syyttää, jos ne toimivat aivan kuten julkissektori tilaajana niitä kannustaa toimimaan.

Näin matkustajan näkökulmasta täytyy sanoa, että uudet hienot näytöt ovat toimineet paremmin kuin Logican tuotteet tavallisesti, vaikka käyttöliittymä mahdollistaakin lukuisia väärintulkintoja. Otan mieluummin hiukan keskeneräisiä palveluita käyttöön kuin odottelen vuosikymmenen IT-järjestelmää, jota ei koskaan tule.