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

Region Syddanmark skal have nyt EPJ-system. Men ideen om standard er dømt at til mislykkedes. Gå i stedet efter Open Source microservices, lyder opfordringen.

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.

Læs også: Hospitalschef efter EPJ-forhandlingsbrud: Nej til flere udviklingsprojekter hos os

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.

Læs også: Træt af it-monolitten? Prøv en microservice

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.

Læs også: Slip for VM's og containere: Serverless-arkitektur skærer alt andet end kode væk

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.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Petersen

...meget før ørerne falder af.

Jeg synes det kunne være interessant, hvis Version2 faktisk spurgte en, der vidste noget (også om domænet) det samme spørgsmål. Så kunne Klavs Klavsen berette andre steder, om den bog om referferencearkitektur, han lige har læst om.

Anders Andersen

Gode argumenter Klavs her kommer med

Det er vigtigt at indkøberne af et system forstår at man ikke kan indkøbe et system til det hele.
EPJ - Elektronisk Patient Journal
ERP - Enterprise Resource Planning
CDS - Cancer Diagnostic System ?
XAS - Xray Archive System ?
HDT - Home Disease Treatment?
... find selv på flere ...
Sundhedssystemerne vil udvikle sig helt uden sidestykke nu og i fremtiden

Derfor kan det være en rigtig dårlig ide at tro at man kan indkøbe et system der kan det hele. Et sådant system vil være forældet ....
Jeg nævner EJP og ERP - som er det to systemer der faktisk eksisterer i nuværende begrebs-verden. Og det er for at vi ikke kommer til at blande dem sammen. Hvad jeg er en del bekymret for at man gør idag.

Klavs Klavsen

Lige for at sikre mig at ingen er af den opfattelse at jeg tror jeg har opfundet noget!
Alt det jeg siger - er gammel vin på nye flasker. "microservices" og "agile" - er jo ting der har været kendt og skrevet om siden 70'erne. Jeg kan kun konkludere at dem der igen og igen vælger IKKE at følge de erfaringer man allerede dengang har gjort sig om den slags "alt i et" kæmpe systemer, både mht. udviklingen af dem og den manglende fleksibilitet de giver (læs "The mythical man month") - IKKE er fagfolk. De kalder sig måske IT "et eller andet" - men de viser tydeligt at de IKKE interesserer sig for den erfaring andre indenfor faget har draget sig over de sidste 50 år :(

Log ind eller Opret konto for at kommentere