Terveydenhuolto

by

Espoo Open Space eli ketteryyttä terveydenhuoltoon

Eilen Dipolissa pidettiin Ketterät terveydenhuollon tietojärjestelmät Espoossa -seminaari. Järjestäjinä toimivat Espoon vihreät valtuutetut, eli minä ja Jyrki Kasvi, Agile Finland sekä Houston, Inc.

Tilaisuuden pihvi oli osallistujien vuorovaikutus: ryhmätyöskentely, jolle oli varattu hyvin aikaa. Seminaarista jäikin parhaiten mieleen innostunut, syvällinen ja kattava keskustelu, jota oli todella harmi keskeyttää seminaarin loppusanoja varten. Onneksi keskustelu varmasti jatkuu muilla kanavilla. Keskustelusta teemme vielä tiivistelmän, joka laitetaan jakoon.

Kuinka se syntyi?

Kävin alkuvuodesta oman työnantajani Siilin kirjahyllyä läpi ja kollegani suositteli sieltä löytyvää Houston, Incin Vesa Teikarin kirjasta Ketterän kehittämisen ostajan opas. Luin kirjan kahdella bussimatkalla ja innostuin: yleistajuinen, tiivis ja kuitenkin kattava paketti ketterän kehityksen ja ennen kaikkea sen ostamisen perusperiaatteista. Yleensä ketterän kehityksen oppaat on suunnattu tekijöille – ostajat kulkevat sokkona. Vaikka kirjanen ei ollutkaan erityisesti suunnattu julkishallinnolle eikä siinä siis käsitelty vaikkapa hankintalain sudenkuoppia, soitin Houstonille ja kysyin itselleni ilmaiskappaleita jaettavaksi Espoossa. Tapasimme Teikarin kanssa lounaalla ja sain kaksi kassillista kirjasia, jotka vein ICT-johtaja Matti Franckille sekä peruspalvelujohtaja Juha Metsolle luettavaksi ja jaettavaksi organisaation sisällä.

Tuolla alkuperäisellä lounaalla puhuimme pitkään Espoosta, terveydenhuollosta ja ketterästä kehityksestä ja Teikari heitti ilmaan idean nimenomaan Espoolle suunnatusta ketterän kehittämisen seminaarista. Kun ideaa myöhemmin jalostettiin ja lähdimme toteuttamaan tilaisuutta, Houston ja Agile Finland ottivat hoitaakseen tilaisuuden organisoinnin ja minä ja Jyrki vieraslistan ja kutsut. Haluaisinkin vielä tässä erikseen kiittää niin Vesa Teikaria, Antti Kirjavaista kuin muitakin fasilitaattoreita ja puhujia tilaisuuden mahdollistamisesta. Erityinen kiitos myös Matti Franckille, jonka kalenterista löytyi tilaa osallistua sekä Juha Metsolle, joka antoi tärkeää evästystä tilaisuuden valmisteluun vaikkei valitettavasti ehtinytkään itse paikalle. Samoin kaikille osanottajille, niin virkamiehille, luottamushenkilöille kuin asiantuntijoillekin, jotka tekivät tilaisuuden.

Mitä siellä tapahtui?

Tilaisuuden aluksi Jyrki Kasvi sekä Espoon ICT-johtaja Matti Franck puhuivat terveydenhuollon tietojärjestelmien haasteista yleisesti sekä Espoon tilanteesta erityisesti. Yleisöä huvitti Franckin heitto ”teitä varmaankin mietityttää, mitä Espoo oikeastaan tekee ketterien järjestelmien tilaisuudessa?” Tätä puitiinkin sitten sekä Franckin jatkossa että tilaisuudessa myöhemminkin. Yleisö otettiin mukaan heti alustuksen jälkeen, kun kaikki saivat pohtia, mikä olisi omassa roolissa tärkein kysymys ratkottavaksi.

Antti Kirjavainen sekä Marko Taipale alustivat ketteristä menetelmistä sekä niiden ostamisprosessista, jonka jälkeen case-esimerkkinä Maanmittauslaitoksen kehittämiskeskuksesta johtava asiantuntija ja hankepäällikkö Jorma Turunen kertoi kokemuksia ketterästä kehittämisestä. Puhe oli suoraa ja hankintalaki taisi jo hetkeksi lentää roskiin – positiivisena esimerkkinä Turunen kuitenkin mainitsi neuvottelumenettelyn.

Pohjustusten jälkeen erillisessä Open Space-osuudessa käytiin konkreettisemmin pienryhmissä osallistujien kanssa läpi tilaisuuden aluksi esitettyjä kysymyksiä: Espoon sosiaali- ja terveyspuolen haasteita ja niiden ratkaisuja. Sessioita oli kaksi, joissa oli kolme ryhmää eri teemojen ympärillä: ensimmäisessä sessiossa ajatuksena oli purkaa asioita auki yleisemmällä tasolla, purkaa keskustelut ja sen jälkeen käydä kustakin aihepiiristä läpi konkreettisia ensiaskeleita ja ratkaisuja.

Sessio 1: Keskustelua, ideoita ja konkretiaa

Istuin ensimmäisessä sessiossa asiakas-ryhmässä, jossa mietittiin tuotteen käyttäjiä eli lääkäreitä, hoitohenkilökuntaa ja myös meitä palvelujen käyttäjiä. Apotti-hankkeen edustaja kertoi, että heillä käyttäjiä on pyritty kuuntelemaan menetelmällä, jossa käyttäjäryhmät pohtivat käytettävyyttä myös muiden näkökulmasta. Tämän avulla ristiriitoja voidaan välttää ja ihmiset ymmärtävät paremmin myös muiden vaatimuksia. Pohdimme paljon myös IT:n klassista ongelmaa eli sitä, että lähdetään tekemään it-järjestelmää miettimättä, miten se oikeasti parantaisi toimintaa. Espoon Sote-puolen virkamies puolestaan muistutti, että me emme voi miettiä pelkästään itse hoitoprosesseja vaan järjestelmän tulee tukea myös johtamista. Lonkkaliukumäki – joka toimii tällä hetkellä puhtaasti paperilapuilla – osoittaa että prosesseja on itse asiassa paras tyypatakin ensin muuten kuin tekemällä mallinnusta suoraan softaan tai hienoilla kaavioilla. Jo fyysisesti pöydän ääressä prosessia kokeilemalla usein löydetään toimivampia ratkaisuja.

