Terveydenhuoltoa tietojärjestelmille

Alkuperäinen aikomukseni oli päättää Tampereen tietotekniikkamokia käsittelevä blogaussarja idean lähtökohtaan eli terveydenhuollon tietojärjestelmiin. Tulin kuitenkin siihen tulokseen, että Tampereen kaupunkia tai edes Pirkanmaan sairaanhoitopiiriä on turha syyttää valtakunnallisesta kaaoksesta. Kunnat ja sairaanhoitopiirit olisivat toki tälläkin saralla voineet paremmin noudattaa samaisia periaatteita, joita olen sarjan aiemmissa osissa esittänyt ratkaisuiksi ohjelmistohankintojen monenkirjaviin ongelmiin, mutta tällä hetkellä paras teko niiltä olisi painostaa valtiota toteuttamaan rooliaan ohjaajana.

Terveydenhuollossa on tietysti meneillään muitakin, vielä isompia haasteita. Joustamattomat työolot aiheuttavat lääkäripulaa ja hoitajapulaa, perusterveydenhuoltoon on puolihuolimattomasti luotu kolmen tason porrastus ja palvelut pitäisi saada järjestymään sellaisella päätöksenteon tasolla, johon kansalaiset voisivat oikeasti vaikuttaa. Tätä kirjoittaessani näyttää lisäksi pahasti siltä, että ainakaan valtion tasolta uudistuksia ei ole ihan heti odotettavissa. Asioita ei kuitenkaan auta, jos terveydenhuollon tietojärjestelmien pelkkään kehittämiseen palaa 2,7 prosenttia julkisen terveydenhuollon kokonaismenoista ja laskennallisesti 600 lääkärin työpanos kuluu tuijottaessa toimimattomien tietojärjestelmien tiimalasia. Vakavin juttu ovat tietenkin käytettävyysongelmat, jotka vaarantavat potilasturvallisuuden.

Tampereella on toiminut yli kymmenen vuotta potilastietojärjestelmänä Pegasos, jota käyttää myös Helsingin kaupunki. Pirkanmaan sairaanhoitopiirillä kuten myös Helsingin ja Uudenmaan sairaanhoitopiirillä käytössä on puolestaan Uranus. Muita Suomessa käytössä olevia järjestelmiä ovat ainakin Effica sekä vähemmässä määrin Mediatri ja Finstar. Potilasjärjestelmät eivät juttele keskenään, minkä ovat huomanneet myös yhdistymishaluttomat kunnat, ja niiden lisäksi käytössä on tuhansia muitakin järjestelmiä. Yhden hoitotoimenpiteen aikana lääkäri saattaa pahimmillaan joutua kaivamaan tietoa kymmenestä eri järjestelmästä, joihin tiedot myös täytyy syöttää erikseen. Hankinnoissa on tyydytty järjestelmätoimittajien valmiisiin paketteihin ilman, että kokonaisuus on kenenkään hallinnassa.

Kohutussa Apotti-hankkeessa ajatuksena oli yhtenäistää tätä sekamelskaa korvaamalla Helsingin ja Uudenmaan sairaanhoitopiirin alueella vanhoja järjestelmiä uudella ja toimivalla. Hieno ja kannatettava tavoite siis, mutta valitettavasti käytännön valmistelu on ollut kammottavaa jokaisella mahdollisella tavalla. Kauhuskenaariossa tuo avaruussukkulan hintainen hökötys pakotettaisiin HUS-alueen jälkeen käyttöön myös muualle maahan, jolloin koko Suomi olisi sen yhden ainoan monopoliyrityksen eli Accenturen armoilla.

Terveydenhuollon tietojärjestelmissä on kaikesta huolimatta saatu aikaan hyvääkin, kuten sähköinen lääkemääräys, sähköinen potilastiedon arkisto ja potilaiden omien tietojen katselu. Viron tehokkaaseen tapaan hoitaa tietojärjestelmähankinnat onkin kiinnitetty jo laajasti huomiota, mutta myös Savonlinnassa on selvästi tehty jotain oikein. Yhteinen piirre toimiville järjestelmille näyttää olevan, että ne maksavat monin verroin vähemmän kuin vastaavat kuolleena syntyneet projektit.

Mitä tässä tilanteessa siis kannattaisi tehdä? Tähän mennessä tapahtuneen uutisoinnin perusteella kaikille lienee jo selvää, että Apotin kaltainen yhden ainoan massiivimonoliitin tilaaminen kerralla yhdeltä ulkopuoliselta tekijältä voi johtaa vain entistä huonompaan tilanteeseen. Suuren siirtymän sijaan järjestelmiä olisikin syytä yhdistää pikku hiljaa. Aivan aluksi valtion tulisi ottaa tiukka ohjaus asiassa määrittämällä avoimet rajapinnat ja perussäännöt, joita järjestelmiä päivitettäessä vastaisuudessa tulisi noudattaa. Valmiin suljetun koodin paketin sijaan tulisi pyrkiä rakentamaan oma järjestelmä alusta lähtien ja mielellään aloittaen kokeilualueelta, jolloin ongelmien korjaaminen käy vielä helposti. Ratkaisun tulisi olla avointa lähdekoodia, jolloin sen luomisessa voitaisiin käyttää hyväksi joukkoälyä. Tietojenkäsittelytieteen peruskursseilla esimerkkinä toimimattomasta ohjelmistokehityksestä esitellyn vesiputousmallin sijaan järjestelmän rakentaminen tulisi aloittaa pienestä ja laajentaa sitä vähä vähältä jatkuvan palautteen kautta.