I takt med digitaliseringen står helsesektoren overfor en voksende utfordring med å håndtere komplekse systemer og integrasjoner – eller rettere sagt: manglende muligheter for det sistnevnte.
![Bilde av Kafka-entusiaster i Norsk helsenett, Simon Glisic Randby og Fredrik Bekkevold.](/jobb/vi-snakker-jobb/den-kafkaeske-e-helsesektoren-kan-kafka-redusere-kompleksiteten/_/image/c59e6864-169a-4ac1-a127-83557aef22c4:cf3d65af8343b37444d2840cd196473f6efe6fc4/width-768/ndc%20bilde%201.png)
Men hvorfor er dette så komplekst? Noe av svaret ligger utenfor IT-sfæren. Helsesektoren er ikke en uniform aktør, selv om den skal oppleves slik av sluttbrukeren: Pasienten og dens pårørende. Det jobber mer enn 300 000 helsepersonell i den norske helsetjenesten, fordelt på 17 000 aktører i privat og offentlig sektor.
IT-verktøyene som skal være en ressurssparende støtte for helsepersonellet leveres av mange ulike aktører, og data er ikke lagret sentralt. To sykehus bruker ikke nødvendigvis den samme løsningen til den samme oppgaven. Og fortsatt mangler vi god støtte for digital utveksling og utlevering av data mellom de som har dataene og de som trenger dataene. Det er heller ingen krav til at IT-verktøyene skal kunne snakke sammen, og de færreste av dem gjør det.
Det er et stort potensial for å øke bærekraften til den norske helsetjenesten. I 2060 vil vi ha behov for 200 000 flere årsverk i helsetjenesten, i følge Perspektivmeldingen 2024 fra regjeringen. Om vi klarer å øke produktiviteten med en halv prosent i året trenger vi ikke et eneste årsverk mer enn vi har i dag,ifølge Menons nylige rapport til det tidligere direktoratet for e-helse. En halv prosent!
Enter Norsk helsenett – og Kafka, forklart av Fredrik Bekkevold:
Kompleksitet og kostnader – den menneskelige faktoren
Kompleksitet er et ord man dytter på ting der mange er involvert, der en person ikke kan “se” hele problemstillingen, fordi man skal gjøre noe som ikke har vært gjort før og/eller at man bruker for mye eller feil teknologi når man løser problemet.
Kompleksitet bli et ord vi bruker som skjuler hva problemet egentlig er. Men om man får de egentlige problemene frem i lyset, så forsvinner ofte “kompleksiteten”. Min personlige erfaring med kompleksitet er at det aldri er så komplekst at man ikke kan dele problemstillingen opp i mindre biter.
Hva med å dele problemet i to. Har man nok folk, så kan halvparten jobbe med en del og resten ta en annen del. Dette er en enkel måte å partere på. Store avgjørelser er ofte vanskelige å reversere. Store avgjørelser øker kompleksiteten. Ikke på selve løsningen, nødvendigvis, men fordi man involverer flere mennesker. Flere mennesker > mer koordinering > mer tid som går med > dyrere løsning.
"Perfekt" utvikling av løsninger i en kompleks verden blir for meg:
- Få involverte som tar de nødvendige avgjørelsene for å levere det som trengs
- At man jobber på en kjent måte, og
- At man ikke kludrer til løsningen med unødig teknologi
Vi streber etter små steg og en kontinuerlig tilbakemelding på at vi løser det problemet som trengs å løses.
Fra prinsipper til teknologi
Oppdeling av kompleksitet er en historie i seg selv, og fortjener en helt egen artikkel. Men hvordan vi skaper løsninger der vi bruker gjentagende mønstre, og kjente løsninger som ikke oser av alt for mye teknologi fortsetter vi med her. Alle de tre punktene henger sammen, men det teknologiske spiller mer inn når vi snakker mønstre og teknologi.
Så kjente mønstre. For oss gjelder 5 mønstre. De skal sammen skape «Gracefull Degregation», som er et av mønstrene i seg selv. De andre er CQRS, Low coupling, high cohetion, pub/sub.
Dette er abstrakt, og vanskelig å forstå, og vi må gjøre dette konkret. Det gjør vi med teknologi. Vi har implementert teknologi som selv bruker disse mønstrene. Vi trenger ikke masse teknologi for å hjelpe oss å implementere disse mønstrene, vi trenger en. Vi ønsker å holde tech-stacken lav. Teknologien vi har valgt som hjelper oss å implementere våre mønstre i våre løsninger, er Kafka.
Kafka er et system som er utviklet for å være gracefully degredable. Måten man har laget Kafka, gjør at de flytter og tilgjengeliggjør data slik at når man bruker Kafka, også implementere CQRS og pub/sub. Low coupling får vi når alle tjenester benytter Kafka for å lagre og dele data. Altså, vi kobler ikke tjenester direkte sammen. Vi deler informasjonen via Kafka som i en datahub eller et NAV. Slik reduserer vi koblinger. Da gjenstår bare high Cohetion. Kafka passer oss godt, men det løser ikke alt, så denne må vi nok fikse selv. Men etter min erfaring, handler den mye mer om soft-skills enn bruk av teknologi.
Balansen mellom tilgjengelighet og sikkerhet – ganske enkelt forenkling
Kafka sikrer dataene våre, fordi vi har satt det opp slik at dataene eksisterer flere steder “samtidig” når vi trenger det. Dataene blir lagret slik at det skal mye til for at vi taper dataene, vi har «near zero data loss».
Kafka har tilgangsstyring. Denne bruker vi per tjeneste. Det er hensikten. Ingen pasienter, helsepersonell eller andre skal bruke eller koble seg på Kafka direkte. Bruken skal gå via tjenester som er laget for det de brukes til. Det er dette som gjør at vi ikke trenger å eksponere Kafka på verken Helsenettet eller på internett. Tjenestene skaper tilgjengelighet. Dette gjør også at Kafka er mindre eksponert for trusler. Viktig for å hindre at sensitive data (dine og mine helsedata) kommer på avveie.
Tjenestene er nøkkelen til å ta unna kompleksiteten i sektoren. Det er teknikken vi bruker for å gjøre mange små kutt, og jobbe på en kjent måte Nå har vi teknologien som gjør det mulig for oss å skape mange små tjenester, raskt. Når vi ser behovet, kan vi raskt ta tak i dette og gjøre det til en løsning. Og siden det krever mindre tid, skaper vi flyt og mister ikke oppmerksomheten til de som trenger løsninger.
De siste årene har vi flere eksempler der vi har brukt teknologien vi nå har fått, til å lage løsninger i løpet av uker. Et av disse er Pasientens prøve svar. Den var piloten for hvordan vi skal lage små, enkle løsninger, på den store og kompleks utfordring: at helsesektoren må bli mer effektiv.