Kronik: Fem fejlslutninger og nøgne kendsgerninger om Sundhedsplatformen

Jan Kold er vicedirektør i NNIT, som er underleverandør på opgaven med at levere Sundhedsplatformen til alle hospitaler i Region Hovedstaden og Region Sjælland.

Det er ikke småting, Sundhedsplatformen har på samvittigheden, hvis man skal dømme ud fra debatten. Som uddannet ingeniør med ti års erfaring som it-leder i det offentlige sundhedssystem og syv år som leverandør til det offentlige, ser jeg på den meget følelsesladede debat om Sundhedsplatformen med en vis forbløffelse.

Titanic… virkelig? Jeg er i daglig kontakt med slutbrugere, og der ER problemer, det vil der altid være på et så ambitiøst projekt. Men mens vi graver os gennem stakken, møder jeg heldigvis også mange, der udtrykker stigende tilfredshed.

For er par uger siden deltog jeg i et interview, som blev bragt i Ingeniøren og Version2. Jeg tog bladet fra munden, fordi jeg synes, det er vigtigt, at debatten inkluderer perspektiver fra it-fagfolk, med konkret erfaring og indsigt i Sundhedsplatformen.

Dette synspunkt har jeg siden fået bekræftet af de kommentarer, der fulgte i kølvandet på interviewet. Med dette bidrag tager jeg fat i fem af de hyppigst forekommende fejlslutninger. Min gennemgang bliver ikke udtømmende, men denne håndfuld går igen.

Fejlslutning nummer 1: Sundhedsplatformen er bygget til det amerikanske sundhedssystem og er ikke tilpasset danske forhold. Rigtigt, og forkert. Epic er ganske rigtigt udviklet i USA og er ligesom Watson og mange andre baneførende løsninger blevet importeret fra udlandet. Det er en fleksibel platform, der anvendes i 11 lande, som deler best practice på tværs, men som stadig giver plads til lokale tilpasninger.

I Danmark importerer vi ikke løsningerne ukritisk; de skal selvfølgelig tilpasses hverdagen på hospitalerne herhjemme, og Epic lever således op til flere end 3.500 danske kravspecifikationer.

Flere end 500 klinikere har været involveret i valget af Epic, og flere end 500 klinikere har været involveret i såvel workflowet som i designet af indhold, og de forbliver involveret i aktiv optimering af systemet.

Arbejdet med tilpasningen pågår stadig, og nogle områder har naturligvis været mindre komplicerede end dem med meget komplekse behandlingsforløb. Vi bliver aldrig bliver færdige, for systemet skal vedvarende tilpasses nye behandlinger og forbedrede patientforløb.

Fejlslutning nr. 2: Sundhedsplatformen bygger på en antikveret database-struktur og kan ikke kommunikere med moderne databaser. Denne påstand bliver nærmest falsificeret hvert eneste sekund, når Epic verden over udveksler data på åbne standardsystemer såsom Medcom, HL7 og FHIR.

I Danmark integrerer Sundhedsplatformen med FMK, MedCom, Sundhed.dk, NemID, Nem SMS og 13 nationale databaser.

Sundhedsplatformen har siden sin første go-live udvekslet flere end 140 millioner beskeder med andre systemer. Herudover er Sundhedsplatformen integreret med medical devices såsom EKG-apparater og intensive monitoreringer, hvilket sparer sundhedspersonalet for tid, fordi vi hermed undgår papirdokumentation, der bagefter skal tastes ind.

Tæller man disse integrationer med, ser vi over 300 millioner beskeder udvekslet med andre systemer. Epic er installeret hos mange af verdens mest respekterede og innovative sundhedsinstitutioner og universitetshospitaler, som netop er anerkendt for deres brug af teknologi, herunder Duke, Mayo Clinic, Stanford, Yale, Cambridge, AMC-VU og Hovedstadsregionen.

Epic er oppe på 76 procent af alle amerikanske hospitaler, der er nået til det anerkendte såkaldte HIMSS Stage 7, som er den mest anerkendte, internationale måde at måle graden af digitalisering på hospitaler.

Fejlslutning nummer 3: Systemet ignorerer brugertilfredshed. Denne påstand er i bedste fald et gæt, der rammer helt uden for skiven. Epic er installeret på cirka 1.100 hospitaler og forbedres til stadighed i samarbejde med klinikere verden over.

Gennem mine ti år som it-leder i det offentlige sundhedsvæsen har jeg aldrig tidligere mødt en leverandør, som arbejder så stædigt og vedholdende med at optimere systemet i samarbejde med slutbrugere.

Bevares, der begås fejl, og afdelinger kan med rette opleve, at de er blevet overset, imens holdet arbejder sig gennem stakkene, men deres tid kommer.

Der sker hele tiden forbedringer, som eksempelvis beskrevet i Version 2.

