Gæstebloggen

Sundhedsplatformen: Fravalg af open source har lænket Region H til leverandøren

En ting er, at det offentlige med jævne mellemrum kaster flere milliarder ud af vinduet eller i lommen på firmaer uden at få en løsning, der virker godt nok. Men når det handler om sundhedsområdet, så går den ikke længere. Der er liv på spil.

Sundhedsplatformen er skabt til at hjælpe med at redde menneskeliv, hvis den ikke gør det, kan resultatet blive det modsatte. Derfor undrer det mig, at det ikke er mere ansvarspådragende.

Jeg er ikke udvikler, mit fokus har været brugervenlighed, brugergrænseflader og senere Computer Supported Cooperative Work. Men selv for en ikke-udvikler virker det uforståeligt, at Danmark i 2017 kaster milliarder efter et proprietærsystem.

Hvilke strategiske fordele fik Region Hovedstaden ud af at vælge et proprietært system? Hvorfor investerer vi i et system, der er kodet i et sprog (MUMPS), som de fleste leverandører ikke kender? Og er systemet egentlig sikkert nok?

Kravet om åbne standarder er i al fald tabt på gulvet. Derfor bliver det også tydeligt, at Region Hovedstaden ikke har kunnet integrere viden fra giganter som: Apple, Microsoft og Google.

Alle disse firmaer har bygget open source systemer, som de strategisk har fået fordele ud af, at andre kan videreudvikle til. Hvorfor forsøgte man ikke at lave sundhedsplatformen til et åbent system?

Det er bedrøveligt, at Region Hovedstaden ikke var mere ambitiøs.

Med de skattemilliarder vi har kastet efter Sundhedsplatformen, kunne vi have skabt en global open source succes. Danskerne kunne stå som den befolkning, der havde styrket åbne standarder for sundhedssektoren i hele verden.

Vi kunne have bidraget til FN’s verdensmål og støttet hele verdens sundhed med robust og åben informationsteknologi. Vi kunne have foræret al vores udviklede funktionalitet til andre - også udviklingslandene. Og så ville vi selv kunne nyde godt af, at alle andre kunne bidrage med features til vores system.

Et open source system ville også have forhindret, at vi blev lænket til én hovedleverandør. Med en åben løsning ville vi altid kunne skifte leverandør. Vi ville også kunne bruge mange forskellige mindre leverandører.

Og hvis vi valgte at afbryde samarbejdet med en leverandør, der ikke kunne leve op til de aftalte krav, så ville vi altid kunne bede andre om at fortsætte med opgaven.

Ringe it-faglighed førte til proprietært system

Men nu står vi med et proprietær system. Det er virkeligheden. Det værste er næsten forudsigeligheden. Sundhedsplatformen er blot det seneste eksempel på det danske IT-syndrom. Det danske IT-syndrom findes i spændingsfeltet mellem: politikere, administration og stribevis af idérige folk med ringe it-faglighed.

Det danske IT-syndrom påvirker hørelsen, så de, der lider under det, ikke kan høre, når fagfolk fortæller, at man er på vej mod et forudsigeligt sammenbrud. Ingen lytter, når fagfolk peger på, at staten igen er ved at designe et system, som ingen kan vedligeholde eller arbejde videre med.

Når disse pointer dukker op, så reagerer politikerne og den ofte samfundsfagligt uddannede administration ved at selvmedicinere med dyr konsulent-terapi. Og så er der pludselig alligevel en business case.

Sundhedsplatformen skriver sig ind i en lang dansk tradition, hvor offentlige IT-projekter startes med skønne visioner, hvorefter brugerne ikke oplever, at systemet passer til dem.

Men det er ikke overraskende, at brugerne ikke mener, at systemet passer til dem. Det er ikke bygget til dem. Det er bygget til det amerikanske sundhedsvæsen, hvor fakturering er en helt central aktivitet. Dernæst er det tilpasset til danske forhold, så godt man nu kunne.

Intet belæg for konvertering af amerikansk system

