DEBATT: Akson-debatten:­– Hvis noe går galt med plattformen, går hele Helse-Norge ned

[Redaksjonen.]

DEBATT: Akson-debatten:­– Hvis noe går galt med plattformen, går hele Helse-Norge ned

[quantum]

Henvisningen til artikkelen https://qristin.wordpress.com/2019/11/30/vi-trenger-ingen-helse-plattform/ hvor det forklares hvorfor "plattform"-tankegangen, slik som DIPS implementerer den, skaper trøbbel er viktig. Og advarselen om at ideen om å finne en så generisk "plattform" i markedet at den kan tilpasses og brukes til alt i ulike settinger er helt utpoisk, er betimelig. I komplekse settinger blir ideen om at man kjøper et "ferdig produkt" en sovepute, it's all taken care of, og så våkner man opp mandags morgen til et customization and configuration hell, som ender med at man stanger hodet i veggen på ytelse, eller at produktet ikke kan konfigureres så fleksibelt likevel osv.

Feilen som tydeligvis gjøres, f.eks. i DIPS med openEHR, er at standarden/den generiske domenemodellen, implementerres naivt bokstavelig i hele den interne applikasjonsarkitekturen, med påfølgende problemer med kompleksistet og ytelse. En mer realistisk tilnærming vil være å la de ulike applikasjonene/(mikro)tjenestene forvalte sin egen interne implementasjon og bare bruke standard-domenemodellen i integrasjoner. 

Tanken om en stor, felles integrasjonshub er vel også problematisk på den måten som påpekes, det blir et svakt punkt, går den ned står alt stille. Samtidig vil jo den andre ytterligheten, alle tjenester integreres direkte med hverandre, kunne medføre store vedlikeholdskostnader, endres api'et i en tjeneste må alle de hundre andre klientapplikasjonene som brukes denne oppdateres. Det kan derfor være lurt å ha et buffer i mellom, men det trenger jo ikke være en monolittisk integrasjonshub, i verktøykassen kalt moderne softwarearkitektur fins gode alternativer.

[Gjest Slettet+9817234]

Kan en ikke bli litt Linux?

 

Noen lager et bra system for blodprøver, andre la-er et annet for røntgen mens en tredje løsning er noe for tester av hjertet. (Tilgi meg fagmennesker for det som nok rent faglig er en rotete inndeling. Prøv å s poenget med at en lager OE for de forskjellige nisjene innen helse). Så trener en bare kunne kjøre kall mot all disse for å samle og presentere data i form av journaler, rapporter og annet. 

La koden være fri og åpen samlet i e tjeneste ala github. Dann en liten organisasjon som er Linus og la alle andre være utviklere av «drivere» og «filsystem».

 

Jeg vil gjerne høre hvorfor en slik tilnærming ikke vil være fornuftig. 

[JM1ORBHF]

Nei, internett er ikke plattformen fordi all medisinske data skal gå i et lukket nettverk og lagres på en spesiell måte i forhold til et strengt regelverk. (pga loggføring,sikekrhet, snoking osv)

Det som ikke er nevnt er at det allerede idag er plattform leverandører. riktignokk lukkede.

-

Det finnes 3 plattformer for Pleie og omsorg, 3 for Allmennleger og 3 for Sykehus.

-

Hvorfor skal staten utkonkurrere desse levarandørene med sin egen plattform?

[oppat]

Det som kan gi merverdi er at Staten bestemmer at alle systemer må kunne snakke en viss protokoll, at autentisering skal skje med en viss protokoll, hvordan identitet skal håndteres osv.

Selv når Staten velger absolutt dårligste løsning (Altinn SOAP f.eks.) så gir det verdi at det i alle fall finnes en standard.

Når man standardiserer så er det en FORDEL at det f.eks. finnes 3 plattformer for Pleie og omsorg, 3 for Allmennleger og 3 for Sykehus. Da kan man effektivt sjekke interoperabiliteten.

Altinn f.eks. har kjørt på buggy implementasjoner av SOAP fordi de kun bruker .NET-stacken og dermed aldri faktisk sjekket samhandling på tvers av implementasjoner før 5-10 år etter at de var igang.

[quantum]

JM1ORBHF skrev (6 timer siden):

Nei, internett er ikke plattformen ...

Det er ingen som har spurt om "internett er plattformen", så du trenger ikke svare nei på noe ingen har spurt om. Det er heller ikke slik at når noen som utvikler en løsning, eksempelvis Linux, bruker Internett som samarbeidsplattform, så må også det de lager kjøre åpent på "internett". Linux, eksempelvis, brukes ofte som bærebjelke i såkalt nasjonal infrastruktur, i kombinasjon med mye annen opensource programvare. Dette er systemer som behandler sensitiv informasjon som ikke skal på avveie.

Et eksempel på opensource medisinsk software som er i bruk: https://www.dhis2.org/  Ifi, UiO administrerer utviklingen, men det er selvfølgelig brukerorganisasjonene som er ansvarlige for data som legges inn i derers organisasjoner, og at disse ikke kommer på avveie.

Men nå er det samtidig sånn at selve fagsystemene ofte er proprietært og bygget "in-house", enten i organisasjonen selv, av konsulenter, eller av utviklere i et produkt-selskap. Det som er spørsmålet her, i forrige innlegg, er om et stort prosjekt som dette kan deles opp i mange "micro-domener" som hver seg betjenes av eksempelvis microservices, som kan settes sammen etter behov. Og det burde være fullt mulig, men det må kunne integreres i helhetlige løsninger, og oppdelingen må være slik at hver del gir bruksverdi i seg selv, slik Gorman påpeker at er viktig.  

Så til spørsmålet om hvorfor ikke eksisterende systemer, som det allerede er flere av, kan brukes, istedenfor å lage nye. Det kan det være mange årsaker til, men den viktigste er vel den Gorman peker på; slike systemer lages ofte veldig generiske slik at salgsargumentet blir at systemet støtter "alt", det kreves bare "litt" konfigurasjon. Dette har man en del erfaring med at ikke alltid stemmer så godt, har selv sett denne tangegangen tryne episk, og det fins, som Gorman skriver, et navn på det også; SAP-syken. Den kanskje viktigste årsaken til å være skeptisk er her de store problemene Danmark har hatt i sitt implementasjonsprosjekt med samme system.

Mot-satsen til dette, er å benytte mest mulig generiske komponenter i arkitektur-stacken (eksempelvis Linux, Kubernetes, Hibernate, Spring, React osv.), men egenutvikle det som håndterer kjerne-domenet selv, siden dette ofte er så spesifikt at det er det beste. Det fins mange "industristandarder" innen helse, finans, reise osv. og disse har mye for seg til bruk i integrasjoner, men i de spesifikke løsningene internt er det ikke sikkert at nasjonale/lokale krav og behov dekkes på en god måte om en kun støtter seg på internasjonale standarder ment for integrasjon på organisasjonsnivå.

Endret 18. august 2020 av quantum