Fejlslutning nummer 4: Amerikanske læger er generelt utilfredse med systemet, herunder med behovet for mange klik. Det er simpelthen blevet en åndssvag vandrehistorie, som savner hold i virkeligheden og ingenlunde kan dokumenteres.

Se på verdens førende analytiker inden for sundheds-it, KLAS, som rådigiver sundhedsmyndigheder verden over med undersøgelser og evalueringer af sundheds-it software og –services: På deres lister rangerer Epic på syvende år i træk som ‘Overall Best Software Suite', og de specifikke moduler vinder hele tiden priser i konkurrence med andre leverandører.

Ifølge KLAS viser et studie, som inkluderer flere end 12.000 læger, at de, som anvender Epic, svarer to gange mere positivt end læger, som arbejder med andre systemer. Dette tal var endda endnu højere for organisationer, som benytter sig af kliniske byggere, (det vil sige læger, der er trænet til at lave standardopsætninger til deres specialer), hvilket Region Hovedstaden og Region Sjælland også gør.

Fejlslutning nummer 5: Epic er genstand for hård og vedvarende kritik i udlandet.

Flere danske medier og debattører har refereret rygter om, at læger i andre lande er utilfredse med Epic. Dem findes der garanteret rigtig nok nogen af, og medierne refererer konkret til den samme håndfuld af organisationer, som har været beskrevet i udenlandske medier.

Vi taler altså om færre end ti eksempler på høj utilfredshed: Epic er installeret på flere end 1.100 hospitaler verden over. Et af de hospitaler er Cambridge University Hospital, som er belønnet med adskillige priser for sin innovative brug af it, herunder det mest ‘wired’ hospital i verden, jf. denne artikel.

Mit håb er, at fejlslutningerne over tid kan korrigeres med nøgne kendsgerninger og konkrete erfaringer fra hospitalsgangene.

Det betyder ikke, at Sundhedsplatformen bliver fejlfrit og problemløst, men vi kan forhåbentlig fokusere på at få platformen til at fungere bedre og bedre i hverdagen på en meningsfuld måde for medarbejdere og patienter, så vi med tiden får realiseret de vigtige visioner, der har drevet beslutningstagningen i regionerne.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (17)
Anne-Marie Krogsbøll

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

https://ugm.epic.com/

Er det muligt at få svar på følgende:
1) Hvad er meningen med disse verdensomspændende UserGroupMeetings?
2) Er det virkeligt nødvendigt at sende 56 personer af sted, med en samlet udgift på ca. 1,2 millioner og over 1 årsværk?
3) Var der derudover udgifter til forplejning i en uge?
4) Hvad har det konkrete udbytte været af deltagelse på dette års UserGroupMeeting?
5) Har repræsentanter for Region Hovedstaden og Sundhedsplatformen givet oplæg på arrangementet? I givet fald om hvad?
6) UserGroupMeeting er en årligt tilbagevendende begivenhed. Er det tanken (evt. en del af kontrakten), at der fremover i lignende omfang skal deltage repræsentanter fra Sundhedsplatformen og regionen?
7) Er det en del af budgettet for Sundhedsplatformen, eller går det på et andet budget?

Jesper Frimann

Så er der vist dømt marketing og spin, og der skal laves noget CMA.

Fejlslutning nummer 1: Sundhedsplatformen er bygget til det amerikanske sundhedssystem og er ikke tilpasset danske forhold.

Øh. Det var vist lidt at skyde sig selv i benet. Det at der er brugt så meget tid på tilpasninger, underbygger jo netop påstanden om, at sundhedsplatformen ikke er udviklet til danske forhold men til amerikanske forhold. Og det faktum at Jan Kold skriver om, hvor meget tid og hvor mange kræfter, der er brugt på at tilpasse systemet, underbygger jo netop at EPIC, som 'standard system' ikke 'out of the box' har passet til danske forhold. Så rent 'teknisk' har Sundhedsplatformen, ligesom andre standard systemer, skulle tilpasses til hvordan de lokale arbejdsgange er.
Man kan så snakke om i hvor høj grad det har påvirket implementeringen, at arbejdsgange, procedurer og kultur har været pænt forskellige fra hospital til hospital inden for samme region.
Desuden har Sundhedsplatformen ikke understøttet dansk talegenkendelse, hvilket jo.. ja..
Men jeg er da helt enig i at Teknisk så passer EPIC lige så godt til Danske forhold som så mange andre systemer.

Men når jeg personligt har sagt at implementeringen af EPIC nok passede dårligt til Danske forhold, så var det rent forretnings mæssigt, set i lyset af hvordan vi som befolkning gerne vil have at sundhedsvæsnet skal fungere. (Effektivt og billigt)
Så når jeg skriver danske forhold, så mener jeg hvordan arbejdsgange, virksomhedskultur og mindsæt på hospitalerne har været traditionelt.

