En innføring i helse-IT for utviklere

Etter å ha fulgt debatten om Helseplattformen og Akson blant utviklere har jeg sett at domenet helse-IT er et område mange av de med IT-bakgrunn som deltar i debatten ikke har mye innsikt i. Jeg har heller ikke bakgrunn i helse-IT men har vokst opp i en familie der alle er i helsevesenet og kjenner folk som har drevet med drift, support, test, utvikling og tilpasning av journalsystem. Jeg har hørt utallige historier og hjertesukk fra alle mulige kanter. Hvorvidt Helseplattformen og Akson som prosjekt og valgene som er gjort er bra ønsker jeg å forholde meg ganske agnostisk til, det får ettertiden bedømme. Jeg ønsker å belyse hvorfor helse-IT har en del utfordringer og kostnader som gjør disse litt annerledes enn mange andre IT-prosjekt.

Når helsepersonell skal bytte til et nytt journalsystem

Et journalsystem er et arbeidsverktøy for leger og sykepleiere. Det er en naturlig del av jobben slik som pasientkontakten og medisinering. Å bytte journalsystem er et nødvendig onde. Helsepersonell ser med like stor glede på å bytte journalsystem som utviklere ser på timeføring og vedlikehold av prosjektdokumenter. 

Å bytte til et nytt journalsystem på et sykehus er som om en utvikler må skifte til et nytt operativsystem, IDE, versjonskontroll- og byggesystem over natta. Dagen etter forventes det at du er omtrent like produktiv som du var med det gamle. I tilfelle du sliter med å få opp gammel kode er den mest sentrale koden skrevet ut på papir. Oppstår det et avvik i produksjon som krever en umiddelbar patching skal denne gjennomføres uten at du har mulighet til å gå tilbake til det du hadde før. Man kan rett og slett ikke leve med to journalsystem, alt må være flyttet over. Å lage auto-sync mellom to system vil være uten gjenbruksverdi og svært risikabelt.

Du kan også spørre hva fastlegen din mener. Veldig mange fastleger jobber 60 timer i uken og de fleste er selvstendig næringsdrivende. Å skulle sette seg inn i et nytt journalsystem er en oppgave som kommer på toppen av alt annet og ikke generer inntekter. Av og til er det nødvendig og da må det ikke oppleves som et steg bakover.

Forskning på innføring av nye journalsystem viser at dette må være godt forberedt. Svært godt forberedt. Det typiske er at noen brukere må kunne det nye systemet inn og ut. Til dette trenger du noen av de mest erfarne og innflytelsesrike blant helsepersonellet. I tillegg må ca. hver femte ansatt ha god opplæring slik at de kan bistå kolleger som trenger hjelp i startfasen. I tillegg må rent IT-personell være tilgjengelig under innføringen for alt som ikke handler om selve bruken av journalsystemet. Husk at helsepersonell jobber til alle døgnets tider og ekspertisen vil det være behov for døgnet rundt og bemanningen bør også økes i overgangsfasen. Dette er i seg selv ikke kontroversielt, men det har en kostnad. Sentrale og godt betalte personer fra hver avdeling skal altså bruke mye av arbeidstiden sin på å bli gode eller svært gode på det nye systemet. For at ikke driften av sykehuset skal lide må disse kjøpes fri ved at de og andre jobber overtid fordi det ikke finnes ledig kapasitet i systemet. For ting som ikke er akutt kunne man velge å la helsekøene vokse, men det har også sin pris. Når man ser på prislappen på innføring av et nytt journalsystem skal du ikke være overrasket om noen hundre millioner eller kanskje milliarder går til akkurat dette. Prislappen øker med størrelsen og kompleksiteten i systemet og ikke minst med antallet brukere.

Alternativet er at man velger å ignorere denne kostnaden. Den må da enten tas over andre budsjett på sykehuset eller man får håpe det beste ved innføring av nytt system. Begge disse alternativene er en oppskrift på katastrofe på ulike måter, det viser forskningen som er gjort på området. Det var også et av problemene i den danske Sundhetsplatformen.

Stort eller mange små system

