Mitä lääkkeeksi eReseptille?



Perjantaina nousi pieni haloo siitä, kuinka sähköiseen reseptiin mahtuu vain 50 merkin pituinen selitys käyttötarkoituksesta.

”Ongelman korjaaminen tulee kalliiksi ja vie aikaa, kertoo projektipäällikkö Riitta Konttinen THL:stä.

– Siinä menee noin puolitoista vuotta. Kärsivällisyyttä tarvitaan ennen kun uudistus saadaan käyttäjälle. Muutosten tekeminen ei ole myöskään halpaa.”

Onhan se tietenkin vähän omituista, että puolen päivän työltä kuulostava muutos vie puolitoista vuotta. Mutta todellisuus on joskus omituisempi kuin mitä uskoisi. Tämä ei nimittäin ole suinkaan ensimmäinen omituisuus sähköisen reseptin historiassa.

Valtiontalouden tarkastusviraston surullisenkuuluisa raportti Sosiaali- ja terveysalan IT-hankkeista käsittelee sähköistä reseptiäkin:

  • Hanke on eri muodoissaan elänyt 80-luvulta asti, myöhästyen toistuvasti. Suurin syy myöhästymisiin on ollut kiire.
  • Vuonna 2002 eReseptiä oli tarkoitus pilotoida 2003. Pilotti viivästyi vuoteen 2005.
  • Vuonna 2007 KanTa-palvelut (joista eResepti on ensimmäinen osa) oli tarkoitus toteuttaa noin vuodessa. Tämänhetkisen aikataulun mukaan resepti on käytössä julkisella sektorilla tänä vuonna ja yksityisellä 2015 mennessä. Muut KanTa-palvelut tulevat myöhemmin.
  • Alkuperäinen kustannusarvio oli 20 miljoonaa, nyt eReseptin kokonaiskustannuksiksi arvioidaan 70 miljoonaa.
  • Sekä aikataulut että kustannusarviot ovat olleet vaihtelevia. VTV:n sanoin: ”Sosiaali- ja terveysministeriöllä ei ole ollut selkeä ja realistista näkemystä KanTa-hankkeen kokonaisaikataulusta. Eri toimijoille esiteyt aikataulut ovat siirtyneet toistuvasti, mikä on johtanut terveydenhuiollon toimijoiden epäluottamukseen minsteriön ohjeistusta kohtaan.”

50 merkin raja ei sinänsä ole kauhean merkittävä ongelma. Itse asiassa voi olla, ettei se ole ongelma ollenkaan. Käyttötavan kohdalle kun voi kirjoittaa myös ”erillisen ohjeen mukaan”. En ole oikea ihminen arvioimaan, paljonko tilaa tarvitaan. Jos kuitenkin katsotaan projektipäällikkö Konttisen tavoin, että 50 merkkiä on liian vähän, niin tässä on kaksi vähän merkittävämpää ongelmaa:

  1. Miksi tätä ei havaittu aiemmin, ja
  2. Miten korjaus voi kestää puolitoista vuotta (ja maksaa paljon).

Ensimmäinen kysymys voidaan esittää oikeastaan kaikille IT-hankkeille. Sellaista projektia ei nimittäin olekaan, jossa kaikki olisi keksitty etukäteen. IT-hankkeet ovat luonteeltaan ennen kaikkea oppimisprojekteja, joissa opitaan ymmärtämään, mitä hankkeessa oikeastaan pitääkään tehdä. Sivutuotteena sitten syntyy softa.

Vaikka ennakkomäärittelyissä olisi ollut mukana kuinka monta lääkäriä, apteekkaria ja potilasta, on silti selvää, että kunhan järjestelmä saadaan käyttöön, tulee esiin tarpeita joita ei ennalta ajateltu. Se on ihan normaalia.

Ketterissä menetelmissä tämä tosiasia pyritään tunnustamaan, ja tuottamaan loppukäyttäjille toimiva järjestelmä mahdollisimman usein, ideaalisti kahden viikon välein. Kun lääkärit pääsevät kokeilemaan järjestelmää pian, selkiytyvät tulevat tarpeetkin nopeammin. Vuoden 2002 jälkeen eReseptiä olisi ehditty demota 250 kertaa. Niissä olisi varmasti löytynyt muutamakin virhe ja kehitysidea.

