Epic fail, eli sairaaloiden IT eilen, tänään ja huomenna

Kaikki nykyään tietävät, että terveydenhuollon IT-järjestelmät tulevat tuhottoman kalliiksi ja toimivat luvattoman huonosti. Erityisesti valtiontalouden tarkastusvirasto avautuu aiheesta säännöllisesti ja asiaa puidaan jo eduskunnassakin. Ylen sanoin, ”Terveydenhuollon it-hankinnoissa lähes kaikki on mennyt pieleen”

Mutta miksi on näin? Pieni tapausesimerkki ehkä valaisee tilannetta. Dickensin kolme aavetta johdattavat teemaan.

Ensin vuorossa menneiden IT-hankkeiden aave.

Helsingin ja uudenmaan sairaanhoitopiiri (HUS) on perinteisesti käyttänyt potilastietojärjestelmänään Uranusta (sama kuin Miranda). Sen kehittämisestä vastasi alkujaan Medici data oy, jonka viisi sairaanhoitopiiriä yhdessä omistivat. Yhtiöitettyä omaa tuotantoa siis. 2007 Medici data myytiin Logicalle (silloin WM-data) hintaan, joka salattiin.  Ratkaisun oli tarkoitus helpottaa järjestelmäintegraatioita, koska Logica teki runsaasti muitakin terveydenhuollon järjestelmiä. Alkuperäisessä sopimuksessa HUS sitoutui ostaman Logicalta päivityksiä 700 000 eurolla vuosittain 2012 asti. Todelliseksi kustannustasoksi kuitenkin muodostui 2-3 miljoonaa euroa vuodessa.

Nyt Uranuksesta ollaan luopumassa. Tavoiteltuja integraatiohyötyjä ei saatu, ja järjestelmän käytettävyydestä on tullut paljon valituksia. Koska sairaalaa ei kuitenkaan voi jättää tyhjän päälle, osti HUS vielä kolmen vuoden tuen ja pienkehityksen Uranukseen Logicalta. Hinta oli 15,7 miljoonaa euroa, eli yli viisi miljoonaa vuodessa. Osto tehtiin ilman kilpailutusta, koska vaihtoehtoja ei oikeastaan ole. Tietoviikon sanoin ”Hankinta on tehty ilman kilpailutusta, koska Uranus-potilastietojärjestelmä on Logican kehittämä ja yhtiö omistaa sen oikeudet.” Alkuperäisen kehitystyön toki maksoivat sairaanhoitopiirit.

Alalla toimivan lähteen arvion mukaan sopimuksen sisältämät työt olisi saanut ostettua markkinoilta noin miljoonalla per vuosi. Loput neljä miljoonaa kuluvat siis käytännössä siksi, että Logica on palvelun ainoa mahdollinen tarjoaja, ja voi hinnoitella työnsä kuten haluaa. Monopolimyyjän markkinat ovat tällaiset. (En väitä, että ne ovat kaikki katetta, vaan suuri osa tuhrautuu myös tehottomaan tai turhaan työhön).

Tähän mennessä siis on ensin koodattu järjestelmä itse, sitten myyty se, luultavasti lähes ilmaiseksi isolle IT-talolle. Iso IT-talo on nostanut hintoja ensin vähän ja sitten paljon, mutta pakko on maksaa koska toimittajalla on monopoli järjestelmäänsä. Laatu ei myöskään ole ainakaan parantunut vuosien varrella. On hyvin ymmärrettävää, että HUS haluaa luopua järjestelmästä.

Sitten kuvaan astuu nykyisten IT-hankkeiden aave

Uranuksen tilalle ollaan tuomassa uutta, kansallista yhtenäistä potilastietojärjestelmää. Sitra teetti Accenturella selvityksen kuinka Suomessa voitaisiin yhtenäistää terveydenhuollon potilastietojärjestelmät ostamalla ulkomailta valmis järjestelmä. Sirius-hankkeen projektipälliköt ja lähes koko projektiryhmä olivat joko HUSin tai Accenturen palkkalistoilla, vaikka muodollisesti hankkeen organisoi Sitra. Käytännössä ajatus on, että uusi järjestelmä tuodaan ensin HUSille ja sitten muualle maahan (sivumennen sanoen tämä on ihan järkevä tapa toimia, ei siinä mitään).

Selvityksessä parhaaksi järjestelmäksi todettiin amerikkalainen Epic ja toiseksi tuli myöskin amerikkalainen Cerner. Jatkotoimenpiteinä HUS aloitti Sirius 2 -hankkeen, jossa valmistellaan varsinaista järjestelmän kilpailutusta, ja Accenture hankki oikeudet myydä Epic-järjestelmää Suomessa (*).

Tässä kohti kannattaa taas pysähtyä hetkeksi. Olemme siis tilanteessa, jossa on konsultin avustuksella käytännössä päätetty, mikä järjestelmä tullaan valitsemaan. Samainen konsultti on nyt ainoa taho, jolta tuon järjestelmän voi saada. On siis Accenturen ehdotuksesta käytännössä päätetty, että potilastietojärjestelmät koko suomeen tulee toimittamaan Accenture.

Terveydenhuollon ATK-päivillä niin Accenturen kuin HUS:inkin edustajat löysi parhaiten Epicin tiskiltä. Lapussa lukee ”Olemme Epicin ständillä. Tervetuloa”

Ja kerrontavastuu siirtyy nyt tulevien IT-hankkeiden aaveelle

Seuraavaksi HUS kilpailuttaa potilastietojärjestelmän hankinnan syksyllä 2012. Accenture tarjoaa Epicciä, Logica tarjonnee Cerneriä. Muitakin varmasti osallistuu.

Accenture voittaa kilpailutuksen, ja alkaa viiden vuoden projekti, jossa Uranus korvataan Epicillä. Kahdeksan vuoden sisään kaikki muutkin suomen potilastietojärjestelmät korvataan Epicillä. Kustannuksiksi arvioidaan 1.2 – 1.8 miljardia euroa, josta 60% menee Accenturelle ja Epic Systemsille. Loput ovat sairaanhoitopiirien omia kuluja.

Alun jälkeen hankinnat tullaan tekemään ilman kilpailutusta; muita vaihtoehtoja ei oikeastaan ole. Epic-potilastietojärjestelmä on Epic Systemsin kehittämä ja Accenture omistaa sen jälleenmyyntioikeudet Suomessa.

Aiemmin HUS oli siis yhden monopolitoimittajan kuristusotteessa, ja tämä hyödynsi sitä laskuttamalla useita miljoonia vuodessa. Jatkossa koko maan sairaanhoitopiirit ovat yhden monopolitoimittajan kuristusotteessa, ja arvioitu kustannustaso on useita satoja miljoonia vuodessa. Siis monopolitoimittajan arvioima kustannustaso.

Tämäkin voisi vielä olla ihan ok. Nykyisestä katastrofista eroon pääseminen maksaa väistämättä paljon rahaa, teki sen miten tahansa. Jos yhtenäisellä ja toimivalla potilastietojärjestelmällä saadaan jatkuva koneiden odottelu ja turhien lomakkeiden täyttely sekä systeemin aiheuttamat hoitovirheet karsittua, on tämänkin potentiaaliset hyödyt jopa satoja miljoonia.

Olisin ihan valmis hyväksymään vaikka kymmenen miljoonan vuotuisen välistävedon, jos sen vastineeksi saataisiin toimiva sairaalajärjestelmä. Mutta miksi ihmeessä saataisiin? Todennäköisempää on, että se toimii suunnilleen yhtä hyvin kuin Uranuskin.

Julkiset kilpailutukset voitetaan sillä, että tarjottava järjestelmä on itsessään halpa. Usein tarjoukset tehdään jopa tappiolla. Tarjoava yritys tekee voittonsa lisä- ja muutostöistä, joiden hinta on kova. Ostaja ei tietenkään halua ostaa kalliita lisätöitä, vaan ostaa niitä ainoastaan jos on pakko.

Eli jos järjestelmä toimii hyvin, jäävät toimittajalta kalliit lisätyöt saamatta, mutta jos se on koko ajan katastrofin partaalla, tili juoksee. En väitä, että kukaan rikkoisi softiaan tahallaan, mutta olemme luoneet järjestelmän, jossa menestyvät lähinnä yhtiöt joiden järjestelmissä on kriittisiä ongelmia. Sitä saa mitä tilaa.

Ratkaisun avain onkin tilata toisin.

Potilastietojärjestelmän kaltainen suuri, monimutkainen ja erittäin kustomoitu tuote luo voimakkaan lock-in efektin. Asiakas on käytännössä täysin riippuvainen lähdekoodin haltijasta, joka voi sanella hintansa ja ehtonsa. Vaihtaminen toiseen järjestelmään vie vuosia ja maksaa kymmeniä miljoonia. Siksi asiakkaan on hallittava lähdekoodia itse.

Toimitusehtoihin on siis lisättävä, että sairaanhoitopiiri saa lähdekoodin hallintansa ja vapaat oikeudet ostaa kehitystyötä järjestelmään keneltä haluaa sekä jakaa tilaamiaan muutoksia muiden sairaanhoitopiirien kanssa. Eli Vaikka Accenture myy Epicin lisenssit HUSille (15% kustannuksista), ylläpito ja muutostyöt  (45% kustannuksista) voidaan tilata keneltä vain.

Parhaiten tämä onnistuisi vaatimalla avoimen lähdekoodin lisenssiä, mutta tärkeimmät hyödyt saadaan vaatimalla jatkokehitysoikeus vain itselle. Välttämätöntä on kuitenkin rikkoa yhden toimittajan monopoliasema. Välttämätöntä on katkaista se kuristusnaru, jolla suuret IT-talot sairaanhoitopiirejä hallitsevat.

On mahdollista, että nykyiset tarjoajat eivät halua lähteä tällaiseen kisaan mukaan, mutta viime kädessä järjestelmän voi vaikka tehdä tyhjästä. Jos käytettävissä on viisi vuotta ja miljardi euroa, sillä oikeasti tekee jo aika paljon koodia. Potilastietojärjestelmät ovat monimutkaisia, mutta ei niiden niin monimutkaisia tarvitse olla. Monopolitoimittajan intressissä on aina tehdä järjestelmästä monimutkaisempi; asiakkaan hallitsemassa IT:ssä näin ei olisi pakko olla.

Koodin omistus tai avoimuus ei ole mikään hopealuoti, joka ratkaisee kaikki IT-hankkeiden ongelmat. Vaikka asiakas omistaisi kaiken koodin, hankkeet voidaan silti mokata. Mutta irtautuminen toimittajan liekanarusta on välttämätön edellytys sille, että hankkeet voivat onnistua.

Terveydenhuollon tietojärjestelmäongelmat ovat ratkaistavissa, mutta ne eivät ratkea ilman muutosta toimintatavoissa.

(*) Accenture on ainoa tiedetty Epicin myyjä Suomessa, ja on syytä olettaa, että sopimus antaa heille yksinoikeuden. Varmaa tietoa tästä ei minulla kuitenkaan ole.