Må vi ha ett system for alt? Ikke nødvendigvis. La oss først se på hvordan ting har vært. Hver helseregion eller deler av disse har hatt hvert sitt journalsystem på sykehusene. Legekontorene har hatt helt andre system. Journalsystemet har hovedsakelig fokusert på journal og det har vært andre system for oversikt over hvilken seng pasienten er i eller medisinering. Det går med mye tid til dobbelføring av informasjon og overføring mellom ulike system. Tenk på når du selv har endret kode om du samtidig har endret eventuelle kommentarer og medfølgende dokumentasjon. Overføring og dobbelføring innfører lett flere feil, noe som potensielt kan være dødelig i helsevesenet.

Når en journal skal overføres fra et sykehus til et annet i en annen helseregion har dette skjedde ved at journalen skrives ut og sendes til det andre sykehuset hvor den scannes og legges ved journalen. Her er ikke problemet om postgangen er elektronisk eller ikke. Problemet er at du nå ikke har en søkbar journal. En lege har ikke tid til å finlese en journal som kanskje er på 30 eller 50 sider. Hadde det vært søkbar tekst hadde det vært enklere. 

Nå ønsker man å knytte sykehus, legekontor og andre behandlere tettere sammen via et felles system. Dette gjør vi ikke i noe særlig grad i dag da alle sitter med sine system som ikke snakker særlig effektivt sammen. Men sett at du brekker beinet og kommer til sykehuset. Etter undersøkelse og noen røntgenbilder er diagnosen ganske klar og hele forløpet kan egentlig legges opp automatisk. Du får en seng, du blir satt opp til operasjon, gipsing, postoperativ behandling, tilbake til sengepost, du får automatisk time for ny røntgenundersøkelse, oppfølging hos fastlegen og opptrening med fysioterapeut på hjemstedet. Alt dette kan ordnes som en samlet pakkebestilling i det diagnosen er klar, systemet finner automatisk ledig kapasitet og gjør avtaler. Gjett hvor mange system som er i bruk for alle disse operasjonen i dag og hvor mye tid som går med til det i dag. Prøv å ikke tenk på hvor ofte noe blir glemt og hvor mye menneskelig smerte og frustrasjon som følger med det.

Men kan vi ikke knytte sammen eksisterende system og bytte dem ut en etter en? Jo, det har også blitt prøvd i Norge. Det ble laget en plattform som alle skulle bruke til å kommunisere. Men mange av leverandørene av systemene som skulle snakke sammen via plattformen klarte ikke å levere oppdateringene sine i tide eller i det hele tatt. Hele prosjektet strandet. IT på et sykehus er et levende museum med et helt økosystem av et femsifret antall systemer utviklet gjennom de siste tretti årene. Eller mer. Noen av leverandørene og utviklerne finnes ikke mer.

Hyllevare eller skreddersøm

I de store helseprosjektene blir det ofte snakk om å kjøpe et system som er i bruk på andre sykehus andre steder i verden. Mange steiler når de ser prislappen på tilpasning av et slikt system og tenker at «med den prislappen er det skreddersøm og ikke hyllevare». Ja og nei. Systemet er ferdig utviklet, men må tilpasses. Ta for eksempel et amerikansk system. Det vil være sterkt preget av amerikansk lovgivning og forsikringsbransje. Å ikke tilpasse dette til norske forhold vil bety at leger og sykepleiere vil kaste bort masse tid hver dag på spørsmål og valg som er totalt irrelevante for oss i Norge. At betalingen ikke skal komme fra forsikringsselskap men fra en kombinasjon av egenandel fra pasient og HELFO er en annen endring. Så kommer alle de norske skjemaene for blodprøver, sykmeldinger, andre skjema fra NAV etc. I tillegg skal det sendes informasjon til kreftregisteret, fødselsregisteret, vaksinasjonsregisteret og mange andre. E-resept er en selvfølge. Språk er jo en annen ting som må tilpasses. Denne jobben setter du ikke bort til et oversettelsesbyrå, men du tar derimot med en gruppe erfarne fagfolk som tilpasser til det virkelige språket på sykehuset. Du må gjøre tilsvarende med all arbeidsflyt for alle de typiske handlingene som er relevante i alle områder av helsetjenesten for at systemet skal jobbe med og ikke mot. Husk at legene, sykepleierne og de andre du bruker til denne jobben skal ha lønn eller at de som gjør den kliniske jobben i deres sted har krav på overtidsbetaling. Alle disse kostnadene skal også gå inn i prosjektet. Det koster mer enn du liker å tenke. Alternativet er et svært lite brukervennlig system som kaster bort mer personalressurser enn god tilpasning.