Sähköisen reseptin kehitysjakso ei kuitenkaan ole kaksi viikkoa, vaan ilmeisesti kaksi vuotta. Jos ja kun nyt huomataan pieni puute, sen saaminen korjatuksi vie 18 kuukautta. Potilasturvallisuuden takia tarvitaan tietysti aika paljon parempi testaus kuin jossain webikaupassa. Ja kokonaisuudessa on toki monia toimittajia. Mutta vähintäänkin kolmen kuukauden kehitysjaksojen pitäisi olla hajautetussa monitoimittajaympäristössäkin aivan realistista.

Tämä ei kuitenkaan vastaa itse kysymykseen: miten tämä voi olla näin?

Politiikan kommentaattori Veikko Eranti kertoo fiktion keinoin, miten tämä lapsus olisi voinut tapahtua. ”Koko sektorin liiketoimintamalli nimittäin perustui sekundan myymiseen ymmärtämättömille keiloille, ”huipputeknologian” kauppaamiseen pohjimmiltaan kirjoituskoneajassa eläville ihmisille, joiden sihteerit hoitivat heidän sähköpostinsa.”

Kuten yleensäkin, todellisuus on tietenkin hiukan monimutkaisempi. Viidenkymmenen merkin raja ei ole syntynyt yhdessä palaverissa, eikä kyse ole vain yhdestä järjestelmästä.

eResepti koostuu Reseptikeskuksesta ja sitä käyttävistä potilastietojärjestelmistä sekä apteekkijärjestelmistä. Suomessa on yli 300 kuntaa, 20 sairaanhoitopiiriä, 4000 yksityisen terveydenhuollon toimijaa ja 800 apteekkia. Jokaisella näistä on oma järjestelmä ja jokaisella niistä toimittava yritys. Kyse on siis tuhansista asiakkaista ja kymmenistä softantoimittajista.

Eri osapuolien kommunikaatio perustuu XML-muotoisiin CDA R2-sanomiin, jotka määritellään HL7-standardeissa. Kaikille eri kentille annetaan kiinteät pituudet, ja käyttötarkoituksen pituus sattuu olemaan 50 merkkiä. Alle 12-vuotiaan painolle on muuten 5 merkkiä, joten parasta olla tekemättä satakiloisia lapsia.

Matti
Esimerkkireseptissä Pekka Potilaalle on määrätty Diapamia ahdistuksen hoitoon.

XML sinänsä ei tekstimuotoisena formaattina vaadi kentille pituusrajoja. Itse asiassa olisi helpompaa tehdä sanomajärjestelmä, jossa ei rajoja ole. Mutta sitten kaikkia eri järjestelmiä päivittävät softatalot eivät tietäisi etukäteen, täsmälleen minkä mittaisilla teksteillä eResepti pitäisi testata. Nykyaikaiset systeemit toki selviäisivät helposti pitkistäkin teksteistä, mutta kaikki järjestelmät eivät ole nykyaikaisia.

Jossain on siis olemassa apteekkitietojärjestelmä, joka kykenee vain tähän määrään. Monet kykenevät enempään. Nyt luotiin uusi kansallinen järjestelmä rajoittaen sen toimintaa heikoimman vanhan järjestelmän speksein.

Suomessa, toisin kuin vaikka Tanskassa, ei ole mitään kansallista tahoa, joka ohjaisi terveydenhuollon järjestelmien kehitystä yhteentoimivaan – tai ylipäänsä toimivaan – suuntaan. Sen sijaan jokainen taho tekee asiat omalla tavallaan, ja ainakin eReseptiä kehitettiin vahvasti konsensusperiaatteella, eli ratkaisujen tuli sopia kaikille. Ja VTV:n sanoin:

”Hankkeen toteuttamisen etenemiselle ei ole riittävää ponninta, koska jatkuva rahoitus on omiaan edistämään eri osapuolten jatkorahoituksen saamista omalle henkilöstölleen”.

