We don’t need a healthcare platform

This text was triggered by discussions on Twitter in the wake of a Norwegian blog post I published about health platforms.
I stated that we need neither Epic, nor OpenEHR, nor any other platform to solve our healthcare needs in the Norwegian public sector. Epic people have not responded, but the OpenEHR crowd have been actively contesting my statements ever since. And many of them don’t read Norwegian, so I’m writing this to them and any other English speakers out there who might be interested. I will try to explain what I believe would be a better approach to solve our needs within the Norwegian public healthcare system.

The Norwegian health department is planning several gigantic software platform projects to solve our health IT problems. And while I know very little about the healthcare domain, I do know a bit about software. I know for instance that the larger the IT project, the larger the chances are that it will fail. This is not an opinion, this has been demonstrated repeatedly. To increase chances of success, one should break projects into smaller bits, each defined by specific user needs. Then one solves one problem at a time.

I have been told that this cannot be done with healthcare, because it is so interconnected and complex. I’d say it’s the other way around. It’s precisely because it is so complex, that we need to break it into smaller pieces. That’s how one solves complex problems.

Health IT professionals keep telling me that my knowledge of software from other domains is simply not transferrable, as health IT is not like other forms of IT. Well, let’s just pretend it is comparable to other forms of IT for a bit. Let’s pretend we could use the best tools and lessons learned from the rest of the software world within healthcare. How could that work?

The fundamental problem with healthcare seems to be, that we want all our data to be accessible to us in a format that matches whatever “health context” we happen to be in at any point in time. I want my blood test results to be available to me personally, and any doctor, nurse or specialist who needs it. Yet what the clinicians need to see from my test results and what I personally get to see will most likely differ a lot. We have different contexts, yet the view will need to be based on much of the same data. How does one store common data in a way that enables its use in multiple specific contexts like this? The fact that so many applications will need access to the same data points is possibly the largest driver towards this idea that we need A PLATFORM where all this data is hosted together. In OpenEHR there is a separation between a semantic modelling layer, and a content-agnostic persistence layer. So all datapoints can be stored in the same database/s – in the same tables/collections within those databases even. The user can then query these databases and get any kind of data structures out, based on the OpenEHR archetype definitions defined in the layer on top. So, they provide one platform with all health data stored together in one place – yet the user can access data in the format that they need given their context. I can see the appeal of this. This solves the problem.

However, there are many reasons to not want a common platform. I have mentioned one already – size itself is problematic. A platform encompassing “healthcare” will be enormous. Healthcare contains everything from nurses in the dementia ward, to cancer patients, to women giving birth, orthopaedic surgeons, and family of children with special needs… the list goes on endlessly. If we succeed building a platform encompassing all of this, and the plattform needs an update – can we go ahead with the update? We’d need to re-test the entire portfolio before daring to do any changes. What happens if there is a problem with the platform (maybe after an upgrade.) Then everything goes down. The more things are connected, the more risky it is to make changes. And in an ever changing world, both within healthcare and IT, we need to be able to make changes safely. There can be no improvement without change. Large platforms quickly become outdated and hated.

In the OpenEHR case – the fact that the persistence has no semantic structure will necessarily introduce added complexity in how to optimise for context specific queries. Looking through the database for debugging purposes will be very challenging, as everything is stored in generic constructs like “data” and “event” etc. Writing queries for data is so complex, that one recommends not doing it by hand – but rather creating the queries with a dedicated query creator UI. Here is an example of a query for blood pressure for instance:

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

This is needless to say a very big turn-off for any experienced programmer.
The good news though, is that I don’t think we need a platform at all. We don’t need to store everything together. We don’t need services to provide our data in all sorts of context-dependent formatting. We can both split health up into smaller bits, and simultaneously have access to every data point in any kind of contextual structure we want. We can have it all. Without the plattform.

Let me explain my thoughts.

Health data has the advantage of naturally lending itself to being represented as immutable data. A blood test will be taken at a particular point in time. Its details will never change after that. Same with the test results. They do not change. One might take a new blood test of the same type, but this is another event entirely with its own attributes attached. Immutable data can be shared easily and safely between applications.