Samaan aikaan muissa ryhmissä puhuttiin IT:n hankinnasta ja erityisesti ketterän hankinnan ongelmista. Miten ketterää voi oikeasti ostaa? Tässä ryhmässä oli pohdittu muun muassa vaihtoehtoa, jossa pitkäkestoisemmassa sopimuksessa olisi jatkuva katkaisukohta, esimerkiksi kuukauden tai parin välein, jolloin toimittajan kyky evaluoitaisiin. Emme olleet päästä purkamaan kaikkia ryhmiäkään, koska kysymys herätti niin kiivasta keskustelua: erityisesti puhutti kysymys siitä, millaisilla kriteereillä sopimuksen voisi purkaa jos tällaisen sopimuksen haluaisi tehdä.

Sessio 2: Hankintaa, osaamista ja hankintaosaamista

Toiseen sessioon vaihdoin ryhmää ja menin keskustelemaan julkisen hankinnan sudenkuopista. Edellisestä sessiosta oli jäänyt kummittelemaan yksi iso kysymys: miten hankintaosaamista voisi vahvistaa kuntapuolella? Kuntien Tiera pyrkii ratkomaan hankintalain ja yhteishankintojen ongelmia tarjoamalla hankintaosaamisen ja toteutuksen valmiissa paketissa: Tiera kuitenkin ainakin tällä hetkellä on erikoistunut tekemään nimenomaan kunnille yleisiä ratkaisuja, kuten tarjoamaan räätälöityjä mutta pohjatekniikaltaan samoja www-sivuja. Pelkkää hankinta-apua siis Tiera ei tällä hetkellä tarjoa: lähtökohtanahan Tieralle on osittain ollut, että pienten kuntien ei ole ollut järkevää tehdä samoja ohjelmistoja satoja kertoja uudelleen.

Totesimme, että markkinoilla on itse asiassa tyhjiö hankintaosaamisen tarjonnassa: jokunen yritys tarjoaa tätä, mutta tilaa olisi kokonaan uudelle toimijalle. Vaikka hankintaosaamisesta on vuosia puhuttu, etenkin julkisella puolella sen merkitys on alkanut selvitä laajemmin vasta viime vuosina. Tätä osaamista ei vielä monellakaan kunnalla ole.

Yksityiselle puolelle helpointa olisi saada mukaan toimija, joka ei myisi toteutusta, jolloin se voisi tuntua kumppanina luotettavammalta. Uusi julkishallinnon toimija, joka keskittyisi hankintaosaamisen kehittämiseen ja tarjoamiseen voisi kuitenkin myös olla erittäin toimiva: konkreettisena askeleena esim. Sitra voisi seuraavassa kuntaohjelmassaan tutkia tällaista vaihtoehtoa.
Samalla keskustelimme myös osaamistyhjiöstä. Mikä on kunnan ydinosaamista, ja mitä asioita voidaan ulkoistaa? Nyt on välillä menty reilustikin metsään ulkoistamalla myös hankinnan kannalta tarpeellista substanssiosaamista. Onnistunut projekti, erityisesti ketterä projekti vaatii vahvaa omistajuutta ja osaamista oman talon sisällä. Kuinka tätä osaamista voisi vahvistaa ja miten sitä voi määritellä? Ulkoistuskysymyksissä on ideologisia rintamalinjoja, mutta it on niistä onneksi ainakin suurimmaksi osaksi vapaa. Hyvä kysymys kuitenkin on, voiko virkamieheltä kysyä, oletko tarpeellinen – tällaisen asian kartoittamisessa ulkopuolinen apu voisi itse asiassa olla tarpeen.

Mitä seuraavaksi?

Terveydenhuollon tietojärjestelmien ongelmat eivät vielä kokonaan ratkenneet, mutta keskustelussa syntyi myös konkreettisia avauksia jatkolle. Vaikka sessiot purettiinkin lopuksi auki, paljon tietoa jäi myös keskustelijoiden päähän. Tässä postauksessa avasin vain niitä paria keskustelua joissa itse olin mukana. Puramme näitä vielä järjestäjäporukalla muistioon, jotta saamme myös konkreettisia jälkiä keskustelusta ja mahdollisia avauksia jatkolle.

Tällaisessa osallistuvassa tilaisuudessa kaikkein jännittävintä on aina se, miten tilaisuus lähtee muokkautumaan: ennalta ei voi tietää, mille poluille juuri tämä porukka keskustelun vie. Tavoitteena oli tuoda yhteen ihmisiä, joilla on aiheesta sanottavaa mutta jotka eivät ehkä muuten kohtaisi, ja tässä uskoakseni onnistuimme. Haluankin lopuksi kiittää kaikkia osallistujia erinomaisesta, innostavasta ja rakentavasta tilaisuudesta!

by

Apotti vastaa

Helsingin sosiaali- ja terveyslautakuntien vaatimat lisäselvitykset Apotti-hankkeesta on nyt tehty. Sosiaalilautakunta kokoontuu käsittelemään asiaa 6.11 eli ensi tiistaina. On hyvä asia, että palautteeseen pyritään reagoimaan nopeasti, vaikka luonnollisesti selvityksen tarkkuudesta on jouduttu tinkimään. On selvää, että HUSissa hanke halutaan liikkeelle mahdollisimman nopeasti.

Parannusta edelliseen on, mutta konkreettisesti on välillä vielä hyvin hankala ottaa selvää siitä, mitä tämä tarkoittaa. Ongelmana on edelleen se, että näillä ehdoilla voidaan lähteä aivan metsään, tai vain vähän vähemmän sinne päin. Tässä siis esiselvityksen tulokset sekä ensivaikutelmani siitä mitä se tarkoittaa.

Ensimmäisenä nostan esiin sen, että selvitysten jälkeen on päädytty edelleen hankinnan tekemiseen kokonaispalveluhankintana, pääosin yhdeltä toimittajalta. Kokonaispalvelu ei tässä ole ongelma vaan aiemmin mainitut ongelmat: toimittajaloukku sekä liian ison järjestelmän vaarat. Kuitenkin on otettu huomioon, että jotkin järjestelmän osat hankitaan muilta toimittajilta. Tässä Deloitten raportti on erittäin suoraviivainen: he suosittelevat, että vaikka järjestelmän isommat kokonaisuudet tilataankin valmisohjelmistona yhdeltä toimittajalta, osakokonaisuudet kannattaa kilpailuttaa mahdollisesti eri toimittajilta ja varmistaa että tämä on myös mahdollista.

