IT-ammattilainen tarkastelee valintaprosessia

Osa 1: puhetta laadusta

Apotti-hanke on nyt syyskuussa edennyt vaiheeseen, jossa hanketoimisto on yksityiskohtaisen valintaprosessin päätteeksi päätynyt esittämään Yhdysvaltalaista EPIC:iä tulevaksi Apotti-toimittajaksi.

Apotti-hankkeen teknologiajohtaja Jari Renko, miltä valintaprosessi näyttää juuri nyt IT-ammattilaisen näkökulmasta?

Jari: on ollut todella hienoa päästä osallistumaan julkiseen hankintaan, jossa on otettu laadulliset ja toiminnalliset tekijät tosissaan. Hankinnan aluksi määritellyt hinta- ja laatukriteerit olivat painoarvoiltaan 40 % ja 60 %, joten toiminnallinen laajuus ja laatu olivat keskeisessä osassa koko hankintaprosessin ajan.

Laadun korostaminen on ymmärrettävää, kun tarkastelee järjestelmillä ohjattavan toiminnan laajuutta ja kriittisyyttä. Vuositasolla 3,11 miljardin euron suuruista SoTe-kokonaisuutta tulee ohjata välineillä, joilla se onnistuu mahdollisimman ketterästi ja tehokkaasti. Lisäksi SoTe-toiminnassa esimerkiksi potilasturvallisuus ja asiakkaan osallistaminen oman asiointinsa omistajaksi ovat keskeisiä tavoitteita joita pystytään hyvin edesauttamaan moderneilla IT-työkaluilla.  Laadun painottaminen tulee tässä yhteydessä varmasti maksamaan itsensä takaisin.

Mitä tarkoitat tässä laadulla? Eikö tässä ole riski siihen että hankitaan sokkona ylilaatua?

Jari: Laatu ei tässä hankkeessa ole ollut missään mielessä abstrakti tai epämääräinen hankittava ”suure”.Termi ”laatu” tarkoittaa tämän hankkeen yhteydessä muun muassa kaikkia niitä toiminnallisia asioita, joita toimivan potilas- ja asiakastietojärjestelmäkokonaisuuden tulee sisältää.Tuotteita vertailtiin ja pisteytettiin muun muassa yksityiskohtaisia terveydenhuollon ja sosiaalihuollon lähtökohdista tehtyjä käyttäjätarinoita ja niiden vaatimuksia vasten.

Laaja tuotevertailu tehtiin monen ammattilaisen, yhteistyötahon ja kansalaisen voimin

Käyttäjätarinat kuljettivat testaajia simuloidusta tilanteista toiseen jolloin tarkasteltiin ohjelman käyttäytymistä ja käyttöä eri tilanteissa; Miten äskettäin rekan alle jääneen motoristin elintoiminnot esitetään päivystyksessä? Entä teho-osastolla? Leikkaussalissa? Miten tieto kokonaislääkityksestä seuraa potilasta ja tuottaa tietoa ja asianmukaisia hälytyksiä eri toimenpiteiden yhteydessä? Miten sosiaalihuollon palvelutehtävässä näkyy asiakkaan kokonaistilanne joustavasti, mutta kuitenkin huomioiden lainsäädännön vaatimukset suojattujen tietojen näkyvyyden rajaamisesta?

Näiden esimerkkikysymysten tarkastelu on vain murto-osa laajan tuotevertailuosuuden aikana läpikäydyistä tehtävistä. Lisäksi tarkasteltiin tuotteiden muokattavuutta, vaatimusmäärittelyjen toiminnallisten ja ei-toiminnallisten ehtojen täyttymistä, toimittajan nimeämien avainhenkilöiden osaamista, avointen rajapintojen toiminnallisuutta sekä ohjelmiston ylläpidettävyyttä. Kaikkiin valintakriteereihin voi tutustua yksityiskohtaisemmin lukemalla hankintapäätöksen julkiset perustelumuistiot.