Der er intet forskningsmæssigt belæg for at tro på, at man kan tage et EPIC system (eller andre systemer), der er designet til en kompleks amerikansk arbejdskontekst og så flytte dem til en kompleks dansk arbejdskontekst. Tværtimod viser forskningen, at hvis man vil designe software til komplekse og kritiske arbejdssituationer, så må man anvende user centered design.

En user centered design tilgang vil, som navnet antyder, være kendetegnet ved, at den ægte bruger sættes i centrum. Man kan kun få ægte succes, ved at tage udgangspunkt i brugernes konkrete situation - og hjælpe dem med at løse de opgaver de vil i mål med.

Fokus på fine IT-karakterer

Set udefra ser det desværre ud til at udgangspunktet for Sundhedsplatformen har været at sætte politikerne og administrationen i centrum. De ville gerne have fine “karakterer” på HIMSS skalaen (Healthcare Information and Management Systems Society).

Men fokus burde have været på at hjælpe sundhedspersonalet med at løse deres konkrete opgaver i deres kontekst, så deres arbejde blev nemmere og mere effektivt.

Forskningen viser, at hvis man leverer systemer, som fx Sundhedsplatformen, der hverken bliver opfattet som brugbar eller brugervenlig, så vil brugerne simpelthen ikke anvende den frivilligt. Man kan tvinge brugerne til at anvende systemer, som man har gjort det med Sundhedsplatformen, men det må anses for en art informationsteknologisk primitivisme.

Med fare for at blive anekdotisk, så har jeg på det seneste talt med en del sundhedsfagligt personale. De personer, jeg taler med, har den klare opfattelse, at Sundhedsplatformen ikke er særlig brugervenlig. De vurderer, at de har mistet mellem 10 til 15 pct. af deres effektive arbejdstid pga. systemet.

Effekten af Sundhedsplatformen er altså sammenlignelig med at spare over en tiendedel af sundhedspersonalet væk. Det bringer mindelser om det berømte citat: operationen lykkedes, men patienten døde.

Kristian Tønning er kandidat til regionsrådet i Region Hovedstaden for Dansk Folkeparti. Indlægget udtrykker dog ikke partiets IT-politik.

Relateret indhold

Kommentarer (30)
Birger Nielsen

Går det som du spår, så kan hovedstaden overtage et af de øvrige forhåbentligt velfungerende systemer, til en (teoretisk, da der er politikere indblandet) rimelig pris.

Men hvis du tænker lidt over din sætning "Det er bygget til det amerikanske sundhedsvæsen, hvor fakturering er en helt central aktivitet.", er de ansvarlige for valget så blot mere forudseende end andre?

Med individualitetens og egoismens fremvækst som vi ser det ske, med hastig erodering af kollektive løsninger, så er valget af den amerikanske model måske ikke så tosset.

Anne-Marie Krogsbøll

Indlægget rammer lige ned i nogle af de problemstillinger vedr. Epic, som ikke omtales så meget, når Epics ambassadører i regionen udtaler sig. Og sætter også fokus på, at man har forpasset en god chance for at se ud over egen næse. Så tak for et rigtigt godt indlæg med originale tanker.

"Set udefra ser det desværre ud til at udgangspunktet for Sundhedsplatformen har været at sætte politikerne og administrationen i centrum."

Ja - det passer præcist med min tiltagende oplevelse af, at Epics kundekreds forsøges bygget op som en sekt. Hvordan skal man ellers forstå det setup, man har opbygget omkring de årlige User Group Meetings, hvor deltagerne (her i blandt 56 ledere fra Region Hovedstaden) lokkes ind i et Harry Potter univers, hvilket vel i ekstrem grad er egnet til at indgyde en følelse af at være del af et særligt, lukket, elitært selskab med magiske evner - komplet uforståeligt og uigennemskueligt for udenforstående (læs uvedkommende/uvelkomne)? Peppet op med tydeligvis underholdende WOW-indslag, som kun kan være egnet til at få de pågældende ledere til at glæde sig rigtigt meget til næste år - for det ser umiddelbart ud til at være en årligt tilbagevendende begivenhed - og fortsat i Harry Potter-universet - det melder man sig jo ikke lige sådan ud af. Jeg har spurgt til regionens fortsatte deltagelse i dette, men har ikke fået svar.