Toisaalta hanketoimiston tulkinta aiheesta vaikuttaa hieman vesitetyltä:

Aikaisemman valmistelun, nyt tehdyn selvityksen taustamateriaalin sekä konsulttitoimisto
Deloitten tekemän kustannus- ja riskianalyysin tulosten perusteella on perustelua edetä
hankinnassa niin, että pyritään alueelliseen sosiaalihuollon, perusterveydenhuollon ja erikoissairaanhoidon yhteisen asiakas- ja potilastietojärjestelmän hankintaan. [2]

Hankitaan yhteinen järjestelmä. Ack. Mutta tarkoittaako tämä nyt monoliittiä vai jotain muuta?

jätetään mahdollisuus siihen, että osa toiminnallisuuksista hankintaa sovitun määräajan sisällä hankintaan liittyvänä erikseen tarjottavana kokonaisuutena. Lisäksi pidätetään oikeus pystyä tarvittaessa vaihtamaan palvelusopimuksen aikana järjestelmän osatoiminnallisuuksia kolmannen osapuolen vaihtoehtoon. [2]

Jätetään mahdollisuus. Vaikea sanoa miten tämä tulee toteutumaan.

Käsittelen riskianalyysia ja eri toimitusvaihtoehtoja kohta. Sitä ennen kuitenkin huomio. Eräs huolestuttavimmista projektidokumentaatiosta lukemistani asioista koski käyttöönottoa: ohjelman käyttöönotto halutaan tehdä ns. Big Bang- menetelmällä eli kertaluonteisella käyttöönotolla. Tämä siksi, että siinä käyttöönottokustannukset näyttävät nimellisesti pienemmiltä, koska rinnakkaista järjestelmäylläpitoa on vähän. Käytännössä etenkin isossa hankkeessa käyttöönotto väistämättä myöhästyy ja tuskin sujuu ongelmitta. Näin ollen säästö jää nimelliseksi mutta riskit kasvavat. Tätä käyttöönottosuunnitelmaa ei käsitelty jatkoselvityksessä millään tavoin. Itse olin tulkinnut asteittain tarkentuvan vaatimuksen yhdistettynä paloittaiseen toteuttamiseen koskevan myös käyttöönottoa, mutta käytännössähän se voidaan lukea vain järjestelmän kehitysprosessina. Eli kun luin uudestaan nuo vaatimukset, siellä olisi pitänyt olla rautalangasta väännettynä: järjestelmän käyttöönoton vaiheistaminen niin, että tuotantoon siirtymisen riskit on minimoitu. Tämä tulee olemaan hankkeen kompastuskivi, jos sitä ei nyt huomioida.

Edellisenhän  ei tarvitse tarkoittaa erillisten toimittajien järjestelmien ostamista ja yhteensovittamista, vaan yksinkertaisimmillaan sitä, että tilattavasta järjestelmästä otetaan ensiksi käyttöön pelkkä potilastietojärjestelmä ja, mikäli tämä onnistuu, katsotaan seuraavia osia. Näin nähdään myös ajoissa, jos järjestelmä ei vastaakaan tarpeita, on liian hankala sovittaa haluttuihin prosesseihin tai jos järjestelmätoimittajan kanssa on ongelmia. Tämän vaihtoehdon riskit ovat toki nykyjärjestelmään integroitumisessa. Se ei ole triviaalia, jos nykyiselläänkin näitä toimittajia on hankala pitää kurissa. Mutta se on vähemmän paha riski kuin havaita projektin myöhästyttyä kaksi vuotta ettei sitä saada valmiiksi koskaan.

Hanketoimiston teesit

Alla käyn läpi kolmea liitteenä ollutta dokumenttia tarkemmin, kommentoiden niitä em. huomion valossa. Postaus on pitkä kuin nälkävuosi, lukekaa omalla riskillä.

Ensin HUSin eli hankkeen ohjausryhmän kanta:

”Aikaisempaan valmisteluun ja nyt tehdyn selvityksen taustamateriaaliin ja kustannus ja riskianalyysiin pohjautuen hankkeen ohjausryhmä päätti 26.10.2012 kokouksessaan seuraavista linjauksista:

–        Hankinta tehdään lähtökohtaisesti kokonaispalveluhankintana

–        On perusteltua tavoitella sellaista hyvin toimivaa mahdollisimman laajaa palvelukokonaisuutta, joka kattaa keskeiset asiakas- ja potilastietojen ja toiminnanohjauksen käsittelyn ydintoiminnot ja tämän lisäksi siihen saumattomasti liitetyt erillistoiminnallisuudet.

–        Jos tarjolle tulevissa järjestelmäkokonaisuuksissa on sellaisia toiminnallisia ominaisuuksia tai palveluja, joiden ei katsota kustannuksiltaan tai muilta ominaisuuksiltaan vastaavan tarpeitamme, ne voidaan jättää hankinnan ulkopuolelle ja hankkia kolmannelta osapuolelta rajapinnan kautta yhteensopiva tuote.

–        Samoin jätetään mahdollisuus siihen, että osa toiminnallisuuksista hankintaa sovitun määräajan sisällä hankintaan liittyvänä erikseen tarjottavana kokonaisuutena.

–        Pidätetään oikeus pystyä tarvittaessa vaihtamaan palvelusopimuksen aikana järjestelmän osatoiminnallisuuksia kolmannen osapuolen vaihtoehtoon.

–        Hankittavan järjestelmäpalvelun tulee sisältää tarpeidemme mukaiset hyvin toimivat avoimet rajapinnat.

–        Hankintasopimuksessa tulee varautua sopimuskauden loppumiseen siirtymäkauden järjestelyillä sekä toimittajan tai toimittajakonsortion jonkin osapuolen mahdolliseen konkurssiin.” [1]

Edelleen siis lähdetään hankkimaan isoa järjestelmäkokonaisuutta. Kuitenkin jätetään auki se, että osa toiminnallisuudesta tilataan muilta toimittajilta tai liitetään tuotteeseen myöhemmin. Erityisen hyvä on se, että pidetään huoli siitä että toimittajaa voi tarvittaessa vaihtaa ja rajapinnat ovat avoimia. Nämä kaksi asiaa ovat sellaisia, jotka on kovin helppoa kirjoittaa auki ja niin helppo unohtaa. Näissä tarvitaan siis kunnolliset sopimukset, määrittelyt, sanktiot ja vahva ohjaus, rajapintojen suhteen mm. niin että niitä ei saa muuttaa ilman tilaajan suostumusta.