Let’s say we start with blood tests. What if we create a public registry for blood test results. Whenever someone takes a blood test, the results need to be sent to this repository. From there, any application with access, can query for the results, or they can subscribe to test results of a given type. Some might subscribe to data for a given patient, others for tests of a certain type. Any app that is interested in blood test results can receive a continuous stream of relevant events. Upon receipt of an event, they can then apply any context specific rules to it, and store it in whatever format is relevant for the given application. Every app can have its own context specific data store.

Repeat for all other types of health data.

The beauty of an approach like this, is that it enables endless functionality, and can solve enormously complex problems, without anyone needing to deal with the “total complexity”.
The blood test registry will still have plenty of complexity in it. There are many types of blood tests, many attributes that need to be handled properly, but it is still a relatively well defined concrete solution. It has only one responsibility, namely to be the “owner” of blood test results and provide that data safely to interested parties.

Each application in turn, only needs concern itself with its own context. It can subscribe to data from any registry it needs access to, and then store it in exactly the format it needs to be maximally effective for whatever usecase it is there to support. The data model in use for nurses in the dementia ward does not need to be linked in any way to the data model in use for brain-surgeons. The data stores for each application will only contain the data that application needs. Which in itself contributes to increased performance as the stores themselves are much smaller. In addition they will be much easier to work with, debug and performance tune, since it is completely dedicated for a specific purpose.

Someone asked me how I would solve an application for
“Cancer histopathology reporting, where every single cancer needs its own information model? and where imaging needs a different information model for each cancer and for each kind of image (CT, MRI, X-ray) +where genomics is going to explode that further”

Well I have no idea what kind of data is involved here. I know very little about cancer treatment. But from the description given, I would say one would create information models for each cancer, and for each type of image and so on. The application would get whatever cancer-data is needed from the appropriate registries, and then transform the data into the appropriate structures for this context and visualise the data in a useful way to the clinician.
We don’t need to optimize for storage space anymore, storage is plentiful and cheap, so the fact that the same information is stored in many places in different formats is not a problem. As long as we, in our applications can safely know that “we have all the necessary data available to us at this point in time”, we’re fine. Having common registries for the various types of data solves this. But these registries don’t need to be connected to each-other. They can be developed and maintained separately.

Healthcare is an enormous field, with enormous complexity. But this does not mean we need enormous and complex solutions. Quite the contrary. We can create complex solutions, without ever having to deal with the total complexity.

The most important thing to optimise for when building software, is the user experience. The reason we’re making the software is to help people do their job, or help them achieve some goal. Software is never an end in itself. In healthcare, there are no jobs that involve dealing with the entirety of “healthcare”. So we don’t need to create systems or platforms that do either. Nobody needs them.

Another problem in healthcare, is that one has gotten used to the idea that software development takes for ever. If you need an update to your application, you’ll have to wait for years, maybe decades to see it implemented. Platforms like OpenEHR deal with this by letting the users configure the platform continually. As the semantic information is decoupled from the underlying code and storage, users can reconfigure the platform without needing to get developers involved. While I can see the appeal of this too, I think it’s better to solve the underlying problem. Software should not take years to update. With DevOps now becoming more and more mainstream, I see no reason we can’t use this approach for health software as well. We need dedicated cross functional teams of developers, UXers, designers and clinicians working together on solutions for specific user groups. They need to write well tested (automatically tested) code that can be pushed to production continuously with changes and updates based on real feedback from the users on what they need to get their jobs done. This is possible. It is becoming more and more mainstream, and we are now getting more and more hard data that this approach not only gives better user experiences, but it also reduces bugs, and increases productivity.

The Norwegian public sector is planning on spending > 11 billion NOK on new health platform software in the next decade. We can save billions AND increase our chances of success dramatically by changing our focus – away from platforms, and on to concrete user needs and just making our health data accessible in safe ways. We can do this one step at a time. We don’t need a platform.

Posted in Uncategorized | 21 Comments

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.

Posted in iT | 11 Comments

Den offentlige digitale støvsugeren

Er det problematisk at Nav bygger opp en intern IT-avdeling? Ja det er det, mener Kjetil Thorvik Brun fra Abelia:
https://www.abelia.no/bransjer/teknologi-og-digitalisering/digitalisering-av-offentlig-sektor/nyheter/den-offentlige-digitale-stovsugeren/

