Distribuerte løsninger basert på åpne standarder vs sentraliserte og proprietære løsninger - hva er fordelene og ulempene? I Norsk helsevesen har de prøvd det meste - la oss se litt på effekten av forskjellige strategier.

Åpne standarder og mangfold

Idag har så å si alle minst én epost-adresse. En til jobb, og en eller flere til privat bruk. Disse hører gjerne til forskjellige epost-servere; Microsoft på jobb, og gmail privat for eksempel. Men det gjør ikke noe. Vi kan sende mail fra en server og til en annen helt uten problemer. Vi må ikke selge sjela til Microsoft eller Google for å sende eller motta e-post. Det finnes tusenvis av epost-tjenester rundt omkring man kan bruke. Du kan lage din egen også hvis du vil. Så lenge en følger standard-protokollene kan man sende og motta eposter mellom alle mulige mail-servere.

Kjempebra.

Det har etterhvert blitt mange slike desentraliserte løsninger som lar folk samhandle uavhengig av hva slags applikasjoner eller servere de selv bruker.

Åpne standarder som HTML og HTTP gjør at internettet kan surfes via mange forskjellige nettlesere, og innhold kan leveres via utallige forskjellige server-teknologier.

Fordelene ved å ha slike åpne standarder som alle kan implementere sine egne versjoner av er åpenbare.

Tregt og begrenset

Men med fordeler kommer det ofte også ulemper.

I tilfellet desentraliserte og distribuerte IT-løsninger snakkes det lite om ulempene, men vi har alle merket dem, kanskje uten å tenke over det.

Ta epost. Standarden for epostutveksling SMTP (Simple Mail Transfer Protocol) ble utarbeidet i 1980. Siden den gang har flere og flere implementert egne mail-servere som bruker denne protokollen. For hver aktør som implementerer en e-post-server og klient, blir det vanskeligere og vanskeligere å utvide og utvikle protokollen. Man kan ikke ta ibruk ny funksjonalitet før alle har implementert den. Jo mer vellykket en slik distribuert åpen standard er, jo vanskeligere blir det å forbedre den. Det er kanskje derfor vi i så stor grad bruker andre måter å kommunisere på digitalt. Snapchat, Slack, Teams, Facebook Messenger, WhatsApp… Dette er proprietære løsninger for kommunikasjon. Man kan ikke sende en melding fra Facebook Messenger til Slack. Likevel velger vi ofte disse fordi de gir en bedre og rikere brukeropplevelse.

Hvis Slack-teamet har lyst til å implementere ny funksjonalitet, kan de bare gjøre det - og dytte det ut til alle brukere i en operasjon. De trenger ikke koordinere med noen andre. Det er mye mer effektivt.

Hva skal det offentlige levere?

Jeg har engasjert meg mye i offentlig IT de siste årene, og her kommer man borti denne problemstillingen stadig vekk. Hva er det det offentlige skal levere? Skal det offentlige levere ferdige løsninger de kan jobbe effektivt med? Eller skal de levere standarder som private aktører i et marked må implementere selv? Eller skal vi gå for en blanding? Utarbeide standarder, implementere dem selv, også åpne for at private også implementerer standardene? Eller hva med å bare kjøpe inn én proprietær 3.partsløsning som bare gjør alt, så ingen trenger å lage noe som helst?

Helse har prøvd alt

Innen helse har man valgt veldig forskjellige strategier for forskjellige typer data og bruk. Hvorfor disse valgene har blitt gjort vet jeg lite om, men det er interessant å se på effektene.

Pasienter

For oss pasienter har det offentlige valgt å lage en ferdig proprietær web-løsning de kan jobbe effektivt med in-house. Vi pasienter logger oss inn på HelseNorge.no og får mer og mer informasjon og funksjonalitet tilgjengeliggjort der.

Helsepersonell

For helsepersonell begynte man på noe litt liknende med Kjernejournal Portal som kom ut i 2013. Her også har man en proprietær webløsning som kan oppdateres fortløpende av det offentlige uten at det nødvendigvis er noen koordinering med aktører i sektor. Men av en eller annen grunn, har man valgt at denne proprietære webløsningen må være bygget inn i et journalsystem (EPJ) laget i privat sektor. Dette gjør at alle EPJ-leverandører må implementere en løsning for dette i henhold til en standard - som så er vanskelig å få oppdatert. I tillegg skaper det kompleksitet i Kjernejournal Portal å håndtere innlogging og brukersesjoner, og man er låst til å vise løsningen i hva det nå enn er for nettleser EPJ har valgt (og ikke hatt tid til å oppdatere). For eksempel er man forpliktet til å støtte IE11 (som ikke lenger er supportert av Microsoft), da Helseplattformen bruker den til å åpne Kjernejournal.

