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.

This entry was posted in iT. Bookmark the permalink.

14 Responses to Vi trenger ingen helse-plattform

  1. Haakon S. Brænden says:

    Takk for et interessant og innsiktsfullt innlegg. Fint om du sender meg dine kontaktopplysninger. Ønsker å høre nærmere om hvordan du tenker.

  2. Carl-Erik says:

    Her er det så mye klartenkthet og erfaring på ett brett at samtlige helsebyråkrater i Norge bør få dette som pensum. Bravo!

  3. openEHR kan användas till att “fokusere på å lagre og tilgjengeliggjøre helsedata på gode og trygge måter”. openEHR kräver inte heller att allt lagras på samma ställe, openEHR underlättar till och med att samla data från flera ställen och flera leverantörer (som implementerat med flera olika programmeringsspråk) när data följer samma modeller.

    Som programmerare kan du kanske se openEHR-specifikationerna som en samling datamodeller/datatyper plus några DSLs (domain specific languages). (Där DSL:et “Odin” kanske var att gå ett steg för långt, men det skapades innan JSON och YAML var populära alternativ och du kan numera välja dem istället).

    En del av de extra nivåerna ovanpå vanligt programmeringsspråk handlar om, versionshantering, om att slippa skriva om mjukvara/databaser när man uppdaterar eller lägger till nya modeller (det kan då ske genom konfiguration istället för programmering). Några av nivåerna handlar om att vara språkneutral i sökvägar ([at0001] etc). Modeller och sökfrågor skapas vanligen i ett verktyg där man kan visa sökvägen på norska, svenska, engelska, kinesiska eller vad man vill.

    Det är också vikigt att fundera på vem man försöker göra det lätt för. Programmerare är viktiga, men inte de allra viktigaste när det gäller att underhålla fungerande IT i vården. Att behöva dra in leverantörer och programmerare i varenda ändring av modeller och sedan vänta på ny version av mjukvaran är ett jätteproblem som man kanske inte ser som programmerare, men vi som sköter konfiguration och anpassningar av IT inom vården ser det som ett stort problem. Underlättar openEHR mer för oss som konfigurerar och justerar än för programmerarna så är det en OK tradeoff. Det finns tillräckligt nu tillräckligt många programmerare och företag i världen som förstått openEHR så att det nu för tiden finns flera system/leverantörer att välja på (inte bara DIPS). Jag tror du kommer gilla openEHR-approachen också när du ser saker från fler vinklar än du gör just nu.

    Vänliga hälsningar,
    Erik Sundvall,
    Informationsarkitekt, Region Östergötland
    Ph.D. Medical Informatics.

    • qristin says:

      Takk for dine innspill.
      Jeg er klar over at OpenEHR KAN fungere til mye. Jeg er også klar over at dagens systemer, der man venter for evig og alltid på å få software oppdatert ikke virker fristende å fortsette med. Og jeg er 100% enig i at det ikke er utvikleropplevelsen vi skal optimalisere for.

      Software er fortsatt et ganske ungt fagfelt, og det skjer utrolig mye rent teknisk som hele tiden snur verden vår på hodet. Men vi lærer stadig og blir bedre. Jeg burde ha nevnt dette i blogg-innlegget mitt: En av tingene vi etterhvert har blitt gode på innen software-utvikling, i alle fall mange, er å jobbe med det vi kaller DevOps, som også går under navn som Continuous Integration (CI) og Continuous Deployment (CD). Tjenester som Netflix, Facebook, Twitter, Spotify… og liknende oppdaterer sine systemer fortløpende. Som bruker er man knapt klar over at det skjer, men de ruller ut ny funksjonalitet, oppgraderinger og fikser hver dag hele tiden. Dette kan sikkert virke som useriøst og usikkert, men vi har nå mye harde data som viser at det å kunne oppdatere systemer fort, henger sammen med kode-kvalitet. Jo raskere en kan få kode ut i produksjon, jo bedre kvalitet får koden. Det henger naturlig nok også sammen med brukertilfredshet – ettersom brukere kan få ny funksjonalitet på timer istedenfor måneder. (Les gjerne boka Accellerate (https://www.goodreads.com/book/show/35747076-accelerate) for mer informasjon.)
      For å få dette til å fungere må man skrive kode som er testbar, og ha automatiske tester som verifiserer at alt fungerer slik det skal. Så blir disse testene kjørt hele tiden på alt som rulles ut. Teamene som utvikler software må ikke bare bestå av utviklere. Det må være et kryssfunksjonelt team som forstår hva det er som lages og hvorfor. Ellers klarer man ikke skrive tester som gir noen verdi. I helse-sammenheng, vil team bestå av både klinikere, utviklere, brukervennlighets-eksperter, designere, alt mulig – disse vil jobbe tett med og følge med på respons fra brukere på hva det er som faktisk trengs, slik at løsningen kan utvikles til å bli optimal for brukerne – som jo er de viktigste i hele prosessen.

      Helse er et enormt fagfelt – og OpenEHR folk og helsefolk generelt snakker alltid om hvor utrolig komplekst det er. Dette er i seg selv et slags rødt flag for meg, at man ser på problemet på feil måte. Selvsagt er “helse” komplekst. Skal man løse “helse” med ett system, så blir det åpenbart utrolig vanskelig. En annen ting vi har lært oss innen IT, som nevnt i artikkelen min, er at det lønner seg å dele ting inn i mindre deler. For når man ser på hver enkelt arbeidsgruppe – så er det plutselig ikke så komplekst like vel. Hva er det en sykepleier i en ortopedi-avedling trenger i løpet av sin arbeidsdag? Trenger han de samme dataene som øyespesialisten på klinikken borte i gata? Mest sannsynligvis ikke. Dersom vi samler våre helsedata i dedikerte registere – et blodprøve-register kanskje? Så vil ikke denne tjenesten i seg selv være så kompleks. Hvert enkelt register trenger ikke være så komplekst, og hver individuelle applikasjon – den til sykepleieren på ortopedi, og den til hjerne-kirurgen, den til hjemmehjelpen tilknyttet eldresenteret, de trenger heller ikke være så komplekse, ettersom de er 100% fokusert på å hjelpe akkurat den arbeidsgruppen eller pasient-gruppen de skal hjelpe. Til sammen kan det bli et hav av forskjellige applikasjoner som alle henter data fra forskjellige steder, men hver for seg, er de enkle og trygge å jobbe med, noe som gjør at man kan jobbe effektivt med dem for å levere maksimalt gode tjenester for dem som trenger det.

      • Erik Sundvall says:

        Vi har givetvis redan vanliga DevOps i sjukvårdsregionens utvecklingsorganisation, det tror jag de flesta större vårdgivare har. De jobbar med exempelvis integrationslösningar och diverse egenutvecklade system som inte finns att köpa som standardprodukter på marknaden. Våra DevOps ser dock inte openEHR som en konkurrent utan som ett avlastande komplement.

        När man driver och konfigurerar ett openEHR-baserat system så är det i prinicip också med ett sorts annorlunda DevOps-team, dock med mer av informatiker och vissa av vårdens ”super-users” inblandade i utvecklingen än vad de flesta mjukvaruutvecklare tänker på när de säger DevOps. Några från vårt “vanliga” DevOps-team ingår givetvis också.

        Det våra mjukvaruutvecklare tycker om med openEHR är att de inte behöver skriva GUI+kod+databas-scheman för en massa föränderliga kliniska detaljer (det genereras istället semi-automatiskt från arketyper, templates, form-buider (med low-/no-code stöd) och en “form-renderer”-komponent att stoppa in i webbaplikationer). Istället kan mjukvaruutvecklarna fokusera sin tid på sådant som krävs runtomkring, och på kod för små viktiga specialfunktioner inuti vissa formulär som behövs för vissa uträkningar eller ovanliga interaktioner. (Då räcker det att de förstår vad just den delen av formuläret är till för.)

        Angående “rött flagg” så finns det säkert fler komplicerade områden än vård, och där har man säkert också kommit på återanvändbara mönster/metoder som underlättar utveckling och underhåll inom den domänen men som inte är självklara innan man sätter sig in i dem och varför de skapats. För vård visar forskning och erfarenhet att man bör dela upp systemen i åtminstone tre olika sorters modeller, se Rector AL, Rogers J, Taweel A. Models and inference methods for clinical systems: a principled approach. Stud Health Technol Inform. 2004;107(Pt 1):79-83 http://ebooks.iospress.nl/publication/20945

        Att det är lite krångligt (och därmed extra spännande att jobba med) kan man även läsa om i exempelvis:
        – A. Rector. Clinical terminology: why is it so hard? http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf
        – T. Beale. The Health Record – why is it so hard? https://pdfs.semanticscholar.org/c8c0/8aa4acaefc11250b2711f3ce215d7e00743f.pdf

        Apropå terminologi-system: Mycket av teorin bakom de ontologi/DL-system som används inom flera andra områden än medicin idag kommer ursprungligen från forskning inom medicinsk informatik där man behövde bättre verktyg för att modellera kunskap än vad standardmetoderna på den tiden erbjöd.

      • Erik Sundvall says:

        Vi har givetvis redan DevOps i sjukvårdsregionens utvecklingsorganisation, det tror jag de flesta större vårdgivare har. De jobbar med exempelvis integrationslösningar och diverse egenutvecklade system som inte finns att köpa som standardprodukter på marknaden.
        När man driver och konfigurerar ett openEHR-baserat system så är det i prinicip också med ett sorts DevOps-team, dock med mer av informatiker och vissa av vårdens ”super-users” inblandade i utvecklingen än vad de flesta mjukvaruutvecklare tänker på när de säger DevOps. Några från vårt vanliga DevOps-team ingår givetvis också.
        Det våra mjukvaruutvecklare tycker om med openEHR är att de inte behöver skriva GUI+kod+databas-scheman för en massa föränderliga kliniska detaljer (det genereras istället semi-automatiskt från arketyper, templates, form-buider med low-/no-code stöd och en “form-renderer”). Istället kan mjukvaruutvecklarna fokusera sin tid på sådant som krävs runtomkring, och på kod för små viktiga specialfunktioner inuti vissa formulär som behövs för vissa uträkningar eller ovanliga interaktioner. (Då räcker det att de förstår vad just den delen av formuläret är till för.)
        Angående “rött flagg” så finns det säkert fler komplicerade områden än vård, och där har man säkert också kommit på återanvändbara mönster/metoder som underlättar utveckling och underhåll inom den domänen men som inte är självklara innan man sätter sig in i dem och varför de skapats. För vård visar forskning och erfarenhet att man bör dela upp systemen i åtminstone tre olika sorters modeller, se Rector AL, Rogers J, Taweel A. Models and inference methods for clinical systems: a principled approach. Stud Health Technol Inform. 2004;107(Pt 1):79-83 http://ebooks.iospress.nl/publication/20945
        Att det är lite krångligt (och därmed extra spännande att jobba med) kan man även läsa om i exempelvis:
        – A. Rector. Clinical terminology: why is it so hard? http://www.cs.man.ac.uk/~rector/papers/Why-is-terminology-hard-single-r2.pdf
        – T. Beale. The Health Record – why is it so hard? https://pdfs.semanticscholar.org/c8c0/8aa4acaefc11250b2711f3ce215d7e00743f.pdf
        Apropå terminologi-system: Mycket av teorin bakom de ontologi/DL-system som används inom flera andra områden än medicin idag kommer ursprungligen från forskning inom medicinsk informatik där man behövde bättre verktyg för att modellera kunskap än vad standardmetoderna på den tiden erbjöd.

    • superslipset says:

      Hei Erik,
      Christin nevner Accelerate i sitt svar, men la meg legge til The Phoenix Project og The Unicon Project i samme slengen, da Gene Kim er (med) forfatter av alle tre.

    • Frode Nilsen says:

      «Att behöva dra in leverantörer och programmerare i varenda ändring av modeller och sedan vänta på ny version av mjukvaran är ett jätteproblem»
      Nei, dette er ikke et problem. Dette er det du må gjøre i enhver annen sammenheng. Du endrer ikke utformingen på en operasjonssal uten å koble inn kirurg, renhold, byggmester osv. heller.
      Der at dette blir fremstilt som et problem er selve problemet. Har man små systemer så krever slike endringer heller ikke så mye tid.

      • Erik Sundvall says:

        När vi ändrar i en operationssal går det lättare och snabbare i de fall då vår egen personal (kirurg, fastighetsförvaltning, renhållning etc.) klarar det mesta själva och vi inte behöver be leverantörerna av lampor och operationsbord komma och flytta på eller designa om sina produkter. Finns det redan genomtänkta, flexibla, väl utformade komponenter att använda som vi själva kan arrangera om för att uppfylla behovet så går det lättare och snabbare än om det måste beställas, designas och testas helt nya komponenter.

        Arketyper och openEHR-baserade system är ofta genomtänkta och flexibla komponenter som vi kan sätta ihop för att möta nya behov. De system vi har där all logik ligger i t.ex. javakod och databas-scheman är vanligtvis mycket långsammare att förändra, särskilt om de är gjorda av en extern leverantör som har en massa annat från övriga kunder att prioritera.

  4. NHS brukte ca 100 milliarder på en tilsvarende, sentral tankegang.
    https://wolandscat.net/2018/10/28/why-npfit-failed/

  5. Pingback: We don’t need a healthcare platform | Hello world

  6. Jeg må bare si at jeg har tenkt på og anbefalt denne blogposten mye i det siste. Det er utrolig viktig at du får fra beskrivelser som binder sammen det hele fra finansiering og samfunnsoppdrag til datamodell og standardisering og hvordan det henger sammen.

    Det er en vanlig tanke i dag at man kan ha verdifulle meninger om hva som bygges uten å forstå opp og ned på de byggeklossene som brukes til å bygge dem. Det er utrolig farlig.

  7. Pingback: God dag Akson! Økseskaft | Hello world

  8. Pingback: KOMMENTAR: God dag Akson! Økseskaft – Norge

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s