Eli suomeksi: Mitä vähemmän edistystä, sen enemmän rahoitusta. Ihmekös tuo jos kestää. Ei ole tietenkään projektin toimittajan vastuulla ajatella asiakkaan etua. Se on asiakkaan vastuulla. Pitäisi osata ostaa IT-järjestelmiä.

Ei ole normaalitila tai business as usual, että hankkeet myöhästyvät kymmenen vuotta tai budjetti kolminkertaistuu. Se kertoo siitä, että asiat ovat vakavasti pielessä. Ulkopuolisen on mahdotonta sanoa, tarkalleen mihin aika ja rahat ovat menneet. Niillä tuskin on lennelty Bahamalle, vaan hyvä arvaus on, että ne ovat menneet vääriin toimintatapoihin. Esimerkiksi siihen, että yritetään pakottaa kaikki toimijat käyttämään samoja protokollaversioita.

Ydinviestissään Eranti on siis täysin oikeassa: ongelmana on, että tilaajan puolella pöytää ei ole riittävää osaamista hankkia IT-järjestelmiä. Valtiontalouden tarkastusvirasto päätyi aivan samaan johtopäätökseen: ”Kokonaisuudessaan arvioiden Sosiaali- ja terveysministeriöllä ei ole ollut osaamista eikä edellytyksiä johtaa KanTa-hanketta eikä sitä edeltänyttä sähköistä potilaskertomushanketta osana kansallista terveyshanketta.”

No, mitä lääkettä terveydenhuollon IT:lle sitten pitäisi määrätä? Tässä kolme ideaa:

  1. Pitää perustetaa Tanskan Medcomia vastaava organisaatio THL:n tai Sosiaali- ja terveysministeriön yhteyteen vastaamaan terveys-IT:n kokonaisarkkitehtuurista.
  2. Järjestelmät pitää päivittää vähintään neljä kertaa vuodessa. Kaikki sellaiset ohjelmistot ja toimintatavat, jotka tekevät tiheästä julkaisusta ongelmallisia, pitää korjata.
  3. Jokaiseen IT-hankkeeseen pitää palkata yksi ihminen, joka ymmärtää mitä siinä ollaan tekemässä. Kokemukseni mukaan se parantaa merkittävästi hankkeen onnistumismahdollisuuksia.

