mikkel lauritsen bloghoved den gode kode

Brugeres oplevelse af ny IT

Der er flere, som i kommentarerne til Version 2's artikel om Region H. og Region Sj.'s nye Sundhedsplatform og problemerne med samme har anklaget sygehuspersonalet for at være modvillige - og det stemmer ikke overens med mine erfaringer. Brugere, der græder af afmagt peger heller ikke i den retning.

I mit daglige arbejde som leverandør af IT til sygehusene oplever jeg brugere, som er hverken mere eller mindre skeptisk indstillede overfor IT end så mange andre. Der er selvfølgelig store individuelle forskelle på hvor trygge de er ved IT generelt, men de er oftest konstruktivt indstillede; også overfor ændringer - forudsat at de giver mening. Det er bare under alle omstændigheder alfa og omega, at IT skal støtte op omkring de daglige arbejdsprocesser, fordi personalet er så pressede, at der ikke er plads til tab forårsaget af dårlig teknologi. Vi har fx konkret siddet og lavet om på brugergrænsefladen i vores applikationer for at nedbringe antallet af museklik, fordi der er sat 10 minutter af pr. patient i ambulatoriet, og hvert et sekund tæller.

Netop hvad Sundhedsplatformen angår ved jeg ved ikke ret meget ud over hvad jeg får fra medierne og mit netværk, men selv om de officielle udmeldinger fra den øverste ledelse er positive kunne noget tyde på, at der er ting, som kunne køre bedre.

Selve kernesystemet virker formentlig, forstået på den måde, at det ikke dørker og har acceptabel performance. Andet ville være underligt - det er, som andre også har påpeget, et standardsystem, som længe har været i drift flere andre steder.

Regionen udpeger selv integrationerne med andre systemer som problematiske, og det kan jeg levende forestille mig. En af pointerne med Sundhedsplatformen er at centralisere megen information i et system, men det er stadig nødvendigt at integrere til andre systemer, både internt i regionen og eksternt (nationale services som fx Fælles Medicinkort og kommunernes og praktiserende lægers systemer).

Det er en kendt sag, at integrationer er notorisk svære at have med at gøre, bl.a. på grund af

  • Manglende dokumentation - det lyder utroligt, men det er ofte svært at få dækkende dokumentation fra leverandørerne af de systemer, man skal integrere med
  • Impedanstilpasningsproblemer - systemet, som er kilden til data, har en for simpel model af tilværelsen, så man ikke kan populere ens model (NOT NULL-constraints er hårde :-)), eller der stilles krav om, at man skal håndtere data, som er rigere, end hvad man umiddelbart kan
  • Inkonsistente data - der er fejl i de data, man modtager, hvilket man som regel først opdager, når man er gået i produktion

Oveni den almindelige mangel på indsigt i et nyt system og hvad der nu måtte være af andre fejl bidrager integrationsproblemerne til, at personalet oplever, at de ikke kan stole på de oplysninger, der fremgår af systemet.

Hvis det så bare var papirclips eller smøreolie der ikke var styr på var det måske til at håndtere, men når det fx drejer sig om patienternes medicinering kan jeg godt forstå, at brugerne føler sig pressede. Det gør også, at der bliver brugt unødigt megen tid på at kontrollere, at ting er blevet registreret korrekt.

Det lyder også som om, at klinikerne oplever, at systemet på andre områder ikke støtter op om deres daglige arbejde. Udsagn som det med mange komplekse klik-funktioner peger i retning af, at man ikke har fået tilpasset systemet til arbejdsprocedurerne - eller omvendt. Det amerikanske sundhedsvæsen er generelt meget fokuseret på fakturering, så man kunne forestille sig, at en amerikansk EPJ kræver registrering af data, som ikke er relevante i det danske offentlige sundhedsvæsen.

Endelig ser det ud som om, at man også fra den øverste ledelses side kan se, at der er problemer. Man accepterer nu, at det kan være nødvendigt at vente til senere end oprindeligt planlagt med at skrue op for produktionen.

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#4 Maciej Szeliga

