Ensin: kiitos kaikesta hyvästä edelliseen kirjoitukseen antamastanne palautteesta. Se toimi kimmokkeena tälle jatko-osalle.

Miksi sote-IT on niin vaikeaa?

Itse tutustuin aiheeseen ensimmäisen kerran vuonna 2012, kun Apotti politisoitui ensimmäisen kerran. Olin mukana järjestämässä aiheesta mielenosoitusta, osallistuin kaikella teekkarin innolla huuteluun aiheesta ja olen yhäkin ylläpidossa Terveydenhoidon tietojärjestelmät korjattava -Facebook-ryhmässä. En siis tee työkseni sote-IT:tä, mutta olen hiljalleen keräillyt tiedon jyviä eri puolilta.

Uskon, että asiaan on oikeastaan neljä syytä, jotka kytkeytyvät toisiinsa:

1. Vanhentunut ohjelmistokehityskulttuuri luo jähmeitä ns. monoliittiohjelmistoja, joiden laajentaminen on yhden toimittajan varassa.
2. Sotea johtavat pääsääntöisesti sote-ammattilaiset, joilla on vähäisesti edellytyksiä toteuttaa vaativia teknisiä hankintoja tai käyttäjäkeskeistä tuotemuotoilua.
3. Ohjelmistohankintaprosessit ovat erittäin vaikeita viedä läpi menestyksekkäästi.
4. Sote-järjestelmillä on paljon eksoottisia kytkentöjä esimerkiksi lääketieteellisiin mittauslaitteistoihin ja lainsäädännöllisiä rajoitteita.

Pureskellaan näitä yksi kerrallaan.

Monoliitit

Puhuin edellisessä kirjoituksessani ketterästä kehityksestä, joka siis on tapa kehittää ohjelmistoja nopeasti ja käyttäjäkeskeisesti. Kehitysmenetelmä ei kuitenkaan ota kantaa siihen, mikä kehitettävän tuotteen sisäinen rakenne on. Ohjelmistot voivat olla tiukasti kytkettyjä monoliitteja tai löyhästi kytkettyjä modulaarisia kokonaisuuksia. Jälkimmäistä pidetään yleensä tavoiteltavana, koska järjestelmän uudistaminen ei silloin edellytä täydellistä uudelleen kirjoittamista. Laadukas modulaarisuus kuitenkin edellyttää lahjakkaita kehittäjiä, hyvää suunnittelua ja liiketoimintaa johtavilta halua sitoutua modulaariseen arkkitehtuuriin.

Modulaarisia arkkitehtuureja on monenlaisia, mutta meidän tavoitteidemme kannalta tärkeimpiä ovat sellaiset, joilla on avoimia rajapintoja. Rajapinnat mahdollistavat ohjelmistojen kytkemisen toisiinsa, ja avoimet rajapinnat ovat niin hyvin dokumentoituja että yhteensopivia ohjelmistoja voivat tehdä muutkin kuin alkuperäinen kirjoittaja. Avoimiin rajapintoihin ei siis voi kytkeytyä kuka vain, mutta kuka vain voi kirjoittaa ohjelmiston, jonka omistaja voi valtuuttaa.

Suurin osa markkinoilla olevista ohjelmistoista on kuitenkin monoliitteja, ainakin siinä mielessä että niihin ei ole laadukkaita rajapintoja. Tämähän torpedoi täysin edellisessä kirjoituksessa esittämäni mallin, jossa tiettyyn, innokkaaseen pilottiyksikköön tehdään vaihtoehtoinen järjestelmä tiettyyn käyttötarkoitukseen. Omistaja voi tilata toimittajalta rajapinnan, mutta toimittajalla ei tietenkään ole insentiivejä tehdä niitä, koska omistaja voi hivuttaa hiljalleen toimittajan järjestelmän tarpeettomaksi.

Tässä tullaan ensimmäiseen ongelmaan: kun markkinoilla on pelkkiä monoliitteja ja toisaalta hankkija ei osaa/voi vaatia rajapintoja tarpeeksi jämäkästi, koko ajatus ketterästä kehityksestä kaatuu.

Tähänkään ongelmaan ei ole hopealuoteja, vaan tarvitaan rauhallista ja määrätietoista kehitystä kohti avoimia rajapintoja. Kun rajapinnat on saatu, voidaan kilpailuttaa ohjelmistotaloja tekemään uusia käyttöliittymiä mahdollisesti huonosti toimivien tilalle.

Johtaminen

Kuvasin edellä karkealla tasolla ohjelmistohankinnan keskeistä ongelmaa, eli toimittajaloukkua. Toimittajaloukkoon on helppo päätyä, jos päätöksentekijä on substanssiammattilainen omalla alallaan ja tekniset kriteerit eivät ole yhtä tärkeitä kuin toiminnalliset kriteerit. Tarkoitukseni ei ole aliarvioida tai katsoa nenääni pitkin sote-ammattilaisia, vaan todeta että eri ammattikunnilla on erilaiset tavoitteet. Jos substanssiammattilaiselle sanoo, että tätä järjestelmää käytetään menestyksekkäästi näin monessa sairaalassa, se tukee automaattisesti kaikkia teidän MRI-laitteitanne ja käyttäjäkokemus on hioutunut miljoonien käyttötuntien kautta, insinöörin ruikutus rajapinnoista kuulostaa tarpeettomalta hifistelyltä. Miksi antaa insinöörien sörkkiä jo toimivaa järjestelmää?