“Hvis det offentlige ønsker å gjøre hele jobben internt, får vi minst tre negative effekter” skriver han. “For det første legger det beslag på en kompetanse som det er knapphet på, og som både privat sektor og offentlige etater har stort behov for.”

Altså.

Når Nav har behov for utvikling av software, så vil det måtte være software-utviklere i Nav-kontorer som skriver denne programvaren. Om de jobber i Accenture eller i Nav, så vil de ikke beslaglegges noe mer eller mindre. De må være der. Akkurat som at når Sparebank 1 eller en hvilken som helst annen privat virksomhet trenger utvikling av sin software så trenger de software-utviklere i sine kontorer som skriver deres programvare. Det sier seg selv at når produktet man leverer er digitalt, så bør man ha folk i organisasjonen som faktisk lager det produktet man leverer. Hvis man ikke selv kan lage sitt eget produkt, så er det noe feil. Hvis man må ut på anbud og be og trygle og forhandle om penger med en ekstern part for hver foreslåtte nye funksjonalitet, så blir man mye mindre effektiv. Hvorfor skal staten drives mindre effektivt enn det private? Selvsagt bør man åpne for å leie inn eksterne eksperter i perioder for å bistå med enten spisskompetanse eller ekstra arbeidskraft i perioder med mye arbeid. Det gjør private bedrifter også. Men den delen av IT-næringa som har levd godt på å støvsuge statskassa for penger for å gjøre det som burde være statlig linjearbeid, den fortjener å dø.

Videre argumenteres det “For det andre krymper man næringslivets mulighet til å bidra i omstillingen av Norge, og dermed til å bygge verdier og arbeidsplasser som gir inntekter i statsbudsjettet gjennom skatt og eksportinntekter.”
Denne skjønner jeg ikke helt. Hva er mest økonomisk lønnsomt for Nav:
1) Betale X millioner i lønn til ansatte, som så skatter av denne lønnen og dermed gir skatteinntekter
2) Betale dobbelt så mye i fakturaer til konsulenthus der noe av det kommer tilbake i form av skatt, men der betydelige andeler rett og slett forsvinner ut av landet og går til utenlandske eiere.
Jeg skjønner ikke hvordan punkt 2 skal føre til hverken flere arbeidsplasser eller mer skatteinntekter.

Siste punkt: “For det tredje risikerer man teknologisk innlåsing. Interne IT-miljøer i offentlige etater har ikke samme krav til fornying som en IT-bedrift i privat sektor som tilbyr tjenester på et åpent marked.”
Et åpent marked, ja. Hvilket marked da? Det finnes ikke noe marked for implementasjoner av det norske trygderegelverket. Det kommer aldri til å finnes noe åpent marked for implementasjoner av det norske trygderegelverket. Dette er et produkt som må eies og styres av Nav og norske folkevalgte politikere. Videre er det faktisk ikke sånn at implementasjonene av det norske trygderegelverket automatisk blir modernisert ved at det er et eksternt konsulenthus som har laget løsningen. De sitter faktisk ikke å videreutvikler og moderniserer trygde-kode for morro skyld i Accenture. De jobber kun dersom de har en kontrakt som gir dem gode penger for å gjøre det. Å sette utvikling ut på anbud er faktisk en oppskrift på å IKKE få modernisert sin applikasjonsinfrastruktur løpende. Det er en oppskrift på å kjøre gammel, utdatert kode.

Nav har aldri vært mer innovativ enn når de nå den siste tiden har ansatt egne folk. Skatteetaten har hatt egne utviklere i lang tid og har høy grad av innovasjon og moderne IT-løsninger.

Videre har ikke Nav og andre offentlige etater samme incentiver til å øke bemanningen i prosjekter. Konsulenthus tjener mer penger jo flere mennesker de får leid ut. Alle ansatte blir lært opp i å se etter muligheter til å få inn flere konsulenter der de er. Derfor ender altfor mange offentlig prosjekt opp med altfor høy bemanning – noe som nødvendigvis fører til økt byråkrati og dårligere leveringsevne.

