Espoo, Epic ja Apotti

Tilanne nyt, 30.1.2013:

Apotti on Helsingin ja Uudenmaan sairaanhoitopiirin (HUS) sekä kuuden pääkaupunkiseudun kunnan hanke potilastietojärjestelmän hankkimiseksi yhdessä. Hankintapäätöksiä tehdään parhaillaan ja järjestelmä on tarkoitus valita loppuvuodesta.

EPIC on wisconsinlaisen Epic Systems Corporationin toteuttama potilastietojärjestelmä, jota Accenture tarjoaa HUSille ja kunnille. Hankkeen alkuvaiheet ovat herättäneet huolen, että kilpailutusta olisi pedattu niin että Epic voittaisi sen.

Espoo on Helsingin länsiosissa sijaitseva 250 000 asukkaan kunta, joka päätti juuri olla lähtemättä mukaan Apotti-hankkeeseen.

Viikko sitten Accenture ja Epic Systems Corporation järjestivät Epicin esittelyn pääkaupunkiseudun valtuutetuille. Paikalla oli tusinan verran valtuutettuja Vihreistä, Perussuomalaisista, Kokoomuksesta ja RKP:stä. Tilaisuudesta löytyy laaja FB-kommenttithreadi, mutta yhteenvedon ja tulkinnan lukee helpommin tästä. Kaikki tiedot perustuvat Epicin asiantuntijoiden vastauksiin, poislukien mahdolliset väärinymmärrykseni.

Ensinnäkin Epic on käytettävyydeltään oikeasti hyvä. Tai no, selvästi parempi kuin nykyään suomessa käytössä olevat järjestelmät. Monimutkaisen ammattilaistyökalun käyttäminen ei ole ihan yksinkertaista hommaa ikinä. Mutta ainakin demossa klikkailumäärät vaikuttivat järjellisiltä eikä tiimalasia tarvinnut tuijottaa.

foo
Epic Systems Corporationin edustajat pyysivät etten julkaisisi tilaisuudessa ottamiani kuvia. Siksi tässä on Nuutti Hyttisen kännykkäkuva, jonka hän ennätti julkaista jo ennen pyyntöä.

Teknisesti EPIC sen sijaan on vanhanaikainen. Sen ydin on kirjoitettu 60-luvun MUMPS-kielellä, joka on nykynäkökulmasta naurettava ja suurin osa käyttöliittymästä on Visual Basicin versiolla 6, jonka virallinen tuki lopetettiin jo 2008. Kuulema tosin Epicillä on Microsoftin kanssa sopimus joka takaa riittävän tuen.

Suurempi ongelma on kuitenkin, että Epic on myös toimintamalliltaan vanhanaikainen. Se on yksi suuri järjestelmä, joka ratkaisee kaikki ongelmat. Kolmansien osapuolien lisäosia ei suosita. Itse asiassa Epic ei tarjoa rajapintoja kolmansille osapuolille lainkaan, vaan integraatioita tehdään ainoastaan asiakkaan suorasta pyynnöstä. Rajapintojen tarkemmasta luonteesta en saanut vastauksia.

Suljettuus menee niin pitkälle, että tosiaan edes kuvia käyttöliittymästä tai tarkkoja ominaisuuksia ei haluta näyttää julkisesti. Myyntitapa muistuttaa 80-luvun kabinettipolitiikkaa, jossa vain asianomaiset tietävät mitä oikeastaan ostettiin ja myytiin, ja hekään eivät saa sitä kenellekään kertoa. Sairaaloiden IT-maailma ei ehkä ole korruptoitunut, mutta siltä tämä taatusti näyttää. Epicin edustajien mukaan syy salailuun on, että sillä estetään kilpailijoita kopioimasta Epicin ominaisuuksia.

Mielenkiintoisesti, Epic kuitenkin tarjoaa koko lähdekoodinsa asiakkaan käyttöön (mutta vain asiakkaan, ei alihankkijoiden). Ensisijainen syy tähän on juridinen: kyse on escrow-palvelua vastaavasta ratkaisusta, jollaista isot asiakkaat usein vaativat. Koodi kuitenkin myös auttaa asiakkaan mahdollista omaa integraatiotyötä. Ilkeämielisesti voisi tulkita, että kyetäkseen käyttämään rajapintoja täytyy siis nähdä ne toteuttava koodikin.

