Vi trenger ingen helse-plattform

Som programmerer er du alltid nødt til å sette deg inn i nye fagområder. Det holder ikke å være ekspert på koding. Forstår du ikke domenet til de som skal bruke programmene du utvikler, blir produktet heller dårlig. I mine 19 år som programmerer har jeg måttet sette meg inn i alt fra risikoanalyse, seismikk, strøm-markeder, offentlige støtteordninger, kryptering av tv-signaler og panteautomater. Alle domener er forskjellige, alle har sine utfordringer. Koden vil bære preg av det domenet det er skrevet i og de spesifikke utfordringene domenet bringer med seg.

Men programmering er et fagområde i seg selv også. Jo flere IT-prosjekter man er med på, jo flere likhetstrekk begynner man å se. Det finnes gode prinsipper for software-utvikling som gjelder de fleste steder:

– Automatisert testing er lurt (og for å få gode tester, hjelper det med en funksjonell stil på koden).

– Kode bør være løst koblet, så man kan gjøre endringer isolert og trygt, uten at det involverer hele kodebasen. Jo flere ting som er koblet sammen, jo tettere de er koblet sammen, jo vanskeligere blir det å gjøre endringer trygt.

– Det å finne gode avgrensninger/inndelinger/abstraksjoner er det vanskeligste innen programmering. For ting hører jo sammen. Jeg har både epostadresser, telefonnumre, postadresse, navn, barn, biler… Skal alt dette lagres sammen? Hvilke ting hører sammen? Idag ligger epost og telefonnummer i kontaktregistret, mens adressen ligger i folkeregisteret. Er det riktig inndeling? Det finnes ingen fasit og et hvert valg har både fordeler og ulemper. Men at det er lurt å dele ting inn i mindre deler, det vet vi.

– Også når det gjelder utviklingsprosess, er det lurt å dele ting opp i mindre biter. All erfaring og forskning tyder på at jo større et IT-prosjekt er, jo større sjanse har det for å feile. Istedenfor å prøve å takle et helt økosystem med integrerte IT-systemer samtidig i parallel, lønner det seg å gjøre en ting av gangen. Det er utfordrende å finne måter å dele ting opp på, men ikke på langt nær så utfordrende som å prøve å gjøre alt samtidig i parallel.

Dette er noe de fleste er enige i.

Med noen hederlige unntak.

Som for eksempel innen helse.

Utfordringene innen helse-IT blir idag forsøkt løst med store altomspennende plattformer som gjør alt samtidig. “De store prosjekters tid er ikke over” konstaterte Christine Bergland, direktøren for e-helse-direktoratet på konferansen EHIN i Oslo i November (2019). Hun refererte kanskje til Akson-prosjektet til estimerte 11 milliarder
1 1 M I L L I A R D E R kroner
over 10 år. Mer enn en milliard i året. Hvordan de kom frem til det tallet er dessverre unndratt offentligheten.

Helse Midt-Norge vedtok nylig å investere i den Amerikanske plattformen Epic. Denne skal kunne levere omtrent ALT. Tilpassing av plattformen, og lisenser regner de med at vil koste 2.7 milliarder kroner (over 10 år). En sum som for eksempel kunne lønne 135 mennesker med 2 millioner i året i hele perioden. For en plattform som allerede er laget. Hva er det pengene skal gå til? Hvordan klarer de å bruke opp pengene? Og hva skjer når en Trønder trenger behandling i Oslo, der de ikke bruker denne plattformen? Hva skjer når Epic kommer med nye versjoner? Klarer vi å holde følge med oppgraderinger gitt alle spesialtilpasningene vi legger på (også kjent som SAP-syken)? Jeg har mange spørsmål.

De har allerede implementert det i Danmark. Sundhetsplatformen er bygget på Epic. Det gikk til helvete og alle er misfornøyde. Men, men, vi kjører på likevel. Vi er jo som kjent mye smartere enn dansker, så vi får nok til dette mye bedre skal du se.

Og uansett, hva annet skulle vi bruke 2.7 milliarder kroner på liksom? Har vi noe annet valg?

Det finnes norske aktører innen helse-plattformer også. Norske DIPS med sitt nye system DIPS Arena skal også være en universal-løsning for IT i helsesektoren. Den baserer seg på plattformen OpenEHR, som i det minste er en åpen standard. Så her har jeg større grunnlag for å uttrykke meg. OpenEHR har et slags modellerings-språk, som lar en definere alt mulig av helse-data. De har en rekke “arketyper” som består av grupperinger av felt av forskjellige typer. Det finnes en arketype for blodtrykk, og arketyper for forskjellige blodprøve-resultater, osv. OpenEHR har byggeklosser som gjør at en kan representere, lagre og hente frem hva det måtte være av helsedata, slik at absolutt ALLE kan bruke det til ALT.