Hanketoimisto muistaa myös kertoa kauniita ajatuksia siitä, mitä kaikkea järjestelmä voisi tehdä:

”Järjestelmä tukee ammattilaisen työtä esimerkiksi sokeritautipotilaan vastaanotolla tarkastamalla hoidon laatuun vaikuttavia seuraavia tekijöitä kuten onko potilaalla suosituksen mukainen lääkitys, onko tarpeelliset laboratoriokokeet otettu ja ovatko muut tarpeelliset tutkimukset esimerkiksi silmänpohjavalokuvaus tehty. Lääkemääräyksiä tehtäessä päätöksenteon tuki tarkastaa ovatko lääkityksen edellyttämät laboratoriokokeet määrätty ja onko laboratoriotuloksissa riskisarvoja lääkitykseen suhteen” [1]

Hienoa. Käytännössä kuitenkin se, mitä pitää tehdä, on ensin hoitaa edes perusjärjestelmä toimivaksi. On aivan turhaa lähteä tekemään hoitoa tukevia muistutuksia, jos potilaan tietojen kirjaus on niin kömpelöä, että paperilla se tapahtuisi nopeammin. Nämä mukavat asiat tulevat sen jälkeen. Ensisijaisesti tulisikin saada käyttöön järjestelmä, joka tekisi sen mitä nykyjärjestelmät mutta paremmin  ja tiedon siirtämisen tarpeet huomioonottaen. Sen jälkeen katsotaan hoitoa tukevia muistutuksia ja sähköistä asiointia.

Katsaus naapurimaiden tilanteeseen

Hanketoimiston paperi on myös mielenkiintoinen katsaus lähinaapureidemme asioihin.

”Virossa, Ruotsissa ja Tanskassa selkeänä etuna järjestelmien kehitykselle on ollut kyky muodostaa, toteuttaa ja ylläpitää kansallista eHealth strategiaa, jonka lähtökohtana ovat olleet tiedonvälitys ja standardit.” [1]

Onko Suomessa tätä? KanTa-hanke kyllä, rajapintamääritysyrityksiä myös. Mutta kuten minua paremmin aiheesta selvillä olevat kommentoivat sosiaalisessa mediassa, meilläkin tulee päästä siihen pisteeseen että tarvittavat standardit ja prosessit on määritelty. Se että olemme myöhässä ei ole tekosyy jättää niitä tekemättä.

Esimerkkinä Ruotsin kansallinen eHealth-strategia:

”Kansallinen eHealth strategia julkaistiin 2006 (päivitetty versio

6/2010). Sen tavoitteita ovat:

1. Yhdenmukaistaa lakeja ja määräyksiä mahdollistamaan it:n käytön lisäämisen

2. Luoda kansallinen tietoarkkitehtuuri

3. Luoda kansallinen järjestelmäarkkitehtuuri

4. Kannustaa it-järjestelmien yhteensopivuuteen ja tiedonvälitykseen

5. Kannustaa organisaatiorajat ylittävään tiedon saatavuuteen

6. Luoda kansalaisille helppo saatavuus tietoon ja palveluihin” [1]

Järjestelmäratkaisuja mainitaan selvityksessä nimeltä pari. Tanskassa ja Ruotsissa Cambio on monessa paikassa yleisin. Jos lähdetään ostamaan yhtä järjestelmää, kallistuisin ehdottomasti lähiseudun järjestemän pariin enkä amerikkalaiseen, vakuutusperustaista terveydenhoitoa tukevaan ohjelmistoon.

Englannin potilastietojärjestelmähankkeissa viitataan erityisesti iSoft Lorenzo-järjestelmään. Raportissa keskityttiin hieman erikoisesti korostamaan, että projektissa lähdettiin tekemään tyhjästä Intiassa järjestelmää. (Kuulemma koodin heikko laatu yllätti kaikki osapuolet. Kukapa olisi arvannut?) Sen sijaan projektin lähtökohdan suurinta ongelmaa: liian suuret suunnitelmat, ei mainittu tässä kohdassa. Toisen brittien hankkiman, valmiin järjestelmän (Cerner Millenniumin) ongelmat jätettiin tässä mainitsematta.

Erityisesti Englantia koskevasta kohdasta toivoisin hanketyöryhmän kiinnittävän huomiota seuraavaan:

Käyttöönotoissa on tyypillisesti ensin on otettu käyttöön kaikille yhteiset osiot, kuten varsinainen potilastietokanta ja siihen liittyvät toiminnot, seuraavassa vaiheessa sairaalan erillisjärjestelmiä (voivat olla myös optioina myöhemmin hankittavia) ja kolmannessa vaiheessa perusterveydenhuollon osuuksia. [1]

Erilaisten toteutusvaihtoehtojen analyysi

Deloitte analysoi seuraavia vaihtoehtoja:

1. Järjestelmän hankkiminen kattavana kokonaisuutena
2. Erikoissairaanhoidon, perusterveydenhuollon ja sosiaalitoimen järjestelmien hankkiminen omina kokonaisuuksinaan
3. Ydinjärjestelmä ja sitä täydentävät erillisjärjestelmät
4. Järjestelmän rakentaminen itse

Kuten jo aiemmin totesin, käyttöönottoa ei tässä valitettavasti analysoitu.
Tavasta 2 todetaan seuraavaa:

Erillisten osajärjestelmäpalveluiden hankinnan kautta hanke voitaisiin jakaa pienempiin ja helpommin hallittaviin kokonaisuuksiin. Yksittäisen palvelutoimittajan asema ei myöskään muodostu yhtä vahvaksi tilaajaan nähden kuin kattavan kokonaisuuden mallissa. Erikoissairaanhoidon, perusterveydenhuollon ja sosiaalitoimen välillä on kuitenkin paljon yhteisiä toiminnallisia osia, tietoja ja tiedonsiirtotarpeita. Ne edellyttävät tiivistä yhteistyötä ja kokonaisohjausta osajärjestelmien toteuttamiseksi, ja riskinä on ettei täydellistä integraatiota saada tehdyksi. [1]

Kiinnittäisin tässä huomiota kohtaan ”edellyttävät tiivistä yhteistyötä ja kokonaisohjausta osajärjestelmien toteuttamiseksi”. Tämä vaatii tilaajalta sekä vahvaa teknistä, projektinhallinta- että integraatio-osaamista (sisältä tai ostettuna) ja vahvoja sopimuksia. Nykyisellään toimittajat pahimmillaan voivat kieltäytyä yhteistyöstä tai muuten haitata integraatioprosessia ilman sanktioita. (Niille jotka odottavat tässä kohdassa lähdeviitettä: perustuu vahvoihin huhupuheisiin.)