Jeg er enig med artikkelforfatteren, i at Nav og andre i offentlig sektor ikke har samme muligheter til å gå konkurs, og dermed ikke kjenner like stor trang til å innovere og følge med i tiden som private aktører. Dette er et problem vi aktivt må jobbe med. Derfor vi trenger politikere og toppledere som forstår seg på IT, slik at de passer på at man til en hver tid har løsninger som yter optimalt gitt dagens teknologiske muligheter.

Posted in Uncategorized | 2 Comments

Felles kurs mot 2020 og 2025

Brønnøysund har skrevet om sitt planlagte arbeid fremover mot 2020 og 2025. Felles kurs mot 2020 og 2025.
Det var ikke helt det jeg hadde lyst til å lese, men heller enn å komme med innsigelser og krangling som vanlig, tenkte jeg å skrive min egen versjon. Det jeg kunne tenkt meg å lese, eller et utkast til det jeg selv hadde skrevet hvis jeg var ansvarlig. Det blir jo mindre morsom lesning; ikke noe sarkasme, ingen rare sammenligninger, men samma det – jeg hadde lyst til å prøve å formulere hva det egentlig er jeg har lyst til å høre/forventer å høre fra det offentlige. Hva synes dere? Er dette en forbedring av budskapet til Brønnøysund?

Felles kurs mot 2020 og 2025

I Brønnøysund forvaltes mange forskjellige offentlige registere. Vi har gått fra papir-systemer der skjemaer og vedtak lagres i papir-arkiv-skap, til digitale løsninger, der skjemaer og vedtak lagres i elektroniske arkiv-skap. Men lite har egentlig endret seg for brukeren. Vi ønsker nå å fullføre den digitale transformasjonen av våre registre. Vi ønsker å legge til rette for gode, personlige, digitale dialoger der bruker og saksbehandler, når som helst og hvor som helst, får innsyn i dokumenter og muligheter til å tilføye/endre informasjon, fra mobilen, nettbrett eller datamaskin. Der både bruker og saksbehandler fortløpende holdes oppdatert med relevant informasjon.

Hva dette betyr i praksis vil variere fra register til register og fra brukerbehov til brukerbehov. Noen trenger informasjon om seg selv og sin bedrift. Andre trenger informasjon om store mengder bedrifter/personer. Noe informasjon er privat, annen informasjon skal være åpent tilgjengelig. Osv.
Ikke bare er det store forskjeller fra register til register og behov til behov, men landskapet innen IKT endrer seg såpass fort, at så snart en har fått på plass en løsning som passer ett brukerbehov, kan ny teknologi være tilgjengelig. Ny teknologi som det vil være hensiktsmessig å benytte for å løse andre brukerbehov. Eller for å løse det samme behovet på en bedre måte.

Vi ønsker derfor ikke å låse oss til én arkitektur og én løsning som skal brukes på tvers av alle registre. Gjør vi dette, blir løsningen mest sannsynlig suboptimal for en stor andel av brukerbehovene. I tillegg ville det bli vanskeligere og mer risikabelt å oppgradere, modernisere og gjøre endringer; Endringer i en enkel frittstående tjeneste, enten en endring i funksjonalitet eller teknologisk, har mye lavere risiko enn en endring som treffer hele porteføljen. Vi ønsker oss en portefølje det er enkelt å jobbe med og endre over tid. Vi vil lage små frittstående tjenester som kommuniserer over veldefinerte APIer ved behov. Istedenfor å utvikle egne felles plattformer, vil vi se til de mange etablerte sky-leverandører som idag leverer infrastruktur som kan brukes til å produksjonssette enkle frittstående tjenester.

Behovene vi skal innfri er ikke behovene til forvaltningen, men behovene til befolkningen. Derfor vil vi i arbeidet fremover organisere oss og arbeidet vårt først og fremst etter brukerbehov. Behovene til det norske folk. Vi vil ha team som jobber med selvstendige næringsdrivende, team som jobber med frivillig organisasjonsarbeid, osv. Tverrfaglige team, som jobber aktivt for at nettopp deres brukergruppe skal få optimale digitale brukeropplevelser. Dette vil innebære samarbeid med andre offentlige og private aktører, samt brukerne selv.