Så ved at indsmigre sig hos nøglebrugere på denne måde, mindskes risikoen for oprør og kritik udadtil og ind ad til - man vil jo nødigt ende i "bad standing". Gad vide om det er en del af kontrakten, at man skal bidrage med indlæg på UGM? I hvert fald har tre af regionens folk holdt oplæg: "Program Management for an Efficient Large-Scale Rollout". "Securing the Link in a Wave Implementation". Og et oplæg af Svend Hartling ved et relateret event udenfor UGM - emne ukendt.
Gad vide, hvad de har sagt? Mon de daglige brugere af SP kan genkende den udlægning, som de udsendte ledere har tegnet af SP's implementering i Region Hovedstaden? Eller har de bidraget til, at kommunikationsdirektører i andre lande/regioner/byer kan tage hjem og levere et skønmaleri af samme karat som det, Elisabeth Geday leverede i Politiken for nylig - efter deltagelse i netop UGM?

http://politiken.dk/debat/debatindlaeg/art6171800/Med-tiden-skal-Sundhed...

Samtidig er UGM tydeligvis en salgsmesse for andre firmaer, eks.: http://www.zynxhealth.com/events/event/ugm-2017-epic-users-group-meeting/
http://www.versustech.com/rtls-news/past-events/epic-user-group-meeting/
https://twitter.com/hashtag/epicugm?lang=en

Hvilke gode ideer har direktionen mon nu fået for nyanskaffelser? Er der ligefrem truffet aftaler om kontakter o.l.? I givet fald - husker man så denne gang at tage kyndige IT-folk med på råd, inden man binder sig?
Jeg ved ikke, om noget lignende cirkus er en normal del af at binde sig til så store systemer/firmaer, men at gøre det til et Harry Potter World event - det antyder ligesom, hvordan man tænker.

Så ja - det virker som om, hele tænkningen omkring Sundhedsplatformen er gennemsyret af præcist det modsatte af det, som efterlyses i indlægget - at man havde holdt sig til open source, fokuseret på danske forhold, på brugerne i dagligdagen, på at bidrage til en bedre verden og med tanke for, at man på et tidspunkt kunne have lyst til at bryde ud med "sekten". Det kan man så ikke nu ....
https://ugm.epic.com/

Michael Rasmussen

Sundhedsplatformen er endnu et eksempel på den nuværende katastrofale offentlige indkøbsproces, hvor processen er vigtigere end produktet således, at generalister i embedslaget og jurister fører takststokken i indkøbsprocessen til umådelig skade for samfundet og borgerne. Man får hurtig den opfattelse, at den nuværende indkøbsproces ikke er designet med henblik på at købe det bedste produkt til den bedste pris, men i højere grad er designet med henblik på at sikre arbejde til generalisterne i embedsværket samt juristerne!

Martin Sølvkjær

Jeg er enig med Kristian Tørning i betragtningen.
Exit omkostninger ved at have anskaffet et proprietært system vil også være enorme - især hvis man ikke kan få sine gamle data med sig. Men heldigvis bliver mange af vores data eksporteret til Sundhedsjournalen.
I 2008 foreslog jeg at man skulle bruge Veterans Affairs system, VistA, i DK på basis af konkrete erfaringer med at tilpasse det. Bortset fra det retoriske 10 mio kr beløb fremfor 10 mia syntes det realistisk på basis af erfaringerne at anskaffe systemet. Det kunne have været fint at forsøge med Bornholm, som kunne have leveret en relativt risikofri aftestning. Men der var stor modstand dengang i forhold til VistA, hvilket jeg aldrig kom til at forstå.
Link til artiklen fra 2008:
http://www.version2.dk/artikel/laege-open-source-vil-kunne-loese-danmark...
Systemet har været placeret på toppen i USA med hensyn til brugertilfredshed igennem mange år.
Men der er jo altid men.....
Systemet har stået overfor en gennemgribende modernisering, og "præsidenten" har valgt at det skulle udbydes, hvor Cerner nu har vundet.
Vi ville i så fald have stået i en situation, hvor den væsentligste hovedaktør bag systemet var faldet væk. Det ville have været svært at løfte.
Man man kunne godt tænke alternative muligheder nu hvor Region Syd er i udbud. Det kunne være at nogle af de aktuelle aktører udgav deres system som open source eller at man videreudviklede på basis af eksisterende komponenter herunder Den Nationale Serviceplatform.
Afkoblingen af ejerskab og opbygning/vedligehold kræver dog en noget anden udbudsform, og er kontraintuitiv i forhold til begrebet at købe et system. Og så har man selv ansvar for udvikling og stabilitet.
Det er nok ikke realistisk at DK kaster sig ud i noget lignende. Den implicitte frygt overfor det ukendte er er for mig at se konturerne af en ny kampflyskandale. Nå nej, det er jo closed source om noget er. Så en signalskandale da.

