INOM
EXAMENSARBETE TEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2020,
Sjukvårdspersonalens behov och involvering vid utveckling av
journalsystem
JOSEFIN DANIELSSON MELANIE KOLLER
KTH
SKOLAN FÖR INDUSTRIELL TEKNIK OCH MANAGEMENT
Examensarbete Integrerad Produktutveckling Grundnivå, 15 hp, kurskod MF131x
Sjukvårdspersonalens behov och involvering vid utveckling av journalsystem
Josefin Danielsson Melanie Koller
Examinator
Sofia Ritzén
Handledare
Magnus Eneberg och Gunilla Ölundh Sandström
Sammanfattning
Det svenska vårdsystemet står inför en rad utmaningar relaterade till de journalsystem som används idag. Sjukvårdspersonalen upplever svårigheter med systemen vilket påverkar det dagliga arbetet inom vården. Undersökningar visar att personal behöver använda sig av flera olika system för att få en helhetsbild över en patients situation, vilket försvårar en fungerande vårdkedja. Kommunikationen mellan utvecklare och sjukvården är komplex eftersom de inte är insatta i varandras arbetssätt och det saknas även enheter som ansvarar för att föra samman sjukvårdspersonalens behov på ett strukturerat sätt.
Denna rapport syftar till att undersöka om och i så fall hur sjukvårdspersonalens behov och upplevelser integreras vid utveckling av journalsystem samt om detta har resulterat i att systemet uppfyller användarnas behov. Fokus för studien har varit på journalsystemet TakeCare vilket är det dominerande journalsystemet inom Region Stockholm.
Arbetet som denna rapport består av utgörs delvis av en litteraturstudie för att bygga en teoretisk bakgrund om användarcentrerade produktutvecklingsprocesser, analysmetoder för behovsidentifiering, hur användarinvolvering kan bedrivas och svårigheter som kan finnas.
Rapporten utgörs även av en empirisk studie bestående av semistrukturerade intervjuer där totalt sex respondenter har medverkat. Dessa respondenter utgörs av en produktägare för ett utvecklingsteam, en chef på ett förvaltningsföretag, en vårdadministrativ chef på ett
akutsjukhus samt sjukvårdspersonal. Vidare så genomfördes en analys, jämförelse och diskussion gällande den information som erhållits från teorin och den empiriska studien.
Resultatet av studien visar att det sker användarinvolvering under produktutvecklingen av
TakeCare men inte i den omfattning som behövs för att uppfylla användarnas behov. Det
framgår att detta inte beror på en ovilja till involvering, utan främst på att det finns en avsaknad av struktur i processen och kommunikation mellan utvecklare och användare. Det behov som återkommande uttrycks av användarna och som inte uppfylls är avsaknaden av tillräcklig kompatibilitet mellan journalsystemet och andra system inom vården. Avsaknad av kompatibilitet gör att användarna måste utföra dubbelt arbete vilket både har en inverkan på patientsäkerheten och tar tid från att vårda patienter.
Nyckelord: produktutveckling, användarinvolvering, användarcentrerad produktutveckling
behov, systemutveckling, journalsystem och sjukvård
Degree project in Integrated Product Development First cycle, 15 cr, course code MF131x
Needs and involvement of the healthcare workers in the development process of electronic medical records
Josefin Danielsson Melanie Koller
Examiner
Sofia Ritzén
Supervisor
Magnus Eneberg och Gunilla Ölundh Sandström
Abstract
The swedish healthcare system is facing some challenges related to the electronic medical records that are being used. The healthcare personnel are experiencing some difficulties with the systems, which affects their daily work in a negative aspect. Studies have shown that the personnel actively must use different systems in parallel to get a complete understanding of a patient's status. Furthermore, this makes the care system as a whole more complicated and inadequate.The communication between developers and healthcare can be seen as a complex process since they do not have an complete understanding of each others ways of working.
Also, units for bringing together user needs in a structured manner does not exist.
This study aims to examine if, and if so, how the needs of healthcare personnel are being involved in the development process of electronic medical records and if this has resulted in a more user adaptive system. The study will focus on the electronic medical record named TakeCare, which is the most used electronic medical record system inside Region Stockholm.
This report partly consists of a literature study that aims to establish a theoretical background focusing on user-centered processes of product development, methods for analysing user needs, how user involvement can be conducted and what kind of difficulties that can be identified. The report also consists of an empirical study with focus on semi structured interviews with six different respondents. These respondents are both healthcare personnel, a product owner for a development team, a chief from a company that specializes in managing the electronic medical record TakeCare and a chief specialized in administrative healthcare.
Furthermore, an analysis, a comparison and a discussion were followed out concerning the
information gained from the theory and empirical study.
The results from the study shows that user involvement during the product development process of TakeCare exists, but not to an enough extent that fulfills the user needs. This is not caused by unwillingness to adapt user involvement in the process, but a lack of structure and inadequate communication between developers and users. One particular user need that repeatedly has been expressed by the healthcare personnel, but not been fulfilled, is the lack of software compatibility between the electronic medical record and other electronic systems within the healthcare sector. The lack of software compatibility have resulted in that the users having to perform the same task repetitively, which has an impact on patient safety but also results in reduced time spent on the patients.
Keywords: product development, user involvement, user-centered product development,
needs, system development, health care system and electronic medical records
Förord
Denna rapport har genomförts som ett kandidatexamensarbete inom kursen MF131X Integrerad Produktutveckling på Kungliga Tekniska Högskolan under vårterminen 2020.
Denna studie behandlar användarinvolveringen med avseende på utvecklingen av
journalsystemet TakeCare. Användarinvolvering i produktutvecklingsprocesser är något vi är väldigt intresserade av och vi hoppas att denna studie kan bidra till en positiv utveckling av journalsystem inom sjukvården.
Vi vill tacka alla respondenter för att ni har ställt upp och gjort vårt arbete möjligt att utföra.
Det har varit väldigt spännande att få kunskap om hur ni arbetar. Vi vill också tacka vår handledare Magnus Eneberg som har varit ett stort stöd för oss under hela processen.
Josefin Danielsson och Melanie Koller
Kungliga Tekniska Högskolan, Stockholm, juni 2020
Innehållsförteckning
1. Introduktion
...11.1 Problematisering
...11.2 Syfte
...21.3 Frågeställningar
...21.4 Avgränsningar
...22. Teoriområde
...32.1 Produktutvecklingsprocessen
...32.2 Användarinvolvering
...42.2.1 Typer av användare ...4
2.2.2 Olika typer av behov hos användare ...5
2.2.3 Grad och metoder för användarinvolvering ...6
2.2.4 För- och nackdelar med användarinvolvering ...8
3. Metod
...93.1 Teoretisk referensram: databaser
...93.2 Datainsamling
...93.3 Analys av data
...93.4 Val av respondenter
...103.5 Kvalitetsmått
...114. Resultat
...124.1 Sjukvårdspersonalens behov
...124.2 Produktutvecklingsprocessen
...144.3 Metoder för användarinvolvering
...154.4 Problem vid användarinvolvering
...175. Diskussion och analys
...205.1 TakeCare anses inte vara tillräckligt kompatibelt med andra system
...205.2 CGM och Acceptus arbetar med användarinvolvering på olika sätt
...205.3 Agila och integrerade processer innebär bättre användarinvolvering
...215.4 Användarbehov prioriteras olika vid utvecklingen
...225.5 Typ av utvecklingsprojekt avgör mängd och metod för användarinvolvering
...235.6 Det finns återkommande problem med användarinvolvering
...235.7 Det finns faktorer som hindrar genomförandet av användarinvolvering
...246. Slutsatser
...26Referenslista
...27Bilaga
... I1
1. Introduktion
I detta kapitel kommer studiens problematisering, syfte, frågeställningar och avgränsningar att behandlas.
1.1 Problematisering
Det svenska vårdsystemet står inför en rad utmaningar relaterade till de journalsystem som används (Grilo, Lapao, Jardim-Goncalves & Cruz-Machado, 2009). Det är viktigt att systemen är uppdaterade till den rådande arbetssituationen inom vården och anpassad till användarens roll (Scandurra, Nordström, Friberg, Wedin, Willman & Ribeiro, 2013). En viktig aspekt vid produktutveckling av system inom vården är att processen bör utgå från behoven och det måste ske en kontinuerlig optimering av systemen med avseende på användbarheten (Scandurra et. al., 2013).
En brist i dagens system som belyses av Socialstyrelsen (2019) är avsaknaden av enheter som ansvarar för att sammanföra förslag och idéer på ett strukturerat sätt och att detta vidare leder till att behov och åsikter inte förs vidare till utvecklarna av systemen. Även kommunikationen mellan sjukvården och utvecklarna beskrivs som väldigt komplex på grund av att de inte är insatta i varandras arbetssätt, vilket försvårar samarbetet (Nilsson, Sikvall, Tuutma & Mella, 2014). Detta innebär en utmaning för utvecklarna att förstå sjukvårdspersonalens behov och göra ställningstagande under utveckling av systemen, vilket är av stor betydelse då forskning visar att industri och sjukvård behöver god kommunikation och samverkan (Kushniruk &
Turner, 2012; Socialstyrelsen, 2019). Ett annat problem är bristande kunskap hos produktutvecklare och ansvariga för framtagande av systemen angående hur sjukvården fungerar, vilket kan resultera i konsekvenser för sjukvårdspersonalen som ska använda sig av systemet och vidare orsaka brister i vården av patienterna (Cresswell, Morrison, Crowe, Robertson & Sheikh, 2011; Cederberg, 2016). Den otillräckliga vetskapen om sjukvårdens yrkesutövning gör det svårt att förbättra och utveckla systemen som används (Scandurra et al., 2013).
En stor problematik enligt Socialstyrelsen (2019) är att systemen som används av
sjukvårdspersonalen inte är kompatibla med varandra, vilket resulterar i att det blir svårt att åstadkomma en vårdkedja som fungerar. Scandurra et al. (2013) beskriver även att
dubbeldokumentation inom vården måste upphöra genom att information endast ska behövas registreras en gång och automatiskt kunna kommuniceras till andra system. Detta belyses av Airaksinen (2015) och Grilo et al. (2009) genom att det saknas ett enhetligt system inom sjukvården. Det finns flera dokumenterade konsekvenser med icke kompatibla system, förutom att systemen blir mer svåranvända för vårdpersonalen så kan det innebära att patienter påverkas negativt och utsätts för risk (Airaksinen, 2015; Lundgren, Stiernstedt &
Olofsson, 2014). Enligt Socialstyrelsen (2019) är det av betydelse att i utvecklingen göra en
noggrann och omfattande identifiering av de behov som personalen inom vården har, vilket i
2
sin tur kräver en nära kontakt med de aktörer som är involverade och kan bidra till utveckling av lösningar samt förbättringar.
1.2 Syfte
Syftet är att undersöka om och i så fall hur sjukvårdspersonalens behov och upplevelser integreras vid utveckling av journalsystem samt om detta har resulterat i att systemet uppfyller användarnas behov.
1.3 Frågeställningar
•
Om och i så fall hur involveras sjukvårdspersonal vid utvecklingen av journalsystem?
•
Vilka huvudsakliga behov upplever sjukvårdspersonalen att de vill ha integrerat i utvecklingen av journalsystem?
1.4 Avgränsningar
Olika journalsystem som används i Sverige beaktas inte i rapporten utan studien behandlar enbart systemet TakeCare. Detta eftersom studien är fokuserad på Region Stockholm där TakeCare är det dominerande journalsystemet.
3
2. Teoriområde
I detta kapitel presenteras den teoretiska bakgrund och relevanta teorier som studien bygger på. Sammanlagt utgör detta kapitel ett underlag för att stödja den formulerade
frågeställningen. Syftet är att ge läsaren nödvändig kunskap som vidare utgör basen för den analys och de slutsatser som arbetet syftar till.
2.1 Produktutvecklingsprocessen
Att ha en strukturerad produktutvecklingsprocess är väldigt viktigt och betydelsefullt för framtagande av nya produkter (Ullman, 2014). Produktutveckling innebär också en
komplicerad process dominerad av osäkerhet och föränderliga omständigheter (Johansson, 2018). Genom att arbeta strukturerat utifrån en särskild produktutvecklingsprocess ökar sannolikheten att projektet genererar ett positivt resultat och idag används många olika typer av strukturerade processer vid produktutveckling (O’Connor, 2003).
En vanlig process inom produktutveckling är Vattenfallsmodellen, en sekventiell process som innebär att nya uppgifter i ett utvecklingsprojekt startar efter att andra har slutförts (Johns, 2002). Den traditionella produktutvecklingsprocessen innebär även att utveckling sker utan utbyte mellan olika team eller avdelningar (Rainey, 2005). När informationssystem började utvecklas så var Vattenfallsmodellen en dominerande metod hos företag (Johns, 2002), men den har fått en del kritik riktat mot sig. Modellen har blivit kritiserad för att den inte är anpassningsbar mot förändringar (Jalote, 2005; Gustavsson, 2007), vilket är problematiskt i till exempel mjukvaruprojekt där ändringar är vanliga och användarna själva inte alltid är medvetna om vilka behov de har (Jalote, 2005).
Idag har många i branschen gått över till en mer flexibel process (Nerur, Mahapatra &
Mangalaraj, 2005). Detta eftersom systemutvecklingsprojekt ställer krav på metoder som kan möta kraven på flexibilitet och den osäkerhet som projekten innebär (Azanha, 2016;
Tonnquist, 2018). I systemutvecklingsprojekt är agilt arbetssätt vanligt, vilket till skillnad från
Vattenfallsmodellen inte utgår ifrån detaljerade krav för att kunna skapa en anpassningsbarhet
till de ändrade behov som kan uppstå under projektets gång (Gustavsson, 2007). Figur 1 visar
en jämförelse mellan Vattenfallsmodellen och agila metoder.
4
Figur 1 - En illustration av Vattenfallsmodellen och agilt arbetssätt
Agilitet har i motsats till Vattenfallsmodellen en cyklisk process där kontinuerliga
feedbackloopar och täta leveranser är centralt för att kunna hantera och upptäcka förändringar i tid (Tonnquist, 2018; Azanha, 2016; Afshin, 2016). En central agil princip är att ha nära kommunikation med slutanvändarna, vilket har visat sig vara framgångsrikt för att utveckla produkter som matchar efterfrågan (Tonnquist, 2018).
Som en motsats till traditionella metoder som inte innebär integrerat arbete i team, så är integrerad produktutveckling ett arbetssätt som däremot bygger på kommunikation mellan team i ett projekt (Rainey, 2005). Enligt Naveh (2005) så resulterar ett integrerat arbetssätt där olika professioner samarbetar synkroniserat för att rätt beslut ska kunna tas i
utvecklingsprojekt. Däremot kan det uppstå en utmaning med integrerad produktutveckling i stort projekt som innefattar utveckling av en komplex produkt och ett arbetsteam med personer från många olika discipliner (Wheelwright & Clark, 1992).
2.2 Användarinvolvering
I det här avsnittet kommer teorier som är fokuserade på användarinvolvering i produktutvecklingsprocessen att presenteras.
2.2.1 Typer av användare
Det finns olika sätt att kategorisera in användare av en produkt och enligt Westerlund (2009)
är det viktigt att vara medveten om vem som är användaren och hur denne ska involveras i
utvecklingsprocessen. Den självklara användaren är de personer som kommer bruka och
integrera med den slutliga produkten, det vill säga slutanvändaren (Abras, Maloney-Krichmar
5
& Preece, 2004; Gulliksen & Göransson, 2002). Enligt Abras et al. (2004) är det viktigt att känna till vilka intressenterna är vid produktutveckling, men att representanter från alla intressenter nödvändigtvis inte behöver vara aktivt delaktiga i användarinvolveringen.
Däremot är det väldigt viktigt att vara medveten om vilken effekt en produkt har på alla intressenter (Abras et al., 2004).
2.2.2 Olika typer av behov hos användare
En metod för att analysera behov hos användarna är Kano-modellen som beskriver graden av kundens nöjdhet mot produktens funktion (Ullman, 2014), se figur 2.
Figur 2 - Illustration efter Kano-modellen (Ullman, 2014)
Tre olika typer av behov finns i modellen vilket är basbehov, uttalade behov och outtalade behov. Basbehov innebär de behov som förväntas göra användarna tillfredsställda av produkten och ses som självklara för produktens funktion. Uttalade behov är de behov som användarna anser är betydelsefulla egenskaper hos produkten, även om de inte är nödvändiga för den grundläggande funktionen. Däremot menar Ullman (2014) att behov som användaren själv inte har beskrivit eller kan beskriva, men som trots detta ger en hög grad av
behovstillfredsställelse, kallas för outtalade behov. Kano-modellen är ett verktyg för att
analysera användarnas behov, men en svårighet med metoden är att behoven förändras med
tiden vilket kan resultera i att kravbilden som formulerats i början måste förändras (Karlsson,
1996). Detta är en utmaning vid produktutveckling och Karlsson (1996) menar att processen
därför behöver vara integrerad och bestå av iterationer för att undvika att utvecklarna har en
felaktig förståelse för de aktuella behoven. Däremot beskriver Ullman (2014) genom Design-
paradoxen betydelsen av att sätta systemkrav tidigt eftersom designfriheten är som störst och
6
kostnaden som lägst i början av processen. Däremot säger Ullman (2916) även att förståelsen för den produkt som ska tas fram är lägre i början, vilket därför kan resultera i att
systemkraven ändå måste ändras senare i processen.
2.2.3 Grad och metoder för användarinvolvering
Det finns olika grader och metoder av användarinvolvering i en utvecklingsprocess som handlar om relationen mellan utvecklare och användare. Enligt Abras et al. (2004) så kan användaren involveras vid en specifik tidpunkt i produktutvecklingsprocessen alternativt genom hela processen. Vanliga metoder är intervjuer, observationer, workshops och tester av olika slag (Abras et al., 2004), se tabell A.
Tabell A - metoder för involvering av användare (Abras et al, 2004)
Metod Syfte Var i processen
Intervjuer Insamling av data relaterat till användaren och dess behov, evaluering av iterationer eller slutprodukten
Tidigt eller i slutet av processen Fokusgrupper Inkludera en stor bredd av intressenter för att diskutera
problem och krav
Tidigt i processen
Tester Insamling av kvantitativ data relaterad till användandet av produkten
Tidigt eller i slutet av processen
Vid intervjuer i början av en process samlas data in för att få information om användarens behov och förväntningar på produkten (Abras et al., 2004).Vid ett senare skede kan en intervju göras med avseende på användarnas tillfredsställelse med produkten. Även användning av fokusgrupper ger värdefull information om användartillfredsställelse och eventuella problem med produktens funktion kan behöva åtgärdas. Användartester är en metod som fokuserar på användarnas behov med avsikt att förbättra produktens användbarhet.
Detta görs genom att involvera verkliga användare i testningen som utför uppgifter relaterat till produkten som sedan får ge feedback på upplevelsen av produkten och dess funktioner (Abras et al., 2004).
För att få en vägledning på vilka effekter som kan förväntas med olika metoder av
användarinvolvering så kan en särskild grad analyseras (Mumford, 1995), se tabell B. Till
skillnad från Abras et al. (2004) som betonar olika metoder för användarinvolvering så går
Mumford in på olika typer som ger olika grader och inflytande av involvering.
7
Tabell B - Grad av användarinvolvering (Mumford, 1995)
Typ Direkt/
indirekt
Grad av involvering
Exempel
Informativ Indirekt Lågt Användare ger samt tar emot information
Konsultativ Blandat Medel Användare ger feedback på alternativ
Medverkande Direkt Högt Användarna påverkar beslut som påverkar
resultatet
Mumford (1995) beskriver metoderna som informativ, konsultativ och medverkande
involvering. Dessa definieras som låg till hög grad utifrån hur mycket användarna involveras.
Systemutvecklingsprojekt där användarinvolveringen är låg kan leda till små effekter på användarnas nöjdhet med produkten, däremot innebär hög grad av involvering även högre kostnader men att användarna blir mer tillfredsställda (Al-Rahman & Quach, 2012). För att kunna välja rätt metod av användarinvolvering så är det enligt Damodaran (1996) väsentligt att ha förståelse för vilken typ av involvering som är relevant för situationen. I situationer där användarna inte involveras tillräckligt i processen så finns det enligt Damodaran (1996) en risk att den utveckling som görs inte är i enlighet med vad användarna förväntar sig.
En process där användarna är en central aspekt i utvecklingsprocessen är Användarcentrerad design som fokuserar på användbarhet (Gulliksen & Görsansson, 2002). Gulliksen et al.
(2002) och Maguire (2001) är eniga om att användaren ska involveras aktivt i
Användarcentrerad design och att det ska skapas en tydlig förståelse för användarens krav och behov. Det sker en iterativ utveckling när alla designlösningar skapas genom att enkla
prototyper utvecklas och testas på användarna (Gulliksen et al., 2002; Maguire, 2001), detta illustreras i figur 3.
Figur 3 - En illustration av Användarcentrerad designprocess
8
Efter återkoppling så kan utvecklarna ändra i prototypen så att användarnas behov blir uppfyllda (Gulliksen et al., 2002; Maguire, 2001). Att ta reda på kundernas behov och att pröva olika koncept med användarna är en iterativ process och möjliggör för utvecklarna att verifiera den bästa lösningen (Abras et al., 2004).
2.2.4 För- och nackdelar med användarinvolvering
Även om involvering av användare i produktutvecklingsprocessen bidrar till många positiva aspekter så finns det även enligt Al-Rahman et al. (2012) en rad nackdelar som är viktiga att känna till. Det tar ofta mycket tid, är dyrt och ansträngande för både användarna och
utvecklarna. Ett annat problem är att om det i utvecklargrupper saknas en grundläggande förståelse för system som ska utvecklas så blir det svårt att ge användbar feedback och förbättringsförslag. Det kan även vara en utmaning att mäta vilket värde som involvering av användare tillför, vilket kan resultera i att produktägare inte vill riskera för mycket resurser på detta (Al-Rahman et al., 2012).
Samtidigt finns en stor riskfaktor i att inte involvera användare tillräckligt eftersom det kan leda till att viktiga krav inte integreras på grund av brist på förståelse av behovet, som i sin tur resulterar i en misslyckad produkt som användarna inte är tillfredsställda med (Al-Rahman et al., 2012; Ullman, 2014). Det finns enligt Ullman (2014) fördelar med att fokusera på
användarinvolvering tidigt i produktutvecklingsprocessen eftersom designfriheten är stor,
men en nackdel är att kunskapen om det som ska utvecklas är som lägst tidigt i processen. En
felaktig förståelse kan resultera i att ändringar behöver göras senare som blir mer kostsamma
ju längre projektet fortskrider (Ullman, 2014).
9
3. Metod
I detta kapitel kommer metoden att presenteras med avseende på hur studien har genomförts.
Struktur och tillvägagångssätt kommer att beskrivas, respondenter och organisationer som involverats och varför just dessa har valts till studien.
3.1 Teoretisk referensram: databaser
En kvalitativ litteraturstudie genomfördes med syfte att beskriva det nuvarande
kunskapsläget. I den teoretiska referensramen används olika synvinklar på frågeställningarna som är hämtade från databaserna DiVA och Google Scholar. Relevanta ämnen som dessa rapporter har behandlat är produktutvecklingsprocesser inom systemutveckling samt olika metoder och modeller inom användarinvolvering.
Sökord som främst användes i litteraturstudien är produktutveckling, användarinvolvering, behov, systemutveckling, användare, användarcentrerad produktutveckling och
journalsystem. Litteratur har använts både på svenska och engelska vilket innebär att sökorden har använts på båda språken.
3.2 Datainsamling
I rapporten benämns sjukvårdspersonalen även som användarna av TakeCare. Hur dessa användare har involverats vid produktutveckling av journalsystemet har undersökts utifrån två olika perspektiv: Utvecklarnas och förvaltarnas men även användarnas. Kvalitativa metoder med semistrukturerade intervjuer har använts som metod för insamling av data vilka är baserade på studiens frågeställningar. På grund av att två perspektiv har studerats så har olika intervjuguider använts: en för personalen på sjukhusen samt en för produktägaren och
förvaltaren, se Bilaga 1 för kompletta intervjuguider. Intervjuerna leddes av ena författaren medan den andra främst hade som uppgift att ta anteckningar under tiden och även
komplettera med frågor utöver intervjuguiden. Två av intervjuerna har genomförts fysiskt, varav en genom besök på respondentens arbetsplats. På grund av risk för smittspridning av Covid-19 i samhället har resterande intervjuer genomförts via Zoom och Google Hangouts, kommunikationsverktyg som erbjuder videokonferenser över nätet. Samtliga intervjuer har spelats in med godkännande från respektive respondent. Intervjuernas längd har varierat mellan 30-60 minuter.
3.3 Analys av data
För att analysera den empiriska datan som införskaffades under intervjuerna så
transkriberades dessa genom att noggrant anteckna allt som sades av både respondenten och
författarna. Vidare analyserades all data konsekvent med syfte att tydliggöra och hitta relevant
information till studiens frågeställning. Relevanta ämnen och information kodades med färg
10
och viktiga nyckelord markerades. Utifrån färgkodning och nyckelord sammanfattades de transkriberade intervjuerna utifrån ämnesområden relevanta för studien. Utifrån dessa sammanfattningar utformades resultatet som vidare möjliggör en jämförelse mellan de olika organisationernas metoder samt användarnas behov,
3.4 Val av respondenter
För att få en bred förståelse för hur utvecklingen av journalsystemet TakeCare går till med avseende på användarinvolvering så har intervjuer med olika respondenter på företag och sjukhus genomförts. Eftersom avsikten med studien är att studera användarinvolvering både från utvecklarnas och användarnas perspektiv så har totalt sex intervjuer genomförts med företag, förvaltare och sjukvårdspersonal. Mer detaljerad information av de genomförda intervjuerna med dessa respondenter återfinns i Tabell C.
Tabell C - Detaljerad information om genomförda intervjuer
Respondent Titel Organisation Metod Datum
1 Produktägare CompuGroup Medical,
CGM
Videointervju 40 minuter
23-03-20
2 Chief Digital Officer Acceptus AB Fysisk intervju
60 minuter
04-03-20
3 Vårdadministrativ chef Sjukhus, Stockholm Videointervju 40 minuter
26-03-20
4 Anestesi- och
operationssjuksköterska
Sjukhus, Stockholm Fysisk intervju 40 minuter
23-03-20
5 Sjuksköterska Sjukhus, Stockholm Videointervju
30 minuter
02-04-20
6 Sjuksköterska Sjukhus, Stockholm Videointervju
30 minuter
03-04-20
Respondent 1 är produktägare i back-end teamet på företaget CompuGroup Medical, CGM,
som utvecklar journalsystemet TakeCare. Back-end innebär arbete med bakomliggande data
som inte är synliga för användarna, i motsats till front-end som är den del användarna ser och
integrerar med. Respondent 2 är Chief Digital Officer och grundare till konsultföretaget
Acceptus som bland annat arbetar med förvaltning, support, utbildning och införande av
TakeCare till privata vårdgivare. Både CGM och Acceptus ägnar sig åt så kallad business to
business, det vill säga att deras kunder utgörs av andra företag och verksamheter. Respondent
11
3 är vårdadministrativ chef inom akut och reparativ medicin på ett akutsjukhus som använder sig av TakeCare och sitter även med som representant i Framtidens Vårdmiljö, FVM.
Respondent 4, 5 och 6 är alla sjuksköterskor som jobbar på akutsjukhus i Stockholm och använder TakeCare i det vardagliga arbetet.
3.5 Kvalitetsmått
Studiens resultat baseras på ett flertal intervjuer där respondenten yttrat sin egen uppfattning och erfarenheter vilket leder till att resultatet ej kan antas vara en generalisering.
Respondenterna på företagen har god erfarenhet av produktutvecklingen av TakeCare och även den intervjuade sjukvårdspersonalen har god erfarenhet av användning av
journalsystemet från olika avdelningar och sjukhus. Det som dock måste tas i beaktning är att när behoven hos sjukvårdspersonalen studerats så har endast en typ av profession,
sjuksköterskor, representerat sjukvårdspersonalen. Detta har inte varit en avsiktlig
avgränsning utan är en konsekvens av den höga belastning som finns inom sjukvården idag på grund av Covid-19. Då ingen avgränsning skett från utvecklarnas perspektiv utan att empirin från resterande respondenter gjorts utifrån olika professioner, så ser vi detta ändå som
representativt. Gällande utvecklarna så har endast en produktägare från back-end teamet har
intervjuats men då respondenten även har insikt i hur användarinvolvering sker i front-end
teamet så är detta inget som påverkar kvaliteten i högre grad. Studiens kvalitet har förstärkts
genom att den teoretiska referensramen grundar sig i studier av hög kvalitet och är vanligt
förekommande. Dessa faktorer skapar tillsammans en god reliabilitet och validitet för studien
som genomförts.
12
4. Resultat
Detta kapitel innefattar den data som samlats in från den kvalitativa undersökningen via genomförda intervjuer med respondenterna som beskrivits i kapitel 3. Resultatet presenteras utifrån fyra identifierade teman; Sjukvårdspersonalens behov, produktutvecklingsprocessen, metoder för användarinvolvering samt problem vid användarinvolvering.
4.1 Sjukvårdspersonalens behov
I det här avsnittet presenteras de behov som respondenterna uttryckt att de själva och sjukvårdspersonal har gällande journalsystemet TakeCare. Avsnittet är uppdelad i
underrubrikerna Respondent 3, Respondent 4, Respondent 5 och Respondent 6. Respondent 1 och 2 uttryckte inte några återkommande behov hos användarna och medverkar därför inte i 4.1.
Respondent 3
Respondent 3 beskriver journalsystemet som “otroligt användarvänligt” men att det samtidigt inte följt med i utvecklingen gällande vad vårdpersonal behöver kunna göra och se i ett
journalsystem. Respondent 3 menar att den allmänna opinionen på akutsjukhus är att systemet är “gammaldags och behöver bli mer innovativt”. Det mest återkommande behovet som Respondent 3 upplever från sjukvårdspersonalen är att olika system ska kunna prata med varandra och att all information gällande en patient ska finnas tillgängligt i samma system.
Respondent 3 beskriver främst två olika system som skulle behövas integreras i
journalsystemet: Kvalitetsregister och operationssystemet Orbit. Enligt Respondent 3 så är CGM, utvecklarna av TakeCare, väl medvetna om det här behovet eftersom det är ett uttryckt önskemål från Region Stockholm.
Vidare berättar Respondent 3 att försök har gjorts för att skapa ett och samma journalsystem i Sverige för att underlätta för vården, men det har hittills varit svårt att genomföra. På
akutavdelningar tror Respondent 3 att faktumet att olika journalsystem används på olika vårdenheter orsakar extra stora problem, eftersom man då inte kan komma åt journalerna snabbt och effektivt.
Respondent 4
Respondent 4 anser att det är lätt att journalsystemet är lätt att använda och navigera i samt tar upp fördelen med att funktioner såsom blodsvar och remisser länkas direkt till journalen.
Respondent 4 tog främst upp två större problem som hon upplever finns med journalsystemet.
Det första problemet är att journalsystemet inte är kompatibelt med andra informationssystem
på avdelningen, vilket innebär att den inskrivna informationen behövs föras över manuellt
mellan systemen. Till exempel använder sig ambulanspersonal av systemet Frapp för att
13
registrera patientens blodtryck och puls. Denna data behöver sedan skrivas in i TakeCare manuellt av sjukvårdspersonalen på akutmottagningen. Detta beskriver Respondent 4 tar mycket tid, särskilt i situationer där många ambulanser kommer in samtidigt och uttrycker att
“det hade varit bra om informationen kunde gå in direkt, vara automatiserat”. Att kunna överföra data som visar patientens blodtryck, puls och andningsfrekvens anser Respondent 4 även är betydelsefullt på avdelningen, eftersom personalen idag behöver gå fram och tillbaka från patienten till datorn för att logga in på nytt och skriva ner värdena i journalen.
Respondent 4 såg även problematiken med att sjukhus i Sverige använder sig av olika
journalsystem. Om en patient har varit på ett sjukhus utanför regionen eller hos en vårdgivare som inte använder TakeCare så kan sjukvårdspersonalen inte komma åt journalen utan att behöva ringa samtal, faxa eller maila. Detta beskriver Respondent 4 ta mycket tid från vardagliga arbetet med patienterna. I många fall så kan patienten själv berätta om sin journal, men det kan ha en negativ inverkan på patientsäkerheten om en patient är svårt skadad och inte kan uttrycka sig.
Respondent 5
Respondent 5 anser att TakeCare är ett användarvänligt och överskådligt journalsystem som är lätt att förstå. Faktumet att inte samma journalsystem används i Sverige eller överallt i Stockholm menar respondenten äventyrar patientsäkerheten. Till exempel om en patient inte själv kan redogöra för sin bakgrund så måste dubbelt arbete göras genom att få tag på
information om en patient i ett annat journalsystem. Respondent beskriver att “det är klart att saker kan missas” gällande viktig information om en patient som i och med detta kan bli svår att få tag på.
Respondent 5 önskar att journalsystemet kan prata med andra system och nämner som exempel EKG-övervakning, registrering av läkemedel i dospåsar och röntgenbilder.
Respondenten beskriver att all patientinformation även borde registreras på samma ställe för att sjukvårdspersonal inte ska behöva göra dubbelt arbete genom att gå in i externa system.
Respondent 6
Respondent 6 beskriver TakeCare som användarvänligt och lätt att förstå, men beskriver en risk i och med att information i patientjournalen inte sparas om två personer är inloggade i journalen vid samma tillfälle eftersom endast en person kan skriva åt gången. Detta gör att remisser behöver skickas som papper eller förmedlas via telefonsamtal.
Enligt respondenten är ett stort problem att samma journalsystem inte används i hela Region Stockholm eller landet och poängterar konsekvensen att journalen inte kan läsas av alla, vilket i sin tur resulterar i fördröjningar. Respondent 6 beskriver även att “detta påverkar
patientsäkerheten i högsta grad, till exempel att felaktig dos ordineras eller att samma prov
tas på en patient flera gånger’’. Respondent 6 beskriver vidare att kompatibiliteten mellan
14
journalsystemet Frapp inte alltid fungerar på ett bra sätt och att det medför en risk att gå miste om mycket förhandsinformation, eftersom det inte går att skriva över information från Frapp till TakeCare innan ambulansen är framme på akutmottagningen.
4.2 Produktutvecklingsprocessen
I detta avsnitt beskrivs hur utvecklingsprocessen av TakeCare går till. Avsnittet är indelat i att först beskriva den övergripande processen får att en användare har ett behov fram till att det kommer fram till utvecklarna. Perspektivet på utvecklingen beskrivs med data från
Respondent 1 och Respondent 3.
Respondent 1
Respondent 1 berättar att Region Stockholm är kund till CGM och att dessa lägger en beställning gällande TakeCare som både kan handla om förbättringar och nyutveckling.
Region Stockholm kan få inputs från bland annat privata aktörer men att det i slutändan är regionen som bestämmer vad som ska utvecklas.
CGMs säljare har regelbunden kontakt med Region Stockholm gällande utveckling av journalsystemet. Vidare har säljaren kontakt med produktägarna på företagets front-end och back-end avdelningar. Dessa två utvecklingsteam arbetar sedan integrerat utifrån krav och önskemål från Region Stockholm genom att ta fram lösningsbeskrivningar som sedan presenteras.
Respondent 1 beskriver att företaget arbetar enligt agila metoder där ärendena från Region Stockholm delas upp i ‘’små test- och releasebara delar’’ som fördelas på två veckors långa sprintar. Om allt går som det ska är ärendet färdigt för release i sista sprinten. Sprintdemos genomförs varannan vecka där hela kontoret får se vad alla andra team har arbetat med, i vissa fall är även kunden medverkande för att se vad som hittills utvecklats och komma med
åsikter. Ofta får CGM inledande in en beskrivning på vad kunden behöver men att “det är upp till oss utvecklare att ta reda på vad de egentligen vill ha”. Processen från att användarna uttrycker ett behov till att det når CGM är lång och enligt Respondent 1 har detta inte en negativ inverkan på möjligheten att uppfatta användarnas behov korrekt. Däremot säger Respondent 1 samtidigt att “de eventuella brister som finns kanske inte upptäcks av dem alls, eftersom de är sist i kedjan”.
Respondent 3
Processen från att ett behov gällande TakeCare uttrycks hos användarna och att det når fram
till utvecklarna består av flera steg. Användarna vänder sig först till ansvarig på avdelningen
som i sin tur kontaktar den lokala TakeCare-förvaltningen. Förvaltningen kan på egen hand
göra mindre justeringar utan att involvera utvecklarna på CGM, som till exempel att skapa en
behovsanpassad mall för en specifik avdelning eller säkerställa att den dagliga driften
15
fungerar. Anställda på TakeCare-förvaltningen har blandad kompetens som både IT- specialister och personer som tidigare arbetat inom sjukvården som till exempel läkare, sjuksköterska eller administratör. Vid större behov och justeringar som inte förvaltningen kan hantera så kontaktar de objektägarna, dvs beslutsfattarna på Region Stockholm.
4.3 Metoder för användarinvolvering
I detta avsnitt presenteras de olika respondenternas syn på hur användarinvolveringen för TakeCare går till. Avsnittet är uppdelat i sex delar utifrån Respondent 1 till och med Respondent 6.
Respondent 1
Respondent 1 berättar att användargrupper används under en del utvecklingsprojekt av
TakeCare. I dessa grupper försöker de få in användare från olika professioner på sjukhus och i primärvården samt förvaltare ute på sjukhusen. Grupperna har regelbundna möten i form av en workshop där deltagarna diskuterar framtagna lösningar och utvecklingsmöjligheter.
Respondent 1 beskriver att involveringen av användare ser olika ut beroende på typ av projekt. I samband med uppdrag där något helt nytt ska utvecklas eller stor vidareutveckling ska genomföras så “är det nästan helt nödvändigt att ha med kundgrupper tidigt, annars är risken stor att något blir fel”. Däremot i uppdrag som tar mindre än 40 timmar att utveckla och inte handlar om nyutveckling så är tidiga inputs inte prioriterade och användargrupper används ibland inte alls. Respondent 1 berättar även att användarinvolveringen skiljer sig åt beroende på om förändringen gäller driftspecifika önskemål eller det grafiska
användargränssnittet. Enligt Respondent 1 är ärenden för back-end teamet ofta tydliga för utvecklarna gällande vad som behövs och kräver därför ingen involvering av kund under arbetets gång, medan front-end teamet istället involverar användarna kontinuerligt under processen.
Respondent 1 berättar att CGM prioriterar önskemål från användare utifrån hur omfattande dessa är och hur mycket värde de tillför kunden. Önskemål som återkommer ofta styr automatiskt prioriteringen medan “är det en idé som inte återkommer eller tillför tillräckligt värde till de andra kunderna, så kommer det förmodligen inte prioriteras”, eftersom
ändringar som görs påverkar hela installationen och därmed alla användare inom Region Stockholm.
Respondent 2
Respondent 2 berättar att samarbetet mellan Acceptus och en ny privat vårdgivare startar med diskussion gällande systemets uppbyggnad utifrån verksamhetens och användarnas behov.
Respondent 2 beskriver kunskapen om hur användarna bedriver verksamheten som väldigt
viktig vid utformningen av systemet. Vårdgivaren involveras i utformandet av systemet
genom att Acceptus tar reda på hur de vill arbeta och utifrån olika grundmallar och sina
16
tidigare erfarenheter så införs systemet anpassat till vårdgivaren. Senare vid driftsättningen erbjuder Acceptus även utbildning vid nyinstallation. Företaget får även ibland in feedback och önskemål av vårdgivarna men eftersom majoriteten av de privata vårdgivarna är mindre verksamheter så har de enligt respondenten inte resurser för att kunna gå djupare in på förbättringsförslag.
Respondent 3
Respondent 3 berättar att önskemål och behov som uttrycks av användarna, det vill säga sjukvårdspersonalen, går via avdelningens IT-ansvariga och vidare till den lokala TakeCare- förvaltningen. Dessa ärenden skrivs in i ett hanteringssystem som erbjuder användarna möjligheten att följa hela ärendeprocessen från att det är mottaget, besvarat och hanterat av förvaltningen.
Respondent 4
Respondent 4 har aldrig blivit involverad i utveckling av journalsystemet. Respondenten känner inte till vem på avdelningen som är ansvarig för att samla upp information om behov och feedback om journalsystemet samt om det finns någon möjlighet att som
sjukvårdspersonal påverka systemets utformning. Vidare anser Respondent 4 att involvering av sjukvårdspersonal vid utveckling av TakeCare kan vara betydelsefullt och att “det är viktigt att involvera personal i vården i saker som berör vården. Man kan ju inte bestämma, hitta på och inte fråga de som kan eller ska arbeta med det”. Däremot ser Respondent 4 ett problem med användarinvolveringen i och med att det finns många andra mer akuta problem inom sjukvården som gör att detta kan hamna i skymundan.
Respondent 5
Respondenten 5 har aldrig involverats och känner inte till ifall det finns något särskilt system eller ansvarig person på avdelningen för att som användare kunna involveras i utvecklingen av journalsystemet. Vidare vet respondenten inte om de åsikter och feedbacks som uttrycks på avdelningen förs vidare till ansvariga för utvecklingen av TakeCare. Respondent 5 tror att man kan vinna mycket på att involvera sjukvårdspersonalen vid utveckling.
Respondent 6
Respondent 6 har aldrig blivit involverad i utvecklingen av journalsystem och känner inte till om det finns ett system för att fånga upp behov och åsikter från sjukvårdspersonalen.
Respondenten berättar däremot om möjligheten för sjukvårdspersonalen att skriva
arbetsmiljöavvikelser ifall vissa program inte fungerar, men respondenten är osäker på om
man också kan komma med åsikter gällande journalsystemet här.
17
4.4 Problem vid användarinvolvering
Detta avsnitt beskriver problem som de olika respondenterna har uttryckt gällande involvering av användare i utvecklingsprocessen av TakeCare. Avsnittet är uppdelat i rubriker
innehållandes information från Respondent 1 till Respondent 6.
Respondent 1
Respondent 1 berättar att det upprepade gånger har förekommit att CGM har gjort
utvecklingar inom TakeCare och att det efter ungefär ett halvår har upptäckts att produkten inte stämmer överens med de behov som användarna uttryckt i början av processen. Vidare berättar Respondent 1 att de under sprintdemos kan dyka upp nya aspekter och behov hos användarna. Dessa kan i sin tur resultera i små eller stora förändringar som behöver genomföras och integreras i utvecklingen av systemet.
Respondent 1 förklarar att det kan vara svårt att få en spridning av deltagare från olika professioner i utvecklingsgrupperna. Även om det finns ett stort intresse för att delta är det svårt för många av användarna att kunna gå ifrån arbetet för att delta på träffarna. Detta har ett flertal gånger resulterat i att rätt personer inte har kunnat delta i gruppen från start, vilket i sin tur ha medfört problem gällande förståelse för användarbehoven.
Respondent 1 berättar också att det finns en risk med att involvera kunden hela vägen i processen på grund av att det kan göra processen spretig. Deltagarna i användargruppen funderar mycket på egen hand vilket kan resultera i att de kommer med nya förslag och behov från dag till dag. Ett annat problem är att det som fungerar för en användare på en vårdenhet kanske inte fungerar eller tillför värde hos en användare som arbetar på ett annat ställe.
Särskilt problematiskt är det om fokusgrupper byts ut och nya personer kommer in sent i processen med nya perspektiv och idéer. Även om idéerna är bra och skulle tillföra mer värde för användarna så säger respondenten att det kan vara svårt att på ett bra sätt ställa om i utvecklingsprocessen. Respondent 1 säger också att det saknas en uttalad strategi för att undvika sådana här problem, men genom att ha med personer från olika professioner från start så kan det underlättas.
Respondent 2
Respondent 2 berättar att ett problem som hindrar användarinvolveringen är att
journalsystemet är ett gammalt system och ‘’går du in och tittar i koden bakom det hela så är
det spagettikod numera, det är inga öppna standarder för det fanns inga öppna standarder att
bygga det på när man byggde upp det’’. Respondent 2 menar att det därför är svårt att ändra
och utveckla koden på grund av att det tar lång tid och även kan vara en ekonomisk fråga att
ta ställning till.
18
Ett annat problem som Respondent 2 ser är att det inom Region Stockholm pågår en
upphandling som kallas Framtidens Vårdinformationssystem och avser ett byte av TakeCare till ett annat journalsystem. Ett gemensamt upphandlingsarbete skulle enligt respondenten gynna patienthanteringen så att det enklare går att läsa journalen oberoende av vilken region du befinner dig i. På grund av upphandlingen så anser Respondent 2 att utvecklingen i TakeCare bortprioriteras i och med att det finns en osäkerhet om journalsystemets framtid.
Respondent 3
Enligt Respondent 3 är det väldigt svårt att som sjukvårdspersonal få igenom större förslag på förändringar rörande TakeCare. Istället menar Respondent 3 att det mest betydelsefulla gällande användarinvolveringen är kontakten gentemot sjukvårdspersonalen och att “det är upp till TakeCare-förvaltningen att fånga upp det som är viktigt och att den kontakten är otroligt bra”.
Respondent 3 uttrycker problematik med förhandlingen om Framtidens vårdinformationsmiljö gällande att för få representanter från sjukhus och primärvården med erfarenhet av
sjukvårdens behov funnits representerade från start av upphandlingen och att representationen utgjorts av tjänstemän, som respondenten menar “inte vet vad sjukhus, regionen och
vårdcentraler egentligen vill ha”. Den nya upphandlingen, som innebär att TakeCare kan komma att bytas ut om några år, ser Respondent 3 som en bidragande orsak till att personal inte engagerar sig i att komma med förbättringsförslag. Även samma sak åt andra hållet, det vill säga att CGM inte lägger ner tid och pengar på att lägga till stora uppdateringar innan upphandlingen är färdig.
Respondent 4
Respondent 4 berättar att det skulle ge väldigt mycket om personalen blir mer involverade i frågor gällande utveckling av TakeCare och att det finns förbättringsmöjligheter, men att det just nu finns många andra problem i sjukvården som är mer akuta, vilket kan vara orsak till att det inte prioriterats på sjukhusen. Respondenten berättar att all personal har sina
ansvarsområden på avdelningen vilket kan orsaka att tid inte läggs på områden som man inte ansvarar för. I och med att TakeCare kan komma att bytas ut inom en snar framtid så ser Respondent 4 att en tänkbar följd är att användarna inte kommer med så mycket feedback.
Respondent 5
Respondent 5 vet inte om de åsikter och den feedback som tas upp på vårdavdelningens
möten gällande TakeCare förs vidare till ansvariga för utvecklingen. Respondent 5 vet inte
heller om det finns någon särskild person på avdelningen att vända sig till vid synpunkter på
systemet. Respondenten har heller inte fått någon förfrågan eller liknande att vara med och
utveckla TakeCare. En ytterligare faktor som kan hindra utvecklingen av TakeCare enligt
respondenten är upphandlingen av journalsystemen.
19
Respondent 6
Respondent 6 känner i dagsläget inget behov av att bli involverad och hävdar att problem som har funnits har blivit åtgärdade och systemet överlag fungerar bra. Det kommande bytet av journalsystemet tror respondenten har en påverkan genom att fokus inte kommer ligga på att förbättra de problem som finns, utan man vill utveckla ett nytt system istället och att detta kan göra att användarinvolvering inte prioriteras i dagsläget.
Respondenten känner inte till om uttryckta behov från sjukvårdspersonalen förs vidare till
ledningsnivå. En risk som respondenten ser som sannolik är att “mycket hamnar mellan
stolarna” mellan sjukvårdspersonalen och ansvariga för TakeCare.
20
5. Diskussion och analys
Detta kapitel innefattar analys och diskussion utifrån teoriområdet i kapitel 2 och resultatet i kapitel 4.
5.1 TakeCare anses inte vara tillräckligt kompatibelt med andra system
Respondent 4, 5 och 6 upplever att journalsystemet överlag fungerar i det dagliga arbetet.
Detta innebär enligt Ullman (2014) att endast användarnas basbehov är uppfyllda, vilket gör att funktionaliteten med systemet uppfylls men att nöjdheten hos användarna är relativt låg.
Detta kan vi se stämmer i och med att respondenterna uttryckte behov som inte uppfylls i systemen men som skulle göra dem mer tillfredsställda, vilket vi tolkar tillhör kategorin uttalade behov enligt Ullmans definition.
Ett uttalade behov som uttrycktes av både Respondent 4, 5 och 6 och som ej är uppfyllt i journalsystemet är kopplat till dess kompatibilitet med andra system inom sjukvården. Även Respondent 3 poängterar att kompatibiliteten är betydelsefull i det vardagliga arbetet. Ett annat exempel på ett uttalat behov hos dessa fyra respondenter är att Region Stockholm, allra helst hela Sverige, ska ha samma journalsystem. Detta påpekar både Respondent 4, 5 och 6 som ett problem kopplat till patientsäkerhet på grund av risken att viktig information om en patient missas eller inte finns tillgänglig för alla. I och med detta kan vi se att
patientsäkerheten har en stark koppling till bristande kompatibilitet och avsaknaden av ett enhetligt journalsystem i landet. Eftersom dessa brister inte endast orsakar problem för användarna själva utan även har en negativ inverkan på patienterna så ser vi att detta bör ses som en prioriterad funktion vid utveckling.
I Kano-modellen finns även så kallade outtalade behov vilket är behov som användaren själv inte kan beskriva (Ullman, 2014). Dessa har vi i studien inte kunnat identifiera hos
sjukvårdspersonalen, vilket kan ha sin förklaring i att studien inte har som fokus att ta reda på de outtalade behoven. Då sjukvårdspersonalens basbehov gällande produktfunktion är
uppfyllda men att det uttalade behovet gällande förbättrad kompatibilitet inte uppfylls, innebär enligt Ullman (2014) att kundnöjdheten inte blir lika hög.
5.2 CGM och Acceptus arbetar med användarinvolvering på olika sätt
Mumford (1995) beskriver konsultativ involvering som när användarna ger feedback på alternativ under produktutvecklingsprocessen och klassas som en medel grad av involvering.
Enligt Respondent 1 och 2 så använder sig båda företagen av detta i och med att de tar in åsikter från slutanvändarna. Genom informativ involvering, som har en låg grad av
involvering och inflytande, så sker en dialog mellan slutanvändare och utvecklare (Mumford,
1995), vilket Acceptus använder sig av i början av processen.
21
Abras et al. (2004) hävdar att en sådan här insamling av användardata är ett sätt att ta reda på användarnas behov, vilket Respondent 2 bekräftar genom att detta görs för att ta reda på hur användarna arbetar och att det är nödvändigt för att kunna anpassa journalsystemet till dem.
Mumford (1995) beskriver en medverkande metod av involvering med hög påverkan och involvering av användarna, vilket CGM använder sig av i och med användargrupperna. CGM och Acceptus arbetar på olika sätt med TakeCare vilket vi kan se vara en förklaring till varför metoderna samt graden av användarinvolvering skiljer sig åt mellan de två företagen. Då CGM är utvecklarna till systemet så kan vi se att de har ett behov av att involvera användarna i högre grad än vad Acceptus har som enbart förvaltar och inför systemet hos verksamheter.
En annan intressant aspekt är att användargrupperna som CGM använder sig av består av ganska få användare, vilket kan vara en bidragande orsak till att behoven inte identifieras korrekt. En användare från en vårdenhet kanske har helt andra behov än användare som arbetar på andra ställen.
Enligt Al-Rahman et al. (2012) kräver det mycket tid, är dyrt och ansträngande för
användarna att involveras i processen. Detta beskriver även Respondent 2 genom att Acceptus kunder till majoritet består av mindre privata vårdgivare som inte alltid har resurser att lägga på ytterligare deltagande av utvecklingen. I och med detta kan vi se att det faktiskt kan finnas ett behov hos Acceptus kunder att involveras mer i processen för att på så sätt få fler behov tillgodosedda.
5.3 Agila och integrerade processer innebär bättre användarinvolvering
Enligt Tonnquist (2018) och Azanha (2016) är agila arbetsmetoder dominerande inom mjukvaruprojekt och ett effektivt tillvägagångssätt vid föränderliga omständigheter. Detta stärks Respondent 1 som berättar att CGM arbetar agilt under utvecklingsprocessen där det ofta dyker upp nya krav och behov under processens gång som utvecklarna måste ta hänsyn till.
De olika utvecklingsteamen på CGM arbetar integrerat och parallellt med TakeCare under processen för att ta fram lösningar och kravspecifikationer utifrån önskemål. Enligt O’Connor (2003) ökar ett integrerat arbetssätt möjligheten till positiva resultat och Tonnquist (2018) hävdar att arbetssättet gör att problem kan upptäckas i god tid. Detta beskriver även
Respondent 1 i och med att utvecklarna via regelbundna sprintdemos uppdaterar varandra om processen och hur de gemensamt kan lösa problem som dyker upp. Säljarna på CGM har regelbunden kontakt med kunden Region Stockholm för att löpande uppdatera under utvecklingsprocessen och genomföra delleveranser. Tonnquist (2018) och Azanha (2016) menar att dessa typer av kontinuerliga feedbackloopar mot användare och täta leveranser är centralt för att upptäcka förändringar i tid.
Samtidigt säger Respondent 1 att ett återkommande problem har varit att de sent i processen
upptäcker att fokus inte ligger på rätt behov, vilket vi kan tolka som att utvecklingsprocessen
22
någonstans brister. En möjlig orsak kan vara att säljarnas täta kontakt sker med kunden Region Stockholm och inte specifikt mot slutanvändarna, vilket kan innebära att utvecklingsteamen i första hand utvecklar utifrån vad Regionen vill ha och inte
slutanvändarna själva. Detta resonemang förstärks även genom att Respondent 1 förklarar att de behov som uttrycks av Region Stockholm inte alltid stämmer överens med vad som egentligen behövs och att detta är upp till utvecklarna att reda på. Ullman (2014) beskriver detta som ett outtalat behov genom Kano-modellen och att det är dessa behov som gör användarna som mest tillfredsställda om de uppfylls.
En annan möjlig orsak till att CGM haft återkommande problem med att fel behov identifierats går att beskriva enligt Design-paradoxen som visar att designfriheten är som störst i början av processen, men att förståelsen för produkten som ska utvecklas här är lägre (Ullman, 2014). Detta ser vi kan vara en förklaring till varför behov som utvecklarna
identifierar hos kunden och användarna tidigt i processen senare har visat sig inte stämma överens med vad som egentligen behövs, i och med att utvecklarna får mer kunskap om problemet ju längre processen fortskrider.
5.4 Användarbehov prioriteras olika vid utvecklingen
Abras et al. (2004) beskriver det inte som nödvändigt att få med alla intressenter i
utvecklingsprocessen, men att det är viktigt att känna till vilka de är och hur produkten kan komma att påverka dem. Respondent 1 förklarar dock att utvecklarna strävar efter att få in användare från olika professioner på sjukhus och förvaltning i användargrupperna för att på så sätt kunna få en bred representation av användarnas behov och sedan använda det för att ta fram en efterfrågad produkt. Samtidigt säger Respondent 1 att en utveckling av systemet inte genomförs om inte alla användare och intressenter blir positivt påverkade. CGM har många intressenter och typer av användare vid utveckling av journalsystemet och Respondent 1 menar att detta innebär att alla behov och önskemål inte kan tillgodoses utan måste prioriteras.
Faktumet att CGM endast gör förändringar i TakeCare om alla användare påverkas positivt kan innebära en fördel i och med att alla på något vis kommer gynnas av utvecklingen.
Däremot ser vi att detta kan vara ett hinder för utvecklingen av systemet, eftersom
förbättringar kan utebli på grund av att till exempel en specifik avdelning eller profession blir
negativt påverkade. Respondent 1 beskriver även att konsekvenserna blir väldigt stora om en
felaktig prioritering görs, vilket vi kan se riskerar leda till ett sämre resultat genom att de
viktigaste behoven inte tillgodoses eller att en funktion i TakeCare till och med kan
försämras.
23
5.5 Typ av utvecklingsprojekt avgör mängd och metod för användarinvolvering
Respondent 1 poängterar att en löpande kontakt med kunden är prioriterat och att
användargrupper används för att aktivt identifiera användarnas behov och utifrån det iterativt utveckla lösningar. Detta är enligt Gulliksen och Göransson (2002) samt Maguire (2001) centrala aspekter inom användarcentrerad design för att skapa en tydlig förståelse för
användarens krav och behov. Däremot på vilket sätt och hur hög grad användarna involveras vid utvecklingen varierar beroende på typ av projekt samt utvecklingens omfattning och längd. Användarinvolveringen var liten eller helt obefintlig i korta projekt samt i projekt med fokus på back-end utveckling. Däremot i projekt fokuserade på front-end utveckling är det vanligare att användarna involveras under hela processen, där användarinvolveringen i form av fokusgrupper och tester sker både tidigt och löpande i processen, innefattandes
diskussioner om problem och krav men även användartester. Detta är inte enligt Abras et al.
(2004) som menar att tester endast ska göras tidigt eller i slutet och fokusgrupper endast i början, vilket vi inte ser vore gynnsamt vid utvecklingen av TakeCare eftersom utvecklarna löpande gör iterationer som de presenterar för användargruppen med syftet att förbättra systemet.
Användarinvolvering vid mjukvaruutveckling beskrivs enligt Al-Rahman et al. (2012) som central för användarnas nöjdhet. Det går att se en brist av involvering applicerat på back-end utvecklingen i och med att behov kanske inte fångas upp på grund av låg eller obefintlig användarinvolvering. Detta förstärks av Respondent 3, 4, 5 och 6 som alla har uttryckt behov gällande utökad kompatibilitet mellan andra system, vilket är kopplat till back-end
avdelningens arbete, men inte är uppfyllt i tillräckligt hög grad. Vid front-end utveckling verkar utvecklarna lyckats bra med användarinvolvering, eftersom samma fyra respondenter anser att systemet är användarvänligt. Detta tolkar vi som att respondenterna är nöjda med systemets gränssnitt. I och med detta kan vi se ett behov av att CGM bör använda mer resurser på användarinvolvering vid back-end projekt så att systemet kan utvecklas med fler funktioner som efterfrågas av användarna, såsom kompatibiliteten.
5.6 Det finns återkommande problem med användarinvolvering
Även om Respondent 1 beskriver många fördelar som användarinvolvering för med sig, så
betonas även risker ur tre perspektiv: om inte rätt användare är involverade från start, om
användare byts ut eller om involveringen blir för hög. Att fel behov identifieras är ett
återkommande problem hos CGM vilket de förklarar har sin grund i att de från start inte
lyckats få tag på tillräckligt bra spridning av deltagare från relevanta professioner samt att
användare ibland byts ut under processens gång. Att involvera användare är tidskrävande
enligt Al-Rahman et al. (2012) vilken också beskrivs av Respondent 1 som säger att
anledningen till att spridning av deltagare saknas, byts ut och rätt användare inte är
medverkande, är en konsekvens av att sjukvårdspersonalen har svårt att komma ifrån sitt
24
