KOMMENTAR | Magne Jørgensen
Å tenke på slutten i starten - om avvikling og Helseplattformen
Når valget står mellom ulike løsningsalternativer for større investeringer i IT-systemer, brukes ofte kost-nytteanalyser som et beslutningsgrunnlag. Disse analysene ser sjelden eller aldri på forskjeller i hva det koster å avvikle det man skal anskaffe eller utvikle.
Dette kan føre til feilaktige lønnsomhetsanalyser, skjevheter i vurderinger av alternative løsninger og innlåsing i IT-løsninger man ikke har råd til å avvikle, slik tilfellet synes å være for Helseplattformen.
Når en statlig virksomhet skal velge mellom ulike IT-konsepter, for eksempel mellom en egenutviklet løsning, et standardsystem eller åpen kildekode, er det krav om at alternativene skal sammenlignes opp mot hverandre i en samfunnsøkonomisk analyse. Ikke-statlige virksomheter og privat næringsliv gjør ofte tilsvarende kost-nytteanalyser for å avgjøre om investeringer er lønnsomme, og for å velge det mest lønnsomme alternativet.
Det som sjelden eller aldri er med i slike analyser, er kostnaden ved å avvikle IT-løsningen når bruksperioden er over, og et nytt system skal anskaffes eller utvikles. Det er neppe fordi det er uvesentlige kostnader. Når et IT-system fases ut, påløper det betydelige kostnader, som datamigrering, reduksjon av teknisk gjeld for å sikre overføring av all nødvendig funksjonalitet, avvikling av integrasjoner mot andre systemer, oppsigelse av lisensbindinger, parallell drift i overgangsperioder og omstilling av rutiner og organisasjon.
Magne Jørgensen
Magne Jørgensen er professor ved SimulaMet der han forsker på IT-utvikling. Han leder senter for Effektiv Digitalisering av Offentlig Sektor (EDOS) og er medlem av Digitaliseringsrådet. Han skriver fast for Computerworld.
Ikke bare er dette kostnadskrevende, men i en undersøkelse vi nylig gjorde [1] av 56 norske systemavviklingsprosjekter fant vi at nesten halvparten av disse mislyktes med å slå av det gamle IT-systemet, og dermed trolig fikk svært høye driftskostnader og lavere brukervennlighet i mange år. Vi fant også at kompleksiteten og kostnadene med avvikling i svært stor grad hadde blitt undervurdert.
Innlåsing koster
Avviklingskostnadene innen IT samvarierer trolig med graden av leverandørinnlåsing. Et komplekst, proprietært fagsystem (standardsystem, hyllevare) vil kunne gi høyere avviklingskostnader, og mer kompleks og risikofylt overgang til nytt system, enn en løsning basert på egenutviklet programvare, open source, åpne standarder og portable data. Dette støttes i undersøkelsen vår der en stegvis overgang (som bruk av såkalt «strangler fig pattern»), som er enklere for modulære, egenutviklede løsninger, lyktes vesentlig oftere enn å bytte alt på en gang («big bang»).
Konsekvensen av å ikke ta med avviklingskostnader i kost/nytteanalysen er at løsningsvalg med høy innlåsingsrisiko fremstår med kunstig lav risiko og kostnad sammenlignet med mer fleksible alternativer.
Helseplattformen
Et eksempel på hvordan det kan gå når man ikke tar tilstrekkelig hensyn til avviklingskostnader er valget av Epic som system for elektronisk pasientjournal for Helse Midt-Norge (Helseplattformen). Mye er skrevet om Helseplattformens problemer med brukervennlighet, pasientsikkerhet og kostnader, men ikke så mye om det teknologiske valget og hvilke konsekvenser det har for innlåsing og avviklingskostnader.
Bedriften og IT-løsningen Epic har en fascinerende historie siden oppstarten i 1979. Teknologiske og forretningsmessige valg gjort de første årene etter oppstarten viste seg å være svært gode og bidro til at de etter hvert ble markedsledere. Men de har også klart å utvikle og selge en løsning som har svært store flyttekostnader. I en svært grundig Epic-positiv gjennomgang av historien til Epic i podcasten «Acquired» med Gilbert og Rosenthal (april 2025) [2] så oppsummerer de at Epics lock-in er «unmatched». De høye avviklingskostnadene kan også være med på å forklare hvorfor Epic aldri har mistet en kunde på alle de 47 årene de har holdt på! [3]
For å forstå grunnen til de antatt svært høye avviklings- og flyttekostnadene kan det være nyttig å se på hvilken teknologi som ligger i bunnen for Epic, og dermed også Helseplattformen.
Datidens begrensninger
Epics teknologiske kjerne var og er basert på MUMPS (offisielt navn er M). Navnet (Mumps = Kusma) var opprinnelig ment som en spøk, og akronymet ble først senere hevdet å stå for Massachusetts General Hospital Utility Multi-Programming System.
Epic, som da het Human Services Computing, valgte MUMPS av pragmatiske årsaker siden det var gratis og det neppe fantes bedre alternativer den gangen. Løsningen på datidens begrensninger med dyre og langsomme datamaskiner var at man gjorde nesten alt i MUMPS. MUMPS var og er både programmeringsspråk, databasespråk og databasemotor i ett uatskillelig hele, og kunne på 70-tallet i tillegg fungere som et helhetlig kjøretidsmiljø uten behov for et separat operativsystem.
Løsningen på datidens begrensninger med dyre og langsomme datamaskiner var at man gjorde nesten alt i MUMPS.
MUMPS lagrer data i en hierarkisk struktur (såkalte «globals») som trolig passer pasientdatas naturlige hierarki svært godt. MUMPS er altså som om Java, JVM og Oracle var smeltet sammen til ett produkt der språk og database er uatskillelige. Mens moderne applikasjoner typisk er modulære med separate database- og applikasjonslag, er Epics kjernearkitektur et udelelig hele.
Dette var trolig et bra valg for Epic den gangen valget ble tatt, og lenge etterpå, men kan i dag være mer et hinder og kan forklare en del brukerproblemer (som utfordringer med samtidighetshåndtering) [4] og ikke minst innlåsingsproblematikk og høye avviklingskostnader.
MUMPS-teknologien, og bruken av den i Epic (Chronicles), fører blant annet til høye flyttekostnader fordi:
- Datastrukturen er proprietær (og hierarkisk), ikke for eksempel relasjonell som størsteparten av andre IT-sytemer bruker. [5]
- Manglende skille mellom data og programvarekode.
- Lokale tilpasninger (skreddersøm) som delvis ligger i kjernen (Chronicles/MUMPS), delvis andre steder i Epic
- Manglende standardisering av datastrukturer og grensesnitt mot andre systemer
- Kompetansen i Chronicles/MUMPS finnes stort sett kun hos Epic, noe som gjør at Epic får et de facto monopol på kompetanse som trengs for å kunne avvikle
Sykehus og helsestasjoner kan ikke stoppe driften mens man migrerer, og konsekvensene av feil kan være svært høye. Dette gjør at risikoen ved å bytte IT-løsning i utgangspunktet er svært høy for alle IT-løsninger. Med valget av Epic har man ytterligere økt kostnadene og risikoen ved flyttingen. Flere, blant annet en 2026-artikkel publisert i PLOS Digital Health [6] , hevder at den økte risikoen og kostnadene ved å flytte er en bevisst del av forretningsmodellen til Epic. [7]
Millioner av kodelinjer på nytt
Hvorfor har ikke Epic modernisert kjernen og kommer neppe til å gjøre det? Dette er trolig mye av de samme grunnene til at flyttekostnadene er høye. Dersom man vil modernisere Epic, vil man trolig måtte skrive flere millioner linjer kode på nytt i kjernesystemet, samt endre store deler av implementasjonene hos tusenvis av sykehus og andre brukere. Det Epic i stedet har gjort, er å legge til flere moderne lag på toppen og på siden som til en viss grad skjuler kjernearkitekturen for brukere og utviklere. Det hjelper, men løser ikke alle problemer, og særlig ikke flyttekostnadene.
Forskjellen er at ingen ville vurdere å anskaffe et COBOL/IMS-basert kjernesystem for en norsk virksomhet i dag! Tvert imot.
En analogi: MUMPS er fra samme tidsepoke som, og har teknologiske likheter med, COBOL og IMS (hierarkisk database fra IBM), og alle tre driver fortsatt kritisk infrastruktur rundt om i verden. Forskjellen er at ingen ville vurdere å anskaffe et COBOL/IMS-basert kjernesystem for en norsk virksomhet i dag! Tvert imot. Det pågår store kostbare initiativer for å komme bort fra teknologien fra denne epoken, som flytting av kjernebanksystemet fra COBOL (og delvis IMS) til mer moderne teknologi. I lys av dette er det enda mer merkelig at Helse Midt-Norge valgte Epic.
Hva bør endres?
Man kan bare spekulere i om Helse Midt-Norge hadde valgt Epic dersom en grundig analyse av avviklingskostnader, innlåsing og flyttekostnader hadde blitt gjort. Men relevansen av å ta med slike kostnader og risiko bør være åpenbar, ikke minst ut fra caset med Helseplattformen. Så hvorfor gjøres det ikke?
Det er ingenting i offentlig regelverk, og helt klart ikke i privat sektor, som forhindrer noen fra å ta med avviklingskostnader i vurderingen av løsningsalternativer. Snarere tvert imot. Rundskriv fra Finansdepartementet (R-109/2021) og EU-direktivet om offentlige anskaffelser er begge tydelige på at alle relevante virkninger gjennom hele tiltakets levetid skal tas med, og at det å kunne endre kurs (ikke låses inne) er en verdi. [8] EU-kommisjonen sier for eksempel i sin IKT-anskaffelsesveiledning: «It is important that procurement decisions do not lead to organizations being unintentionally tied to certain products or suppliers. The ability to change products or suppliers should be included in one of the procurement options.»
Løsningen på problemet med at avviklingskostnader ikke tas med i analysen, krever altså ikke nytt regelverk, men kun tydeligere veiledning og endret praksis. Dette kan for offentlig sektor for eksempel starte med at DFØ (Direktoratet for forvaltning og økonomistyring) utvider sin veileder med et avsnitt om IT-spesifikke avviklingskostnader. Dette kan omfatte elementer som datamigrering, integrasjonsavvikling, lisensbinding, parallell drift, teknisk gjeld og leverandørinnlåsingsrisiko. I tillegg vil kvalitetssikringsordningen (KS1/KS2) kunne stille krav om at forskjeller i fremtidige avviklingskostnader og leverandørinnlåsing (manglende fremtidig fleksibilitet) synliggjøres.
Vanskelig å anslå
En mulig grunn til at avviklingskostnader (og effekten av innlåsing) ikke tas med i samfunnsøkonomiske analyser og sammenligninger mellom alternative løsninger, kan være at man synes det er vanskelig å anslå dem. Det er vanskelig, men høy usikkerhet kan aldri være en gyldig grunn til å utelate en vesentlig kostnadskomponent fra kost/nytteanalyser.
Dersom ikke avviklingskostnader tas med når ulike løsningsalternativer vurderes, og feil valg tas, vil organisasjonene før eller senere måtte betale prisen for lite fremsynte beslutninger.
En annen, også dårlig, grunn er at de som er ansvarlige for å velge løsning for nytt IT-system sjelden er de som kommer til å måtte avvikle det. Utviklings- og innføringskostnadene får dermed all fokus. Det kan også være at leverandørene gjør sitt for å gjøre det vanskelig å få tak i innlåsings- og avviklingskostnader.
Dersom ikke avviklingskostnader tas med når ulike løsningsalternativer vurderes, og feil valg tas, vil organisasjonene før eller senere måtte betale prisen for lite fremsynte beslutninger. At dette skjer først om mange år, når IT-systemet en gang skal byttes ut, gjør ikke prisen lavere.
Kilder og noter:
[1] papers.ssrn.com/sol3/papers.cfm?abstract_id=6257138
[2] www.acquired.fm/episodes/epic-systems-mychart
[3] freakonomics.com/podcast/what-makes-judy-faulkner-run/. Her sier Epics eier og leder at de mistet en kunde en gang, men at denne kom tilbake etter litt.
[4] Samtidighetshåndtering er et velkjent problem for databaser. For å unngå konflikter i hva som er gjeldende pasientdata, vil man unngå at to oppdaterer samme informasjon på samme tid. Samtidighetshåndtering er komplisert i Epic og er (såvidt jeg forstår) noe som i stor grad må programmeres i MUMPS-koden, mens man i mer moderne løsninger har databasesystemer som håndterer dette. I tillegg komer at Epics løsning har "pessimistisk låsing" (der ingen andre får lov til å endre før den første er ferdig), mens man i moderne løsninger har "optimistisk" låsing (der man løser problemene dersom det oppstår konflikter og lar folk jobbe i parallell). Dette ligger dypt i strukturen til Epic og er en følge av valget av MUMPS og underliggende hierarkisk datastruktur gjort på 1970-tallet, som sikkert var fornuftige da, men i dag gjør at løsningen blir mer kompleks og det er vanskelig å få til god brukervennlighet.
[5] Epic har en relasjonsdatabase for analyse og rapportering. Denne er imidlertid hverken fullstendig eller inneholder "forretningslogikk" på data-ene.
[6] Abulibdeh, R., Crowson, M. G., Douglas, M. J., Ramos, M., Saillant, N. N., & Celi, L. A. (2026). A problem of Epic proportion. PLOS Digital Health, 5(3), e0001143. (Nedlastbar fra: https://journals.plos.org/digitalhealth/article?id=10.1371/journal.pdig.0001143&?utm_id=plos111&utm_source=internal&utm_medium=email&utm_campaign=author)
[7] Konsekvensene av lock-in viste seg da Stortinget i 2026 vurderte å avvikle og bytte ut Helseplattformen. Sopra Sterias analyse, bestilt av Helse Midt-Norge, landet på 14,2 milliarder kroner og syv års gjennomføringstid for et systemskifte. Selv om kritikere har påpekt at den reelle merkostnaden trolig er lavere, kanskje rundt 5 milliarder, er hovedbudskapet det samme. Et system som ble innført i 2022 viste seg fire år senere å være praktisk talt umulig å bytte ut uten store økonomiske og driftsmessige konsekvenser. Når Epic-kunder først er innenfor, er det nesten alltid dyrere å gå enn å bli. Et annet forhold er at hva flyttekostnadene faktisk er vil være svært usikkert siden ingen sålangt har avviklet en implementert Epic-løsning.
[8] Formelt sett er kostnader ved avvikling for samfunnsøkonomiske analyser dekket av restverdi-begrepet. Dersom avviklingen koster mer enn systemet er verdt, er restverdien negativ. Det er metodisk korrekt, men selve begrepet «avviklingskostnad» eller tilsvarende begrep opptrer ikke i veilederen, og det gis ingen veiledning spesifikt for IT-konteksten.