Tarkemmasta riskianalyysistä

Suositukset
Edellisten näkökohtien perusteella neuvottelut kannattaa käynnistää laajasta kokonaisuudesta mutta tehdä hankinta siten, että ydinjärjestelmäpalvelun toiminnallisuutta voidaan täydentää tarvittavilta osin erillisillä, ydinjärjestelmään integroiduilla
erillisjärjestelmillä jotka voidaan tarvittaessa kilpailuttaa ja hankkia eri toimittajilta. Myös tuotteiden tai toimittajien vaihtomahdollisuus tarvittaessa tulee pyrkiä säilyttämään. [3]

Kuulostaa järkevältä. Tässä se, miten asia toteutetaan tulee olemaan kriittistä. Vaihtomahdollisuuden tulee olla aito ja sen hankaloittamisen tulee aiheuttaa sanktio.

Osa erikseen hankittavista osajärjestelmistä voi olla valmiiseen tuotteeseen perustuvia,
osa erikseen ohjelmoitavia uusia palveluita. Uusista palveluista voi syntyä myös uusia
tuotteita tämän alueen tietojärjestelmien markkinoille kansallisesti tai kansainvälisesti.
Riippumatta valittavasta hankintavaihtoehdosta hanketta ohjaavan tilaajaorganisaation
tulee olla koko hankkeen ajan vahvassa roolissa toteutuksen ohjauksessa, ja sillä tulee
olla jatkuvuus myös tuotannon aikaiseen tilaajaorganisaatioon.

Kehittämisessä tulee huomioida myös Apotti-järjestelmän elinkaaren aikana tapahtuva
sosiaali- ja terveydenhuollon sekä muun julkishallinnon järjestämistapojen muutokset sekä
tietojärjestelmäarkkitehtuurien kehitys kansallisella ja eurooppalaisella tasolla, joka kulkee
kohti vahvempaa potilas- ja asiakaskeskeisyyttä ja asiakkaan sähköisiä palveluita sekä laajempaa eri osapuolien järjestelmien yhteentoimivuutta. [3]

Parempaa. Tätä ei kovin huolella tosin huomioitu kokouksen liitteessä 3 (hanketoimiston selvitys [2]). Toivottavasti tätä kappaletta on tutkittu siellä tarkkaan.

Kustannuksia ei arvioitu tarkkaan. Toisaalta tällä epämääräisyysasteella se olisikin hankalaa. Selvitys on tehty nopealla aikataululla ja siinä myönnetäänkin, että käytössä oleva informaatio on ollut rajattua ja esim. riskeistä on käsitelty vain keskeisimmät.

Näyttää siltä että edelleen ollaan ajautumassa ns. lypsymalliin vaihtoehdosta riippumatta, eli luvataan jotain tietyllä hinnalla ja kaikki siitäeteenpäin maksaa. Olen niin kyyninen etten jaksa välittää – tärkeintä olisi, että hinta ei paukkuisi ihan liikaa (se joka tapauksessa venyy), että toimitusaika pysyisi hallinnassa ja että softa olisi käytettävä. Ja että se olisi joskus käytössä.

Kaikissa vaihtoehdoissa on havaittu, että olennaista on että langat pysyvät tiukasti tilaajan käsissä. Vaihtoehdossa yksi tätä ei todettu niin suuresti tarpeelliseksi, mistä en ole ihan vakuuttunut.

Deloitten lopullinen kannanotto tiivistyy seuraavasti:

Hankinnat kannattaa toteuttaa tarkastellun vaihtoehdon 3 mukaisella, myös tiettyjä
vaihtoehdon 1 piirteitä sisältävällä tavalla.

—

Neuvottelut kannattaa siis käynnistää laajasta kokonaisuudesta mutta tehdä hankinta
siten, että ensi vaiheessa hankitaan neuvottelujen perusteella tarkoituksenmukaiseksi
osoittautuva kokonaisuus, jonka toiminnallisuutta täydennetään tarvittavilta osin erillisillä,
ydinjärjestelmään integroiduilla erillisjärjestelmillä tai lisäpalveluilla. Näitä voidaan hankkia
joko samalta toimittajalta tai konsortiolta lisähankintoina, tai kilpailuttaa ja hankkia eri
toimittajilta. Myös tuotteiden tai toimittajien vaihtomahdollisuus tarvittaessa tulee pyrkiä
säilyttämään.

—

Riippumatta valittavasta hankintavaihtoehdosta hanketta ohjaavan tilaajaorganisaation
(tällä hetkellä Apotti-hanketoimisto) tulee olla koko hankkeen ajan vahvassa roolissa
toteutuksen ohjauksessa, ja sillä tulee olla jatkumo myös tuotannon aikaiseen
tilaajaorganisaatioon (esimerkiksi osallistujakuntien omistama yhtiö). Mikäli yhden
toimittajakonsortion kokonaispalvelun sijasta hankinta tehdään useammalta toisistaan
riippumattomalta toimittajalta, tilaajaorganisaation vastuu kokonaisuuden
yhteensopivuudesta kasvaa ja tämän tulee heijastua myös organisaation resursointiin ja
osaamisiin. [3]

Deloitten teksti on asiaa. Kysymys kuuluu, toteutuuko tämä? Tämän lisäksi käyttöönotto on vielä suuri kysymysmerkki. Palaan taas lempiaiheeseeni luottamukseen: jotta hankkeelle voitaisiin avata avoin piikki (ja tätä on turha kaunistella millään kuvitteellisilla maksimiarvioilla), täytyy luottaa siihen, että hankkeella olisi edes jonkinlainen onnistumisen mahdollisuus.

[1] Lausunto sosiaalihuollon, perusterveydenhuollon ja erikoissairaanhoidon yhteisen asiakas- ja potilastietojärjestelmäpalvelun hankintailmoituksesta ja pyynnöstä osallistumishakemusten jättämisestä

[2] Hanketoimiston selvitys 29102012

[3] Apotti-järjestelmähankinnan vaihtoehtojen kustannusvaikutukset ja riskit 30102012 (Deloitten selvitys)

by

Potilastietojärjestelmälle toipumisaikaa

Ilouutisia: Helsingin kaupungin sosiaalilautakunta päätti tänään kokouksessaan palauttaa Apotti-hankkeen uudelleen valmisteltavaksi seuraavin ehdoin:

