Mitä lääkkeeksi eReseptille?

Perjantaina nousi pieni haloo siitä, kuinka sähköiseen reseptiin mahtuu vain 50 merkin pituinen selitys käyttötarkoituksesta.

“Ongelman korjaaminen tulee kalliiksi ja vie aikaa, kertoo projektipäällikkö Riitta Konttinen THL:stä.

– Siinä menee noin puolitoista vuotta. Kärsivällisyyttä tarvitaan ennen kun uudistus saadaan käyttäjälle. Muutosten tekeminen ei ole myöskään halpaa.”

Onhan se tietenkin vähän omituista, että puolen päivän työltä kuulostava muutos vie puolitoista vuotta. Mutta todellisuus on joskus omituisempi kuin mitä uskoisi. Tämä ei nimittäin ole suinkaan ensimmäinen omituisuus sähköisen reseptin historiassa.

Valtiontalouden tarkastusviraston surullisenkuuluisa raportti Sosiaali- ja terveysalan IT-hankkeista käsittelee sähköistä reseptiäkin:

  • Hanke on eri muodoissaan elänyt 80-luvulta asti, myöhästyen toistuvasti. Suurin syy myöhästymisiin on ollut kiire.
  • Vuonna 2002 eReseptiä oli tarkoitus pilotoida 2003. Pilotti viivästyi vuoteen 2005.
  • Vuonna 2007 KanTa-palvelut (joista eResepti on ensimmäinen osa) oli tarkoitus toteuttaa noin vuodessa. Tämänhetkisen aikataulun mukaan resepti on käytössä julkisella sektorilla tänä vuonna ja yksityisellä 2015 mennessä. Muut KanTa-palvelut tulevat myöhemmin.
  • Alkuperäinen kustannusarvio oli 20 miljoonaa, nyt eReseptin kokonaiskustannuksiksi arvioidaan 70 miljoonaa.
  • Sekä aikataulut että kustannusarviot ovat olleet vaihtelevia. VTV:n sanoin: “Sosiaali- ja terveysministeriöllä ei ole ollut selkeä ja realistista näkemystä KanTa-hankkeen kokonaisaikataulusta. Eri toimijoille esiteyt aikataulut ovat siirtyneet toistuvasti, mikä on johtanut terveydenhuiollon toimijoiden epäluottamukseen minsteriön ohjeistusta kohtaan.”

50 merkin raja ei sinänsä ole kauhean merkittävä ongelma. Itse asiassa voi olla, ettei se ole ongelma ollenkaan. Käyttötavan kohdalle kun voi kirjoittaa myös “erillisen ohjeen mukaan”. En ole oikea ihminen arvioimaan, paljonko tilaa tarvitaan. Jos kuitenkin katsotaan projektipäällikkö Konttisen tavoin, että 50 merkkiä on liian vähän, niin tässä on kaksi vähän merkittävämpää ongelmaa:

  1. Miksi tätä ei havaittu aiemmin, ja
  2. Miten korjaus voi kestää puolitoista vuotta (ja maksaa paljon).

No, miksi tätä ei havaittu aiemmin?

Ensimmäinen kysymys voidaan esittää oikeastaan kaikille IT-hankkeille. Sellaista projektia ei nimittäin olekaan, jossa kaikki olisi keksitty etukäteen. IT-hankkeet ovat luonteeltaan ennen kaikkea oppimisprojekteja, joissa opitaan ymmärtämään, mitä hankkeessa oikeastaan pitääkään tehdä. Sivutuotteena sitten syntyy softa.

Vaikka ennakkomäärittelyissä olisi ollut mukana kuinka monta lääkäriä, apteekkaria ja potilasta, on silti selvää, että kunhan järjestelmä saadaan käyttöön, tulee esiin tarpeita joita ei ennalta ajateltu. Se on ihan normaalia.

Ketterissä menetelmissä tämä tosiasia pyritään tunnustamaan, ja tuottamaan loppukäyttäjille toimiva järjestelmä mahdollisimman usein, ideaalisti kahden viikon välein. Kun lääkärit pääsevät kokeilemaan järjestelmää pian, selkiytyvät tulevat tarpeetkin nopeammin. Vuoden 2002 jälkeen eReseptiä olisi ehditty demota 250 kertaa. Niissä olisi varmasti löytynyt muutamakin virhe ja kehitysidea.