HelseNorge.no er en moderne, universelt utformet webløsning som fungerer like godt på mobil som på desktop. En stor kontrast til Kjernejournal Portal som i stor grad ser ut som den gjorde i 2013. Det er samme organisasjon som står bak, så det er ikke kompetansen som mangler, men valgene man har tatt rundt hvordan vi skal levere IT-løsninger som står for forskjellene.

Ved å gå for en løsning som krever at alle private aktører må implementere noe, så har man også valgt en løsning som er mye vanskeligere å oppdatere. Selv en så liten ting, som å miste kontroll over hvordan løsningen åpnes, skaper enorme forskjeller i hva man er istand til å levere.

Man kunne bestemt seg for at helsepersonell logger rett inn i Kjernejournal portal, slik pasienter logger rett inn i HelseNorge. Men det har man ikke gjort. Hvorfor ikke? Jeg vet ikke.

Helse Midt-Norge

Men må staten lage noe selv i det hele tatt? Kan ikke bare markedet levere? I Helse Midt-Norge tester man nå ut en variant der staten i utgangspunktet ikke skulle trenge å utvikle noe som helst. Man kjøper inn ferdig hyllevare som “gjør alt”. Helseplattformen er basert på det Amerikanske systemet Epic. Argumentasjonen min hittil skulle tilsi at dette nok er den mest effektive måten å få gode løsninger på. Men det er ikke det vi ser. Avisene både lokalt og nasjonalt har vært fulle av reportasjer om alvorlige feil og mangler og elendig brukervennlighet. Hva har gått galt?

Dårlig brukervennlighet kommer av at systemet ikke er laget for norske forhold. Epic kommer aldri til å prioritere norsk brukervennlighet. Vi vil aldri kunne bli mer enn en av deres aller minste kunder, og det er ikke i deres interesse å lage spesialtilpasninger til hver eneste kunde uansett. Det hjelper lite å ha en effektiv utviklings-organisasjon, hvis denne aldri kommer til å prioritere dine ønsker uansett.

Når det gjelder de andre feilene rapportert i Helseplattformen er vi i stor grad tilbake med dette med felles standarder og problemene de fører med seg. I motsetning til de fleste andre kundene til Epic har Norge allerede et digitalt helsevesen der meldingsutveksling skjer mellom forskjellige systemer i henhold til avtalte standarder. En Epic-installasjon i Norge kan ikke leve i et vakuum. Med mindre hele Norge innfører Epic (skrekk og gru), må Epic uansett kunne sende epikriser, prøvesvar, resepter og mer til helsepersonell som ikke bruker Epic. Helseplattformen har typisk fulgt siste godkjente standard for meldinger, men det er det slettes ikke alle som har. Så når de sender ut meldinger i siste format, så kan det vises fint i ett legekontor, men ikke i et annet. Dette er en kjent utfordring for alle som har drevet med webutvikling. Man lager en løsning som ser helt topp ut i Chrome, men ser det bra ut i Firefox? Kanskje ikke. (Og i IE11 fungerer den ikke overhodet)

Sentraliserte vs desentraliserte APIer

Også når det gjelder APIer jobber man med helt forskjellige tilnærminger innen helse.
Det er to spennende løsninger for deling av helseinformasjon som breddes til flere og flere om dagen. Deling av journaldokumenter og deling av prøvesvar.

Journaldokumenter

Deling av journaldokumenter skjer ved at alle sykehus må ha IT-systemer som integrerer seg mot en felles tjeneste for deling av dokumenter. De må selv få skrevet kode som står for tilgangsstyring og levering av dokumenter.
Dette er det ikke alle som har fått tatt seg tid til. Helseplattformen deler for eksempel ikke journaldokumenter ennå. Når en lege åpner Kjernejournal portal og går til fanen “Journaldokumenter” går et kall ut til samtlige institusjoner som er påkoblet og disse må da svare i samme format med informasjon om hva slags dokumenter de har tilgjengelig.

Hver institusjon kan potensielt ha feil versjon av standarden, de kan være nede, de kan ha forskjellige regler for utlevering og forskjellige formater på dokumentene. Det er ikke helt rett frem å teste at et slikt system fungerer som det skal, så feil blir naturligvis mer krevende å avdekke. Endringer i regler eller formater vil kreve at alle aktører gjør en jobb.

Prøvesvar