94 thoughts on “Epic fail, eli sairaaloiden IT eilen, tänään ja huomenna”

  1. Liitetään tähän vielä julkisen hankinnan aave. Toisin tilaaminen olisi tärkeää myös, koska tilaaja ei ole meedio. Toimittajat laskuttavat mielellään kalliisti lisätöistä ja tähän koriin satavat myös sen speksin muutokset, jonka perusteella tarjous on tehty. Ja koska se speksi on huono arvaus siitä mitä projektissa tapahtuu helmikuussa 2014 niitä muutospyyntöjä tulee paljon.

  2. Olen samaa mieltä, että 1) tehdään avoimella lähdekoodilla, 2) perustetaan oma firma, joka käyttää ne arvioidut 1 miljardia euroa tämän kehittämiseen. Sitten sitä tuotetta voidaan myydäkin muihin maihin eikä vaan rahoiteta muiden IT-tahojen osaamista ja tuotekehitystä.

  3. Yksi ongelma on myös se, että järjestelmät on rakennettu kammottavien legacy-viritelmien päälle, eikä niitä osaa käytännössä ylläpitää kuin kourallinen vanhoja guruja. Erityisesti potilasjärjestelmien kanssa ongelmana on osuvasti nimetty MUMPS-ohjelmointikieli (mumps = sikotauti), johon myös Epic pohjautuu, ja jonka suunnittelussa pyrittiin aikoinaan mahdollisimman tiiviiseen koodiin.

  4. Alan ammattilaisena tiedän kuinka kyseiset järjestelmät toimivat ja millaisesta työmäärästä olisi kyse jos tehdään vastaavanlainen järjestelmä puhtaasti uusimmilla arkkitehtuureilla ja menetelmillä niin määräksi tulee suunilleen 24 000 työtuntia ja hinta on arviolta 1.6milliä. Noin 4-5kk kuluttua pitäisi olla toimiva paketti, kevyt versio. Tämä siis täysin alan parhaiden tekemänä ja testaamiset yms. mukaan luettuna. Siihen päivitykset yms. bugi fiksit päälle niin karkeasti arvioiden 0.5milliä vuotta kohti. Kunhan vain pääsis noihin kilpailutuksiin mukaan niin sais tehdä aikamoisen katteen – Siis yksi projekti ja miljoona tulot 🙂

  5. Itsellä on opinnot pitkälle IT:n puolella ja rahakkaan konsultin paikka melkein varma. Todellisuudessa en halua olla missään tekemissä näiden rosvoyhtiöiden kanssa. Pienen yritykset tai aivan muunlainen tulevaisuus odottavat minua. Pienen Suomen soisi olevan ketterän kehityksen ja järkevien päätöksien maa. Sitten koko maa rampautetaan Accenturen lipunmyyntisoftilla ja kohta lopullisesti uudelle entistä paskemmalla sairaalasoftalla.

    Ja voi perkele voi olla vaikeita kuvia, ihmisyyteni todistamiseksi…

  6. Komppaan anonyymiä yllä, sillä varauksella että siitä kun itse tutuistin pintapuolisesti potilastietojärjestelmiin on aikaa. Eli mikä niissä nyt on niin monimutkaista?

    Korjatkaa jos olen väärässä, mutta kyseessä on mun käsittääkseni pohjimmiltaan suhteellisen yksinkertainen tietovarasto. Tietenkin jos siihen rupeaa rakentamaan jotain ERPin tapaista päälle, niin saa siitä joo monimutkaisen, mutta miksi pitäisi tehdä noin?

  7. Mistä tulee mieleen yksi lainsäädännöllinen hack jota joskus piruuttani pohdin:

    Lain mukaan sinulla on oikeus sinua koskevaan rekisteridataan, ml. potilaskertomus. Rekisterinpitäjän pitää muistaakseni vastata kirjallisesti niin kuin paperi puolen vuoden sisään.

    No muutetaan toi niin että tunnistautuneen käyttäjän, esim. TUPASilla, tulee saada välittämästi sähköisessä muodossa rekisteritiedot itsestään avoimesta rajapinnasta. Sivutuotteena integraatio-ongelmat on pakko ratkaista.

  8. Aamen!

    Voi olla, että ministeriöissä ja sairaanhoitopiireissä istuu päättävissä asemissa jo liian vanhaa väkeä, jotka eivät hahmota miten tällaisena avoimen lähdekoodin ja web-sovellusten aikakaudella IT-hankintoja tulee toteuttaa. Sovelluskehitys on nykyään edullisempaa ja tehokkaampaa, kuin koskaan aiemmin transsistorielektroniikan historiassa.

    1. Ministeriössä ja joka tasolla sairaalatietojärjestelmissä on vahva keski-ikäisyyden leima. Samoin kuin koulutetut ja gurut puuttuvat. Jokaisella on lupa haluta omaansa …paras hallintakeino tässä olisi diktatuuri.
      Myös ikävä kulttuuri tee mahdollisimman vähän niin et tee virheitä on vallitseva.

      nimim. useamman eri tietojärjestelmän projektiin osallistunut.

  9. No niin, keneen otan yhteyttä ja mitä sanon, jotta tällainen viesti menisi perille päättäjillekin? Laaja pommitus saattaisi purra, jos se kohdistuisi oikeisiin tahoihin.

    Koodaamisesta mitään ymmärtämättömänä, mutta paskan softan kanssa päätäni seinään hakanneena soisin, että nämä haamut saataisiin haudan lepoon.

    1. Tätä minäkin kysyisin. Miten saadaan estettyä paskan järjestelmän käyttöönotto, joka myös maksaa maltaita? Hirvittää tämmöinen, miten näitä rahoista ja päätöksistä vastaavia voidaan viedä kuin pässiä narussa. Kreikan rahoituskin on ollut pakko olla hyvä idea, koska se toteutettiin, mutta missä todisteet sen järkevyydestä. Oliko sekin vaan iso huijaus, kuten tämäkin vaikuttaa olevan. IT-alan kestämätöntä kehitystä – rahaa ei tule ikuisesti palavasta hehkulampusta.

  10. Edelliseen on pakko lisätä että myös Logica koostuu lähinnä henkilöistä joilla ei ole lainkaan teknistä kompetenssia tietotekniikasta, ja joiden läsnäolo tietotekniikka projektissa jo sinällään takaa epäonnistumisen, tosin epäonnistumisen aste saattaa vaihdella. Jos puhutaan oikeista asioista, eli hoitohenkilökunnan ja it suunnittelijoiden yhteistyöstä, joiden tuloksena teoriassa tälläinen hyvin toimiva järjestelmä voisi syntyä, niin tälläistä yhteistyötä ei ole näköpiirissä. Ja näin ollen ei ole hyvin toimivaa järjestelmääkään.

  11. Disclaimer: En tiedä asiasta mitään, ja olen töissä KPMG:llä (osin Accenturen kilpailija) tietoturva-asiantuntijana.

    Minusta tärkeintä tässä olisi ”tietorakenteet” eikä ”koodi”. Eli ihan ensimmäiseksi järjestelmän käyttämät tietokannat ja verkkorajapinnat tulisi määritellä niin, että ne on helppo toteuttaa useammallakin ohjelmisto- ja kantatuotteella tarvittaessa. Tällaisen määrittelyn voisi tilata ja kilpailuttaa. Verkko-API voisi olla hierarkinen, matala- ja korkea taso erikseen. Kannat voisivat olla piilotettu niin, että niiden hajautukseen ja teniikkaan (SQL, noSQL) jää vaihtoehtoja.

    Tässä kohtaa voisi miettiä myös avoimuustarpeita. Esim. tilastoanalyysi siitä, miten terveydenhuolto toimii tehokkaasti voisi olla netti-APIssa tarjolla. Samoin siellä voisi olla julkinen API Vetuma-SAML-tunnistetulle käyttäjälle omiin tietoihinsa netissä.

    Kantarakenteet, master data ja APIt (esim. RESTful tai WS) kuntoon ja softariippumattomiksi! Jokainen projekti pitäisi aloittaa siitä.

    Sitten siitä voisi tilata jonkinlaisen pienen toteutuksen ja siihen päälle Proof-of-concept -tyyppisen kevyen sovelluksen.

    Sen jälkeen voitaisiin sitten alkaa kilpailuttaa ja rakentaa tuotantovaiheen softaa moduleittain, ja ostaa sitä vaikka eri paikoista. Osa voisi olla Javaa, osa .NETiä, osa vaikka mitä esim. ihan vaan että nähtäisiin, mikä toimii, ja varmistettaisiin että verkko-APIt todella pysyvät teknologiariippumattomina.

    1. Tuohon tapaan minäkin kysymystä lähestyisin, jos pitäisi nyt alkaa tyhjästä suurta tietojärjestelmää kehittää. Mutta ei ole minullakaan riittävää kokemusta sairaalajärjestelmistä, että osaisin kaikki erityiskysymykset ratkaista lonkalta.

      Varmasti erilaisia käyttöliittymiä ja integraatioita tarvittaisiin enemmän kuin äkkiseltään luulisi, eli kyllähän siitä jonkun kokoinen projekti väistämättä tulisi.

    2. Uskoisin, että aika hurja parannus nykytilanteeseen saataisiin jo sillä, jos järjestelmä suunniteltaisiin alusta asti niin että käyttöliittymä keskustelee taustajärjestelmän kanssa selkeästi dokumentoidun rajapinnan kautta, niin että käyttöliittymä voidaan tehdä vaikka kokonaan uusiksi ilman että tarvitsee koskea taustajärjestelmiin. Suuri osa sairaanhoitohenkilökunnan työajastahan hupenee juuri kelvottoman käyttöliittymän kanssa tappelemiseen ja sitten saadaankin lukea siitä, miten käyttäjiä ohjeistetaan olemaan painamatta rivivaihtoa hengenvaarallisten virheiden välttämiseksi: http://www.laakarilehti.fi/uutinen.html?opcode=show/news_id=12029/type=1

      Jos käyttöliittymä olisi irroitettavissa taustajärjestelmistä, järjestelmän käyttäjät voisivat teettää muutaman kymppitonnin pikkuprojekteina omiin tarpeisiinsa sopivia käyttöliittymäratkaisuja suhteellisen ketterästi. Totta kai myös sillä on välilä mitä tietokantapuolella ja muualla taustalla tapahtuu, mutta ei it-ihmisenä kuvittelisin, että sen puolen tekniset haasteet ovat kertaluokkaa suurempia kuin UI:n puolella.

  12. Siitähän se kaunis soppa syntyy, kun sekä tilaajan että toimittajan puolella on asioista päättämässä henkilöt, joilla ei ole minkään valtakunnan teknistä kompetenssia hankittavan järjestelmän suhteen. Saatikka, että suostuisivat kuuntelemaan henkilöitä jotka asiasta jotain oikeasti ymmärtävät.

    Paljonko lisäkustannuksia tulee pelkästään siitä, ettei tilaaja ole osannut speksata järjestelmän vaatimuksia oikein/riittävän laajasti?

    1. Juuri speksauksen ongelmathan ovat keskeisessä roolissa. Tietojärjestelmä on organisaation toiminnan ja sen hallinnan ydin. Kysymys siitä, mitä tietojärjestelmällä voi ja ei voi tehdä on samalla kysymys siitä, mitä organisaatio voi ja ei voi tehdä.

      Vaatimusmäärittely on vaikea optimointitehtävä, jossa pitää tasapainottaa tarpeita, kustannuksia ja toimintatapoja keskenään. Onnistuneissa isoissa tietojärjestelmähankkeissa otetaan määrittelyssä aina kantaa myös toimintatapoihin ja niiden muuttamiseen. Olen nähnyt sitäkin, että vaatimusmäärittelytyöpajassa asiakas toteaa, että bisnesmalli menikin uusiksi. Vähän pienempi yritys tosin…

      Erityisesti terveydenhuollossa vaatimusmäärittelyjen ongelmana on, että
      1) Asiakkaan edustajat eivät usien ymmärrä softasta ja tietojärjestelmähankkeista juuri mitään
      2) Toimittajan intresseissä ei ole tehdä hankkeesta helppoa ja halpaa, vaan päin vastoin mielummin kallis ja vaikea.
      3) Ihmiset, joilla olisi valtaa päättää toimintatapojen muutoksista, jotta tietojärjetslemästä saataisiin toimivampi eivät osallistu ollenkaan.
      4) Seurauksena kukaan ei ohjaa vaatimuksia rajattuun ja hallittavaan muotoon, vaan niiden annetaan paisua massiivisiksi
      5) Bonuksena toteutus tehdään usien vesiputoushenkisesti, eli vaatimukset naulataan kiveen ennen kun työt alotetaan.

    2. Terveydenhuollon organisaatiossa tälläinen osallistuminen tietojärjestelmä projektiin voi olla myös palkinto hyvin tehdystä työstä. Eli pisimpään mukana olleet saavat mahdollisuuden edetä työurallaan. Tässä teille iso ongelma, mukan on harvemmin niitä jotka joutuvat seuraavat 20 vuotta tehdyn ratkaisun kanssa elämään. Myös työn uudelleen organisointi ja rohkeus nähdä asioita toisin ei aina ole palkitsevaa tässä järjestelmäkulttuurissa

    3. Noin tekninen lähtökohta ei auta. Pitää tietää MITÄ järjestelmän tulee tehdä ja MITEN. Järjestelmän toimittaja ei voi sitä tietää ja se onnistuu vain kysymällä käyttäjiltä. Valmista tsydeemiä ei ole olemassakaan ja periaatteessa on sama, millä sen toteuttaa. Ostamiseen kuuluu OMAN ostajaporukan jatkuva evaluointi SEKÄ mm. järjetelmätoimittajien yritysten toimitatapojen ymmärtäminen. Siihen tarvitaan sekä sisällöntuotannon, tekniikan, talouden, sosiologian että johtamisen osaamista (ostajalta). Ja liiketoiminnan lainalaisuuksien, ymmärtääkseen, miksi j-toimittaja tarjoaa mitäkin, sen takana on aina raha. Ja loppujen lopuksi ostaja tavitsee jääräpäisyyttä viedäkseen läpi tarpeelliset näkemykset, eikä laitetoimittajan esityksiä

  13. Arvioidut kustannukset 1.2 – 1.8 miljardia. Mitä jos tietojärjestelmä korvattaisiin ihmisillä, lomakkeilla ja paperarkistotilalla ? Paljonko se tulisi maksamaan ?

  14. Vilkaisin ton Accenturen selvityksen läpi. Mites muiden ammatillinen intuitio, kun mulla vilkuttaa punaista kun katon sitä toiminnallisuuskarttaa (sivu 23)? Kyllä mä ymmärrän mikä tuossa houkuttaa, koska integrointi on hankalaa, mutta silti. Jos tommoiseen lähtee on parempi olla oikeasti varma että se softa kanssa pelittää noissa kaikisssa laatikoissa sekä raudanluja soppari, ja siltikin en kyllä välttämättä lähtisi. Mä en muuten ymmärrä mitä tässä yhteydessä tarkoittaa skaalautuvuus.

    http://www.sitra.fi/NR/rdonlyres/F693B202-E4F2-4998-A652-018890A4ED22/0/Sirius_Potilastietojärjestelmäkartoitus.pdf

  15. Voisiko joku asiaa ymmärtävä valaista tiiviisti, mitä tuollainen potilastietojärjestelmä tyypillisesti käsittää? Siis millaisia eri osia siinä on ja mitä kaikkea sillä pitää voida tehdä?

    Ja ennen kaikkea: pitääkö se todellakin rakentaa itse, eikö voi ostaa valmiina mistään?

  16. Kaikki näyttää helpolta kun katsoo tarpeeksi etäältä.

    Valtion tarkastusviraston taannoinen moite liittyi hankkeisiin, jossa laadittiin kansallisia standardeja ja rajapintoja terveydenhuollon tietojärjestelmien yhteensovittamiseksi.
    Tästä kertovassa MOT-ohjelmassa kuulijalta meni sekaisin miljoonat ja miljardit ensi minuutilla ja olemattoman huomion sai, että siinä oikeasti puhuttiin noin 1,2 miljoonan euron kuluista 10 vuoden aikana. Mitä se nyt on; reilu 100 000/vuosi, eli ei yhtään mitään.
    Suomen parhaat asiantuntijat ovat tehneet lähes talkootöinä kansainvälisiin standardeihin pohjautuvat kansalliset sovellukset moniin keskeisiin yhteensopivuutta lisääviin tarpeisiin. Tämän työn tulokset ovat avoimesti saatavilla ja hyvin laajassa käytössä tänään kaikessa HL7-sanomaliikenteessä, Aluetietojärjestelmissä, eReseptissä, koodistopalvelussa, jne.

    Uranus-tuoteperhe on siis tullut tiensä päähän. Se ei ole mikään ihme, sillä se perustuu (liian) monikerros arkkitehtuuriin ja 1980 keksittyihin tekniikoihin, joista kaikki muut ovat luopuneet jo kauan aikaa sitten.
    Uranus tukee huonosti kansallisia standardeja tai vaikka Logica väittäsi jotain tuetun, niin tuki on oikeasti puutteellinen. Uusimmassa versiossa on sentään eResepti-tuki.

    Oleellista on sen [arkkitehtuurin] kyvyttömyys mukautua uusiin tarpeisiin palveluihin ilman että se merkitsee isoa suunnitteluprojektia ja koko tuotteen uutta versiota ja uuden version mukana tuomaa raskasta ja hidasta testaus- ja käyttöönottoprojektia.
    Esimerkiksi Uranuksen ensimmäinen Webservices-palvelu on ollut tarjolla nyt vasta vähän aikaa, mutta sen laajentaminen nykyisestä on heti liian iso ja kallis projekti. Nykyisillä työkaluilla tällaiset rajapinnat ja niitä tukevat ratkaisut voidaan toteuttaa päivässä — usein tunneissa. Nyt pelkän työmääräarvio saamiseen Logicalta menee nopeimmillaan kaksi viikkoa.

    Maailma menee siitä ohi ja on syytä etsiä ratkaisua, joka mukautuu helpommin ja jatkaa mukautumista hamaan maailman tappiin.

    Sirius 2-hanke etsii nyt ratkaisua joka kattaisi HUS:n koko alueen erikoissairaanhoidon, sosiaalipalveluiden sekä perusterveydenhoidon tarpeet. Tämä on kiinnostava avaus ja lähikunnat ovat kaiketi jo suostuneet tähän yhteistyöhön.
    Ansiokasta on ainakin siihen liittyvissä juhlapuheissa esille tuodut tavoitteet lähteä liikkeelle prosesseista ja niiden kehittämisestä. Tämä on hitaampi mutta ehdottomasti parempi tie.

    Missään tapauksessa tähän ei löydy valmista ratkaisua vaan HUS:n ja toimittajan on löydettävä konsensus monessa kohtaa. HUS on tunnettu siitä, että kompromisseja ei tehdä. Suuret kansainväliset ohjelmistotalo taas sanovat että ”tämä kelpaa näin Kanadalle, miksei siis Suomelle?”.

    Oli miten oli, niin avain löytyy avoimista rajapinnoista ja siitä että kuinka helposti niitä voidaan toteuttaa sekä toisenlaisesta projektityöskentelystä, jossa asioita tehdään avoimesta ja ratkaisuhakuisesti.

    On liioiteltua sanoa että kaikki on mennyt pieleen. Meillä Suomalaisilla on vain omituinen tarve liata omaa pesää ja unohtaa että olemme terveydenhuollon tietotekniikan mallimaa monen kansainvälisen asiantuntijan silmissä.

  17. Minä olen itse töissä julkisella sektorilla ja edustan myös Accenturen asiakasta (tai tavallaan se asiakas on Suomen valtio, minä vain edustan asiakasta). Minusta Accenture on tässä toiminut törkeästi. Selvitys olisi pitänyt teettää sellaisella puolueettomalla konsulttiyrityksellä, joka ei sitten tule itse olemaan mukana kilpailutuksessa. Tai sitten Accenturen kanssa olisi pitänyt sopia, että he ovat itse jäävejä osallistumaan kilpailutukseen. Tämä on mielestäni todella törkeää. Olen itse töissä valtion organisaatiossa, missä suurimman osan IT-järjestelmistä valtio itse omistaa. Sitten niiden kehitys ja ylläpito kilpailutetaan ja toimittajaa voidaan tarvittaessa vaihtaa. Avointa koodia käytetään ainakin siinä mielessä, että käytetään avoimen koodin ohjelmistokomponenttaja. On myös huonosti tehtyjä ratkaisuja, missä on pakka ostaa jotain yhdeltä toimittajalta (Oraclelta) ja maksaa mitä ne vaan kehtaavat pyytää. Mutta tämä on mielestäni virhe ja pitäisi korjata, jos itse voin vaikuttaa, se tullaan tulevaisuudessa korjaamaan.

  18. ”Sitten koko maa rampautetaan Accenturen lipunmyyntisoftilla ja kohta lopullisesti uudelle entistä paskemmalla sairaalasoftalla.”

    Tasapuolisuuden nimissä on sanottava, että aika iso osa maasta on rampautettu Tiedon kotimaisilla tuotteilla. Maksuliikenne taasen on juuttunut SAPpiin, monesssa muussakin paikassa kuin uutisissa keikkuneissa Helsingin kaupungin virastoissa.

  19. Kannattaa muuten vilkaista Mikko Huovilan gradua ”Avoimen lähdekoodin ohjelmistoprojektit terveydenhuollossa”.

    Pätkä yhteenvedosta:

    Mihin terveydenhuollon tietojärjestelmien haasteisiin avoin lähdekoodi voi vastata? Tämän tutkielman pohjalta voidaan sanoa, että avoin lähdekoodi ei ole mikään yksittäinen taikatemppu, jolla kaikki ongelmat korjautuvat. Pikemminkin on niin, että avoin lähdekoodi antaa mahdollisuuksia tehdä tiettyjä asioita toisin. Luvussa 3.4 esitellyistä ongelmakohdista valtaosa on sellaisia, että ne eivät ole riippuvaisia koodin avoimuuteen liittyvistä asioista, vaikka joitain yhteyksiä näihin eri alueisiin löytyykin.

    Tämän tutkielman keskeisenä tuloksena on, että avoimen lähdekoodin käyttämisessä terveydenhuollossa on keskeistä vallan siirtyminen ohjelmistoyrityksiltä järjestelmien käyttäjille ja kehittäjille. Lähdekoodin muuttuminen julkishyödykkeeksi tarkkaan varjellun liikesalaisuuden sijaan tarkoittaa suurta muutosta sen suhteen, kenellä on valta päättää siitä, mitä ohjelmistoon otetaan mukaan ja miten sitä kehitetään. Itse asiassa avoin lähdekoodi johtaa siihen, että kuka tahansa voi tehdä muutoksia ja kehittää koodia haluamaansa suuntaan. Tämä ei kuitenkaan tarkoita sitä, että koodista käännettyjä ohjelmia käytettäisiin terveydenhuollon organisaation sisällä kontrolloimattomasti. Käytännössä kehittämistavan muutos ei todennäköisesti näkyisi suurimmalle osalla loppukäyttäjistä juuri lainkaan. Kyse onkin ennen kaikkea siitä, että terveydenhuollon organisaatioiden valta ohjelmistojen kehittämisessä vahvistuu merkittävästi, ja ohjelmistoyritysten liiketoimintalogiikka joutuu väkisin mukautumaan tähän muutokseen. Omisteisessa mallissa käyttöoikeuksien myynti ja ohjelmistotuotteiden monistaminen ovat keskeiset liikevoiton lähteet. Avoimessa mallissa ohjelmistoyritysten rooli on myydä työpanosta ja erilaisia avoimen lähdekoodin tuotteiden ympärille luotuja palveluja terveydenhuollon organisaatioille.

    http://epublications.uef.fi/pub/urn_nbn_fi_uef-20110076/

  20. ”Missään tapauksessa tähän ei löydy valmista ratkaisua vaan HUS:n ja toimittajan on löydettävä konsensus monessa kohtaa. ”

    Kuitenkin EPICiä myydään ikäänkuin valmiina ratkaisuna: lisää vain miljardi euroa ja se on toimiva suomeen.

    Valmiiden suljettujen järjestelmien käyttö on ihan ok (windows, exchange, jne), mutta tämän sirius hankeen kaltaisia ”räätälöidään suljetun järjestelmän päälle” ratkaisuja pitäisi välttää ruton lailla.

    Tämän hankeen pahin ongelma ei kuitenkaan ole hinta tai räätälöinti, vaan nimenomaan se, että se estää kilpailuttamisen terveydenhuollon it-hankinnoissa seuraavan vuosikymmenen ajaksi.

    1. Ison organisaation keskeinen tietojärjestelmnä ei KOSKAAN ole käytännössä valmistuote, vaan se on pakko räätälöidä. Kyse on yksinkertaisesti siitä, että organisaatiot eivät ole toistensa kopioita, joten eivät niiden tiedot ja tietotarpeetkaan ole.

      Ja tosiaan oman titojärjestelmän täytyy isossa organisaatiossa olla omissa näpeissä. Muu on veren kerjäämistä nenästään.

  21. Anonyymi8.6.2012 15.26.00
    “Voisiko joku asiaa ymmärtävä valaista tiiviisti, mitä tuollainen potilastietojärjestelmä tyypillisesti käsittää? Siis millaisia eri osia siinä on ja mitä kaikkea sillä pitää voida tehdä?”

    En väitä tuntevani potilastietojärjestelmiä täydellisesti mutta sairaanhoitajana työskennellessäni seuraavanlaisia tehtäviä tietojärjestelmillä tehtiin, Uranuksen ollessa kyseessä vaihtelevalla menestyksellä ja uskomattoman hitaasti:

    Potilastietojärjestelmässä tulee olla potilaan henkilötiedot ja kontaktitiedot. Henkilötietojen tulisi olla yhteydessä maistraatin vastaaviin järjestelmiin. Jolloin uusienkin potilaiden osoitetiedot ovat valmiina olemassa kutsun lähettämistä ja peruutusajoista ilmoittamista jne. varten. Alaikäisten lasten kohdalla järjestelmään pitäisi päivittyä myös vanhempien tai muun laillisen huoltajan vastaavat tiedot.
    Henkilötietojen ollessa kyseessä pitäisi olla mahdollista myös osoite/puhelinnumeroiden suojaus. Eli siis mikäli henkilöllä on salattu osoite tai salattu puhelinnumero näiden näkymistä pitäisi pystyä rajoittamaan ainoastaan hoitavien yksiköiden nähtäviksi ja niin että osoitetietoa hakeva henkilö varmasti tietää hakevansa salattavaa tietoa. Kätevintä tämä jaottelu olisi mielestäni niin, että päivystyksellistä hoitoa antavat saavat salattavat tiedot näkyville potilaan sisäänkirjaamisen yhteydessä ja muut yksiköt lähetteen tullessa mikäli potilas on antanut siihen luvan. Esimerkiksi tuossa Uranuksessa tämä on hoidettu sillä että hoitajat kirjottavat CAPS LOCK päällä jonkin vapaamuotoisen kommentin jonnekin henkilötietosivulle ja kuitenkin kaikki tunnusten omaavat henkilöt pystyvät katsomaan tietoja.
    Toisaalta yksiköiden pitäis pystyä kirjoittamaan omia lisätietoja henkilötietolomakkeille. Esimerkiksi kuuron ollessa kyseessä, jossakin pitäisi pystyä ilmaisemaan että potilaalle ei kannata soittaa puhelimella.
    Potilastietojärjestelmässä tulisi olla potilaskertomus erikoisalan lehtineen. Eli ne käyntitiedot mitkä lääkärit käynnistä kirjoittelee omille erikoisalan lehdilleen. Myös näissä tiedoissa pitäisi pystyä toisaalta rajamaan käyttäjiä. En tiedä tarvitseeko vastaanottovirkailijan esimerkiksi korvaklinikalla välttämättä käydä katsomassa sukupuolitautien poliklinikan kertomuksia. Toisaalta mikäli potilaalla on esimerkiksi jokin vakava tarttuva tauti tai vaikka paha sydänvika täytyisi keskeiset tiedot näistä olla kaikilla hoitavilla tahoilla päästävissä. Uranuksessa on kaikki ollut esillä ja tiedon rajoitukset ovat olleet tunnusten omaavien henkilöiden oman omantunnon asia.
    Potilastietojärjestelmässä tulisi olla hoitajien kertomukset käynneiltä. Nämä ovat perinteisesti olleet eri paikassa kuin lääkärien kertomukset. Samalla päivälle pitäisi pystyä tekemään useampia merkintöjä eri henkilöiden toimesta. Ja käynti/vuorokertomuksista ei tulisi olla ainakaan kovin helppoa toisen kirjoittaman tekstin muokkaaminen.
    Potilaan ollessa osastolla tulisi olla jonkin sellainen peruslomake jonka näkemään pystyisi sekä hoitaja että lääkäri. Tämä lomake voisi olla erilainen esimerkiksi tehohoidossa olevalle potilaalle, tavallisella vuodeosastolla olevalle potilaalle, leikkaussalissa toimenpiteetssä olevalle potilaalle ja säännöllisillä poliklinikka käynneillä olevalle potilaalle. Lomakkeelle pitäisi pystyä kirjaamaan esimerkiksi veren happipitoisuuden arvoja, lämpötiloja, painoa, pituutta jne. Näitä ei esimerkiksi Uranus järjestelmässä ollut mitenkään järkevällä tavalla saatavilla ja usein osastoilla oli omia paperisia lomakesysteemeitään edelleen käytössä. Uudet mittarit esimerkiksi osastoilla olevat monitorit osaavat jonkunverran säilyttää viimeaikaisia trendejä esimerkiksi verenpaineesta. Ihannetilanne varmaankin olisi, jos kaikki hankittavat uudet laitteet olisivat pienellä työllä yhdistettävissä potilastietojärjestelmiin, joilloin idioottimaiset “Katso tältä ruudulta arvo jonka kirjoitat käsin tälle koneelle jäisivät pois”.

    1. Saksalainen terveystietojärjestelmäasiantuntija Bernd Bloebl on tokaissut, että puolet suurten terveystietojärjestelmien tuotantokustannuksista liittyvät tavalla tai toisella säädöksistä tuleviin tietoturvavaatimuksiin. Näitä Santrakin tässä hieman meille valotti.

    2. Ainakaan sukupuolitautien polin ja psykiatrian tekstit eivät näy ilman erillisiä oikeuksia Uranuksessakaan. Ihan näin btw.

  22. Potilastietojärjestelmässä tulee olla myös tapa komminikoida esimerkiksi laboratorioiden järjestelmien kanssa. Eli laboratoriolähetteen kirjoittaminen, tulosten selailu ja jonkinlainen merkintä että tilaava henkilö on tulokset kuitannut nähneeksi. Samoin röntgenosastoiden järjestelmien kanssa pitäisi pystyä tekemään samaa.
    Järjestelmässä tulisi olla ajanvarausjärjestelmä joka on yhteydessä laskutusjärjestelmään. Lisäksi tietysti pidenpään on tainnut olla mietinnän alla mahdollisuus kutsua ihmisiä ajalle sähköisesti. Tässä jarruttaa lait, koska esimerkiksi sähköposteja ei luokitella tarpeeksi turvallisiksi tavoiksi terveydenhuollon ottaa asiakkaaseensa yhteyttä.
    Osastoilla tulisi olla jokin osastokohtainen näkymä, joka olisi yhteydessä osaston hoitajakutsujärjestelmään. Nämä ovat nykyisin vielä usein omia järjestelmiään.
    Kokonaisuutta pitäisi pystyä katsomaan osasto, klinikka tai jopa sairaalakohtaisesti, jotta hallinnolle saataisiin tilastodataa esimerkiksi hoitajien määrän ja työn jakautumisesta. Nämä järjestelmät ovat myös usein ainakin osittain erillisiä. Kaikki erilliset järjestelmät yleensä vain kuormittavat hoitohenkilökuntaa lisää, joten potilasjärjestelmässä sisällä olevat ns.tehokkuuden laskemistavat voisivat olla käytännössä parempia. Tietysti tähän voisi olla hyvä lisätä jokin automaattinen tapa myös hakea työvuorojärjestelmistä jokaisen vuoron henkilökuntatilanne.
    Utopiaa taitaisi olla jonkilainen potilasjärjestelmä joka olisi mahdollisesti yhteudessä myös potilaaseen. Eli siis sellainen tarpeeksi turvallinen kanava, jossa potilaat saisivat itse pyytää omia sairaskertomuksen osia ja esimerkiksi mahdollistaisi etänä potilaan ja hoitohenkilökunnan kommunikoimisen (koska sähköposti se ei voi olla). Olen itseasiassa miettinyt sellaista että olisi kauhean fiksua jos olisi järjestelmä johon voisin astmaatikkona käydä laittamassa omat pef-mittarilukemani flunssan yhteydessä ja asmahoitaja voisi niitä siitä selata ja tarvittaessa antaa lääkityksen lisäysohjeita tai mikäli tilanne pahenee pyytää käymään. Ja olisiko aivan kamalaa järjestelmä missä työterveyslääkäri vuosittain kyselisi vointia, painonkehitystä, liikkumista jne. Ja moittisi etänä jos ei ole ehtinyt tarpeeksi lenkkipolulle tai pyytäisi vastaanotolle mikäli normaalipainoinen aikuinen olisi laihtunut yllättäen.

    1. Nämä kaikki ovat kyllä varsin peruskauraa, joiden toteuttamisessa ei sinänsä pitäisi olla teknisesti mitään ihmeellistä. En ole terveydenhoitoalalla, mutta saatan kuvitella, että juridiset ja turvavaatimukset mutkistavat asioita, mutta ei tuon silti miljardia pitäisi maksaa.

      Teknisiä ongelmia syntynee pikemminkin kuvamateriaalin (magneettikuvaukset sun muut nykyajan ihmeet) ja juurikin mainituista laitteista saadun datan liittämisessä potilaskertomukseen.

      Eri käyttäjien pääsyä dataan voidaan nykymaailman systeemeillä säätää hyvinkin hienojakoisesti, eikä tämän pitäisi olla ohjelmistokehittäjille mikään ongelma. Käyttöoikeuksien myöntäminen eri työntekijöille ja niiden pitäminen ajan tasalla on tietysti riippuvaista ihmisten välisistä sopimuksista ja käytännöistä, jossa tulee eteen joku rajankäynti hienojakoisuuden ja työläyden välillä. Ts. lukuoikeuden säätäminen joka tiedonmurulle erikseen on liian hankalaa ja tässä tapauksessa vaarallistakin, toisaalta pitäisi olla mahdollista rajoittaa pääsyä osaan potilaskertomusta.

      Tuo, että jonkun kirjoittamia merkintöjä ei muut pääse jälkikäteen hävittämään, on aivan perusominaisuuksia monissakin tietokannoissa ja versionhallintajärjestelmissä, jotka tallentavat kaikki muokkaustapahtumat niin, että dokumentin versioita voi kelata ajassa taaksepäin ja nähdä, kuka teki minkäkin muutoksen. Näinhän toimii esim. Wikipedia ja moni muu.

    2. Hyvä selvitys Sandralta. Muutama kommentti:
      ”Potilastietojärjestelmässä tulisi olla potilaskertomus erikoisalan lehtineen.” Mielestäni jätit erikoisalat hieman vähälle huomiolle. Erikoisalojen tiedot tulee suojata erikoisala kohtaisesti. Kuitenkin näihin tietoihin pitää päästä käsiksi myös muun henkilökunnan erilaisissa hätätilanteissa (liikenneonnettomuus jne.). Joissakin järjestelmissä tämä on toteutettu erityisellä lokilla, johon lääkärin on pakko kirjoittaa syy, miksi tieto avataan. Jälkikäteen tällaiset ”pakkoaukaisut” on jäljitettävissä helposti ja kusessa on jos selkeää syytä avaamiselle ei löydy. Erikoisalat asettavat myös paljon erilaisia vaatimuksia järjestelmälle. Esim kotihoidossa on erilaiset vaatimukset (reittisuunnittelu, mobiililaitteet jne.) kuin vaikkapa hammashuollossa (hammaskartat jne.). Nykyisin erikoisalat käyttävät paljon erillisiä järjestelmiä, koska ei ole ollut yhtä järjestelmää joka taipuisi kaikkiin tarpeisiin. Oleellista onkin, että näkymät ja toiminnallisuudet ovat pääkäyttäjien muokattavissa ilman koodaamista. Järjestelmässä on UI komponentti hammaskartalle ja toinen reittisuunnitteluun. Näitä komponentteja pääkäyttäjät voivat käyttää missä tahansa UI näkymässä tarpeen tullen. Kovakoodatut näkymät ovat ollutta ja mennyttä.

      ”Lomakkeelle pitäisi pystyä kirjaamaan esimerkiksi veren happipitoisuuden arvoja, lämpötiloja, painoa, pituutta jne” Ja ennen kaikkea tiedo tulee tallentaa erillisiin kenttiin eikä kertomustekstin sekaan. Näin mittaustuloksista voidaan tehdä grafiikoita ym. myöhemmin. Jälleen lomakkeita ei tarvitse tehdä kovakoodattuna, vaan käyttäjä voi ottaa esim. valikosta ”Lisää uusi mittaus –> verenpaine”.

      Merkittävä työ/kulu potilaskertomusjärjestelmässä on erilaiset integraatiot ja sitä varten järjestelmässä tulee olla kattavat integraatiotyökalut. On Kela, vakuutusyhtiöt, labrat, rtg, mittalaitteet, erp jne. jne. Osa on kansainvälisiä standardeja, osa taas Suomeen tehtäviä lokalisointeja (huom. ei räätälöintejä).

      ”Utopiaa taitaisi olla jonkilainen potilasjärjestelmä joka olisi mahdollisesti yhteudessä myös potilaaseen.” Ei ole utopiaa lainkaan. Yksityisellä sektorilla näitä löytyy jo. Googlella löytyy esim. hakusanalla ”omahoito”.

  23. Itsekkin tietotekniikan ammattilaisena olen hyvinkin samaa mieltä bloginkirjoituksen sekä Anssin ja Juuson kommenttien kanssa.

    Ohjelmistotalot ovat kaupallisia yrityksiä ja osaavat hyvin tehdä julkishallinnolle tarjouksia. Jos niille tarjotaan mahdollisuus tehdä tarjous lock-in periaateella niin eivät ne nyt rahasta kieltäydy. On toki selvää että kun hankkeesen sisältyy mahdollisuus tehdä ylläpitoa ja jatkokehitysä ilman kilpailutusta ja vapaasti hinnoitellen, voidaan projektin hinta vetää tarjouksessa alta todellisetn kustannusten. Se voitto tulee sitten jatkossa korkojen kanssa takaisin.

    Eräässä suuressa yrityksessä toimivana tiedän jos asiakas alusta alkaen vaatii toteutusta avoimen lähdekoodin pohjalta, sitä myös tarjotaan ihan samojen yritysten toimesta jotka myyvät julkishallinnolle suljetun koodin lock-in projekteja.

    Nämä yritykset hoitavat yhteiskuntasuhteensa erinomaisesti valmisteleviin virkamiehiin ja tuloksena tarjouspyynnöt tehdään niin että lock-in on onnistuu. Poliittisilla pättäjillä taas ei ole riittävää toimialatuntemusta ja rohkeutta kyseenalaistaa virkamiesten ja konsulttien valmistelemaa esitystä.

    Poliittisten päättäjien pitäisi suoraan asettaa vaatimukseksi tarjouksiin että julkisin varoin toeutettu ohjelmisto tulee olla avointa lähdekodia. Tämä takaisi että kaikki jatkoylläpito ja kehitys voidaan myös kilpailuttaa. Kun yhteiskunta kuitenkin maksaa kulut niin sen tulee myös omistaa tulos. Toki, varmaan senkin jälkeen moni ohjelmistotalo yrittää ujuttaa lock-in ansaa sopimukseen vetoamalla että se käyttää omistamaansa valmista osakokonaisuutta ja tällätavalla tarjoaaaaaaaa muka edullisempaa hintaa.

    Tärkeää on avoin lähdekoodi, tietokannt, rajapinnat ja protokollat. Avoimilla rajapinnoilla ja protokollilla vidaan erottaa toisistaan sovelluksen eri osat kuten tietokantaa pyörittävä ydin ja käyttäjien koneissa pyörivät asiakassovellukset. Tarvittaessa eri osia sovelluksista voidaan uusia riippumattomasti eikä koko järjestelmää jouduta uusimaan kerralla. Asiakassovellusten järkevä elinkaari on myös paljon lyhyempi kuin tietokannan.

    Avoimella koodilla taas voidaan varmistaa että kaikkien osasovellusten jakokehitys voidaan avoimesti kilpailuttaa.

    Mikäli järjestelmässä joudutaan käyttämään jotain suljettua osakokonaisuutta kannattaa se aidata avoimien rajapintojen taakse jolloin koko järjestelmään ei tule lock-in:iä.

    Valitettavan usein julkishallinnon sovellukset kärsivät myös huonosta käytettävyydestä. Taho, joka on paras mahdollinen suunnittelemaan tietokantajärjestelmiä ei välttämättä oleparas käytettävyyssuunnittelussa.

    1. Pitäisikö pistää käyntiin nimenkeruu kansalaisilta lakialoitteeseen että julkisella rahalla teetettävä tietojärjestelmä pitää toteuttaa avoimen lähdekoodin periaatteella, mikäli järjestelmän toteutuneeksi hinnaksi tulee yli 5 miljoonaa euroa. Poislukien puolustus, rajavalvonta ja KRP. Eli niin että tarjouksentekijä joutuu sitoutumaan vapauttamaan koodin avoimeksi mikäli loppusumma ylittää 5 miltsiä.

      -Topi Rinkinen

  24. Huoh. Mistähän sitä edes alkas. No otetaan epic alkuun
    1) Brian Ahierin (Jenkkiläinen Health-IT guru) google plus threadissä on varsin mielenkiintoista jutustelua tästä järjestelmästä.
    https://plus.google.com/u/0/102493891906301577447/posts/UGrzsUPgv4B
    Pointteja tuolta
    – ”technology is old and laughable outside”(=MUMPS)
    – ”Epic doesnt even interoprate with Epic & there;s no such thing as a standard install”

    Eli meillä on siis järjestelmä joka on suljettu ja jonka interoperability on. No sitä ei ole. (Kaiser Permanantella oli vissiin vaikeuksia sovitella eri yksiköitään yhteen jossa käytettiin Epiciä)

    2) Käytettävyys. Tämähän on kuulemma tärkeimpiä kriteereitä sille uudelle valittavalla järjestemälle.
    Nyt vaan joka tuutista tuuppaa lahden takaa kuinka noiden EHR/EMR 1.0 (Epic,Cerner) käyttävyys on ihan kuraa (http://www.healthdatamanagement.com/issues/20_2/ehr-electronic-health-records-user-unfriendly-43946-1.html?zkPrintable=1&nopagination=1)

    Ja toisaalta jos käyttäjien/lääkäreidein piti osallistua tämän projektin käyttävyydeen määrittelyyn, niin mitä se oikein tapahtuu kun ostetaan ”valmista”?

    Jostan myös kantautu korviin että Epic Ipad käyttöliittymä oli hurmannut Suomalaisia alan ihmisiä. Really? http://itunes.apple.com/us/app/epic-canto/id395395172?mt=8

    Summa summarum; Vanha järjestelmä halutaan korvata koska sen kallis, käytettävyys olematon ja yhteensopivuus on mitä on. Otetaan tilalle Epic, ja saadaan kallis järjestelmä, jonka käytettävyys on huono ja yhteensopviuus on mitä on. Kuullostaa melko win-win jutulta?

    1. Älä nyt. Eräässä julkisessa laitoksessa haluttiin korvata kökkö sovellus uudella. Saatiin yhtä kökkö, ja lopputulemana heillä on nyt käytössä molemmat sovellukset, ja samat tiedot pidetään yllä molempiin.

  25. Morjes,

    Kommentoin laajemmin täällä:
    http://blogit.tietokone.fi/ossi/2012/06/kivekkaan-eeppinen-tarina-terveydenhuollon-itssa-tulossa-miljardiluokan-moka

    Bottom line: en usko avoimeen lähdekoodiin näin laajassa järjestelmässä. Ja Kivekäs on väärässä siinä, että suurten talojen tietojärjestelmät eivät olisi tuotepohjaisia. Ovat ne. Nykyään suuri työ on nimen omaan siinä, että siirrytään pois näistä itsetehdyistä liian suurista räätälöinneistä.

    1. En täysin ymmärrä, mitä nyt tarkoitat tuotepohjaisella. Ovathan nykyisetkin sairaaloiden IT-järjestelmät tuotteita (Uranus, Effica jne). Keskeinen osa ongelmaa on, että ne ostetaan juurikin tuotteina, eli könttähinnalla lisenssi ja ainoastaan tuotteen omistaja voi tehdä muutoksia.

      Avoin lähdekoodi ei tässä ole ydinasia. Ydinasia on Vendor lock-innin välttäminen. Oman koodin tilaaminen avoimena on tähän yksi tapa, mutta ei ainoa.

      Tilaajan pääsy kaikkien tietojärjestelmän ydinkomponenttien koodiin ja oikeus tilata niihin muutoksia keneltä haluaa sen sijaan on käytännössä välttämätöntä, jotta lukkoefekti vältettäisiin. Tässä kun nyt ei ole kyse mistään SAP:sta, vaan huomattavasti sitä vähemmän tuotteistetusta ratkaisusta.

      Vastasin laajemmin oman blogisi puolelle.

    2. En aivan ymmärrä mitä tarkoitat nyt tuotepohjaisella. Ovathan nykyisetkin potilastietojärjestelmät (Uranus, Effica jne) tuotteita. Keskeinen osa ongelmaa on juurikin, että ne ostetaan ikään kuin valmiina tuotteina, eli lisenssiä könttähinnalla (vuosihinnalla) ja tuotteen omistaja on ainoa joka voi sitten tehdä kustomointia.

      Voidaan toki ajatella, että esimerkiksi EPIC valmiimpana ja modernimpana tuotteena sopisi vähemmällä kustomoinnilla vaikkapa HUSin käyttöön. Mutta kuinka uskottavalta kuulostaa, ettei amerikkalaista järjestelmää tarvitsisi kustomoida? Terveydenhuoltoalan toimintakenttä on sielä melko erilainen. Myös mainittu SIRIUS-selvitys arvioi ostettavan kustomointityön osuudeksi kustannuksista noin 45%, eli 0,5 – 0,8 miljardia.

      Open source ei ole tässä ydinasia. Vendor lock-innin välttäminen on. Kehityksen tilaaminen avoimella lisenssillä on tähän yksi tapa, mutta ei ainoa.

      Sen sijaan tietojärjestelmän keskeisten osien lähdekoodin saaminen tilaajan hallintaan niin, että kehitystyötä voidaan ostaa mistä halutaan, on välttämätöntä toimittajalukon välttämiseksi. Kyse ei kuitenkaan ole mistään SAP:stä vaan huomattavasti vähemmän tuotteistetusta järjestelmästä.

  26. Sitten vielä sananen tästä Suomen Epic-toimittajasta Accenturesta. Tarjouspyynnöissähän pyydetään aina referenssit vastaavanlaisista toteuksista. Minkähänlaisena referenssinä toimii Accenturen toiminta Brittien(NHS) suuressa Healthcare-IT uudistuksessa vuosina 2003-2006? Kyseessähän oli mammuttinen 10-vuotinen ja miljardeja maksava hanke, josta acce sitten kesken kaiken vetäyty.
    http://newsroom.accenture.com/article_display.cfm?article_id=4061
    http://www.ft.com/cms/s/0/17f8065a-4e69-11db-bcbc-0000779e2340.html#axzz1xOJ3Cdbw

    Luotettava kumppani?

  27. Forbesissa melko mielenkiintoinen juttu noista Epiceistä ja cernereistä;
    http://www.forbes.com/sites/zinamoukheiber/2012/04/26/will-cerner-epic-and-allscripts-continue-to-dominate-health-it/

    – “It’s clear to me that these EHRs we are rolling out today are version 1.0. In the next five years, we’ll see someone leapfrog to bring us to the next generation that mimics the workflow of doctors and nurses,”

    Jenkeissähän puhaltaa avoimuuden tuulet tuon health datan suhteen tällähetkellä. Todd Park (Jenkkien uusi CTO); http://gov20.govfresh.com/todd-park-on-unleashing-the-power-of-open-data-to-improve-health/

  28. Kyllähän nuo rahasummat hirvittävät. Itse seuraan hyvinkin läheltä tapahtumia noiden kanssa, ja esim. Uranus ei ole ulkonäöllisesti, eikä edes toiminnallisesti, niin hirvittävästi kehittynyt sitten Medici Datan aikojen. Purkkaa purkan päälle, ja koodista voi bongata monesta kohtaa vielä MD-tekstiä 🙂 Kannattikohan sitä silloin myydä? Siihen tuhlatuilla rahoilla ”oma” yritys olisi kehittänyt vaikka kahden hengen voimin tuota kymmenessä vuodessa paljon pidemmälle kuin mitä Logica on nyt saanut aikaiseksi.

    Vielä olisi ESKO vaihtoehtona, siihen ei tarvitse miljardeja upottaa että siitä saisi hyvin toimivan vempeleen…

    Ja tässä kohtaa tulee mieleen se eräs tarina Suomen Kuvalehdestä, jossa kerrottiin Sitran/tms kilpailuttamasta www-portaalista. Hinta-arvioksi oli laskettu miljoon(i)a, ja kahdelle loppusuoralle pääseelle yritykselle annettiin 5000e ja viikko aikaa tehdä niin toimiva järjestelmä kuin mahdollista. Paremmin suoriutunut pääsisi siis kiinni miljoonaprojektiin. No, kun viikon jälkeen alettiin tutkia tuotoksia, kumpikin yritys oli 5000 eurolla tuottanut jo lähes valmiin järjestelmän jossa oli surin osa vaatimuksista täytetty…

    1. Hei anonyymi! Vastasin meillä Sitrassa tuosta mainitsemastasi Sitra.fi-projektista ja ajattelin että okaisen nopeasti pari pikku juttua että voidaan jatkaa tätäkin kiinnostavan keskustelun käännettä faktapohjalta.

      Sitra.fi-kilpailutuksessa oli tosiaan viimeisen kierroksen kahdelle tarjoajalle yhden viikon koesprintti, jonka tarkoituksena oli kyllä toteuttaa lopputulosta niin pitkälle kuin mahdollista mutta ideana oli demottaa tarjoajien ehdottaman teknologian, projektimetodien ja konsepti-idean toimivuutta (ei niinkään saada lopullista saittia ja sen työkaluja mahdollisimman pitkälle). Koska Sitra.fi tehtiin agilesti, meillä oli tuossa vaiheessa lopulliseen nähden hyvin rajattu kehitysjono ja homma oli vielä monessa suhteessa ilmassa.

      Molemmat koesprintissä mukana olleet saivat viikossa kasaan prototyypin jossa oli vaikuttava määrä toiminnallisuutta, mutta tosiaan tuossa oltiin todella prototyyppiasteella verrattna lopputulokseen. Esim. käytetty Drupalin versio vielä vaihtui koesprintin jälkeen suhteessa voittaneen tarjoajan protoon.

      Tuon toimittajavalinnan jälkeen vasta alkoi varsinainen konseptisuunnittelu, arkkitehtuurisuunnittelu ja kehittäminen. Meillä oli ratkottavana mm. integroituminen sosiaalisen median sisältövirtoihin ja taustajärjestelmiimme, vasta alalle tullut responsiivisuuden idea vastauksena suunnittelemiselle mobiiliin, ylläpitotyökalujen kehittäminen paljon käyttäjälähtöisemmäksi kuin Drupalissa lähtökohtaisesti on jotta Sitran ihmiset myös ottaisivat järjestelmän käyttöön omassa verkkojulkaisemisessaan jne. jne. Keräsimme kehitysprojektin läpi myös paljon käyttäjäpalautetta jotta saimme lopputuloksesta varmasti eri käyttjäryhmien tarvetta vastaavan, julkaisimme mm. tätä varten palvelun betaversion oikeaan käyttöön n. kaksi kuukautta projektin alkamisen jälkeen. Näin päädyimme kehittämään monia juttuja ikään puoleentoista kertaan (ensimmäinen versio – palaute – kehittäminen eteenpäin) saadaksemme lopputuloksesta kerralla osuvan.

      Sivuston ja sen työkalujen suunnittelu ja toteuttaminen maksoi lopulta n. 600 000 euroa. Koko projektin läpi tehtiin tavallista parempaa laatua, koska projektin lopputulokset tehtiin myös muiden kuin Sitran jatkojalostettavaksi. Metoditulokset on julkaistu projektiblogiin https://opencorporatesite.posterous.com/, projektista syntyneitä moduuleita on Drupalin sandboxissa ja koko saitin lähdekoodin julkaiseminenkin on työlistalla. Ideana oli siis kerrankin ottaa investoinnista irti muillekin kuin järjestelmän tilanneelle organisaatiolle.

      Mutta siis niin tai näin, tarjouskilpailun ja viikon koesprintin jälkeen olimme voittaneen toteuttajan kanssa tosi hyvässä yhteisymmärryksessä projektin tavoitteista ja toteutustavasta, eli huikea hyöty siitä oli. Eikä kakkoseksi jääneellekään jäänyt pettymyksestä huolimatta kamalan paha maku suuhun: http://www.aucor.fi/blogi/sitra-mita-jai-kateen

      Jatketaan hyvää keskustelua!

      Karoliina / Sitra

  29. Saako tässä tuo käsite ”avoin lähdekoodi” nyt kohtuuttomasti huomiota, vaikkei se itse asiassa asian kannalta edes ole välttämätön. Se mitä potilastietojärjestelmään tarvitaan ovat avoimet rajapinnat ja tietomallit (kuten tietokantarakenteet). Lisäksi on mahdollisimman pitkälti tukeuduttava julkishallinnon yhteisiin tietosisältömäärityksiin (JHS-suositukset).

  30. Tarpeen olisi jaksottaa hankinta edes kahtia. Ensin määrittelyprojekti, joka määrittelisi riittävän määrän palikoita, joista kokonaisuus rakennetaan, ja AVOIMET rajapinnat niiden väliin. Tätähän ei nyt siis ole edes yritetty, siinähän mukamas-selvittäjä olisi sahannut omaa Epic-oksaansa.

    Seuraavassa vaiheessa tarjouspyynnöt toteutusprojekteihin JULKISTEN HANKINTOJEN YLEISESTÄ KÄYTÄNNÖSTÄ POIKETEN siten, että myös osatarjoukset otetaan huomioon: kuka tahansa voi tarjoutua tekemään yhden tai useamman pikku palikan määriteltyihin rajapintoihin.

    Sitten palikoiden hankinnassa pitää unohtaa myös aiemmat referenssit (näitä kun ei kukaan pysty osoittamaan tehneensä kertaakaan kunnolla!) ja muut räätälöidyt keinotekoiset rajoitteet (”saman alan liikevaihtio vähintään miljardi per vuosi”).

    Olisihan se tietysti kiva olla itse se, jolle haluttaisiin kaataa miljardi rahaa. Saisin sillä varmasti palkattua muutaman kymmentä oikeasti kovaa kollegaa vaihtamaan firmaa ja tekemään tuon eläkeprojektin (ei enää tarvitsisi miettiä kuka maksaa eläkkeet sitten joskus :-).

  31. On myös yksi perustavaalaatua oleva kysymys mikä kannattaisi ehdottamasti muistaa/ottaa huomioon.

    Amerikkalaispohjaiset järjestelmät ovat alunperin suunniteltu potilaan/vakuutusyhtiön laskuttamisen näkökulmasta. (http://www.govhealthit.com/news/5-reasons-ehr-functionality-hasnt-changed-1982, http://www.kevinmd.com/blog/2012/02/emr-dirty-word-doctors.html). Tästä seuraa se että potilaan näkökulma on unohdettu lähes kokonaan. Ja ei sitä järjestelmää päivittäin käyttävää hoitohenkikökuntaakaan kovin hyvin ole kuunneltu.

    Mielestäni tässä olisi tuhannen taalan paikka Suomalaiselle tietoyhteiskunnalle rakentaa avoin health 2.0 järjestelmä, jossa on huomioitu nuo sudenkuopat. Tekijöiksi uusia/nuoria kasvoja terveydenhuollosta, koodaus ja ux maailmoista. Ja sit vielä niin että oikeasti lean vääntö päälle from day 1 (=ei vuosikausia määrittelyihin, stragegiansuunnitteluun yms). Olen varma että vuoteen 2016, jolloin tuo uusi järjestelmä pitäisi olla HUSissa käytössä, meillä olisi aikamoiset palikat käsissä.

  32. @Karri Niemelä (ja muut). Olen täsmälleen samaa mieltä. Ehdottomasti paras vaihtoehto olisi perustaa riittävän suuri ja varakas ( mieluiten julkishallinnollinen yksikkö) yritys, jossa on ainoastaan modernia ketterän kehittämisen osaajia. Tämä tulisi suunnitella ja toteuttaa kattava Suomen terveydenhuollon kokonaisjärjestelmä alusta alkaen. Kaikkein kammottavin vaihtoehto on jukin vanha ja vanhaan teknologiaan perustuva pohja, jota sitten epätoivoisesti yritetään tunata onnistumatta siinä. Voi hyvin tarvittaessa mainita nimeltä Suomesta ainakin 3 – 4 tällaista hanketta, joissa tappiot varmasti ylittää 100 milj €.

    Tämän kaiken estää (kuten tästä artikkelista ja siihen liittyvästä keskustelusta hyvin käy selville, Suomen oligokarkkinen muutaman IT -mammutin monopoli. Tämän menestymisen ehtona on ( ja ainakin on ollut) ostajan lähes täydellinen ammattitaidottomuus ja sisäpiireihin liittyvä suomalaistyyppinen ”hyvä veli” korruptio.

    Tässä vielä oma blogikirjoitukseni asiasta:

    http://itkritiikki.wordpress.com/2011/10/12/suomelle-hyva-terveydenhuollon-tietojarjestelma-halvalla/

  33. Todella hyvä kirjoitus ja erinomaista kommentointia. Oli ilo lukea ja jakaa linkkiä eteenpäin.

    Olen itse pääasiassa käyttöliittymäsuunnittelija, melko laajalla kokemuksella muustakin. Tämä aihe, eli järkyttävät ongelmat julkisissa hankinnoissa, on kiinnostanut minua jo pidempään.

    Alkuperäisessä kirjoituksessa ja aiemmissa kommenteissa tulikin jo esille oikein hyviä ratkaisumalleja tämän hankinnan tärkeimpiin ongelmiin, sekä sopimusten että teknologian kannalta. Sammon jakama MUMPS-linkki oli muuten erityisen huvittava. Mitä tulee taustajärjestelmiin, kieliin ja muihin teknologiavalintoihin, niin olisi varmasti paljon järkevämpää katsoa tulevaisuuteen kuin 1960-luvulle:

    http://en.wikipedia.org/wiki/MUMPS

    Loppukäyttäjien kokeman laadun kannalta taustajärjestelmillä ei ole niin väliä, mikäli vaan ne toimivat oikein eivätkä rampauta käyttöliittymää. Suurin kritiikki asiakkaan puolelta kohdistuukin juuri näiden järjestelmien onnettomaan käytettävyyteen.

    Väitän, että myös käytettävyysongelmat olisivat triviaaleja ratkaista. Miljardin euron kustannuksista voitaisiin varmaan ihan hyvin käyttää esimerkiksi kymmenestuhannesosa siihen, että palkattaisiin pari taitavaa käyttöliittymäsuunnittelijaa puoleksi vuodeksi suunnittelemaan järjestelmän keskeiset osat, ennen kuin niitä lähdetään toteuttamaan. Tai vielä paljon mieluummin ennen kuin edes valitaan toimittajia, saati taustajärjestelmiä. Tai ehkäpä tähän suunnittelupuoleen voitaisiin käyttää vaikkapa tuhannesosa kustannuksista, jolloin voitaisiin palkata esimerkiksi 20 taitavan suunnittelijan tiimi tekemään samat asia erittäin huolellisesti.

    On sinänsä kiinnostavaa, että tämänkin hankinnan yksittäiset ongelmat suhteellisen triviaaleja ratkaista. Jopa näin crowdsourcing-tyyliin, ilman merkittäviä kustannuksia. Mutta miten tämäkin hankinta saadaan sitten mokattua ihan järjettömillä kustannuksilla? Varmaan siten, ettei asiakas osaa vaatia mitään konkreettista, jolloin järjestelmän toimittajien etu on tuottaa mahdollisimman kallista paskaa. Väitän, että ongelmana on ainoastaan hankkijoiden epäpätevyys yhdistettynä tarjoajien epäeettisyyteen. Muut ongelmat olisi jokseenkin helppo ratkaista.

    Erityisen ikävän tästä asiasta tekee se, että hankinnan mokaamisella on vaikutusta veronmaksajien kukkaron lisäksi ihmisten terveyteen ja hoitohenkilökunnan hyvinvointiin. Mikäli tämä hankinta tehtäisiin kunnolla, niin rahojen pois lahjoittamisen ja entistä huonomman järjestelmän sijaan uudistuksen tuloksena voisi olla esimerkiksi satojen miljoonien säästöt, merkittävä helpotus hoitohenkilökunnan työhön ja potilaiden turvallisuuden varmistaminen.

    Mutta ehkäpä tällaisen projektin tavoitteet pitäisi asettaa useaa kertaluokkaa korkeammalle kuin kestämättömien ylläpitokustannusten karsimiseen ja kestämättömän huonon käytettävyyden korjailuun?

    Jos homman hoitaisi oikein hyvin, niin tuloksena olisi lisäksi järjestelmä, joka mahdollistaa esimerkiksi tilastotietojen keräämisen erilaisista kansanterveydellisistä ongelmista ja auttaisi sitä kautta ennaltaehkäisemään terveysongelmia, mikä puolestaan edistäisi ihmisten hyvinvointia ja vähentäisi julkisen terveydenhuollon kustannuksia huomattavasti enemmänkin.

    Avoimen arkkitehtuurin ja avoimien rajapintojen määrittelyn jälkeen monet eri tahot voisivat kehittää vaihtoehtoisia ratkaisuja eri ongelmiin. Niistä voisi vaikka sitten kuoria kerman päältä. Miljardilla eurolla voitaisiin vaikkapa saattaa hyvään alkuun tuhat terveydenhuollon tietojärjestelmien eri osia kehittävää startuppia.

  34. Otan tässä esiin yhden kohdan jota ei monetkaan näytä näissä kommenteissa huomioineen: lainsäädännön ja viranomaisten terveydenhuollon ohjelmistoille asettamiin vaatimuksiin, ja tässä erityisesti terveydenhuollon ohjelmistojen CE-merkinnästä.

    CE-merkintä
    vaaditaan nykyään kaikilta uusilta käyttönotettavilta ohjelmistoilta ja vanhojen ohjelmistojen uusilta versioilta. Ilman merkintää sovellusta ei saa käyttää.

    Merkinnän saamisen edelletyksenä on erittäin tarkkaan määriteltävä määrittely-, suunnittelu-, dokumentointi-, toteutus- ja testausprosessi jonka tulee täyttää tiettyjä vaatimuksia. Prosessi on auditoitava tarkoitukseen hyväksytyllä auditoijalla. Muuten tuotteelle ei merkintää myönnetä.

    Asiaa koskeva laki Finlexissä: http://www.finlex.fi/fi/laki/ajantasa/2010/20100629. Tosta voi aloittaa, suoraan lakitekstistä ei käytännön vaatimukset ja tulkinnat tietenkään selviä.

    Nämä vaatimukset eivät sellaisenaan estä esimerkiksi open source -ohjelmistojen käyttöä tai kehitystä, mutta asettaa niille melkoisia vaatimuksia. Lisäksi kaikki suunnittelu- ja toteutusfilosofiat eivät välttämättä ihan helpolla istu lain vaatimuksiin.

  35. Hyvä pointti, eli lainsäädöntö/asetukset on otettava huomioon tällaisia järjestelmiä tehdessä.

    EUssa on käytössä lääkelaitedirektiivi (93/42/EEC) joka asettaa vaateita tuon softan tekemisen suhteen. Vaateina mainittakoon tässä laadunvarmistaminen(=saavutetaan iso13485 standardin avulla), riskienhallinta(=iso14971), prosessi(=iec62304), käytettävyys(=iec62366)

    Ja toki, alkuun nämä kaikki voivat tuntua melkomoisilta, jopa ahdistavilta lean-näkökulmasta. Mutta yksinkertaistaen tarkoitus on vain pyrkiä siihen että tehdään laadukasta softaa, laadukkailla menetelmillä ja jossa on mietitty riskejä/riskienhallintaa etukäteen/aktiivisesti. Ja vieläpä niin että käyttäjä/käytettävyys on otettu huomioon suunnitellussa.

    Todettakoon vielä että
    1) Jo nyt tehdään medical device softaa agile menetelmillä.
    2) Open-source ei ole este sertifioinnille. Esimerkkinä vaikka tämä PACS/RISssi; http://clearcanvas.ca/dnn/Home/News/tabid/196/EntryId/65/Worlds-first-ISO-13485-certified-open-source-RIS-PACS.aspx

  36. Miljardilla tekee ehkä noin 10 tarpeet täyttävää ratkaisua crätchistä.

    Ehkä tässä kannattaisi lähteä siitä, että todellinen alan ammattilainen tulisi katsomaan paikan päälle, mitä oikeasti tarvitaan.

    Sitten tehtäisiin alustava vaatimusmäärittely.

    Iteroitaisiin.. jne jne

    Toi kuulostaa ihan sanalta joka alkaa ku……

  37. Jaaha. En usko sen enempää ketterien menetelmien kuin agility-harrastajienkaan teknologiauskon meitä tältäkään kuluerältä pelastavan. Aito avoimuus ei rajaa tekniikoita muodin mukaan (nuo enempi ja vähempi ketterät menetelmät on keksitty eri markkinpointinimillä niin moneen kertaan ainakin 60-luvulta alkaen.)

    Mutta tuo lakipommi oli kyllä muistutus kuolevaisuudesta. Kuka ryhtyisi pelastamaan meitä tuollaiselta akreditoitujen testauslaboratorioiden suojelemiselta lailla ja asetuksella, siis purkamaan näitä älyttömiä lakeja, jotka kyllä käytännössä estävät minkään start-upin pääsyn mukaan. Myöskään palastelu ei taida onnistua samasta syystä.

    Blääh, olisiko jossain vielä sivistysvaltio, jonka lakikirja olisi todellakin lakikirja, eikä 127 hyllymetriä puolisalaisia säädöksiä? Harkitsisin sinne muuttamista…

    1. Aika hauskaa sinänsä, että firma joka akkreditoi labroja suomessa (nimeä en mainitse), pääsi otsikoihin koska talousihminen kavalsi muutaman millin rahaa ja pelasi kasinolla.

      Onkohan ne akkrediotu akkreditoimaan ?

  38. Tänään 15.6. ilmestyneessä 3T-lehdessä sivulla 8 on juttu ”Accenturen rooli kiistanalainen”, jossa lainataan blogin kirjoittajaa Accenture-asiassa. Jutusta:

    ”Accenturen viestintäpäällikön Hetta Huittisen mukaan yritys ei edusta Epicin tuotteita Suomessa.
    Lisäksi jutun mukaan Accenturella ei ole mitään roolia epävirallisena järjestelmäpilottina toimivan HUS:in järjesetelmän määrittelyssä; lähteenä HUS:in hallintoylilääkäri Lasse Lehtonen.

    1. Kyseisessä jutussa myös tituleerattiin minua kaupunginvaltuutetuksi. Pyysin kyllä jutun nähtäväksi etukäteen voidakseni korjata virheet, mutta toimittajalle tuli ilmeisesti liian kiire.

      Ylläolevan voi lukea kommentaarina jutun muustakin laadusta. Ei kyse ole siitä, ”edustaako” Accenture HUSia, vaan siitä ovatko he tarjoamassa sitä HUSille. Tähän asti ovat olleet tarjoamassa.

      Eikä kyse ole siitä, onko Accenture mukana Sirius 2:ssa (ei ole, kuten HUSin edustajakin sanoo), vaan siitä että Accenture toteutti Sirius-hankkeen yhdessä HUSin kanssa, kuten hankkeen raporteista voi lukea.

      Mutta yhden palstan lehtijuttuun ei toki mahdu kaikkea, joten siihen kirjoitetaan sitten se mitä toimittaja siihen haluaa.

  39. Accenture on tilintarkastusyhteisö Arthur Andersenista eritynyt konsulttiosasto. Arthur Andersen luopui toimiluvastaan v. 2002 ns. Enron-skandaalin takia. Enron asetettiin konkurssiin 20.11.2001 ja konkurssin taustalla oli pitkällinen, huolellinen ja institutionaalinen kirjanpitorikoskokonaisuus.

    Kirjoitin 1990-luuvulla tilintarkastajien kaksoisroolista Kauppalehdessä liittyen Suomen pankkitukikäytäntöjen yhteydessä. Enronin tapauksessa tämä kansainvälisen tilintarkastustoiminnan riski jysähti yleiseen tietoisuuteen Yhdysvaltain suurimpana konkurssina.

    1. Arthur Andersenin toimistolla ristiinleikkaavat paperisilppurit kävivät kuulemma terät punaisena hohtaen, kun tietyt ”kirjanpitorikosepäilyt” vahingossa ”pullahtivat” pinnalle. Accidenturella ei ole mitään tekemistä entisen Accident Andersenin kanssa.

  40. Kiitos herätyksestä – sen seurauksena Hesarikin toi asian julkisuuteen. Toivottavasti asiaa selvitetään hieman pidemmälle.

    Alkuperäisessä Sirius raportissa selvitettiin Accanturen johdolla ulkolaisia vaihtoehtoja nykyisille järjestelmille – tietoisesti siinä ei selvitetty kotimaisia eikä eurooppalaisia vaihtehtoja. Selvitykssä mukana olevat järjestelmät valittiin Accenturen ohjauksesta ja johdatuksesta.

    Selvityksen yhteydessä Accenture havaitsi merkittävän hankepotentiaalin, päätyi suosittelemaan Epic-pärjestelmää ja käynnisti samalla neuvottelut Epicin kanssa järjestelmän myymiseksi Suomeen. Näppärä veto ”puolueettomalta” konsulttiyritykseltä.

    Lähes välittömästi Accenture käynnisti mittavan markkinointiponnistuksen, jossa he esittelivät Epiciä sairaanhoitopiireille ja päättäjille. He käyttivät Sirius – hankkeen ”puolueettoman” konsultin mandaattia päästäkseen esittelemään ja suosittelemaan Epic-järjestelmää.

    Ollaan tilanteessa, jossa HUS ja Helsinki aikovat käynnistää hankintaprosessin heti sen jälkeen kun Accenture on ennättänyt markkinoida ja esitellä Epic-järjestelmää jo vuoden verran – ei siinä mitään, mutta samanlaista mahdollisuutta ei ole annettu muille kandidaateille. Päättäjien mielet on täytetty Accenturen Epic-sanomalla.

    Asiaa on lobattu Accenturelle palkatun entisen pääministerin valtiosihteerin toimesta; Helsingin kaupungin sosiaali- ja terveystoimen johdossakin kuuluu olevan sukulaisuussiteitä Accenturen johtajistoon.

    On lähes mahdotonta enää käynnistää tasapuolista hankintakilpailusa – lain kirjainta ei varmastikaan ole rikottu, mutta lain henkeä ei enää pystytä noudattamaan.

    1. Tervehdys,

      En toki voi tietää varmaksi viitataanko edellä allekirjoittaneeseen ja puolisooni mutta kommentoidaan kuitenkin hieman faktoilla. Työskentelin Accenturella liikkenjohdonkonsultoinnissa elokuusta 2002 elokuun 2011 loppuun asti. En ollut Accenturen Suomen toimiston johtoryhmän jäsen enkä työskennellyt julkisen sektorin tai terveydenhuollon toimeksiantojen parissa koskaan, pääasiallinen fokukseni oli perusteollisuudessa.

  41. Suuret kiitokseni Otso Kivekkäälle, joka ansaitsisi tiedonjulkistamispalkinnon tai korkean kunniamerkin tämän hämärämiesten jättikaappauksen yrityksen päivänvaloon tuomisesta.

    Kivekäs kirjoittaa hyvin osuvasti suuren, monimutkaisen ja erittäin kustomoidun tuotteen voimakkaasta lock-in efektistä, jota on Suomessa käytetty härskiin rahastamiseen tähän saakka ja ilman tämän hankkeen parempaa läpinäkyvyyttä samanlaista riippuvuutta toimittajasta tullaan epäilemättä hyödyntämään uudelleen miljoonien lypsämiseksi toisensa jälkeen.

    Järjestelmää käyttävien lääkärien kannalta Suomen potilastietojärjestelmien markkinoilla on nykyisin pelkkää sutta ja sekundaa, käytettävyydeltään ala-arvoisia pirullisia esteratoja, joihin harva pitkälle koulutettu ammattilainen suostuisi koskemaan kepilläkään millään muilla aloilla. MItää kaupallista softaa ei ikinä voitaisi myydä kuluttajille yhtä tökeröillä ja kömpelöillä käyttöliittymillä.

    On hälyttävää, kuinka tärkein käyttäjäryhmä ollaan ilmeisesti ohittamassa tälläkin kerralla, sillä potilaan saaman hoidon laatu riippuu nimenomaan lääkärien päätöksistä. Suomen Lääkäriliitossa on kyllä asiaan perehtyneitä kliinisen lääkärintyön tekijöitä, aihetta on käsitelty Lääkärilehdessäkin, mutta taaasko aiheesta pihalla olevat maallikkopäättäjät syövät nöyrästi markkinamiesten kädestä?

    Sopii toivoa, että potilastietojärjestelmien uusimishanke pysäytetään, kunnes rakenteet ja menettelytavat kestävät päivänvalon, ja kunnes on varmistettu, että tuleva järjestelmä tosiaan helpottaa eikä vaikeuta terveydenhuollon ammattilaisten työtä.

  42. Tyoskentelen koodarina EPIC:in kilpailijalle Allscripts:lle, joten olen puolueellinen. Haluan vaan tuoda esille yhden vaihtoehdon.

    Pahin EPIC:in ongelma talta puolelta katsottuna on se, etta se on taydellisesti suljettu systeemi. Asiakas ja konsultit eivat voi vaikuttaa koodin toimintaan ja kulkuun.

    Meidan systeemi pohjautuu Windowsiin, joka on suljettu kayttojarjestelma. Kuitenkin, sovellukset ovat erittain avoimia.

    Ensinnakin, sovellukeset perustuvat Windows Workflow (tyonkulku) Foundationiin ja niin sanottuihin Event:eihin (tapahtumat). Kun jotain tapahtuu jossain sovelluksessa, toiset sovellukset, jotka ”kuuntelevat” tiettyja tapahtumia saavat siita tiedon ja lahtevat suorittamaan omia toimintojaan. Nama toiset sovellukset voivat olla asiakkaan tai konsulttejen tekemia sovelluksia. Asiakkaat ja konsultit voivat tehda omia tyonkulkujaan.

    Jos tietoturvallisuussyista on mahdollista, niin toinen tapa kayttaa sovelluksia olisi asiakkaan tai konsulttien koodista on kutsua suoraan meidan koodia tekemalla WCF kutsuja. Talla tavalla saa tietoja ulkopuolisiin systeemeihin ja voi myos tallettaa niita.

    Minun email: tapani@live.com

    1. Huhhuh. Allscripts kuulostaa vähintään yhtä pelottavalta valinnalta…

      Kommenteissa on jo esitetty paljon parempia vaihtoehtoja.

  43. Sitra polki pystyyn kuntien Tieran ja Epic-hankkeen: Sitralla on pelottavat linkit Accentureen

    Kuntien Tieran hallitusjäsen, entinen Accenturen maajohtaja
    Juho Malmberg on 50-vuotias diplomi-insinööri. Malmberg toimii KONE Oyj:n Customer Experience -yksikön johtajana. Malmberg toimi aiemmin KONE Oyj:n kehitysjohtajana ja johtokunnan jäsen hän on ollut vuodesta 2006 lähtien.
    Malmberg työskenteli aiemmin Accenture Suomen maayhtiön toimitusjohtajana ja pohjoismaiden ulkoistusjohtajana. Keskeisin luottamusmiestoimi on hallitusjäsenyys F-Secure Oy:ssä.

    Entinen Accenture Nordicin toimitusjohtaja Markku Silen toimii Sitran Senior Advisorina. Toimii Tieran rakentamisen aikaan Tieran hallituksessa.

    Tässä tiivis artikkeli Siriuksesta, kirjoittaja Jari Renko/HUS
    http://www.terveysjatalous.fi/lehti/2011_02.pdf

  44. Yksi negatiivinen juttu on Accenturen käyttämä off-shore toimitusmalli. Ymmärrän sen jos globaali liikeyritys haluaa mahdollisimman halvalla ”laatua” ja mukana on off-shore-komponentti jolla hintaa saadaan alemmaksi..

    Mutta kuinka reilua on että verovaroin tuotetun julkishallinnon hankkeen ravintoketjussa pohjalla on intialainen, kiinalainen tai malesialainen koodari tai testaaja?

    Tämä samaan aikaan kun jeesustellaan jostain Nokian irtisanomisista ja työpaikkojen menetyksistä.

    (Toki Nokian potkut ovat koskeneet koko henkilöstöä eikä voi olettaa vapaana olevan massoittain viimeistä huutoa olevien sovellusekehitysmetodologioiden tai -teknologioiden osaajia)

    Aikoinaan itse Accella töissä ollessa esillä jenkkimediassa oli voiko sama firma joka on verosyistä siirtänyt pääkonttorinsa Karibialle toimia kansalliseen turvallisuuteen liittyvissä hankkeissa. Sama analogia kyllä pätee voiko suomalaisin verovaroin teettää IT-hommia Aasiasta.

    Ainoa oikea ratkaisu mielestäni on aikaisemmin esitetty uuden (julkisen) yhtiön perustaminen joka ottaa homman haltuun modernein ideoin.

  45. Noin tekninen lähtökohta ei auta. Pitää tietää MITÄ järjestelmän tulee tehdä ja MITEN. Järjestelmän toimittaja ei voi sitä tietää ja se onnistuu vain kysymällä käyttäjiltä. Valmista tsydeemiä ei ole olemassakaan ja periaatteessa on sama, millä sen toteuttaa. Ostamiseen kuuluu OMAN ostajaporukan jatkuva evaluointi SEKÄ mm. järjetelmätoimittajien yritysten toimitatapojen ymmärtäminen. Siihen tarvitaan sekä sisällöntuotannon, tekniikan, talouden, sosiologian että johtamisen osaamista (ostajalta). Ja liiketoiminnan lainalaisuuksien, ymmärtääkseen, miksi j-toimittaja tarjoaa mitäkin, sen takana on aina raha. Ja loppujen lopuksi ostaja tavitsee jääräpäisyyttä viedäkseen läpi tarpeelliset näkemykset, eikä laitetoimittajan esityksiä

  46. Täällä on niin paljon asiavirheitä, että niitä on syytä oikoa. Luin tuon raportin nimittäin kannesta kanteen läpi ja ihmettelen että onko Otso ja useimmat kommentoitat sitä lukeneet lainkaan. Tästä asiasta on ollut infoa nyt useissa medioissa lisäksi jälkikäteen ja yritän vetää yhteen käsitykseni tilanteesta ja asiavirheistä.

    1. Sirius – hanke on ollut luonteeltaan esivalinta. Sen tavoitteena (sivu 6) on ollut ainoastaan selvittää, että mitkä kansainväliset ratkaisut soveltuvat Suomen tarpeisiin ja millä ehdoilla ne ovat tänne halukkaita tulemaan. Tämän selvityksen pohjalta ei siis tehty valintoja. Normaalisti tämän mittaluokan hankkeessa järjestetään seuraavassa vaiheessa mittavat demot ja vierailut järjestelmätoimittajien asiakasyrityksiin. Raportin sivulla 12 on kokonaiskuva hyvin esitetty.

    2. Vastoin kuin alkuperäinen blogi on antanut ymmärtää, Helsingin Sanomissa varmistui että Accenturella ei ole ollut yhteistyötä Epicin kanssa esiselvityksen aikana, vaan vasta useita kuukausia sen jälkeen. Näin ollen mitään jääviysongelmaa ei heillä ole. Sirius raporttihan oli julkinen heti ilmestyttyään ja kaikilla yrityksillä oli mahdollisuus tavoitella yhteistyötä Suomessa Epicin, Cernerin ja muidenkin yritysten kanssa. Pidänkin todennäköisenä, että Epiciin on ollut yhteydessä lukuisat muutkin yritykset Suomesta.

    3. On myös selvää, että ohjelmistotoimistot edustavat myynnissä itse itseään. Ei Logica edusta Cerneriä, eikä Accenture Epiciä. Aivan samalla tavalla kuin muillakin toimialoilla, konsultointitaloilla on rooli käyttöönotossa mutta eivät he toimi myyntiedustajina, en ainakaan ole sellaiseen koskaan törmännyt, sehän olisi todella typerää toimintaa järjestelmätoimittajilta jos he antaisivat paikallisen firman hoitaa myyntiään. Sen sijaan näitä käyttöönottoon liittyviä kumppanoitumisia on tapahtunut paljon Sirius hankkeen jälkeen, mikä on normaalia.

    4. Kansainvälisille yrityksille järjestelmän kehittämisen kannalta on aivan yhdentekevää, että kuinka suuren aseman ne Suomessa saavat. Heillä on satoja tai tuhansia asiakkaita maailmalla ja järjestelmiä kehitetään joka tapauksessa, riippumatta Suomen tilanteesta. Nykyisten järjestelmien osalta kehitystyöhön ei ole intressejä ellei Suomessa joku siitä erikseen maksa. Tässä juuri piilee syy siihen minkä vuoksi suomalaiset yritykset ovat ottaneet kansainväliset toiminnanohjausjärjestelmät käyttöön, sen sijaan että rakentaisivat sellaisen itse. Kehityskustannukset jakautuvat satojen muiden asiakkaiden kesken. Tätä toivon myös potilastietojärjestelmien osalta tapahtuvan.

    5. Avoin lähdekoodi ei ole realistinen vaihtoehto. Jos täällä alettaisiin virittelemään käyttöönoton jälkeen pakettiratkaisun koodia itse, niin mitenköhän ne päivitykset sen jälkeen tehtäisiin. Silloin kun valitsee pakettisoftan, niin avoin lähdekoodi ei ole millään tavalla järkevä vaihtoehto. Avoin lähdekoodi voisi toimia, jos tänne rakennettaisiin nollasta oma järjestelmä, kuten aiemmin on tehty. Mutta silloin ollaan siinä tilanteessa, että kaikki kehitystyö maksetaan itse. Tällaisissa ohjelmistotaloissa tehdään kehitystyötä sadoilla miljoonilla, jatkossa jopa miljardeilla vuodessa.

    Lopuksi:

    On hyvä, että näistä asioista puhutaan, mutta suosittelen jokaista joka täällä käy, lukemaan raportin ensin kannesta kanteen.

    Kun tuon raportin lukee, niin ensimmäisenä minulla tulee mieleen että meidän pitäisi olla kiitollisia siitä, että kaksi maailman parhaaksi rankattua järjestelmätoimittajaa ovat aidosti kiinnostuneita tulemaan Suomeen. Se, että Accenture ja Logica ovat heidän kumppaneitaan, ei pidä sisällään mitään epänormaalia. Päinvastoin, paikallisia yrityksiä tarvitaan kumppaneiksi ja myös Accenturella on tähän ollut samanlainen oikeus kuin muillakin. Olisi eri asia, jos he olisivat kumppanoituneet jo ennen Siriusta tai sen aikana. Näinhän asia ei ole, kuten Hesarista ilmeni, enkä ole koskaan törmännyt siihen että kansainvälinen konsulttiyhtiö tekisi sellaisen virheen.

  47. ”Kansainvälisille yrityksille järjestelmän kehittämisen kannalta on aivan yhdentekevää, että kuinka suuren aseman ne Suomessa saavat. Heillä on satoja tai tuhansia asiakkaita maailmalla ja järjestelmiä kehitetään joka tapauksessa, riippumatta Suomen tilanteesta. Nykyisten järjestelmien osalta kehitystyöhön ei ole intressejä ellei Suomessa joku siitä erikseen maksa. Tässä juuri piilee syy siihen minkä vuoksi suomalaiset yritykset ovat ottaneet kansainväliset toiminnanohjausjärjestelmät käyttöön, sen sijaan että rakentaisivat sellaisen itse. Kehityskustannukset jakautuvat satojen muiden asiakkaiden kesken. Tätä toivon myös potilastietojärjestelmien osalta tapahtuvan.”

    Mielenkiintoisesti yksi syy siihen miksi Kansalliskirjasto siirtyi kansallisen digitaalisen kirjaston toteutuksesssa open source -softa Vufindiin oli, että valmiin kaupallisen järjestelmän kustomointi ei lopulta oikein onnistunutkaan järkevin kustannuksin. Ilmeisesti tässä potilastietojärjestelmähommassa aletaan jo olla sillä kannalla, että ajatus järkevistä kustannuksista hylätään.

    ”Avoin lähdekoodi ei ole realistinen vaihtoehto. Jos täällä alettaisiin virittelemään käyttöönoton jälkeen pakettiratkaisun koodia itse, niin mitenköhän ne päivitykset sen jälkeen tehtäisiin. Silloin kun valitsee pakettisoftan, niin avoin lähdekoodi ei ole millään tavalla järkevä vaihtoehto. Avoin lähdekoodi voisi toimia, jos tänne rakennettaisiin nollasta oma järjestelmä, kuten aiemmin on tehty. Mutta silloin ollaan siinä tilanteessa, että kaikki kehitystyö maksetaan itse. Tällaisissa ohjelmistotaloissa tehdään kehitystyötä sadoilla miljoonilla, jatkossa jopa miljardeilla vuodessa.”

    Jos kaupalliselta toimijalta saataisiin ostetun järjestelmän lähdekoodi toimisi päivitysten teko, kuten muutenkin. Silloin vain olisi myös vaihtoehto ostaa ne päivitykset jostain muualta. En oikein ymmärrä miten voi ajatella avoimen lähdekoodin olevan huono asia, koska se pääosin poistaa vendor lock-inin. Tiettyyn järjestelmäntoimittajaan sitoutuminen ei liene järkevää näin kustomoidussa järjestelmässä, jos halutaan kustannusten pysyvän kohtuullisina.

  48. Niin kauan, kun potilastietojärjestelmien loppukäyttäjiä (lääkärit, eri työtehtävissä ja asiantuntijarooleissa toimiva hoitohenkilökunta, hallinto, potilaat/asiakkaat ja eri sidos- ja yhteistyöryhmien edustajat) ei oteta mukaan suunnittelemaan omaa työkaluaan eli tietojärjestelmää ja sen käyttäjäryhmä- ja käyttäjäkohtaisia käyttöliittymiä (esim. sähköisiä lomakkeita ja integrointeja muista järjestelmistä ja teknisistä laitteista), niin ollaan tiedonhallinnan suhteen kivikauden tasolla eli samaa kiveä käytetään eri käyttötarkoituksiin riippumatta siitä, kuinka hyvin se kulloiseenkin käyttötarkoitukseen soveltuu.

    Esim. hoitajien kirjaukset hoitokertomukseen ja lääkärien sanelut potilaskertomukseen tietyllä erikoisalalla sisältävät monia usein toistuvia tietoryhmiä ja tietoja, joita on aika idioottimaista ja ajankäytöllisesti tehotonta kirjoittaa tai sanella useita kertoja päivässä vaikkapa kiireisellä poliklinikalla käyttämättä jotain valmista ko. erikoisalalle loppukäyttäjien suunnittelemaa mallipohjaa. Ja eri teknisistä laitteista saatuja mittaustuloksia pitää kirjata erikseen potilastietojärjestelmään, kun ne voisi sinne tuottaa integroimalla laite jotenkin potilastietojärjestelmään. Tulisi myös ottaa huomioon, että lääkäreiden ja hoitohenkilökunnan tiedontarpeet samalla erikoisalalla ovat osittain yhteneväisiä ja osittain kullekin työtehtävälle ja ammattiryhmälle ominaisia.

    Terveydenhuoltoalan eri erikoisalojen tiedontarpeet tietojärjestelmien tietojen suhteen voivat olla hyvin erikoistuneita ja samalla kuitenkin tiettyjä tietoja tarvitaan usealla eri erikoisalalla jopa yhtaikaisesti. Silloin tällöin esim. silmävaivaan voi liittyä myös sukupuolitauti…

    Ja minkähän takia esim. Uranuksen hoitokertomuksessa ei ole mahdollista lainkaan käyttää copy-paste-toimintoa? Ja kuka keksi, että on viljeltävä rakenteisessa hoitokertomuksessa niin paljon ikkunoita, miksei esim. tällaisia lomakekenttiä, mihin nyt tätä kommenttia kirjoitan?

  49. Muutama vuosi sitten puuhattiin sellaisen standardin kuin HL7 kanssa, jonka tämän vuosituhannen versio piti olla XML-pohjainen. En ole yksityiskohtaisesti perehtynyt siihen, mutta käsitin, että se olisi ollut melko laaja. Onko siellä ratkaistu kaikki tai ainakin valtaosa tarvittavista tietorakenteista ja/tai esitysmuodoista? Sisäisesti järjestelmät voisivat sitten käyttää mitä rakennetta ja esitysmuotoa vaan, kunhan se on konvertoitavissa standardimuotoon ja päinvastoin. Järjestelmää kokonaisuudessaan tämä ei tietenkään ratkaise, varsinkin tietoturva ja tietosuoja-asiat ovat tietenkin aika keskeisiä.

  50. Muutama kommentti:

    1) Positiivista keskustelun käynnistäneessä selvityksessä on, että on kerrankin ymmärretty katsoa löytyisikö maailmalta jotain valmista mitä voisi käyttää. Omituista on kuitenkin, että on päädytty amerikkalaisiin tuotteisiin jo siksikin (kuten joku täällä mainitsi), että siellä koko sairaanhoidon peruslähtökohta (vakuutusyhtiöiden laskuttaminen) on eri kuin täällä.

    2) Muilla toimialoilla pakettituotteiden hankkimisten jälkimaininkeja lähempääkin seuranneena ihmettelen, milloin tietojärjestelmiä pakettituotteina ostaviin organisaaoihin uppoaisi tämä perusoppi: Jos ostat pakettituotteen ja haluat säästää suhteessa täysin räätälöityyn tuotteeseen, ole valmis muuttamaan organisaatiosi toimintatapoja pakettituotteen olettamien mukaiseksi. Muuten järjestelmä ei tule millään rahasummalla palvelemaan organisaatiota hyvin.

    3) Joku täällä mainitsikin, ja olen täysin samaa mieltä, että paras ratkaisu olisi perustaa täysin uusi yritys, joka olisi riippumaton sekä nykyisistä toimittajista sekä yksittäisistä sairaanhoitopiireistä. Tämä yritys voisi olla täysin voittoa tavoittelematon tai sitten voitot jaettaisiin sitä rahoittavien sairaanhoitopiirien kesken. Yrityksen ainoana tehtävänä olisi varmistaa Suomen potilastietojärjestelmän (huomaa yksikkömuoto) toimivuus ja käytettävyys.

    Tämä Suomen Potilastieto Oyj voisi sitten ostaa järkevissä osissa toteutuksia minkä tahansa kokoisilta kotimaisilta yrityksiltä (kyllä, kannatan ehdottomasti sitä että verovarat jätetään hyödyttämään suomalaisia yrityksiä eikä ylikansallisia oligopoleja) ILMAN sitä käsittämätöntä byrokratian määrää joka tuhoaa julkisen puolen IT-hankinnat jo kalkkiviivoille.

    Voisin kuvitella, että muualla mainittu Tanskan malli on melko lähellä tuota käytännössä.

    Alan ammattilaisena minua ahdistaa ja nolottaa se, missä alennustilassa suomalainen ohjelmistotuotanto tässä kohtaa on. Kyse ei ole siitä, etteikö täällä olisi osaamista tai halua tehdä näitä asioita. Kyse on siitä, että pienet yritykset, joissa kumpaakin olisi, eivät pääse mukaan.

    Otsolle hatunnosto kissan nostamisesta pöydälle sekä terävästä analyysistä!

  51. Pirkanmaalla on ainakin ymmärretty miten potilastietovarasto kannattaa järjestää. Saa nähdä miten toimii käytännössä.

    Poiminta Antti Jokelan pitämästä esityksestä Alueellisen tietojärjestelmäarkkitehtuurin
    kehittäminen, Case Pirkanmaa:

    ”Järjestelmäkokonaisuuden jakamisen logiikka perustuu siihen, että yhteisellä potilastietovarastolla saadaan
    potilastiedot siivottua ja vakioitua, potilastiedot saadaan standardien rajapintojen kautta yhteiskäytettäviksi,
    logiikkakerrosta sekä käyttöliittymäkerrosta voidaan kehittää palvelemaan paremmin toiminnan muuttuvia
    tarpeita kuin perinteisillä siilomaisilla järjestelmillä. Malliin voidaan liittää myös vanhat siilojärjestelmät eli niihin
    tehdyt panostukset eivät mene hukkaan.”

    Linkki esitykseen:
    http://www.kunnat.net/fi/tietopankit/tapahtumat/aineisto/2011-tapas-seminaarit/Documents/2011-10-28-05-Jokela-Antti.pdf

  52. Uuden yrityksen perustaminen kuulostaa täältä luettuna uskomattoman helpolta. Eniten särähtää korvaan tuo huippuosaamisen hankkiminen sinne. Pahoittelen, mutta huippuosaamista tuonne on lähes mahdotonta saada. Uuden järjestelmän toteuttaminen kokonaisuudessaan kestää varmasti vuosia. Ei pidä myöskään olettaa, että eri sairaanhoitopiireillä olisi yhtenäiset laitteistot ja vempeleet, joten kaiken tämän tekeminen kestää varmasti. Kestää niin kauan, että joudutaan ampumaan liikkuvaan maaliin.

    Ketterät huippuosaajat eivät halua työskennellä tällaisessa ympäristössä. Eri osapuolia on yksinkertaisesti niin paljon, että homma menee puoliväkisin raskaan määrittelyn kautta. Projektilla on varmasti oma valittu teknologiapinonsa, joka alkaa hapantua jo ennen kuin on valmista. Tämä karkottaa suuren osan tekijöistä, jotka haluavat pitää oman osaamisensa ajantasaisena. Käytännössä tällaisesta duunista pitävät ne henkilöt, jotka haluavat saada valmiiksi pureskellun speksin eteensä ja toivovat pääsevänsä eläkkeelle samaa tuttua ja turvallista tehden. Kannattaa kuitenkin huomioida, että järjestelmän elinikä on 20-30 vuotta ja web serviceille nauretaan varmaankin tuolloin.

    Kyllä, olen työskennellyt tällaisessa ympäristössä. Moni rekrytoitu ihminen pakeni paikalta varsin nopeasti. Ja minulla ei kertakaikkiaan ole mitään sitä vastaan, että vendor lockeja pyrittäisiin välttämään, päinvastoin. Asia ei kuitenkaan ole ihan niin helppo kuin täältä lukemalla kuvittelisi.

  53. konsulentille. Olet varmasti oikeassa, että yrityksen perustaminen tai osaamisen haaliminen on vaikeaa. Asiaa voi kuitenkin helpottaa ehkäpä muutamalla tavalla. Yksi olisi pitää yrityksen omilla palkkalistoilla vain ns. domain-asiantuntijat sekä tarvittava hankejohto. Varsinainen tekninen osaaminen ostettaisiin vapailta markkinoilta vaikka sitten maksamalla erittäin korkeita korvauksia.

    En myöskään ole ihan niin negatiivinen sen suhteen, että osaavia asiantuntijoita ei kiinnostaisi kyseinen hanke, varsinkin jos sitä yritettäisiin tosissaan tehdä oikein. Itse olen ainakin jo aikaa sitten kasvanut ulos siitä ajatuksesta, että vain uusin ja ihmeellisin teknologia on se, jonka takia haluaisin olla jossain hankkeessa. En usko, että olen yksin tässä asiassa.

    Avainsana tässä onkin tuo ”ympäristö”, jonka mainitsit. Ympäristö ja tekemisenen yleinen meininki voisikin olla suuri tekijä noinkin vaativan hankkeen onnistumisessa. Toimintakulttuuri on vain vaikea asia muuttaa ja siitä olen myös samaa mieltä, että se on usein valitettavan huono suomalaisissa julkisissa IT-hankkeissa.

  54. Näinhän se menee. Myyjänä on tietenkin kiva hykerrellä jos asiakas on niin tyhmä ettei vaadi hänelle kehitettävän softan oikeuksia itselleen. Usein se tietenkin perustuu siihen, että uutta järjestelmää ei rakenneta tyhjästä vaan se perustuu olemassaolevaan suljettuun kaupalliseen tuotteeseen. Tästä toki voidaan varmasti saadakin kustannussäästöjä.

    Joka tapauksessa voi olla mahdotonta vaatia kaikkien ohjelmistojen oikeuksia asiakkaille, koska kyse ei ole vain yhdestä ohjelmasta. Sairaaloissa on satoja erilaisia laboratoriolaitteita, joissa useimmissa on suljetut ohjelmistot. Valmistajat eivät välttämättä edes suostu julkaisemaan protokolliaan, varsinkaan jos sairaalajärjestelmä on avointa lähdekoodia. Käytännössä jokin kompromissi on pakko tehdä, vaikka se tietenkin mahdollistaa kaikenlaista peliä. Miksi vetää oikeusvaatimusraja laboratoriolaitteisiin, kun sairaaloissa on kaikenlaisia muitakin suljettuja ohjelmistoja. Siirrytäänkö samalla avoimiin toimisto-ohjelmistoihin? (Sinällään kannatettavaa.) Entä spesialisoidut analyysiohjelmistot? Taloushallinto? No niin, toki näissä kaikissa ovat samat lukitusongelmat, joiden ratkaiseminen avaisi suuret mahdollisuudet muutenkin kuin vain terveydenhuollon alalla.

  55. Juuri tajusin, että tämähän on vuoden vanha keskustelu, asiat taitavat olla jo menossa pahaan suuntaan vai onko tälle tullut mitään korjausta?

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *