Akson-prosjektet, hva er alternativet?

Akson-prosjektet har fått mye kritikk.
Akson-prosjektet har fått mye kritikk.

Inga Nordberg fra Direktoratet for e-helse forsøker å imøtegå kritikken som har kommet mot Akson-prosjektet. Hennes hovedpoeng er at en ikke kan bruke «smidig»-metodikk til store kompliserte IKT-prosjekter. Bortsett fra at det baserer seg på en misforståelse av hva «smidig»-metodikk er, bommer hun på selve hovedpoenget: Det er tilnærmingen til problemet som er kjernen i kritikken.

Prosjektet har stilt spørsmålet «Hva er alternativet?» Det er et reelt, og ikke et retorisk spørsmål, som fortjener et svar. Kanskje ligger det her. Akson-prosjektet illustrerer nemlig forskjellen på «nedstrøms»- og «oppstrøms»-digitalisering.

Ett enkelt eksempel på «nedstrøms»-digitalisering

Politiet har laget en hel-digital prosess for å søke om politiattest. En politiattest er viktig å ha for f.eks. de som søker jobb som vektere. Den forteller om du har noen dommer på deg.  Du må levere attesten innen tre måneder til arbeidsgiver, og arbeidsgiver kan ikke be om ny attest hvis du ikke skifter jobb eller stilling.

Hva er feil her? Attesten har null verdi dagen etter at den er skrevet ut, fordi nye relevante opplysninger kan ha kommet til. Men viktigst av alt – den er basert på digitalisering i forhold til «nedstrøms»-prosesser som fanger opp data fra ulike kilder til et endelig resultat i form av et fysisk dokument.

Slik er det med mange prosjekter i forvaltningen – de fokuserer på digitalisering av de prosessene som fører frem til et (fysisk) sluttdokument med historiske data.

Alternativet «oppstrøms»-digitalisering

Alternativet er digitalisering av «oppstrøms-prosesser». Det betyr at prosesseringen skjer der dataene oppstår, at dataene lagres og forvaltes lokalt (f.eks. i en skytjeneste), og videreformidles gjennom en sikker, autorisert infrastruktur i et økosystem med flere domene-eiere. Deling av data skjer ved bruk av åpne API-er.

Det er dataene som er viktig, ikke applikasjonen, dvs. «leveringen» av historiske data i et sluttdokument fremfor tilgang til sanntids-data fra der dataene oppstår.

Et slikt perspektiv medfører nye og annerledes utfordringer:

  • Den teknologiske utfordring i form av ny IKT-arkitektur ved å gå fra en monolittisk IKT-arkitektur til et nettverk av data.
  • Den strategiske utfordringen ved å endre fokus fra horisontal samhandling på tvers mellom likesinnede, til vertikal integrasjon på langs i en verdikjede hvor også IKT-leverandørene inngår som partnere og bidragsytere.

«Open eHealth»?

Det finnes flere eksempler på denne formen for «oppstrøms»-digitalisering og verdikjedesamarbeid. EU har gitt bankene nye regulatoriske krav som medfører at de må gi tilgang til sine bankdata gjennom åpne API-er. Dermed kan flere aktører utvikle og levere nye tjenester til bankkundene. Dette kalles «open banking».

Den samme tankegang ligger bak prosjektet Nordic Smart Government» i regi av Brønnøysundregistrene og tilsvarende enheter i de nordiske landene.  Konseptet medfører at deling av data ikke skjer gjennom regnskapsdokumenter, men lokalt der data oppstår og forvaltes, hentes etter behov fra økosystemet gjennom åpne API-er og standardiserte grensesnitt, og videreformildes i en sikker infrastruktur (Peppol). Samarbeid med ERP-leverandørene er her helt essentielt. Dette kalles «open accounting».

Les også

Kan en tenke seg denne analogien overført til helsesektoren med sine kompliserte strukturer og mangfoldige IKT-systemer? Er et «open eHealth»-konsept et alternativ til Akson? «Ved å tilrettelegge for sentral metadata-forvaltning og en god – og moderne systemarkitektur – vil man kunne ha all hjemlet og relevant pasientinformasjon tilgjengelig selv om den er spredt over flere systemer», sier Tor Arild Sunnevåg i sin blogg i en kommentar til helsebyråd Robert Steens innvendinger mot Akson-prosjektet.

Hvordan kommer en dit?

De problemene som nåværende pasientjournal-opplegg i kommunene medfører, er kjent og akseptert av alle. Inga Nordberg mener å tegne et nytt målbilde for å løse dagens situasjon bestående av en komplisert IKT-arkitektur. Men et målbilde må ta utgangspunkt i en fremtidig visjon om hva helse-Norge vil være om noen år.