Jan Larsen

Især fra politisk side, har vi et mantra om: Vi er ikke specielle i Danmark, vi skal købe en hyldevare og tilpasser os. Det kan være rigtigt, hvis vi skal skrive et notat, læse nyheder eller lytte til musik.

Vi har også besluttet at, alle systemer skal i udbud, med jævne mellemrum, for så kan vi spare penge.

Men Open Source finder vi ikke på hylderne.
Det er kun firmaer der har varer på hylderne, der deltager i udbud.
Derfor er der ikke Open Source produkter med i udbud!

Som Morpheus siger i Matrix: "Welcome to the real world".

Klavs Klavsen

Super godt indlæg Kristian Tørning.. jeg kan kun erklære mig 100% enig (savner thumbs op til artiklen ;)

Dem der i dette tilfælde foreslår open source: Findes der et FOSS projekt der har de features og ikke mindst performance og skalerbarhed der kræves ? Og professionel support?

Du har vist ikke forstået pointen med Open Source.
Læs lidt her https://www.pcworld.com/article/209891/10_reasons_open_source_is_good_fo...

Og NEJ der findes næsten med 100% sikkerhed IKKE et Open Source projekt der er designet til at drive et hospital.. men det er heller ikke sådan man bør lave et.. Man bør benytte alle de Open Source byggeklodser der allerede findes.. (middleware såsom REST frameworks a la SLIM eller Laravel eller Symfony - hvis det skal være PHP - eller falcon til Python osv. osv.)

Og så have nogle fornuftige IT arkitekter på - der kan hjælpe med at lave et design der giver http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/ - så man kan udvikle hvert område som sin egen komponent.. Herunder UI grænsefladen - som bør benytte et API der udstilles af den bagvedliggende komponent der bekymrer sig om data, privilegier og "alle de tekniske detaljer" - hvorved man kan udvikle/ændre på UI som man har lyst, for at holde fokus på at gøre det nemt for brugeren af systemet. "Brugeren i centrum" - som jeg er 100% enig i..

Og hvordan man så får udvikling til at fungere godt - Ja der kunne man jo passende tage erfaringer fra fejlede projekter (du ved ligesom man gør tog + fly.. ) en IT Havari komissionsion (som PHK blandt andet har foreslået mange gange :)

Torben Mogensen Blogger

Andre projekter bliver beskyldt for at udvikle selv og ikke bruge en hyldevare. Og så er det sgu ikke nemt hvis man skal begge dele.

PolSag brugte faktisk en hyldevare, og det gik også skidt. Hyldevarer kan være fine, men kun hvis de fungerer godt og ikke kræver meget omkostningstunge tilpasninger.

Dernæst er der forskel på proprietær og hyldevare. Hyldevarer kan sagtens være open source, og specialudviklede systemer kan sagtens være proprietære. Artiklens kritik er ikke, at det valgte system er en hyldevare, men dels at det er proprietært (og derfor giver vendor lock in), dels at den lukkede platform vanskeliggør senere migration til et andet system, og dels at det er en forkert slags hyldevare -- en vare, der er designet til helt andre forhold end de danske. Det svarer lidt til at købe en 18-wheeler lastvogn, når man egentlig skulle bruge en traktor.