Jeg er helt med på, at politikerne i Danmark gerne vil køre sundhedssystemet, som om det var en privat virksomhed, hvor sundhedssystemet i regionerne fakturerer hinanden og staten for de ydelser de leverer. Og dette passer meget godt med den amerikanske model, hvor sundheds systemet i høj grad består af private enheder, der så fakturerer forsikring selskaber, som så delvist f.eks. kan fakturere videre til staten. Så systemet passer jo Glimrende til hvad politikerne gerne vil. Problemet med det er bare at det er HAMRENDE ineffektivt, det amerikanske sundhedssystem rangerer konstant i bunden når det kommer til effektivitet (læses som ydelse per cost unit (f.eks. er bruges der i USA x2 på sundhedssystemet i forhold til et land som Sverige).
Og det er ikke det som borgerne og sundhedspersonalet gerne vil. Vi ønsker, at sundhedsvæsnet skal køre som en forretning, der skal tjene penge på vores dårligdomme.

Hvis man endelig skal bruge en 'privat virksomheds' model for hvad sundhedsvæsnet er, så er det et fagligt komplekst 'cost center' med en forretnings mæssig ROI horisont, der regnes i årtier.
Og det er noget ganske andet...

Lad mig forklare det med et eksempel. I et sundhedssystem, hvor der politisk er et fokus på produktion og fakturering, der vil sådan noget som forebyggende behandling jo være 'counter productive', for forebyggende behandling er jo typisk både billigere og giver mulighed for mindre fremadrettet fakturering.

Fejlslutning nr. 2:Sundhedsplatformen bygger på en antikveret database-struktur og kan ikke kommunikere med moderne databaser.

EPIC bruger en proprietær database/patient journal, og der har været problemer med integrationen med de centrale sundheds databaser.
Og man har i regionen lavet et 'buy in' på ideen med et fuldt integreret system.

Så ja.. det er der ikke så meget at sige til, det er jo sådan set ikke selve systemet skyld at:

Man i Danmark har fejlet med at lave et standard patient journal format/system (GEPJ blev skrottet i 2006).
At man har haft så travlt i sundhedsplatform projektet at integrationerne har lidt under det.

Fejlslutning nummer 3: Systemet ignorerer brugertilfredshed.

Det er jo ikke systemet.. men projektet skyld. Og ja.. det som Jan Kold skriver, er jo IMHO en indrømmelse af at projektet har grebet udrulningen forkert an.

Fejlslutning nummer 4: Amerikanske læger er generelt utilfredse med systemet, herunder med behovet for mange klik.

Det er jo for at sige det lige ud irrelevant. Det er IMHO ret ligegyldigt hvad amerikanske læger synes. Det er jo hvad de danske læger synes. Igen så er (eller den burde være) den danske sundhedsforretnings virkelighed være væsentlig anderledes end den danske (et hovedsaglig privat sundhedssystem kontra et offentligt sundhedssystem). Og kulturen er meget forskellig. Desuden har amerikanske læger for det meste folk til at 'klikke for sig'.

Fejlslutning nummer 5: Epic er genstand for hård og vedvarende kritik i udlandet.

Who cares, det er IMHO total irrelevant nu.

// Jesper

Anne-Marie Krogsbøll

Jesper Springer:
Det er muligt, at du har ret - det er derfor jeg spørger - hvad er der helt konkret kommet ud af det? Hvad er tanken med det? På hvilken måde bidrager denne deltagelse til noget positivt i dagligdagen på regionens sygehuse?

Jesper Frimanns indlæg opridser noget af det, der gør mig bekymret: De meget forskellige måder, sundhedsvæsner er indrettet på rundt om i verden. Når jeg ser UGM's hjemmeside, og læser kommunikationsdirektørens indlæg, så er der nærmest noget sekterisk over det, og det bekymrer mig. "Vi er alle en stor familie". Men er vi det? Ønsker vi at være en del af den meget store - hovedsageligt amerikanske - UG-familie under Epics paraply?

Er UGM i virkeligheden en måde at "nurse" en fælles forståelse af, hvordan man skal indrette et sundhedsvæsen - på den amerikanske måde? Er det dybest set et smart reklamefremstød for Epic?

Eller får man faktisk noget konkret brugbart med hjem for de 1,2 millioner og mere end et årsværk, som man trækker ud af det i forvejen udpinte sundhedssystem i Region Hovedstaden? Og får man noget med hjem, som man ikke kunnet have fået via kurser og dialog med Epic herhjemme fra?

Det er muligt, at min mistanke er ubegrundet - det må vi håbe. Forhåbentlig kommer der et brugbart svar...

og som modvægt til Jan Kolds synsvinkel: http://politiken.dk/debat/debatindlaeg/art6176718/Paranoide-amerikanske-...

Anne-Marie Krogsbøll

Ad: Fejlslutning nummer 1: Flere end 500 klinikere har været involveret i valget af Epic.....
Ja, de var vist involverede. Var det ikke dem der fravalgte Epic ?!?


Ja, det var vist et eksempel på dygtigt spin fra Kolds side. Bortset fra, at ingen her hopper på det pga. Version2's dækning af forløbet :-) Men måske virker det andre steder?

I øvrigt anvender Epic, i følge lægens debatindlæg ovenfor, Mumps som programmeringssprog:
https://thedailywtf.com/articles/A_Case_of_the_MUMPS

Søren Neermark

Fint at Jan Kold nu svarer på nogen af de kommentarer, som har været i forbindelse med SP. Men svarerne er så ukonkrete, og i visse tilfælde forkerte, at det må være på sin plads lige at hjælpe Jan Kold med et par præciseringer.

(Fejl)slutning 1 (beslutning og kravsspecifikationer):
Det er korrekt at 500 klinikere var med til at vælge Epic - de valgte bare Cerner, og ikke Epic da de skulle stemme. Herudover var der tale om et powerpointshow og ikke systemets faktiske funktionalitet der blev vurderet af de 500. Det har været beskrevet flere gange, også her på Version2.

Jan Kold burde om nogen vide at Epic ikke (endnu?) lever op til de kravsspecifikationer som er givet i udbuddet, og det som vi ude i klinikkerne blev lovet i forbindelse med Sundhedsplatformen. Jeg kan blandt andet nævne koblingen af data til diverse kvalitetsdatabaser - det er jo slet ikke korrekt at der leveres data til 13 databaser - tallet er 6 og der kun tale om helt basale data, hvori der er meget store problemer med validiteten af de data som indrapporteres.
Hertil kommer leveringen af (korrekte) valideringsregler i forhold til Landspatientregisteret i SP. En korrekt understøttelse af den danske forløbsmodel. Problemer med afregningsmodulet til højt specialiserede funktioner. En korrekt understøttelse af kræftpakkeregistrering og korrekt visualisering af eventuelle overskridelser, og så er der selvfølgelig FMK som jo er en historie helt for sig - bare for at nævne et par stykker. Om dette så skyldes at kravspecifikationerne har været skrevet forkert, eller der alene er tale om manglende kvalitet i leveringen er jeg ikke den rette til at svare på. Jeg kan blot konstatere at man ikke endnu har været i stand til at levere alle de funktionaliteter som blev lovet inden og som kan bruges i dagligdagen.

(Fejl)slutning 2 (Epics software):
Kernen i Epics kode er skrevet i MUMPS, hvilket nok er det som hovedparten kritikerne sigter mod når de siger at EPIC's kode er forældet. Det er korrekt af man har omkring dette har bygget en række elementer til afvikling af kode i andre kodesprog, men det ændrer ikke ved at det grundlæggende styresystem er lige så gammelt som organisationen (MUMPS er fra 70'erne).

Jeg ved ikke om MUMPS er årsagen til at EPIC's GUI ligner noget fra et rumskib (fyldt med knapper og manglende overskuelighed), hvor de primære muligheder for at ændre brugergrænsefladen er at kunne ændre farven på baggrunden og rækkefølgen af de præsenterede data. F.eks. understøtter SP kun sortering på maksimalt 3 variabler ad gangen i de fleste oversigter, og filterfunktionerne er meget basale (IF, THEN, CONTAINS, OR, AND), hvis de overhovedet virker efter hensigten.

Der er overhovedet ikke leveret nogen form for dokumentation til brugerne om hvad de forskellige variabler og tables dækker over, hvilket gør valideringen af data nærmest umulig. Systemet er så svært at bruge at selv et skifte fra sommertid til vintertid skal beskrives i et 17! siders langt dokument.

De danske hospitaler over en bred kam havde allerede før EPIC en score i forhold til HMISS på 5 til tæt på 6 - der manglende primært beslutningsstøtte i de gamle systemer for at opnå en højere score.

Jeg har dog endnu til gode at opleve i den faktiske brug af SP at vi har fået specielt meget mere beslutningsstøtte end vi havde før - om dette skyldes manglende udvikling/tilpasning af systemet eller andre forhold har jeg meget svært ved at gennemskue. Jeg har derfor svært ved at se at SP i sin nuværende form scorer meget højere end før. Herudover kommer mange af de hospitaler som Jan Kold sammenligner med i sin kronik fra en meget lavere udgangspunkt (HMISS 3-4), hvilket gør at de selvfølgelig har set en større forbedring end dem som ses i Region Hovedstaden og i særlig grad Region Sjælland som går på lige om lidt (de lå højere end Region H).

