Roadmap-dokumentti: Vaiheittainen roadmap nykyisten järjestelmien korvaamiselle

[pe3]

Ei tehdä yhtä mammuttihankintaa, vaan avoimia rajapintoja hyödyntäen korvataan nykyinen järjestelmä joustavasti ja avoimesti pala kerrallaan. Mutta miten ja missä järjestyksessä?

[pe3]

Mitä tässä projektissa on tarkoitus seuraavaksi tehdä? Ajattelisin, että olisi tärkeintä tuottaa mahdollisimman uskottava uusi vaihtoehto 2.10. järjestettävään terveyslautakunnan seuraavaan kokoukseen. En ole varma onko tyhjästä aloitettu web-ohjelmointiprojekti sitä.

[d2s]

@pe3 Epäilen että tyhjästä aloittamalla ei paljoa voiteta, mutta ainakin voidaan saada aikaan joitakin ehdotuksia joilla perinteisten kankeiden järjestelmien rinnalle voi saada jotain vaihtoehtoja.

Löytyykö muuten tuota Accenturen tekemää raporttia/suositusta vielä mistään julkisesti?

[pekko]

Accenturen presis aiheesta: http://www.sitra.fi/NR/rdonlyres/EC4CA5AD-634B-4F80-8ACC-6E70FFAEAFFF/0/Sirius_Potilastietoj%C3%A4rjestelm%C3%A4kartoitus_tiivistelm%C3%A4.pdf

Kattavampaa raporttia ei tähän hätään löytynyt.

[mikkohei13]

Mikä on tämän hankkeen (realistinen) tarkoitus ja tavoite pitkällä aikavälillä? Haarukoida millä tavoilla potilastietojärjestelmää voisi tehdä avoimesti, ehkä toteuttaakin joitakin osia? Muuttaa tapaa, jolla järjestelmähankintoja tehdään?

Miten tätä kannattaa edistää lähikuukausina? Valistaa päättäjiä ketterästä kehityksestä ja nykytekniikan mahdollisuuksista (esim. rajapinnat)? Tehdä uskottava suunnitelma? (Miten pienen piirin suunnitelma voi olla uskottava päättäjien silmissä?) Toteuttaa nopeasti jokin pieni järjestelmän osa wow-efektin toivossa? Innostaa osaavia ihmisiä tulemaan mukaan?

Tämä(kin) hanke on suurimmaksi osaksi epäteknistä työtä, ainakin muuta kuin koodaamista.

[d2s]

Tuosta dokumentista hieman zoomailemalla näkee sivulta 5 tarkempaa erittelyä erilaisista järjestelmistä mitä nykyhetken järjestelmistä (tai ainakin tarpeista) löytyy. Paljon on erillisiä järjestelmiä ja erilaisia tietotyyppejä.

[itmo]

imo tosta dokumentista näkyy just se ongelma jonka noi luo itelleen. ts. yritetään tehdä kerralla kaikki monoliittisella systeemillä. Ei tule onnistumaan.

[itmo]

Käytännössä mä vähän veikkaan että tällä projektilla (githubissa) ei ole mitään tulevaisuutta. Jos haluttaisiin vaikuttaa niin se vaikuttaminen pitäisi tapahtua huipulla , tavoitteena uusia koko hankintaprosessi ja pakottaa HUSssista alkaen se sakki hankkimaan taloon oikeata IT-osaamista. Käsitys hankintamallista jossa alkuun julkaistaan vaatimukset , sitten speksi, sitten hierotaan, sitten kilpailutetaan paloina. Ton onnistumiseen tarvitaan osaamista edes vähän talon sisään. Toinen vaihtoehto on että valtio perustaa laitoksen joka tukee kuntia it-hankinnoissa.

[d2s]

@itmo Voi olla että jossakin määrin monoliittinen järjestelmä onnistuisikin, mutta yksittäisten osioiden kehitys muuttuisi hyvin hankalaksi vaikuttamatta muihin osiin järjestelmistä.

Hankintaprosessin toimintatapojen muuttamisen tarpeesta olen samaa mieltä.

[MikkoPaltamaa]