Løsningen for deling av prøvesvar, som etter planen blir tilgjengelig til neste år, vil fungere på en helt annen måte. Allerede idag har vi meldingsstandarder for å rekvirere prøver, og for å få svarene i retur. Når en lege rekriverer en prøve fra f.eks et Fürst-laboratorium, så vil Fürst-systemene sende svarene tilbake til rekvirent i et standard xml-format. Alle EPJer har implementert visning av prøvesvar som kommer inn på dette formatet. Prøvene ligger da både hos laboratoriet, og i journalsystemet til rekvirerende helsepersonell. Men er f.eks ikke tilgjengelig på legevakta, eller hos den nye fastlegen.
Dette problemet skal den nye tjenesten for deling av prøvesvar løse. Her kunne man sett for seg at man valgte samme strategi som for journaldokumenter. Man kunne laget et opplegg der alle legekontor koblet seg på et felles delingsnettverk og selv sto ansvarlig for å dele informasjonen de hadde liggende lokalt. Men istedenfor har man gjort følgende: Når laboratoriene sender svarene i retur til rekvirent, sender de også samme melding på kopi til et nasjonalt register.

Da får det nasjonale registret kopi av alle svar for alle pasienter og kan dermed gi dem ut samlet til helsepersonell som har tjenestelig behov. Dette krever betydelig mindre jobb for alle aktører. Det eneste laboratoriene trenger å gjøre er å legge til en cc i en melding de allerede sender. Rekvirent trenger ikke gjøre noen endringer overhodet. Norsk Helsenett (NHN) tar seg av resten. NHN har også laget en visning av prøvesvar i Kjernejournal portal, slik at EPJ slipper å implementere dette hvis de ikke har tid eller kapasitet.

Hva skal man velge?

Det er altså mange måter man kan velge å lage IT-systemer på. Alle med fordeler og ulemper.

Hvis du lager en helt egen løsning som “gjør alt”, vil du i størst mulig grad kunne jobbe effektivt med denne løsningen. MEN du forplikter deg da til å nettopp gjøre alt. Man mister også muligheter til å utnytte evt innovasjon i markedet. Det at vi har helsenorge.no, gjør at det ikke er så store muligheter for en privat aktør å selge inn sluttbrukerløsninger for pasienter. Er det et problem? Det spørs hvem du spør.

Hvis du baserer deg på åpne standarder som private aktører må implementere, så velger du en løsning som vil ta lang tid før er på plass, og som når den er på plass vil være vanskelig å teste og tung å oppdatere. Men man åpner da for et levende marked der nye aktører kan komme og implementere standardene på bedre og bedre måter.

Kjøper du inn hyllevare, må du passe på at hyllevaren i størst mulig grad løser oppgavene på en god måte “ut av boksen”. Det er naivt å forvente at en stor internasjonal leverandør kommer til å prioritere å endre sine produkter bare for å støtte norske behov. Og hvis man må stå for store mengder lokale tilpasninger selv - så er man dømt til et frustrerende evighetsarbeid med å holde disse tilpasningene ved like ved nye oppgraderinger av hyllevaren. Tilpasning av hyllevare - det er skreddersøm det. Skreddersøm, der skredderne må arbeide med boksehansker på. Istedenfor å skrive enkel kode som løser et konkret problem, må man skrive kode som hacker til et system som var laget for noe helt annet. Det er forsvinnende få fordeler med en “hyllevare med tilpasning”-modell. Det skaper arbeidsplasser for boksehanske-skreddere og er en god inntektskilde for leverandører av “hyllevaren” man kjøper inn. For meg er ikke dette å anse som fordeler på noe som helst plan.

Ikke kast noe som fungerer

Sist, men ikke minst, uansett hvilken tilnærming du har valgt, vil det nesten uansett være dyrere å kaste noe som fungerer ut, for å begynne på en helt ny løsning fra scratch og håpe på at den vil levere på alle områder når den “er ferdig” om noen år.
Selv om løsningen for prøvesvar er mer effektiv enn løsningen for journaldokumenter, så fungerer dokumentdelingsløsningen fint og har sine fordeler. E-resept-systemet er vanskelig å jobbe med, men det funker. Det blir aldri perfekt uansett hvilken tilnærming man har brukt. Det vil alltid være noen ulemper og noen vil være misfornøyde. Vi må prøve å gjøre det beste ut av situasjonen vi er i, men passe på at nye valg vi tar er bedre enn de forrige. Dette skjer kun hvis beslutningstakerne er informert om fordeler og ulemper ved valgene de må ta.
Jeg håper denne teksten kan være et bidrag i å øke denne forståelsen.