KOMMENTAR: Akson: Prosjektet har for høy risiko med for mange uavklarte problemstillinger

[Arild Haraldsen]

KOMMENTAR: Akson: Prosjektet har for høy risiko med for mange uavklarte problemstillinger

[tjavel]

Kan man ikke bare gjøre som man gjør i open source prosjekter at man har et lite men dyktig team (3-5 utviklere) som bare begynner lage noe som ligner på et journal styrings system ut i fra best tilgjengelig kunnskap men uten å planlegge eller arkitekt-styre det i hjel. For all del ikke sett det ut på anbud som eget prosjekt til de store konsulenthusene, bare hyr inn noen kompetente utviklere. Kostnadene er da under kontroll og om det ikke fører noen vei etter et år så har man bare blåst noen få millioner.

Så gjør man release early, release often, lager noe som man kan begynne å teste og ber om tilbakemeldinger fra kommuner, leger og andre interesserte.

Gjør kildekoden tilgjengelig på github tidlig og dokumenter designet med kjent datamodell og foreløpig arkitektur for deployment, sikkerhetsmodell osv på wiki slik at enhver skattebetaler eller ansatt i helsevesenet og utviklere over det ganske land kan gi tilbakemeldinger. Dette er skattebetalernes penger og er offentlig eiendom.

Spørsmålet om stor kjerne kontra liten kjerne er et sidespor om man bygger modulært, man finner de delene (klynger av entiteter) av datamodellen som er noenlunde isolerte og kan oppdateres asynkront og bygger disse klyngene til å kunne fungere uavhengig, slik som er vanlig med micro services tankegang.

Da kan enten staten eller private lage støttekomponenter. Men jo flere APIer, dess større angrepsflate og pasientjournaler er sikkerhetskritiske så jeg vill sagt at bygg modulært men gjør deployment som en monolittisk applikasjon der det er færrest mulig API-kall på nettet.

Ser ikke noe problem med at staten sier at de bygger systemet fullt og helt, det er det offentlige som betaler legene og da burde ikke NHO ha noe de skulle sagt på at byggingen av dette ikke blir lagt på det åpne markedet.

Endret 1. juli 2020 av tjavel

[tjavel]

Eller bare benytte seg av dette, eksisterende modulært journal-system bare et google-søk unna.

https://openmrs.org/

Kjapt anslag av kompleksitet sammenlignet med andre komplekse systemer har jobbet på ca 500.000 kodelinjer.

En flink utvikler som får mulighet til å jobbe selvstendig og ikke sitter halve dagen i møter bør klare 50.000 i året, så jeg vil anslå 10 årsverk. Så må det være noen produkteiere som driver overordnet brukerkravs-innsamling og interaksjon med mulige brukere, siler tilbakemeldingene, skjermer utviklerne osv.

 

AKSON er planlagt til å koste milliarder etter hva jeg ser. Dette er på ene siden helt ubegripelig men på den andre siden følger det sikkert vanlig planlegging

- en lang planleggingsprosess som ender i tusenvis sider med dokumentasjon, når en A4 side hadde vært nok komme i gang med å lage noe konkret.

- skalert opp som stort prosjekt med mange deltakere der mye av kompleksiteten ligger i å styre kompleksiteten av prosjektet, som mest er der fordi man skalerte det opp tidlig.

- unødige tidsrammer hvor man da bruker mye av den produktive tiden på estimater av hvor lang tid oppgavene tar og diskusjon over hvorfor en ikke estimerte bra nok, i stedet for å studere hva en faktisk lager.

Regel nummer 1 i effektiv programvareutvikling, start med få personer involvert og lag noe konkret som fungerer! slik at en har et grunnlag for videre diskusjon og kan begynne å eliminere ukjente. Hyr inn folk etter behov. Lag en prototyp en kan bygge videre på eller studer et eksisterende open source EMR prosjekt som det over slik at man har noe å å orientere seg etter.

Endret 1. juli 2020 av tjavel