Kuten minkä tahansa muunkin ihmisten käyttämän järjestelmän kohdalla, niin viime kädessä eniten väliä on järjestelmän hyödyllisyydellä ja käytettävyydellä. Eli a) tekeekö järjestelmä oikeat asiat ja b) kuinka helppoa käyttäjien on ne sillä tehdä.

Jos tämä potilastietojärjestelmä on niin tärkeä ja vaikea projekti kuin väitetään, niin se pitäisi jakaa karkeasti kahteen vaiheeseen: suunnitteluun ja toteutukseen. Koko homma tulee aloittaa käyttöliittymien suunnittelulla. Kun on ensin suunniteltu ja testattu oleelliset käyttöliittymät, niiden pohjalta voidaan suunnitella järjestelmälle toimiva arkkitehtuuri ja valittu sopivat toteutusteknologiat.

Siinä vaiheessa kun käyttöliittymät ja arkkitehtuurit ovat kunnossa, niin projektin riskit ovat valtavasti pienemmät. Ensinnäkin ollaan tekemässä oikeaa asiaa alusta lähtien. Tämän jälkeen loppu on enää suoraviivaista teknistä toteutusta. Ja jos silti onnistuttaisiin tekemään toteutus väärin (esim. liian huonolaatuisena), niin se voitaisiin tehdä uudestaan toisen toimijan avulla.

Tätä järjestystä puoltaa myös se, että projektin hankalin osa ovat integraatiot olemassaoleviin surkeisiin tietojärjestelmiin. Käyttöliittymien ja arkkitehtuurin suunnittelussa voitaisiin parhaimmillaan onnistua tekemään tarpeettomaksi useita vanhoja järjestelmiä, eli välttää näin integraatiotarve.

Jos riskejä halutaan erityisesti välttää, niin kilpailuttaisin ensin suunnitteluun 2-3 tiimiä, joiden parhaat tuotokset vedettäisiin aina välillä yhteen ja jatkettaisiin yhteiseltä pohjalta. Nämä firmat eivät saisi tarjota toteutusta itse, mutta osallistuvat kuitenkin työhön koko toteutusprojektin ajan, myös toteuttajien arviointiin ja valintaan.

Sitten kun on tiedossa mitä tarvitaan, niin toteutuksen kilpailuttaminen olisi hyvin suoraviivaista. Hankkija tietää mitä haluaa, tarjoaja tietää mitä joutuu tekemään, kustannukset on helppo laskea. Ja jos riskejä halutaan edelleen välttää, niin voidaan hajauttaa eri osajärjestelmien toteutus eri tahoille.

Ja jos budjettia riittää, niin voitaisiin edelleen tehdä päällekkäistä työtä useamman firman toimesta ja valita aina parempi toteutus, sekä luvata bonuspalkkio valituksi tulevalle. Tämän luulisi motivoivan tuottamaan hyvää laatua ja suorittamaan testauksen kunnolla

Koko homma maksaisi näin tehtynä vain murto-osan arvioidusta hinnasta. Ja väitän, ettei se voisi epäonnistua käytännössä. Sen sijaan tuloksena olisi erittäin hyvä järjestelmä, jota voitaisiin vaikkapa myydä muihin maihin. Pitkällä tähtäimellä parempi ratkaisu olisi tietenkin julkaista avoimena lähdekoodina muidenkin käyttöön ja jatkokehitettäväksi.

Olen itse käyttöliittymäsuunnittelija, joten tämä kommentti voi olla vähän värittynyt siihen suuntaan. Mutta näin siis itse tekisin, jos olisin hankinnasta vastuussa.

[d2s]

@MikkoPaltamaa Hyvä pointti tuo käyttöliittymän tärkeys. Samaa mieltä siitä että monissa nykyisistä järjestelmistä yksi suurimmista ongelmista on käytettävyys. Backendin nopeudella on tietysti paljon vaikutusta mutta ilman toimivaa käyttöliittymää mikään järjestelmä ei toimi kunnolla.

Protoilemalla erilaisia käyttöliittymiä nykyisten korvaajiksi voisi samalla selkeyttää monen jokapäiväistä työtä. Tärkeä olisi kuitenkin tehdä kokonaisuudet niin selkeiksi että navigointi on toimivaa vaikka tietojen määrä kasvaa.

[keskival]