Tämä on tietenkin karikatyyri, mutta on joka tapauksessa helppo päätyä loukkuun jossa käyttökokemukseltaan ja rajapinnoiltaan tiukasti integroitu järjestelmä ei muutukaan muuttuvien prosessien (moi, sosiaali- ja terveysalan tietojärjestelmäintegraatiot!) mukana. Tiukka integraatio mahdollistaa tehokkaan kehityksen, mutta sieltä yksittäisen moduulin korvaaminen jonkun toisen tekemällä onkin sitten mahdotonta.

Huonon tietojärjestelmän vaikutukset johtamiseen ovat pirullisia. Tekninen velka on kuin öljyä rattaissa: ensin rattaat pyörivät mukavasti nopeammin, mutta jos öljyä ei aika ajoin siivota pois, alkaa siihen kertyä likaa ja nöyhtää. Lopulta rattaat ovatkin tahmeammat kuin aloittaessa. Järjestelmään saattaa jäädä pieni käytettävyyskukkanen, josta käyttäjät jaksavat aluksi valittaa. Sitten se jää korjaamatta vuodeksi, toiseksikin. Käyttäjät menettävät uskonsa kehittämisprosessiin, kyynistyvät ja valittavat järjestelmästä vain kahvipöydässä. Ja isommatkin virheet jäävät raportoimatta, kunnes joudutaan tekemään potilasturvallisuusilmoituksia.

Virheet ovat voineet jäädä korjaamatta arkkitehtuurin vuoksi, tai sitten säästöpäätösten. Toimittaja on voinut hinnoitella korjauksen korkeaksi tai korjauskierroksilla se on aina priorisoitu niin alas, ettei sitä ole korjattukaan. Eikä toimittajalle ole kilpailijaa. Luonnollisia syitä, mutta lopputuloksena on organisaation jähmettyminen ja kyynistyminen.

Ohjelmistohankinnat

On aivan eri hommaa hankkia ohjelmisto kuin ostaa kyniä tai silta. Kynät ovat helppoja: määrittelet tekniset kriteerit, keräät tarjouksia eri toimittajilta ja hyväksyt halvimman kriteerit täyttävän tarjouksen. Sillan hankkiminen on vaikeampaa: hyvän sillan rakentaminen vaatii ammattitaitoa ja kykyä muovata tarjottu tuote haluttuun paikkaan. Siltoja on kuitenkin rakennettu satoja vuosia, ja on olemassa melko selvä, tylsähkö prosessi jolla silta saadaan paikalleen - ellei ostaja halua jotain aivan poikkeuksellisen eksoottista.

Ohjelmistokehitys on nuori insinööriala. Sitä on tehty vakavasti vasta seitsemisenkymmentä vuotta, ja siitäkin ajasta hyvin pieni osa on tapahtunut nykyisessä mittakaavassa. Parhaat käytänteet ovat vielä käymistilassa ja - toisin kuin sillat - ohjelmistot ovat melko vaativia otuksia käyttäjilleen. Toisin kuin sillan kanssa, asiakas harvemmin tietää vielä tilatessaan, mitä oikeasti tarvitsee.

Ohjelmistokehittäjien hipsterimmällä osastolla tunnetaan Cynefin-malli, jolla voidaan mallintaa päätöksentekoa erilaisissa toimintaympäristöissä. Jos tunnemme hyvin kausaalisuhteet (mikä aiheuttaa mitä) ja riippuvuudet (minkä rajojen sisällä kuljetaan), voidaan löytää optimaalisia toimintatapoja. Toimitaan yksinkertaisessa (clear) ympäristössä. Tämä on kynien hankintaa, jota voidaan tehdä ottamalla oppikirjasta optimaalinen seuraava askel.

Kun syy-seuraussuhteet ovat selkeät, mutta riippuvuudet aukeavat vain asiantuntijalle, ollaan vaikeassa (complicated) ympäristössä. Tämä on siltojen rakentamista: oppikirjat eivät enää riitä, vaan tarvitaan kokemusperäistä intuitiota oikeiden ratkaisujen löytämiseen.

Mutta mitä tapahtuu, kun emme oikeastaan enää tiedä mitä haluamme? Luulemme tietävämme mitä käyttäjät haluavat, mutta järjestelmän nähdessään he haluavatkin jotain muuta. Oma toimintamme muuttaa syy-seuraussuhteita ja siitä seuraa soppa, jota kutsutaan kompleksiseksi (complex) toimintaympäristöksi. Kompleksisessa ympäristössä edes asiantuntijan intuitio, saati oppikirjat, eivät auta vaan pitää siirtyä kokeilevaan toimintamalliin.

Mitä sanoit? Että miten tämä käsitehimmeli liittyy mitenkään ohjelmistohankintoihin?