(Fejl)slutning 3 (brugertilfredshed):
Jan Kold hævder korrekt at Epic generelt arbejder med brugertilfredshed. Men det siger jo ikke noget om man har arbejdet med brugertilfredshed i forbindelse med implementeringen af Sundhedsplatformen i Region H. Såvidt jeg ved er de to eneste undersøgelse der har været af "brugertilfredsheden" været en medieanalyse af positive udarbejdet af Regionens kommunikationsenhed og negative historier i pressen omkring SP, hvor konklusionen var at langt hovedparten var negative, samt en pilotundersøgelse på Herlev/Gentofte hospital blandt lægerne med meget dårlige resultater.

Jeg har hørt rygter om at man har tænkt sig at gennemføre en tilfredshedsundersøgelse i fremtiden, men før en sådan er gennemført kan man ikke påstå at Epic/SP arbejder seriøst med brugertilfredsheden.

(Fejl)slutning 4 (utilfredshed):
En kort søgning på "EHR burnout" både i videnskabelige databaser og på Google, viser at der nok her er tale om et generelt problem med elektroniske patientjournaler og ikke kun et problem relateret til Epic. Den store forskel er dog at man i USA primært har indført en administrativt lag af "clickers" som sørger for at dette mindskes. Dette har vi ikke i Danmark, derfor er den "burnout" som ses blandt lægerne i Region H ganske velbegrundet.

Det er rigtigt at Region Sjælland og Region H også har indført kliniske byggere. Men dette er jo først sket efter massivt pres fra hospitalernes side, og ikke noget som lå i den oprindelige implementeringsplan. Desuden mangler der oplysninger om hvor mange kliniske byggere der bruges på disse udenlanske hospitaler i forhold til de få kliniske byggere der indtil videre er uddannet i DK.

Det er mit indtryk at man har valgt et helt andet setup i forhold til mulighed for modificering "lokalt", end det som man har valgt i Region H hvor mulighederne for lokal tilpasning er meget begrænsede grundet et meget stort ønske om standardisering og en alt for hierarkisk opbygning af organisationen - med et meget stort kvalitets- og produktivitetstab til følge. Men dette er jo ikke nødvendigvis Epics skyld (bortset fra at vi købt implementeringskonceptet af dem).

(Fejl)slutning 5 (Cambridge):
Jan Kold fremhæver igen Cambridge. Et hospital som blev sat under administrativt opsyn på grund af for dårlig kvalitet efter indføringen af Epic's EHR, og først efter tre år kom ud af dette tilsyn. Det er korrekt at Cambridge har vundet en pris for at være det mest "wired" hospital, men Jan Kold glemmer at nævne at kvaliteten i behandlingen IKKE er bedre end andre hospitaler i England, når man gennemlæser de tilgængelige rapporter om kvaliteten generelt på hospitalerne i England. Samtidig kører Cambridge-organisationen med merforbrug på mere end 500 mio. årligt. Så tillykke med Cambridge med deres digitalisering - det har hverken givet dem bedre kvalitet eller bedre økonomi.

Og her til sidst en lille analogi, som måske kan anskueliggøre nogen af problemerne for udefrakommende:

Forestil jer at Novo Nordisk med 41.200 (44.000) ansatte beslutter sig for at indføre et nyt IT-system. Systemet udskrifter mere end 30 fagsystemer der bruges for nuværende i organisationen.

Systemet lover at mindske omkostningerne ved selve produktionen af blandt andet insulin og samtidig vil de gøre at kvaliteten af insulinen øges så patienterne oplever en bedre behandling af deres diabetes, hvilket vil stille Novo Nordisk i en bedre situation i den globale konkurrence, hvor profitten er faldende og kunderne ikke er helt så villige til at betale så meget fra insulinen (regionernes økonomi/ældrebyrde mv.). Systemet er kinesisk (amerikansk) og meget dyrt men bruges af nogen af Novos største konkurrenter i andre lande, så bestyrelsen (regionrådet) vil meget gerne have systemet, selvom beslutningsgrundlaget (businesscasen) er af meget dårlig kvalitet og visse afsnit ligefrem stadigvæk står på kinesisk. Der forventes en lille forstyrrelse af produktionen omkring overgangen men at produktionen vil være oppe igen efter 1 måned, og de gevinster der er ved systemet vil gøre at man kan indhente de tabte i løbet af få måneder.

Efter halvandet års indkøring, hvor der været haft massive problemer med indkøringen, viser det sig at produktionen er gået ned med minimum 5%, udgifterne til produktionen er steget på grund af mange driftsstop, hvor batch må kasseres. Der er endnu ikke tegn på at produktionen er nået niveauet før indførsel, selvom Novo typisk årligt har kunnet reducere deres omkostninger med minimum 3-5% og samtidig øge produktionen.