Små eller store endringer

Hva er MVP for journalsystem? Ingen i helsevesenet får noe som helst verdi av å innføre enda et system som gjør mindre enn et som allerede er der. Verdien kommer først når et nytt system gjør noe bedre enn det eller de systemene det erstatter. Da er tusenvis av årsverk allerede brukt. Det har vært flere norskutviklede journalsystem som ikke har tatt steget til det som kreves av et system slik det er etterspurt i Helseplattformen og Akson.

Sett at du måtte gå over til et nytt IDE. I første omgang inneholder det samme funksjonalitet som Notepad i tillegg til en kompilator. Men alle blir lovet at det stadig vil dryppe inn ny funksjonalitet. I mellomtiden kan du gjøre søk i filutforskeren i Windows. Alle som trenger det kan få kurs i å skrive raskt på tastatur slik at man ikke er like avhengig av autocomplete, og vet du ikke hva metoden heter kan du alltids slå det opp. Versjonskontroll kan ordnes av andre system. Tester kan kjøres av andre system. Det blir tungt å navigere rundt i koden, men det er allerede på roadmap å støtte det. Mange små leveranser er fint, men de gir ingen verdi før et punkt der tilstrekkelig funksjonalitet er på plass.

Agile og mange små leveranser har blitt normen innen IT-prosjekt. Det har ikke blitt normen innen helsevesenet. Man introduserer ikke bare en ny versjon uten omfattende testing og beredskapsplaner ved utrulling. Både feil som oppstår under installasjon og bruk kan få fatale konsekvenser slik at sannsynligheten for disse må minimeres. Man kan godt si at sykehus henger etter og at en annen modell hadde vært bedre, men man vil raskere enn ellers nå smerteterskelen for hvor ofte man tåler ustabilitet og småfeil. Avbrutte operasjoner, feilmedisinering og manglende tilgang til kritisk informasjon er ikke gøy for noen part. Et annet spørsmål er hvordan man takler informasjonsflyten i hyppige leveranser. Personalet kan raskt gå i metning på stadige endringer, og man kan heller ikke informere alle på et allmøte, det er alltid noen vil være på vakt og noen som har turnusfri.

For en del år tilbake ble det innført en liten endring på et system på et norsk sykehus. Økonomiavdelingen hadde fått delt en avdeling i to slik at de kunne få bedre oversikt over kostnadene på de to sengepostene. (Sårt tiltrengte endringer som legene hadde mast om i lang tid var ikke prioritert til leveranse på veldig lang tid.) Installasjonen ble lagt til fredag ettermiddag. Et naturlig tidspunkt siden det er færre brukere av systemet i helgene; det verste tidspunktet siden bemanningen er lavere i helgene. Konsekvensene for leger og sykepleiere på vakt i helgen var at de ikke fant pasientene i systemet da de søkte på avdelingen slik de var vant til. De måtte raskt gå over til penn og papir. Totalt kaos hele helgen, men heldigvis gikk ikke liv tapt… Endringen måtte rulles tilbake og en oppdatering til flere hundre tusen kroner gikk rett i søpla. Om ikke annet er det et godt eksempel på hva en liten endring kan føre til om systemet ikke testes slik det faktisk blir brukt og informasjonen ikke gis til aktuelle brukere.

Mange arbeidsoperasjoner i et journalsystem er rutine for helsepersonell. De klikker seg gjennom de samme sekvensene av valg mange ganger hver dag og vet nøyaktig hvor de skal trykke og hva som er neste spørsmål. «Snikinnføres» endringer på et spørsmål risikerer man at mange mater systemet med gal informasjon. De har rett og slett ikke tid til å lese alt hver gang når de uansett vet hva som står der. Igjen er det livsviktig å informere ved endringer. I slike situasjoner kan det øke personalets oppmerksomhet på endringer dersom endringer kommer samlet og ikke som en endeløs strøm av små justeringer.