Lähtökohtaisesti siis Epicin laajennokset ja jatkokehityksen tekee Epic Systems Corporation kampuksellaan Wisconsinin Veronassa (vastaa suunnilleen Lempäälää). Jos asiakas haluaa järjestelmältä jotain ominaisuuksia, ne joko löytyvät ennestään, Epic lisää ne järjestelmään niin parhaaksi harkitessaan, tai niitä yksinkertaisesti ei saa mistään. Tietojärjestelmä on käytännössä sama asia kuin toimintatapojen ohjaus, joten tällainen hallinnan menetys tarkoittaa, että terveydenhuollon toimintatapojen kehittäminen ulkoistetaan Wisconsiniin.

Modernit ohjelmistojärjestelmät perustuvat ”ekosysteemiin”, jossa kokonaisuutta orkestroiva yhtiö tekee vain ydinosat tarjonnasta, ja lukuisa joukko pienempiä yrityksiä kehittää kukin omia laajennoksiaan. Hyviä esimerkkejä ovat vaikka Salesforce, jonka asiakkuudenhallintajärjestelmään saa muokkauksia ja laajennoksia sadoilta yrityksiltä tai SAP, jonka toiminnanohjausjärjestelmä on pikemminkin ohjelmointialusta, jonka päälle konsulttitalot koodaavat toiminnanohjauksia. Tai alaa huonommin tunteville vertaus vähän kauempaa: vanha Nokian puhelinkehitys vastaan Applen ekosysteemi ja kaikki applikaatiot.

Ekosysteemiin on menty, koska mikään yksi yhtiö ei yksinkertaisesti pysty kehittämään todella monimutkaisia järjestelmiä kaikkia asiakkaita hyvin palvelevalla tavalla. Ekosysteemi tuottaa paremman lopputuloksen. Se myös sitouttaa asiakkaat paremmin. Vaikka kaikki innovaatiot ovat kilpailijoiden kopioitavissa, ei asiakas halua luopua ekosysteemistä, koska menettää kaikki sen sisältämät palvelut. Ajattele siirtymistä iPhonesta takaisin nokialaiseen.

Mutta kuten sanottu, Epic on ekosysteemin antiteesi. Epic on Nokia. Se on kilpailijoitaan edellä käytettävyydessä samaan tapaan kuin Nokian puhelimet olivat kymmenen vuotta sitten. Eli kilpailijat ovat vaan vielä huonompia. Nykyisillä toimintatavoilla se jää aikanaan väistämättä jälkeen, kun joku kilpailija kykenee ekosysteemin rakentamaan.

Teollisuuspoliittisesti Epicin suljettuus on isompi ongelma kuin STX:n risteilijätilauksen menetys. Uuden risteilijän hytit ja muuta alihankintaa tehtäneen Suomessa ja suurimman osan töistä tekevät samat puolalaiset aivan riippumatta siitä, onko telakka Turussa vai Saint-Nazairessa. Sen sijaan Epicin alihankintatöitä ei Suomeen tippuisi, ainoana poikkeuksena Accenturen asennusdiili.

Terveydenhuollon tarkoitus ei tietenkään ole tuottaa rahaa IT-yhtiöiden kassaan (vaikka toisin voisi joskus luulla alan sopimuskäytäntöjä katsoessa). Mutta kotimaisen alan teollisuuden alasajo on ongelma muutoinkin kuin taloudellisesti. Innovaatiot terveydenhuollon paremmaksi palvelemiseksi syntyvät tarpeiden ja mahdollisuuksien ristiaallokossa, silloin kun järjestelmää kehittävät ja sitä käyttävät ovat läheisesti tekemisissä. Sitä ei tapahdu samalla tavalla 8000 kilometrin päähän.

Siriuksessa visioitu yksi kansallinen potilastietojärjestelmä olisi kansallinen katastrofi. Se tappaisi Suomesta kaiken kyvyn kehittää ja innovoida terveydenhuollon järjestelmiä ja pikkuhiljaa heikentäisi terveydenhoidon laatuamme.

