HUS:n potilastietojärjestelmän hankinnasta

   HUS:n (ja myöhemmin myös muiden) potilastietojärjestelmän uusiminen on herättänyt mediassa polemiikkia ja aivan ansaitusti. Myöhemmin Apotiksi nimetty hanke kun on kooltaan yksi kaikkien aikojen suurimpia suomalaisia tietohallinnon investointeja. Viime vuosilta on lähinnä pitkä lista enemmän tai vähemmän epäonnistuneita hankkeita. Tähän olen listannut joitakin tekijöitä, jotka itseäni hankkeessa erityisesti epäilyttää.

   Markkinoilla ei ole olemassa valmiita ns. COTS (Commercial-off-the-shelf) tuotteita potilastietojen hallintaan, jotka olisivat sellaisenaan sovellettavissa eri ympäristöihin. Se tarkoittaa sitä, että valittiinpa mikä tahansa valmis järjestelmä, niin sitä joudutaan räätälöimään täkäläisiin oloihin, erilaisille organisaatiomalleille ja paikalliseen lainsäädäntöön sopivaksi. Vaikka tallennettava tieto – potilastiedot – olisi yhteinen nimittäjä, niin työn organisointi, tapa tuottaa ja käyttää näitä tietoja vaihtelevat. Hyväksi havaitut toimintamallit pitää olla järjestelmän suunnittelun pohjana. Ei niin, että järjestelmän rajoitukset määrittävät toimintamallit.

   On valitettavan yleinen harhaluulo, että valmiin järjestelmän muokkaaminen olisi helppoa tai halpaa. Pienenkin toiminnallisuuden tai uuden ominaisuuden lisääminen saattaa edellyttää massiivisia muutoksia hyvin laajaan osaan ohjelmistoa ja ennen kuin sitä päästään edes tekemään, on tekijän opeteltava perinpohjaisesti miten järjestelmä toimii. Alkuperäisiä tekijöitä on erittäin harvoin saatavilla tehtävään. Ongelmaa pahentaa se, että Epic:in pohjalla oleva ohjelmointitekniikka ei missään tapauksessa ole uudelleenkäytettävyydeltään korkeatasoista.

   Nyt kaavailtu järjestelmä on ns. monoliittinen ja perustuu pitkälti samaan tekniikkaan kuin vanhatkin suomalaiset potilasjärjestelmät (mm. Musti). Se ei ole teknisesti nykyaikainen järjestelmä, jota olisi helppo jatkossa päivittää tai edelleen kehittää. Modulaarinen ratkaisu, jossa olisi selkeästi määritellyt standardit rajapinnat (mm. Tanskassa käytössä) on ehdottomasti parempi ratkaisu. Tällaisessa mallissa eri toimittajat voivat tuottaa järjestelmän eri osia kilpaillusti ja eri aikoina. Pitää muistaa, että muut sairaanhoitopiirit ja kunnat ovat vapaat tekemään itsenäisesti omat ratkaisunsa. Modulaarinen järjestelmä mahdollistaa sen, että jokainen taho voi vapaasti kilpailuttaa oman järjestelmänsä ja valita sille haluamansa toimittajan.

   Olipa järjestelmä sitten valmiina ostettu tai alusta pitäen tyhjästä rakennettu, pitää ostajan olla siinä aktiivisesti mukana. Ei räätäliltäkään voi tilata hyvin istuvaa pukua pelkästään puhelimessa; pitää saada mitat ja vielä ennen valmistumistakin sitä on syytä sovittaa ainakin kerran ja tehdä tarvittavat muutokset. Vaikka näennäisesti monimutkaisempia tuotteita kuten omakotitaloja myydään avaimet käteen -periaatteella, niin sekin on mahdollista lähinnä vain siksi, että asumisen tarpeet ovat hyvin yhdenmukaisia ja niiden tuntemuksella on vuosisataiset perinteet. Siitä huolimatta avaimet käteen ostettujen omakotitalojen pohjaratkaisuihin, muunneltavuuteen ja käytettävyyteen ollaan joskus lopulta tyytymättömiä.

   Kaikissa teetetyissä töissä ostaja saa itselleen tarvittavat ohjeet ja piirustukset tuotteen käyttöön ja ylläpitoon. Näin on yleinen käytäntö myös ohjelmistoteollisuudessa silloin, kun ostaja teettää itselleen järjestelmän alusta asti. Vaatimus- ja toteutusmäärittelyt ja itse lähdekoodi tulisi aina sopia ostajan omaisuudeksi. Tilanne on toinen, kun olemassaolevaa järjestelmää muokataan omiin tarpeisiin. Sellaiseen jamaan, jossa yksi toimittaja omaa kaiken järjestelmän ylläpitoon ja kehittämiseen tarvittavan tiedon, ei pidä tietoisesti mennä!

   Olisi hyvä asia, jos kaavailtu valtion it-yhtiö ottaisi hoitaakseen tämän kaltaisten hankintojen ja hankkeiden projektihallinnon, keskitetysti hoitaisi ostamisen osaamisen ja mahdollisesti myös hallinnoisi niissä tuotettujen järjestelmien määrittelyjen ja lähdekoodin säilytyksen. Siinäkään tapauksessa loppukäyttäjä ei voi tietenkään jäädä odottelemaan valmista tuotetta, vaan järjestelmän määrittelyyn on silti osallistuttava. Sekin on toisaalta helppoa, jos projektihallinnossa on henkilöitä, jotka osaavat opastaa vaatimusmäärittelyn tekemiseen. Siihen riittää omien tarpeiden ja työssä tarvittavien tietojen tuntemus; ohjelmoinnista tai ohjelmistosuunnittelusta ei tarvitse ymmärtää mitään. Oleellista on, että määrittelytyössä on mukana ne henkilöt, jotka itse järjestelmää joutuvat päivittäin ja eniten käyttämään. Johto harvoin kuuluu siihen ryhmään ja viestin välittäjiä ei ole syytä käyttää.