Helsingin terveyslautakunta päättää huomenna 11.9. käynnistää kilpailutuksen tietojärjestelmähankinnasta, jossa HUS ja alueen kunnat käyttävät yhteensä noin puoli miljardia euroa terveydenhuollon IT:n kokonaisvaltaiseen uusintaan. Tai siis luultavasti ei päätä, vaan hanke jää pöydälle ainakin kolmeksi viikoksi.
Tässä tekstissä käyn läpi hankkeen taustan, merkittävimmät riskit ja mitä sille pitäisi tehdä.
Taustalla on tavoite hankkia koko maan terveydenhuoltoon yhtenäinen tietojärjestelmä. Sitra selvitti tätä SIRIUS-hankkeessa, jossa selvityksen tehnyt Accenture päätyi suosittamaan, että ostakaa koko roska Accenturelta.
Alkujaan HUS:n ja kuntien hanke oli nimeltään SIRIUS 2, mutta kun Hesari uutisoi Accenturen roolista Siriuksessa, vaihtui nimeksi nykyinen APOTTI. Hankkeilla kun ei kuulema ole juuri mitään tekemistä keskenään. HUS:in hanketta vetävä hallintoylilääkäri Lasse Lehtonen ilmoitti että ”Kritiikki ei vaikuta HUS:n potilastietojärjestelmän hankintaan”.
Nyt päätöstä tekee siis Helsinki. HUS, Espoo, Vantaa, Kauniainen, Kirkkonummi, Kerava tekevät sitten kukin tahoillaan saman päätöksen. Tätä ennen kuntien virkamiestyöryhmä on ensin sen suljettujen ovien takana hyväksynyt. Menettelyä voi syystäkin pitää epädemokraattisena, mutta tätä kuntayhteistyö käytännössä on. Ei mennä siihen nyt, tulee vaan paha mieli.
 |