Ett eller mange system

Alle ønsker system som snakker sammen. Vi har prøvd å sy sammen system fra mange ulike leverandører uten hell tidligere. Hvis vi starter fra bunnen av og følger åpne standarder vil systemene lettere fungere sammen. For en utvikler er dette åpenbart. Problemene oppstår imidlertid på et senere tidspunkt. Når disse systemene skal driftes har man først og fremst en større miks av arkitektur og teknologi. Deretter har man raskt flere kontaktpunkter for support der man opplever lengre runddanser der alle skylder på hverandre. Det er også sannsynlig at man velger en modell der hvert enkelt delsystem settes ut på anbud og leveres av ulike leverandører. Ikke noe problem under utvikling, men mange av systemene vil etter hvert ikke være i aktiv utvikling og svært få av de som skrev koden og kjenner den godt vil være tilgjengelige når videreutvikling eller vedlikehold trengs.

Flere system må ikke bare snakke godt sammen, de må også være raske og enkle å bruke. Du skal ikke trenge å flytte data manuelt mellom dem. Det må også gå lynraskt å skifte mellom de ulike systemene, du skal ikke trenge å bruke tid på å logge inn flere steder. En lege sa for en del år siden at hun i løpet av en vakt brukte ca. en og en halv time på å vente på datasystem. Det blir mye endring av kontekst, pasienten opplever vekslende fokus hos legen og mye verdifull tid går tapt.

Burde vi ikke lage dette selv?

For meg virker det som om at mange som ser på prislappen på altomfattende helseprosjekt tenker at dette kunne vi løst selv, kanskje til og med til en lavere pris. Spørsmålet er egentlig om vi burde det. Og det er hovedsakelig et spørsmål om økonomiske og menneskelige ressurser. Ønsker vi å satse på å utvikle et eget journalsystem for lille Norge? Vil dette være billigere i det lange løp enn å kjøpe et system fra en leverandør som allerede har et system å tilby? Vil dette en gang i framtiden kunne selges til bruk hos andre? Har vi nok tilgjengelige utviklere i dette landet til å lage alt fra bunnen av? Svaret på det siste spørsmålet er nei. Det er stolleken så det holder i norske IT-selskap allerede. Det hentes utviklere fra utlandet der det er mulig og det settes bort utvikling til utlandet over en lav sko fordi vi ikke har tilstrekkelig antall mennesker med rett kompetanse. Å skulle satse på at vi skal utvikle vårt eget journalsystem vil gi en lønnsfest for utviklere generelt og IT-konsulentene spesielt, som vil oppleve tidenes etterspørsel etter folk. Det vil være en tragedie for alle eksportrettede IT-bedrifter og gi en kostnadsøkning for andre bedrifter med et behov for utvikling.

Sluttord

Det er mange som kritiserer prosjekter innen helse-IT. Kritikken gir veldig mange et inntrykk av at aktørene innen helse-IT ikke har fulgt med på hvordan ting har utviklet seg de siste tiårene. De som har et innblikk i fagfeltet ser at veldig mye av kritikken bommer fullstendig på grunn av manglende kjennskap til fagfeltet. Store offentlige prosjekt trenger helt klart et kritisk søkelys og det er viktig å ta tak i kritikkverdige forhold tidlig. Jeg håper denne teksten kan være en forholdsvis rask introduksjon til hvorfor en del ting gjøres annerledes når IT møter helsevesenet og konsekvensene dette får i prosjektene.

Om forfatteren: Halvor Sakshaug jobber i softwarefirmaet Confirmit som Application Security Lead, men driver fortsatt med en del utvikling. Han har mange nærstående som jobber i helsevesenet og mange nærstående som har jobbet med drift, support og test av helse-IT. Har ingen aksjer, næringsinteresser eller andre bindinger til leverandører eller beslutningstakere innen helse-IT.