Espoon päätöksen tärkein seuraus onkin, että Apotista ja Epicistä ei voi sellaista tulla. Integraatiot on nyt pakko tehdä kunnolla, eikä voida yrittää kiertää niiden tarvetta kikkailemalla yhteisellä järjestelmällä.

Ehkä parasta mitä nyt voi tapahtua on, että Epic otetaan käyttöön yhdessä sairaanhoitopiirissä tai kunnassa Suomessa, mutta ei muualla. Silloin sen parempi käytettävyys asettaa standardin sille, miten kelvollinen järjestelmä toimii. Sitten käy se, mitä Epic yrittää salailullaan välttää, eli kilpailijat kopioivat sen käytettävyyden ja ideat. Pikkuhiljaa saattaa syntyä suomalaisia järjestelmiä osaksi kansainvälistä potilastietojärjestelmien ekosysteemiä.

Ajatus vain Suomeen tehtävästä järjestelmästä on osoittautunut huonoksi. Mutta suljettujen potilastietojärjestelmien siirtomaaksi ryhtyminen ei ole sen parempi idea. Pitää tavoitella kansainvälisesti toimivia järjestelmiä, joiden ekosysteemissä myös suomalaiset alan yhtiöt menestyvät. Suurin vastuu on nyt alan yrityksillä saada kerrankin jotain kelvollista tuotettua, mutta se vaatii, että julkishallinto ei estä kehitystä.