| Apotti Saint Dominic of Silos. |
Kyse ei ole pelkästä IT-hankkeesta. Päinvastoin, tavoitteena on uudistaa toimintatavat ja prosessit yhdenmukaisiksi ja järkeviksi. Tavoite on kiistatta hyvä. Pitää pyrkiä hyvään toimintaan, ja tietojärjestelmä on tässä vain apuväline. IT-hankkeiden hyödyt tulevat juuri toimintatapojen muutoksista; pelkkä vanhan toimintatavan siirto tietokoneelle ei tuo minkäänlaisia säästöjä vaan ainoastaan lisätyötä.
Yhtenä esimerkkinä hankkeelle on ilmeisesti toiminut USA:laisen Veterans Health Administrationin (VHA) uusiutuminen maan surkeimmasta terveyspalvelujen tuottajasta kärkijoukkoon vuosikymmenessä. VHA:ssa toteutettiin merkittävä toimintatapopjen uudistus, jonka yhteydessä vanha ja huonosti toimiva tietojärjestelmä päivitettiin pala kerrallaan nykyaikaiseksi. Venkatesh et al. kuvaavat artikkelissaan hyvin muutosta ja niitä toimintatapoja, joilla siihen päästiin.
Apotin tavoitelista on myös melkoinen toiveiden tynnyri. Tavoiteltu järjestelmä muun muassa:
- tarjoaa uusien innovatiivisten palvelujen käytön, asiakkaan oman osallistumisen ja sähköisen asioinnin. Asiakkaan vahvempi osallistuminen lisää tyytyväisyyttä ja voimaantumista vähentäen ulkopuolisen tuen tarvetta.
- toteuttaa parhaalla mahdollisella tavalla asiakkaan ja potilaan hoidon toteuttamista koko hoitoprosessin ajan riippumatta siitä, missä organisaatiossa kukin hoitoprosessin vaihe tapahtuu.
- tarjoaa sosiaali- ja terveydenhuollon prosessien tehokkaan ja taloudellisen integraation muiden organisaatioiden ja heidän asiakkaidensa prosessien kanssa.
- mahdollistaa sen, että kulloisessakin hoitotilanteessa asiakkaan ja potilaan ajantasaiset tiedot ovat luotettavasti käytettävissä.
- tarjoaa hoitoprosessin eri hoitotapahtumien tuen, ohjauksen ja seurannan.
- tukee uusien hoitoprosessien aktiivista kehittämistä ja edistää hoitoprosessin laatua, asiakas- ja potilasturvallisuutta sekä kustannustehokkuutta.
- tukee ammattilaista päätöksenteossa ja ohjaa standardin mukaisiin ratkaisuihin vähentäen toimintatapojen vaihtelua ja parantaen asiakas- ja potilasturvallisuutta sekä hoitotuloksia.
- mahdollistaa avoimet rajapinnat, joiden kautta kokonaisratkaisuun voidaan liittää tulevaisuuden tarpeita palvelevia lisätoiminnallisuuksia tai vaihtaa yksittäisiä ratkaisun osia.
- sisältää tiedonsiirtorajapinnan muihin tarvittaviin, kuten esimerkiksi hallinnollisiin järjestelmiin.
- on käyttäjäystävällinen.
- toteuttaa sähköisesti modernin käyttöoikeushallinnan, tietoturvan ja suojan sekä niihin liittyvät sujuvat käytännöt (hoitoketjujen hallinta / roolien mukaiset käyttöoikeudet).
- mahdollistaa yhteisen järjestelmän hallinnan ja hyödyntämisen usean erillisen järjestelmän sijasta.
- tukee vuoden 2011 alusta voimaan tulleen kotikuntalain muutoksen (1377/2010) ja terveydenhuoltolain (1326/2010) vuonna 2014 voimaan tulevan maanlaajuisen vapaan hakeutumisen sujuvaa toteuttamista.
- tuottaa hallinnolle ja tutkimukselle tarpeellisia tietoja
Onnistuneiden hankkeiden tavoitteet ovat yleensä kapeasti määriteltyjä ja täsmällisiä. Jos olisin päättämässä asiasta, kysyisin että täsmälleen miten jokainen näistä tavoitteista aiotaan saavuttaa ja miten sitä mitataan.
Minulla on hankkeen suhteen muutama spesifi huoli, niistä alla kolme tärkeintä:
- Yritetäänkö tässä ulkoistaa vastuuta?
- Riittääkö osaaminen?
- Onko valittu teknologia järkevä?
Vastuun ulkoistus
Lääkärilehdessä Lehtonen toteaa, että ”sairaanhoitopiirillä on huonoja kokemuksia järjestelmän kehittämisestä. Se haluaa ostaa valmiin tuotteen ja palvelun, jossa toimittaja vastaa ylläpidosta. Kehitysriski on silloin toimittajalla.”
Näkemys on sivistyneesti sanoen vaarallisen naivi ja herättää epäilyksen, ymmärretäänkö HUSissa oikeasti mitä ollaan tekemässä. Ei tilaajan tarpeisiin laajasti muokattavaa järjestelmää yksinkertaisesti voi ostaa noin. Tälläinen ”avaimet käteen”-toimitus antaa käytännössä toimittajalle avaimet käteen suoraan tilaajan kassaholviin.
Missään organisaatiouudistuksessa ei voida määrittää etukäteen kaikkia tarpeita. Päinvastoin, ja kuten mainittu VHA:n esimerkkikin osoittaa, on syytä edetä askel kerrallaan. Siksi nykyään suuretkin tietojärjestelmähankkeet pyritään tekemään ns. ketterillä menetelmillä, joissa ei sitouduta täsmälliseen määrittelyyn, vaan opitaan vaatimukset projektin aikana.
Tietenkin voidaan ajatella, että ketteryyttä sovelletaan toimittajayrityksen sisällä, ja HUS vaan saa mitä haluaa: toimivan järjestelmän. Mutta kuinka toimittava yritys voisi päättää sairaanhoitopiirin toimintaprosesseista, jota tässä siis ensisijaisesti haluttiin uudistaa? Ei mitenkään.
Vastuuta omista tietojärjestelmistään ei voi koskaan ulkoistaa. Tietojärjestelmiä tuntemattomalle syntyy helposti houkutus kuvitella että kokonaistoimitus ratkaisee ongelmat. Että IT-toimittaja kyllä hoitaa nämä IT-ongelmat. Mutta ei ole hoitanut tähän mennessäkään, vaan päinvastoin terveydenhuoltoalan IT:tä pidetään katastrofina.
On syytä myös huomata, että yllä mainittu Veterans Health Administration omistaa itse potilasjärjestelmänsä (VistA) lähdekoodin ja jakaa sitä avoimena lähdekoodina. En sano, että VistA mitenkään välttämättä sopisi HUSille, mutta oman tietojärjestelmänsä hallinta on VHA:n onnistuneen muutoksen ytimessä.
HUS ja kunnat sen sijaan tähätäävät malliin, jossa tilaajalla ei ole hallintaa tietojärjestelmään, vaan kaikki kontrolli on sysätty toimittajalle. Tämä asettaa HUSin täydelliseen toimittajaloukkuun. Mikään määrä määrittelyjä tai sopimusehtoja ei voi tätä loukkua välttää, mistä HUSilla pitäisi olla jo pitkä kokemus.
Kompetenssi
Sairaalamaailma on kuuluisa siitä, että lääkärintutkinto on avain etenemiseen, eikä muita kuin lääkäreitä haluta päästää johtopaikoille. Tämä näkyy myös Apotti-hankkeessa.
Apotin ohjaus- ja kehittämisryhmissä on yhteensä 47 jäsentä, joista nopeasti googlaten:
- 19 lääkäriä
- 23 erilaista hallintohenkilöä, juristia tai ekonomia
- 5 joiden työtehtävä liittyy tietohallintoon tai -tekniikkaan. Heistä
- 2 valtiotieteen maisteria
- 1 ekonomi
- 1 tradenomi (logistiikka)
- 1 jonka koulutus ei selvinnyt.
Näyttäisi siltä, että hanketta vetämässä ei kenties ole yhtäkään IT-alan minkäänlaista tukintoa suorittanutta henkilöä. Muutamilla toki on alan työkokemusta, mutta varsinaista koulutusta ei.
Suomalainen lääkärinkoulutus on vaativa ja korkeatasoinen. Se ei silti pätevöitä märittelemään suuria tietojärjestelmiä. Sitä varten on olemassa ihan omaa koulutustaan.
Teknologia
Apotti-hanke tähtää vahvasti yhteen monoliittiseen järjestelmään. Siis sellaiseen, joka tarjoaa ulospäin vain kauniisti toimivia rajapintoja ja käyttöliittymiä, eikä sisäisestä toteutuksesta tarvitse kenenkään olla kiinnostunut. Esimerkiksi hankkeessa kaikki tiedot halutaan tallettaa yhteen loogiseen tietokantaan (hankesuunnitelma, kappale 2.2.2).
Siis samassa kannassa kaikki tiedot, sisältäen muun muassa:
- hoitokertomukset
- asiakkaiden laskutustiedot
- sosiaalihuollon asiakastiedot (kyllä, joku on nekin tunkenut osaksi hanketta)
- sairaalan toiminnanohjaus sisältäen laitteistojen käytön
Moderneissa järjestelmissä vastuu pyritää pilkkomaan mahdollisimman pieniin osiin, jotta kukin osajärjestelmä voi tehdä yhden asian hyvin. Esimerkiksi SOA-arkkitehtuuri perustuu tähän periaatteeseen. HUS on valitsemassa vanhanaikaisen monoliittisen arkkitehtuurin, jossa kaikki integroidaan tiukasti yhteen. Tai mikäli pellin alla onkin hyviä rajapintoja, HUS ei halua niitä tietää, vaan ne ovat toimittajan sisäinen asia.
IT-alan yleinen kokemus on, että modernit arkkitehtuurit toimivat paremmin kuin vanhanaikaiset.
Ajatus yhtenäisestä järjestelmästä on ymmärrettävä, kun seuraa suomalaisten potilastietojärjestelmien kaaosta. Mutta ongelma ei ole järjestelmien hajanaisuus. Tanskassa vastaava kokonaisuus toimii hyvin. Ongelma on ostamisen tavassa ja osaamattomuudessa.
Yhteenveto
Onnistuvan laajan tietojärjestelmähankkeen lähtökohtana täytyy nähdäkseni olla:
- vahva oma osaaminen tietojärjestelmän kehittämisessä
- sen mahdollistama asiakkaan hallintaote siihen, mitä ja miksi kehitetään.
Epäonnistuvat hankkeet taas tunnistaa usien seuraavista merkeistä:
- Vaatimusmäärittely on maailmojasyleilevä: samaan hankkeeseen on kasattu kaikki maan ja taivaan välillä.
- Tilaaja pyrkii ulkoistamaan vastuun omasta järjestelmästään.
- Suunniteltu toimintatapa on epätarkoituksenmukainen eikä vastaa alan parhaita käytäntöjä.
Mitkään merkit eivät nyt viittaa siihen, että kumpaakaan onnistumisen avainkohtaa olisi saavutettu. Päin vastoin, epäonnistumislistalta löytyy rasteja.
Hankkeen oma riskianalyysi (hankesuunnitelma, kappale 6.7) ei näitä ongelmia tunnista. Se mainitsee kaksi riskiä: johtamisongelmat ja sen että entä jos hanke ei toteudu. Tietojärjestelmään tai hankintaprosessiin liittyviä riskejä ei mainita.
Päätösehdotus
No, mitä terveyslautakunnan sitten pitäisi päättää?
- Hankkeessa on syytä ottaa aikalisä, ja valmistella se uudelleen avoimemmin. Aivan erityisesti hanke on syytä valmistella siitä lähtökohdasta että kokonaisvastuu pidetään tiukasti tilaajan hyppysissä.
- Erityisesti on syytä katsoa malleja, jossa ei tehdä yhtä mammuttihankintaa, vaan vaihdetaan järjestelmiä pala kerrallaan perustuen tilaajan hallitsemaan kokonaisarkkitehtuuriin ja ketterään hankintaan.
- Tähän mennessä tehdyt selvitykset ja vertailut julkaistaan kaikki. Ainakin seuraavat dokumentit pitää julkaista
- Touko–kesäkuussa 2012 tehdyn ulkoinen riskiarvio (viitattu hankesuunnitelmassa, kappale 6.7.)
- HUSin selvitykset muissa Euroopan maissa tehdyistä vastaavista
- myös dokumentit, joiden olemassaolo ei toistaiseksi ole vuotanut julkisuuteen pitää julkaista
- Perehdytään tarkasti Viron ja Tanskan kokemuksiin ja mitä niistä voitaisiin oppia. Teetetään molemmista konsulttiselvitykset, mikäli olemassaolevat (julkaistavat) selvitykset eivät ole riittäviä.
- Tarvittaessa hankkeen johtoa vahvistetaan riittävällä tietojärjestelmäosaamisella. Konsultit eivät riitä korvaamaan oman osaamisen puutteita.
 |