Sähköisen reseptin kehitysjakso ei kuitenkaan ole kaksi viikkoa, vaan ilmeisesti kaksi vuotta. Jos ja kun nyt huomataan pieni puute, sen saaminen korjatuksi vie 18 kuukautta. Potilasturvallisuuden takia tarvitaan tietysti aika paljon parempi testaus kuin jossain webikaupassa. Ja kokonaisuudessa on toki monia toimittajia. Mutta vähintäänkin kolmen kuukauden kehitysjaksojen pitäisi olla hajautetussa monitoimittajaympäristössäkin aivan realistista.

Tämä ei kuitenkaan vastaa itse kysymykseen:

Miten tämä voi olla näin?

Politiikan kommentaattori Veikko Eranti kertoo fiktion keinoin, miten tämä lapsus olisi voinut tapahtua. “Koko sektorin liiketoimintamalli nimittäin perustui sekundan myymiseen ymmärtämättömille keiloille, ”huipputeknologian” kauppaamiseen pohjimmiltaan kirjoituskoneajassa eläville ihmisille, joiden sihteerit hoitivat heidän sähköpostinsa.”

Kuten yleensäkin, todellisuus on tietenkin hiukan monimutkaisempi. Viidenkymmenen merkin raja ei ole syntynyt yhdessä palaverissa, eikä kyse ole vain yhdestä järjestelmästä.

eResepti koostuu Reseptikeskuksesta ja sitä käyttävistä potilastietojärjestelmistä sekä apteekkijärjestelmistä. Suomessa on yli 300 kuntaa, 20 sairaanhoitopiiriä, 4000 yksityisen terveydenhuollon toimijaa ja 800 apteekkia. Jokaisella näistä on oma järjestelmä ja jokaisella niistä toimittava yritys. Kyse on siis tuhansista asiakkaista ja kymmenistä softantoimittajista.

Eri osapuolien kommunikaatio perustuu XML-muotoisiin CDA R2-sanomiin, jotka määritellään HL7-standardeissa. Kaikille eri kentille annetaan kiinteät pituudet, ja käyttötarkoituksen pituus sattuu olemaan 50 merkkiä. Alle 12-vuotiaan painolle on muuten 5 merkkiä, joten parasta olla tekemättä satakiloisia lapsia.

XML sinänsä ei tekstimuotoisena formaattina vaadi kentille pituusrajoja. Itse asiassa olisi helpompaa tehdä sanomajärjestelmä, jossa ei rajoja ole. Mutta sitten kaikkia eri järjestelmiä päivittävät softatalot eivät tietäisi etukäteen, täsmälleen minkä mittaisilla teksteillä eResepti pitäisi testata. Nykyaikaiset systeemit toki selviäisivät helposti pitkistäkin teksteistä, mutta kaikki järjestelmät eivät ole nykyaikaisia.

Jossain on siis olemassa apteekkitietojärjestelmä, joka kykenee vain tähän määrään. Monet kykenevät enempään. Nyt luotiin uusi kansallinen järjestelmä rajoittaen sen toimintaa heikoimman vanhan järjestelmän speksein.

Mitä vähemmän edistystä, sitä enemmän rahoitusta

Suomessa, toisin kuin vaikka Tanskassa, ei ole mitään kansallista tahoa, joka ohjaisi terveydenhuollon järjestelmien kehitystä yhteentoimivaan – tai ylipäänsä toimivaan – suuntaan. Sen sijaan jokainen taho tekee asiat omalla tavallaan, ja ainakin eReseptiä kehitettiin vahvasti konsensusperiaatteella, eli ratkaisujen tuli sopia kaikille. Ja VTV:n sanoin:

“Hankkeen toteuttamisen etenemiselle ei ole riittävää ponninta, koska jatkuva rahoitus on omiaan edistämään eri osapuolten jatkorahoituksen saamista omalle henkilöstölleen.”

Eli suomeksi: Mitä vähemmän edistystä, sen enemmän rahoitusta. Ihmekös tuo jos kestää. Ei ole tietenkään projektin toimittajan vastuulla ajatella asiakkaan etua. Se on asiakkaan vastuulla. Pitäisi osata ostaa IT-järjestelmiä.

Ei ole normaalitila tai business as usual, että hankkeet myöhästyvät kymmenen vuotta tai budjetti kolminkertaistuu. Se kertoo siitä, että asiat ovat vakavasti pielessä. Ulkopuolisen on mahdotonta sanoa, tarkalleen mihin aika ja rahat ovat menneet. Niillä tuskin on lennelty Bahamalle, vaan hyvä arvaus on, että ne ovat menneet vääriin toimintatapoihin. Esimerkiksi siihen, että yritetään pakottaa kaikki toimijat käyttämään samoja protokollaversioita.