14 kommenttia artikkeliin ”Mitä lääkkeeksi eReseptille?

  1. Viisi merkkiä kylläkin riittää tuhatkiloisiin asti, ellei vaadita suomen kielen mukaista määrittelyä (”999kg” vs ”99 kg”), eli se kenttä on onneksi tarpeeksi pitkä. Enemmän voisi ihmetellä taas kerran miksi arvo ja tyyppi ovat samassa kentässä…

    Eranton kirjoitus taas oli sinänsä hyvä, mutta tässä tapauksessa osui metsään kun kyse oli speksauksesta, johon toteutustalot eivät tainneet osallistua. Ja kommenteista siellä voi lukea miten ei osata ajatella yhtään pitemmälle asioita. Onneksi tässä sentään fiksusti mainitaan, että niitä korjattavia kohtia on enemmän kuin ”yksi tietokantakenttä.”

    • Aa, taisin lukea speksiä huonosti. Oletin sen olevan grammoina ilman yksikkömerkintää, mutta en sitten tosiaan tarkistanut onko jossain annettu kentälle käyttöohje.

      Tosiaan merkin sijoittaminen samaan stringiin lukuarvon kanssa on hiukan erikoista. Kenttää ei varmaankaan kauheasti konelueta, tai ainakaan sitä ei ole konelukemista silmällä pitäen suunniteltu.

  2. Voisiko blogin kirjoittaa niin, että siinä ei olisi harmaata tekstiä harmaalla pohjalla. Kaskun ei mustaa mustalla.

    • Kiitos palautteesta. Mietin itsekin aivan samaa tätä julkaistessa taas, että tuota leiskaa täytyy kyllä päivittää…

  3. 50 merkin raja ei sinänsä ole kauhean merkittävä ongelma. Itse asiassa voi olla, ettei se ole ongelma ollenkaan. Käyttötavan kohdalle kun voi kirjoittaa myös ”erillisen ohjeen mukaan”.

    >>> Ei nyt ihan oleellisin pointti, mutta eikö se ollut nimenomaan käyttötarkoitus jossa oli 50 merkki rajoitus eikä annostusohje? Väittivät että annostusohjeeseen olisi 300 merkkiä.

    Jotenkin muuten on kyllä sellaista perus-agilekonsultin helppoja vastauksia tässä kirjoituksessa. On nimittäin niitäkin tullut aika paljon jo nähtyä kun ei agile enää ole uusi asia. Eikö tuo arkkitehtuuriohjausyksikkö ole THL:ään perustettukin? Ja eiköhän tuohonkin porukkaan ole joku/joitakin asiaa ymmärtäviä eksynyt. Kyllä mä olisin taipuvainen ajattelemaan, että tuollaisessa ekosysteemissä asiat ei ole ihan niin helppoja kuin päältäpäin näyttää. Pelikentän reunalta on helppo huudella.

    • Käyttötavasta juuri on kyse, ja annostukselle on oma kenttänsä. Itse asiassa monimutkaisempikin joukko kenttiä.

      Itse en perus-agiilikonsulttina ole pätevä arvioimaan, kuinka pitkiä kenttiä lääkärit ja apteekkarit mihinkin käyttöön tarvitsevat. Mutta lääkäriltä kuulemani mukaan tuohon käyttötapakenttäänkin voi halutessaan kirjoittaa noin.

      Toinen lääkäri sanoi:

      ”käyttötarkoitus eli indikaatiokenttä, johon mahtuu vain 50 merkkiä on toki kökkö, mutta siihen ei juuri tarvitsekaan mahtua muuta kuin esim. ”verenpainetaudin hoitoon” tai ”eturauhasen hyvänlaatuisen liikakasvun oireiden hoitoon” (mikä jälkimmäinen ei seíis enää mahdu). Muut ohjeet tulee kenttään annos, siinä kerrotaan miten lääkettä otetaan, miten paljon ja miten usein ja esim ei ruuan kanssa tai runsaan nesteen kanssa tai tiettyinä päivinä eri annos.

      ”Erillisen ohjeen mukaan” kuuluu siis oikeasti annoskenttään. Jostain syystä e-reseptikoulutuksessa selitettiin, että jonkun säännön mukaan annoskohdassa ei saisi lukea mitän ylimääräisiä ohjeita, mutta kuitenkin nykyisin siihen kaikki tarpeellinen käyttöohje kirjoitetaan.

      Tyhmää tässä on lähinnä se, että ennen noiden kenttien tilat oli päinvastoin, ja valmiit fraasit, joita Pegasoksessa indikaatiokentässä on, joutuu leikkaamaan ja liittämään annoskohtaan, koska ohjelma herjaa merkkirajan ylityksestä.”

  4. En tyytyisi edes neljään julkaisuun vuodessa. Aidosti ketterä työ hyvällä testausautomaatiolla mahdollistaisi julkaisun lähes jatkuvasti. Järeällä ihmisten tekemällä hyväksymistestauksellakin muutamien viikkojen syklillä.

    Nuo kolme pointtia olivat oikein päteviä lääkkeitä. Itse lisäisin vielä neljännen: ketteröittämiseen liittyvä turhien byrokratioiden ja raja-aitojen purkaminen. Niin usein monitoimittajaympäristöä pyritään hallitsemaan luomalla mahtavat, extensiivisesti dokumentoidut prosessit, jotka kuvaavat yksityiskohtaisesti kunkin paikan ketjussa. Tällä vältetään ainoastaan se, että ihmiset aidosti keskustelisivat toistensa kanssa. Kukaan ei kuitenkaan hallitse prosessia täydellisesti, jolloin pallo putoaa jossain vaiheessa ja toisen on niin helppo istua käsiensä päällä, kun oikeassa muodossa olevaa impulssia töiden aloittamiseksi ei saatu.

    Siis:
    4. Kaikki yli yksisivuiset toimitusprosessikuvaukset hiiteen ja tilalle yksi lause per toimittaja siitä mistä osa-alueesta kukin vastaa. Ja lopuksi käsky sopia asiat keskenään nopeimmalla ja sujuvimmalla tavalla.

    PS. En usko, että on mikään toimialan standardi yrittää viivyttää projekteja lisälaskutuksen toivossa. Kuitenkin asiakkaan toiveet ilman product owner -asennetta yhdistettynä koodaamiseen ilman johtajuutta saavat efektiivisesti saman aikaan.

    • Haluaisinpa vain todeta, että en todellakaan haluaisi olla potilaana jos järjestelmä olisi kehitetty näiden Markon ohjeiden mukaan. Olisihan se aidosti ketterää, mutta jos olet koskaan kokeillut vastaavaa oikeasti isossa projektissa, tietäisit, että tällä saavutetaan vain tuote joka on myös aidosti aina rikki jostain, kun julkaisusykli ei vaan anna periksi riittävän kattavalle testaukselle. Kyllä nämä oikeasti pitää testata kattavemmin kuin pelkkä hyväksymistestaus – integraatio-, regressio-, käytettävyys, suorituskyky- ja muut testaukset on kanssa hoidettava kunnolla ja kunnialla, ja tulokset tulee käydä läpi ja niistä oppiakin jotain. Myöskään ilman selkeitä vastuualueita ”sopikaa itse keskenänne”-mentaliteetilla ei päästä muuta kuin massiiviseen väärinymmärrysten suohon, enkä minä ainakaan uhraisi potilasturvallisuutta tällaiselle ideologiselle agilehihhuloinnille. Agilelle on paikkansa, mutta rajansa jeesustelullakin.

      • Heh, tämä asia riippunee, Jarkko, kunkin omista kokemuksista. Jos et ole näin hanketta tehnyt, mistä tiedät ettei se tule onnistumaan. Itse olen ollut mukana näin vedetyissä projekteissa ja lopputulokset ovat mielestäni olleet paremmat kuin missaan muussa keikassa koskaan.

      • Testausta on montaa sorttia toki, mutta ei tämän kokoluokan softaa kannata käsin testata ja nopeammassa syklissä ehtii mennä vähemmän asioita rikki. Toki todella odottamattomia juttuja tapahtuu, mutta riskiin perustuvalla tutkivalla testauksella saadaan mielenkiintoa ohjattua pienemmälle alueelle. Toimittamisenkaan ei tarvitse olla kertarysäys. Esimerkiksi suorituskykyä voi mitata käytännössä ajamalla uuden version käyttöön rajatulle käyttäjäkunnalle. Jos kuorma kasvaa yli ohjearvon, muutos perutaan.

        Tapoja on monia, mutta täytyy oikeasti haluta kehittyä softan toimittajana. Keinot löytyvät kyllä. Sekin vaatii keksintöjä.

  5. > XML sinänsä ei tekstimuotoisena
    > formaattina vaadi kentille pituusrajoja.
    > Itse asiassa olisi helpompaa tehdä
    > sanomajärjestelmä, jossa ei rajoja ole.

    Kyse lienee tarpeesta validoida viestin sisältö rajapinnoissa. Samalla tavalla voidaan väittää, että on helpompi tehdä järjestelmä, jossa ei ole autentikaatiota.

  6. Aika iso haloo muutamasta merkistä jolla ei loppukäyttäjän kannalta taida olla suurtamerkitystä?

    Itseäni ainakin hek.koht riepoo se ettei lapsen sähköistä arkistoa pääse näkemään huoltaja ja se, että sähköisen reseptin säilytysaika on vain 30 kuukautta.

    Onneksi reseptin saa vielä pareriversiona niin halutessa.

  7. Hyvin tuntui tuomivan tuo Kanta.fi. Ainoa tapa selvittää onko sähköistä reseptiä vai ei oli mennä apteekkiin kysymään.

Vastaa

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

Voit käyttää näitä HTML-tageja ja attribuutteja: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>