Konsulent om stort EPJ-udbud i Region Syddanmark: »Det er præget af stor uvidenhed«

Et stort udbud fra Region Syddanmark af et system til elektroniske patientjournaler kalder på panderynker og kritiske kommentarer fra en konsulent med mange års erfaring i systemadministration og it-arkitektur.

Version2 har tidligere omtalt, at Region Syddanmark har besluttet at droppe deres nuværende EPJ-system Cosmic, bl.a. fordi man ikke ville acceptere, at leverandøren havde eneadgang til kildekoden og derfor fortsat havde monopol på at servicere og vedligeholde systemet.

Derfor er man i gang med at anskaffe et nyt EPJ/Patientadministrativt System (PAS).

Formålet er ifølge regionens udbudsmateriale 'at anskaffe en løsning, der leverer effektiv, patientsikker, hurtig og brugervenlig it-understøttelse af arbejdsgange.'

I første omgang ønsker regionen en såkaldt markedsdialog, hvor man vil invitere EPJ-leverandørerne til bl.a. at fortælle om deres systemers kernefunktioner, hvordan de kan implementeres og hvordan en kravspecifikation kan indrettes.

Samtidig melder Region Syddanmark ud, at man ønsker en standardløsning, hvilket ikke nødvendigvis betyder, at den alene består af standardprogrammel, men en løsning som allerede er i drift. Regionen skriver, at man vil ’undgå de risici, der er forbundet med et udviklingsprojekt.’

Klavs Klavsen, der er selvstændig konsulent, udvikler og datamatiker advarer imidlertid imod standardsystemer. For de færreste vil reelt indrette sig efter et standard it-system. For det første tror han ikke på, at der findes et perfekt standard-EPJ system. For EPJ-problematikkerne er ikke løst endnu.

For det andet vil et standardsystem erfaringsmæssigt kræve langt mere udvikling af organisationen for at passe til systemets arbejdsflows end man er klar til:

»I princippet ville det være super godt, hvis man kunne finde et standardsystem der præcis er konstrueret til ens behov. Men problemet er, at det er løsningerne aldrig. Erfaringen viser, at regionerne altid gør tingene på deres egen måde - og at man ikke er villig til at indrette arbejdsgangene til et standardsystem,« siger han.

Det betyder, at selv standardsystemer bliver ændret til ens behov.

»Og så er det, at det går galt. Man får det værste af begge verdener,« siger Klavs Klavsen.

Problemet er, at man i den situation vrider standardsystemet til at tjene et formål på en måde, som ikke fungerer, siger han.

»Enten er det meget svært, hvis man vil tilføje en feature til et klassisk standardsystem - eller det ender dårligt. Det bør man holde sig fra,« siger han og tilføjer, at konsekvensen kan blive langsomt system eller et, der ikke hænger sammen.

Rent økonomisk bliver problemet også, at ofte har kunden kun brug for en lille del af det som et standardsystem kan, men betaler for hele pakken. Og man får samtidig alle de begrænsninger og bindinger, som et standardsystem giver.

»Hvis man udvikler på et standardsystem bliver det din egen specifikke kode og version. Og erfaringen viser at det vil ingen tage ansvar for, med mindre de får dyr særskilt betaling for det,« siger han.

Del op og gå open source-vejen

Klavs Klavsen anbefaler i stedet, at ved et behov for it til et specielt behov - hvilket stort set alt er i dag - er det meget bedre at bygge løsninger af komponenter, som man baserer så meget som muligt på Open Source-baserede komponenter - libraries eller færdige komponenter.

»Det er min erfaring, at det altid vil blive billigere at udvikle i mindre afgrænsede kompetencer. Det gælder især for større projekter, hvor man undgår de situationer, hvor man skal smide f.eks. 10 års udvikling væk, fordi man ikke kan blive enige om det videre forløb,« siger han.

Men desværre lægger materialet fra Region Syddanmark ikke op til et komponentopdelt udbud, anfører han.

»Regionen ved tydeligvis for lidt om, hvad der fungerer. Man vil det hele på én gang, og intet er opdelt i logiske bidder. Man beder om at få skåret en elefant op – men hvis man ikke kender elefanten, ved man jo ikke, hvor man skal skære,« siger han.

En forklaring kan være, at man vil spare på antallet af udbud, fordi det er en dyr proces.

»Derfor går man ud med et kæmpe udbud, som omfatter alt mellem himmel og jord. Men man får en monolit,« siger han.

Kæmpeudbuddet burde have været opdelt i moduler, der hver for sig giver forretningsmæssigt mening – og her tage interne udviklere og arkitekter med på råd med sparring fra kompetent hjælp udefra, tilføjer Klavs Klavsen.

Et yderligere krav om at benytte eksisterende Open Source-komponenter - og at ændringer til disse skal sendes til 'upstream' - vil ifølge ham endvidere øge sandsynligheden for at ændringer og udviklinger kun bliver godkendt, hvis de er gode nok. Man distribuerer med andre ord ansvaret for kvalitet i systemudviklingen til et kollektiv.

»Ved Open Source skal andre også kunne bruge komponenten eller videreudviklingen, og hvis den ikke rummer en tilstrækkelig kvalitet, så bliver den ikke godkendt. Det sikrer en grundig videreudvikling,« siger han.

Byg microservices på standard frameworks

Klavs Klavsen medgiver, at der ikke findes fulde open source-baserede EPJ-systemer og derfor skal man dele sin forretningsbehov op i enheder, som der findes komponenter – microservices - til at understøtte.

Microservices indbærer, at hver funktionalitet er splittet op i sin egen lille miniapplikation med åbent API.

»Du kan muligvis finde noget - men definitionen, som ligger bag eksisterende moduler, af hvad EPJ har behov for af funktionalitet, sikkerhed mm. er højst sandsynligt væsentligt forskelligt fra hvad Region Syddanmark har behov for.«

Derfor bør man ifølge ham gå et eller to skridt under det niveau.

F.eks. analysere ens behov og lave (mikro)services, der implementerer de forskellige datamæssige områder - patientdata i ét system, lokaleinformation og booking i et andet og koncentrere sig om at finde udbredte og passende standarder til ens API'er og protokoller.

Hver af disse microservices kan ifølge ham nemt bygges, baseret på standard frameworks til en REST service - som PHP SLIM eller Falcon - og det kan endvidere nemt ensrettes så andre kan bygge deres service på et fælles setup med exceptions, logningshåndtering mm.

»Der er i dag rigtig meget Open Source kode som man kan anvende, og som gør det til en væsentligt nemmere sag at udvikle større systemer, når man har lavet sit forarbejde ordentligt,« siger Klavs Klavsen.

Fordi hver service er uafhængig af den næste, kan udviklingsholdet opdatere tjenesten uden at påvirke det øvrige system - så længe aftalen om API'et overholdes.

Samtidig opnår man ifølge Klavs Klavsen, at forretningskrav, dvs. krav til funktionalitet, adskilles fra krav til brugergrænseflade. Det betyder, at forskellige personalegrupper med særlige behov for, hvordan deres skærm skal se ud kan få det uden at det kræver et særskilt system.

Se udbudsbekendtgørelsen her.