Niin. Julkisissa hankinnoissa on periaatteessa yksinkertaiset pelisäännöt: määritellään toimitettava tuote, haetaan tarjoukset, otetaan kokonaistaloudellisesti edullisin tarjous ja toteutetaan se yhdessä toimittajan kanssa. (Eihän se ihan näin mene - on puitehankintoja, suorahankintoja, JIT 2015:n ketterän kehityksen ehdot…) Mutta entä jos - kuten totesin - emme tunne edes ohjelmistokehityksen mahdollisuuksien rajoja, miten voisimme edes tietää etukäteen miltä muutenkin kompleksisessa sote-ympäristössä toimiva järjestelmä näyttäisi? Entä jos IT-järjestelmän mahdollisuudet saavatkin meidät muuttamaan prosesseja?

Tilanteessa pelataan vaikeilla pelisäännöillä kompleksisessa ympäristössä, ja se on aina tuomittu epäonnistumaan.

Tämän lisäksi tietenkin julkisten hankintaprosessien sääntely aiheuttaa omat (ylitettävät) haasteensa, mutta siinä on tapahtunut viime vuosina jo paljon kehitystä. Esimerkiksi Helsingin kaupungilla tapahtuu paljon mielenkiintoisia asioita aiheeseen liittyen.

Eksoottiset vaatimukset

Viimeinen, vaan ei vähäisin, on yleinen usko että sote-tietojärjestelmät ovat jotenkin erityisiä. On lääketieteellistä kuvantamista, erityisiä diagnostisia kriteerejä, raportointi- ja käyttöoikeusvelvoitteita, tietosuoja/-turvastandardeja… Ja nämä ovat ihan oikeita rajoitteita, kyllä. Ne eivät kuitenkaan eroa mitenkään laadullisesti kaikista muista erityisohjelmistojen rajoitteista.

Ohjelmistoalan ammattilaiset ovat erikoistuneet tunnistamaan vaatimuksia ja rakentamaan ne toteuttavia ohjelmistoja. Ongelmallista ei ole niinkään se, että sote-alalla on erikoisia vaatimuksia, vaan se että edellä mainittujen syiden vuoksi päädytään ostamaan erityisjärjestelmiä harkitsematta mahdollisuutta alkaa rakentaa ekosysteemiä.

Sote-IT:n ekosysteemi

Nyt alkaa hullu ideapuhe. Tänään Twitterissä huudeltiin, että Suomeen tarvitaan Yksi Potilastietojärjestelmä, joka tietenkin voisi olla maanmainio Esko.

Itse haluaisin ajatella laajemmin: entä jos Suomessa olisi laadukkaiden sote-ohjelmistokomponenttien ekosysteemi? (Ekosysteemi-sana herättää varmasti tätä lukevissa ohjelmoijissa pahennusta pöhinäisyyden vuoksi, mutta malttakaa hetki.)

Ekosysteemissä meillä ei olekaan Yhtä Oikeaa Potilastietojärjestelmää, vaan joukko yhteisesti määriteltyjä rajapintoja. Kuka tahansa voi tulla markkinoille uuden radiologian käyttöliittymän kanssa, tuoda sen valtion sote-markkinapaikalle ja hyvinvointialueet tai yksittäiset yksiköt voisivat ottaa sen sieltä kokeiluun. Jos kokeilu onnistuu, ostetaan lisenssi ja tehdään yhdessä mahdollisesti tarvittavat muutokset.

Tämä avaisi sote-tietojärjestelmien markkinoita, koska toimittajan ei tarvitsisi enää olla CGI:n kaltainen Leviathan, koska ei tarvitse hallita monimiljoonarivistä tietojärjestelmää. Moduulien rakentaminen sopii pienemmällekin nyrkkipajalle - tai jopa hyvinvointialueen omalle Skunkworks-ryhmälle.

Oma moduulikehitys avaisi vielä enemmän ikkunaa prosessien kehitykselle: kun käyttäjät voisivat kävellä sairaalan kellariin pyytämään päivittäistä työtä helpottavia ominaisuuksia, avautuisi ikkuna laajemminkin prosessien uudelleen miettimiselle. Hoitoapulaiselta voi tulla vähintään yhtä arvokasta palautetta kuin lääkäriltä, ja hierarkiat madaltuisivat kohti aidosti kollegiaalista työympäristöä.

Yhteinen ekosysteemi tukisi myös muita tavoitteita. Kun rajapinnat ovat yhteisiä, olisi helppo jakaa kokemuksia ja prosesseja hyvinvointialueelta ja yksiköltä toiselle. Emmekä tarvitsisi erillislainsäädäntöä korjaamaan hillittömän osaoptimoinnin tuloksia, jotta edes tieto saataisiin kulkemaan järjestelmästä toiseen.

Vision toteutuminen vaatii uskallusta vaatia enemmän ohjelmistoarkkitehtuurilta, kykyä kuunnella teknisiä asiantuntijoita, ketteriä toimintatapoja ja uskoa siihen, että sote-IT on vain ATK:ta ATK:n joukossa. Siksi kannattaa aluevaaleissa äänestää nörttiä.