Hvis vi lykkes i å lage gode, stabile og brukervennlige løsninger, ønsker vi at andre skal få lære av våre erfaringer. Derfor vil all kildekode være åpent tilgjengelig, og vi tar imot forslag til forbedringer og utvidelser. Der det er hensiktsmessig vil vi lage gjenbrukbare biblioteker og tjenester som andre kan benytte seg av ved behov. Men vi jobber etter “bruk, før gjenbruk” prinsippet. Vi lager løsninger først og fremst for å løse et konkret og reelt behov. Først når vi ser at det fungerer i praksis, vurderer vi om det kan eller bør gjenbrukes.

Vi har en stor jobb å gjøre, men gevinstene er enorme og vi gleder oss til å komme igang!”

Posted in iT | 1 Comment

For mye lekser og skolearbeid, sier du? Langt ifra.

“La barn være barn” er det mange som sier om dagen. Vi blir advart mot økende læringstrykk i barnehage og skole. Det er for mye skole for tidlig. For mye lekser og for mye forventninger, barna bør få lov til å leke mer sier man. “For mye skole”? Hva er det vi klager over – for mye læring? For høye forventninger – forventninger om hva da? At barna er lærelystne og nysgjerrige? Er ikke alle barn det av natur?
“Hvorfor det?” “Hvorfor det?” “Hvorfor det?” “Hva er det?”
Det er jo nettopp disse tingene skolen svarer på. Eller rettere sagt skal svare på. For det er jo det som er problemet.
Skolen svarer ikke på spørsmålene barna lurer på. Skolen lærer deg “hvordan lese sammensatte ord”, “hvordan regne pluss og minus”, “når skal jeg bruke dobbeltkonsonant”, “og eller å?” Barn er utrolig nysgjerrige av natur, men de lurer ikke på “hvordan brukes dobbeltkonsonant?”. De lurer på ting som “Hvordan staves ´sticky piston´? Jeg prøver å finne en Minecraft video på youtube”. De er kjempegira på å lære alt skolen har å tilby. De får ikke nok. Men på skolen får de ikke svar på interessante ting. Der lærer de om “ord med dobbeltkonsonant” eller “sammensatte ord”. Illustrert av korte, kjedelige, usammenhengende anekdoter om oppdiktede uinteressante barn som gjør meningsløse ting:

Trym og Trine bor på Berg.
Berg er en bondegård.
På Berg er det mye liv.
Hønene kakler i hønsegården.
Trym gir hønene mat og samler egg.
– Tuppa, tuppa, tuppa, sier Trym.
Grisene i bingen ruller seg i søla.
De grynter glade når Trine gir dem mat.
– Gryntegrisen min, sier Trine.

Ferdig.
WOW, så spennende da gitt! Altså… det er ikke noe poeng, ikke noe humor, ikke noe spenning, ikke noe læring, ikke NOE AV INTERESSE FOR NOEN SOM HELST. Hverken voksne eller barn. “Lekse til tirsdag: Les teksten 3 ganger med innlevelse” Kødder du eller? 3 GANGER? Med innlevelse? Innlevelse? Selv jeg klarer ikke lese noe så drepende kjedelig med innlevelse. Hvordan kan jeg forvente det av barna mine? Jeg ser igjennom norsk-læreboka til min 2.klassing og spør meg selv “Hvis forfatterne hadde prøvd så godt de kunne å gjøre dette uinteressant – hadde jeg merket forskjellen?” Jeg vet sannelig ikke.
Hadde tekstene blitt skrevet av læreren fra uke til uke, så hadde jeg kanskje vært mer forståelsesfull. “Kanskje hun er stresset, har altfor mye å gjøre, har ikke tid til å finne på noe gøy til barna” Men dette er det offisielle, godkjente skolemateriellet tusenvis av barneskolebarn må gjennom. Klarer vi ikke bedre enn dette? Hvem er det som godkjenner det her? Med så mye god barnelitteratur å ta fatt på, så mye kule lærerike prosjekter og oppgaver å finne i bøker og på nett.. Hvordan kan utdanningsdirektoratet (eller hvem det nå enn er som har ansvar) få dagens pensum i fanget og si “Ja, dette ser bra ut. Det blir ikke bedre enn dette. Kjør på. Trykk det opp og send det ut.” Hvordan i alle dager har vi klart å ende opp med et pensum som er så drepende kjedelig? Så kjedelig at flere og flere folk aktivt fraråder for mye “skolearbeid”.
Det snakkes om at vi trenger bedre lærere. Det holder ikke. Selv ikke den beste pedagog i landet klarer å gjøre dette pensumet interessant.