| Suomen, Viron ja Tanskan ”eHealth-profiili” EU:n ”eHealt Benchmarking III” -raportissa |
Terveydenhuollon IT on Suomessa historiallisesti ollut suljettu luostari, jossa lääkärit päättävät keskenään mitä ja miten tehdään. Tuloksena on ollut katastrofi toisensa jälkeen. Se on ollut maan tapa.
Nyt on kyse siitä, onko apotti tullut luostarin portille avaaman sen ja kutsumaan rahvaan tutustumaan saleihin. Vai onko hän ehkä tullut nostamaan salvan säppiin, jotta mokailu ja sikailu voisi jatkua entiseen malliin.
Vastausta emme vielä tiedä, mutta se portti on avattava. Maan tapa on nyt tullut tiensä päähän.
Lisäisin yhden kysymyksen: Leikitään että tää Iisakin kirkko valmistuu joskus, ja sitten on kaikki prosessit yhtenäistetty sekä speksattu. Miten niitä muutetaan? Eli siis toi hankesuunnitelma näyttää minusta siltä että tehdään kerralla kaikki valmiiksi, ja lääketiede kuitenkin muuttuu koko ajan.
Eikö noissa ohjaus- ja kehittämisryhmissä ollut yhtään rivitason hoitohenkilökuntaa edustavaa jäsentä? Kyseinen ammattikunta kuitenkin on järjestelmän suurin käyttäjäryhmä.
Mitä titteleitä katsomalla vaikuttaa niin hoitohenkilökunta osallistuu johtajiensa välityksellä. Eli siis ei.
Iivanainen puhui viikko sitten, että hankkeen yhteyteen pyritään saamaan myös käytettävyysarviointi, mutta ilmeisesti siis vasta toimittajan valinnan jälkeen. Siinä käyttäjät pääsisivät siis testaamaan ja kommentoimaan järjestelmää. Pyritään saamaan, ja epäselvää on mihin se vaikuttaa.
Tämähän on vähän kuin sanottaisiin Lemminkäiselle, että tilaamme teiltä Suomeen tieverkon. Päättäkää itse, toimitatteko tänne Ruotsin vai Yhdysvaltain tieverkon ja tehkää sitten se.
Laittaisin hymiön, mutta tässä asiassa ei lopulta ole mitään hauskaa.
Suuri kiitos Otso K:lle ja muillekin blogisteille asian pitämisestä esillä. Hesarin verkkosivuilla oli asiasta juuri uutinen, ja siinä viitattiin nimenomaan verkkokeskusteluun. Toivottavasti nyt noussut haloo vaikuttaa päätöksiin asti.
Mun havaintoni mukaan lääkäreihin iskostetaan koulutuksessa semmoinen jännä kaikkitietävyyden asenne. Potilaita hoitaessa on tietysti hyvä olla asiastaan varma, ja siinä myös ulospäin annetulla varmuuden mielikuvalla voi olla sinänsä arvoa. Sivuvaikutuksena lääkärit tuntuvat sitten olevan harvinaisen innoikkaita pätemään asioissa, joista eivät oikeasti ole yhtään kärryillä.
Suomessa on kyllä oikeastikin tietojärjestelmähankintojen saralla osaamista, jolla tämmöinen hanke hyvin hoituisi. Ei ehkä julkisella sektorilla mutta muuten. Toivottavasti se saadaan käyttöön.
Lainaus tuosta artikkelista koskien tutustumiskäyntiä Tanskaan: ”On perustettava ”MedCom Finland” kehityksen katalysaattoriksi, ideoiden ja
kokemusten jakajaksi sekä yhteisten standardien sopijaksi…”
Tuohon tämä mielestäni kiteytyy. Tarvitaan suhteellisen puolueeton taho, joka ei ole valmiiksi suurten toimittajien tai myöskään suurten terveydenhuollon yksiköiden taskussa.
Terveyden ja hyvinvoinnin laitoksella (THL) on perustettu vähän aikaa sitten Oper-yksikkö (Sosiaali- ja terveydenhuollon tietohallinnon operatiivinen ohjaus). Se olisi se taho, josta ehkä voisi tulla suomen Medcom.
En tiedä sen enempää siitä miten Operin toiminta on lähtenyt käyntiin tai millaista osaamista siellä on. Täytyy perehtyä.
Ilmeisesti 80-luvulla suomalaiset kehittelivät VA:n kanssa VistA:aa (Meidän versio MUSTI, Mumps-pohjaisenen sairaalatietojärjestelmä). Nyt 2010-luvulla USA:ssa sairaalat ottavat n. 1/10 kustannuksilla (vs. Epic) VistA:aa käyttöön, public domainia kun on verovaroilla kirjoitettua. Täällä ilmeisesti poistunut enimmäkseen jo käytöstä, ilmeisesti vanhentuneena? Kai siinä on jotain vikaa ollut, ja USA:laiset ovat vaan tyhmiä, kun se on siellä jostain syystä suosituin järjestelmä?
Onko nyt niin, että alkuun liipaisimella on HUS:n järjestelmä ja helsinki päättää siitä ensimmäisenä. Mitäpä kun HUS valitsee järjestelmäkseen Accenturen kartoituksen perusteella Accenturen suositteleman, jonka valmistajana ja hinnoittelijana on Accenture, sidotaanko tällä päätöksellä koko Suomi tähän samaan järjestelmään? Tuskinpa muut sairaanhoitopiirit voivat valita mitään muuta järjestelmää, jos maahan halutaan yhtenäinen tietokanta. Arvasinko oikein?
Miten vastaavissa hankkeissa on yleensä pitänyt a)kustannusarvia b) aikataulu? Kuinka suurta kustannusarvion ylitystä voidaan odottaa realistisesti?
Arvauksesi kuulostaa täysin realistiselta. Ei toki ainoalta mahdolliselta kehityskululta, mutta juuri noinhan tätä ovat kai ainakin jotkut kaavailleet.
Kustannusarvioita haarukoi mm. Juuso Koponen.
Arvaan että kun järjestelmä on valmis, se ei toimi ilman Internet Explorer 6:tta.
Kivekkäällä on oleellinen huomio jutussaan: hankkeeen ohjausryhmään tarvittaisiin aivan ehdottomasti myös tietojärjestelmien osaajaa.
Sen sijaan en itse ole järin huolissani ”loogisesta tietokannasta”. Kysymyksessä on oman lukuymmärrykseni perusteella konseptuaalinen tietokanta, ei yksi fyysinen kanta.
Myös pointit hankesuunnitelman riskien kartoittamisesta ovat hyviä.
Omat kommenttini laajemmin:
http://ossimantylahti.puheenvuoro.uusisuomi.fi/116692-hus-potilastietoa-miljardeilla
Kiitos hyvästä jatkotekstistä Ossi! Erityisesti tuo vaatimus/toive-listan läpikäynti ja kommentaari on loistava.
Muutama kysymys tule kuitenkin mieleen (kysyn täällä, kun US-tunnarini menivät taas kiinni käyttämättöminä)
Mitä siis ihan käytännössä tarkoitat ehdotuksella: ”Hankinnassa pitää edellyttää useita toimittajia ja ratkaisua, jonka Suomessa pystyy toimittamaan joko osittain tai kokonaan vähintään kolme varteenotettavaa toimittajaa”?
Otetaan vaikka spekulatiivinen esimerkki, jossa järjestelmäksi valitaan Tiedon LifeCare ja toiset toimittajat olisivat Logica ja Accenture. Mitä ostetaan ja millaisin sopimuksin? En nimittäin ihan ymmärrä millaista toimintatapaa haet tässä takaa, ehkä käytännön esimerkki selvittäisi sen minulle.
Minulle tuli tuosta konsortiosta vähän mieleen se, miten Brittien terveydenhuoltouudistusta ilmeisesti tehtiin, eikä se ole lupaava esimerkki.
Toisena huomiona, että kokonaistaloudellinen edullisuushan periaatteessa tarkoittaa juuri sitä mitä haet. Käytännössä sitä vaan ei yleensä mitata tavalla, joka toimisi. Objektiivinen mittaaminen kun on aidosti aika vaikeaa.
Mikäli nämä terveydenhuollon it-systeemit on rakennettu tämän mumpsin päälle, ei ole mikään ihmekään että kalliiksi tulee…
http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx
Hyvin kirjoitettu Otso ja todella tärkeää, että olet nostanut tämän asian esille ja että mediassa on se myös huomattu. Tämän kokoluokan kansantaloudellinen katastrofi täytyy voida estää. Ostopäätös täytyy voida nyt pysäyttää ja hakea vielä vaihtoehtoista suunnitelmaa.
Jos ”on varaa” suunnitella n. 2 miljardin euron sijoitusta tällaiseen hankkeeseen, jonka lopputulosta ei edes voida tarkasti ennakoida, niin eikö ole varaa järjestää avointa toteutuskilpailua, jossa toimivin ja käytettävyydeltään paras prototyyppi voittaa ja saa 10 miljoonaa sen tuotantokelpoiseksi viimeistelyyn? Käytettävyyden arvioi oikeista käyttäjistä koostuva raati, joka ei tiedä prototyypin toimittajaa. Kilpailuun ostallistuville tarjotaan samanlaiset mahdollisuudet käyttäjähaastatteluihin tai niitä voidaan tehdä myös konsultin toimesta ja teettää kattavat käyttötilanneanalyysit ja jakaa ne kaikille kilpailijoille avoimesti.
Prototyypin teknisen toteutuksen ja rajapinnat arvioi asiantuntijaraati etukäteen tehdyn ja avoimen kriteeristön perusteella.
Osallistujat saavat aikaa 4 viikkoa ensimmäisen toimivan version demoamiseksi ja demojen perusteella valitaan vaikkapa 20 toimittajaa jatkoon, joille maksetaan kullekin 30000 euroa proton rahoitukseksi ja sen viimeistelyksi arviointia varten 10 viikossa. Rahoitusta maksetaan 2 viikon sprinttien mukaan mikäli toteutus etenee hyväksyttävästi.
Jatkoselvennykseksi: Terveydenhuollon tietojärjestelmän kokonaisratkaisun monimutkaisuutta on aivan tolkuttomasti liioiteltu ja se voidaan paljastaa järjestämällä tällainen avoin toiminnallisen prototyypin toteutuskilpailu siten, että sen tulee kattaa kaikki tärkeimmät aspektit: ajanvaraus, terveysaseman tai sairaalan työvuorojen hallinta, e-resepti, käypähoitoluokitukset, lääkeainerekisteri (pharmaca fennica), hoitohistoriat, hoitoprosessin hallinta yksikköjen välillä (esim. ulkoiset labrat), jne…
Se kaikki täytyy toteuttaa prototyyppiin toiminnalliseksi kokonaisuudeksi käyttöliittymineen ja Suomessa on ehkä juuri parikymmentä sellaista yritystä tai tiimiä, jotka tällaisen kokonaisvaltaisen ja toimivan prototyypin pystyvät toimittamaan 3 kuukaudessa. Ja vieläpä siten että prototyypistä on suoraviivaista jatkaa toteutus tuotantojärjestelmäksi samalla ketterällä malliohjatulla menetelmällä.
Valmis alustava domain malli tähän löytyy pitkäaikaisen kollegani Jukka Tammisen blogista:
http://jukkatamminen.wordpress.com/2010/03/24/genuine-object-model-health-care/
Tuo käytettävyyshän on tässä suunnitelmassa ratkaistu kätevästi budjetoimalla kymmeniä vai satoja miljoonia (lue: lähinnä hoitohenkilöstön työaikaa) myös käyttökoulutukseen.
Vaihtoehto tosiaan olisi tehdä Käytettävää softaa, mutta kun se ei ollut tapana (tai edes mahdollista) COBOL/MUMPS-aikakaudella, ei kai sitä ymmärretä ainakaan päättävällä tasolla vaatia nytkään.
Jospa aloitettaisiin näiden rahareikien paikkaaminen vaikka näistä:
http://omakaupunki.hs.fi/paakaupunkiseutu/uutiset/viisi_pyoratelinetta_maksoi_kymmeniatuhansia_euroja/
Tämän tekeillä olevan tietojärjestelmähankkeen hinnalla saisi noin 400 000 tuollaista pyörätelinettä. Samalla hinnalla voisi tehdä tuollaisen pyörätelinehankinnan joka viikko seuraavan 1540 vuoden ajan. Mittasuhteet kannattaa pitää virkeänä mielessä että säästöt kohdistetaan suurimpiin katastrofeihin ensin.
Hienoa! Osaat aritmetiikkaa! Se taito unohtuu monelta ja sen takia tuollaisia järjettömiä summia ollaan valmiita maksamaan kyseenalaistamatta. Tiesitkö muuten että kaikki julkinen raha kerätään kansalaisilta ja yksityisiltä yrityksiltä? Vaikka mittasuhteet heittelevät, niin nuokin verot alkavat sentistä. Ihan jokainen veroeuro.
Kirjoittaja on poistanut tämän kommentin.
Eiköhän kaikki veroja maksaneet tiedä hyvinkin mistä ne julkiset rahat otetaan. Erikoinen kysymys. Tämän blogin aiheen kokoluokka on 2 miljardia euroa. Kyse on törkeästä julkisten varojen ryöstöstä. Tässä yhteydessä design-pyörätelinehankinnat tuntuvat kieltämättä aika epäolennaisilta ennenkuin tällaiselle megaluokan kassankäännölle on tehty jotain. (Vaikka jokainen verotettu euro tulee tietenkin käyttää harkiten ja viisaasti).
Poimittu mitä selvityksessä sanotaan kustannusten arvioinnista:
Perustuen Accenturen kokemuksiin aikaisemmista potilastietojärjestelmätoteutuksista, tehtiin
karkean tason analyysi investoinneista sekä ylläpitokustannuksista. Arviossa huomioitiin
erilaiset kustannusajurit: toiminnallinen kompleksiteetti, oppimiskäyrä, tekninen kypsyys,
tilaajan ja toimittajan välinen työnjako jne.
Olihan siellä muutakin, mutta diipadaapadaa ”toiminnallinen kompleksiteetti”
Normaalit kaupunkikalusteohjeen mukaiset pyörätelineet G1 maksavat ruostumattomasta teräksestä 163€ + ALV per kaari. Tämä oli kilpailutuksen halvin tarjous. Kysyin virastosta, kun minua kiinnosti tämä asia.
Tuota Car spacea vastaavat 5 kaarta maksaisivat siis 1002 euroa. Siihen päälle työt, joiden määrä riippuu paljon paikasta. Arvataan että toinen mokoma, kun pitää kuitenkin kaivaa katua auki ja valaa betonia jne.
Nuo Car space rackit maksoivat 5000 euroa kappaleelta kaikkineen. Että joo, onhan se 2-3 koertaa kalliimpaa kuin perustelineet.
Toisaalta nuo ostettiinkin pyöräilynedistämisrahoilla, ja näillä saatu näkyvyys on kyllä varmasti edistänyt pyöräilyä koko tuon lisähinnan edestä.
Jos haluat ehdottaa kustannustehokkaampia tapoja edistää pyöräilyä, ehdotan että kommentoit siitä vaikkapa postaukseen jonka aiheena se on. Tämän postauksen aiheena on potilastietojärjestelmä, kuten ehkä huomasitkin, jos tekstin luit.
Hyvä postaus, tosin arkkitehtuuriosa on minusta hieman harhaanjohtava. Järjestelmän arkkitehtuuri ei sinänsä ole kovin olennainen, lähinnä suunnitteluperiaatteet ja kehitysprosessit. Tehokkaassa projektissa pitäisi lähteä liikkeelle siitä, mitkä ovat käyttäjien tarpeet ja mitä ohjelmistolla halutaan saavuttaa. Näistä valitaan sopiva osakokonaisuus, jonka voi toteuttaa ja ottaa käyttöön itsenäisesti, lyhyessä ajassa ja pienehköllä budjetilla. Näitä sitten jatkettaisiin iteratiivisesti pala palalta, olennaisena osana kuitenkin tarkastella ensisijaisesti käyttöprosesseja ja muokata ohjelmisto tukemaan niitä.
Luonnollisesti ostajan tulisi omistaa lähdekoodi eikä olla velvoitettu käyttämään alkuperäistä toimittajaa jatkokehitykseen. Valmisohjelmien ongelmana tällä sovellusalueella on se, että ne täytyy käytännössä aina räätälöidä vastaamaan suomalaista lainsäädäntöä ja prosesseja, jolloin valmiin tuotteen ostaminen ei ole erityisen kustannustehokasta. Lähdekoodin omistajuus vapauttaa myös yhden toimittajan kahleista ja osiin pilkkominen tekee vaihtamisen helpoksi. Ei kukaan laita toiminnalleen kriittistä tietojärjestelmää yhden ulkopuolisen toimittajan varaan.
Nykyisellään projektin suurimmat ongelmat ovat ”kerralla kuntoon” -lähestymistapa, liiallinen painotus toimittajavalintaan ja tekniikkaan ongelmalähtöisyyden sijaan, sekä ilmeisesti projektin hallinto. 47 henkeä ei ole tehokas ohjausryhmä, maksimikoko olisi ennemmin 8 ja jonkun täytyy kyetä tekemään päivittäisiä päätöksiä.
Kompetensseista vielä, kaikki kunnia eri alueiden asiantuntijoille, mutta jos halutaan tietojärjestelmä, niin hyviä ohjelmistokehityksen asiantuntijoita tarvitaan. Vai pyydetänkö diplomi-insinööriä mukaan miettimään hoitosuunnitelmia ja haluaisiko joku sitä?
Olen samaa mieltä, että arkkitehtuuri ei tässä nyt ole mitenkään ydinasia. Se liittyy aiheeseen vain sikäli, kun se liittyy niihin prosesseihin ja ostotapoihin. Monoiliittinen arkkitehtuuri pakottaa ostamaan kaiken könttänä, ja pahentaa vendor lock inniä, jos sellainen päästetään syntymään. Ei tietysti pitäisi päästää.
Muutoin samaa mieltä kaikesta mitä sanot.
Järjestelmän ydin kannattaa toteuttaa yhtenä kokonaisuutena ilman hajautusta erillisiksi järjestelmiksi, mutta siten, että koodi on avointa ja omistus asiakkaalla.
Kysymys on aina kokonaisuuden toiminnasta ja se kokonaisuus muodostaa aina ulkopuolelta katsottuna ”monoliitin”. Kaikkien ytimen osien täytyy toimia saumattomasti yhteen ja löyhät kytkennät tiukan ytimen osien välillä vain mutkistavat toteutusta.
SOA ja ”orkestrointikerros” on kaikkien monoliittien äiti ja se räjäyttää minkä tahansa tietojärjestelmän kustannukset 10-100 kertaiseksi siitä mitä vastaava systeemi olisi maksanut yhdellä yhtenäisellä arkkitehtuurilla toteutettuna jossa koko ydin on toteutettu yhtenä järjestelmänä.
Monoliitti-argumentti vuotaa muun muassa siinä mielessä, ettei ole mitään määriteltyä kriteeriä, missä kohden jako alisysteemeihin tulisi lopettaa. Konsolidointi on integrointia edullisempaa.
Tiedän että tämä jakaa usein mielipiteitä ja että tämän kysymyksen perinpohjainen ruotiminen tässä foorumissa on hankalaa. Sen takia jokin hyvin mietitty ”tulokset puhukoot puolestaan”-lähestymistapa prototyypein pienentäisi riskejä ja auttaisi arvioimaan konkreettisia tuloksia spekulointien ja powerpointtien sijaan.
Hajautuksen ja konsolidoinnin välinen tarkoituksenmukaisuus on aika monimutkainen kysymys, eikä siihen ole oikein hyvää yleisratkaisua, vaan paljon riippuu aina tilanteesta jossa ollaan.
En sinänsä ole eri mieltä mistään mitä sanot, mutta aivan erityisesti olen samaa mieltä siitä, että oikea tapa lähestyä tätä kysymystä on empiria ja prototyypit. Käytännössä siis uusi järjestelmä pitäisi rakentaa ensin yhteen sairaalaan (tai yhteen sairaalaan ja yhteen pienempään kuntaan) ja vasta jos se toimii hyvin, aloittaa levittäminen muualle. Jos taas ei toimi, niin sopimus poikki ja seuraavaa kehiin.
Mammuttihankkeen ongelma on, että se on ”liian suuri epäonnistumaan”. Yleensä sellaiset hankkeet aina epäonnistuvat, ja tekevät sen kolossaalisesti.
Yhden sairaalan ja yhden pienen kunnan järjestelmä olisi varmasti loistava tapa todeta ratkaisun toimivuus käytännössä ja juuri niinkuin totesit: jos homma ei toimi, niin sopimus poikki ja uusi toimittaja kehiin. Juuri niin tätä hanketta tulisi osittaa ja riskejä pienentää. Olemme tästä täsmälleen yhtä mieltä.
Ajatuksena houkuttelisi jonkinlaisen prototyyppikilpailun järjestäminen, jotta mahdollisimman paljon hyviä yrityksiä ja tiimejä pääsisi mukaan tuomaan ideoitaan ja myös kilpailevia ja keskenään riittävän erilaisia ratkaisuja tulisi arvioitavaksi. Varsinainen toteutus voisi olla näiden prototyyppien parhaista oivalluksista jokin toimiva yhdistelmä, vaikka jopa kyseisten tiimien yhteistyössä toteutettuna.
Jonkin verran ymmärrän tuota hankinnan ylimielisyyttä, hankkijana on sairaanhoitopiiri. Ei niiden tarvitse rahasta välittää, ne toimivat kuntien/kapupunkien rahoilla ja ovat ohjauksen ulottumattomissa.
Sairaanhoitopiirit ovat kasvaneet kuin syöpä, ja tervehdin ilolla sitä, että uusi terveydenhuollon rakennelaki lakkauttaa sairaanhoitopiirit.
– Kake
Jos sinulla on ennakkotietoa siitä, mitä rakennelaissa tullaan oikeasti säätämään, olisin kyllä hyvin kiinnostunut. En ole erityisen perehtynyt aiheeseen, mutta se on tässä tietojärjestelmiä katsoessa alkanut kiinnostaa yhä enemmän.
Keskustelu tällaisista isoista hankkeista on aina paikallaan, mutta valitettavasti sekaan eksyy pahojakin vääristymiä, koska keskustelijat tietävät usein vain osatotuuksia, tai tieto on vanhentunutta. Eräs selkeä väärinkäsitys on eri foorumeilla näkymät viittaukset MUMPS-kieleen/välineeseen, joka tosiasiassa kuuluu menneeseen maailmaan. Vastaava teknologia (InterSystems Caché) tänä päivänä on aivan muuta, kuin mihin mm. näköjään laajalti levitetty artikkeli (http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx
) viittaa. Tuosta teknologiasta oikeasti tietäviä on selkeästi vähemmän, kuin esim. relaatiotietokantojen kanssa työskenteleviä, mutta kyseinen teknologia antaa tänä päivänä käytännössä todella hyvät mahdollisuudet ja erittäin toimivan tietokannan, jos siihen päädyttäisiin.
Näillä sivuilla puhutaan myös kovasti sen puolesta, että erillissovellukset ja niiden integrointi toisiinsa on nykyaikaa. Niinpä. Tosiasiassa totuus alkaa valjeta siinä vaiheessa, kun oikeasti tuleekin tarve liikutella tietoa joka suuntaan kaikkien erillissovellusten välillä (ja tämä on nähty jo!). Mitä useampi osasovellus sisältyy kokonaisuuteen jo valmiiksi, sitä toimintavarmempi kokonaisuus saadaan. Näillä sivuillakin mainittu MUSTI (joka muuten ei perustu VA Vistaan, koska sitä ei ollut vielä olemassakaan 1980-luvun alussa) oli itsessään varsin fiksu sovelluskokonaisuus, sisältäen useat eri osasovellukset toisiinsa liittyneinä, ja yhteisellä potilastietokannalla. Sovellus vain oli päätekäyttöinen, merkkipohjainen, ja olisi 2000-luvulle tultaessa kaivannut paitsi graafisen käyttöliittymän, myös muuta täydentävää remonttia. Ei tosin teknologia-alustansa puolesta.
Millä lisenssillä nuo linkittämäsi artikkelit on uudelleenjulkaistu? Kannattaisi ehkä pistää siitä maininta, sillä ainakaan MISQE:n artikkelit eivät ole vapaata aineistoa.
Who gives a shit?
Mitenkähän voi tietää että kenelläkään ei ole tietojärjestelmien määrittämisestä kokemusta johtoryhmässä? Suomessa annetaan aika laajaa tietojärjestelmäkoulutusta ekonomeille mm. Jyväskylässä ja Helsingissä.
Hei! Vuosikausia IT-asiantuntijoina toimivien ekonomien kanssa työskennelleenä voin sanoa että tetojenkäsittelytieteen laitos tai Teknillisen korkeakoulun IT-osasto tuottavat osaajia IT-alalle. Kauppakorkea keskimäärin ei.
Siihen en voi yhtyä että lääkäreiden mukanaolo uuden järjestelmän kehittämisessä olisi huono asia. Toki varmasti myös tietojärjestelmäasiantuntijan tulisi olla ryhmässä mukana. Itselläni lääkärinä on kuitenkin kokemusta useista eri potilastietojärjestelmistä aiemmin terveyskeskuksista, nykyään sairaalasta (ei HUS:ssa). Yksikään näistä järjestelmistä ei ole ollut sillä tavoin looginen, että siitä löytäisi tarvitsemansa tiedot potilaasta helpommin tai edes yhtä helposti kuin aikaisemmin potilaan papereista. Valtaosa lääkäreistä ottaisi ilolla takaisin vanhan paperisen ”kuumekurvan”, yhden A4:n josta yhdellä silmäyksellä sai käsityksen potilaan kokonaistilanteesta. Monesti on tuntunut siltä, että nykyisiä järjestelmiä kehittämässä ei ole ollut yhtäkään ihmistä, jolla olisi käsitys siitä kuinka potilaan hoito yleensä etenee.
Hankintamenettelyssä sen sijaan vaikuttaa olevan paljon suhmurointia, johon kirjoituksessa mielestäni aivan oikein puututtiin.
Hei,
ehdottomasti lääkärien mukana olo on tarpeen. Se on välttämätöntä onnistumiselle.
Huomioni koskee sitä, että myös IT-ammattialisten mukanaolo ostajan puolella on välttämätöntä hankkeen onnistumiselle.
25 vuotta ICT-alalla olleena voin vain todeta, että tämä on todella hyvä analyysi tästä sekoilusta.
Varsinkin nuo kommentit vaatimuksista ovat naulan kantaan. Jokainen, joka on suunnitellut vähänkin suurempia ICT-arkkitehtuureja, tietää, että suuri osa projekteista lähtee väärille urille heti alkumetreillä, kun vaatimuksia määritellään.
En suosittelisi mitään valmisjärjestelmän hankintaa.
Mitä vanhempi ja ”täydellisempi” systeemi, sitä enemmän hankinnan mukana tulee runsaasti tarpeettomia moduuleita. Teknologia saattaa olla täysin vanhentunutta, josta on ketteryys kaukana. Räätälöinti on hankalaa ja tulee todella kalliiksi. Tämmöiseen koodiin koskeminen vaatii erityisperehtymistä, ja silti se on ns. vaarallista. (Jo pelkästään täysin vanhentunut toteutuskieli MUMPS pitäisi riittää jonkin ehdotuksen hylkäämisperusteeksi.)
Kun toimittaja omistaa järjestelmän ja lähdekoodin, ollaan täysin sen armoilla. Tällöin räätälöinnit hinnoitellaan tähtitieteellisiksi, joten niitä ei välttämättä toteuteta, kun budjetti on jo ylittynyt.
Siis:
Ydinjärjestelmän täydellinen omistus ja hallinta. Tämä onnistuu sen osuuden tekemisellä tyhjästä omana projektinaan toimittajia hyväksikäyttäen. Muutaman miljoonan projekti enintään; silti tärkein osuus tulee tehdyksi ja täyttää nykyaikaiset laatustandardit.
Avoimet rajapinnat.
Erillismoduulit hankitaan ja kilpailutetaan erikseen, hankitaan valmiina näiltä toimittajilta, tehdään itse tai teetetään.
Tietyt operatiiviset järjestelmät ovat toimintayksikön ydintoimintaa: esim. potilastietojärjestelmä sairaalassa. (Kirjanpito ja palkanlaskenta eivät ole.) Näiden omistaminen, toiminnan hallinta, tietokannat, lähdekoodi yksityiskohtaisesti pitäisi olla toimintayksiköllä. Näiden ulkoistaminen on suuri virhe, josta monet organisaatiot kärsivät kasvavina kustannuksina ja kehityksen pysähtymisenä – myös yksityisellä puolella.
Järjestelmäosaston pitäisi pystyä itse kehittämään järjestelmää yksin ja yhdessä luottotoimittajien kanssa. Yksittäiselle toimittajalle ei saisi antaa toimitusmonopolia. Henkilökunnan pitää hallita koko kehitys- ja käyttöprosessi, ei pelkästään koordinoida loppukäyttäjän vaatimusluetteloa, neuvotella tilaushinnoista ja osallistua toimittajien järjestämiin tapahtumiin.
Juuri näin. Lisäksi hyvän käytettävyyden varmistaminen edellyttää henkilökunnasta koostuvan ryhmän tiivistä osallistumista suunnitteluun sekä toteutusvaiheessa prototyyppien iterointiin.
Erinomainen käytettävyys on koko tämän järjestelmän onnistumisen tärkein laatukriteeri (perustoimintavarmuuden ja tietoturvan ohella) ja sen varmistamiseksi on olemassa hyviä menetelmiä. Ratkaisuja voidaan arvioida ja testata jo ennen toteutusta.
Jukka, Mikael ja Teppo, kuulostaa yhtä järkevältä kuin suosittelisitte että teollisuusyrityksen tulee SAP-järjestelmän käyttöönoton sijasta koodata vastaava järjestelmä alusta alkaen itse. Varsin naivistinen visio.
Itseasiassa monienkin teollisuusyritysten olisi taloudellisesti kannattanut hankkia taitava tiimi ja antaa sen toteuttaa toiminnanohjausjärjestelmänsä. Ja eihän niitä järjestelmiä ihan alusta alkaen tehdä vaan rakennetaan aina käyttäen hyvin tunnettuja ratkaisuja, mutta säilyttäen silti joustavuus, joka tarvitaan jokaisen erinomaisen järjestelmän toteuttamiseksi. SAP:issa perusajatus on oikein: yksi keskitetty ydinjärjestelmä. Mutta SAP on ikivanha ja raskas läjä nykyään turhaksi käynyttä koodia ja vanhoja rumia käyttöliittymiä joiden kanssa kaikki käyttäjät joutuvat ennen aikojaan sairaseläkkeelle.
Useammastakin organisaatiosta on menetetty parhaita osaajia erinäisten SAP-projektien ja ERP-hankkeiden tuloksena. Älkää hyvät päättäjät vaan koskaan enää haksahtako tilaamaan SAP:eja vaan haastakaa oikeasti nämä vanhojen dinosaurusten jutut ja testatkaa systeemit loppukäyttäjillä.
Naivistinen toki, mutta vain siksi, että taloushallinto-osasto haluaa sen SAPin kuitenkin, ”koska kaikilla muillakin tämän kokoluokan organisaatioilla on”, ja ne saa päättää.
Miksikö mukana ei ole lääkäreitä? Koska Lehtonen tietää että se kaataisi hankkeen. Tässä puhutaan toimintatapojen muutoksesta, joka on yksi suurimmista haasteista. Jos kolme kirurgia laitetaan miettimään yhteistä toimintamallia johonkin toiminnallisuuteen, 90% todennäköisyydellä yhteistä, yhtä mallia ei tule löytymään. Ja se taas johtaa ohjelmiston räätälöintiin…
Ouluun haetaan terveydenhuollon it:n professoria, pätevyysvaatimuksena mikäs muu kuin lääketieteellinen tutkijakoulutus: http://www.mediuutiset.fi/uutisarkisto/oulu+saa+terveydenhuollon+itprofessuurin/a859325