Ei mitään monoliittijärjestelmiä. Piste. Siis ei todellakaan.

Laittakaas se alustava vaatimukset.md sieltä pull requesteista hyväksytyksi, niin voidaan siirtyä keskustelemaan oikeista asioista.

[hessuvi]

http://www.tietoviikko.fi/cio/helsinki+eparoi+massiivista+ithanketta++selvittaa+ketterampaa+vaihtoehtoa/a844354 Mutta mitä seuraavaksi? Joko luovutetaan ja toivotaan, että julkishallinto pystyy lautakunnilta saamansa evästyksen turvin polkaisemaan pystyyn menestyksekkään IT-hankintahankkeen? Vai pitäisikö sittenkin etsiä ja kirjata ylös vielä muita vaihtoehtoja?

Esimerkiksi en muista nähneeni täällä tarinaa siitä, miten Googlen softatuotantoa tai Handelsbankenin pankkitoimintaa johdetaan. Samat ideat voisivat hyvinkin olla sovellettavissa myös sosiaali- ja terveydenhuollon asiakastietojärjestelmän rakentamiseen. Onhan sekin iso järjestelmä ja terveydenhuollon toimijoiden kertomuksista jää sellainen tuntuma, että tarvitaan melkoinen joukko pieniä innovaatioita, ennenkuin siitä tulee käyttökelpoinen. Lisäksi maailma järjestelmän ympärillä muuttuu koko ajan. Tulee uutta ja tiukempaa lainsäädäntöä, lääketieteellinen tutkimus kehittää koko ajan uusia diagnoosi- ja hoitomenetelmiä ja terveydenhuoltoalaa uhkaa ennusteiden mukaan työvoimapula.

Perusideana on, että varsinaista työtä tekevät hyvin autonomiset tiimit. Jokaisella tiimillä on kooltaan sopivaksi rajattu toimintakenttä ja tehtävänä hyödyntää saamansa resurssit mahdollisimman tuottavasti. Tästä seuraa, että organisaatiosta tulee joustava ja mukautumiskykyinen sekä hallinnollisesti kevyt.

Toki tiimien välistä koordinointiakin tarvitaan. Ainakin tarvitaan järjestelmäarkkitehtuurista vastaava tiimi, jolla on kaksi tehtävää. Toisaalta sen pitää huolehtia, että järjestelmän rakenne on yhteensopiva käyttäjien työskentelyprosessien kanssa, ja toisaalta pitää huolta, että jokaisen tiimin pelialue on selkeä ja riittävän yksinkertainen (kolmen APIn sääntö).

Toinen järjestelmätasoista koordinointia vaativa asia on lainsäädännön asettamat auditointimenettelyt. Lain 629/2010 perusteella ainakin keskeiset osat terveydenhuollon tietojärjestelmästä luokitellaan lääkintälaitteiden luokkiin I, II A ja II B, mikä edellyttää soveltuvien standardien noudattamista kehitystyössä. Tämän tiimin tehtävänä olisi siis ainakin vahtia, että tiimien kehitysmenetelmät kestävät päivänvalon, ja toimia virallisena vastuu- ja yhteystahona ulkopuolisiin auditoijiin.

Tällaisen toimintamallin pitäisi sopia myös hallintokoneiston virkamiehille ja APOTTI-hankkeen ohjausryhmälle. Heillä on hyvin tärkeä rooli hankkeessa, koska he joutuvat käytännössä koordinoimaan koko hankkeen etenemistä. Tiimien työskentelyyn he eivät tietenkään puutu, vaan mittaavat tulosten vaikuttavuutta haluamallaan tavalla käyttäjien organisaatiossa ja jyvittävät tulokset tiimeille tulospisteinä. (Hihasta ravistettu esimerkiksi: vakavan hoitovirheen esto, miljoona pistettä; hoitajan työn väheneminen 5 pistettä minuuttilta; lääkärin työn väheneminen 10 pistettä minuutilta; jne.)

Näiden tarinoiden keräämisen jälkeen ne pitäisi varmaan saattaa myös hankkeen valmistelijoiden tietoon. Tietääkö kukaan, mitä foorumeita esimerkiksi hankejohtaja Antti Iivanainen seuraa?