Der har været en række kvalitetssvigt i produktionen som gør at EMA og FDA nu undersøger sikkerheden ved insulinproduktionen nærmere (UTH v. Styrelsen for patientsikkerhed, cancerpakker/udredningsret m.m. ved Sundhedsstyrelsen).

Aktionærerne kræver samtidig en kulegravning af businesscase/økonomien bag it-systemet og det stemmer igennem at et eksternt revisionsfirma skal udarbejde en rapport (Rigsrevisionen).

Medarbejdernes trivsel er faldet ganske markant (se seneste trivselsmåling fra Region H) og flere opsiger eller søger ligefrem nye stillinger på grund af det nye system.

Novos forskningsafdeling melder samtidig tilbage at stadigvæk efter halvandet år ikke har data til gennemføre nye forsøg til udvikling af nye insulintyper, da data stadigvæk ikke kan udtrækkes fra deres nye kinesiske fagsystem (kvalitetsafdelinger og forskere i Region H). Man er flere steder gået over til at køre forskningen og kvalitetsudviklingen i egne excelark og på papir, med de risici og produktivitetsproblemer dette indebærer. Herudover er der så store problemer med validiteten af data som præsenteres i fagsystemet, at man ikke er sikker på at man tør sætte nye insulintyper i produktion som ellers både kunne være billigere og bedre for patienterne.

Novos økonomiafdeling melder samtidig at de ikke har noget overblik over hvilke indtægter som produktionen har givet, da et helt basalt indtastningsmodul vedr. salg ikke fungerer efter hensigten (datakvalitet i LPR).

Bør Novos ledere blive ved med at hævde at det kinesiske IT-system ikke har problemer, eller bør man i stedet erkende at der både i løbet af implementeringen har været en masse problemer som stadig ikke er løst, og kvaliteten af systemet måske ikke er helt så høj som lovet?

Michael Cederberg

Hvis man har oplevet sundhedssystemet i hovedstaden indefra før Epic blev rullet ud, så ved man også at dagligdagen blev brugt på mange uafhængige og ikke sammenkoblede systemer. Der var processer som blev gennemført på 3270 terminaler (med tilhørende antikverede systemer bagved). Noget så simpelt som at få taget en blodprøve på et andet hospital end det man blev behandlet på, var ikke en process nogen stolede på.

Så det var ikke en mulighed at gøre ingenting. Der skulle ske noget. Og havde man valgt noget andet end Epic så havde der også været problemer.

Når man lytter til sundhedspersonale er der ting der er blevet dårligere (nogen er meget) og ting der er meget bedre. Men var det ikke det man skulle forvente? Sådan er det næsten altid når man skifter IT systemer ud til noget der er helt anderledes. Det må således forventes at det tager nogen tid (i dette tilfælde år) at få systemerne og processerne optimeret.

I den forbindelse er min bekymring hvorvidt region hovedstaden (og andre) har indrettet sig på at de har en meget langsigtet binding til Epic. Jeg gætter på at man kommer til at bruge den platform de næste 30 år.

Jeg er også bekymret for hvis man altid vælger at føje brugerne. Når man køber standardsystemer, så er der altid et udtalt ønske om at tilrette systemet til netop de arbejdsprocesser man har netop nu, uagtet at andre kunne være bedre eller lige så gode. Min erfaring er at man skal vælge hvilke processer der er vigtige for en, og tilrette systemet efter disse. Alle de andre - dem der ikke er vigtige - der skal man acceptere at ændre processer. Ellers bliver det meget dyrt og ens binding til leverandøren bliver endnu større.

Søren Neermark

Det er korrekt at der i Region H før Epic var flere fagsystemer. Det er også korrekt at der skulle et nyt it-system til grundet blandt andet afhængigheder til gamle browsere og versioner af Windows mv.

Det med blodprøverne kan jeg ikke genkende - vi har haft samme blodprøvesystem på tværs af hospitalerne de seneste mange år - og desuden er der stadigvæk det samme blodprøvesystem som før Epic (LabkaII), EPIC har kun lavet en integration til bestilling og visning af svar herfra.

Jeg er helt enig i at der ville have været problemer uanset valg af leverandør. Men omfanget af problemerne har bare været meget, meget større end hvad der f.eks. var i forbindelse med udrulningen af Cosmic i Region Syd og MidtEPJ Region Midt, som jo faktisk kun gav lidt historier i Region Syd, særligt omkring udrulningen på OUH (aktivitetstab og problemer med LPR-registreringen, som de fik løst på et par måneder). Om dette skyldes at man havde valgt et andet implementeringskoncept, eller man som organisation var bedre gearet til IT-implementering, eller Midt/Syd har været mindre ambitiøse i hvad der skulle ændres, skal jeg ikke kunne vurdere, men det er nok en kombination af flere faktorer.