Ååå, disse jordbærene smaker godt,
sier Jakob.
–De smaker sommer.
–Ja, de smaker sommer, sier mamma.
–Kan du kjøpe flere i morgen?
–Ja, men du må minne meg på det.
Jeg har så mye jeg skal huske.
–Det skal jeg gjøre, sier Jakob.

“Måååå jeg lese en gang til?” spør sønnen min.
“Ja, sier jeg. To ganger til. Med innlevelse.
“Ååååååhhhh….” stønner han.

Ja, vet du hva, jeg er helt enig. Lekser er SINNSYKT kjedelig. For både forelder og barn. Jeg klarer ikke det her altså. Hvem er ansvarlig for å godkjenne pensum her i landet? Eier de ikke skam?

Posted in Samfunn | 9 Comments

Rette streker sparer millioner

Rett strek til 125 millioner

Rett strek til 125 millioner

Noen flere enn meg som så denne artikkelen? “Lars Magnar rettet ut kommunens svingete tunnelforslag i siste øyeblikk. Sparte 125 millioner kroner” Da jeg trykket på linken trodde jeg det var en parodi. Jeg trodde det var en morsom historie som skulle illustrere hvor utrolig dårlige avgjørelser som kan tas i det offentlige. Men det viste seg å være en sann historie. Ikke bare hadde man planlagt tunnelløp som snirkler seg rundt i sirkler, men det var i tillegg altfor bratt og altfor smalt. I siste liten kommer Lars Magnar til unnsetning – “hva om vi bare lager en rett tunell fra A til B?” “Hmmmm… ja, det var kanskje ikke så dumt.”
Er det mulig? EEER DEEET MUUUULIG? Se på den tegningen da!

Rett strek til 125 millioner

Rett strek til 125 millioner


Seriøst!?! Er det mulig? Hva I ALLE DAGER er det som har skjedd her? Det er jo helt absurd. Hvordan kan ellers intelligente mennesker komme frem til så åpenbart elendige designforslag? “Får vi se, vi trenger en ny tunell fra hit til dit – Jeg vet det! (Whoosh, svisj, pennen snurrer rundt og rundt i ring) SÅNN! Dét ble bra tuneller det!”
??????

Og ikke bare det – hvordan i alle dager kan så åpenbart elendige designforslag gå gjennom all kvalitetskontroll og bli godkjent? De fikk offisiell dispensasjon fra krav om stigning og bredde på tunell. Hæ? HÆ? “Jaja, det blir jo litt bratt og svingete, men jeg ser INGEN ANNEN UTVEI enn å ha tunellen snirklende rundt i bratte sirkler slik som planlagt”.
WAT? Hvorfor tenkte man ikke som Lars Magnar med en gang?

Det er ikke bare innen veiprosjektering slike ting skjer, dessverre. Og de samme grunnene til at slike avgjørelser tas innen vei, er også de samme grunnene til at de tas innen f.eks. IT:
Gjenbruk.
Gjenbruk og eksisterende hyllevare “med litt tilpasning”.
Det høres mye bedre ut når man sier det sånn. Det er ikke ønske om å innføre hysterisk dårlige brukeropplevelser som ligger til grunn. Det er snakk om å gjenbruke eksisterende ressurser. I Hordaland var det allerede flere tunnelløp og veier i området. “Da må vi jo benytte oss av disse” Tenkte de. Når man ser på tegningen over blir det forhåpentligvis for alle ganske klart at gjenbruk ikke nødvendigvis er så lurt likevel. De sparte over 30% på å lage en helt ny løsning. Ikke bare ble millioner spart, løsningen ble også mye bedre og tryggere. Tunellen ble hverken trang eller bratt, og reisevei fra A til B ble kortet ned betraktelig.