1) selvitetään mahdollisuutta hankkia järjestelmä osina yhden
kokonaisuuden sijasta

2) selvitetään mahdollisuutta rakentaa järjestelmä asteittain
tarkentuvaksi (iteroiden),
3) selvitetään näiden toimien kustannusvaikutukset
sekä
4) laaditaan riskianalyysi, jossa arvioidaan myös hankkeen
viivästymisen todennäköisyys eri hankintavaihtoehdoissa ja sen
vaikutukset kokonaiskustannuksiin sekä järjestelmästä luopumisen
kustannus aikanaan.5) Lisäksi sosiaalilautakunnan mielestä ennen hankintaa ja mahdollisen hankinnan edetessä tulee varmistaa, että sosiaalihuollon tietojärjestelmien tarpeet ja miten asiakas- ja potilastietojärjestelmä Apotti vastaa niihin.

6) Myös hankinnan ohjelmistotuotanto- ja hankintaprosessien osaaminen tulee varmistaa.

Tämä kanta ratkaisee potilastietojärjestelmän seuraavat askeleet.

Olen jättänyt Hinnalla millä hyvänsä -kirjoituksen jälkeen julkaisematta jo monta aiheeseen liittyvää postausta. Mitä enemmän projektista tietää, sen vähemmän on yksinkertaisia vastauksia. On selvää, että kyseessä ei ole ensisijaisesti tietotekninen projekti, joten päätin jättää pois tietotekniikkaprojektien teknisiä yksityiskohtia vilisevän kirjoituksen. Moni muu on, onneksi, pitänyt asiaa pöydällä ja kirjoittanut aiheesta erittäin ansiokasta sisältöä. Muokannen itse vielä julkaisukuntoon kaksi postausta joista toinen käsittelee järjestelmien nykytilaa integraattorina toimineen ihmisen näkökulmasta sekä toisen, joka käsittelee Apotti-hankkeen tiedotusta.

Erityisesti voin suositella seuraavia linkkejä, joista käy ilmi tarkemmin, mistä tässä on kyse. Yleisesti uudistuksen eri tahoja ja uudistettavia asioita käydään läpi mm. Sosiaali- ja terveysministeriön tiedotteessa. Tässä mielenkiintoista on mm. KanTa-hankkeen osuus – tulkitsen sen niin, että paikallisen tason järjestelmä ei voi käyttää KanTaa niin, että oma järjestelmä toimisi vain ”käyttöliittymänä” KanTalle. Otso Kivekäs puolestaan kirjoitti hankkeen riskianalyysista. Lyhyesti, hanke on järkälemäinen ja huonosti määritelty, ja epäonnistumisen riski on suuri jos ongelmakohdille ei tehdä mitään. Harri Juntunen kirjoitti hyvän analyysin kriittisimmistä ongelmakohdista aiheesta järjestetyn keskustelutilaisuuden jälkeen. Kaikki suurimmat ongelmat liittyvät itse toimintakentän huonoon määrittelyyn, eivät teknisiin riskeihin. (Niitäkin on, mutta jos lähdetään tekemään hosuen, valituilla teknisillä ratkaisuilla ei ole oikeastaan merkitystä. IT-projektin onnistuminen ratkeaa määrittelyvaiheessa.)

Lyhyesti kyseessä on kuitenkin seuraavanlainen asia. HUS on ajanut, kenties ajattelematta sen kummemmin että asia voisi kiinnostaa sen suurempia kansanjoukkoja, lähti ajamaan sinänsä erittäin tarpeellista parannusprojektia erityisemmin tuomatta sitä päättäjille. Vaikka kyseessä on ennenkaikkea prosessien ja toimintamallin uudistus, sitä lähdettiin tekemään IT edellä: jopa niin vahvasti, että hankesuunnitelmassa mainitaan, että IT-järjestelmä suurella todennäköisyydellä määrittää toimintatapoja eikä päinvastoin. Hanketta oli mahdollisesti tarkoitus ensin jopa lähteä ajamaan normaalina hankintapäätöksenä, HUSin sisäisenä asiana. Asiakirjoja lukemalla on äärimmäisen vaikea päästä projektista kärryille.

Ongelmana on, että hankesuunnitelma ei oikeastaan kerro hankkeesta mitään. Siinä luvataan projektin onnistuessa yhdeksän hyvää ja kahdeksan kaunista, mutta edes projektin itsensä onnistumisen mittareita ei ole määritelty, sillä ”Mittareita kehitetään hankkeen aikana”. Hankesuunnitelmasta käy myös selvästi ilmi, että koko projektia – prosessien yhtenäistämistä, toiminnanmuutosta ja näihin nivoutuvaa järjestelmää – pyritään tekemään kertarysäyksellä, vesiputousmallina. Tämän lisäksi projektisuunnitelmassa ei millään tapaa kerrota, miten sitä mahdollisesti ajateltiin jaksottaa. Hankkeen aikana mm. halutaan luoda toimiva sähköinen asiointijärjestelmä. Tämä on iso kokonaisuus, joka hoituu kyllä, kun itse potilastiedot on saatu yhtenäisesti kerättyä (ja muutama muukin pikku detalji). Mutta näin ison palasen ottaminen mukaan hankkeeseen tekee siitä entistäkin kiikkerämmän. Toinen ihmetyksen aihe on ollut sosiaalipuolen mukaanotto – hankkeen tavoitteena on yhtenäistää myös nämä järjestelmät, mutta projektiryhmissä ei edes ole ollut mukana alan asiantuntijaa. Tämäkin voitaisiin ehkä tehdä erikseen.

On täysin mahdollista, että nämä asiat on mietitty hankkeessa jo valmiiksi. Mutta mistään päin dokumentaatiota se ei käy ilmi.

Olisi helppoa nimitellä hankkeen puuhamiehiä kädettömiksi ja osaamattomiksi. Tästä ei ole kyse, heitä on pidetty aika kovilla viime viikkoina. Mutta vaikuttaa siltä, että osittain vanhojen painolastien vuoksi on lähdetty tekemään hyvin riskialtista projektia, lähinnä sillä ajatusmallilla että tätä ei ainakaan vielä ole kokeiltu. Harri Juntunen totesikin, että yhden toimittajan mallilla on lähdetty simuloimaan sitä, että Virossa yksi taho toimii järjestelmän tilaajana. Tässä on kuitenkin jotain nurinkurista – eikö olisi parempi sitten yhtenäistää tilaajapuoli, jota tässä on hankintarenkaalla yritettykin, eikä toimittaja?

Projektiorganisaatiossakin voitaisiin vielä miettiä asioita. Eräitä ehdotuksia ovat olleet mm. erillinen laadunvalvontaroganisaatio. (Erillinen, toimittajasta erillään oleva laadunvalvontayksikkö tulee projektissa väistämättä olla). Keski-Suomessa lähdettiin yhtenäistämään järjestelmiä vähän kerrallaan, valiten keskeisimmistä järjestelmistä fiksuin ja uudistaen samalla hiljalleen toimintatapoja. Siellä ei rykäisty kaikkea uusiksi mutta toimivaa on saatu pikku hiljaa. (Laitan linkin heti kun löydän, oli käsillä eilen.)

Terveydenhuollon järjestelmät tulee saada toimimaan. Surullisia tarinoita niiden tilasta löytyy riittämiin. Nämä järjestelmät tulee saada kuntoon, mutta hosumalla ei tule hyvää jälkeä. Järjestelmäuudistuksissa ollaan vuosia myöhässä monesta eri syystä, mutta näiden ongelmien ratkaisemiseksi ei ole nopeaa ratkaisua. Alkuperäinen hankesuunnitelma ehdotti avointa sekkiä hankkeelle, jonka epäonnistumisen riski oli jättiläismäinen – ja epäonnistumisen panokset huikeat, kun epäonnistumisen varaa ei ole.

Tässä on voitettu pieni taistelu, mutta isoimmat ovat vielä käymättä. Kuinka näitä ohjeita noudatetaan? Mitkä tulevat olemaan hanketyöryhmän vastaukset? Ja mitä ratkaisuja Apotin kanssa lopulta tehdään?

Elämme mielenkiintoisia aikoja.

by

Potilastietojärjestelmän parantaminen: Mitä voin tehdä?

Kirjoituksesta, jossa pyrin tuomaan esiin mahdollisimman selvällä esimerkillä potilastietojärjestelmän järjettömän kustannusarvion, on levinnyt melkoinen lumipalloefekti. Uutinen on poimittu mm. IT-viikkoon ja Helsingin Sanomiin. (Jälkimmäisessä pyrittiin katsomaan kiihkottomasti, mistä eri osista hinta-arvio koostuu, mutta jätettiin huomioitta mm. se olennainen seikka, että liki puolet kustannusarviosta on ohjelmistokustannuksia.) Monet ovat ymmärrettävästi huolissaan siitä, voiko asialle enää tehdä mitään: järjestelmää ja sen hankintaprosessia on päivitelty julkisuudessakin jo kuukausitolkulla, mutta byrokratian rattaat ovat vain ruksuttaneet eteenpäin.

Kokosin tähän muutaman asian, joihin voi itse vaikuttaa – tänään, parin kuukauden sisään ja myös pidemmällä tähtäimellä.

1) Osallistu mielenilmaukseen huomenna.
Huomenna, ennen Helsingin kaupungin terveyslautakunnan kokouksen alkua luovutetaan kannanotto terveydenhuoltojärjestelmän uusimisesta kaupungin luottamushenkilöille. Tuossa kokouksessa pitäisi päättää Helsingin osalta järjestelmähankinnasta, vaikka asia jääneekin vielä pöydälle. Tapahtumakutsu löytyy Facebookista, mukana myös pyyntö osallistua kannanoton luonnostelemiseen vielä tänään.

2) Kerro mielipiteesi jo tänään.

Allekirjoita adressi, jossa halutaan julkishallinnon järjestelmät irti yhden toimittajan loukusta. Adressi koskee vain yhtä pientä osaa prosessissa, jossa menee pieleen lähes kaikki mahdollinen, mutta tämä on yksi erittäin tärkeä palikka palapelissä, jossa tavoitteena on saada vihdoin toimivia järjestelmiä järkevällä hinnalla, aikataulun mukaisesti.

3) Tutustu aiheeseen.

Hyvä paikka aloittaa on esimerkiksi Facebookiin kerätty linkki- ja faktakokoelma.

4) Pidä huoli siitä, ettei tämä toistu.

Vaikka tämä hanke menisikin läpi, voit huolehtia siitä että seuraavassa valtuustossa istuu ihmisiä, jotka ymmärtävät mistä on kyse. Kysy kunnallisvaaliehdokkaaltasi, mitä mieltä hän on it-hankinnoista. Kysy, mitä hän ymmärtää niistä. Ohjelmisto-alan ammattilaisia on harvassa, ja heitäkin tarvitaan valtuustoon. Mutta jo kyky hahmottaa ero miljoonien ja miljardien välillä on merkittävä etu.

5) Levitä sanaa.

IT-hankinnoissa mättää moni muukin asia kuin hintalappu. Hintalappu on usein vain suoraa seurausta siitä, että ensin on tyritty parikymmentä muuta kohtaa. Hyvä aloituskohta tärkeimpiin ongelmiin on esim Otso Kivekkään tuorein kirjoitus aiheesta. Linkkaa nämä jutut kunnallisvaltuutetullesi. Kirjoitan itsekin myöhemmin tänne muutamia asioita, joita pitää ottaa huomioon hankinnoissa. (Esimerkkinä: jos it-alan yrityksen edustaja on tekemässä selvitystä hankinnasta, ko. yritys tulee jäävätä varsinaisesta tarjouskilpailusta.)

Suunniteltu potilastietojärjestelmä on surkuhupaisa esimerkki siitä, mitä tapahtuu kun yritysmaailma pääsee osallistumaan hankintojen suunnitteluun, projektin suunnittelijat eivät ymmärrä tietotekniikkaa, ja virkamiehet pääsevät sooloilemaan ilman tulosvastuuta. Jos omalta osaltasi haluat vaikuttaa tämän asiantilan muutokseen, tee se nyt.

by

Hinnalla millä hyvänsä: Potilastietojärjestelmä vai avaruussukkula?

Pääkaupunkiseudulla ollaan uudistamassa potilastietojärjestelmiä. Helsingin, Espoon, Vantaan ja muutamien ympäryskuntien projekti tehdään yhteistyönä. Samalla uudistetaan järjestelmät koko maassa. Maanlaajuisesti projektin hinnaksi on alustavasti arvioitu 1,8 miljardia euroa, josta pääkaupunkiseudulla voi kulua leijonanosa.