Min vurdering er dog at en del af problemerne skyldes at man har undervurderet hvor store forskelle der er EPIC's opbygning vs de gamle systemer. SP er jo netop ikke er tilpasset den "normale" måde hvorpå der arbejdes i det danske sundhedsvæsen - det er en amerikansk standardsystem, men meget få ændringer. Dermed har det valgte implementeringskoncept været fuldstændig utilstrækkeligt i forhold til de ændringer man gerne ville gennemføre organisatorisk indenfor en meget kort tidsperiode med hurtige "gevinster", så den høje pris på systemet kunne retfærdiggøres.

Samtidig har der været tale om en meget topstyret proces som i høj grad har foregået langt væk fra det kliniske arbejde og som har været alt for forceret - resultatet er derefter!

Man har arbejdet med "parathedsgrupper", hvor formålet primært har været at disse grupper skulle tilpasse organisationen og ikke it-systemet.
Der er kun blevet foretaget ændringer i SP, der hvor patientsikkerheden åbenlyst har været truet, og selv disse ændringer har været meget svære at gennemføre, blandt andet grundet en håbløs regid model i forhold til implementering af ændringer, og en organisation som slet ikke har haft muskler nok til at gennemføre en kontinuerlig udrulning og fejlrettelse på samme tid.

Men igen dette er nok ikke Epics skyld, men nærmere den valgte ressourcetildeling og organisering af implementeringsorganisationen (som består af folk fra NNIT og Region Hs egne folk).

Min pointe - også med min tidligere kommentarer - er ikke så meget valget af Epic, det kan vi ikke gøre om, men nærmere den manglende erkendelse af at der er mange uadresserede problemer, og alt for meget spin fra dem, som ikke sidder med konsekvenserne af systemet.

Denne erkendelse og ydmyghed synes jeg ikke Jan Kold med ovenstående kronik og svar på kritik, nødvendigvis virker til at have.

Klavs Klavsen

Ineffektivt sekretærarbejde - fordi systemet åbenbart er så anti-brugervenligt..

Nogen burde se hvad andre brugervenlige bruger grænseflader gør - og lære noget.. Og hvis ikke EPIC er fleksibelt nok, til at man kan erstatte(!) brugergrænsefladen - med nogen(IMHO flere) brugergrænseflader (webinterface er f.ex. populært - men må gerne være klassisk GUI) optimeret til de mange(!) forskellige opgaver det skal bruges til..