Mukana tässä arvioinnissa on ollut yhteensä noin 500 terveydenhuollon, sosiaalihuollon ja IT-ammattilaisen lisäksi laajalti myös hankkeen ulkopuolisia tahoja kuten VTT, Tampereen Yliopiston tietojärjestelmätieteen laboratorio, Aalto-yliopiston käytettävyyslaboratorio sekä kansalaiskäyttäjistä koostettu koekäyttäjäraati. Myös sähköisten asioinnin portaaliin esteettömyyden arviointi on tehty yhteistyössä Kehitysvammaliiton kanssa.

Osa 2: puhetta tuotevalinnasta

Apotti-hankkeen yhteydessä puhutaan paljon tuotevalinnasta. Mitä tämä tarkoittaa? Eikö kyseessä olekaan ohjelmistoprojekti?

Jari: alusta alkaen on ollut selvää että painotamme tässä hankinnassa ratkaisuja jotka perustuvat tuotteistettuihin ratkaisuihin ja yleisesti käytössä oleviin teknologioihin.

Kaikilla tähän hankintaan osallistuneilla hankintarenkaan osapuolilla on organisaatioina pitkä, usein kymmenien vuosien kokemus pala palalta etenevän IT-tuotekehityksen tukemisesta ostajina, määrittelijöinä, testaajina ja viimekädessä tämän kehitystyön maksajina. Näiden tuotekehitysprojektien tuloksena on siis rakennettu nykyiset, varsin laajat järjestelmäkokonaisuutemme joiden varassa SoTe- sektorimme nyt toimii.

Tälle hankkeelle määritellyn strategian vaatimuksena on ollut että riskialttiin tuotekehitysprojektin sijaan arvioidaan ja valitaan valmiisiin rakenteisiin ja komponentteihin perustuvia ratkaisuja; arviointien kohteena on monista ohjelmistohankkeista tuttujen PowerPoint- kalvojen ja myyjien lupausten sijaan vaadittu arvioitavaksi ensisijaisesti jo toimivia ohjelmistokomponentteja.

Nyt on siis haluttu järjestelmä, joka on (alusta alkavaan tuotekehitysprojektiin verrattuna) varmuudella käytettävissä ennakoitavissa olevan ajan ja kustannusten puitteissa. Nykyisten järjestelmien ylläpito on monimutkaista ja kallista ja niiden kehittämisen jäykkyys haittaa suoraan toimintamme kehittämistä yhä kiristyvien joustavuuden ja tehokkuuden vaatimusten mukaiseksi.

Näitä valmiita tuotteita ja komponentteja muokataan seuraavaksi alkavan käyttöönottoprojektin aikana vastaamaan kotimaista lainsäädäntöämme sekä yksityiskohtaisesi tukemaan juuri meille parhaiten sopivia
terveyden- ja sosiaalihuollon toimintamalleja. Varsinainen ohjelmointityö, siten kuten se on perinteisellä tavalla totuttu ymmärtämään, on vain hyvin pieni osa hankkeen kokonaislaajuutta.

Osa 3: puhetta MUMPS-kielestä ja toimittajaloukusta

Pystymmekö sitten lainkaan ohjelmoimaan hankittavaa järjestelmää? Mikä on se sosiaalisessa mediassa väittelyiden kohteena ollut MUMPS-kieli? Miten vältetään toimittajaloukku?

Jari: Nyt hankittavaksi ehdotettu ohjelmistokokonaisuus muodostuu useista ohjelmointikielistä ja teknologioista, joista keskeisimpänä ovat M ja Cache, joille Epicin tietokanta ja ”ydin” rakentuvat. M-kieli (eli MUMPS – Massachusetts General Hospital Utility Multi-Programming System) on terveydenhuollon sovellusten ohjelmointiin alun perin 1966 kehitetty ohjelmointikieli; sen erikoisuutena on tietokannan käsittely tavalla joka muistuttaa monien ohjelmointikielien tapaa käsitellä muistiavaruutta.