Akkurat slik er det også innen software. Når man på død og liv skal få alle til å “bruke samme vei”, så blir brukeropplevelsen ofte veldig dårlig. Ikke bare blir den dårlig, den blir også kostbar å lage og vedlikeholde. Endringer i løsningen blir vanskeligere jo flere som bruker den. Både administrativt og rent praktisk. En forbedring for bruker X, kan bety at bruker Y ikke lenger får gjort jobben. Man ender opp med et minste felles multiplum der alle må kjøre rundt i bratte sirkler og det ikke er noe å få gjort med det.

Gjenbruk, hyllevare og fellesløsnigner kan være kjempebra. Men man skal ikke glemme å bruke hodet heller. Av og til er det å lage en ny vei helt klart riktig løsning. Ikke glem å se etter de rette strekene.

Posted in iT | Leave a comment

Billige slips i India

Vi privatiserer stadig flere statlige tjenester og flere av disse private aktørene outsourcer så både drift og utvikling av IT-løsninger til lavkostland som India. Halve poenget med privatisering er å få ned kostnadene, så det skulle jo bare mangle. Uansvarlig å la være kan man si. Hvorfor gjøres det ikke mer av dette egentlig? Og hvorfor begrenser vi oss til IT? Når vi førstnes er igang med å spare skattepenger ser jeg ingen grunn til å ikke gå “all in”. Fra et rent økonomisk perspektiv er det ytterst få ting vi ikke kan gjøre billigere i utlandet (eller med data/roboter). Er det egentlig noe inderne ikke kan gjøre vel så godt som oss – og til en brøkdel av prisen? De har alt de. Fra designere, programmerere og ingeniører til leger, managere og advokater. Norske advokater tar mange tusen kroner i timen. Hvorfor går vi med på slikt? Jovisst kan de sikkert det norske regelverket litt bedre enn indiske advokater, dessuten har de sikkert bedre forståelse for norske forhold, men ærlig talt – inderne kan jo lese seg opp. Til en bitteliten brøkdel av prisen burde det være en “no brainer”: Vi kan få 10 suverene indiske advokater til mindre enn prisen av en norsk en. Jo flere advokater man har, jo større er sjansen for å vinne saken sin, er det ikke sånn det funker? Kvantitet og kostnad per enhet. Dette er gode, robuste og ikke minst enkle ting å måle. Hva er det slipsene sier – “you can’t manage what you can’t measure”. Så skal vi maksimere kontroll, gjelder det å måle så mye som overhodet mulig. Kontroll er som kjent mye viktigere enn suksess.
Og når vi først er inne på slips… Er det noe de har masse av i India så er det jo nettop management og byråkrati. Hvorfor i alle dager er det ingen som har begynt å privatisere og outsource ledelsen og byråkratiet i staten? Det er jo her de høyeste lønningene er. Utrolig mye penger å spare på å outsource ledelsen. Det vrimler av pent kledde folk med slips i India som med sikkerhet kan bidra på alle ledermøter vi har her til lands. Det er jo ikke som om avgjørelsene som tas kan bli så fryktelig mye dårligere? Jeg har stor tiltro til inderne, jeg. Kjør på.

Det er mye vanskeligere å jobbe sammen om å skape verdi for kunder/brukere/mennesker når teamet er delt i to – med den bestemmende overklassen i Norge og arbeiderne i India. Ved å outsource også ledelsen til India, vil de kunne jobbe sammen som ett team. Så tjener vi mer på at de kan jobbe mer effektivt. Vi vil spare masse byråkrati og misforståelser i arbeidsprosessene. Ja, vi vil miste gode arbeidsplasser, men det var vi enige om at ikke gjorde noe – ikke sant? Det er kostnad i kroner og øre vi må fokusere på – ikke arbeidsplasser. Det er mye billigere å ha folk gående på Nav, enn å betale dem lederlønninger i staten.

Det er lett å bestemme at andre enn deg selv skal outsources for å spare penger.
Hvor er vi egentlig på vei? Hva skal vi egentlig ta oss råd til å jobbe med her til lands? Hva slags verden er det vi etterlater oss? Etter oljen skal vi leve av å sitte i møter og skrive kravspesifikasjoner til indere? Vil vi barna våre virkelig så vondt?

Posted in iT, Samfunn, Uncategorized | 1 Comment