Så man kan gøre simple ting, som at undgå at brugerne ser menu-punkter og alt muligt andet de IKKE skal bruge i DERES arbejde.. og ikke skal igennem flere niveauer end højst nødvendigt (med tilhørende ekstra interaktion/klik) - så får vi ihvertfald IKKE øget effektivitet ud af det her.. Og ja - så er det billigere at have sekretærer der spilder deres tid, end at lade lægerne gøre det.. :(

Mht. museklik.. har systemet ikke genveje.. hvis man benytter et system meget - er det langt mere effektivt at benytte keyboard genveje.. og dem kan man indlære ganske nemt og effektivt.. i modsætning til at bevæge musen rundt..

Lars Skovlund

Systemet er så svært at bruge at selv et skifte fra sommertid til vintertid skal beskrives i et 17! siders langt dokument.


Lige denne må jeg kommentere på. Jeg har set indholdsfortegnelsen til det pågældende dokument, og det drejer sig altså lige så meget om registrering af hændelser i det forkætrede tidsrum, hvor klokkeslettene fra 02:00 til 02:59 optræder to gange. I fuldt automatiserede systemer kan man gøre ting (såsom at bruge monotone ure) for at gøre systemet robust overfor dette, men når menneskelige registreringer er nødvendige, så kan almindelige klokkeslet ikke bruges alene (I har formentlig ingen vejledning til at dække det modsatte skift - hvor klokkeslettene ikke opfører sig på denne måde?).

Det kræver støtte i brugergrænsefladen, som er unødvendig resten af året - og derfor skal man enten pladre brugergrænsefladen til med dette ekstraudstyr hele året som alle lærer, eller have vejledninger til det vagthavende personale på dagen (som de helst skal have læst i forvejen). Personligt ville jeg satse på det sidste.

Politi, brandvæsen etc. har formentlig tilsvarende issues.

Søren Neermark

@Lars Jeg er helt enig med dig i at der selvfølgelig skal være info til de relevante brugere i forbindelse med skift mellem sommer og vintertid. Det har der været i sundhedsvæsenet siden (IT-)tidernes morgen. Det der nærmere var pointen var længden af dokumentationen, som skulle give en illustration af systemets kompleksitet.

I min verden er et "tipsheet" (som de kaldes i SP-verdenen) et dokument som i korte træk forklarer, hvorledes man løser en given problemstilling i it-system. Rent semantisk kan man sige at det er et stykke papir (sheet) med tips (tips) og ikke 17 stykker papir med tips - det ville jeg nærmere kalde en manual - altså noget man læser inden man skal gå i gang med at bruge systemet for første gang! I min optik opfylder gennemlæsning af 17 sider ikke denne definition på et tipsheet til håndtering af et event som er af en times varighed, som optræder to gange om året.

Og hvis det nu bare var sådan at dette konkrete tipsheet/manual om sommer/vintertid var udtryk for en enlig svale, kunne man skyde mig i skoene at jeg var selektiv i forhold til mit eksempel. Men sådan forholder det sig desværre ikke. Hvis jeg f.eks. søger efter tipsheets og manualer vedr. FMK får jeg 124 resultater, In basket (eller InBasket) får jeg hhv 104 og 27 resultater alt efter stavemåde. Det første dokument som må være en manual fylder 32 sider, det næste 2 sider, det tredje 14 sider, det næste igen 42 sider osv. Og jeg sidder stadigvæk tilbage med følelsen af at jeg ikke er sikker på at jeg nu ved hvad funktionaliteten kan (for hvad står der mon i de dokumenter jeg ikke har læst?).

In basket kan for udenforstående bedst forklares som et notifikationssystem (mailprogram) hvor personalet (i visse tilfælde) foreligger en besked om at der nu foreligger et svar på en prøve, eller der er noget på en given patient der skal tages stilling til. Det burde være rigtig smart, og er faktisk et af de områder som potentielt kunne løfte patientkvaliteten (prøvesvar er og har altid været rigtig svært!), men i praksis indtil videre har givet anledning til enorm (patient)usikkerhed og frustration blandt personalet, grundet en helt ulogisk håndtering af prøvesvar alt efter hvor behandlingen foregår, og problemer med integrationen til "fødesystemerne" (blod, røntgen og patologi).

Det eneste positive man kan sige manualerne/tipsheets, er da at man hos SP's driftsorganisation er utroligt produktive, i form af produktion af tipssheets og længden af disse. Men det hjælper ikke brugeren specielt meget, når brugeren har et konkret problem og man sidder inde med en patient, og kun har 20 minutter til at undersøge, og orientere patienten om at patienten har en alvorlig sygdom, men at man ikke kan komme videre med patientens behandling grundet et IT-problem (f.eks. FMK), og som man skal søge efter blandt mere end 100 manualer/tipssheets af varierende længde for at løse.

Resultatet er at man lokalt udarbejder "små" tipsheets, hvilket giver en uens brug af systemet, da disse lommekort jo ikke kan opdateres når der f.eks. ændres på funktionaliteten, hvilket bidrager til yderligere frustration hos brugerne, og spild af ressourcer, og dårlig patientoplevet kvalitet.

Den store mængde af tipssheets/manualer udgør også et organisatorisk problem i form af en enorm løbende vedligeholdelsesopgave, når der f.eks. i 2018 skal implementeres en større opdatering af SP i forbindelse med LPR3 og et skifte til en nyere version "kernen" af SP (vist 2017/2018 udgaven). Vedligeholdelsen nedsætter driftsorganisationens muligheder for rent faktisk at komme ud og løse (ændre) nogen af de konkrete problemer, som ses i hverdagen på hospitalerne.

Et andet eksempel til illustration af hvor kompleks Sundhedsplatformen er, er den kursus aktivitet som man som "ny-uddannet" læge skal gennemgå både i form af e-learningsmoduler og klasseundervisning. I praksis vil nyuddannede læger skulle bruge knapt en måned på oplæring før at de er "certificerede" til at måtte bruge SP (altså for at få et login). Hertil kommer en længere periode bagefter med sidemandsoplæring, hvor der også er et produktivitetstab, da man i standardiseringens hellige navn, ikke har lavet de kurser der skal gennemgås specielt specifikke (altså afdelings/afsnitsvendte). Dette er et ressourcespild som presser afdelingernes økonomi, da de jo også i denne oplæringsperiode skal betale for denne undervisning, som slet ikke havde dette omfang før SP - (man kunne klare IT-introduktionen til det meste på få timer og det foregik ude i afdelingerne).

Johnny Rose Larsen

Jeg skulle i dag kigge på nogle prøvesvar på minsundhedsplatform.dk.
Prøvesvarene er der, men for at se resultatet skal jeg klikke på hver eneste enkeltprøve. Heldigvis kun 17.

Jeg kan udskrive listen, men der står stadig ingen værdier ud for hver enkelt prøve. Komplet værdiløst.

Kommentaren fra dette lille hjørne af platformen: OMMER!!

Jeg kan se samme resultater på sundhed.dk, men her opstillet i skemaform med både de nyeste og tidligere resultater side om side - meget brugervenligt.
Udskrivning er med samme brugervenlighed.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017