Ydinviestissään Eranti on siis täysin oikeassa: ongelmana on, että tilaajan puolella pöytää ei ole riittävää osaamista hankkia IT-järjestelmiä. Valtiontalouden tarkastusvirasto päätyi aivan samaan johtopäätökseen: “Kokonaisuudessaan arvioiden Sosiaali- ja terveysministeriöllä ei ole ollut osaamista eikä edellytyksiä johtaa KanTa-hanketta eikä sitä edeltänyttä sähköistä potilaskertomushanketta osana kansallista terveyshanketta.”

Lääkkeet terveydenhuollon IT:lle

No, mitä lääkettä terveydenhuollon IT:lle sitten pitäisi määrätä? Tässä kolme ideaa:

  1. Pitää perustaa Tanskan Medcomia vastaava organisaatio THL:n tai Sosiaali- ja terveysministeriön yhteyteen vastaamaan terveys-IT:n kokonaisarkkitehtuurista.
  2. Järjestelmät pitää päivittää vähintään neljä kertaa vuodessa. Kaikki sellaiset ohjelmistot ja toimintatavat, jotka tekevät tiheästä julkaisusta ongelmallisia, pitää korjata.
  3. Jokaiseen IT-hankkeeseen pitää palkata yksi ihminen, joka ymmärtää mitä siinä ollaan tekemässä. Kokemukseni mukaan se parantaa merkittävästi hankkeen onnistumismahdollisuuksia.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Miten gaussin käyrä liittyy teknologiastrategiaan?

Fyysisten laitteiden maailmassa on ilmeistä tarvitaanko F1-kilpuria vai ihan vaan tämän vuoden vuosimallia olevaa perheautoa, mutta ohjelmistopuolella tilanne ei ole ollenkaan niin suoraviivainen.

Tilanteesta riippuen sekä konservatiiviselle Java-sovellukselle että uusimpia tekniikoita käyttävälle HTML 5 -sivustolle on paikkansa. Mutta milloin on minkäkin tekniikan aika? Kuka tarvitsee uusimpia työkaluja?

Kirjoitan aiheesta, sillä uusien asiakkaiden kanssa käyn toistuvasti samoja keskusteluja työkaluista. Onko yhtä selvää Tekniikan Maailman testivoittajaa vai onko sittenkin niin, että työkaluvalinta on tapauskohtaista?

Tarvitsetko uusinta uutta?

Uusimpien työkalujen ja jo käytössä koeteltujen ohjelmointikielien käyttäjien on usein vaikeaa ymmärtää toisiaan. Kumpikin on tottunut omaan katsantokantaansa ja toisen näkökulma tuntuu vieraalta. Mistä valinnassa oikein on kyse? Onko toinen koulukunta ihan väärässä? Sama konflikti on jatkunut jo pitkään, eikä vieläkään ole löydetty yhteisymmärrystä siitä, millä työkaluilla softaa kannattaisi tehdä.

Uusien ideoiden omaksuminen

Alkuperäisen tutkimustuloksen löysi vuonna 1948 maanviljelijä kuvan oikeassa laidassa, viimeisten farmareiden löytäessä idean kahdeksan vuotta myöhemmin.
Alkuperäisen tutkimustuloksen löysi vuonna 1948 maanviljelijä kuvan oikeassa laidassa, viimeisten farmareiden löytäessä idean kahdeksan vuotta myöhemmin.

Tässäkin tilanteessa on kyse on uusien ideoiden omaksumisen lainalaisuuksista. Aiheen popularisoi riskisijoittaja Geoffrey Moore kirjassaan Crossing the Chasm vuodelta 1991. Uudet ideat eivät nouse kerralla kaikkien tietoisuuteen vaan valuvat ensimmäisten käyttäjien kautta hiljalleen kaiken kansan hyödyksi.

Uutena mainostettu malli on paljon vanhempi ja yleispätevämpi kuin voisi kuvitella. Uuden teknologian omaksumista tutkittiin vuonna 1957 Yhdysvaltain keskilännessä helppolukuisessa ja yllättävän kiinnostavassa Adopters of New Farm Ideas -julkaisussa.  Omaksumisen nähtiin noudattavan gaussin käyrää.