30 kommenttia artikkeliin ”Espoo, Epic ja Apotti”

  1. Tuosta Epicistä ja sen koodikielestä kyllä kiertää niin monia kauhutarinoita internetissä, että itselläni nousee karvat pystyyn pelkästä ajatuksesta.

    Tämä lienee tunnetuin: thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

    Mutta onhan noita: ”It is essentially a closed platform, which makes it challenging and costly for hospitals to interface Epic with clinical or billing software from other companies for the purpose of merging patient information. In addition to the software, customers pay dearly for hardware, and for the army of Epic-certified technicians that needs to be deployed to get the system up and running.”

    http://www.forbes.com/sites/zinamoukheiber/2012/04/18/epic-systems-tough-billionaire/

    Tosin onhan siinä hyväkin ajatus, että yksi kunta suostuisi ottamaan iskun tuon järjestelmän kanssa ja sen pohjalta voitaisiin kehittää sitten oikeasti toimiva järjestelmä. Sääliksi kuitenkin käy sitä kuntaa joka sen iskun ottaa, ja pahiten tässä pelottaa jos se on kotikuntani Espoo.

  2. Kerrankin voi olla ylpeä espoolaisuudestaan, olin positiivisella tavalla puulla päähän lyöty kun lukaisin uutisista kotiKAUPUNKIMME (huom. ei kunta:) päättäjien tekevän heti kautensa alkuun taloudellisesti merkittävässä asiassa päätöksen maksettujen äyriemme hyväksi eivätkä totuttuun tapaan peesaile itäistä naapuriamme ihan laput silmillä ja pyllistä meille asukkaille.

  3. Olisin käyttänyt tuossa vertauskuvana ehkä mieluummin Androidin ympärillä olevaa ekosysteemiä kuin iPhonea. Apple käyttää systeemissään sen kaltaista valtaa, että en mielelläni näkisi vastaavaa terveydenhoidon järjestelmien osalta (Apple on systeemissään sekä ainoa laitevalmistaja että ainoa, sensuuria harjoittava verkkokauppa). Android näyttää ehkä äkkiseltään Googlen vastaavalta viritelmältä, mutta Google ja sen verkkosovellukset on mahdollista kuitenkin tarvittaessa täysin ohittaa, kuten kiinalaiset sikäläisten kotimarkkinoiden halpapuhelinvalmistajat Android-kapuloissaan tekevät. No tämä oli pikkuseikka, pisteet Espoolle järjen käytöstä.

    1. Androidin ekosysteemistä itsekin pidän enemmän. Käytin Applea esimerkkinä, koska

      1) se kuitenkin yhäkin on tunnetumpi (Android-kännyköitä on toki enemmän, mutta Androidien omistajilla on usien ”Samsung” tai ”HTC” tms, eivätkä he tunne itse Androidia.)

      2) Apple osoittaa, että ekosysteemin rakentaminen ei sinänsä tarkoita välttämättä avointa koodia tai millään tapaa erityisen hajautettua hallintaa. Nämä kun voidaan kokea myös uhkina.

      Sitten kun ajatus tietojärjestelmäekosysteemistä on siäsistetty päätöksenteossa hyvin, rupean advokoimaan kovaan ääneen, miten juuri avoimeen koodiin ja hajautettuun valtaan perustuvat ekosysteemit ovat parhaita.

      Kirjottaja ei omista Applen tuotteita

  4. Hieno ja rohkea päätös Espoolta. Tervettö järkeä vielä sentään löytyy. Mutta, mutta. Mitäpä jos metropolialueen kuntien pakkoliitos on totisisnta totta kuten on ministerein ja muiden puheista ymmärrettävissä ja Espoo pakotetaan Helsingin ja Vantaan kanssa yhteen. Joutuuko Espoo silloin ottamaan käyttöön saman muiden jo hankkiman Apotti järjestelmän ja maksamaan siitö oman (jätti)osansa?

  5. EPICista tulee pakosti mieleen vanha Helsingin kaupungin potilastietojärjestelmä, joka oli jonkun pankin vanha systeemi. Se ei niinkään ollut ongelmallisin seikka, vaan sen vanhuus (kaiketi jostain 60-70 -luvulta myöskin). Haasteita riitti.

  6. Hieno juttu, kiitos. Kuitenkin karsastan tuota ekosysteemi-sanan käyttöä, mielestäni sitä voisi pyrkiä välttämään kun puhutaan tietojärjestelmistä. Toimittajathan tuota pakosta käyttävät mutta hyvä termi se ei ole. Syitä tähän on monia, esim Stallman: ”It is inadvisable to describe the free software community, or any human community, as an “ecosystem,” because that word implies the absence of ethical judgment.” (http://www.gnu.org/philosophy/words-to-avoid.html#Ecosystem)

  7. Suljettu järjestelmä todellakin tietää lisää rahanmenoa. Kilpailutuksia ei tarvitse enää tulevaisuudessa järjestää, kun toimittaja myy lisätyötä haluamallaan hinnalla.

    Määrittelykin luultavasti jää niin vajavaiseksi, että toimittaja voi myydä uutta työtä vaikka kuinka paljon. Vasta tämän jälkeen ohjelmistolla on tarvittavat perusominaisuudet.

    Ohjelmiston toimittaja nauraa matkalla pankkiin.

  8. Aika hurjaa lukea noita Mumps juttuja. Huhut kertovat ettöä Kuopion seudulla olisi joskus (arvellaan että ovat jo eläkeiässä) ollut jotain harvoja Mumps osaajia mutta tuskin muualla Suomessa. Ja tuo Visual Basici 6 ja Mumpsin välinen integraatio kuullostaa aika aataminaikuiselta. Sinänsä VB on mielestäni ihan käyttökelpoinen kieli mutta soisi käytössä olevan välineet, joille saa Microsoftin tukea.

  9. En malta olla laittamatta tähän linkkiä
    http://www.talouselama.fi/kumppaniblogit/sahkoiset+terveyspalvelut+verkkopankkien+tasolle/a2165915
    Kirjoitus oli suurimalta osin OK. Mutta hiukan alkoi ihmetyttää onko Amerikassa todella kaikki noin hyvin ja onko meillä Suomessa jotenkin asiat noin huonosti kuin ne kirjoituksessa esitettiin. Siinä yhteydessä aloinkin katsoa kirjoittajatietoja. Jos oikein ymmärsin lukemaani ei kyse ollut kenestä tahansa suomalaisesta joka oli mennyt töihin amerikkalaiseen sairaalan vaan kirjoittaja oli Accenture nimisen yrityksen henkilöstöä. Yrityksen joka on Apotti -järjestelmän edustaja Suomessa. Haistoin kirjoituksessa piilomainontaa vaikka se olikin jotenkin verhottu kumppanuusblogiksi. Mutta sieltähän se selvisi. Se oli Apotti jårjestelmää edustavan Accneture yrotyksen blogi.

  10. SAPia ei ehkä kannattaisi myöskään käyttää tässä erityisen hyvänä esimerkkinä. Vaikka SAP on avannut rajapintojaan kolmansille osapuolille (ja siinä mielessä näyttää hyvää esimerkkiä), sen ydin kuitenkin perustuu myös vanhentuneeseen tekniikkaan. Kyllä siihen on päälle liimattu sen sellaista kuorrutetta, mutta samaa legacy-kamaa siellä pohjalla on. SAPin ABAP-konsultit laskuttavat ihan muikeita hintoja, tosin heitä sentään Suomessakin on.

  11. Demotilaisuuksista ei pysty päättelemään miten järjestelmä todellisuudessa toimisi. Konsultin näyttämää demoa ei voi testata ja verifioida suorituskyvyn, tietoturvan ja monen muun vastaavan seikan osalta. Kun kyseessä on suljettu monoliitti, näissä osa-alueissa olevia ongelmia tai rajoitteita ei luultavasti voi korjata mitenkään.

    SAP on tässä suhteessa varoittava esimerkki. Rajapinnat ovat kyllä ”avoimia” mutta järjestelmän ydin on täynnä 80-luvulla kovakoodattuja rajoitteita, joille ei kukaan voi mitään. Kallispalkkaisia konsultteja pyörii kiertämässä näitä ongelmia. Avoimuuden ansiosta joskus kyllä kelpaa halvempikin konsultti – been there, done that, mutta toista kertaa en SAP:n lähelle mene.

    En tiedä mikä julkista sektoria näissä IT-monoliittihankinnoissa vaivaa, mutta en ole koskaan nähnyt onnistunutta megaluokan monoliittijärjestelmää enkä edes kuullut sellaisesta. Muiltakaan aloilta niitä ei tietääkseni löydy. Autoteollisuus on perinteisempi insinööriala, mutta ei kukaan yritä rakentaa autoja siten että moottori, vaihdelaatikko, kytkin ja kaikki mahdollinen on integroitu yhteen vaan rakenne on modulaarinen tarkoituksella ja hyvistä syistä. Ja auton arkkitehtuuri on avoin – osia voivat valmistaa ja vaihtaa muutkin kuin auton alkuperäinen valmistaja.

  12. Toisaalla samana päivänä: ”The team discovered that evolution produces modules not because they produce more adaptable designs, but because modular designs have fewer and shorter network connections, which are costly to build and maintain. As it turned out, it was enough to include a ”cost of wiring” to make evolution favor modular architectures.”
    http://www.sciencedaily.com/releases/2013/01/130130082300.htm

    Monoliittiset järjestelmät ovat kalliimpia rakentaa, kehittää, ylläpitää ja muuttaa, koska niissä on liikaa sisäisiä (rikkimeneviä) liitoksia. Rajapinnat mahdollistavat modulaarisuuden.

  13. Kyllä niitä mumps-osaajia vielä Stadistakin löytyy jokusia. Mumps tai M on relaatiotietokannoista totaalisesti poikkeavan tiedontallennus- ja hakutapansa ansiosta äärimmäisen suorituskykyinen järjestelmissä, joissa transaktioita voi syntyä miljoonia päivässä. Siksi se on ollut suosittu terveydenhuollon ja finanssialan järjestelmissä ja käyttökelpoinen edelleen (mm. M:ään perustuva InterSystemsin Caché on laajasti käytössä, käyttäjiä mm. ESA, US DoD, lukuisa joukko isoja jenkkisairaaloita, Suomessakin käytössä sairaaloissa).

  14. This thread kicks ass!

    Espoon pitäis valjastaa Otaniemen nörtit koodaamaan sellainen järjestelmä joka pieksee kaikki olemassaolevat! Sillä tehtäis miljardeja. 🙂

  15. Applesta puhuttaessa kannattaa muistaa että OS X ja iOS rakentuu hyvin pitkälle Open Source komponenteista joiden lähdekoodit Apple jakaa julkisesti aina uusien käyttöjärjestelmäpäivityksien yhteydessä. Näinpä Googlen Chrome ja Android selainten HTML renderointi-komponentti WebKit on itse asiassa alun perin pääosin Applen kehittämä. Nykyiset suljetutkin järjestelmät voivat siis olla suurelta osin avoimia – Epicin kaltaiset 100% suljetut monoliitit alkavat onneksi häviämään kartalta.

    Ks täällä: http://www.opensource.apple.com

  16. Puhutte mitä puhutte, mutta tuo M-tekniikka on erittäin hyväksi havaittu ja koettu tapahtumaintensiiviseen tietojenkäsittelyyn.

    1. M:n käyttöönotolle oli todellakin aikanaan hyvät perusteet. Potilastiedot ovat hyvin harvaa dataa, ja sopivat huonosti relaatiokantojen toimintamallille. Suuria potilastietojärjestelmiä ei luultavasti olisi voinut tehdä relaatiokannan päälle, ei edes vielä 90-luvulla.

      Mutta maailma on muuttunut
      1) relaatiokannat ovat tehostuneet valtavasti. Nykyaikainen klusteri pystyy jo paljoon
      2) NoSQL-kannat ovat tulleet vastaamaan vastaaviin harvan datan ongelmiin kuin M
      3) Se MUMPS nyt vaan oikeasti on nykynäkökulmasta järjetöntä.

      Vaikka M toimii, niin kyllä jokaisella sitä vielä käyttävällä yrityksellä pitäisi olla jo suunnitelmat miten siitä tullaan luopumaan ajan mittaan.

  17. Espoolle aploodit Apotin hylystä!
    M-kielestä innostuneille vaan intoa koodata systeemi sitten vaikka sillä.
    Kielen valinta ei ole pääosassa, vaan se, että vältetään ”infinite vendor lock” ja saadaan vapaat rajapinnat yhteensopivuuden varmistamiseksi muiden (tulevien) systeemien kanssa.

  18. Yksi luokka aika samantyyppisiä järjestelmiä tuon Epic:n kanssa ovat operaattoreiden asiakashallinta- ja laskutusjärjestelmät. Tästä alueesta löytyy varoittavia esimerkkejä, esimerkiksi julkisuudessakin ollut Elisan integroitu kokonaisjärjestelmä, joka perustuu Amdocs:n tuotteeseen.
    Kun kaikki voi olla kytköksissä kaikkeen, tarkoittaa se sitä, että pienikin muutos voi aiheuttaa ikäviä sivuvaikutuksia melkein minne vain ja siksi testaus on jatkuva ja iso kulu mihin suuntaan hyvänsä järjestelmää kehitettäisiinkään. Modulaarisessa arkkitehtuurissa toiminnallisuudet erotetaan toisistaan moduleihin ja nämä modulit näkyvät muile rajoitetun näkymän kautta, jolloin rajapintojen säilyessä voidaan muutoksia toteutettaa pienemmällä riskillä.

  19. Eiköhän MUMPSin käytön yleisyys johdu ihan tasan vendor lockin:sta. Isoja tietojärjestelmiä on aikoinaan myyty eikä isoilla asiakkailla ole keinoa uudistaa sitä. Vaihtoehto on joko käyttää vanhaa tai pistää kaikki uusiksi. Joka on, kuten Apotista näemme, sikamaisen kallista. Ja kun sitä vanhaa käytetään, pystyy se toimittaja käyttämään näitä isoja asiakkaita referenssinään.

    Nykyaikana näin ison rahamäärän polttaminen siihen, että ollaan täysin riippuvaisia yhdestä ainoasta toimittajasta ilman mitään taetta esim. muutospyyntöjen toteutumisesta, on vain typerää.

    Tässä lyhyt tarina vuodelta 2007. MUMPS ja VB sielläkin: http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx

  20. Kiitos Otso hyvästä kirjoituksesta! Tästä IT-alan ulkopuolinenkin pääsee kärryille mistä tässä apotti hankkeessa ja EPIC-järjestelmässä sekä onkaan kyse.

  21. Hieno kirjoitus! Sanot, että ”Ajatus vain Suomeen tehtävästä järjestelmästä on osoittautunut huonoksi.” En ole eri mieltä, mutta kertaatko vielä mitkä pääsyyt tähän on. Mikä tarkkaan ottaen kaatoi verkossa kiehahtaneen ajatuksen, että ”kyllähän asiantuntevat arkitehdit ja koodarit tuolla hinnalla koodaavat avoimesti ja modulaarisesti paljon paremman ja paljon halvemmalla kunhan vain näin päätetää ja ryhdytään hommiin” -ajatuksen mielestäsi?

  22. Paluuviite: Digi-isyyttä

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *