Har Sundhedsplatformen fåresyge?

Der har i de seneste dage været en del diskussion om Sundhedsplatformen.

Dels har Kristian Tørnings gæsteblog kritiseret, at systemet er proprietært, hvilket binder regionen til leverandøren, og at systemet er kodet i et relativt ukendt sprog kaldet MUMPS, hvilket gør det svært at finde udviklere.

Andre steder (bl.a. i Radio 24/7 her til morgen) har Sundhedsplatformen været kritiseret for at være bygget på en forældet kerne. Sundhedsplatformen er bygget på systemet EPIC fra et Winsconsinbaseret firma af samme navn, og bygger på databasesystemet Caché fra InterSystems. Caché databasen er oprindeligt udviklet i 1997, men er løbende blevet opdateret.

Jeg kender ikke arkitekturen i EPIC og Caché, og arkitektur er heller ikke mit resortområde, så jeg vil ikke kommentere yderligere på denne, udover at nævne at min kollega Jørgen Bansler har udtrykt bekymringer om platformen, men mestendels fordi den er bygget til det amerikanske sundhedssystem og kun besværligt lader sig tilpasse det danske.

MUMPS er ikke meget ældre end C

Jeg vil dog snakke lidt om programmeringssproget, da sprog er mit område.

Caché og EPIC er begge skrevet i programmeringssproget MUMPS. MUMPS blev oprindeligt udviklet i 1966-1967 på Massachusetts General Hospital, og navnet er en forkortelse for "Massachusetts General Hospital Utility Multi-Programming System", men forkortelsen er sikkert også valgt fordi "mumps" på engelsk betyder "fåresyge".

MUMPS er sidenhen blevet videreudviklet, og den seneste ANSI standard er fra 1995 (og godkendt af ISO i 1999 og igen i 2010).

Der findes Open-Source implementeringer af MUMPS, der kan køre på f.eks. Raspberry Pi. Sproget er altså ikke væsentligt ældre end f.eks. C, som bliver flittigt brugt, så alderen alene burde ikke være en hindring for at bruge det.

Men er der andre ting, der taler for eller imod brug af MUMPS til Sundhedsplatformen?

MUMPS er designet omkring en hierarkisk database, og variable med "^" som præfiks er persistente i databasen, og vil være tilgængelige for alle programmer, der deler denne database. Semantikken er transaktionssikker (ACID), så systemer skrevet i MUMPS er generelt robuste.

Datatyper i MUMPS er strings og multidimensionale arrays, som bruger vilkårlige værdier som indices. Det minder på den måde lidt om LUA, som også bruger associative arrays som primær datastruktur. Forskellen er primært, at arrays i MUMPS kan være persistente, og at tal repræsenteres som strings.

MUMPS er et imperativt sprog, og har procedurer/funktioner med argumenter og resultatværdier, men ikke mere moderne faciliteter såsom objekter eller funktionelle værdier. Ikke-persistente variabler bruger dynamiske virkefelter (dynamic scoping). Persistente variabler er globale (også på tværs af programmer).

Simpelt men kan være en fordel

MUMPS er alt i alt et relativt simpelt programmeringssprog, men det er ikke nødvendigvis en ulempe. Til kritiske systemer kan det være en fordel, at det er meget klart, hvad der sker (hvilket det ikke altid er, når man kalder virtuelle metoder eller funktionsparametre). MUMPS har dog nogle særheder:

1. Nøgleord kan forkortes helt ned til enkelte bogstaver. Det skyldes, at MUMPS oprindeligt kørte fortolket og på ret små systemer, men det kan gøre koden svær at læse.

2. Variabler kan have samme navn som nøgleord. Konteksten gør det klart, om noget er en variabel eller et nøgleord, men det kan igen gøre det svært at læse programmer.

3. Det er muligt at bygge MUMPS-kode i en string, og bagefter udføre denne. Det kan bruges som erstatning for funktionelle parametre, men det kan gøre det svært at forstå programmer.

4. Der er ikke noget statisk typesystem, så typefejl findes først under afprøvning.

5. Dynamiske virkefelter kan også gøre det vanskeligt at følge programlogik.

De to første særheder kan håndteres ved hjælp af automatiske værktøjer, der ekspanderer nøgleord og markerer dem med fed skrift eller farve, så de er nemme at adskille fra variabler. De tre sidste kræver disciplin i programmeringen af systemer, da de ellers kan give anledning til fejl, der er svære at finde.

Er MUMPS så et godt eller skidt sprog til formålet? Det har både gode og dårlige sider, men alt i alt kunne det have været meget værre. Det er ikke voldsomt svært at lære at programmere i MUMPS, og de persistente variabler gør programmering op mod en hierarkisk database nemt og relativt robust. På minussiden kræver de dynamiske egenskaber (scoping, typer og kodeeksekvering) mere disciplin omkring kodestil og afprøvning.

Men umiddelbart er min fornemmelse, at MUMPS ikke er en væsentlig årsag til, at Sundhedsplatformen har problemer. Det skyldes nærmere systemets opbygning og licensbetingelser, samt at processen omkring tilpasning til det danske sundhedssystem og ibrugtagelse har været uigennemtænkt.