Summa on niin suuri, että siitä on hankala keskustella. Sadoista miljoonista euroista tulee monopolirahaa, jota pyöritellään tajuamatta että loppusumman marginaaleissakin puhutaan suuremmista summista kuin päivähoidon tai koulujen kokonaisbudjetti.

Potilastietojärjestelmä on kannatettava asia. Mutta mikään fiksusti hankittu IT-järjestelmä ei voi maksaa 1,8 miljardia. Jos arvioitu summa on noin suuri, jotain on pielessä jo projektin suunnittelussa.

Selittelyt Suomen uniikista tilanteesta ovat täyttä tuubaa. Suomen tilanteessa on uniikkia järjestelmätoimittajien osallistuminen selvitystyöhön, joka pohjustaa toimittajien ja järjestelmän valintaa, sekä ymmärtämättömyys siitä mitä oikeastaan ostetaan.

Kaikkien hankintaan osallistuvien pitäisi viimeistään tässä vaiheessa tietää, että suuret ohjelmistotalot osallistuivat potilastietojärjestelmän selvitystyöhän ja siinä sivussa hankkivat lisenssit ohjelmiin, joita päättivät suositella. Ne siis suosittelevat ohjelmia, joista ne itse saavat suurimmat voitot, ja jotka voi tilata vain niiltä.

Muokataanko valmista vai tehdäänkö itse?

Selvitykseen osallistuneet ohjelmistotalot suosittelevat ulkomailta lisensoimiaan valmiita terveydenhuoltoalan ohjelmia. Vaikka tämä kuulostaisikin helpolta ratkaisulta, tietojärjestelmää ei voi sellaisenaan siirtää paikasta toiseen. Jos ostamme amerikkalaiseen terveydenhuoltojärjestelmään kehitetyn ohjelman, saatamme joutua käyttämään sen korjaamiseen enemmän rahaa kuin uuden alusta pitäen tekemiseen. Osa virheistä paljastuu vasta paljon myöhemmin, sillä kaikkia yhteensopivuusongelmia ei todennäköisesti huomata.

En väitä, etteikö valmis ohjelmisto voisi toimia uuden järjestelmän pohjana. Mutta harva, joka ei työskentele it-alalla, ymmärtää että ohjelmistoprojekti ei ole suoraan verrattavissa elementtitaloon tai tiehankkeeseen. Näihin verrattuna suurimmat erot ovat siinä, että ohjelmiston, isonkaan, ei tarvitse olla superkallis. Ja toisekseen, valmiin ohjelman muokkaus voi joskus olla hankalampaa kuin uuden teko.

Kustannukset perspektiiviin

Virossa tämä sama juttu – yksinkertainen potilastietojärjestelmä – tehtiin 10 miljoonalla. Kirsikkana kakussa sähköinen resepti tehtiin miljoonalla.

Merkillepantavaa on, että myöskään ajallisesti projekteissa ei virolaisilla kauaa nokka tuhissut  – kumpikin järjestelmä toteutettiin noin vuodessa.

Viro ei ole mielikuvitusmaa, alienien siirtokunta tai erityistapaus terveydenhuollon järjestelyjen osalta. Virossa vain tiedetään, mitä halutaan, eikö olla vielä jouduttu ylisuurten korruptoituneiden it-talojen kuristussyleilyyn. Jos Suomesta ei löydy taloa, joka tekisi tämän järjestelmän fiksulla hinnalla, ehdotan että tilaamme järjestelmän virolaisilta. (Fakta tosin on, että löytyy – näitä ei vain huomioida tarjouskilpailuissa.)

Tietotekniikan ammattilaisena tiedän, että ei ole olemassa onnistunutta tietotekniikkaprojektia, joka maksaisi näin paljon. Jos tietotekniikkahankinnalle voidaan laittaa tällainen hintalappu – ja jos tilaaja sen hyväksyy – se osoittaa, ettei tilaaja itse tiedä mitä on tekemässä.

On toki olemassa poikkeuksia. Suunnitellulle terveydenhoitojärjestelmälle vetää hinnassa vertoja vain NASA:n avaruussukkulalentojen ohjelmistoprojekti.

NASAn avaruussukkula-ohjelmaan tehty ohjelmisto, PASS, oli eräs kaikkien aikojen tiukimmin testatuista ja virheettömimmistä tietokoneohjelmista, jota tehtiin 300 insinöörin voimin. Projektin kokonaishinnaksi tuli 500 miljoonaa dollaria. Tiukan testauksen ja laadunvalvonnan vuoksi ohjelmasta tuli 20 kertaa kalliimpi kuin keskiverto vastaavan kokoinen tietokoneohjelmisto: yhden testatun ja viimeistellyn, tuotantoon saadun koodirivin hinnaksi tuli 1000 dollaria verrattuna keskivertoon 50 dollariin. Käännettynä nykyrahaksi PASS-järjestelmän hinnaksi tulisi noin 2 miljardia dollaria – euroissa siis hieman vähemmän kuin suunniteltu potilastietojärjestelmä.

Emme ole tilaamassa avaruusohjelmaa. Jollei projektin todellisena tavoitteena ole lähettää sairaita ihmisiä Maata kiertävälle radalle, ei ole tilannetta jossa tällaisia summia tarvitsisi käyttää ohjelmistokehitykseen. Uskallan myös epäillä, olisiko parin miljardin hassaamisen jälkeen meillä oikeasti eräs kaikkien aikojen tiukimmin testatuista ja virheettömimmistä potilastietojärjestelmistä – todennäköisemmin tuloksena on luokaton läjä roskaa ja taas yksi kammottavalla tavalla epäonnistunut yhteisten rahojen tuhoamisjuhla.

Potilastietojärjestelmäprojekti on mietittävä uudelleen, tällä kertaa järkeä käyttäen ja ilman suurten konsulttitalojen ”apua”. Tämän hulluuden on loputtava.

Ps. (10.9) Jos haluat saada julkisiin it-hankintoihin järkeä, lue Potilastietojärjestelmän parantaminen: Mitä voin tehdä.

Päivitys 9/9/12: Korjattu NASA-esimerkissä aluksi mainittu Apollo-ohjelma oikeaksi eli sukkulaohjelmaksi.

Päivitys 10/9/2012: Tarkennettu, että 1,8 miljardia on koko maan potilastietojärjestelmien arvioitu kokonaissumma. Tästä toki leijonanosa menee pääkaupunkiseudun projektiin. 1,8 miljardia on joka tapauksessa aivan järjetön summa rahaa myös koko maan mittakaavassa.