Den visjonen kan f.eks. se slik ut: Det finnes ikke lenger noe sykehus. All behandling skjer i hjemmet ved hjelp av smarttelefon; Pasienten blir selv innovatør, produsent og utvikler av nye helsetjenester; Behandlingen og medisineringen blir persontilpasset; Kravspesifikasjonenes tid er forbi, all utvikling blir behovsdrevet; Kunstig intelligens brukes for å planlegge innleggelse, utskriving og ledig kapasitet; Ny teknologi fører til fokus på forebygging fremfor symptombehandling.

Det er av mindre betydning om denne beskrivelsen er riktig. Poenget er at ethvert digitaliseringsprosjekt må se utover sine egne grenser og sin egen samtid. For en ting er sikkert: Teknologiutviklingen endrer hvordan dagens problemer blir løst i fremtiden; Nye pasientforventninger og mer persontilpassede helsetjenester, blir driverne., etc. Dette tvinger oss til å tenke annerledes. Digitaliseringsprosjekter blir ikke lenger anskaffelser av applikasjoner, men løpende utviklingsprosjekter.

Men da må (minst) to utfordringer løses:

Den «interne» utfordringen

Ved å ta et «utenfra og inn-perspektiv» blir fokuset ikke bare på pasientenes helhetlige behov, men at dette behovet må løses gjennom samarbeid med de IKT-aktørene som står nærmest der datafangsten oppstår. Pasientgenererte data, data fra velferdsteknologiske løsninger, data som fanges opp av sensorer under klinisk behandling, må samspille med historiske pasientdata. Verdien av dataene i forhold til en behandlingssituasjon ligger i tilgangen til sanntids-pasientinformasjon. Utfordringen ligger i å bygge medisinske behandlingsregler inn i disse dataene.

Les også

Rollen som «eier av e-helseløsninger», blir ikke som kravstiller og innkjøper av en «applikasjon», men som regulatorisk myndighet med krav om åpne grensesnitt og API-er. En utfordrer dermed IKT-leverandørenes innovasjonsevne, og inviterer helsepersonell og pasienter inn som produsenter, og ikke konsumenter, av løsningene.  

Den «eksterne» utfordringen

Statens Prosjektmodell (KS-ordningen) har nettopp fått senket terskelverdien for digitaliseringsprosjekter fra 700 til 300 millioner kroner. (Andre store investeringsprosjekter har fått hevet terskelverdien til 1 milliard). Flere digitaliseringsprosjekter kommer derfor nå inn under ordningen. 

Men KS-ordningen er lite tilpasset «oppstrøms»-digitalisering. Dette er prosjekter som løper langt frem i tid, hvor forutsetningene stadig endrer seg, og hvor beregning av de samfunnsøkonomiske gevinster er krevende. Selve formålet med KS-ordningen - «effektiv bruk av statens penger» -, ivaretar i liten grad kravet til effektmål og gevinster på tvers av verdikjeder.

Store, tverrgående digitaliseringsprosjekter skal ha en «sentral styring eller koordinering» ifølge Regjeringens Digitaliseringsstrategi. Akson-prosjektet er tenkt styrt av Direktoratet for e-helse som prosjekteier, både i kraft av den nylig foreslåtte e-helselov og det faktum at Direktoratet er et myndighetsorgan. Et nytt firma -  Akson Journal AS – er tenkt etablert med delt eierskap mellom kommunene og staten, og skal være kunde og innkjøper av systemet, mens Norsk Helsenett skal være kunde og innkjøper av Samhandlingsløsningen. 

Det bryter med den styringsstrukturen som «oppstrøms»-digitalisering har, hvor samstyring er viktigere enn sentralstyring. Det knebler også innovasjonsevnen i prosjektet, og gir prosjekteier kun illusjonen av kontroll.

Er begrepet «smidig» forstått riktig?

Inga Nordberg viser i sitt innlegg til en forskningsrapport fra Sintef om Styring og gjennomføring av store statlige IKT-prosjekter. Det er en god referanse. Den tar opp flere av de problemstillinger jeg har drøftet her. Men spørsmålet om «smidig» versus «fossefall»-gjennomføringsmetodikk, har fått liten oppmerksomhet i den rapporten – med rette. Den snakker i den sammenheng heller om kontraktsstrategier, og det er noe annet.

Les også

Kommentarer (3)

Kommentarer (3)
Til toppen