Umiddelbart så ser der største problem være at man ikke har tænkt arbejdsgange og platform sammen eller ikke efteruddannet brugerne.

Før: læge indtaler på diktafon til lægesekretær som så skriver ind Nu: læge indtaster selv det hele

Først og fremmest er problemet i det at de fleste som IKKE har taget et kursus i maskinskrivning taler omtrent 4 gange hurtigere end de skriver (på tastatur). Hvis man ikke har set den komme burde man fyres på stående fod! ...og hvis man ikke er blevet gjort opmærksom på det burde man fyre dem som ikke gjorde opmærksom på det (forudsat selvf. at de kendte forholdende).

Løsninger: * opkvalificere lægerne med maskinskrivningskursus (og i øvrigt udvide uddannelsen til at indeholde det) * tilføje et voice interface til systemet * ansæt flere læger så der bliver bedre tid til at skrive (det kan måske på sigt betyde bedre tid til patienterne) * lade lægesekretæren indtaste fra diktat som før, det kræver bare at hun får samme adgang som hun har haft før

Jeg abstrahere lige fra de 9000 rapporterede fejl FORDI: 1. der vil altid forekomme fejl og jo mere komplekse systemerne er desto flere fejl vil man få. 2. vi ved meget lidt om de fejl ud over at der er 9000. 3. man kan altid sige at man kunne have testet bedre men det vil betyde at man i f.eks. 3 måneder skal køre reel dobbelt drift, hvis det ikke er en option så må man leve med fejl og rette dem efterfølgende (og selv dobbelt drift garanterer ikke fejlfrihed), hvis man bevidst har fravalgt dobbelt drift så er der selvf. nogen som er ansvarlige for den beslutning.

  • 4
  • 0
#5 Morten Hansen

Det kommer da an på data. Hvis nu 2000 brugere melder ind at "funktionalitet X virker ikke", så er der ikke tale om 2000 fejl. Så er der tale om 1 fejl, opdaget 2000 gange - altså 2000 fejlmeldinger på samme fejl. Jeg mistænker at sådan det i ét eller andet led bliver fejlciteret som 2000 "fejl". Det lød som om at mange af de "fejl"/fejlmeldinger der blev fundet kunne løses af de floorwalkers der var sendt ud i forbindelse med opstarten. Så kan vi yderligere antage at en stor del af disse "fejlmeldinger" måske i virkeligheden skal betragtes som den type af fejl vi alle kender, som hører under "brugeren kunne ikke finde ud af hvilken knap de skulle trykke på". En incident kunne for eksempel være at bruger x ikke kunne finde knappen til at sende en sag videre. Det er ikke en fejl, men mon ikke den er talt med i statistikken? Dem kunne man ligeledes forestille sig der var mange af. Det kan så skyldes manglende undervisning, eller bare klassisk at det tager tid for folk at vende sig til et nyt system, eller en masse andet. Men jeg betvivler på det kraftigste at der var 9000 "fejl".

  • 0
  • 0
#6 Gert Madsen

"sygehuspersonalet for at være modvillige"

Det er en strategi, som ses mange steder. Man fjerner support-funktionerne under indførelse af noget IT-sovs, som man påstår skulle overflødiggøre funktionen. Når brugerne så konstaterer at det giver dem et øget tidsforbrug, så brokker de sig over projektet. I stedet for at kompensere det øgede tidsforbrug, så råbes der "Modvillig", "modstand mod forandring" etc., for at skjule hullet i forretningsplanen.

  • 1
  • 0
#7 Finn Thøgersen

Husk nu på at der er mange hundrede (tusinde?) funktioner i systemet, og at det bruges i mange forskellige arbejdsgange og integrerer med et større antal externe systemer.

Der vil da givetvis være overlap, om ikke andet så fordi samme fejl opleves og derfor beskrives fiorskelligt.

Det er givetvis også en blanding af småfejl/uhensigtsmæssigheder (for lidt plads til XXX, for mange klik osv) og meget alvorlige fejl (forkert data, nedbrud osv)

  • 0
  • 0
Log ind eller Opret konto for at kommentere