Akkurat som et programmeringsspråk faktisk. I programmeringsspråket java, kaller vi arketypene “klasser”. Akkurat som i OpenEHR kan disse bygges opp av “attributter” som er av en gitt “type”. Dette lar en definere hva det måtte være av datastrukturer. Fra blodtrykk til fødsler, romskip til fuglebestander. OpenEHR – er altså et programmeringsspråk på toppen av et programmeringsspråk. Litt som å bruke en sag til å sage ut en ny sag i et mykere materiale, som du så igjen må bruke til å sage det du egentlig skulle ha kuttet opp. Ikke spesielt effektivt. (Bare bruk den første saga! Den er kraftigere og bedre.)

I en vanlig software-applikasjon, ville man hatt en struktur som heter “Blodtrykk” som har feltene overtrykk, undertrykk, dato, personnummer, etc. I databasen ville man hatt en tabell med tilsvarende navn og felter. For å hente ut data spør man så:

SELECT overtrykk, undertrykk FROM blodtrykk WHERE personnummer = ? AND dato BETWEEN ? and ?

Med openEHR, har man abstrahert seg vekk fra disse konkretene. Så istedenfor å ha en klasse og en database-tabell som heter “blodtrykk” som inneholder blodtrykkdata, så vil man f.eks hatt en tabell som heter “EHR” som kan ha kolonner som refererer til “Compositions” – definert i en annen tabell, som igjen referer til “Observations” hvor disse kan referere til konseptet “blodtrykk”. Så har man andre tabeller med “attributter” som har kolonner som referer til en type. Så har man til slutt tabeller for “verdi”, som refererer til en attributt.

Her er et eksempel av en OpenEHR spørring etter blodtrykk:

let $systolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude"
let $diastolic_bp="data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude"

SELECT
  obs/$systolic_bp, obs/$diastolic_bp
FROM
  EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
      CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
WHERE
  obs/$systolic_bp>= 140 OR obs/$diastolic_bp>=90

Så her kan vi altså sømløst jobbe med hva det måtte være av helsedata. Og det blir like vanskelig å jobbe med alt sammen. Hva konsekvensen er om man f.eks skriver “at0002” istedenfor “at0003” det vet jeg ikke, men det er åpenbart viktig at man holder tunga rett i munnen når man forvalter slik kode. De beste utviklerne vil holde seg langt unna – da denne typen koding rundt generiske modeller er notorisk vanskelig og lite tilfredstillende å jobbe med.

Ytelse er det også tilnærmet umulig å jobbe med. Det kan være vanskelig nok å optimalisere indekser og lagrings-løsninger når man vet akkurat hva slags data man lagrer hvor og hvordan de blir aksessert. Men når alt, uansett størrelse og tilgangsmønster lagres i de samme tabellene, så kan man ikke optimalisere for spesifikke bruksmønster på samme måte. Ikke uventet sliter DIPS stadig med ytelsesproblemer.

Kanskje viktigst av alt er likevel dette – hva skjer om plattformen eller databasen går ned eller får problemer? Da går alt ned. Hele helse-systemet blir utilgjengelig.

Likeså med oppgraderinger av systemene. Hele porteføljen blir nødvendigvis affektert samtidig. “Kan vi oppgradere til siste versjon?” Ikke uten å teste at absolutt ALT takler oppgraderingen. Noe som fører til at oppgraderinger skjer mer og mer sjelden. Med alle sikkerhetsrisikoer og manglende funksjonalitet det fører med seg.

Man kan få til de utroligste ting i slike plattformer. Det er ikke det. Mye bra har blitt laget. Mye bra kommer til å bli laget i fremtiden. Folk finner ut av ting. Bare se her:

Her har en fyr klart å lage et pokemon nintendo-spill inne i Minecraft, ene og alene med Minecraft sine innebygde CommandBlocks! Helt villt! Kjempeimponerende! Men på ingen måte den mest effektive måten å skrive et nintendo-spill på. Akkurat som at generiske alt-i-ett-plattformer ikke er de mest effektive måtene å skrive kode på.

Jeg har stor forståelse for at det høres forlokkende ut med plattformer som løser alt. Men det er ikke en god idé. Kommunisme feilet, ikke fordi kommunister var dumme og slemme, men fordi det er veldig vanskelig å ha et sentralstyrt system som passer for alt. Uansett hvor gode intensjoner man har. Kapitalisme kan være “rotete” i forhold, men med gode regler på plass, så er det mye mer effektivt. Dette gjelder for software også.