Bjarne Nielsen

Dernæst "Hvis det er lavet af et stort firma, så må det være godt".

Jeg tror, at det er noget med, at man gerne vil have en leverandør som er stor nok til at kunne betale erstatning, hvis noget går galt.

Problemet er så bare, at de firmaer, som man vælger, dels har spillet det spil på professionelt plan i mange år, og dels ofte har flere advokater end Sauron havde orker. Så det med erstatning bliver sjældent til noget i praksis, uanset hvor galt det går.

Og selv med erstatning, så står man så efter megen tid og arbejde uden en løsning.

Jesper Frimann

Klavs Klavsen skrev:

Og NEJ der findes næsten med 100% sikkerhed IKKE et Open Source projekt der er designet til at drive et hospital.. men det er heller ikke sådan man bør lave et..

Du læste vist ikke Martin Sølvkjær's kommentar.
Der findes et Public Domain system. Det hedder VistA.
https://en.wikipedia.org/wiki/VistA

Og for at gøre tingene værre, så er nogle af de systemer som Sundhedsplatformen erstatter f.eks. GS open (grønt system) jo oprindeligt udviklet af Kommune Data, ALTSÅ DET OFFENTLIGE SELV, men blev trukket ud af Kommune Data af amterne og solgt til CSC tilbage i slutningen af sidste årtusinde.

Altså vi havde et (i det mindste potentielt) landsdækkende system udviklet af det offentlige for vores skattepenge.

// Jesper

Klavs Klavsen

Jeg læste den godt.. Såvidt jeg ved er det skrevet i et programmeringssprog MEGET FÅ kender.. og er det adskildt, så man kan lave sin egen UI - der hvor der kunne være brug for det?

Man skal sikre sig at have udviklere til de sprog man anvender.. og det vigtigste kriterie for et Open Source projekt er hvor mange aktive brugere det har.

Derfor vil jeg mene det er bedre at anvende Open Source frameworks og bygge relevante komponenter - man så kan udvikle som et Open Source projekt.. derved lade de forskellige regioner bruge det (hvis de synes det er brugbart) - og andre lande mv.. og lade det blive formet af dets brugere.

Man skal klart passe på NIH.. men der kan være mange gode grunde til at implementere sin egen løsning.

Jesper Frimann
Klavs Klavsen

Dejligt hvis der findes noget man kan bygge på.. Hvis man er seriøs med det, vil man nok blive nødt til at fork'e - da de har en "enterprise" version - og hvilket desværre ofte betyder at de ikke vil tage imod forbedringer udefra (uden overgivelse af copyright rettigheder ihvertfald).. Men jeg kan tage fejl.. de har trods alt 272 contributors..

Og det er opbygget i et api og en webapp.. Men uagtet er pointen den samme.. finde noget der giver dig friheden til at kunne understøtte dine bruger først og fremmest - og selvfølgelig også gøre det muligt at have styr på borgernes data - så det ikke bliver et sikkerhedsmæssigt hul i jorden.

Ditlev Petersen

Det bringer mindelser om det berømte citat: operationen lykkedes, men patienten døde.

Operationen aflyst, patienten døde. Men til gengæld har vi sparet en masse suturtråd!

Der er alt muligt galt med projektet (og en del andre). Brugerne (med blod og bræk på hænderne) nedvurderes. De skal adlyde, ikke komme med gode ideer.

Jo mindre man ved om emnet, desto mere "uhildede" beslutninger kan man tage. Regneark er gud. Modeller er sandheden.

Og så vil man ikke risikere offentlige penge på noget nyt og uudviklet. Man går uden videre ud fra, at noget eksisterende passer, fungerer og er moderne. Også selv om andres erfaringer peeger på flere problemer.

På den måde undgår man, at vi nogensinde selv udvikler eller bidrager til at udvikle noget, som vi selv kan være glade for og stolte over. Og som måske kan inspirere andre.

Og så viser det sig forresten af og til, at det er meget dyrt at købe noget FOR billigt.

Jesper Frimann

Og det er opbygget i et api og en webapp.. Men uagtet er pointen den samme.. finde noget der giver dig friheden til at kunne understøtte dine bruger først og fremmest - og selvfølgelig også gøre det muligt at have styr på borgernes data - så det ikke bliver et sikkerhedsmæssigt hul i jorden.

Det er vi så slet ikke uenige i :)
Igen så er det tragiske jo, at det offentlige jo ejede en sundhedsplatform, eller måske rettere nogle af komponenterne til en. Så set i den kontekst kunne man jo have brugt det produkt man ejede, som basis for det som du beskriver.

Man solgte forresten platformen og virksomheden bag ved det for, hvad nok har været omkring 300 millioner (eller 400 millioner i nutidskroner). Det skal så ses i lyset af at man har betalt over en milliard for Sundhedsplatformen. Og oven i det skal så lægges projekt omkostninger og tabet i produktivitet.

// Jesper

Torben Mogensen Blogger

Man skal sikre sig at have udviklere til de sprog man anvender..

Når systemet er lukket, betyder sproget ikke noget -- man har alligevel ikke lov til at røre ved koden (og måske endda ikke en gang se den).

Hvis man har adgang til koden og lov til at tilpasse den, så betyder dokumentation langt mere end valget af sprog. En god datalog/softwareingeniør kan på ret kort tid sætte sig ind i et nyt sprog. Det er selvfølgelig lidt nemmere, hvis de fleste kender sproget i forvejen, men det er ikke afgørende, hvis det er betalt arbejde. Det er noget andet med frivilligt arbejde -- der er ikke mange, der vil bidrage til et FOSS projekt, hvis de skal lære et nyt sprog for at gøre det.

Søren Madsen

Først og fremmest, fornemt indlæg - der korrekt påpeger nogle af de nærmest håbløse beslutninger, der bliver taget i den danske stat, så snart det snakken handler om IT-systemer.

Jeg kan dog ikke lade vær med at stille spørgmålstegn ved, at der flere gange gange bliver nævnt, at brugen af Open-source ville have været redningen uden på et eneste tidspunkt at reflektere over risiko-faktoren?

Ja, Open-source vil kunne ændres/tilpasses over tid - alt undervejs kunne derimod gå galt, som det har gjort så mange gange før.

Close-source: Du ved, hvad du vil få - med det mén, at du er bundet af leverandøren.

Uden at kende til de bagvedliggende beslutninger, kunne det så tænkes, at de på baggrund af andre falliterklærede IT-systemer har valgt et close-source system netop for at minimere risikoen for endnu en IT-fiasko?

Klavs Klavsen

De IT fiaskoer jeg har set - har alle bygget på COTS tankegangen (dvs. køb et 'hyldeprodukt' og juster det til ens behov).. Har du set nogen der byggede på open source?

Jeg savner kraftigt at man blev tvunget til at lære af sine fejl.. ie. find nogle metoder der fungerer og tving nye projekter til at anvende dem.. hint hint IT havarikomission..

Ivo Santos

Et af problemer med lukkede systemer er at de kan være kodet til et system, som efter f.eks. fem år er forældet, og derfor skal kodes om eller rettes til sådan at det virker med næste version af det pågældende system, som f.eks. det er tilfældet med .net.

Et system som f.eks. et sundhed platform burde egentlig være designet således at patientdelen er for sig, betalingsdel for sig, og en behandlingsdel for sig selv. Havde det være designet på den måde ville det måske også have været nemmere at implementere.

Jeg tænker her på at behandlings delen nok ikke er meget forskelligt fra land til land, så den del burde være nogenlunde ret nem.

Patientdelen er en anden sag, da den del kan være meget forskellig fra land til land, der findes trods alt ikke mange lande som har et egentlig CPR nummer, eller blot et personlig nummer.

Betalingsdelen er nok også noget som forskelligt fra land til land på grund af at lovene er anderledes, og i nogle lande er det måske kun en lille del af regningen som staten betaler, og resten skal patienten selv betale.

En fordel ved et åbent systen er at det til dels er nemmere at vedligeholde og måske kan man få det til at virke i mange år i forhold til et lukket system som måske kræver at man skifter hardwaren ud noget oftere fordi man absolut skal skifte til et andet operativ system som naturligvis kræver at man skifter hele serverparken ud med en anden.

Anders Melander

Jeg kan kun tilslutte mig horden af folk, der aner endnu en IT katastrofe i horisonten, men selvom jeg også mener at Open-Source ville være en god ide, er jeg ikke sikker på at VistA er løsningen.

VistA er nemlig ligesom EPIC skrevet i MUMPS - et proceduralt sprog der blev født i 60'erne og ikke har flyttet sig meget siden. Det er stadig proceduralt og det er stadig normen at skrive alt i uppercase (variable skal vistnok være uppercase, max 6 chars). Jeg har aldrig mødt en MUMPS-udvikler, men efter sigende er der på verdensplan "flere tusinde" der programmerer i det...

Prøv lige at kigge på en tilfældig source-fil i VistA projektet. Velkommen tilbage til 70'erne!

Men hvorfor er det relevant, hvilket sprog et system er skrevet i? Fordi det for MUMPS vedkommende vil begrænse den talentmasse, der kan eller vil arbejde på systemet. Det er også kraftigt begrænsende for de teknologier og metoder der kan benyttes. Vi er trods alt blevet en hel del bedre til at skrue tingene sammen siden MUMPS blev designet.

Torben Mogensen Blogger

MUMPS - et proceduralt sprog der blev født i 60'erne og ikke har flyttet sig meget siden.

Det er nu ikke helt korrekt. Den seneste standard er fra 1995. Der er ganske rigtigt ikke tilføjet klasser, objekter, og lignende, som ellers er sket med de fleste sprog fra 1960'erne, men det er ikke nødvendigvis en ulempe. Til sikkerhedskritiske systemer er der en pointe i at holde sproget enkelt. Og MUMPS' tætte integration til persistent storage er en god feature for den slags systemer, som det bruges til.

Ikke dermed sagt, at MUMPS er uden problemer: Der er f.eks. ikke noget statisk typesystem, og muligheden for at have variabler med samme navn som nøgleord, og at nøgleord kan forkortes til et enkelt bogstav, kan gøre koden svær at læse. Det sidste er dog ikke værre end at et automatisk værktøj kan ekspandere alle nøgleord til deres fulde længde og bruge farver (eller fed tekst) til at markere nøgleord, så de adskilles tydeligt fra variabler.

Niels-Arne Nørgaard Knudsen

Hvis jeg havde magt som jeg havde akt med hensyn til statslig it her i landet så ville jeg starte med at finde nogle ligesindede og bare blive enige om at erklære den måde det foregår på nu for highway to hell!

Jeg ville nedsætte et it råd bestående af en styregruppe der som de eneste har beslutningsmagt når det kommer til statslig it. Derudover skal rådet have faste eksperter og mulighed for at hyre ekstern rådgivning. Om dette råd skal være et selvstændigt ministerie med egen minister eller et statsligt organ udenfor den politiske arena er der argumenter for og imod.

Ved et selvstændigt ministerie er der et tættere parløb med regeringen (det er jo en del af samme) hvor det ved et konsortium er udenfor politik da chefen ikke skiftes ved hver ny regering. Afvejningen er altså kortere vej til magten eller højere grad af kontinuitet.

Borgerens data. Vi leverer alle til statens data opsamling. Når vi går til lægen, i skole, trafiktællinger, straffeattester, pas-billeder og så videre.

Vi kan lige så godt omdefinere begrebet cpr-nummer. Det er ikke noget der er hemmeligt og det kan ikke bruges til autentikering men kun identifikation. Altså at cpr-nummeret er en offentlig nøgle man bruger som id i systemerne.