Alussa tekniikan ottavat käyttöön vain harvat, heitä seuraa vähän suurempi joukko ja vasta sitten valtavirta. Uusien siemenlajien ja uusien ohjelmointikielien välillä on enemmän yhteistä kuin ensi hätään luulisi. Tarkemmin ajateluna ei ole ihme, että moni suuryrityksen johtaja on vapaa-ajallaan myös menestynyt kartanonherra.

Innovaattorit

Niin maataloudessa kuin ohjelmistotekniikankin alalla innovaattorit näkevät uuden teknologian mahdollisuudet ja ovat valmiit muuttamaan yrityksessään paljonkin saadaakseen uusimman uuden käyttöön. Innovaattorit vievät uudet keksinnöt nopeasti tuotantoon ja käyttävät osin keskeneräisiäkin työkaluja hyötyäkseen keksinnöistä. He ovat uuden teknologian kannalta tärkeitä niin maanviljelyksessä kuin tietotekniikassakin.

Mallin mukaan innovaattoreita on vain noin kaksi prosenttia väestöstä. He kuluttavat keskimääräistä enemmän aikaa ideoiden etsimiseen ja kokeiluun, mutta toisaalta saavuttavat näin kilpailuetua. Suomalaisessa maataloudessa innovaattorit ovat kasvattaneet monia kannattavia suurtiloja rohkeiden kokeilujensa kautta.

Valtavirta

Valtavirtaan kuuluvilla ei ole mahdollisuutta omaksua keskeneräistä uutta teknologiaa. Kyse on yhtä lailla asenteesta sekä priorisoinnista. Uutta otetaan käyttöön siinä vaiheessa, kun sen käyttö on kilpailijoiden toimesta jo hyvin todistettu.  Tekniikkaa ei oteta käyttöön ennen kuin sen rajat tunnetaan hyvin ja se sopii olemassa olevaan rakenteeseen. Tuolloin tekniikan käyttöönotto koetaan helpoksi ja vaarattomaksi, sillä hyödyt ovat ilmeisiä ja vähällä vaivalla saavutettavissa.

Miten gaussin käyrä liittyy teknologiastrategiaan?

Omaksuminen on kategorisoitu sekä alkuperäisessä maanviljelystutkimuksessa että Geoffrey Mooren julkaisussa suoraan tilastollisen keskihajonnan eli sigman mukaan.
Omaksuminen on kategorisoitu sekä alkuperäisessä maanviljelystutkimuksessa että Geoffrey Mooren julkaisussa suoraan tilastollisen keskihajonnan eli sigman mukaan.

Innovaattorit ovat pääsääntöisesti ratkaisemassa ongelmia, joita aiemmalla tekniikalla ei voitu ratkaista. He löytävät markkinarakoja, joiden täyttäminen tuo nopeaa ja kannattavaa kasvua. Innovaattorit valitsevat uusimpia työkaluja saadakseen ideansa kilpailijoita nopeammin valmiiksi. Esimerkiksi pilvipalvelujen ja uusien ohjelmointikielien avulla etsitään voittavaa asemaa markkinoilta.

Valtavirrassa uivalla yrityksellä on turvallinen markkinaosuus ja tutut asiakkaat, joille tarjota ratkaisuja tunnettuihin ongelmiin. Valtavirran rooli on ylläpitää innovaattorien ja muiden propellipäiden aikanaan kehittämiä systeemejä. Tämä on tehnyt heistä varovaisia. Valtavirrassa toimivalle ylläpidettävyys, tuttuus ja virheettömyys ovat arvossaan.

Ohjelmistoalalla tarpeet vaihtelevat suuresti. Harva työkalu sopii sekä perheauton että F1:n luomiseen. Turvallista taloushallinnon järjestelmää tutuille asiakkaille tehdään edelleen pääsääntöisesti Javalla. Se ei ole työkaluista ketterin eikä seksikkäin, mutta osaamista löytyy kaikkiin toiminnan osiin. F1:stä, eli uusinta uutta, tehdään harvoin Javalla. Osaavissa käsissä ohjelmistokielistä Python, Ruby, Scala tai Javascript tuottaa nopeammin tuloksia. Uusimman uuden tekijätiimi joutuu tosin ajoittain etsimään tekijöitä kissojen ja koirien kanssa, kun valitun alustan osaajia ei löydykään helposti.

Työkaluvalintojen arvostelussa saa olla kieli keskellä suuta. Kun ohjelmistoa tehdään mahdollisimman nopeasti, tarvitaan erilaiset työkalut kuin silloin, kun jokainen koodirivi jää elämään omaa elämäänsä vuosiksi tai vuosikymmeniksi.