Hp Vitforum-3.pptx
•Download as PPTX, PDF•
0 likes•20 views
Foredrag i vitenskapsteoretisk forum NTNU
Recommended
Recommended
More Related Content
Similar to Hp Vitforum-3.pptx
Similar to Hp Vitforum-3.pptx (20)
Hp Vitforum-3.pptx
- 1. Helseplattformen: Hva kan vi lære til neste store IT-prosjekt? Vitenskapsteorietisk forum 29.08.2023 Dag Svanæs (professor, dr.philos.) Institutt for Datateknologi og Informatikk NTNU
- 3. Hva kan vi lære til neste store IT-prosjekt? • Dette er komplekst, og jeg har ikke svaret med stor S. • Summen av mange forskere med forskjellig tilgang (IT, samfunnsvitenskap, psykologi, økonomi,,) kan ta oss nærmere svaret. Mitt bidrag HP
- 4. Helseplattformen: Behovet og visjonene Fire regionale helseforetak i Norge (RHFer): Helse Midt-Norge RHF (Møre- og Romsdal og Trøndelag): • 720.000 innbyggere • Potensielt 40.000 brukere av et felles helse-IT- system for sykehusene, kommunene og fastlegene. • Før Helseplattformen (2012): • Et gammelt IT-system ved sykehusene (Doculive). • Tekstbasert journal. • Fremdeles papirkurve på sengepost. • Manglende verktøy for samhandling (f.eks. når pasienter går fra sykehus til sykehjem til fastlege). • En rekke forskjellige IT-systemer som bare delvis kommuniserte med hverandre.
- 5. 34 Copyright © 2023 by Boston Consulting Group. All rights reserved. Den nye journalløsningen krever samhandling på tvers av aktører som opprinnelig ikke har felles forvaltning Helse- og omsorgsjenester inkl.: • Legevakt og akuttmottak • Helsestasjon og skolehelsetjeneste • Omsorgsboliger • Institusjoner (rus, psykisk helse) Kommunal finansiering via rammetilskudd fra staten basert på en kostnadsnøkkel som reflekterer bla. innbyggere fordelt på aldersgrupper, dødelighet og geografi 3. Omfang og tidslinje Merk: AVS = avtalespesialister Kilder: regjeringen.no, helsedirektoratet.no, lovdata.no, helse-midt.no, helsenorge.no Bekreftet av HP AS 14.06.2023 >700 fastleger/AVS 66 kommuner 4 helseforetak De fire helseforetakene i Helse Midt-Norge inkluderer • St. Olavs hospital HF • Helse Møre- og Romsdal HF • Helse Nord-Trøndelag HF • Sykehusapotekene i Midt-Norge Finansiering Beskrivelse Statlig finansiert gjennom de regionale helseforetakene gjennom en to-delt finansiering: • Basisbevilgning • Aktivitetsbasert finansiering (DRG koder) • Kommunene dekker behovet for fastleger gjennom avtaler med selvstendig næringsdrivende leger, fast ansettelse eller andre økonomiske tiltak • Avtalespesialister/avtalefysiotera- peuter får driftstilskudd fra staten Næringsdrivende leger har en tre-delt finansiering: • Per-capita tilskudd fra kommunen basert på antall innbyggere på pasientlisten • Takstrefusjoner fra staten/ folketrygden (via HELFO) • Egenandeler fra pasientene
- 6. Copyright © 2023 by Boston Consulting Group. All rights reserved. 47 Helseplattformen har status som regionalt utprøvings- prosjekt for «én innbygger, én journal»... 5. Årsaker A. Formål og omfang A1. Nasjonal utprøvingsarena Kilde: ehelse.no; Dokumentasjon mottatt fra direktoratet for e-helse; riksrevisjonen.no 2012 2016 2019 2021 Akson • Direktoratet for e-helse fikk i april 2019 oppdrag om å utvikle et felles kommunal journalløsning ... men uklart hva dette betyr i praksis da det foreligger begrenset med planer for å trekke læringer fra HP som helhet Stortingsmelding 9 (2012-2013) «Én innbygger – én journal» "Målet er at nødvendige helseopplysninger skal følge pasienten gjennom hele pasientforløpet". Regionalt utprøvingsprosjekt for «Én innbygger – én journal» • HOD gir HMN i oppdrag å være et regionalt utprøvingsprogram for det nasjonale målbildet Én innbygger, én journal, etter anbefaling fra Direktoratet for e-helse • Som en konsekvens fikk nasjonale aktører en observatørstatus i anskaffelsesfasen av Journalprosjektet, samt rett til å delta i andre faser Planer for oppfølging Hverken teknologivalg eller organisering av Helseplattformen skal være førende for videre nasjonal utbygging av «én innbygger – én journal» Fra tildelingsbrev E-helse (2023) foreligger det planer for at Helse Vest RHF, Bergen kommune og HMN sammen skal innhente erfaringer knyttet til regional legemiddelliste E-helse skal også følge opp de andre nasjonale oppdragene I HMNs foretaksprotokoll (2023) står at HMN skal dele læringspunkter fra arbeidet med Helseplattformen med andre RHF 2022 «Én innbygger – én journal» får kritikk fra Riksrevisjonen pga. svakheter ved helse- myndighetenes styring og kontroll av IT-satsingen, manglende framdrift, og brudd i reglene for anskaffelser Statlig støtte til Akson avsluttes Nasjonale oppdrag Helseplattformen skal være en utprøvingsarena for: • Felles språk i helse- og omsorgstjenesten • Journalmodernisering • Pasientens legemiddelsiste • Innbyggertjenester
- 7. 11 Copyright © 2023 by Boston Consulting Group. All rights reserved. Innføring ved STO forsinket med ett år fra opprinnelig go-live i nov 2021 – først til april 2022 og så til nov 2022 Kilder: Dokumenter fra Helse Midt-Norge, Helseplattformen og St. Olav; pressesøk 2021 2012: IKT-strategi for Helse Midt-Norge vedtas; inkl. mål om standardisering, informasjonsdeling i ende-til- ende pasientforløp og journalsystem i strukturert form 14. mar 2019: HMN vedtar Helseplattformen til 2,8 Mrd. NOK, levert av Epic T e stfase: test og godkjenning av løsning, planlegging av produksjonssetting 9. mar 2023: Adm. dir. for HP AS går av U t viklingsfase: design og utvikling av arbeidsflyt, plan for testfase 4. des 2020: Utsetter go- live fra nov 2021 til vår 2022 Nov 2019: Samarbeidsavtalen mellom HMN/HF og TK etablert 1 2 . nov 2 0 2 2 : STO innfører Helseplattformen 1. jan 2022: HEMIT får status som HF 27. apr 2022: Utsetter go-live fra 30. apr til nov 2022 1. sep 2022: Fastleger utsettes på ubestemt tid 2023 2019 8. feb 2019: Helseplattformen AS (HP AS) etableres 7 . mai 2 0 2 2 : Trondheim kommune innfører Helseplattformen 2. sep 2019: Trondheim Bystyre vedtar at Helseplattformen innføres 2016: Besluttes at Helseplattformen skal gjennomføres som regional utprøving for "Én innbygger- én journal" anskaffelsesprosjekt starter, signering av kontrakt f o rskyves med e t t å r til ma r s 2019 26. jan 2023: Innføring utsatt i HNT (til nov '23) og HMR (til apr '24) Mars 2022: Tjenesteavtalen signert mellom HP AS, TK, HMN/HF 2020 2022 Mar 2020: Covid-19 7. mar 2020: Lab-modul Epic Beaker innføres ved STO 19. apr 2023: Helsetilsynet konkluderer med at innføringen ved STO har ført til økt risiko for svikt i pasient- behandling Bekreftet av HP AS 14.06.2023 0. Sammendrag
- 8. Helsetilsynets rapport 17. april 2023 • “Helsetilsynet og Statsforvalteren i Trøndelag har i dette tilsynet konkludert med at innføringen av Helseplattformen ved St. Olavs hospital har ført til økt risiko for svikt i pasientbehandlingen.” • “På bakgrunn av nye, alvorlige feilmeldinger ved løsningen i perioden etter tilsynsbesøket oppfatter vi risikoen som pågående.” • “Systemets kompleksitet samt den inkonsistensen brukerne opplever, kan føre til alvorlige konsekvenser for pasientsikkerheten i fortsettelsen av bruken av Helseplattformen i sin nåværende form.” • “Tilsynsmyndighetene anser at utfordringene med gjentatte feil, og manglende oversikt på disse områdene, truer pasientsikkerheten både ved St. Olavs hospital og ved virksomhetene helseforetaket utveksler informasjon med. Omfanget av feil og mangler utfordrer dermed også helseforetakets evne til å yte forsvarlig helsehjelp innenfor disse områdene.”
- 9. Hvordan havnet vi her? • En rekke organisatoriske faktorer knyttet til at dette er et megaprosjekt (rundt 5 mrd kr) med veldig mange aktører. • Mitt fokus har vært på: • Brukermedvirkning. • Svakheter ved anbud som anskaffelsesform. • Manglende praksisnærhet og lite respekt for brukernes perspektiv. • Manglende bestillerkompetanse. • For stor makt til leverandør (Epic).
- 10. Hvordan skille er godt fra et dårlig produkt? • ISO/IEC 25010:2011: Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models • Skiller mellom “Product quality” og “Quality in use”. • På norsk: Produktkvalitet og Brukskvalitet. Produktkvalitet Brukskvalitet
- 11. Context of use – “brukssammenheng” ISO 9241-11 (1998) definerer usability: ”The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Context of use: ”users, tasks, equipment (hardware, software and materials), and the physical and social environment in which a product is used”. Context of use
- 12. Hvordan måler man et produkts brukskvalitet? • Eksempel: Spiseredskaper. • Brukskvalitet er ”anvendbarhet, effektivitet og tilfredsstillelse...”
- 13. ”...for bestemte brukere med bestemte mål i bestemte omgivelser.”
- 15. Brukskvalitet vs. andre egenskaper • Brukskvalitet er en kontekst-avhengig egenskap ved et produkt. Det er en relasjon mellom produktet og dets “context of use”. • Det er bare meningsfylt å måle brukskvalitet når man kan svare på: • Hvem er brukerne av produktet? • Hva ønsker de å bruke det til? • Hvor, og i hvilken sammenheng skal det brukes? • Eksempler på det motsatte (kontekst-uavhengige egenskaper): • Vekt, Størrelse, Farge, Prosessorhastighet. • Disse egenskapene er de samme på mandag og tirsdag, for Ole og for Kari, på kontoret og på gaten.
- 16. Konsekvenser for design og evaluering • Forutsetninger for design og evaluering av brukskvalitet: • Hvem er brukerne av produktet? • Krever tilgang til faktiske brukere: f.eks. leger, sykepleiere, pasienter, administratorer,, • Hva ønsker de å bruke det til? • Krever detaljert kartlegging av arbeidspraksis og informasjonsflyt. • Hvor, og i hvilken sammenheng skal det brukes? • Krever kunnskap om fysiske omgivelser, og mulighet til å observere og teste i faktiske omgivelser eller simulere disse i et laboratorium.
- 17. Det filosofiske bakteppet: Vet vi hva vi kan? • Tidlig “Requirement engineering” baserte seg på en antagelse om at kunnskap er eksplisitt (språklig/logisk): • Brukerne kan gjøre rede for sin egen praksis og handlingskompetanse. • Deres kunnskap og praksis kan «ekstraheres» i form av skriftlige beskrivelser. • Kravene til IT-systemer kan utformes som kravlister, ofte i dialog med brukerne. • Disse kravlistene kan så brukes til å lage IT-systemer.
- 18. Kritikk: Implisitt vs. eksplisitt kunnskap • Vannfallsmodellen fungerer dårlig i praksis. • Behov for alternativer til dens rasjonalistiske/reduksjonistiske menneskesyn. • «Taus kunnskap» (Polanyi, 1958): • Vi kan og vet mer enn det vi klarer å gjøre rede for. • Eksempler på «tause» handlingskompetanser: Å sykle, å svømme, å snakke et språk. • Ekspertkunnskap (Dreyfus and Dreyfus, 1980): • Ferdigheter på mesternivå (som f.eks. erfarne helsearbeidere) lar seg ikke beskrive som et sett med regler. • Slik kunnskap er basert på år med erfaring og setter seg som intuisjon og “magefølelse”.
- 19. Noen filosofer/teorier som er gjort relevante • Husserl: • “Livsverden”. • Heidegger: • Handling kommer før refleksjon. • All handling er situert (her og nå). • IT som verktøy: Teknologi blir en slags forlengelse av oss gjennom bruk, så lenge den virker. • Merleau-Ponty: • Vi er og handler som kropp. • Persepsjonen har en ”rettethet”. • Wittgenstein: • “Språkspill”: At relasjonen språk-virkelighet ikke er en-til-en. • Marx: • Makt og arbeid.
- 20. 1980 – Xerox Star Innovasjoner: Desktop, vinduer, ikoner, mapper, menyer, knapper, dialogbokser, WYSIWYG, objekt-orientert arkitektur.
- 21. Gradvis forfining • Eksempel: Utviklingen av ikonet for dokumenter på skrivebordet. Design / redesign Brukbarhets- testing
- 22. ISO 9241-210 • ISO 9241-210: User-centered design of interactive systems (2010). • Beskriver prosesskrav i forhold til utvikling av bruker-sentrert utvikling av software. • Fokus på iterasjoner, brukbarhets- evaluering, og dokumentasjon av brukbarhet. • Ratifisert som NS-EN ISO 9241- 210. Identifisere behov for brukersenteret design Forstå og spesifisere brukssammenheng Evaluere design mot krav Spesifisere brukerkrav Utvikle designløsninger Systemet tilfredstiller bruker og organisasjons krav
- 23. Anbud som anskaffelsesform • Problemer med anbud: • De kravene som inngår i kontrakten blir bindende. • Kvaliteten på sluttproduktet er avhengig av stor bestillerkompetanse. • Det er vanskelig å gjøre store endringer etter kontraktsinngåesle. Pre-contract After contract (no user-centered activities!) Requirements analysis Requirements specification Requirements evaluation Design Implementation, deployment Tender preparation Tender Evaluation of bids. Contract negitiations
- 24. Tidslinje: Anbud, Kontrakt, Implementasjon 24 Forslag om klinikervurdering Skulle ha skjedd her (før kontrakt)
- 25. Forslag til klinikervurdering (testing) i anbud • I 2014 hadde jeg gjort et studie av en annen anbudsprosess ved St.Olavs og så at det var viktig å få inn testing med brukere som del av anbudsprosessen. • Forslag til klinikervurdering av brukervennlighet og pasientsikkerhet på kjørende systemer i realistiske scenarier: • Samarbeid SINTEF/NTNU. • Basert på erfaring fra Danmark. • Budsjett NOK 620.000 • Anbefalt av deler av anskaffelsesorganisasjonen. • Helse-Midt sa nei.
- 26. Fra forslaget til klinikervurdering i 2014:
- 27. Forskningsprosjektet KONPAS (2019-2023) • KONPAS (Konfigurering av Elektronisk Pasientjournal). • Finansiert av NTNU Helse som del av forskningen på Helseplattformen. • To PhDer og én post.doc. • Ett av målene var å studere brukemedvirkningen i Helseplattformen. • Vi ønsket å gjøre aksjonsforskning der vi prøvde ut forskjellige beste-praksis metoder for brukernær systemutvikling. • Epic og HP sa nei til det, og vi endte opp med å gjøre følgeforskning. Fra “Salmer fra kjøkkenet”
- 28. Fra ISO 9241-210 • ”En bruker-sentrert designprosess har typisk: • Aktiv involvering av brukere, og en klar forståelse av bruker og oppgavene. • En iterativ prosess • Tverrfaglige utviklingsteam.” • Sterkt fokus på at utvikler må forstå og kunne formulere produktets ”brukssammenheng” (context of use). • Fokus på kommunikasjon med bruker gjennom konkrete prototyper etc. Identifisere behov for brukersenteret design Forstå og spesifisere brukssammenheng Evaluere design mot krav Spesifisere brukerkrav Utvikle designløsninger Systemet tilfredstiller bruker og organisasjons krav
- 29. Brukermedvirkning (Arnstein, 1969) 8. Innbyggerkontroll: Innbyggerne håndterer hele jobben med planlegging, politikkutforming og administrasjon av et program. 7. Delegering: Innbyggere har et klart flertall av setene i komiteer med delegert myndighet til å ta beslutninger. Offentlig har makten til å sikre ansvarlighet for programmet overfor dem. 6. Partnerskap: Makt omfordeles gjennom forhandlinger mellom borgere og makthavere. Planleggings- og beslutningsansvar deles f.eks. gjennom fellesutvalg. 5. Plassering: For eksempel samvalg av håndplukkede innbyggere i komiteer. Det lar innbyggerne gi råd eller planlegge, men beholder makthavere retten til å bedømme legitimiteten eller gjennomførbarheten av disse rådene. 4. Konsultasjon: Innbyggerne blir konsulert om deres meninger og råd, men har ikke makt til å vedta beslutninger. 3. Informere: Et første skritt til legitim deltakelse, men hvor vekten legges på en enveis flyt av informasjon og det er ingen kanal for tilbakemelding.
- 30. Brukermedvirkning i konfigureringen • 400 helsearbeidere ansatt deltid som fageksperter, “Subject Matter Experts” (SMEer). • En rekke møter der de blir spurt om hva de ønsker fra det ferdige systemet. • Fokus er på overordnet funksjonalitet og arbeidsflyt. • Problemer: • For høyt abstraksjonsnivå. • Det tar lang tid før man får se resultatet og får prøve ut et konkret kjørende system.
- 31. Krav til effektivitet påvirket brukermedvirkningen 31 Project Leading SME Consensus group Project organization Client organizations Pre-breakdown Project Leading SME Project organization Client organizations Consensus group Colleague Post-breakdown Regular deliverables Time (own time + colleagues time) Project (”tribal”) language (participants vs. non-participants) ?
- 32. Noen sitater: Om rollen som fagekspert • «Den tiltenkte rollen er å være konsulenter og fortelle hvordan vi jobber, beskrive arbeidsflyt til det daglige, arbeidsprosesser og prosedyrer, slik at vi kan bygge løsningen i henhold til det.» (Ledende fagekspert, informant 13) • «Det er vi fageksperter som har foreslått og gjennomført mange av de endringene. (…) Fagekspertenes innflytelse har uten tvil hatt en positive innvirkning. Systemet blir mye bedre på grunn av fagekspertene.» (Fagekspert, informant 2) • «Når vi sitter og tester, så kommer vi med innspill der vi synes det mangler litt, og de innspillene føler jeg blir tatt hensyn til så langt det er mulig.» (Fagekspert, informant 3)
- 33. Noen sitater: Avstand mellom krav og produkt • «De burde ha vist frem en demo-versjon av det endelige produktet, slik at vi kunne få prøve det og komme med tilbakemeldinger. Det er lettere å komme med tilbakemeldinger hvis man ser et konkret produkt.» (Superbruker, informant 5) • «Det er vanskelig for oss å gi tilbakemeldinger når vi ikke kan se hvordan sluttproduktet kommer til å se ut. Jeg synes ikke det har vært lett. Jeg skulle ønske vi hadde blitt mer hørt på.» (Superbruker, informant 4) • «Ofte har det vært slik at man har kommet inn til et sånt møte, også har det blitt presentert en PowerPoint-presentasjon: «Når en bruker gjør sånn, vil du ha valg a eller valg b». Så har vi spurt: «Men hva er det som leder brukeren til det valget?» eller «hva er konsekvensene av valg a eller valg b?». Det kan ingen svare på. Det er klart at sånn kan man ikke jobbe, beslutningene blir jo veldig basert på utilstrekkelig grunnlag.» (Ledende fagekspert, informant 11)
- 34. Noen sitater: Vanskelig å konfigurere systemet • «Da jeg ble med som fagekspert, ble det presentert at systemet i stor grad var formbart og at man kunne gjøre akkurat de tilpasningene man selv ville. Det har visst seg å ikke stemme. Det har vært mer fastlåst enn som så.» (Ledende fagekspert, informant 11) • «Et annet problem er at vi kan ikke endre programmet, for da endrer du programmet for flere ti-talls millioner brukere. Vi kan endre og tilpasse innholdet litt til oss, men vi får ikke designet nytt innhold. Da er det ikke Epic lengre, da er det et annet program. Det tok lang tid før jeg ble gjort innforstått med at sånn er det bare.» (Fagekspert, informant 2) • «Innspillene blir tatt på alvor, men det blir prioritert etter hvor vanskelig det er å lage. De vurderer det også opp mot det de har fra før. Hvis de har noe lignende fra før og det er enkelt å tilpasse, så prioriteres dette. (…) Vi har hele tiden hørt at det finnes en mal i bunn som er «default- konfigrasjonen», og at det er lettere for alle hvis vi bruker den.» (Superbruker, informant 5)
- 35. Noen sitater: Dårlig brukervennlighet • «Det er veldig mange tabs og bilder man må klikke på for å finne det man leter etter. Det er mange valg, og alt er ikke like enkelt og intuitivt. Det blir litt som I programmet Word, man bruker bare 10% av mulighetene der.» (Fagekspert informant 3) • «Stegene som blir gjort under en prosedyre er gjemt bak flere ulike valg. (…) Det er veldig mange valgmuligheter, med mye klikking og veldig mye bruk av ulike farger. Man skjønner ikke sammenhengen i farger, siden det er så mange. Man skal egentlig ikke se så mange valgmuligheter brukergrensesnittsmessig. Man skal egentlig ikke ha mer enn 7-9 valg på skjermen samtidig.» (Superbruker, informant 5) • «Et eksempel er at man skal dokumentere ting i bokser. Vi trenger kun 2-3 alternativer, men en annen avdeling trenger kanskje 15 alternativer. Det er nå slik at vi ser alle disse 15 alternativene, som ikke har noe med oss å gjøre» (Ledende superbruker, informant 9)
- 36. Sitater: Avstand og språk «Vi designer ingenting, vi får bare presentert skjermbilder. Vi bare forteller hvordan vi gjør noe. Vi har ikke sett enda hvordan hele systemet ser ut. Det var en test i dag, og det virket ikke. Vi har bare en følelse av hvordan løsningen generelt sett kommer til å se ut.» (Superbruker, informant 5) «Vi har til og med invitert folk fra Epic til å komme til oss for å se hvordan vi har det og jobber. De jobber jo ikke med det samme som oss, de har jo en helt annen fagbakgrunn, så de skjønner ikke hvorfor de ulike tingene er så viktig for oss. (…) Jeg skulle også ønske at det hadde vært interesse fra deres side for å komme her og se litt, enn at vi skal oppmuntre til det. At de innser selv at det er viktig for dem å komme å se hvordan vi arbeider.» (Superbruker, informant 4) «Vi driver ikke en fabrikk, det er snakk om liv og død når ting ikke virker. Sånn sett burde de vært mer involvert og brydd seg mer om hvordan ting skjer på sykehuset. De burde komme å observere, og få en større følelse av hvordan det er å være på sykehuset.» (Superbruker, informant 5) Babels tårn
- 37. Brukermedvirkning (Arnstein, 1969) 8. Brukerkontroll: Brukerne håndterer hele jobben med planlegging, politikkutforming og administrasjon av et program. 7. Delegering: Brukerne har et klart flertall av setene i komiteer med delegert myndighet til å ta beslutninger. Prosjektledelsen har makten til å sikre ansvarlighet for programmet overfor dem. 6. Partnerskap: Makt omfordeles gjennom forhandlinger mellom brukere og ledlesen. Planleggings- og beslutningsansvar deles f.eks. gjennom fellesutvalg. 5. Plassering: For eksempel samvalg av håndplukkede brukere i komiteer. Det lar brukerne gi råd eller planlegge, men beholder ledelsens rett til å bedømme legitimiteten eller gjennomførbarheten av disse rådene. 4. Konsultasjon: Brukene blir konsulert om deres meninger og råd, men har ikke makt til å vedta beslutninger. 3. Informere: Et første skritt til legitim deltakelse, men hvor vekten legges på en enveis flyt av informasjon og det er ingen kanal for tilbakemelding.
- 38. Tidslinje: Anbud, Kontrakt, Implementasjon 38 Jeg skrev kronikk her
- 39. Kronikk i Adressa før golive ved St.Olavs • Dersom man tar advarslene fra helsearbeiderne nok på alvor til å stille spørsmål ved pasientsikkerheten, blir neste spørsmål hvilke konsekvenser dette bør ha for prosjektet Helseplattformen. • Systemet bør verken igangsettes eller skrotes, men testes grundig med reelle brukere i realistiske scenarioer for å få svar på de åpne spørsmålene rundt pasientsikkerheten. • Mitt forslag er at de ansvarlige for innføring av Helseplattformen ved St. Olavs hospital følger beste praksis innen utvikling av IT-systemer og sier: “Vi tar bekymringene fra helsearbeiderne på alvor og setter innføringen av Helseplattformen på vent inntil vi har fått testet systemet grundig og kan garantere at pasientsikkerheten er god nok”
- 40. 79 Copyright © 2023 by Boston Consulting Group. All rights reserved. Verifikasjon av brukervennlighet: Brukervenn- lighet i fokus fra start, men ikke grundig testet Flere av feilene som har blitt rapportert etter go-live ved STO har blitt klassifisert av HP AS som brukerfeil – intervjuene peker imidlertid på at når mange brukere gjør samme feil, vitner det om for dårlig brukervennlighet Arbeidet med design av Helseplattformen har ikke vært tilstrekkelig med tanke på en intuitive og helhetlige brukerreiser • Fageksperter har i stor grad spesifisert krav basert på funksjonalitet i enkeltmoduler, med begrenset mulighet til å se helhetlig funksjonalitet • Flere intervjuer peker på at applikasjonsutviklerne i liten grad har blitt støttet av ressurser med kompetanse innen arkitektur og UX- design (design av brukergrensesnitt), samt at det har vært for få ressurser til å jobbe med helheten (kun 4 virksomhetsarkitekter) • Unntaket er HelsaMi, som har hatt flere UX-designere involvert I kravspesifikasjonen til Helseplattformen var brukervennlighet et fokusområde, men dette har ikke blitt tilstrekkelig fulgt opp • Testing fokusert på å sjekke av løsningen mot krav, men brukeropplevelse har i liten grad eksplisitt testet • Eksempelvis peker flere intervjuobjekter på at det burde vært mer bruk av negativ testing for å undersøke hva som skjer hvis brukeren gjør noe annet enn det som er tiltenkt 5. Årsaker D. Løsning og leveranser Intuitivitet i løsningen er fraværende Det har vært en diskusjon om de feilene vi ser nå er tekniske feil eller brukerfeil – men brukerfeil skyldes i sin tur et for komplekst system Det er gjort en stor mengden testing, men man har ikke i stor nok grad sett på helheten Brukergrensesnittet til Helseplattformen er krevende – det visste de da de valgte Epic Det har vært for dårlig arbeid med design – mangel på UX-kompetanse Testing: Det har vært for lite fokus på hva som skjer når brukerne gjør noe annet enn det som er tenkt Vi prøvde å spille inn brukervennlighetstest, men fikk ikke gjennomslag for det D2. Verifikasjon av brukervennlighet Samtidig trekkes det frem av flere at overgangen til strukturert journal i liten grad vil oppleves som brukervennlig. Det var kjent fra start fra start at Epic sitt brukergrensesnitt er krevende. Dette kan tyde på mangelfull forventningsstyring rundt brukervennlighet Utvalgte sitater som illustrerer poengene: Brukervennlighet har forsvunnet gradvis og blitt hentet frem på oppløpssiden
- 42. Konklusjon • Mange gode intensjoner og mye er gjort riktig. • Mye av problemet ligger i valg av leverandør (Epic): • Et “stivbeint” IT-system som gjør det vanskelig å gjøre endringer raskt. • Gammeldags brukergrensesnitt gir dårlig brukervennlighet. • En innføringsmetodikk som er gammeldags (vannfall, kontraktsstyrt). • Stor avstand mellom høynivå krav og faktisk kjørende system. • Dette er koblet med mangler ved den norske delen av prosjektet: • Manglende IT-kompetanse fra store IT-prosjekter. • Manglende vilje til å lytte til brukerne (fakkeltog, “brukerfeil”, “støy”). • Overmot (hybris) i forhold til tid og ressurser. • Prosjektstyringsverktøy som fjerner ledelsen fra praksisfeltet.
- 43. Til neste store IT-prosjekt innen helse • IT-kompetanse: Ansett nok folk i ledelsen med erfaring fra store IT-prosjekter. • Sett krav til leverandøren(e). Vær kritisk og krev å få “prøve varen” før man skriver kontrakt. • Gi brukerne reell makt og respekter deres kompetanse og opplevelser. • Jobb praksisnært og gjør utviklingen iterativt i små skritt sammen med brukerne. • Vær selvkritisk i forhold til visjoner, abstraksjoner og modeller. Tenk «taus kunnskap». • Ikke vær redd for å si at dette er vanskelig og å bli «skitne på fingrene». • Legg inn nok tid og ressurser. Ikke stress.
- 44. Radikalt forslag: Gi brukerne vetorett før golive. 8. Brukerkontroll: Brukerne håndterer hele jobben med planlegging, politikkutforming og administrasjon av et program. 7. Delegering: Brukerne har et klart flertall av setene i komiteer med delegert myndighet til å ta beslutninger. Prosjektledelsen har ansvar for å sikre ansvarlighet for programmet overfor dem. 6. Partnerskap: Makt omfordeles gjennom forhandlinger mellom brukere og ledlesen. Planleggings- og beslutningsansvar deles f.eks. gjennom fellesutvalg. 5. Plassering: For eksempel samvalg av håndplukkede brukere i komiteer. Det lar brukerne gi råd eller planlegge, men beholder ledelsens rett til å bedømme legitimiteten eller gjennomførbarheten av disse rådene. 4. Konsultasjon: Brukene blir konsulert om deres meninger og råd, men har ikke makt til å vedta beslutninger. 3. Informere: Et første skritt til legitim deltakelse, men hvor vekten legges på en enveis flyt av informasjon og det er ingen kanal for tilbakemelding.
- 45. Relevansen av filosofi (men må “oversettes”) • Mye av kritikken av ingeniørtradisjonen og kognitivismen er fremdeles relevant. • Språkets begrensninger: • “Taus kunnskap” (Polanyi) • “Språkspill” (Wittgenstein) • Praksis og situerthet • “Væren i verden” (Heidegger) • “Livsverden” (Husserl) • Makt, arbeid og frigjøring (Marx) • Kropp og arbeid • “Den levde kroppen” (Merleau-Ponty)
- 46. Litteratur • Boston Consulting Group. “Ekstern evaluering av Helseplattformen.” 2023 • Helsetilsynet. “Rapport fra tilsyn ved St. Olavs hospital etter innføring av Helseplattformen. Tilsynsrapport etter alvorlig hendelse.” 2023. • Adrian Sand. “Utfordringer med brukermedvirkning og implementasjon av et storskala helseinformasjonssystem: En case studie om Helseplattformen”. Masteroppgave i Informatikk. NTNU, 2023. • Zahlsen, Øivind Klungseth, Dag Svanæs, and Yngve Dahl. "Representative Participation in a Large-Scale Health IT Project." Computer Supported Cooperative Work (CSCW) (2022): 1-38. • Ehn, Pelle. Work-oriented design of computer artifacts. Diss. Arbetslivscentrum, 1988. • Suchman, Lucy A. Plans and situated actions: The problem of human-machine communication. Cambridge university press, 1987. • Polanyi, Michael. "The tacit dimension." Knowledge in organisations. Routledge, 2009. 135-146. • Dreyfus, Stuart E., and Hubert L. Dreyfus. "A five-stage model of the mental activities involved in directed skill acquisition." (1980).