Vi har ingen kontrol over de data. Overhovedet. Når først staten har fået dem er det ude af vores hænder, akkurat som Facebook og Google (som nogle politikere er efter netop omkring privatliv og databeskyttelse). Der skal skabes et udvekslings interface der håndterer data udveksling med andre systemer. Dette er en form for personlig datawall under den enkelte borgers kontrol. Her kan folk vælge om deres data må deles med andre, for eksempel til forskning, statistik og analyser. Dette er overordnet da der er mange ting ind over: nogle vil gerne donere data til kræftforskning men kunne aldrig
drømme om at levere noget som helst til private analyse institutter, andre igen vil sige intet skal deles og nogle vil sige bare tag løs. Faktisk skal borgeren som minimum have mulighed for at data kun deles anonymt og at deres data ikke forlader landets grænser. Begge dele vil give udfordringer. Kun anonym deling kræver at der laves en form for hashing eller scrambling af data således at den enkelte ikke entydigt kan identificeres (dette er ekstremt svært når man har data nok om den enkelte) og ved ikke at tillade data forlader landets grænser kan man afskære sig fra lægeundersøgelser ved hjælp af for eksempel IBM Watson.

En kategori bør være adskilt fra de andre: udvikling af statslige it systemer. Her bør man kunne vælge om man ønsker at ens data bruges i test af statslige it systemer. Man bør også kunne vælge at det kun må ske anonymt. Dette kan løses ved at alle der ønsker anonymitet får deres data byttet om, efternavne, cpr-numre, adresse, ja alle felter. En gang om måneden kan man køre en scramble algoritme på test-data der gør det sværere at identificere den enkelte (faktisk noget nær umuligt).

Når det kommer til udvikling kan enkelte virksomheder udpeges som statslige udviklere hvilket betyder at de får ansvar for at udvikle en standard løsning der skal være dækkende for opgaven.

For eksempel at lægen både har adgang til patientjournal og receptsystem. den nemmeste løsning er nok en vpn og et webbaseret bruger interface da det så vil kunne køre på stort set alle enheder. Alle de projekter statslige udviklere laver skal være open source. Grunden til at jeg ønsker både statslige og private udviklere er ganske simpel: når man har statslige udviklere kan man ganske enkelt sætte en standard. Helt ærligt hvem betaler for et produkt når den statslige open source udgave er milevidt bedre?

En statslig udvikler kan sagtens udvikle private løsninger med ekstra funktionalitet. Derfor skal grund løsningen være open source da det ellers vil give en uhensigtsmæssig skævvridning overfor små udviklere der til gengæld kan specialisere sig indenfor nicher.

Der skabes altså et fælles api alle kan benytte. Det vil være klogt at bruge små objekter der kan en ting men til gengæld kan det rigtig godt. Der laves en analyse af opgaver og så udvikles det som små atomare systemer der trækker på samme datakilder. Med hensyn til gui så kan man samle de enkelte undersider i for eksempel læge-main.aspx, addresse-main.html eller hvad der nu dukker op.

Dette vil sikre bedre integration systemerne imellem. Data udveksling er ultra vigtigt i dag, derfor skal der fastsættes sikkerhedskriterier der skal overholdes før et stykke software kan godkendes. Denne godkendelse fås hos styregruppen.

Det vil være dumt at låse sig fast på bestemte sprog da man givetvis afskærer sig selv fra en bedre delløsning. Et sprog er ikke bedst til alt og det bør udnyttes. Desuden giver det større muligheder for at få udviklet noget der sparker røv i den private sektor.

Meget tidlig indragelse af brugere og borgere i udviklingsfasen. Et stykke papir og en blyant og et par timer med en medarbejder fra skat vil nok give større chance for succes når man udvikler løsningen.

Og så en meget vigtig funktion - måske den vigtigste, nemlig funktionen til at terminere et projekt der er kørt af sporet. we're creating a monster - kill it! kill it! Destroy!

Henrik Eiriksson

Læs her og gys!
https://en.wikipedia.org/wiki/MUMPS#Summary_of_key_language_features

F.eks.

There is one universal datatype, which is implicitly coerced to string, integer, or floating-point datatypes as context requires.

eller

All variables are dynamically created at the first time a value is assigned..

eller

Since MUMPS interprets source code by context, there is no need for reserved words. You may use the names of language commands as variables.

(indsæt billede af "skriget" her)

Log ind eller Opret konto for at kommentere