“Men helse IT er ikke som andre former for IT. Det er mye mer komplekst.” Blir det sagt. Vet du hva, jeg har hørt denne argumentasjonen før. Hvor var det igjen?
Jo i ALLE BRANSJER JEG HAR JOBBET I.
I absolutt alle bransjer, sitter fagfolk og fordyper seg i problemene i akkurat deres domene. Og det er alltid komplekst der nede i dypet. Men all erfaring (ikke bare min) tilsier at jo mer komplekst noe er, desto viktigere er det å nettopp dele ting opp. Jo mer komplekst noe er, jo viktigere er det å unngå å samle alt i ett system. Ønsker vi å ha gode helse-systemer, må vi åpne for flere, mindre, dedikerte og spesialiserte løsninger.

“Men det er jo det som er problemet idag.” Kan du si. At vi har masse små systemer som ikke snakker sammen. Ja, det at de ikke snakker sammen må vi gjøre noe med. Og det at samme type data lagres over alt i forskjellige formater. Det bør vi også gjøre noe med. Men det fordrer på ingen måte at vi må tvinge alle over på samme plattform.

Da jeg jobbet i Husbanken utviklet vi et nytt system for å kunne søke om bostøtte på nett. Det vant flere priser og var en stor suksess nettopp fordi vi klarte å integrere så mange forskjellige offentlige registre i løsningen. Man trengte bare logge seg inn med ID-porten, så hentet løsningen opp epost og telefonnummer fra kontaktregisteret, adresse, navn, barn og andre husstandsmedlemmer ble hentet fra folkeregisteret. Boliginformasjon ble hentet fra Matrikkelen, inntektsinformasjon ble hentet fra skattemyndighetene, trygder ble hentet fra Nav og eksisterende bostøtteforhold og startlån ble hentet fra Husbankens egne systemer. Da kunne man med veldig få tastetrykk få en ferdig utfylt søknad og vite hvor mye man kunne forvente å få utbetalt i bostøtte. Kjempebra! Ingen av disse systemene kjørte på samme plattform. Det trengte de ikke heller. Jeg ser ingen grunn til at man ikke kan få til tilsvarende løsninger innen helse.

Vi trenger ingen altomspennende helse-plattform. Vi trenger bare å fokusere på å lagre og tilgjengeliggjøre helsedata på gode og trygge måter. Akkurat som vi gjør med all annen data i Norge. Vi er alle enige i at folkeregisteret har navn og adresse-info, at matrikkelen har bolig-info og at kartverket har kart-data.
Hvordan man kom frem til denne inndelingen vet jeg ikke, men det er denne tankegangen vi må få inn i helse. Jeg vil at mine helsedata skal være lagret trygt og være tilgjengelig for alle helse-institusjoner i Norge. Blodtrykksdata trenger ikke være lagret på samme plass som resultatene fra MR scan av kneet mitt. Jeg bryr meg ikke om hvilke applikasjoner som leser dem opp eller skriver dem ned heller. Jeg bryr meg om dataene, og om hvem som har tilgang. Om mine blodtrykksdata leses opp i software laget av store kommersielle aktører, eller en app laget av sønnen til legen min, det driter jeg i, så lenge dataene er sikret. Vi må skille data fra verktøy. Verktøy kan hvem som helst lage, og det kan være mange av dem, samma det.

Vi må dele helsedata opp i mindre deler og fordele ansvar. Arketypene som har blitt laget i OpenEHR-arbeidet kan kanskje være et godt utgangspunkt for å fordele ting. “Dere der borte kan lagre blodtrykk og EKG, så kan dere her nede lagre MR-scan-resultater”. Altså hvordan dette deles opp, det kan ikke jeg uttrykke meg om. Jeg kan lite om helse. Men jeg vet at uansett hvordan man deler det opp kommer noen til å klage. Akkurat som at mange sikkert er irriterte over at epost-adresser og telefonnummer ikke er i folkeregisteret, men i kontaktregisteret. Men litt sånn kan vi leve med. Så lenge all data er tilgjengelig over gode APIer, så får man tak i det man trenger. Da kan hvem som helst lage gode tilpassede løsninger for alt mulig innen helse-sektoren uten at det hele må inn i en felles plattform. Om det er 500 forskjellige apper for å se på blodprøveresultater rundt om i Norge gjør ingen verdens ting. La legene velge det som er mest effektivt for dem. Vi må bare få kontroll på hvor dataene skal hentes fra og lagres til. Og dette kan vi gjøre steg for steg.

Hvordan spiser man en elefant?
En bit av gangen.

Advertisement