Kyseistä teknologiaa käytetään erityisesti suurissa, paljon nopeita transaktioita vaativissa sovelluksissa ja se on nykyään käytössä sadoilla tällaisilla asiakkailla erityisesti terveydenhuollossa ja pankkisektorilla. Kuriositeettina voisi mainita, että edellä mainittujen lisäksi M-teknologiaa käytetään modernissa avaruustutkimuksessa. European Space Agencyn (ESA) vuonna 2013 laukaisema GAIA-luotain nimittäin käyttää MUMPS:ia nimenomaan sen nopean ja tehokkaan tietokannan käsittelykyvyn vuoksi. Joidenkin arvioijien mielestä M-kieli on ollut erityisesti suurten datamassojen käsittelyssä edelläkävijä joka muistuttaa nykypäivänä Big Data- yhteyksissä suosittua NoSQL- teknologiaa.

Apotti-hankkeen tavoite ei kuitenkaan ole sitoa ekosysteemimme jatkokehitystä pelkästään hankkimamme tuotteen kehityskaareen; vaikka nyt hankittavaa valmistuotteista koostuvaa järjestelmäkokonaisuutta kehitetään jatkuvasti erittäin suuren asiakasjoukon tarpeiden perusteella, on eräs keskeinen tavoite kuitenkin tämän lisäksi oman Apotti-ohjelmistoekosysteemimme rakentaminen. Näin voimme jatkossa tehdä itse tai itse valitsemiemme kumppaneiden kanssa erillissovelluksia, jotka kytkeytyvät Apotti- kokonaisuuteen esim. SOA- rajapintojen tai asiakasportaalien tarjoamien tiedonvälitysrajapintojen ja ohjelmistokutsujen avulla. Näiden lisäksi hankittavan ratkaisun seuraavan version roadmapilla on
eräs erityisen kiinnostava uusi kehittyvä standardi, FHIR, joka pohjautuu olemassa oleviin avoimiin standardeihin kuten REST, CSS ja OAuth. FHIR mahdollistaa näyttävien käyttöliittymien toteutuksen ja integroinnin, jopa eri toimittajien järjestelmien välillä.

Oman jatkokehityksemme varmistamiseksi tarvitsemamme rajapinnat ovat olleet keskeisessä roolissa hankkeen tuotevalinnan pisteytyksessä. Olemme lisäksi edellyttäneet kaikilta hankintaan osallistuneilta tarjoajilta jo hankinnan varhaisesta vaiheesta lähtien sitoutumista siihen, että saamme näin määrittelemämme rajapinnat omaan käyttöömme täysin toimivina ja ilman joillain markkinoilla käytännöksi muodostunutta erillistä transaktiokohtaista käyttökorvausta.

Lisäksi tulemme kouluttamaan käyttöönottohankkeen aikana noin 100 EPIC -sertifioitua, järjestelmän mukauttamiseen koulutettua henkilöä, jotka siis jatkossa tekevät Apottiin juuri niitä toiminnallisuuden muokkaustehtäviä, joihin nykyisten järjestelmien kanssa tarvitaan poikkeuksetta järjestelmätoimittajan erikseen tarjoama ja hinnoittelema ohjelmistokehitysprojekti. Nämä henkilöt tulevat jatkossa olemaan julkistoimijan palveluksessa, osin IT-henkilöstöä ja osin terveydenhuollon ja sosiaalitoimen ammattihenkilöitä.

Oma arviomme on, että Apotin yhteydessä tulemme merkittävästi parantamaan omia edellytyksiämme muokata omistamaamme järjestelmää itsenäisesti, omin voimin ja ilman ulkopuolisille tahoille valuvia kustannuksia.

Sanalla sanoen; monien nykyisten järjestelmien yhteydessä vallitseva lähes täydellinen toimittajaloukkutilanne helpottuu merkittävästi Apotin käyttöönoton yhteydessä.